Waterfall Model
The creation of large software applications is rarely, if ever, a simple and straightforward business. There are all the problems associated with vanilla programming, as also those associated with running a successful business, as well as the need to function in an environment where the competition is always fierce. There is not a great deal of scope for trial and error, and it is necessary to use a well-defined and rigorously enforced process model for software development that would form the basis for the creation of high quality software.
The standard life-cycle model of software is called a "waterfall model," because it is supposed to go down through a series of steps, reminding one of the route a natural waterfall takes over a series of rocks at different levels.
In the traditional waterfall model, the first step in the software life-cycle is requirements analysis--this is the stage where the customers are queried for their needs, and a formal description of the software requirements is created. The next step is design, where the software that is to meet the requirements is planned. The third stage is implementation, where teams of developers create the software. The fourth step is testing, at which time developers, as well as representatives of the user community, are allowed to use the software and are asked to report any bugs they find. Upon completion of this step, the software is declared operational, and only maintenance tasks are required thereafter.
The traditional waterfall model is much too simplistic, however, because each of the distinct steps it asks for is really itself a broad phase consisting of many sub-steps. To give a better perspective of what these smaller steps are, a more detailed waterfall model is usually described.
In the detailed waterfall model, the requirements analysis step is extremely important. It is necessary to understand the customer's needs and to translate them into appropriate desired system behaviors. Any miscommunication with the customer could be fatal to the project as a whole, as it could result in a product that does not meet the customer's expectations, thus giving the company a bad reputation--a real disaster in the competitive software vendor's marketplace. Yet, communicating with the customer is not always easy either, because the customer may have only vaguely-formulated objectives; or may have objectives that aren't vocalized very well and remain in the background for too long; or may have unrealizable or conflicting objectives. In some cases, it is necessary for the software development team to tell the customer exactly what he wants based on his vague utterances, and also whether he can get it--needless to say, this involves a fair amount of skill at diplomacy and personal communication, in addition to knowledge of software engineering. Once the customer's requirements are understood, it is then necessary to document those requirements in a formal manner and reach an agreement with the customer about them (this is most often done in the form of a legally binding contract).
Once the requirements analysis is over, design must happen. This itself has to have at least two distinct stages, system or architectural design at the large scale, and detailed design of modules, objects, and the like at the small scale.
After the design steps, module designs are coded by programmers, and are individually tested against their specifications. Such testing is usually called unit testing of modules. After the modules have been unit tested individually, they are put together as a functioning system in a step called system integration, and the system as a whole is tested to see if it meets behavior and performance requirements.
The customer cannot be left with just the system, of course—he will also want very detailed documentation that shows him how to use the system, what things to do or not do, and the like. The customer may also need special training in the system. For this reason, the finished product must be delivered to the customer with documentation, and possibly with training support as well. This documenting of the system and creation of training resources is considered to be part of the delivery step, but actually goes on from almost the very beginning of the software life-cycle, right in parallel with the development effort itself.
The waterfall model is conceptually simple to understand and is useful to explain the basics of software development, but even with the added detail, it is highly limited in its application as a practical method for managing such development. It is much too simplistic in its view of the software life-cycle, and focuses largely on creation of software as though it were a physical product or fixed artifact, rather than the result of incremental problem solving by a large group of diverse people. In practical software development, there are also numerous feedback loops that arise between stages--for example, a problem with the design may be discovered during implementation, leading to a reversion to the design step. The waterfall model also does not deal with hardware upgrades (a constant feature in contemporary information technology practice), incremental development, or development of later versions of software based on earlier ones.
The term "process maturity" refers to the effectiveness and comprehensiveness of an organization's software engineering practices. The widely accepted standard in this regard is the Capability Maturity Model (CMM) developed by the Software Engineering Institute at Carnegie-Mellon University in Pittsburgh, Pennsylvania. The CMM defines five levels of process maturity and has an associated assessment process to determine an organization's level of maturity in software engineering practice, with level five being the highest. An organization wishing to achieve the higher levels would probably do very well to avoid using the waterfall model of development and instead use an advanced model such as Boehm's Spiral Life-Cycle Model.
This is the complete article, containing 950 words
(approx. 3 pages at 300 words per page).
