Model Phases

Feasibility:	Defining a preferred concept for the software product, and determining its life-cycle feasibility and superiority to alternative concepts.
Requirements:	A complete, verified specification of the required functions, interfaces, and performance for the software product.
Product Design:	A complete verified specification of the overall hardware-software architecture, control structure, and data structure for the product, along with such other necessary components as draft user's manuals and test plans.
Detailed Design:	A complete verified specification of the control structure, data structure, interface relations, sizing, key algorithms, and assumptions of each program component.
Coding:	A complete, verified set of program components.
Integration:	A properly function software product composed of the software components.
Implementation:	A fully functioning operational hardware-software system, including such objectives as program and data conversion, installation, and training.
Maintenance:	A fully functioning update of the hardware-software system repeated for each update.
Phaseout:	A clean transition of the functions performed by the product to its successors.

Key Characteristics

• Each phase is required.
• Each phase ends with a verification, validation, or test activity to ensure that the objectives of each phase are satisfied.
• The product goes through each phase sequentially and produces ever improving baselines of intermediate products.
• Interactions within a phase occur until it is passes the transition criteria (verified or validated as satisfactory).
• The baseline, once achieved, is put under formal change control process. (No changes are made to the baseline unless all interested parties agree.)

Economic Rationales

1. In order to achieve a successful software product, must achieve all of the subgoals within each phase at some stage anyway.
2. Any different ordering of the phases will produce a less successful software product. (It costs more to remove defects later in the development cycle.)

Problems

• A sequential approach to building a product in which iteration is not visibly evident.
• Emphasis on fully elaborated documents as completion criteria for early requirements and design phases does not work well for many classes of software, particularly interactive end-user applications.

“Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. Hence, they cannot be fixed without fundamental revision—revision that provides for iterative development and specification of prototypes and products.”  —Fred Brooks