Copyright , 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

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

“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!

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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.

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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, Revised in 1995.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version Spiral Model

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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 ).

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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!

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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!

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M05 - Version 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

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