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