Using UML, Patterns, and Java Object-Oriented Software

Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 15, Software Life Cycle

Lecture Road Map Software Development as Application Domain Modeling the software lifecycle IEEE Standard 1074 for Software Lifecycles Modeling the software life cycle Sequential models Pure waterfall model V-model Iterative models Boehm’s spiral model Unified Process (in the next lecture) Entity-oriented models Issue-based model Capability Maturity Model Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

Inherent Problems with Software Development Requirements are constantly changing The client might not know all the requirements in advance 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”) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3

Software Life Cycle The term “Lifecycle” is based on the metaphor of the life of a person: Conception PreDevelopment Bernd Bruegge & Allen H. Dutoit Childhood Adulthood Development Development Object-Oriented Software Engineering: Using UML, Patterns, and Java Retirement PostDevelopment 4

Typical Software Life Cycle Questions Which activities should we select for the software project? What are the dependencies between activities? How should we schedule the activities? To find these activities and dependencies we can use the same modeling techniques we use for software development: Functional Modeling of a Software Lifecycle Scenarios Use case model Structural modeling of a Software Lifecycle Object identification Class diagrams Dynamic Modeling of a Software Lifecycle Sequence diagrams, statechart and activity diagrams Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5

Identifying Software Development Activities Questions to ask: What is the problem? What is the solution? What are the best mechanisms to 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? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6

Software Development Activities (Example 1) Requirements Analysis What is the problem? System Design What is the solution? Detailed Design What are the best mechanisms to implement the solution? Application Application Domain Domain Program Implementation How is the solution constructed? Testing Is the problem solved? Delivery Can the customer use the solution? Maintenance Are enhancements needed? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java Solution Solution Domain Domain 7

Software Development Activities (Example 2) Requirements Analysis What is the problem? Application Application Domain Domain System Design What is the solution? Object Design What are the best mechanisms to implement the solution? Implementation How is the solution constructed? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java Solution Solution Domain Domain 8

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 applied across the software life cycle Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9

Functional Model of a simple life cycle model Software development include include include Problem definition Client System development Project manager Bernd Bruegge & Allen H. Dutoit Developer System operation Administrator Object-Oriented Software Engineering: Using UML, Patterns, and Java End user 10

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 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11

Another simple Life Cycle Model System development activity System upgrade activity Market creation activity System Development and Market creation can be done in parallel. They must be done before the system upgrade activity Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12

Two Major Views of the Software Life Cycle Activity-oriented view of a software life cycle Software development consists of a set of development activities all the examples so far Entity-oriented view of a software life cycle Software development consists of the creation of a set of deliverables. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13

Entity-centered view of Software Development Software Development Lessons learned document Market survey document System specification document Executable system Software development consists of the creation of a set of deliverables Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14

Combining Activities and Entities in One View Activity Work product consumes Problem definition activity System development activity produces consumes Market survey document Specification document produces System operation activity consumes produces Bernd Bruegge & Allen H. Dutoit Executable system Lessons learned document Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

IEEE Std 1074: Standard for Software Process Group Life Cycle Activities IEEE IEEEStd Std1074 1074 Project Project Management Management PrePreDevelopment Development Project Initiation Project Monitoring &Control Software Quality Management Concept Exploration System Allocation DevelopDevelopment ment PostPostDevelopment Development Requirements Design Implementation CrossCrossDevelopment Development (Integral (IntegralProcesses) Processes) Installation Operation & Support Maintenance Retirement V&V Configuration Management Documentation Training Process Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16

Processes, 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 Development Development Process Process Design Design Activity Activity Design Design Database Database Task Task Bernd Bruegge & Allen H. Dutoit Make Makeaa Purchase Purchase Recommendation Recommendation Object-Oriented Software Engineering: Using UML, Patterns, and Java 17

Object Model of the IEEE 1074 Standard Software Life Cycle Money * Process Group Time Participant * Process * * Work Unit consumed by * Activity Bernd Bruegge & Allen H. Dutoit Resource Task * produces Object-Oriented Software Engineering: Using UML, Patterns, and Java Work Product 18

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 CMM: Capability Maturity Model (SEI,Humphrey) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19

