Вы находитесь на странице: 1из 28

Monday, September 7, 1:42:43 PM

Evolutionary
Spiral

model

model Incremental model

Spiral model

Monday, September 7, 1:48:54 PM

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.

Monday, September 7, 1:48:54 PM

History

Monday, September 7, 1:48:54 PM

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

Monday, September 7, 1:48:54 PM

In the spiral model, the radial coordinate represents cost the angular coordinate represents progress in completion of a cycle of the model

traversing through four quadrants.

Monday, September 7, 1:48:54 PM

Each cycle involves traversing through four quadrants.

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.

Monday, September 7, 1:48:54 PM

Defining Objectives, Alternatives, and Constraints Analyzing Risks Developing Product Spiral Planning

Spiral Quadrant Determine objectives, alternatives and constraints

Monday, September 7, 1:48:54 PM

Objectives: functionality, performance, hardware/software interface, critical success factors, etc. Alternatives: build, reuse, buy, subcontract, etc. Constraints: cost, schedule, interface, etc.

Spiral Quadrant Evaluate alternatives, identify and resolve risks

Monday, September 7, 1:48:54 PM

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

Spiral Quadrant Develop next-level product

Monday, September 7, 1:48:54 PM

Typical activites: Create a design Review design Develop code Inspect code Test product

Spiral Quadrant Plan next phase

Monday, September 7, 1:48:54 PM

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.

Monday, September 7, 1:48:54 PM

Monday, September 7, 1:48:54 PM

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

Monday, September 7, 1:48:54 PM

Spiral Model Strengths

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

Spiral Model Weaknesses

Monday, September 7, 1:48:54 PM

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 to use Spiral Model


Monday, September 7, 1:48:54 PM

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

Monday, September 7, 1:48:54 PM

The spiral model is used most often

in large projects.

Advantages

Monday, September 7, 1:48:54 PM

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.

Monday, September 7, 1:42:43 PM

Incremental Model

Incremental Model (IM)

Monday, September 7, 1:48:54 PM

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.

The Incremental Model (IM)

Monday, September 7, 1:48:54 PM

Monday, September 7, 1:48:54 PM

Incremental Model (IM)

Monday, September 7, 1:48:54 PM

Construct a partial implementation of a total system

Then slowly add increased functionality The incremental model prioritizes requirements of the system and then

implements them in groups.

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

Monday, September 7, 1:48:54 PM

Incremental Model Strengths

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

Monday, September 7, 1:48:54 PM

Incremental Model Weaknesses


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

Monday, September 7, 1:48:54 PM

When to use the Incremental Model

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

Monday, September 7, 1:48:54 PM

The End

Вам также может понравиться