• CSCI - Computer Software Configuration Items
• HWCI - Hardware Configuration Items
• MIL-STD-498 - US Military standard 498
  

• The single requirements phase encourages specification of what the system is to do before deciding how the system will do it (i.e., specification before design.
• The single design phase encourages planning of the system structure before building the components (i.e. design before coding)
• The use of reviews at the end of each phase permits acquirer and user involvement
• The model permits early imposition of baselines and configuration control.
• Each preceding step serves as an approved, documented baseline for the succeeding step

Development Models:: Waterfall:: Disadvantages

Customers must be able to express their requirements completely, correctly, and with clarity.

• Delays can occur in design, coding, and testing.
• Too much time can be spent on the production of little-used documentation.
• It is difficult to access the true state of progress during the first two or three stages.
• Baselines and milestones place heavily emphasis on documentation in the early phases of the project.
• The developer must understand the application from the beginning.
• A large integration and test effort must occur near the end of the project.
• No demonstration of system capabilities can occur until the end of the project.

Fig.2: Development Models:: The Incremental Model

The assumption behind the model is that the requirements can be segmented into an incremental series of the products, each of which is developed somewhat independently.

Development Models:: Incremental Waterfall

Incremental Waterfall Model is shown on Figure 3.

Fig.3: Development Models:: The Incremental Waterfall

In addition to the benefits that arise from being variation of the waterfall model, the incremental model have the following advantages:

Development Models:: Incremental Waterfall:: Advantages

• Less cost and time is required to make the first delivery.
• Less risk is incurred to develop the smaller systems represented by the increments.
• User requirement changes may decrease because of the quicker time to first release.
  
• Incremental funding is allowed; that is, only one or two increments might be funded when the program starts.

• Fielding of initial increments may destabilize later increments through unplanned levels of user change requests.
• If requirements are not as stable or complete as thought earlier, increments might be withdrawn from service, reworked, and re-released.
• Managing the resulting cost, schedule, and configuration complexity may exceed the capabilities of the organization.

Development Models:: Evolutionary

The next logical step in life cycle development is the Evolutionary Model, which explicitly extends the Incremental Model to the requirements phase. Figure 4 illustrates this, showing that the first build increment is used to refine the requirement s for a second build increment.

Fig.4: Development Models:: Evolutionary

Development Models:: Evolutionary:: Advantages

• The model can be used when the requirements cannot or will not be specified.
  
• The user can experiment with the system to improve the requirements.
  
• Greater user/ acquirer involvement is required than in the waterfall method.

Development Models:: Evolutionary:: Disadvantages

•  Use of the method is exploratory in nature and therefore constitutes a high-risk endeavor. Strong management is required.
• This method is used as an excuse for hacking to avoid documenting the requirements or design, even if they are well understood.
• Users / acquires do not understand the nature of the approach and can be disappointed when results are unsatisfactory.

Spiral Development Model is shown on Figure 5.

Fig.5: Development Models:: Spiral

The main features of the Spiral Model are: 

• Planning, Analysis, Development, and Testing are repeated on each iteration.
• User Acceptance Testing will be started only after source code is ready.

Mapping of the Activities and Multiple releases (Builds) is shown on Figure 6.

Fig.6: Development Models:: Mapping of the Activities and Build Releases

See US Military MIL-STD-498 standard for further information.

Development Models:: V-Model

V-Model Development Process (actually, there are a lot of them!) is shown on the Figure 7.

Fig.7: Development Models:: V-Model

This view is used to show Test Cases, Test Data, Build Files, and Integration Plan flows as well as cross-verification (dotted lines) between phases of the software development.

Another meaning of the diagram Figure 7 is relationship between three activities of Software Development: System Engineering, Software System Engineering, and Software Engineering.

See US Military MIL-STD-498 and ISO/IEC 12207 standards for further details. Brief overview of ISO 12207 and related standards can be found here: http://www.acm.org/tsc/lifecycle.html.

Downloads

	Diagrams from the above Diagram Set could be downloaded in Zip format here:
	development_models_dia.zip
	Diagrams are created in Dia format. For Unix/Linux users it is a standard diagram drawing software. Windows users can obtain legal GPL-ed copy of Dia from http://dia-installer.de/index_en.html

Your Comments

It could be really great if you find time to submit your comments, corrections, and other feedback to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Regards,
 
Sergei