TUM

Software Life Cycles
Prof. Bernd Brügge, Ph.D Technische Universität München Institut für Informatik Lehrstuhl für Angewandte Softwaretechnik http://wwwbruegge.in.tum.de 14 May 2002

Copyright 2002 Bernd Brügge

Software Engineering II, Lecture 3: Scheduling SS 2002

1

Archeology of TRAMP
❖ ❖ ❖ ❖ ❖

Christian Sandor No SPMP Tailorize the process Slack time (3 days) Deadline: Friday 5pm. E-mail the solution in PDF

Copyright 2002 Bernd Brügge

Software Engineering II, Lecture 3: Scheduling SS 2002

2

Miscellaneous: Project Management Workshop
❖ ❖ ❖ ❖ ❖ ❖

What? Project Management Case study of an industrial project
Planning of a purchase order system

Where? Accenture, Maximillianstr. 35 (S-Bahn near Isartor) When? July 2, 2002 How long? 9:00 - 16:00 (Lunch will be provided) # of participants: ~30 If interested sign up for it today
Signup Sheet: Provide Name and e-mail E-mail your resume to bruegge@in.tum.de N Accenture Workshop (Filter)

Copyright 2002 Bernd Brügge

Software Engineering II, Lecture 3: Scheduling SS 2002

3

Lecture 3: Scheduling SS 2002 4 . 9:00 .Signup Sheet for Project Management Workshop (July 2.16:00) Name Copyright 2002 Bernd Brügge E-Mail Address Software Engineering II. 2002.

Lecture 3: Scheduling SS 2002 5 .Miscellaneous: Return of Homeworks ❖ ❖ Graded homework I available Pickup starting tomorrow in H-1205 between 9:30 and 13:00 (Frau Hiller) Copyright 2002 Bernd Brügge Software Engineering II.

Inherent Problems with Software Development ❖ Requirements are constantly changing The client might not know all the requirements in advance Technology enablers offer new possibilities ❖ ❖ Frequent changes are difficult to manage Identifying checkpoints for planning and cost estimation is difficult There is more than one software system New system must often be backward compatible with existing system (“legacy system”) Phased development: The organization distinguishes between a system under development and the already released systems ❖ ❖ Let’s view these problems as the nonfunctional requirements for a system that supports software development! (CASE = Computer Aided Software Engeering) This leads us to software life cycle modeling Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 6 .

Lecture 3: Scheduling SS 2002 7 .Outline of Today’s Lecture ✔ ❖ ❖ ❖ Problems of Software Development Software Development as Application Domain Modeling the software lifecycle IEEE Standard for Software Lifecycles Modelling the Software Life cycle Waterfall model and its problems N Pure Waterfall Model N V-Model N Sawtooth Model Alternative process models N Boehm’s Spiral Model N Issue-based Development Model ❖ Capability Maturity Model Copyright 2002 Bernd Brügge Software Engineering II.

applied across the software life cycle Copyright 2002 Bernd Brügge Software Engineering II.Definitions ❖ Software life cycle: Set of activities and their relationships to each other to support the development of a software system ❖ Software development methodology: A collection of techniques for building models . Lecture 3: Scheduling SS 2002 8 .

Software Life Cycle ❖ Metaphor of the life of a person: Conception Childhood Childhood Adulthood Retirement PreDevelopment Development Development PostDevelopment Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 9 .

Typical Software Life Cycle Questions ❖ ❖ ❖ ❖ Which activities should I select for the software project? What are the dependencies between activities? How should I schedule the activities? For finding activities and dependencies we can use the same modeling techniques from Software Engineering I: Functional Modeling N Scenarios N Use Case Model Structural modeling: N Object identification N Class Diagrams Dynamic Modeling: N Activity Diagrams Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 10 .

Identifying Software Development Activities ❖ Questions to ask: What is the problem? What is the solution? What are the mechanisms that best implement the solution? How is the solution constructed? Is the problem solved? Can the customer use the solution? How do we deal with changes that occur during the development? Are enhancements needed? Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 11 .

Software Development Activities (Example 1) Requirements Analysis What is the problem? What is the solution? What are the mechanisms that best implement the solution? How is the solution constructed? Is the problem solved? Can the customer use the solution? Are enhancements needed? Software Engineering II. Lecture 3: Scheduling SS 2002 12 Application Application Domain Domain System Design Detailed Design Program Implementation Testing Delivery Maintenance Copyright 2002 Bernd Brügge Solution Solution Domain Domain .