CMM levels 1. Initial Level also called ad hoc or chaotic 2. Repeatable Level Process depends on individuals ("champions") 3. Defined Level Process is institutionalized (sanctioned by management) 4. Managed Level Activities are measured and provide feedback for resource allocation (process itself does not change) 5. Optimizing Level Process allows feedback of information to change process itself Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20

What does Process Maturity Measure? The real indicator of process maturity is the level of predictability of project performance (quality, cost, schedule). Level 1: Random, unpredictable performance Level 2: Repeatable performance from project to project Level 3: Better performance on each successive project Level 4: Substantial improvement (order of magnitude) in one dimension of project performance Level 5: Substantial improvements across all dimensions of project performance. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21

Key Process Areas To achieve a specific level of maturity, the organization must demonstrate that it addresses all the key process areas defined for that level. There are no key process areas for Level 1 KPA Level 2: Basic software project management practice KPA Level 3: Infrastructure for single software life cycle model KPA Level 4: Quantitative understanding of process and deliverables KPA Level 5: Keep track of technology and process changes Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22

Pros and Cons of Process Maturity Benefits: Increased control of projects Predictability of project cost and schedule Objective evaluations of changes in techniques, tools and methodologies Predictability of the effect of a change on project cost or schedule Problems: Need to watch a lot (“Big brother“, „big sister“) Overhead to capture, store and analyse the required information Agile Methodologies Deemphasize the importance of process maturity Lecture on Methodologies Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23

Lecture Road Map Software Development as Application Domain Modeling the software lifecycle IEEE Standard 1074 for Software Lifecycles Modeling the software life cycle Sequential models Pure waterfall model V-model Iterative models Boehm’s spiral model (Unified Process in the next lecture) Entity-oriented models Issue-based model Capability Maturity Model Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24

The Waterfall Model of the Software Life Cycle Concept Exploration Process System Allocation Process Requirements Process Design Process Implementation Process Verification & Validation Process adapted from [Royce 1970] Installation Process Operation & Support Process Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25

Example of a waterfall model : DOD Standard 2167A Software development activities: System Requirements Analysis/Design Software Requirements Analysis Preliminary Design and Detailed Design Coding and CSU testing CSC Integration and Testing CSCI Testing System integration and Testing Required by the U.S. Department of Defense for all software contractors in the 1980-90’s. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26

Activity Diagram of MIL DOD-STD-2167A System Requirements Analysis Preliminary Design System Requirements Review Preliminary Design Review System Design Detailed Design System Design Review Critical Design Review (CDR) Software Requirements Analysis Software Specification Review Bernd Bruegge & Allen H. Dutoit CSC Integration & Testing Coding & CSU Testing Object-Oriented Software Engineering: Using UML, Patterns, and Java 27

From the Waterfall Model to the V Model Acceptance Requireme nts Engineerin g Requireme System Testing nts Analysis Integration Testing System Design Object Design Unit Testing Implementation Unit Testing Integration Testing System Testing Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28

Activity Diagram of the V Model System Requirements Analysis Operation Is validated by precedes Software Requirements Elicitation Client Acceptance System Integration & Test Requirements Analysis Component Integration & Test Preliminary Design Detailed Design Unit Test Problem with the V-Model: Developers Perception Implementation Bernd Bruegge & Allen H. Dutoit User Perception 29 Object-Oriented Software Engineering: Using UML, Patterns, and Java

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, 20% tested However, software development is non-linear While a design is being developed, problems with requirements are identified While a program is being coded, design and requirement problems are found While a program is tested, coding errors, design errors and requirement errors are found. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30

The Alternative: Allow Iteration http://en.wikipedia.org/wiki/File:Escher Waterfall.jpg Note: The image is copyrighted Escher was the first:-) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31

Construction of Escher’s Waterfall Model http://www.cs.technion.ac.il/ gershon/EscherForReal/ EscherWaterfall2Penrose.gif Note: The image is copyrighted Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32

