Waterfall model, Rapid Prototyping, throwaway prototyping model, evolutionary prototyping model, incremental/iterative development, spiral model, reusable

software model, and automated software synthesis, V model

Stakeholders start seeing results early, with the first increment, and are calmed. Developers start seeing results early, too, and are encouraged. If the system isn't turning out as the stakeholders expected, everyone finds out sooner. Short increment cycle times mean development is less likely to get seriously off track (there isn't time to). Daily build cycles mean each developers is forced to focus and fix bugs as they arise. Because everyone has to focus on what is important in order to prioritize system features and allocate them to increments, stakeholders and developers tend not to waste time on inessentials. Each increment (if well chosen) is of manageable size for the developers. Everyone is happier because the system is visibly working (incomplete, but working) from the beginning. Virtually all modern development processes are incremental. The waterfall process is best as a means of explaining software development phases, activities, and artifacts. It gives a general overview and is a good starting point for discussion. However, the processes by which people usually produce software are a good bit more complex. The spiral model is so general that it does not provide much guidance for novice software developers. For more sophisticated developers, it can help guide them in focusing on risks; that is what the spiral model is best for.

Waterfall, rapid prototyping models Operational quality complete product at end Incremental model Operational quality portion of product within weeks Less traumatic Smaller capital outlay, rapid return on investment Need open architecturemaintenance implications Variations used in object-oriented life cycle

**********************************8 Waterfall Problems Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. Few business systems have stable requirements. The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. Doesn't support iteration, so changes can cause confusion Difficult for customers to state all requirements explicitly and up front Requires customer patience because a working version of the program doesn't occur until the final phase Problems can be somewhat alleviated in the model through the addition of feedback loops (see the next slide) Inflexible partitioning of the project into distinct stages Difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood Because software is different :

No fabrication step Program code is another design level Hence, no commit step software can always be changed! No body of experience for design analysis (yet) Most analysis (testing) is done on program code Hence, problems not detected until late in the process Waterfall model takes a static view of requirements

Waterfall: 1. Idealized, doesnt match reality well. 2. Doesnt reflect iterative nature of exploratory development. 3. Unrealistic to expect accurate requirements so early in project. 4. Software is delivered late in project, delays discovery of serious errors. 5. Difficult to integrate risk management. 6. Difficult and expensive to make changes to documents, swimming upstream. 7. Significant administrative overhead, costly for small teams and projects [6]. Ignore changing needs Real large-scale projects rarely follow this model because a) it requires ALL requirements to be known in advance; b) the working model will be available only at the very end; c) customers are not involved into process, etc.). It works for small-size routine projects (nothing innovative in these projects) It usually used by very experienced software developers Lack of user involvement once specification is written Unrealistic separation of specification from the design

Doesnt accommodate prototyping, reuse, etc

Incremental Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing. Multiple independent deliveries are identified Work flow is in a linear (i.e., sequential) fashion within an increment and is staggered between increments Iterative in nature; focuses on an operational product with each increment Provides a needed set of functionality sooner while delivering optional components later Useful also when staffing is too short for a full-scale development Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing. The incremental model may be viewed as a modification to the waterfall mode. As software projects increased in size, it was recognized that it is much easier and sometimes necessary, to develop the software if the large projects are subdivided into smaller components, which may thus be developed incrementally and iteratively. In the early days, each component followed a waterfall process model, passing through each step iteratively. If any one component ran in trouble, the other components were able to still continue to be developed independently. Another perspective in utilizing the increment is to first develop the core software that contains most of the required functionality. The first increment may be delivered to users and customers as release 1. Additional functionality and supplemental features are then developed and delivered separately as they are completed, becoming Release 2, Release 3 and so on.

Spiral disadvantages:

Can be a costly model to use. 2. Risk analysis requires highly specific expertise. 3. Projects success is highly dependent on the risk analysis phase. 4. Doesnt work well for smaller projects [7].