Software Development Activities (Example 2) Requirements Analysis System Design Object Design What is the problem? What is the solution? What is the solution in the context of an existing system or set of components? How is the solution constructed? Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 Application Application Domain Domain Implementation Solution Solution Domain Domain 13 .

Functional Model of a simple life cycle model Software development <<include>> <<include>> <<include>> Problem definition System development System operation Client Project manager Developer Administrator End user Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 14 .

Activity diagram for the same life cycle model Problem definition activity System development activity System operation activity Software development goes through a linear progression of states called software development activities Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 15 .

Lecture 3: Scheduling SS 2002 16 .Another simple life cycle model System development activity System upgrade activity Market creation activity System Development and Market creation can be done in parallel and Must be done before the system upgrade activity Copyright 2002 Bernd Brügge Software Engineering II.

Two Major Views of the Software life cycle ❖ ❖ Activity-oriented view of a software life cycle all the examples so far Entity-oriented view of a software life cycle Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 17 .

Lecture 3: Scheduling SS 2002 18 .Entity-centered view of software development Software Development Market survey document System specification document Executable system Lessons learned document Software development consists of the creation of a set of deliverables Copyright 2002 Bernd Brügge Software Engineering II.

Combining activities and entities in one view Activity Work product consumes Problem definition activity produces consumes System development activity produces Market survey document Specification document Executable system consumes System operation activity produces Lessons learned document Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 19 .

IEEE Std 1074: Standard for Software Life Cycle Process Group IEEE Std 1074 IEEE Std 1074 CrossCrossDevelopment Development Project Project Management Management > Project Initiation >Project Monitoring &Control > Software Quality Management PrePreDevelopment Development > Concept Exploration > System Allocation DevelopDevelopment ment PostPostDevelopment Development (Integral Processes) (Integral Processes) >V&V > Configuration Management > Documentation > Training > Requirements Analysis > Design > Implementation > Installation > Operation & Support > Maintenance > Retirement Process Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 20 .

Activities and Tasks ❖ ❖ ❖ Process Group: Consists of a Set of Processes Process: Consists of Activities Activity: Consists of sub activities and tasks Process Process Group Group Process Process Development Development Design Design Design Design Database Database Make aa Make Purchase Purchase Recommendation Recommendation Software Engineering II. Lecture 3: Scheduling SS 2002 21 Activity Activity Task Task Copyright 2002 Bernd Brügge .Processes.

Lecture 3: Scheduling SS 2002 22 ... Copyright 2002 Bernd Brügge Software Engineering II..Example ❖ ❖ The Design Process is part of Development The Design Process consists of the following Activities Perform Architectural Design Design Database (If Applicable) Design Interfaces Select or Develop Algorithsm (If Applicable) Perform Detailed Design (= Object Design) ❖ The Design Database Activity has the following Tasks Review Relational Databases Review Object-Oriented Databases Make a Purchase recommendation .

Lecture 3: Scheduling SS 2002 Money 23 .UML Class Diagram of the IEEE Standard Software life cycle * Process group * Process * Phase * Work Product * Activity Task produces consumes * Resource Participant Time Copyright 2002 Bernd Brügge Software Engineering II.

Lecture 3: Scheduling SS 2002 24 .Life Cycle Modeling ❖ ❖ Many models have been proposed to deal with the problems of defining activities and associating them with each other The first model proposed was the waterfall model [Royce 1970] Copyright 2002 Bernd Brügge Software Engineering II.

Concept Exploration Process System Allocation Process Requirements Process Design Process The Waterfall Model of the Software Life Cycle Implementation Process Verification & Validation Process Installation Process Operation & Support Process Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 25 adapted from [Royce 1970] .