Spiral Model The spiral model proposed by Boehm has the following set of 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 If a risk has successfully been resolved, evaluate the results of the round and plan the next round If a certain risk cannot be resolved, terminate the project immediately This set of activities is applied to a couple of so-called rounds. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33

Rounds in Boehm’s Spiral Model Concept of Operations For each round go through Software these activities: Define objectives, Requirements alternatives, constraints Software Product Evaluate alternatives, Design identify and resolve risks Detailed Design Develop and verify a Code prototype Unit Test Plan the next round. Integration and Test Acceptance Test Implementation Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34

Diagram of Boehm’s Spiral Model Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35

Round 1, Concept of Operations, Quadrant IV: Determine Objectives,Alternatives & Constraints Project Project Start Start Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36

Round 1, Concept of Operations, Quadrant I: Evaluate Alternatives, identify & resolve Risks Risk RiskAnalysis Analysis Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37

Round 1, Concept of Operations, Quadrant II: Develop and Verify Concept Conceptof ofOperation Operation Activity Activity Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38

Round 1, Concept of Operations, Quadrant III: Prepare for Next Activity Requirements Requirementsand and Life Lifecycle cyclePlanning Planning Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39

Round 2, Software Requirements, Quadrant IV: Determine Objectives,Alternatives & Constraints Start of Round 2 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40

Comparison of Projects Determine objectives, alternatives, & constraints Evaluate alternatives, identify & resolve risks Risk analysis Risk analysis Project P1 Risk analysis P1 Prototype3 Prototype2 Prototype1 Requirements plan Concept of operation Software Requirements Development Requirements plan validation Plan next phase Integration Design plan validation System Product Design P2 Detailed Design Code Unit Test Integration & Test Develop & verify next level product Acceptance Test Project P2 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41

Limitations of Waterfall and Spiral Models Neither of these models deal well with frequent change The Waterfall model assumes 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, but does not allow change within a phase What do you do if change is happening more frequently? “The only constant is the change” Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42

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.I1:Open SD.I1:Closed SD.I3:Closed I2:Closed I3:Closed Planning Bernd Bruegge & Allen H. Dutoit A.I2:Open Requirements Analysis SD.I2:Closed System Design Object-Oriented Software Engineering: Using UML, Patterns, and Java 43

Waterfall Model: Analysis Phase I1:Open A.I1:Open I2:Open I3:Open A.I2:Open SD.I1:Open Analysis Analysis SD.I3:Open SD.I2:Open Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44

Waterfall Model: Design Phase I1:Closed A.I1:Open I2:Closed I3:Open A.I2:Open SD.I1:Open Analysis Analysis SD.I3:Open SD.I2:Open Design Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45

Waterfall Model: Implementation Phase I1:Closed A.I1:Closed I2:Closed I3:Closed A.I2:Closed SD.I1:Open Analysis SD.I3:Open SD.I2:Open Design Implementation Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46

Waterfall Model: Project is Done I1:Closed A.I1:Closed I2:Closed I3:Closed A.I2:Closed SD.I1:Open Analysis SD.I3:Open SD.I2:Open Design Implementation Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47

Issue-Based Model: Analysis Phase I1:Open D.I1:Open I2:Open I3:Open Imp.I1:Open Analysis:80% Design: 10% Implementation: 10% Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48

Issue-Based Model: Design Phase I1:Closed SD.I1:Open I2:Closed I3:Open SD.I2:Open Imp.I1:Open Imp.I3:Open Analysis:40% Imp.I2:Open Design: 60% Implementation: 0% Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49

Issue-Based Model: Implementation Phase I1:Open A.I1:Open I2:Closed I3:Closed A.I2:Closed SD.I1:Open SD.I3:Open Analysis:10% SD.I2:Closed Design: 10% Implementation: 60% Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50

Issue-Based Model: Prototype is Done I1:Closed A.I1:Closed I2:Closed I3: Pending A.I2:Closed SD.I1:Open SD.I3:Closed SD.I2: Unresolved Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51

