T–76.3601 — Introduction to Software Engineering

Software Life-Cycle Models

http://www.soberit.hut.fi/T-76.3601/

Casper Lassenius Casper.Lassenius@tkk.fi AB HELSINKI UNIVERSITY OF TECHNOLOGY Software Engineering?

1. The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software 2. The study of approaches in (1).

IEEE Computer Society

AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Software Process?

• Process • Webster: 1. A continuing development involving many changes. 2. A particular method for doing something, usually involving a number of steps or operations. • IEEE: A sequence of steps performed for a given purpose. • Software Process • CMM(I): a set of activities, methods, practices and transformations that people use to develop and maintain software and the associated products • Simply: the way an organization/team/individual develops AB software HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Leavitt’s Organizational Diamond

Structure StrStructuructure, Culture e, Management, Structure,Culture, Decision making Management, Decision making

ProcessProcess People People PracticesPractices, Knowledge, Knowledge ProcedurPresocedures, Skills, Needs,Skills, Needs, InstructionsInstructions Motivation Motivation

Technology TTools,echnology Methods, Facilities, Tools,En virMethods,onment Facilities, Environment

Adapted from Leavitt, H.J. Applied organizational change in industry: Structural, technological and ABAB humanistic approaches. Handbook of Organizational. J.G. March. Chicago, Rand McNally. 1965 HEHELSINKILSINKI UN UNIVERSITYIVERSITY OF OF TE CTECHNOLOGYHNOLOGY CasperCasper Lassenius Lassenius The Sandbox

CMM Business Management CMM

Process management (Quality System) RUP Program management SPICE Project Management eXtreme Programming UML Instal- Imple- lation, Specifi- Defi- men- Testing Basic activities cation nition Z tation Mainte- Time Boxing nance

Object Orientation Configuration Management Quality Control (V & V) Documentation SupportSA/SD activities Requirements management USDP CleanRoom

AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Process: Adaptability

• the framework activities will always be applied on every project ... BUT • the tasks and degree of rigor for each activity will vary based upon many factors, e.g.: • the type project • project characteristics • team characteristics • common sense judgement

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. AB 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005. HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Prescriptive Models • Prescriptive process models advocate an orderly approach to software engineering • That leads to a few questions... • If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? • Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. AB 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005. HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Build and Fix Model

• Problems • ProblemsProblems • • No speci!cations • No speci!cations • No• Nspecificationso design • No design • NoTotal designly unsatisfactory ••Totally unsatisfactory • Need life"cycle model ••NeedLack life of"cycle visibility model • #Game plan$ •• Easily#Game leads plan$ to poorly • Phases • structuredPhases systems • Milestones •• TotallyMilestones unsatisfactory • Problems ProblemsNeed life-cycle model •• lack of visibility •lack of visibility • easily leads to poorly structured systems •easily leads to poorly structured systems AB • Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed. ABHELSINKI UNIVERSITY OF TECHNOLOGY Picture from Schach: Classical and Object-Oriented Software Engineering,Casper 5th Lassenius ed. AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Waterfall Model • Characterized by ••ProblemsFeedback loops •• DocumentationNo speci!cations!driven •• "NDoingo design the homework" ••T•otalPlanningPlanningly unsatisfact and and ccontrolontrolory • •AdvantaN•eedDocumentation lifeges" cycle model-driven ••• #DocumentationG“Doingame plan the$ homework” ••• MPhaFormalaintsesenanc changee ea sier management • Disadvanta• Milestgesones ••ProblemsIn#exible partitioning •• Specilack of$ cationvisibility changes • expensiveeasily leads to poorly structured systems AB Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed. HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius AB Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed. AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius The Waterfall Model • Strengths • Easily manageable process (manager’s favourite?) • Probably the most effective model, if you know the requirements • Extensive documentation • Weaknesses • Inflexible partitioning of the project into distinct phases • Difficult to respond to changing customer requirements • Feedback on system performance available very late and changes can be very expensive • Applicability • Appropriate when the requirements are well understood • Short, clearly definable projects (e.g. maintenance) • Very large, complex system development that requires extensive AB documentation. Safety critical systems. HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Cost to Detect and Correct a Fault

AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Rapid Prototyping Model