Lecture 3: Scheduling SS 2002 26 . can be decomposed into CSC's and CSU's) CSCI Testing (CSCI = Computer Software Configuration Item) System integration and Testing Copyright 2002 Bernd Brügge Software Engineering II.DOD Standard 2167A ❖ ❖ Required by the Department of Defense for all software contractors in the 1980-90s Waterfall-based model with the software development activities System Requirements Analysis/Design Software Requirements Analysis Preliminary Design and Detailed Design Coding and CSU testing (CSU = Computer Software Unit) CSC Integration and Testing (CSC = Computer Software Component.

Activity Diagram of MIL DOD-STD-2167A System Requirements Analysis System Requirements Review System Design System Design Review Software Requirements Analysis Software Specification Review Decision point: The next activity is initiated only if the review is successful Preliminary Design Preliminary Design Review Detailed Design Critical Design Review (CDR) Coding & CSU Testing CSC Integration & Testing Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 … 27 .

From the Waterfall Model to the V Model Requirements Engineering Requirements Analysis System Design Unit Testing Implementation Unit Testing Integration Testing System Testing 28 Integration Testing Acceptance System Testing Object Design Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 .

Lecture 3: Scheduling SS 2002 .Activity Diagram of a V Model System Requirements Analysis Is validated by Operation precedes Software Requirements Elicitation Client Acceptance Requirements Analysis System Integration & Test Preliminary Design Component Integration & Test Detailed Design Unit Test Problem with the V-Model: Implementation Developers Perception = User Perception 29 Copyright 2002 Bernd Brügge Software Engineering II.

Lecture 3: Scheduling SS 2002 30 .Sawtooth Model distinguishes between client and developers Client System Requirements Analysis Prototype Demonstration 1 Prototype Demonstration 2 Client Acceptance Developer System Integration & Test Requirements Analysis Component Integration & Test Preliminary Design Unit Test Detailed Design Implementation Copyright 2002 Bernd Brügge Software Engineering II.

Lecture 3: Scheduling SS 2002 31 . project manager and developers Client System Requirements Analysis Prototype Demo 1 Prototype Demo 2 Client Acceptance Manager Design Review System Integration & Test Requirements Analysis Developer Component Integration & Test Preliminary Design Detailed Design Unit Test Implementation Copyright 2002 Bernd Brügge Software Engineering II.The Sharktooth Model distinguishes between client.

Properties of Waterfall -based Models ❖ Managers love waterfall models: Nice milestones No need to look back (linear system) Always one activity at a time Easy to check progress during development: 90% coded. problems with requirements are identified While a program is being coded. design errors and requirement errors are found Copyright 2002 Bernd Brügge Software Engineering II. software development is nonlinear While a design is being developed. 20% tested ❖ However. coding errors. design and requirement problems are found While a program is tested. Lecture 3: Scheduling SS 2002 32 .

Lecture 3: Scheduling SS 2002 33 .The Alternative: Allow Iteration Escher was the first:-) Copyright 2002 Bernd Brügge Software Engineering II.

Spiral Model

The spiral model proposed by Boehm is an iterative model with the following activities
Determine objectives and constraints Evaluate Alternatives Identify risks Resolve risks by assigning priorities to risks Develop a series of prototypes for the identified risks starting with the highest risk. Use a waterfall model for each prototype development (“cycle”) If a risk has successfully been resolved, evaluate the results of the “cycle” and plan the next round If a certain risk cannot be resolved, terminate the project immediately

Copyright 2002 Bernd Brügge

Software Engineering II, Lecture 3: Scheduling SS 2002

34

Cycles in Boehm’s Spiral Model
❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖

Concept of Operations Software Requirements Software Product Design Detailed Design Code Unit Test Integration and Test Acceptance Test Implementation

For each cycle go through these activities
Quadrant IV: Define objectives, alternatives, constraints Quadrant I: Evaluate alternative, identify and resolve risks Quadrant II: Develop, verify prototype Quadrant III: Plan next “cycle”

The first 3 cycles are shown in a polar coordinate system.
The polar coordinates r = (l, a) of a point indicate the resource spent in the project and the type of activity

Copyright 2002 Bernd Brügge

Software Engineering II, Lecture 3: Scheduling SS 2002

35

Spiral Model
Determine objectives, alternatives, & constraints
Risk analysis Risk analysis Risk analysis P1 Prototype3 Prototype2 Prototype1 Requirements plan Concept of operation

Evaluate alternatives, identify & resolve risks

Project P1

Software Requirements

System Product Design

Development Requirements plan validation

Detailed Design

P2

Code Unit Test

Plan next phase

Integration plan

Design validation Acceptance Test

Develop & verify next level product

Integration & Test

Project P2
Copyright 2002 Bernd Brügge Software Engineering II, Lecture 3: Scheduling SS 2002 36

Lecture 3: Scheduling SS 2002 37 . Quadrant IV: Determine Objectives.Cycle 1. Alternatives and Constraints Project Project Start Start Copyright 2002 Bernd Brügge Software Engineering II.