Frequency of Change and Choice of Software Lifecycle Model PT Project Time, MTBC Mean Time Between Change Change rarely occurs (MTBC » PT) Linear Model (Waterfall, V-Model) Open issues are closed before moving to next phase Change occurs sometimes (MTBC PT) Iterative model (Spiral Model, Unified Process) Change occurring during phase may lead to iteration of a previous phase or cancellation of the project Change is frequent (MTBC « PT) Issue-based Model (Concurrent Development, Scrum) Phases are never finished, they all run in parallel. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52

Summary Software life cycle models Sequential models Pure waterfall model and V-model Sawtooth model Iterative model Boehm’s spiral model Rounds Comparison of projects Prototyping Revolutionary and evolutionary prototyping Time-boxed prototyping instead of rapid prototyping Entity-oriented models Issue-based model Sequential models can be modeled as special cases of the issue-based model. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53

Additional and Backup Slides Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 54

Questions Boehm‘s spiral model is usually shown in a polar coordinate system. Why did Boehm use such a notation? What are the problems with such a notation? What happens if you attempt to remodel the spiral model in UML? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 55

Industry Distribution across Maturity Levels (State of the Software Industry in 1995) Maturity Level 1 2 3 4 5 Frequency Initial 70% Repeatable 15% Defined 10% Managed 5% Optimizing 1% Source: Royce, Project Management, page 364 Citation needs to be updated Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 56

Movie of Escher’s Waterfall Model Escher for Real http://www.cs.technion.ac.il/ gershon/EscherForRealWaterfallFull.avi (C) Copyright 2002-5 Gershon Elber,Computer Science Department, Technion Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 57

OOSE-Book: Development activities and their products problem statement Requirements elicitation nonfunctional requirements functional model use case diagram Analysis class diagram System design Bernd Bruegge & Allen H. Dutoit statechart diagram object model dynamic model Object-Oriented Software Engineering: Using UML, Patterns, and Java sequence diagram 58

OOSE- Development activities (cont’d) System design subsystem decomposition design goals Object design object design model class diagram source code Testing Bernd Bruegge & Allen H. Dutoit Implemen-tation deliverable system Object-Oriented Software Engineering: Using UML, Patterns, and Java 59

Insert: Types of Prototypes Illustrative Prototype Develop the user interface with a set of storyboards Implement them on a napkin or with a user interface builder (Visual C , .) 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 ("Hack") Implement part of the system to learn more about the requirements. Good for paradigm breaks Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 60

Types of Prototyping Revolutionary Prototyping Also called specification prototyping Get user experience with a throwaway version to get the requirements right, then build the whole system Advantage: Can be developed in a short amount of time. Disadvantage: Users may have to accept that features in the prototype are expensive to implement 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 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 61

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. It is a particular way to control a project Prototyping can go on forever if it is not restricted “Time-boxed” prototyping limits the duration of the prototype development Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 62

References Readings used for this lecture [Bruegge-Dutoit] Chapter 12 [Humphrey 1989] Watts Humphrey, Managing the Software Process, SEI Series in Software Engineering, Addison Wesley, ISBN 0-201-18095-2 Additional References [Royce 1970] Winston Royce, Managing the Development of Large Software Systems, Proceedings of the IEEE WESCON, August 1970, pp. 1-9 SEI Maturity Questionaire, Appendix E.3 in [Royce 1998], Walker Royce, Software Project Management, Addison-Wesley, ISBN0-201-30958-0 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 63

Additional References Overview of Capability Maturity Models http://www.sei.cmu.edu/cmm/cmms/cmms.html Personal Process http://www.sei.cmu.edu/tsp/psp.html Team Process: http://www.sei.cmu.edu/tsp/tsp.html Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 64

Summary Software life cycle The development process is broken into individual pieces called software development activities Software development standards IEEE 1074 The standard allows the lifecycle to be tailored Capability Maturity Model An attempt to characterize the maturity of a software development organization following a software lifecycle model. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 65

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 Similar projects may vary widely in productivity "when we did it last year we got it done" Bernd Bruegge & Allen H. Dutoit Level 1 Metrics: Rate of Productivity (Baseline comparisons, Collection of data is difficult) Product size (LOC, number of functions, etc) Staff effort (“Man-years”, person-months) Recommendation: Level 1 managers & developers should not concentrate on metrics and their meanings, They should first attempt to adopt a process model (waterfall, spiral model, saw-tooth, macro/micro process lifecycle, unified process) Object-Oriented Software Engineering: Using UML, Patterns, and Java 66

