Академический Документы
Профессиональный Документы
Культура Документы
Evolutionary
Spiral
model
Spiral model
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottomup concepts. Also known as the spiral lifecycle model, it is a systems development method (SDM) used in Information Technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects. Each cycle involves the same sequence of steps as the waterfall process model.
History
The spiral model was defined by Barry Boehm. the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project
In the spiral model, the radial coordinate represents cost the angular coordinate represents progress in completion of a cycle of the model
The first quadrant is to determine objectives, alternatives, and constraints for the cycle. 2. The second quadrant is a risk analysis and evaluation of alternatives for the cycle. 3. The third quadrant is to develop and verify the next level product. 4. The fourth quadrant involves planning for the next phases.
1.
The Spiral Model is intended to encompass other life cycle models such as the Waterfall Model, the Incremental Development model, and the Throwaway Prototyping Model. During Risk Analysis, the key characteristics of the project are determined, referred to as process drivers. The process drivers are used to determine which process model is most appropriate for the project. In this way, the Spiral Model can be considered a process model generator [Boehm89]. The spiral model consists of four quadrants:
1. 2. 3. 4.
Defining Objectives, Alternatives, and Constraints Analyzing Risks Developing Product Spiral Planning
Objectives: functionality, performance, hardware/software interface, critical success factors, etc. Alternatives: build, reuse, buy, subcontract, etc. Constraints: cost, schedule, interface, etc.
Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, poor process, etc. Resolve risks (evaluate if money could be lost by continuing system development
Typical activites: Create a design Review design Develop code Inspect code Test product
Typical activities Develop project plan Develop configuration management plan Develop a test plan Develop an installation plan
Risk factors might involve development cost overruns, operating-cost miscalculation, customer's judgment, lessthan-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime
Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently
Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during nondevelopment phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration
When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)
Applications
in large projects.
Advantages
Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. It is more able to cope with the changes that software development generally entails. Software engineers can get their hands in and start working on the core of a project earlier.
Incremental Model
More specifically, the model is designed, implemented and tested as a series of incremental builds until the product is finished. A build consists of pieces of code from various modules that interact together to provide a specific function. At each stage of the IM a new build is coded and then integrated into the structure, which is tested as a whole. Note that the product is only defined as finished when it satisfies all of its requirements.
Then slowly add increased functionality The incremental model prioritizes requirements of the system and then
Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.
This
model combines the elements of the waterfall model with the iterative philosophy of prototyping. IM focuses on the delivery of an operational product at the end of each increment.
Monday, September 7, 1:48:54 PM
Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses divide and conquer breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced
Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower
Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology
The End