Outline The Spiral Model of Software • Introduction • Previous Models Development and • The Spiral Model Enhancement • TRW-SPS Application • Advantages and Difficulties • Risk Management Barry W. Boehm, TRW Defense • Conclusions Systems Group • Future of the Spiral Model 1988 • Discussion 1 2 A Risk-Driven Approach Software Process Model • Different idea of software development. • Used to determine the order of the stages • How does this project affect the and to establish the transition criteria. developers and the clients? – What do we do next? • How does each step in the project affect – How long shall we continue doing it? its overall development? • Provides guidance between the different • Not used in previous development models. phases of a project. – Usually code-driven or document-driven. • As opposed to a software methodology. 3 4 Previous Software Process Models Code & Fix • An evolution of models • First, elementary model – Code & Fix • Write code now; fix it later – Stagewise & Waterfall • No planning involved – Evolutionary Development • Problems: – Transform Model – Code is poorly structured. – The software developed was usually a poor match for the users’ needs. 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 Automated Ground Environment), an early evaluation. warning system for the Cold War era. • Underwent two refinements in 1970. • Now referred to as the Waterfall Model. 7 8 Waterfall Model Waterfall Model • Introduced: – Feedback loops across multiple stages: Validation and verification steps. – Prototyping via a “build it twice” step alongside of requirements and design. • Difficulties exposed even as revisions were made to the model. – Required elaborated documents. (Document-driven) – Led to pursuing stages of development in the wrong order. 9 10 Evolutionary Development Evolutionary Development • Evolution of the system in directions based • Problems: on experience. – No formal design phase (same problem as • Provides rapid initial operational capability. Code & Fix). • “I can’t tell you what I want, but I’ll know it – One bad assumption – the unplanned paths “will” be compatible. when I see it.” – Hard-to-change code resulted. • Flexible, yet uncertain approach. – Many problems when new software was incrementally replacing old software. 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 Spiral Model Spiral Model • The Risk-Driven Approach. • A different approach born out of the evolution of the Waterfall Model. • Encompasses the previous models as special cases, and can make use of a combination of models. • Risk analysis asks, “ What are the areas of uncertainty, and what is the probability that they will slow the progress of development?” 15 16 A Typical Cycle Initiating/Terminating the Process • Risk Analysis • Initiating the process •Prototype – Hypothesize that a particular operational • Design/Validation mission(s) can be improved by software effort. • Planning • Test this hypothesis throughout. • Alternatives? • Terminating • And repeat – If a spiral violates its hypothesis then the spiral is terminated. • Measure of – Otherwise it ends with the installation of a Cumulative Cost new or modified software product. and Progress 17 18 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 Overlapping Spirals Applied to TRW-SPS • Necessary for • An example of how the Spiral model works in a alternatives and large system. parallel components. • Software Productivity System (SPS) – a group of • Stop everything until integrated software development tools for use the break-away spiral within TRW, as well as for other clients. is complete??? • Spiral Model rounds • Problems? – Rounds correspond to a level in the spiral. – In this case, a Round 0 was needed to determine initial feasibility of the TRW-SPS project, but is not necessary for all projects. 21 22 TRW-SPS – Round 0 Round 1 • Round 1: Concept of Operations – More detail. • Round 0: Feasibility study -- Very Basic. – Man-months: 12 man-months, 6 people – Objectives: Double software productivity in 5 years – Man-months: 5 part-time for 2 months (2MM) – Constraints: $10,000 per person investment; – Objectives: Significantly increase software productivity. preference for TRW products (LAN). – Constraints: Costs; within context of TRW culture. – Alternatives: Change in office, communication, terminals, tools, CPU. – Alternatives: Change in management, personnel, technology, facilities. – Risks: May miss high-leverage options, LAN price/performance, workstation costs. – Risks: May be no high-leverage improvements. – Risk resolution: Extensive surveys, LAN benchmarking, workstation pricing. – Risk resolution: Surveys, cost models. – Risk resolution results: Operations concept; defer OS/tools – Risk resolution results: Some alternatives infeasible; selection. significant gains can result (double in 5 yrs). – Plan for next phase: Partition into SDE, facilities, and – Plan for next phase: 6 part-time for 6 months(12MM); management; develop prototype SDE; design more analysis; develop operations. -to-cost team: 15 people for one year. – Commitment: Fund next phase. (>>Next Round) – Commitment: Develop SDE, and use it. Form a representative steering group. (>>Next Round) 23 24 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; • More attractive alternatives may be found. workstation study. – 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 Spiral Model Features Results • Balances all of the risk elements, i.e. the • The Software Productivity System (SPS) high-risk elements must be lowered first. has grown to over 300 tools and 1.3 • Offers prototyping as a risk-reduction million instructions. option at any stage of development. • Over 25 projects have used SPS with • It allows reworks of earlier stages as more overall productivity up 50%; most projects attractive alternatives are identified. have doubled productivity. • Detail isn’t necessary until detail is • One underestimation of Unix compatibility needed. (Round 0) led to some TRW projects not using SPS. 27 28 Other Models as a Subset of the Advantages Spiral Model • Once certain risk areas are removed other 9It promotes reuse of existing software in models can replace the Spiral. early stages of development. – If project is low-risk in user-interface and performance 9Allows quality objectives to be formulated requirements, but high-risk in budget and schedule (Waterfall Model). during development. – If requirements are stable, i.e. a low-risk of design, 9Provides preparation for eventual and errors produce high-risk (Two-leg model). evolution of the software product. – If project is low-risk in budget and schedule, and high- risk in user-interface (Evolutionary Model). 9Eliminates errors and unattractive – If automated software generation is available alternatives early. (Transform Model). 29 30 5 Advantages Disadvantages 9It balances resource expenditure. Spiral model not yet complete (in 1988). 9Doesn’t involve separate approaches for Matching to contract software – Internal projects have more freedom. software development and software – Contract software demands total control and a full maintenance. picture of the deliverables in advance. 9Provides a viable framework for integrated Relying on risk-assessment expertise. hardware-software