Otfligriil

Qperaliünal\ Prc-olvpcng "■-...^PnotGîyping \

Risk Analysis fti*

Design \ -. Assessment\ PrOiôlyi.feiiy

SmulDijons.J Models-.

Dptrjl '^i J SoJlV/dfe SifsBéfiï / Rkjuifg' ) Sbüwiri -iWilS Súee / Síwc.^ Updated/

Syíton / ScHw^e Solfea sX'L^&y.jty Spnc grxj /

Inlegrat^Ji and Tesl,

IOC DELIVERV

Tosr«ng

User

Accepta nco

Test ilrtd Tra nmo _.

DETERMINE OBJECTIVES,

EVALUATE ALTERNATIVES.

IDENTIFY APíD RESOLVE ¡RISKS

ALTERNATIVES, AND

CONSTRAINTS

DELVERY

FCA/PCA

PLAN NLK" PHASE

DEVELOP MLKT-LEVEL PHCUUCr

To read the spiral model shown in Figure 4-14, start in the center in Quadrant 1 (determine objectives, alternatives, and constraints), explore risks, make a plan to handle risks, commit to the approach for the next iteration, and move to the right.

For each iteration, determine objectives, alternatives, and constraints; identify and resolve risks; evaluate alternatives; develop the deliverables for that iteration and verify that they are correct; plan the next iteration; and commit to an approach for the next iteration, if you decide to have one.

There is no set number of loops through the four quadrants—as many should be taken as are appropriate, and iterations may be tailored for a specific project.

A salient factor is that coding is de-emphasized for a much longer period than with other models. The idea is to minimize risk through successive refinements of user requirements. Each "mini-project" (travel around the spiral) addresses one or more major risks, beginning with the highest. Typical risks include poorly understood requirements, poorly understood architecture, potential performance problems, problems in the underlying technology, and so on. Chapter 18, "Determining Project Risks," will describe the most common software project risks and techniques for their mitigation. The first build, the initial operational capability (IOC), is the customer's first chance to "test-drive" the system, after which another set of planning activities takes place to kick off the next iteration. It is also important to note that the model does not dispense with traditional structured methods—they appear at the end (outside loop) of the spiral. Design through user acceptance testing appears before final operational capability (FOC), just as they do in the waterfall model.

When using a prototyping approach, there may be a tendency for developers to dismiss good system development practices and misuse the model as an excuse for "quick-and-dirty" development. Proper use of the spiral model or one of its simpler variants will help prevent "hacking" and instill discipline. As seen in Figure 4-14, after much analysis and risk assessment, the "tail" of the spiral shows a set of waterfall-like disciplined process phases.

Addressed more thoroughly than with other strategies, the spiral method emphasizes the evaluation of alternatives and risk assessment. A review at the end of each phase ensures commitment to the next phase, or, if necessary, identifies the need to rework a phase. The advantages of the spiral model are its emphasis on procedures, such as risk analysis, and its adaptability to different life cycle approaches. If the spiral method is employed with demonstrations, baselining, and configuration management, you can get continuous user buy-in and a disciplined process.'-^

Strengths of the Spiral Model

When applied to a project for which it is well suited, strengths of the spiral model include the following:

• The spiral model allows users to see the system early, through the use of rapid prototyping in the development life cycle.

• It provides early indications of insurmountable risks, without much cost.

• It allows users to be closely tied to all planning, risk analysis, development, and evaluation activities.

• It splits a potentially large development effort into small chunks in which critical, high-risk functions are implemented first, allowing the continuation of the project to be optional. In this way, expenses are lessened if the project must be abandoned.

• The model allows for flexible design by embracing the strengths of the waterfall model while allowing for iteration throughout the phases of that model.

• It takes advantage of the strengths of the incremental model, with incremental releases, schedule reduction through phased overlap of releases, and resources held constant as the system gradually grows.

• It does not rely on the impossible task of getting the design perfect.

• It provides early and frequent feedback from users to developers, ensuring a correct product with high quality.

• Management control of quality, correctness, cost, schedule, and staffing is improved though reviews at the conclusion of each iteration.

• It provides productivity improvement through reuse capabilities.

• It enhances predictability through clarification of objectives.

• All the money needed for the project need not be allocated up-front when the spiral model is adopted.

* Cumulative costs may be assessed frequently, and a decrease in risk is associated with the cost.

Weaknesses of the Spiral Model

When applied to a project for which it isnofwell suited, weaknesses of the spiral model include the following:

• If the project is low-risk or small, this model can be an expensive one. The time spent evaluating the risk after each spiral is costly. ® The model is complex, and developers, managers, and customers may find it too complicated to use.

• Considerable risk assessment expertise is required.

• The spiral may continue indefinitely, generated by each of the customer's responses to the build initiating a new cycle; closure (convergence on a solution) may be difficult to achieve.

• The large number of intermediate stages can create additional internal and external documentation to process.

• Use of the model may be expensive and even unaffordable—time spent planning, resetting objectives, doing risk analysis, and prototyping may be excessive.

• Developers must be reassigned during nondevelopment-phase activities.

• It can be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration.

• The lack of a good prototyping tool or technique can make this model clumsy to use.

• The industry has not had as much experience with the spiral model as it has with others.

Some users of this technique have found the original spiral model to be complex and have created a simplified version, shown in Figure 4-15.

Figure 4-15. A Simplified View of the Spiral Model

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment