The models of SW Development

The models of SW Development
Waterfall Model
Overview
Waterfall development isn t new — it s been around since 1970 — but most developers still only have a vague (unclear) idea of what it means. Essentially, it s a framework for software development in which development proceeds sequentially through a series of phases, starting with system requirements analysis and leading up to product release and maintenance. Feedback loops exist between each phase, so that as new information is uncovered or problems are discovered, it is possible to "go back" a phase and make appropriate modification. Progress "flows" from one stage to the next, much like the waterfall that gives the model its name.
A number of variants of this model exist, with each one quoting slightly different labels for the various stages. In general, however, the model may be considered as having six distinct phases, described below:
1. Requirements analysis: This first step is also the most important, because it involves gathering information about what the customer needs and defining, in the clearest possible terms, the problem that the product is expected to solve. Analysis includes understanding the customer s business context and constraints, the functions the product must perform, the performance levels it must add here to, and the external systems it must be compatible with. Techniques used to obtain this understanding include customer interviews, use cases, and "shopping lists" of software features. The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step.
2. Design: This step consists of "defining the hardware and software architecture, components, modules, interfaces, and data...to satisfy specified requirement". It involves defining the hardware and software architecture, specifying performance and security parameters, designing data storage containers and constraints, choosing the programming language, and indicating strategies to deal with issues such as exception handling, resource management and interface connectivity. This is also the stage at which user interface design is addressed, including issues relating to navigation and accessibility. The output of this stage is one or more design specifications, which are used in the next stage of implementation.
3. Implementation: This step consists of actually constructing the product as per the design specification(s) developed in the previous step. Typically, this step is performed by a development team consisting of programmers, interface designers and other specialists, using tools such as compilers, debuggers, interpreters and media editors. The output of this step is one or more product components, built according to a pre-defined coding standard and debugged, tested and integrated to satisfy the system architecture requirements. For projects involving a large team, version control is recommended to track changes to the code tree and revert to previous snapshots in case of problems.
4. Testing: In this stage, both individual components and the integrated whole are methodically verified to ensure that they are error-free and fully meet the requirements outlined in the first step. An independent quality assurance team defines "test cases" to evaluate whether the product fully or partially satisfies the requirements outlined in the first step. Three types of testing typically take place: unit testing of individual code modules; system testing of the integrated product; and acceptance testing, formally conducted by or on behalf of the customer. Defects, if found, are logged and feedback provided to the implementation team to enable correction. This is also the stage at which product documentation, such as a user manual, is prepared, reviewed and published.
5. Installation: This step occurs once the product has been tested and certified as fit for use, and involves preparing the system or product for installation and use at the customer site. Delivery may take place via the Internet or physical media, and the deliverable is typically tagged with a formal revision number to facilitate updates at a later date.
6. Maintenance: This step occurs after installation, and involves making modifications to the system or an individual component to alter attributes or improve performance. These modifications arise either due to change requests initiated by the customer, or defects uncovered during live use of the system. Typically, every change made to the product during the maintenance cycle is recorded and a new product release (called a "maintenance release" and exhibiting an updated revision number) is performed to enable the customer to gain the benefit of the update.
Advantages
The waterfall model, as described above, offers numerous advantages for software developers. First, the staged development cycle enforces discipline: every phase has a defined start and end point. The emphasis on requirements and design before writing a single line of code ensures minimal wastage of time and effort and reduces the risk of schedule slippage (table sliding), or of customer expectations not being met.
Getting the requirements and design out of the way first also improves quality; it s much easier to catch and correct possible flaws at the design stage than at the testing stage, after all the components have been integrated and tracking down specific errors is more complex. Finally, because the first two phases end in the production of a formal specification, the waterfall model can aid (support) efficient knowledge transfer when team members are dispersed in different locations.
Criticisms
Despite the seemingly obvious advantages, the waterfall model has come in for a fair share of criticism in recent times. The most prominent criticism revolves around the fact that very often, customers don t really know what they want up-front; rather, what they want emerges out of repeated two-way interactions over the course of the project. In this situation, the waterfall model, with its emphasis on up-front requirements capture and design, is seen as somewhat unrealistic and unsuitable for the vagaries of the real world. Further, given the uncertain nature of customer needs, estimating time and costs with any degree of accuracy (as the model suggests) is often extremely difficult. In general, therefore, the model is recommended for use only in projects which are relatively stable and where customer needs can be clearly identified at an early stage.
Another, Often, designs that look feasible on paper turn out to be expensive or difficult in practice, requiring a re-design and hence destroying the clear distinctions between phases of the traditional waterfall model. Some criticisms also center on the fact that the waterfall model implies a clear division of labor between, say, "designers", "programmers" and "testers"; in reality, such a division of labor in most software firms is neither realistic nor efficient.
Customer needs
While the model does have critics, it still remains useful for certain types of projects and can, when properly implemented, produce significant cost and time savings. Whether you should use it or not depends largely on how well you believe you understand your customer s needs, and how much volatility you expect in those needs as the project progresses. It s worth noting that for more volatile projects, other frameworks exists for thinking about project management, notably the so-called spiral model...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



















Steps Of The Spiral Model





;





The Spiral Development ( or Lifecycle) Model is a systems development method used in information technology.
1- It combines the features of the prototyping model and the waterfall model.
2- It is favored for large, expensive, and complicated models. steps of the spiral model :-

1- Define the problem with as much detail as possible by interviewing the client and potential users of the system, as well as, studying any existing system.
2- A preliminary (initial) design is created for the new system.
3- A first prototype of the new system is constructed from the preliminary designed is a scaled down version of the final product
4. A second prototype is derived by the following procedure
– Evaluate the first prototype for strengths, weaknesses and risks
– Define the requirements of the 2nd prototype
– Plan and design the 2nd prototype
– Construct and test the 2nd prototype
At this point the customer may decide to scrap the whole project if:-
-The risk is too high.
–Development cost overruns
–Operating-cost
- Other factors that might result in a substandard product
1-Evaluate the current prototype in the same way as the previous prototype and create another one if needed
2. Iterate the proceeding steps until the customer is satisfied that the current prototype represents the final product.
3-construct the final system
The final system is thoroughly evaluated and tested and routine maintenance is carried out for the life of the product
Advantages
Estimates of the budget and schedule become more realistic as work progresses
1- Easier to cope with the changes inherent to software development
2- Software engineers can start working on the project earlier rather than wading through a lengthy early design process.
disadvantage
Estimates of budget and time are harder to judge at the beginning of the project since the requirements evolve through the process