1. 1 CMPT 275 Software Engineering Software life cycle

2. Janice Regan, 2008 2 Software Life Cycle  Sequence of processes completed as a software project moves from inception to retirement  At beginning of project development, choose  Software development paradigm  Software development process model  Define the order/manner in which software life cycle processes are performed  Then you are ready to start software specification, design, implementation, validation

3. Janice Regan, 2008 3 Development Processes  Next we will discuss a list of processes that need to occur some time during the lifetime of a project.  The exact order of the processes and the number of times the processes are done will vary according to the process model developed  Some processes can be considered to happen before, during or after development  Other process occur at any time during development

4. Janice Regan, 2008 4 Processes  For each process we consider we will decide/indicate when the process will most likely occur, give a name for the process, and give a list (partial?) of activities that comprise the process  WHEN: before, during, after development  Name of process  List of activities

5. Janice Regan, 2008 5 Development Processes - 1  WHEN: before development  Concept Exploration  Identifying idea and need for a product  Formulate possible approaches to solution (high level only)  Determining feasibility, identifying and mitigating risks  promotion concept and setting up funding/support

6. Janice Regan, 2008 6 Development Processes - 2  WHEN: before development  System allocation  Estimating, planning and identifying staffing needs for each phase  Determine system architecture

7. Janice Regan, 2008 7 Development Processes - 3  WHEN: during development  Requirements Analysis  gathering, specifying and analyzing the requirements.  Defining functionality and scope (limits on functionality)  Define interface requirements  Prioritize requirements  Validate and Verify requirements

8. Janice Regan, 2008 8 Development Processes - 4  WHEN: during development  System and Software Design  Design how software will be structured internally  Establish system architecture  Select or develop algorithms (if needed)  Describe software system abstractions and relationships  Analysis of the design and verification that the design meets the requirements

9. Janice Regan, 2008 9 Development Processes - 5  WHEN: during development  Implementation:  Programming (and building)  Verification that implemented software meets all requirements Plan unit implementation and integration (implementation/test)  Create user manual (operating instructions)

10. Janice Regan, 2008 10 Development Processes - 6  WHEN: during development  Testing (verification of implementation phase)  Testing modules (unit test)  Testing combinations of modules (integration test)  Testing the whole system (system test)

11. Janice Regan, 2008 11 Development Processes - 7  WHEN: post development  Installation  Installation at user site (plan test accept)  User testing, verifying user needs are met (includes user acceptance test or UAT)  Errors corrected, bugs fixed

12. Janice Regan, 2008 12 Development Processes - 8  WHEN: post development  Operation and Support (maintenance)  Software enhanced (new features, new requirements)  Errors corrected, bugs fixed  Evolution to newer platforms (newer OS, hardware)  Retirement: post development

13. Janice Regan, 2008 13 Integral Processes  Integral processes take place during all phases of development  Verification and Validation:  Software Configuration and Management  Configuration Control, Revision management  Tracking and control of changes  Documentation development / distribution  Training  Plan, Develop, Validate, Implement training program

14. Janice Regan, 2008 14 Life cycle models  Combine the development processes and activities in different ways (different order, once or repeated …) to model the life cycle of a project  By making models of the life cycle of successful software projects can help us design better approaches to plan the life cycle of future projects  There are several ‘generic’ life cycle models that are often used or used as a basis for design of custom life cycle models

15. Janice Regan, 2008 15 Generic Life Cycle models  Sequential (activity centered) Perspective  The waterfall method  V model  Iterative (activity centered) development  Evolutionary  Spiral

16. Janice Regan, 2008 16 Types of Generic Process Models - 2  Component Based Perspective  Focus on applying reusable components (most already exist)  Rational Unified Process  Combines aspects of all three perspectives  Useful for large systems

17. Janice Regan, 2008 17 Waterfall Process Model Project Initiation Concept Exploration System Allocation Requirements Design Implementation Installation Operation & Support Verification Validation

18. Janice Regan, 2008 18 Waterfall Process Model Project Planning Requirement Analysis Design Implementation Testing Maintenance

19. Janice Regan, 2008 19 V Model System Requirements Allocation Requirements Elicitation Unit Test Implementation Operation Component Integration/test Requirements Analysis Preliminary Design Detailed Design System Integration/test Client Acceptance

20. Janice Regan, 2008 20 Why a Waterfall Process Model?  Phases (processes) are performed once  Makes the process easy to follow  One phase should not be started until the previous one is complete  Makes the process easy to manage  Documents need only be produced and approved once (this is a costly process)  Parallels other engineering process models  The waterfall method should only be used if the requirements are well understood

