1. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M05 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project Module 05 Software Lifecycles and Processes

2. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 2 Goal of This Module  To examine different kinds of software lifecycles / process models –Advantages and disadvantages –How to select

3. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 3 Software Lifecycles  The software lifecycle is the top level view of the software process  The specific lifecycle chosen depends on the software to be built - its goals and requirements and its intended uses  Selection of the software lifecycle model(s) is a primary responsibility of a software manager

4. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 4 Recall that there are Many Possible Software Lifecycles within a Project Lifecycle Phase 2Phase 3Phase 4Phase nPhase 1.... c: Software Lifecycle b: Software Lifecycle d: Software Lifecycle a: Software Lifecycle

5. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 5 Tailoring the Software Lifecycle  Generally one tailors a given lifecycle model to fit the specific needs of the software  You may need several lifecycles corresponding to different kinds of software c: Software Lifecycle b: Software Lifecycle a: Software Lifecycle

6. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 6 You May Want to Construct a Matrix to Plan the Lifecycles Lifecycle # 2 Products Lifecycle # 3 Lifecycle # 4 Lifecycle # 1 Mission SW Support SW Factory Test SW Simulator X X X X

7. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 7 This Chart May Help You Decide How to Group Software Items Mission Critical SupportIncidental Life Critical Testing Deliverable Products Throwaway Part of a Deliverable Product Reused in Deliverable Products Criticality of Function AMOUNTOFUSEAMOUNTOFUSE

8. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 8 Entry Criteria for a Software Lifecycle  The Goal is defined and measurable –Throwaway or production or ??? –Purpose, requirements, etc.  The Requirements are allocated to the software –Suggestion: use a trace matrix to show what requirements are associated with what software items … continued

9. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 9 Entry Criteria for a Software Lifecycle (continued)  Intended use and end-users are clear  Applicable standards for coding, design, quality and such are clearly stated  Deliverables are clearly known

10. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 10 Ideal Requirements  Complete (every requirement is known and allocated)  Sufficient (every required feature is specified)  Consistent (no requirements contradict each other)  Unambiguous (only one possible interpretation)  Testable (you can tell when they are met)

11. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 11 Actual Requirements  Some requirements will be: –TBD (unknown - to be determined) –Wrong –Missing –Vague or unclear  Some requirements will –Contradict others –Not be testable –Change in mid- stream  Technology changes  Customer understanding of problem changes  Problem changes

12. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 12 Risk Management for Imperfect Requirements  Define a process to accept requirements changes  Assign someone to be responsible to manage requirements changes –including involvement of software staff  Select lifecycle based on level of expected requirements stability  Get ranges for TBD requirements  Work to eliminate wrong and missing requirements

13. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 13 Interface Requirements  How does your software interface to other parts of the system?  This is just as important as other requirements  Make sure the interface requirements are –Documented –Under Control –Contained in (or controlled by) a SINGLE document or other control point

14. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 14 Who is Establishing the Requirements? All Stakeholders!  End user -- will use the software  Champion -- will pay for it  Marketing -- will sell it  Accountants and Lawyers -- will protect but may not understand the product or the process  Political factors –Such as engineers -- who “know better” than the customer

15. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 15 The Software Process This is the detailed process for carrying out the various steps of the software lifecycle model Integration & TestDesignCodingRequirements Unit Test Write Test Code Write Code Code Walkthrough Lifecycle (Top Level of SW Process) More Detailed Software Process

16. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 16 Tailoring / Planning (concept) DEFINE THE APPROACH UNDERSTAND THE NEED All Possible Software Lifecycles and Processes High Level Process (Software Lifecycle) Specific Software Process

17. “V” Model A General Model of Software Development Requirements Analysis Architecture Design Detailed Design Implementation Unit Test Integration Test Acceptance Test Test Cases Based on Requirements Test Cases Based on Architecture Test Cases Based on Design Note: Test Planning Begins with Requirements!

18. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 18 Some General Categories of Lifecycle Models  Linear: Do each step once, in order –Example: Waterfall model  Incremental or Evolutionary: add to the product at each phase –Example: Spiral model  Iterative: re-do the product at each phase  Ad-Hoc: No set approach, do what seems appropriate at the time

19. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 19 Big-Bang Model (Ad-Hoc)  Developer receives problem statement.  Developer implements solution.  Developer delivers result.  Developer hopes client is satisfied.

20. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 20 Drawbacks of Big-Bang Model  Little or no consistency between applications of the model –So it is hard to incorporate lessons learned  Little or no discipline  Little or no documentation  Little or no transferability to others –So each developer learns on their own Generally this model works well only for small software applications

21. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 21 Waterfall Model of the Software Process (Linear)  Basic Idea: Software is developed in a series of phases that mimic the system lifecycle described above  Goal: to develop, produce, and support a software product Royce, Winston - several papers in the late 1960’s and early 1970’s outlined this model. Royce knew of waterfall’s limitations.

22. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 22 Waterfall Model of the Software Lifecycle Requirements Analysis Design Code Test Integrate Rqmts Specs Design Specs Unit Tested Code Tested Code

23. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 23 Waterfall Model of the Software Lifecycle Requirements Analysis Design Code Test Integrate Each phase ends with a review and/or signoff Rqmts Specs Design Specs Unit Tested Code Tested Code

24. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 24 Waterfall Model of the Software Lifecycle Requirements Analysis Design Code Test Integrate Rqmts Specs Design Specs Unit Tested Code Tested Code Each phase produces artifacts that are input to the next phase

25. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 25 Waterfall Assumptions  Assumption 1: Good Requirements –system or other requirements have been established (defined and validated); –those requirements to be addressed by software are clearly defined –requirements are allocated to all system components (software items)

26. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 26 More Waterfall Assumptions  Assumption 2: A Good System Design –The system design is complete –Software has been fully identified –The software has been divided into individual “products” or software items –Each software item can be developed independently –Requirements are clearly allocated to each software item –Interfaces are clearly defined

27. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 27 Typical Waterfall Phases Exit Criteria Software Requirements Specification (states what software must do and tests it must pass) Software Design Specifications (sufficient to code the software) Code Compiles Code Passes Tests Product Passes Tests Phase Requirements Analysis Design - Preliminary - Detailed Code Test Integrate Goals Translate Allocated Requirements into Specific, Detailed Software Requirements Come up with a Design that will Implement the Requirements Write the Code Test the Code Combine Code Units

28. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 28 Each Phase has Other Aspects Reviews SW Requirements Review Software Design Review(s) Code Review(s) Test Reviews Product Acceptance Test or Review Phase Requirements Analysis Design Code Test Integrate Goals Determine What the SW should Do Determine How to do it Do It Does Code Work? Does Product Work?

29. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 29 An Important Concept in the Waterfall Model  Different groups could be assigned to each phase without loss of performance or time  This concept is the reason behind some of the documentation and review requirements  This is a good concept in general because on a big project it may be very realistic

30. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 30 Problems with the Concept  This concept is unrealistic in many cases –It is overkill for small projects –It can be costly for any size project  The organizational structure may or may not fit these assumptions –does each phase have a different organization?

31. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 31 Suggested Student Study  Determine the milestones, entry criteria, exit criteria, and goals for each phase of the waterfall model  Use waterfall as a basis for looking at other models –Most are described in terms of how they differ NOTE: the essence of the waterfall model is not the names of the specific phases, but rather the fixed, sequential nature of the phases

32. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 32 Waterfall Model Benefits  Intuitive, logical, basic structure  Tells what, not how  Includes all of the basic tasks of software development  Adaptable to many situations by making simple changes or tailoring

33. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 33 Waterfall Model Drawbacks: Waterfall Assumes that:  Requirements are clearly understood –But they often change with time (technology, customer needs, customer understanding of problem) –As we develop we gain insight  Phases occur sequentially –But errors may require going back to fix –Overlapping phases can be more efficient  The customer can understand the requirements specification and verify that it is correct –Prototyping and technical interchange may be necessary in practice

34. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 34 Waterfall Model with Backflow Requirements Analysis Design Code Test Integrate Rqmts Specs Design Specs Unit Tested Code Tested Code This is what actually happens in practice with most applications of the waterfall model

35. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 35 The Waffle Principle  “Plan to throw the first one away; you will anyhow.” Fred Brooks, “The Mythical Man- Month: Essays on Software Engineering”, Addison Wesley, 1975. Revised in 1995.

36. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 36 Spiral Model (Incremental or Iterative)  Originated by Barry Boehm in the 1970’s  Basic idea: software is developed as a series of successively more capable prototypes, each of which is designed to build on the previous stages and to address the areas of highest risk Boehm, Barry, “A Spiral Model of Software Engineering,” IEEE Transactions on Software Engineering, 197? Prof. Barry Boehm

37. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 37 Spiral Model (continued)  Goal: same as waterfall: to develop, produce and support a software product  Difference: an evolutionary series of small steps rather than a single sequence

38. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 38 Spiral Model

39. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 39 Spiral Assumptions 1) Intial requirements are established but may change based on results of prototypes 2) Good design, allocation – but may also change 3) (new from waterfall) You know how to identify, analyze, and rank the risks associated with the project

40. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 40 Spiral Advantages  Accommodates changes in requirements  Facilitates risk management  Supports various forms of incremental and evolutionary development

41. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 41 The “Cycles of Learning” Benefit  You learn a lot during each iteration, which makes the next one more efficient  Studies show that by the third or fourth iteration (when you are doing the bulk of the actual work), the development team is functioning very effectively –And the total time may be less than one “big” iteration, as in the waterfall –Because you made the mistakes on the early, simple software instead of one big software item

42. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 42 Spiral Drawbacks  Admits lack of understanding –May be hard for management and customers to accept)  Does not allow good synchronization with other parts of the project  Hard to tell exactly where you are and how much you have left to do –No exit criteria or time-based milestones  Harder to manage  Can be costly - lots of “throwaway” code

43. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 43 Controlled-Iteration Model  Four phases per major cycle –Inception: Negotiate and define product for this iteration –Elaboration: Architecture and Design –Construction: Create fully functional product –Transition: Deliver and install  The next phase is started before the end of the previous phase (say at 80% point ).

44. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 44 Rational Unified Process (a form of controlled iteration) Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations within phases Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements ElaborationTransitionInceptionConstruction

45. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 45 Rapid Application Development (RAD) (Incremental or Iterative)  An extension/extrapolation of the spiral model  Evolved in the 1980’s and 1990’s among developers of software for the mass market and networks (e-commerce) –Need products quickly –Products often have short lifetimes –Requirements change very rapidly –The system/environment is fluid

46. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 46 Definition Rapid Application Development (RAD)  A collection of programming tools and methods that enables quick production of working software  Key elements of RAD include: –use of short, incremental development cycles –libraries of pre-compiled, commonly used components, such as user interface elements

47. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 47 RAD Requirements Analysis Design Code Test Integrate Rqmts Specs Design Specs Unit Tested Code Tested Code Design Code Test Integrate Requirements Analysis Component Library Artifacts On-line And Dynamic Rqmts Specs Design Specs Code

48. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 48 RAD Assumptions  Interface requirements are established early and kept relatively firm  Application requirements and system design are fluid  Risks of quality problems are mitigated by short product life cycles and opportunity to correct in next release

49. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 49 Advantages of RAD Model  Accommodates Changes in Requirements –Each iteration can accommodate new information about the requirements  Produces a usable product on each iteration  Deals effectively with the biggest risk in this specific type of software – failing to meet market windows!

50. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 50 The “Cycles of Learning” Benefit  Even more than with the spiral model, you learn a lot during each iteration, which makes the next one more efficient  Reuses proven components, so you don’t spend time reinventing

51. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 51 Drawbacks of the RAD Model  Hard for outsiders to understand where you are  Can be chaotic if not managed effectively  Comprehensive quality checks and testing are not normally part of the process  Many documents and artifacts are not produced or not permanent, so long term maintenance can suffer

52. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 52 Extreme Programming (XP) (Incremental or Iterative)  A “lightweight” discipline of software development derived from object oriented programming and based on these principles: –Simplicity –Communication among developers –Feedback –Courage!  Originated with the “C3” project at Chrysler Corporation in 1997

53. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 53 Simple Definition of XP  A highly iterative form of RAD where the focus is on minimalism –Evolutionary design rather than planned design  3-week cycles are typical, even for large projects  Don’t plan ahead because you will probably be wrong –Do only what must be done now - add functionality in later iterations

54. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 54 XP Assumptions  Small, co-located teams  Customers will change their minds  A perfect product cannot be produced, so get something out and then improve it  Close customer contact with programmers

55. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 55 Key XP Practices  Refactoring - ongoing redesign to respond to change  Test first, then code  Pair programming - two people inspect each others’ work  Continuous integration - daily builds to solidify interfaces early

56. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 56 XP Drawbacks  Simplicity is not always easy to accomplish  It is easy to drop the discipline and descend into “hacking”  It doesn’t scale well to really large projects  The whole thing hinges on the developers understanding the problem well - no design specs to work from!

57. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 57 Summary of Module  The lifecycle model is the top level view of the process  There are many different software lifecycle models  A process/lifecycle must be tailored to fit the needs of the specific project

58. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 58 END OF MODULE 05

59. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M05 - Version 8.01 Appendix Other Models

60. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 60 R = Understand Requirements D = Design I = Implement E = Evaluate These are the Basic Steps of Any Development Effort Essentially Similar to One Turn of the Spiral Model or One Cycle through the Waterfall Tornado Model – A Meta Model Basic Development Cycle R I DE

61. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 61 Tornado Model Sequential Application  This application is like the spiral model  Incremental development: each cycle adds new features  Evolutionary development: each cycle improves the previous one R I DE

62. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 62 Tornado Model Other Applications  Requirements –Simulation or prototype –To analyze alternatives or quantify risks  Design –Build a prototype –Test out a concept  Implementation –Two incremental pre- releases R I DE R I DE R I DE R I DE R I DE

63. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 8.01 63 Other Models (Look on the Web – the URLs change to often to list here)  Fountain model  SCRUM model  Ropes model  Time Box model  …