Some Software Development Considerations

The traditional method to develop IS applications is a staged approach. It is generally called the "waterfall" approach, because the whole project is divided into several consecutive phases normally called "Product Specification", "High Level Design", "Low Level Design", "Coding", "Testing", and finally "Introduction". To enter a new phase is only allowed, if the final checkpoint of the previous phase has been passed successfully.

With the advent of new object oriented programming languages like Smalltalk and Java this approach was discarded by a lot of programmers in favour of an iterative approach called "spiral" or "fountain" approach. It normally starts with a first draft of a program. This draft (sometimes called a prototype) is then discussed and refined in various iterations until it is commonly accepted.

It is claimed by the advocates of that iterative approach that it will generate results which are better accepted by the potential end users. This is because these potential end users get relatively early an impression about the look and feel of the new product by playing around with the early "prototypes". The potential end users by that can influence the product very directly.

This seems to be a valid argument, but experience shows, that projects not performed under the stringent rules of the waterfall model tend to blow established schedules significantly. There seems to be a serious conflict between "time to market" and product acceptance.

The truth seems to be in the middle. At least for larger development projects the following arguments and statements will hold:

A Recommended Development Approach

If a product has to be developed that covers business wise a complete industry sector (or at least a considerable part of it) I recommend the "ingenious waterfall" model. That is, I recommend to perform first a (relatively) comprehensive problem domain analysis in order to generate a business design ("to be") model. After that, based on this model a basic technical design of a solution system (at least to the level of what is called high level design in the traditional structured development approach) should be performed. This high level technical design than can be the basis for a segmentation of the problem domain into various implementation projects. According to the available resources the defined implementation projects can be done in parallel or one after the other.

Development approach
    A recommended development approach.

The major advantage of this approach is, that the implementation of the various product components can be done on a sound basis - a comprehensive and highly consistent business model. That will guarantee, that the product components seamlessly fit together, that is, there is no functional overlap and no duplication of effort.

But there are other advantages:

Software Specification Considerations

According to the diagram above the product (or problem) specification phase is the first phase in a development cycle for an IS business application suite.

During this phase the envisaged application must be described as comprehensive as possible from a business perspective. I recommend for this description the form of a business model because pure business functions (not polluted by any organizational and technical aspects) normally do not change dramatically over times and therefore this type of specification is very stable and stays valid for a long time.

There are basically three types of application software:

  1. generic middle-ware and tools like workflow managers, transaction managers, information protection managers, text- and graphical editors, or spreadsheets.
  2. computer games which can be played standalone or even in a network.
  3. business software to control and support the business transactions of an enterprise in order to stay competitive.

There are basic differences between these software types. The most important difference is probably the treatment of data.

For tools and games there is normally little need to use data elements which are shared between all active instances of the software. Inconsistencies between information instances used in various active software instances may be tolerable. An exception may be games which are played in a network environment like the World Wide Web.

The purpose of business software is mainly information treatment. That means information instances used by the various application instances must be consistent. The integrity of the enterprise database is normally vital for a company and therefore the most important task of the software system(s) used by the enterprise is to guarantee this integrity. This creates specific requirements for the commercial business application development.

This document deals especially with the development of commercial business software, so it is important to understand the specific requirements for this type of software and also the differences with respect to the other types.

If we start with the development of a commercial business application we immediately recognize (normally already during the creation of the functional specifications) that we normally deal with a rather complex problem domain. Within this problem domain especially the information units but also the essential workflow components appear at various places.

There is a principle difference between the treatment of an information element determining the size of a font used for the text of a specific document which has to be created by a specific editor tool and the treatment of information elements belonging to an order which flows e.g. through the various departments of a trading company.

Tools normally have a considerable number of more or less independent parameters with a limited number of allowed values. They also have normally a large number of well defined, but small, and not too complex elementary operations which are relatively independent but controlled by the parameter values set for the active session. Interactive usage of the provided elementary functions by the end-user is typical for tools.

For industry specific business applications the number of parameters which control how the business itself is handled (not those which determine the presentation of information in a window on the screen) is normally not that high, but the integration of activities is much more intensive. Very often there are defined sequences of actions requiring a specific type of information provision with well determined database access operations in order to perform a concrete business task.

Tools normally do not require a database as a repository for "sleeping objects" or "instances of information groups" which conform to a specific type of information structure.

Commercial business applications use the same data elements (instances) within various business processes. The business processes may be independent from each other or they may be dependent on each other. Because information values are used simultaneously in various processes and because they almost always have an influence on the desired business transaction result, it is important to structure the information well and make sure, that each process uses the same and the most actual information value. Otherwise it will be impossible to guarantee the integrity of the database of a company.

Another desirable demand on commercial business software is to support specific elementary business transactions always by the same elementary software procedures. It is very confusing for end users of a commercial software system if for similar business transactions different support is offered. This always has to be avoided.

The two requirements (the integrity of the commercial database and the provision of unique essential business procedures) make it obvious, that for the development of commercial software systems it is much more important than for a tools development, to thoroughly analyse the problem domain and to provide a fairly comprehensive documentation about the analysis results. The goal during this phase therefore should be to generate a sound business specification free of any organizational and technical aspects which can be the basis for the design of an IT application optimally supporting the business of the described problem domain and which can in addition be the basis for managerial decisions how to run the business in the future. Although changes are seldom after the completion of the specification it nevertheless should be documented in the form of a Business Model, a form of documentation which can be kept up to date easily.

Top of page
Table of Content