Lecture 3: Scheduling SS 2002 38 .Cycle 1. Quadrant I: Evaluate Alternatives. Identify. resolve risks Build Build Prototype Prototype Copyright 2002 Bernd Brügge Software Engineering II.

Lecture 3: Scheduling SS 2002 39 .Cycle 1. Quadrant II: Develop & Verify Product Concept of Operation Concept of Operation Activity Activity Copyright 2002 Bernd Brügge Software Engineering II.

Cycle 1. Quadrant III: Prepare for Next Activity Requirements and Requirements and Life cycle Planning Life cycle Planning Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 40 .

Lecture 3: Scheduling SS 2002 41 . Quadrant IV: Software Requirements Activity Start of Round 2 Copyright 2002 Bernd Brügge Software Engineering II.Cycle 2.

identify & resolve risks Project P1 Software Requirements System Product Design Development Requirements plan validation Detailed Design P2 Code Unit Test Plan next phase Integration plan Design validation Acceptance Test Develop & verify next level product Integration & Test Project P3 Copyright 2002 Bernd Brügge Project P2 42 Software Engineering II. Lecture 3: Scheduling SS 2002 .Comparing two Projects Determine objectives. alternatives. & constraints Risk analysis Risk analysis Risk analysis P1 Prototype3 Prototype2 Prototype1 Requirements plan Concept of operation Evaluate alternatives.

