Professional Documents
Culture Documents
1 2
3 4
5 6
1
Stagewise & Waterfall Stagewise
• Born out of the shortsightedness of the • A development process of successive
Code & Fix model. phases.
– need for a design phase, requirements phase, – Phases included operational plan, operational
and a testing phase. specs, coding specs, coding, parameter
• First used to develop SAGE (Semi- testing, assembly testing, shakedown, system
evaluation.
Automated Ground Environment), an early
warning system for the Cold War era. • Underwent two refinements in 1970.
• Now referred to as the Waterfall Model.
7 8
11 12
2
Transform Model Transform Model
• The solution to the Evolutionary Model. • Difficulties arose, as in the other models.
• The Transform Model contains: • The automatic transformation isn’t so
– A formal specification. easy.
– Automatic transformation of the specifications
into code. • Unplanned paths still can cause a problem
(i.e. the Evolutionary Model’s bad assumption).
– An iterative loop (for improved performance).
– An outer iterative loop (for adjustments). • A knowledge-base-maintenance problem
• Modifications are made to the would result. Problem of choosing the
specifications. best option at each transformation point.
13 14
3
Cycle Requirements Cycle Requirements
• If alternatives or uncertainties are found • Each cycle is completed by a review by
they must be resolved.
the people concerned with the project.
• Risk-driven “subsetting” allows a mixture of
other software process models, as • Plans for the next cycle should be
necessary, until a high-risk situation is introduced.
resolved.
– Specification-oriented (Transform or Stagewise) • With each succeeding level in the spiral
– Prototype-oriented (Waterfall) the level of detail increases.
– Automatic-transformation oriented (Transform)
– Simulation-oriented (Evolutionary)
19 20
4
Round 2 More Rounds??
• Round 2: Top-level requirements spec. – More detail yet.
– Man-months: 1 year, 15 people
– Objectives: User-friendly system; integrated tools; • Succeeding rounds may be necessary.
project and personnel support.
– Constraints: Customer-deliverable SDE, reliability. • Depends on the amount of risk.
– Alternatives: Change in OS, host target, workstations.
– Risks: Mismatch needs and priorities, user-unfriendly
– Ex. The risk alleviation of the RTT preliminary
system, Unix performance, workstation design specification.
compatibility. (Mini-spiral spawned)
– Risk resolution: Survey of Unix-using organizations;
workstation study.
• More attractive alternatives may be found.
– Risk resolution results: Use Unix based interfaces; use tools to – Ex. The change in UDF tool requirements.
support early phases.
– Plan for next phase: Tools: SREM, RTT,PDL; front end: support
tools; LAN: equipment, facilities.
– Commitment: Proceed with plans.
(>>Features)
25 26
27 28
5
Advantages Disadvantages
9It balances resource expenditure. Spiral model not yet complete (in 1988).
Matching to contract software
9Doesn’t involve separate approaches for
– Internal projects have more freedom.
software development and software – Contract software demands total control and a full
maintenance. picture of the deliverables in advance.
31 32
6
Six Spiral Essential The Spiral Model Today
• Six essential attributes which every spiral
development process must incorporate.
• A more complete Spiral Model
– Ability of the Spiral Model to work on external
projects (stakeholder review).
– A more elaborated method in proceeding
through the spiral.
• Use of milestones and the six “essentials”.
• The awareness of “hazardous spiral look-alikes”,
as well as possible invariants in the model.
• Spiral Model sources:
http://www.stsc.hill.af.mil/crosstalk/2001/05/boehm.html
37 38
Discussion
• Since the Spiral Model is based on the
human ability to assess risk, is the model
prone to human errors?
• Is this model just a combination of all of
the other software process models?
• Can we get lost in the spiral, i.e. endless
levels, gigantic breakaway spirals?
39