• Problems • No speci!cations • No design • Linear • Totally unsatisfactory • “Rapid” • Need life"cycle model • Exploratory vs. • #Game plan$ throw-away • Phases prototypes • Milestones • Problems • lack of visibility • easily leads to poorly structured systems AB Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed. AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Incremental Model

• Problems ••NDivideo speci!cations project into • Nbuildso design Totally unsatisfactory • Each build adds N•eed life"cycle model • functionality • #Game plan$ ••PhaPrioritizedses user • Milestrequirementsones • Problems• Requirements frozen • lackduring of visibility each build! • easily leads to poorly structured systems AB Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed. AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Incremental Model • The concept of growing a system via iterations: iterative and incremental development (IID) • Divide the project into increments • Each increment adds functionality • Each iteration is a self-contained mini project composed of activities such as requirements analysis, design, programming and test • At the end of the iteration an iteration release: a stable, integrated and tested partially complete system • Most releases internal, final iteration release is the complete product • Prioritize user requirements • MOSCOW priorities: must, should, could, want • High-priority requirements into early increments AB • Freeze requirements during each increment HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Incremental Development Advantages • Customer value can be delivered at the end of each increment making system functionality available earlier • Final product better matches true customer needs • Early increments act as a prototype to help • elicit requirements for later increments • get feedback on system performance • Lower risk of overall project failure • Smaller sub-projects are easier to control and manage • A meaningful progress indicator: tested software • The highest priority features tend to receive the most testing • Job satisfaction is increased for developers who can see early results of AB their work HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Incremental Development Disadvantages

• Can be harder to plan and control than waterfall development • Can be more expensive than waterfall development • May require more experienced staff • System architecture must be adaptive to change • Software project contracts are still mostly drawn up according to the waterfall model and all changes cause renegotiations AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Synchronize-and-Stabilize Model

• Microsoft’s life-cycle model • Requirements analysis—interview potential customers • Draw up specifications • Divide project into 3 or 4 builds • Each build is carried out by small teams working in parallel

AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Synch-and-Stabilize

Product vision

Functional specification

Development Development Development subcycle subcycle subcycle

Buffer time Buffer time Buffer time Alpha release Beta release Feature complete Beta release UI freeze Code complete • Final test • Final debug • Stabilize AB Final release AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Sync-and-Stabilize

• At the end of the day—synchronize (test and debug) • At the end of the build—stabilize (freeze build) • Components always work together • Get early insights into operation of product

AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Spiral Model

Radial •• Radial dimension:dimension: cumulativecumulative cost costto date to date •AngularAngular • dimension: dimension:progress progressthrough the throughspiral the spiral AB ABHELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius The Spiral Model • A meta-model -> other models can be derived • Risk management is central • Problems • Hard to match to contract software • Not enough flexibility and freedom in contract mechanisms • Great deal of reliance on risk-assessment expertise • Applicability • Internal software development • A framework for risk-driven application of other models AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Still Other Process Models • Component based development—the process to apply when reuse is a development objective • Formal methods—emphasizes the mathematical specification of requirements • AOSD—provides a process and methodological approach for defining, specifying, designing and constructing aspects • Unified process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. AB 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005. HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius Rational Unified Process (RUP)

AB AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius UP Work Products

Inception phase

Elaboration phase Vision document Initial use-case model Construction phase Initial project glossary Use-case model Initial business case Supplementary requirements Initial risk assessment. Transition phase including non-functional Design model Project plan, Analysis model Software components phases and iterations. Software architecture Integrated software Delivered software increment Business model, Description. increment Beta test reports if necessary. Executable architectural Test plan and procedure General user feedback One or more prototypes prototype. Inceptio Test cases n Preliminary design model Support documentation Revised risk list user manuals Project plan including installation manuals iteration plan description of current adapted workflows increment milestones technical work products Preliminary user manual

These courseware materials are to be used in conjunction with Software Engineering: A These courseware materials arePractitioner’s to be used in conjunction Approach, with 6/e Software and are Engineering: provided A withPractitioner’s permission Approach. by R.S. Pressman & AB 6/e and are provided with permissionAssociates, by R.S. PressmanInc., copyright & Associates, © 1996, Inc., copyright 2001, 2005 © 1996, 2001, 2005. AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius21 Questions?

AB HELSINKI UNIVERSITY OF TECHNOLOGY