Life Cycle Plan (LCP)

1. Life Cycle Plan (LCP) Barry Boehm CS577a Fall 2010 09/20/2010

2. Problems With Computer System Acquisition and Use in U.S. Government, 1965-1976 1 Source: GAO Report FGMSD-77-14

3. Project Plans May Look Complicated, But They Aren’t! • Just Answer the Simple Questions: • - Why? • - What? • - When? • - Who? • - Where? • - How? • - How Much? • - Whereas? Objectives to be achieved Milestones (dates) & Products (to be delivered) Responsibilities (individual And location/organization) Approach Resources Assumptions

4. Objectives of Software Development • Deliver a software system • Deliver a trustworthy software system • Deliver a trustworthy, maintainable, software system • Make winners of key stakeholders • Operators: explain procedures, and prepare facilities • Users, Operators, and Maintainers: perform data conversion, training; set up transition procedures, and support capabilities

5. LCP 1. Introduction • 1.1 Purpose of the LCP document • 1.2 Status of the LCP document • Identify and document any differences between the contents of LCP and Win-Win negotiations. • Identify major LCP-related issues

6. LCP 1. Introduction (Contd.) • 1.3 Assumptions • Conditions Necessary to Meet Plans, which, if not realized, would require re-negotiation • Examples • Requirements Stability • Schedule Stability • Continuity of Funding • Delivery of Customer-Furnished Items, On-Schedule, and in Acceptable Condition • Customer Response Time when Approvals are Required • Other external dependencies (Hardware availability/performance, COTS availability/performance, satisfactory progress of other teams on other projects on which this one depends)

7. 2. Milestones and Products (What? When?) • 2.1 Overall Strategy • Describe the choice of process model to be used • Depending upon: • Type of project : COTS-based, Custom, Other • Key stakeholders’ requirements • Schedule As Independent Variable (SAIV), which is required in a university course

8. Example LCP 2.1 Overall Strategy From Hispanic Digital Archive LCP: • The proposed amount of flexibility. Therefore, we propose to use the evolutionary development as our software engineering process as suggested by the Process Model Decision Table. Further, we propose to use the WinWin Spiral Model as it is understood fairly well by the team members and system envisages a moderately understood set of requirements to be met with a low degree of robustness but with a high is supported by the Center for Software Engineering, University of Southern California. The schedules for project activities have been estimated using COCOMO II post-architecture model.

9. ICSM: The Incremental Commitment Spiral Model @USC CSSE

10. Different Risk Patterns Yield Different Processes Architected Agile E.g. Business data processing Use Single NDI E.g. Accounting System NDI-Intensive E.g. Supply Chain Management Services-Intensive E.g. Community Services @USC CSSE

11. Process Model Decision Table

12. Process model for CS 577 • Exploration, Valuation, Foundations phases • Exploration phase • Valuation phase • WinWin Spiral cycle for Valuation • Foundations Architecture Review Board review • Use Decision Criteria to select the appropriate special case • Architected Agile • Use NDI • NDI-Intensive • NCS-Intensive • Foundations phase • WinWin Spiral cycle for Foundations • Development Architecture Review Board review

13. Process model for CS 577 • Development phase • Construction iteration • WinWin Spiral Cycle • Core Capability Review • Transition Readiness Review • Transition iteration • Operation Commitment Review

14. Process model for CS 577 (contd.) • Operation phase (Customer responsibility) • Release 1 • Release Readiness Review • Release 2 • Release Readiness Review • …

15. Phases • Provide more detailed milestone charts and activity graphs • For each increment, indicate: • Major dependencies of development activities on other increments, on facilities, etc.; • Milestones showing the overall order in which components are to be integrated, and the intermediate stages of increment and acceptance testing. • How these are synchronized with milestones for preparation of test drivers, facilities, etc... for the various increments. • Completion of integration, of product test, and of acceptance test

16. Phases (Contd.) • Measurable milestones • - Not “Start working on next version of GUI” • - But “Complete next version of GUI for presentation to client in two days” • Specific schedule dates • Gantt charts • Calendar-oriented tasks lists • Task dependencies optional • Activity networks/PERT charts • - Task dependencies explicit

17. 2.2 Project Deliverables • Provide a list of artifacts to be delivered.  • The precise artifacts to be delivered depend upon your project’s type.  • The contents of the list depend on the type of project • with certain COTS projects having different artifact delivery requirements than custom development projects, so an indication of the project type would be appropriate here. • For each artifact, provide its due date, format (word, pdf, etc) and delivery medium (hard copy, soft copy, etc).

18. Example Project Schedule

19. Example Detailed Schedule

20. Example 2.3 Phase Deliverables and Completion Criteria 2.2.1 Exploration Phase During this phase, explore current system and identify initial scope of the system. 2.2.2 Valuation Phase During this phase, initial understanding of the desired system must be accomplished. This is achieved by defining the scope of the project so all stakeholders are in concurrence. Feasibility analysis and prioritization of the tasks must also be done here. 2.2.3 Foundations Phase During this phase, prototyping must demonstrate the architecture’s feasibility and stability. Risks and plans to minimize risk must also be assessed and developed in this phase. Additionally an appropriate development schedule should be created. Furthermore, cost estimates must also be conceived here. Moreover, an operational impact analysis must be completed to observe how useful the proposed would be to the customer and user. 2.2.4 Rebaselined Foundations Phase 2.2.5 Development Phase see Default Project Deliverables in Each Phase in ICSM EPG

21. 3. Responsibilities (Who? Where?) • 3.1 Project – specific stakeholder’s responsibilities • Provide an overall summary of stakeholders’ responsibilities during the development of the project. • Include the responsibilities of each stakeholders – or group of stakeholders -- for each phase

22. 3.2 Responsibilities By Phase • For each member of the development team, identify his/her role and his/her primary and secondary responsibility during the various phases of the development. • Identify the stakeholder representative(s) who is/are authorized to approve any change(s) in project scope, budget or schedule along with the organization that each one represents.

23. 3.3 Skills • Identify skills required for each role. • If you are looking for a team member(s) to join your team in CSCI577b, please identify expected roles, responsibilities, and skills of your new team member(s)

24. 4. Approach • 4.1 Monitoring and Control • 4.1.1 Closed loop feedback control • 4.1.2 Reviews • 4.2 Methods, Tools, and Facilities

25. 5. Resources • COCOMO Analysis • Provide COCOMOII effort and schedule estimates. • Explain how values were chosen for the various parameters. • Analyze the COCOMOII estimation result • For NDI/NCS team, Use COCOTS for your resources calculation