Notes on SDLC Models

Waterfall
The Waterfall Model assumes that distinct phases of development of a whole system exist for analysis, preliminary design, detailed design, coding and unit test, and system test.
Documentation produced at the end of each phase provides the basis for work performed in the next phase of development.
In the Waterfall Model, characterized by a single build of software (one increment), the software development effort must return to previous phases of development to fix misunderstood or unstated requirements, design flaws, and logical coding errors discovered in later phases of the model.
Guidelines for selection
1. All capabilities are needed for first delivery
2. Risk of delivery is minimal
3. Requirements are complete, stable, and well understood
4. Technology is well understood
5.This model has its peak loading during the midpoint of the development activity (the design and coding phase).
6.All funding and staffing are available at the beginning Waterfall Model

Spiral

The Spiral Model adds risk analysis and prototyping activities at the beginning of each phase defined in the Waterfall Model to address the perceived risk areas of a project
The Spiral Model focuses on significant areas of risk, studies alternative solutions, and develops prototypes and simulations to explore the strengths and weaknesses of candidate solutions.
Some implementations of the Spiral Model suggest incremental development of a system by completing its component parts in sequence.
Guidelines for Selection
1 Applicable to high-risk programs where prototyping will be used to minimize risk
2 Requirements incomplete, unstable
3 Lack of DemVal Program
4 Applicable to large-scale projects
5 This model has relatively flat loading during the development activities.

Rapid Prototyping
The Rapid Prototyping Model is designed to develop a complete, unambiguous set of requirements early in the analysis phase of the lifecycle by conducting frequent reviews of a functional prototype by customers and users during the analysis phase.
This approach hopes to avoid delaying the detection of analysis and design problems to the integration and test phase of development, where they are more expensive to fix.
The developers create a prototype that exhibits their understanding of customer requirements. The customers and users review the prototype for conformance to their view of how the system should operate. The prototype is evolved until it becomes a dynamic operational specification of the actual requirements.
Guidelines for Selection
1 This model has the highest loading early in the development cycle, since it involves very intense customer involvement during the early phases of development with correspondingly low levels of activity during test and integration.
2 Lack of DemVal program
3 Customer doesn’t fully understand requirements

 

Incremental
The Incremental Model determines user needs and defines the system requirements, then performs the rest of the development in a sequence of builds.
The first build incorporates a subset of the system’s planned capabilities; the next build adds more capabilities, and so on, until the system is complete. This model allows early delivery of functions to the customer as development continues on other functions.
Guidelines for Selection
1 Early capability is needed, and not all capabilities are needed at first delivery
2 Requirements are well understood, and complete at the beginning of the program
3 Requirements are stable
4 System functionality breaks naturally into increments
5 Funding and staffing are not all available at beginning
6 This model has its peak loading early in the development cycle

Evolutionary

The Evolutionary Model, like the Incremental Model, develops the system in builds, but differs from the Incremental Model in acknowledging that the user need (or some other aspect affecting the generation of system requirements) is not fully understood and that all requirements cannot be defined early in the development cycle.
The system design may be evolving in parallel with the software activities. In each build, new software requirements are defined and the existing requirements are refined. Rapid Prototyping may be used as an early build with this method.
Guidelines for Selection
1 Early capability is needed
2 Not all capabilities are needed for first delivery
3 Not all requirements can be developed at once
4 Requirements are expected to change
5 User feedback of initial capability is needed to develop requirements
6 Technology development is needed to develop requirements
7 System functionality breaks naturally into increments
8 Funding and staffing are not all available at the beginning of the project
9 Prototyping is needed
10 This model has relatively flat loading during the development activities

 

Advantages

Waterfall	Spiral	Rapid	Incremental	Evolutionary
	1. The Waterfall Model is widely used on projects of all sizes	1. Early attention to options for the use of existing software in the form of COTS or reusable software components	1. The Rapid Prototyping Model is well suited for the Demonstration and Validation phase of system procurement and to IR&D projects because it produces a working prototype that captures refined requirements (a live requirements document).	1. The Incremental Model delivers product to the customer earlier than some other models.	1. The Evolutionary Model shows early capability.
	2. The model provides a disciplined, structured approach to the software development process	2. This model encourages the identification and evaluation of alternative solutions	2. The Rapid Prototyping Model excels in developing a complete set of system requirements. The Rapid Prototyping Model blurs the distinction between analysis, design, and coding to overcome the traditional breaks between these three activities	2. This strategy models situations where the system breaks naturally into increments.	2. This strategy anticipates changes to the system or changes because user feedback and monitoring are necessary to understand the full requirements.
	3. The model provides an accurate document trail, including revision histories	3. Mechanisms are provided for incorporating software quality objectives into the software product development process		3. This model is appropriate when the system is too large to do all at once, or when funding or staffing will be provided in increments.	3. This strategy models situations where the system breaks naturally into increments
		4. This method allows the identification of all types of objectives and constraints during each round of the spiral			4. This model is appropriate when the system is too large to do all at once, or when funding or staffing will be incremental.
		5. This model features flexible management of the software lifecycle by accommodating a mix of software development methodologies (e.g., structured analysis, object oriented, prototyping, etc.)			5. This model is able to utilize a Rapid Prototyping capability effectively.
		6. The opportunity to evaluate progress at each phase of the development process is provided by assessing risk and planning for the next phase			6. This strategy handles anticipated changes to the system or changes because user feedback and monitoring is provided to understand the full requirements.
		7. Each round provides the opportunity to use simulations, system models, or prototypes to evaluate system concepts, software requirements, and software architectures.  This feature accommodates the evolutionary prototyping software lifecycle model and allows simulation and software modeling tools to be integrated into the development process

 

Disadvantages

Waterfall	Spiral	Rapid	Incremental	Evolutionary
Disadvantages	1. The emphasis on documents being the completion criteria for the phases of the Waterfall Model makes the development process less flexible	1. Effort is required to elaborate the steps of the Spiral Model.  Specifically, the number of rounds of the spiral needs to be identified including the objectives and constraints of each round	1. Effort is concentrated in the analysis phase of development, which extends the time required to complete analysis.  The schedule of activities and dates for deliverables will not conform to the schedule that the customer has become accustomed to for the waterfall model.	1. The model is not appropriate when the user wants to see full capabilities at the first delivery.	1. The model is not appropriate when the customer wants the full capabilities in the first delivery.
	2. It assumes that requirements are fully developed early in the project. If requirements are not well understood, there is a risk that the final product may not meet customer expectations.	The model relies on the ability of the software development team and software managers to identify and manage project risks	2. Since there is not a clean break between analysis and design, the developers must ensure that the requirements are formally documented upon completion of the initial working prototype.	2. The contents and schedule for builds must be tightly controlled to ensure their integrity and quality.	2. Additional effort must be spent to ensure that the coordination between the builds is well defined.
	3. The model provides an accurate document trail, including revision histories	Each stage of the spiral must be executed consistently for each round of the spiral in order to have a controlled and a well-managed software development project.	3. The customer and the contractor must revisit previous agreements concerning what is to be delivered from each phase.	3. Each successive build is dependent upon the previous build.	3. Each successive build is dependent upon the success of the previous build.
	4. The model relies on the ability of the software development team and software managers to identify and manage project risks.  It also forces cost estimation and project planning to occur after only a limited amount of analysis has been performed.	For the spiral model to be used effectively, an organization must have solid experience identifying, prioritizing, and mitigating risk		4. The model relies on the ability of the software development team and software managers to identify and manage project risks. Cost estimation and project planning must be performed continuously throughout the project.