Maturity Level 2: Repeatable Process Inputs and outputs are defined Input: Problem statement or requirements specification Output: Source code 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 Level 2 Metrics: Software size: Lines of code, Function points, classes or method counts Personnel efforts: person-months Technical expertise Experience with application domain Design experience Tools & Method experience Employee turnover within project "Champion" Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 67

Example: LOC (Lines of Code) Metrics Basic Course Adv. Course 40000 35000 Numbers do not include: reused code classes from class libraries 600 3000 500 2500 25000 400 2000 20000 300 1500 200 1000 100 500 0 0 30000 15000 10000 5000 0 F'89 F'91 F'92 S'91 S'92 S'93 Lines of Code Bernd Bruegge & Allen H. Dutoit F'89 F'91 F'92 S'91 S'92 S'93 # of Classes F'89 F'91 F'92 S'91 S'92 S'93 Lines of Code/Student Object-Oriented Software Engineering: Using UML, Patterns, and Java 68

Maturity Level 3: Defined Process Activities of software development process are well defined with clear entry and exit conditions. 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, methods, interfaces Design complexity: Number of subsystems, concurrency, platforms Bernd Bruegge & Allen H. Dutoit Implementation complexity: Number of code modules, code complexity Testing complexity: Number of paths to test, number of class interfaces to test Thoroughness of Testing: Requirements defects discovered Design defects discovered Code defects discovered Failure density per unit (subsystem, code module, class Object-Oriented Software Engineering: Using UML, Patterns, and Java 69

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) Bernd Bruegge & Allen H. Dutoit Defect identification: How and when (which review) are defects discovered? Defect density: When is testing complete? Configuration management: Is it used during the development process? (Has impact on tracability of changes). Module completion time: Rate at which modules are completed (Slow rate indicates that the process needs to be improved). Object-Oriented Software Engineering: Using UML, Patterns, and Java 70

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 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 71

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: 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? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 72

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, subsystem tests need to be done? Documentation complexity: Number of documents & pages Quality of testing: Can defects be discovered during analysis, design, implementation? How is it determined that testing is complete? What was the failure density? (Failures discovered per unit size) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 73

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? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 74

Key Process Areas for Level 2 (Repeatable Process) Requirements Management: Requirements are baselined in a project agreement and maintained during the project Project Planning and Tracking: A software project management plan is established at the beginning of the project and is tracked during the project. Subcontractor Management: The organization selects and effectively manages qualified software subcontractors. Quality Assurance Management: All deliverables and process activities are reviewed and audited against standards and guidelines adopted by the organization. Configuration Management: Controlled items are defined and maintained throughout the entire project. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 75

Key Process Areas for Level 3 (Defined Process) Organization process: Permanent team maintains software life cycle. A standard software life cycle model is used for all projects. Training program: The organization identifies training needs and develops training programs. Integrated Software management: Each project can tailor their specific process from the standard process. Software product engineering: Software is built according to the software life cycle, methods and tools. Inter-group coordination: The project teams interact with other teams to address requirements and issues. Peer reviews: Deliverables are reviewed on a peer level to identify defects and areas where changes are needed. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 76

Key Process Areas for Level 4 (Managed Process) Quantitative process management: Productivity and quality metrics are defined and constantly measured across the project. These data are not immediately used during the project, but are stored in a database to allow for comparison with other projects. Quality management: The organization has defined a set of quality goals for software products. It monitors and adjusts the goals and products to deliver high-quality products to the user. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 77

Key Process Areas for Level 5 (Optimized Process Defect prevention: Failures in past projects are analyzed, using data from the metrics database. Technology change management: Technology enablers and innovations are constantly investigated. Process change management: The software process is constantly changed to deal with problems identified by the software process metrics. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 78

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