21. Janice Regan, 2008 21  Impractical to fully complete any one of the phases before starting the next one  difficult to capture all requirements before proceeding to design …  Users don’t get to see the results until the end  problems may emerge only at the end when user realizes the product is not what was needed Why not ?

22. Janice Regan, 2008 22  How can we modify these sequential life cycle model to address these problems  Prototypes  can be useful to show to the user to catch problems before implementation  can also be misleading as the client must understand that the system is not ‘almost ready’  Allow for return to earlier processes to update models to include changes to fix deficiencies found in later processes: incorporate iteration  Allow for an incremental approach of developing a basic solution, then adding additional functionality Fixing the problems

23. Janice Regan, 2008 23 Modified Waterfall Model Project Planning Requirement Analysis Design Implementation Testing Maintenance Add some iteration

24. Janice Regan, 2008 24 Evolutionary model  Iterative and incremental (many waterfalls)  Software system to be developed is partitioned into development phases (sub goals) that include some user driven subset of the functionality of the entire project (e.g. Critical Functionality, Required Functionality, Desired Functionality)  Each phase has its own requirements analysis followed by design, implementation, and testing  Each phase adds additional functionality to the project

25. Janice Regan, 2008 25 Boehm’s spiral model After Boehm, 1987 Unit Test and test Acceptance test System test

26. Janice Regan, 2008 26 Spiral model  Round 0: Feasibility study  Round 1: Requirements development  Round 2… : Development / test of system  Risk analysis aspect is critical. In any round development can stop is risk is too high  Requirements clearly defined and completely defined, risks are all low and a single round of development reduces to a waterfall  Requirements clearly defined, but lowest risk in 1 st round, higher in 2 nd reduces to evolutionary

27. Janice Regan, 2008 27 Evolutionary Process Model - 1  Advantages:  Helps assure modularity and maintainability  Each version built on tested results of a previous version  User/client feedback of first iteration (could be a prototype) provides opportunity to catch potential problems, or misunderstanding early  Helps improve project time estimation  Record time taken during first iteration  Helps produce better estimations for next iterations  Test plans can be expanded for new functionality in later iterations

28. Janice Regan, 2008 28  Disadvantages: Because of overlapping iterations  Synchronizing documentation  Management overhead Evolutionary Process Model - 2

29. Janice Regan, 2008 29 Programming Paradigm  The process life cycle models we have discussed were developed before the OO paradigm came into common use  Some models can be adapted to the new paradigm  What about life cycle models specifically for the OO paradigm?

30. Janice Regan, 2008 30 OO: Dividing Tasks  During requirements analysis identify requirements or groups of requirements that have different priorities. As an example  Core functionality (for OO a few use cases)  Necessary additional functionality (for OO add use cases)  Desired additional functionality ( for OO add more use cases)

31. Janice Regan, 2008 31 OO: Incremental Development  A proposed approach for the example:  Develop the Core functionality. Get feedback from the client  As a second iteration/increment add the necessary additional features, repeat the linear sequential process. Get more feedback  Finally (time permitting) complete a third iteration/increment to add the desired additional functionality

32. Janice Regan, 2008 32 Prototyping  Build a mock up of the system for evaluation by client  Helps confirm you are on the right track  Mock-ups may be throwaway, that is rapidly constructed, (usually in a modeling language too inefficient for the final system) to illustrate the functionality of the system  Mockups may be incremental, demonstrating some aspects of the system  Beware the client may see the mock-up as an almost finished product, not a tool for interactive development with input from the client

33. Agile development: Scrum  Please refer to an excellent online summary and video at  http://scrumreferencecard.com/scrum- reference-card/ http://scrumreferencecard.com/scrum- reference-card/  http://scrumtrainingseries.com/Intro_to_ Scrum/Intro_to_Scrum.htm Janice Regan, 2008 33

34. SCRUM  Three roles  Project owner – has overview of entire project (might include multiple scrum teams)  Scrum manager (no management authority, a facilitator)  Scrum team (ideally small < 6) a group of developers with a variety of skills Janice Regan, 2008 34

35. Scrum: incremental development  Task are kept in a “backlog”  Scrum team accepts tasks (features) from “backlog” as they are ready to deal with them.  Develop working system by adding one feature or one small group of features at a time. Janice Regan, 2008 35