1. University of Southern California Center for Systems and Software Engineering Life Cycle Plan (LCP) Barry Boehm CS577a Fall 2010 09/20/2010 1

2. University of Southern California Center for Systems and Software Engineering 2 Problems With Computer System Acquisition and Use in U.S. Government, 1965-1976 Source: GAO Report FGMSD-77-14 1

3. University of Southern California Center for Systems and Software Engineering 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. University of Southern California Center for Systems and Software Engineering 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 4

5. University of Southern California Center for Systems and Software Engineering 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 5

6. University of Southern California Center for Systems and Software Engineering 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) 6

7. University of Southern California Center for Systems and Software Engineering 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 7

8. University of Southern California Center for Systems and Software Engineering 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. 8

9. University of Southern California Center for Systems and Software Engineering ICSM: The Incremental Commitment Spiral Model 09/03/2010@USC CSSE9

10. University of Southern California Center for Systems and Software Engineering Different Risk Patterns Yield Different Processes 1009/03/2010@USC CSSE 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

11. University of Southern California Center for Systems and Software Engineering Process Model Decision Table 11 Process PatternsExample Size, Complexity Change Rate (%/Month) Criticality NDI Support Organization al and Personnel Capability Time/Build; Time/Increm ent 1. Use NDISmall accountingComplete 2. AgileE-servicesLow1-30Low-MedGood; in placeAgile-ready Med-high <= 1 day; 2-6 weeks 3. Architected AgileBusiness data processingMed1-10Med-HighGood; most in placeAgile-ready Med-high 2-4 weeks; 2-6 months 4. Formal MethodsSecurity kernel; Safety- critical LSI chip Low0.3Extra HighNoneStrong formal methods experience 1-5 days; 1-4 weeks 5. HW with embedded SW component Multi-sensor control deviceLow0.3-1Med-Very HighGood; in placeExperienced; med-high SW: 1-5 days; Market-driven 6. Indivisible IOCComplete vehicle platformMed-High0.3-1High- Very HighSome in placeExperienced; med-high SW: 2-6 weeks; Platform: 6-18 months 7. NDI- intensiveSupply chain managementMed-High0.3-3Med-Very HighNDI-driven architectureNDI- experienced; med-high SW: 1-4 weeks; Systems: 6-18 months 8. Hybrid agile/ plan-driven systemC4ISR systemMed-Very HighMixed parts; 1-10Mixed parts; Med- Very High Mixed parts 1-2 months; 9-18 months 9. Multi-owner system of systemsNet-centric military operations Very HighMixed parts; 1-10Very HighMany NDIs; some in placeRelated experience, med-high 2-4 months; 18-24 months 10. Family of systemsMedical device product lineMed-Very High1-3Med-Very HighSome in placeRelated experience, med-high 1-2 months; 9-18 months 11. BrownfieldIncremental legacy phaseoutHigh-Very High 0.3-3Med-HighNDI as legacy replacementLegacy re-engineering 2-6 weeks/ refactor ; 2-6 months 12a. Net- Centric Services— Community Support Community Services or Special Interest Group Low-Med0.3-3Low-MedTailorable service elements NDI- experienced <= 1 day; 6-12 months 12b. Net-Centric Services—Quick Response Decision Suppport Response to competitor initiative Med-High3-30Med-HighTailorable service elements NDI- experienced <= 1 day ; QR-driven Legend: C4ISR: Command, Control, Computing, Communications, Intelligence, Surveillance, Reconnaissance; HW: Hardware; IOC: Initial Operational Capability; NDI: Non-Development Item; SW: Software.

12. University of Southern California Center for Systems and Software Engineering 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 12

13. University of Southern California Center for Systems and Software Engineering Process model for CS 577 Development phase –Construction iteration WinWin Spiral Cycle Core Capability Review Transition Readiness Review –Transition iteration Operation Commitment Review 13

14. University of Southern California Center for Systems and Software Engineering Process model for CS 577 (contd.) Operation phase (Customer responsibility) –Release 1 –Release Readiness Review –Release 2 –Release Readiness Review –… 14

15. University of Southern California Center for Systems and Software Engineering 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 15

16. University of Southern California Center for Systems and Software Engineering 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. University of Southern California Center for Systems and Software Engineering 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. University of Southern California Center for Systems and Software Engineering Example Project Schedule 18

19. University of Southern California Center for Systems and Software Engineering 19 Example Detailed Schedule

20. University of Southern California Center for Systems and Software Engineering 20 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 Example 2.3 Phase Deliverables and Completion Criteria see Default Project Deliverables in Each Phase in ICSM EPG ArtifactDue dateFormatMedium Client Interaction Report9/17/2006.doc,.pdfSoft copy Valuation Commitment Package  Operational Concept Description (OCD) Early Section  Life Cycle Plan (LCP) Early Section  Feasibility Evidence Description (FED) Early Section 09/18/2006.doc,.pdfSoft copy Evaluation of Valuation Commitment Package09/27/2006.xlsSoft copy Project EffortEvery MondayTextER system Project PlanEvery Wednesday.mpp,.pdfSoft copy Progress ReportEvery Wednesday.xlsSoft copy Risk AnalysisEvery WednesdayTextDART system

21. University of Southern California Center for Systems and Software Engineering 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 21

22. University of Southern California Center for Systems and Software Engineering 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. 22

23. University of Southern California Center for Systems and Software Engineering 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) 23

24. University of Southern California Center for Systems and Software Engineering 4. Approach 4.1 Monitoring and Control –4.1.1 Closed loop feedback control –4.1.2 Reviews 4.2 Methods, Tools, and Facilities 24

25. University of Southern California Center for Systems and Software Engineering 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 25