ABHELSINKI UNIVERSITY OF TECHNOLOGY

T 76.3601 Introduction to Software Engineering Software Life-Cycle Models http://www.soberit.hut.fi/t-76.3601/ Casper.Lassenius@tkk.fi

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

Software Process?

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 software

Leavitt s Organizational Diamond Structure Structure, Culture, Management, Decision making Process Practices Procedures Instructions People Knowledge Skills, Needs, Motivation Technology Tools, Methods, Facilities, Environment Adapted from Leavitt, H.J. Applied organizational change in industry: Structural, technological and humanistic approaches. Handbook of Organizational. J.G. March. Chicago, Rand McNally. 1965

The Sandbox CMM Business Management CMM SPICE UML Process management (Quality System) Program management Project Management RUP extreme Programming Basic activities Z Testing Specification Definition Implementation Installation, Maintenance Time Boxing Object Orientation USDP Configuration Management Quality Control (V & V) Documentation Requirements management SA/SD Support activities CleanRoom

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. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Prescriptive Models These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions... These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

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? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

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. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Build and Fix Model Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

Build and Fix Model Problems No specifications No design Lack of visibility Easily leads to poorly structured systems Totally unsatisfactory Need life-cycle model Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

Waterfall Model d Object-Oriented Software Engineering, 5th ed. Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

Waterfall Model Planning and control Documentation-driven Doing the homework Formal change management d Object-Oriented Software Engineering, 5th ed. Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

The Waterfall Model

The Waterfall Model Strengths Easily manageable process (manager s favourite?) Probably the most effective model, if you know the requirements Extensive documentation

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 documentation. Safety critical systems.

Cost to Detect and Correct a Fault

Rapid Prototyping Model Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

Rapid Prototyping Model Linear Rapid Exploratory vs. throw-away prototypes Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

Incremental Model Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

Incremental Model Divide project into builds Each build adds functionality Prioritized user requirements Requirements frozen during each build! Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

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 Freeze requirements during each increment

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 their work

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

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

Synch-and-Stabilize Product vision Functional specification Development subcycle Development subcycle Development subcycle ERSITY OF TECHNOLOGY Buffer time Buffer time Buffer time Alpha release Beta release Feature complete Beta release UI freeze Code complete Final test Final debug Stabilize Final release

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

Spiral Model Radial dimension: cumulative cost to date Angular dimension: progress through the spiral

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

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, architecturecentric, 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. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Rational Unified Process (RUP)

UP Work Products Inception phase Vision document Initial use-case model Initial project glossary Initial business case Initial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Inceptio n Elaboration phase Use-case model Supplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk list Project plan including iteration plan adapted workflows milestones technical work products Preliminary user manual Construction phase Design model Software components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installation manuals description of current increment Transition phase Delivered software increment Beta test reports General user feedback These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Agile Software Development

The Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck et allii These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

What is Agility Effective (rapid and adaptive) response to change Effective communication among all stakeholders Drawing the customer onto the team Organizing a team so that it is in control of the work performed Yielding... Rapid, incremental delivery of software These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

An Agile Process Is driven by customer descriptions of what is required (scenarios) Recognizes that plans are short-lived Develops software iteratively with a heavy emphasis on construction activities Delivers multiple software increments Adapts as changes occur These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

From Waterfall to Agility Specification Design Time Implementation Test Waterfall Iterative/Incremental XP

Extreme Programming (XP) The most widely used agile process, originally proposed by Kent Beck XP Planning Begins with the creation of user stories Agile team assesses each story and assigns a cost Stories are grouped for a deliverable increment A commitment is made on the delivery date After the first increment, projct velocity is used to help define subsequent delivery dates for other increments These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Extreme Programming (XP) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Extreme Programming (XP) XP Design Follows the KIS principle Encourage the use of CRC cards (Chapter 8) Difficult solutions prototyped using spike solutions Encourages refactoring an iterative refinement of the internal program design These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Extreme Programming (XP) XP Design Follows the KIS principle Encourage the use of CRC cards (Chapter 8) Difficult solutions prototyped using spike solutions Encourages refactoring an iterative refinement of the internal program design XP Coding Recommends the construction of unit tests before coding commences Encourages pair programming These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Extreme Programming (XP) XP Design Follows the KIS principle Encourage the use of CRC cards (Chapter 8) Difficult solutions prototyped using spike solutions Encourages refactoring an iterative refinement of the internal program design XP Coding XP Testing Recommends the construction of unit tests before coding commences Encourages pair programming All unit tests are executed daily Acceptance tests are defined by the customer and executed to assess customer visible functionality These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Scrum Originally proposed by Schwaber and Beedle Distinguishing features Development work partitioned into packets Testing and documentation on-going as the product is constructed Work occurs in sprints and is derived from a backlog of existing requirements Meetings are very short and sometimes conducted without chairs (scrums) Demos are delivered to the customer within the time-box allocated These courseware materials are to be used in conjunction with Software Engineering: A Practitioner s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005.

Scrum B Casper CaspeLassenius

Challenges and Solutions for a Flexible Process Challenges Detailed design work must be started before the product architecture is fully defined Buffering need The system must be integrated before the completion of all its modules Design work partitioned The development team must be able to respond to new information even at a late stage of the project Flexibility in architecture Solutions Greater investment in architectural design Earlier feedback on a product s system level performance Development team with a grater amount of generational experience

A Flexible Process IS Iterative Based upon rapid, frequent, intense, systematic iterations, starting early in the process and involving customers NEEDS A modular and scaleable product architecture An experienced team Early customer/user involvement IS NOT Cheaper than a traditional process Fire-fighting Unmanaged ad-hoc hacking

Two Different Project Types

Two Different Project Types Functionality driven Example: a new operating system Certain functionalities must be in place They are well-known in advance The schedule is allowed to slip so that the required functionality can be developed Schedule driven Example: consecutive releases of a word processor Release deadline set and fixed Product released on schedule Final configuration of features unknown until late in the project Features must be prioritized for this to work

Two Different Project Types Functionality driven Example: a new operating system Certain functionalities must be in place They are well-known in advance The schedule is allowed to slip so that the required functionality can be developed Schedule driven Example: consecutive releases of a word processor Release deadline set and fixed Product released on schedule A one-size process does not fit all! Final configuration of features unknown until late in the project Features must be prioritized for this to work

Process Choice There is not uniformally applicable process which is applicable to any type and size of project High costs may occur if you force an inappropriate process on a development team However, one organization cannot have a vast number of different processes in use Sometimes you don t have a possibility to choose A chosen process model can be tailored to suit the project

Process Choice For large systems, management is usually the principal problem, so you need a strictly managed process For smaller systems, more informality is possible Hybrid models: Large systems are usually made up of several sub-systems The same process model need not be used for all subsystems Prototyping or agile development for high-risk specifications Waterfall model for well-understood developments

Dimensions Affecting Process Model Selection Dimensions Affecting Process Model Selection (Boehm & Turner 2003)

Plan-driven vs. Agile Neither plan-driven nor agile methods provide a silver bullet Both have home grounds where one clearly dominates the other Both agility and disciplines are critical Increasingly rapid pace of change E.g., larger projects using agile methods need plandriven process aspects to be integrated to be successful Build your method up don t tailor it down

Questions?