. Good for paradigm breaks Copyright 2002 Bernd Brügge Software Engineering II..) Good for first dialog with client ❖ Functional Prototype Implement and deliver an operational system with minimum functionality Then add more functionality Order identified by risk ❖ Exploratory Prototype ("Hacking") Implement part of the system to learn more about the requirements.. Lecture 3: Scheduling SS 2002 43 ..Types of Prototypes used in the Spiral Model ❖ Illustrative Prototype Develop the user interface with a set of storyboards Implement them on a napkin or with a user interface builder (Visual C++.

Types of Prototyping ctd ❖ Revolutionary Prototyping Also called specification prototyping Get user experience with a throwaway version to get the requirements right. then build the whole system N Disadvantage: Users may have to accept that features in the prototype are expensive to implement N User may be disappointed when some of the functionality and user interface evaporates because it can not be made available in the implementation environment ❖ Evolutionary Prototyping The prototype is used as the basis for the implementation of the final system Advantage: Short time to market Disadvantage: Can be used only if target system can be constructed in prototyping language Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 44 .

Prototyping vs Rapid Development ❖ ❖ ❖ Revolutionary prototyping is sometimes called rapid prototyping Rapid Prototyping is not a good term because it confuses prototyping with rapid development Prototyping is a technical issue: It is a particular model in the life cycle process Rapid development is a management issue. Lecture 3: Scheduling SS 2002 45 . It is a particular way to control a project Prototyping can go on forever if it is not restricted N “Time-boxed” prototyping limits the duration of the prototype development Copyright 2002 Bernd Brügge Software Engineering II.

Lecture 3: Scheduling SS 2002 46 . no change is allowed ❖ What do you do if change is happening more frequently? “The only constant is the change” Copyright 2002 Bernd Brügge Software Engineering II. but once inside a phase.Limitations of Waterfall and Spiral Models ❖ Neither of these model deals well with frequent change The Waterfall model assume that once you are done with a phase. all issues covered in that phase are closed and cannot be reopened The Spiral model can deal with change between phases.

I1:Closed SD.I3:Closed I2:Closed I3:Closed A. Lecture 3: Scheduling SS 2002 System Design 47 .I2:Closed Planning Copyright 2002 Bernd Brügge Requirements Analysis Software Engineering II.I1:Open SD.I2:Open SD.An Alternative: Issue-Based Development ❖ A system is described as a collection of issues Issues are either closed or open Closed issues have a resolution Closed issues can be reopened (Iteration!) ❖ The set of closed issues is the basis of the system model I1:Open A.

they all run in parallel – Decision when to close an issue is up to management – The set of closed issues form the basis for the system to be developed Copyright 2002 Bernd Brügge Software Engineering II.Frequency Change and Software Lifeycle PT = Project Time. Lecture 3: Scheduling SS 2002 48 . MTBC = Mean Time Between Change Change rarely occurs (MTBC >> PT): N Waterfall Model N All issues in one phase are closed before proceeding to the next phase Change occurs sometimes (MTBC = PT): N Boehm’s Spiral Model N Change occuring during a phase might lead to an iteration of a previous phase or cancellation of the project “Change is constant” (MTBC << PT): N Issue-based Development (Concurrent Development Model) N Phases are never finished.

Waterfall Model: Analysis Phase I1:Open A.I2:Open SD. Lecture 3: Scheduling SS 2002 49 .I1:Open Analysis Analysis Analysis SD.I2:Open SD.I3:Open Copyright 2002 Bernd Brügge Software Engineering II.I1:Open I2:Open I3:Open A.

Waterfall Model: Design Phase I1:Closed A.I3:Open Design Design Copyright 2002 Bernd Brügge Software Engineering II.I2:Open SD.I2:Open SD.I1:Open Analysis Analysis Analysis SD. Lecture 3: Scheduling SS 2002 50 .I1:Open I2:Closed I3:Open A.

I2:Open SD. Lecture 3: Scheduling SS 2002 51 .I1:Open Analysis Analysis SD.Waterfall Model: Implementation Phase I1:Closed A.I1:Closed I2:Closed I3:Closed A.I2:Closed SD.I3:Open Design Design Implementation Implementation Copyright 2002 Bernd Brügge Software Engineering II.

I1:Closed I2:Closed I3:Closed A.Waterfall Model: Project is Done I1:Closed A.I2:Closed SD.I1:Open Analysis Analysis SD. Lecture 3: Scheduling SS 2002 52 .I3:Open Design Design Implementation Implementation Copyright 2002 Bernd Brügge Software Engineering II.I2:Open SD.

Issue-Based Model: Analysis Phase I1:Open D. Lecture 3: Scheduling SS 2002 53 .I1:Open Analysis:80% Analysis:80% Design: 10% Design: 10% ImplemenImplementation: 10% tation: 10% Copyright 2002 Bernd Brügge Software Engineering II.I1:Open I2:Open I3:Open Imp.

I3:Open Design: 60% Design: 60% ImplemenImplementation: 0% tation: 0% Copyright 2002 Bernd Brügge Software Engineering II.I1:Open I2:Closed I3:Open SD. Lecture 3: Scheduling SS 2002 54 .I2:Open Imp.Issue-Based Model: Design Phase I1:Closed SD.I1:Open Analysis:40% Analysis:40% Imp.I2:Open Imp.

I1:Open Analysis:10% Analysis:10% SD.Issue-Based Model: Implementation Phase I1:Open A.I1:Open I2:Closed I3:Closed A.I3:Open Design: 10% Design: 10% ImplemenImplementation: 60% tation: 60% Copyright 2002 Bernd Brügge Software Engineering II.I2:Closed SD. Lecture 3: Scheduling SS 2002 55 .I2:Closed SD.

I1:Closed I2:Closed I3: Pending A.I3:Closed SD.I2: Unresolved Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 56 .I2:Closed SD.Issue-Based Model: Prototype is Done I1:Closed A.I1:Open SD.

Lecture 3: Scheduling SS 2002 57 .Process Maturity ❖ A software development process is mature if the development activities are well defined and if management has some control over the quality. budget and schedule of the project ❖ Process maturity is described with a set of maturity levels and the associated measurements (metrics) to manage the process ❖ Assumption: With increasing maturity the risk of project failure decreases Copyright 2002 Bernd Brügge Software Engineering II.

Defined Level Process is institutionalized (sanctioned by management) 4. Initial Level also called ad hoc or chaotic 2. Optimizing Level Process allows feedback of information to change process itself Copyright 2002 Bernd Brügge Software Engineering II.SEI process maturity levels (Watts Humphrey) ❖ ❖ ❖ ❖ 1. Lecture 3: Scheduling SS 2002 58 . Managed Level Activities are measured and provide feedback for resource allocation (process itself does not change) ❖ 5. Repeatable Level Process depends on individuals ("champions") 3.

person-months) ❖ Similar projects may vary widely in productivity "when we did it last year we got it done" ❖ Recommendation: Level 1 managers & developers should not concentrate on metrics and their meanings. Lecture 3: Scheduling SS 2002 59 .Maturity Level 1: Chaotic Process ❖ ❖ ❖ Ad hoc approach to software development activities No problem statement or requirements specification Output is expected but nobody knows how to get there in a deterministic fashion ❖ Level 1 Metrics: Rate of Productivity (Baseline comparisons. unified process) Copyright 2002 Bernd Brügge Software Engineering II. They should first attempt to adopt a process model (waterfall. Collection of data is difficult) Product size (LOC. saw-tooth. macro/micro process lifecycle. etc) Staff effort (“Man-years”. spiral model. number of functions.

classes or method counts Personnel efforts: person-months Technical expertise N Experience with application domain N Design experience N Tools & Method experience Employee turnover within project ❖ Process itself is a black box ( activities within process are not known) No intermediate products are visible No intermediate deliverables ❖ Process is repeatable due to some individuals who know how to do it "Champion" Copyright 2002 Bernd Brügge Software Engineering II. Function points. Lecture 3: Scheduling SS 2002 60 .Maturity Level 2: Repeatable Process ❖ Inputs and outputs are defined Input: Problem statement or requirements specification Output: Source code ❖ Level 2 Metrics: Software size: Lines of code.

Course 40000 35000 30000 25000 20000 15000 10000 5000 0 F'89 F'91 F'92 S'91 S'92 S'93 600 500 400 300 200 100 0 F'89 F'91 F'92 S'91 S'92 S'93 Numbers do not include: > reused code > classes from class libraries 3000 2500 2000 1500 1000 500 0 F'89 F'91 F'92 S'91 S'92 S'93 Lines of Code Copyright 2002 Bernd Brügge # of Classes Software Engineering II.Example: LOC (Lines of Code) Metrics Basic Course Adv. Lecture 3: Scheduling SS 2002 Lines of Code/Student 61 .

concurrency. platforms Copyright 2002 Bernd Brügge Implementation complexity: Number of code modules. Lecture 3: Scheduling SS 2002 62 . Intermediate products of development are well defined and visible Level 3 Metrics (in addition to metrics from lower maturity levels): Requirements complexity: Number of classes. code module. methods. code complexity Testing complexity: Number of paths to test. class Software Engineering II. interfaces Design complexity: Number of subsystems.Maturity Level 3: Defined Process ❖ ❖ ❖ Activities of software development process are well defined with clear entry and exit conditions. number of class interfaces to test Thoroughness of Testing: N Requirements defects discovered N Design defects discovered N Code defects discovered N Failure density per unit (subsystem.

Module completion time: N Rate at which modules are completed (Slow rate indicates that the process needs to be improved).Maturity Level 4: Managed Process ❖ Uses information from early project activities to set priorities for later project activities (intra-project feedback) The feedback determines how and in what order resources are deployed ❖ ❖ Effects of changes in one activity can be tracked in the others Level 4 Metrics: Number of iterations per activity Code reuse: Amount of producer reuse (time designated for reuse for future projects?) Amount of component reuse (reuse of components from other projects and components) Defect identification: N How and when (which review) are defects discovered? Defect density: N When is testing complete? Configuration management: N Is it used during the development process? (Has impact on tracability of changes). Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 63 .

Maturity Level 5: Optimizing Process ❖ ❖ Measures from software development activities are used to change and improve the current process This change can affect both the organization and the project: The organization might change its management scheme A project may change its process model before completion Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 64 .

Lecture 3: Scheduling SS 2002 66 . unpredictable performance Level 2: Repeatable performance from project to project Level 3: Better performance on each successive project Level 4: project performance improves on each subsequent project either N Substantially (order of magnitude) in one dimension of project performance N Significant in each dimension of project performance Level 5: Substantial improvements across all dimensions of project performance. Copyright 2002 Bernd Brügge Software Engineering II. cost. Level 1: Random.What does Process Maturity Measure? ❖ The real indicator of process maturity is the level of predictability of project performance (quality. schedule).

Determining the Maturity of a Project ❖ ❖ Level 1 questions: Has a process model been adopted for the Project? Level 2 questions: Software size: How big is the system? Personnel effort: How many person-months have been invested? Technical expertise of the personnel: N N N N What is the application domain experience What is their design experience Do they use tools? Do they have experience with a design method? What is the employee turnover? Copyright 2002 Bernd Brügge Software Engineering II. Lecture 3: Scheduling SS 2002 67 .

subsystem tests need to be done? Documentation complexity: Number of documents & pages Quality of testing: Can defects be discovered during analysis. design. Lecture 3: Scheduling SS 2002 68 .Maturity Level 3 Questions ❖ ❖ ❖ What are the software development activities? Requirements complexity: How many requirements are in the requirements specification? Design complexity: Does the project use a software architecture? How many subsystems are defined? Are the subsystems tightly coupled? ❖ ❖ ❖ ❖ Code complexity: How many classes are identified? Test complexity: How many unit tests. implementation? How is it determined that testing is complete? What was the failure density? (Failures discovered per unit size) Copyright 2002 Bernd Brügge Software Engineering II.

Lecture 3: Scheduling SS 2002 69 .Maturity Level 4 and 5 Questions ❖ Level 4 questions: Has intra-project feedback been used? Is inter-project feedback used? Does the project have a post-mortem phase? How much code has been reused? Was the configuration management scheme followed? Were defect identification metrics used? Module completion rate: How many modules were completed in time? How many iterations were done per activity? ❖ Level 5 questions: Did we use measures obtained during development to influence our design or implementation activities? Copyright 2002 Bernd Brügge Software Engineering II.

Lecture 3: Scheduling SS 2002 70 . Assess your current process maturity level 2. tools and techniques whenever possible implement automated support for metrics collection 5. develop and populate a project data base of metrics data. Construct a project data base: Design.Steps to Take in Using Metrics Metrics are useful only when implemented in a careful sequence of process-related activities. 6. Recommend metrics. Use this database for the analysis of past projects and for prediction of future projects. Evaluate productivity and quality Make an overall assessment of project productivity and product quality based on the metrics available. 4. 1. Evaluate cost and schedule for accuracy after the project is complete. Estimate project cost and schedule and monitor actual cost and schedule during development Copyright 2002 Bernd Brügge Software Engineering II. Determine what metrics to collect 3. 7.

„big sister“) Overhead to capture.Pros and Cons of Process Maturity ❖ Problems: Need to watch a lot (“Big brother“. store and analyse the required information ❖ Benefits: Increased control of projects Predictability of project cost and schedule Objective evaluations of changes in techniques. Lecture 3: Scheduling SS 2002 71 . tools and methodologies Predictability of the effect of a change on project cost or schedule Copyright 2002 Bernd Brügge Software Engineering II.

Managing the Development of Large Software Systems. Proceedings of the IEEE WESCON. Lecture 3: Scheduling SS 2002 72 . ISBN 0-20118095-2 ❖ Additional References [Royce 1970] Winston Royce. August 1970.3 in [Royce 1998]. Appendix E. ISBN0-20130958-0 Copyright 2002 Bernd Brügge Software Engineering II.References ❖ Readings used for this lecture [Bruegge-Dutoit] Chapter 12 [Humphrey 1989] Watts Humphrey. Addison Wesley. Software Project Management. Managing the Software Process. 1-9 SEI Maturity Questionaire. pp. SEI Series in Software Engineering. Walker Royce. Addison-Wesley.

stsc.cmu.mil/crosstalk/1998/apr/dimensions.af.edu/tsp/ http://www.edu/cmm/cmms/cmms.html http://www.Additional References ❖ Capability Maturity Model http://www.stsc.sei.mil/crosstalk/1998/mar/dimensions.af.sei.cmu. Lecture 3: Scheduling SS 2002 73 .asp ❖ Team Process: http://www.hill.hill.asp ❖ Personal Process http://www.hill.cmu.asp Copyright 2002 Bernd Brügge Software Engineering II.mil/crosstalk/1998/feb/processimp.sei.edu/tsp/psp.stsc.html http://www.af.

Lecture 3: Scheduling SS 2002 74 . Due Date: June 11 ❖ Copyright 2002 Bernd Brügge Software Engineering II. Why did Boehm use such a notation? What are the problems with such a notation? Remodel the spiral model in UML.Homework 5 ❖ ❖ ❖ ❖ Boehm‘s spiral model (see slide 33) is usually shown in a polar coordinate system.

Lecture 3: Scheduling SS 2002 75 .Summary ❖ Software life cycle The development process is broken into individual pieces called software development activities ❖ No good model for modeling the process (black art) Existing models are an inexact representation of reality Nothing really convincing is available today ❖ Software development standards IEEE 1074 Standards help. but must be taken with a grain of salt The standard allows the lifecycle to be tailored ❖ Capability Maturity Model Copyright 2002 Bernd Brügge Software Engineering II.

Sign up to vote on this title
UsefulNot useful