CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved CSE7315M05 Slide # 1August 10, 2004 SMU CSE 7315 / NTU SE 584-N Planning and Managing a Software Project Module 05 Software Lifecycles and Processes

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 2 Goal of This Module To examine different kinds of software lifecycles / process models – Advantages and disadvantages – How to select

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 4 Recall that there are Many Possible Software Lifecycles within a Project Lifecycle Phase 2Phase 3Phase 4Phase nPhase c: Software Lifecycle b: Software Lifecycle d: Software Lifecycle a: Software Lifecycle

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 7 This Chart May Help You Decide How to Group Software Products Mission Critical SupportIncidental Life Critical Testing Deliverable Products Throwaway Part of a Deliverable Product Reused in Deliverable Products Criticality of Function AMOUNTOFUSEAMOUNTOFUSE

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 9 Entry Criteria for a Software Lifecycle (continued) Intended use and end-users are clear Applicable standards of quality and such are clearly stated Deliverables are clearly known

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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)

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 14 Who is Establishing the Requirements? 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 16 Tailoring / Planning (concept) DEFINE THE APPROACH UNDERSTAND THE NEED All Possible Software Lifecycles and Processes High Level Process (Software Lifecycle) Specific Software Process

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 17 Waterfall Model of the Software Process 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.

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 18 Waterfall Model of the Software Lifecycle Requirements Analysis Design Code Test Integrate Rqmts Specs Design Specs Unit Tested Code Tested Code

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 19 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 20 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 21 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)

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 22 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 23 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 24 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?

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 25 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 26 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?

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 27 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 28 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 29 Waterfall Model Drawbacks: Waterfall Assumes that: Requirements are clearly understood – But they change with time – 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 30 Spiral Model 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?

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 31 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 32 Spiral Model Plan Next Cycle; Get Commitment Determine What to Do Evaluate the Results Develop the Next Version of Software Start Here

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 33 Spiral Assumptions 1) Intial requirements are established but may change based on results of prototypes 2) (same as waterfall) - Good design, allocation 3) (new) You know how to identify, analyze, and rank the risks associated with the project

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 34 Spiral Advantages Accommodates changes in requirements Facilitates risk management Supports various forms of incremental and evolutionary development

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 35 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 36 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 37 Rapid Application Development (RAD) 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 38 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 39 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 40 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 41 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!

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 42 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 43 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 44 Extreme Programming (XP) 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 45 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 46 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 47 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 48 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!

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 49 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 50 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 51 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 52 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

CSE7315M05 August 10, 2004 CSE SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © , Dennis J. Frailey, All Rights Reserved Slide # 53 END OF MODULE 05