15. Software Life Cycle

1. 15. Software Life Cycle

2. Outline • Software Life Cycle • Waterfall model and its problems • Pure Waterfall Model • V-Model • Iterative process models • Boehm’s Spiral Model

3. Inherent Problems with Software Development • Requirements are complex • The client does not know the functional requirements in advance • Requirements may be changing • Technology enablers introduce new possibilities to deal with nonfunctional requirements • Frequent changes are difficult to manage • Identifying milestones and cost estimation is difficult • There is more than one software system • New system must be backward compatible with existing system (“legacy system”) • Phased development: Need to distinguish between the system under development and already released systems • Let’s view these problems as the nonfunctional requirements for a system that supports software development! • This leads us to software life cycle modeling

4. Definitions • Software lifecycle modeling: Attempt to deal with complexity and change • Software lifecycle: • 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 lifecycle

5. Software Life Cycle • Software construction goes through a progression of states Adulthood Conception Childhood Retirement Post- Development Pre- Development Development

6. Typical Software Lifecycle Questions • Which activities should I select for the software project? • What are the dependencies between activities? • Does system design depend on analysis? Does analysis depend on design? • How should I schedule the activities? • Should analysis precede design? • Can analysis and design be done in parallel? • Should they be done iteratively?

7. Identifying Software Development Activities • For finding activities and dependencies we can use the same modeling techniques when modeling a system such as creating scenarios, use case models, object identification, drawing class diagrams, activity diagrams • 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?

8. Requirements Analysis What is the solution? System Design What are the mechanismsthat best implement the solution? Program Design How is the solutionconstructed? Program Implementation Is the problem solved? Testing Can the customer use the solution? Delivery Are enhancements needed? Maintenance Possible Identification of Software Development Activities What is the problem? Problem Domain Implementation Domain

9. Software Development as Application Domain: A Use Case Model

10. IEEE Std 1074: Standard for Software Lifecycle Process Group IEEE Std 1074 Development Pre- Development Project Management Post- Development Cross- Development (Integral Processes) > Requirements Analysis > Design > Implementation > Project Initiation >Project Monitoring &Control > Software Quality Management > V & V > Configuration Management > Documentation > Training > Installation > Operation & Support > Maintenance > Retirement > Concept Exploration > System Allocation Processes

11. Processes, Activities, and Tasks • Process Group: Consists of Set of Processes • Process: Consists of Activities • Activity: Consists of sub activities and tasks Development Process Group Process Design Activity Design Database Task Make a Purchase Recommendation

12. 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 Algorithms (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 • ....

13. 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]

14. Life-Cycle Model: Variations on a Theme • Many models have been proposed to deal with the problems of defining activities and associating them with each other • The waterfall model • First described by Royce in 1970 • There seem to be at least as many versions as there are authorities - perhaps more

15. Concept Exploration Process System Allocation Process Requirements Process Design Process Implementation Process Verification & Validation Process Installation Process Operation & Support Process The Waterfall Model of the Software Life Cycle adapted from [Royce 1970]

16. Problems with Waterfall Model • Managers love waterfall models: • Nice milestones • No need to look back (linear system), one activity at a time • Easy to check progress : 90% coded, 20% tested • V-Model • Software development is iterative • During design problems with requirements are identified • During coding, design and requirement problems are found • During testing, coding, design& requirement errors are found • => Spiral Model

17. Acceptance System Testing Integration Testing Unit Testing Unit Testing Integration Testing System Testing From the Waterfall Model to the V Model Requirements Engineering Requirements Analysis System Design Object Design Implementation

18. Activity Diagram of a V Model Is validated by precedes

19. 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 nonlinear • 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

20. Spiral Model (Boehm) Deals with Iteration • 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

21. Project P1 Project P2 Spiral Model

22. Types of Prototypes • Illustrative Prototype (Revolutionary Prototyping) • 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 (Evolutionary Prototyping) • 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.

23. 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

24. Capability maturity 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

25. 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" 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) Maturity Level 1: Chaotic Process

26. 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 "Champion" 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 Maturity Level 2: Repeatable Process

27. 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 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 Maturity Level 3: Defined Process

28. 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: 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 tractability of changes). Module completion time: Rate at which modules are completed (Slow rate indicates that the process needs to be improved). Maturity Level 4: Managed Process

29. 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

30. 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.