1. University of Southern California Center for Systems and Software Engineering Life Cycle Plan (LCP) Barry Boehm CS577a Fall 2015 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 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 3

4. University of Southern California Center for Systems and Software Engineering 1/13/2014 ICSM Activity Levels for Complex Systems 4© USC-CSSE

5. University of Southern California Center for Systems and Software Engineering 1/13/2014 Anchor Point Feasibility Evidence Descriptions Evidence provided by developer and validated by independent experts that: If the system is built to the specified architecture, it will –Satisfy the requirements: capability, interfaces, level of service, and evolution –Support the operational concept –Be buildable within the budgets and schedules in the plan –Generate a viable return on investment –Generate satisfactory outcomes for all of the success-critical stakeholders All major risks resolved or covered by risk management plans Serves as basis for stakeholders’ commitment to proceed Synchronizes and stabilizes concurrent activities Can be used to strengthen current schedule- or event-based reviews 5© USC-CSSE

6. University of Southern California Center for Systems and Software Engineering 6 Similarity of OCD and LCP 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, Quality Assumptions OCD does this for the system. LCP for the project

7. University of Southern California Center for Systems and Software Engineering Business Model Generation 7 More info at EP09 – Business Model Generation

8. University of Southern California Center for Systems and Software Engineering 8

9. University of Southern California Center for Systems and Software Engineering Success-critical stakeholders Success- Critical Stakeholders (SCS) –Project SCS Client, developers, sponsors –Operational SCS: System’s users, operators, supporters, administrators, maintainers (client’s clients) –System-specific SCS supplier, actor, volunteer, vendor, researcher –Key stakeholders should have CRACK characteristics CRACK: Collaborative, Representative, Authorized, Committed, and Knowledgeable ©USC-CSSE9

10. University of Southern California Center for Systems and Software Engineering Value Propositions Are we solving anything? What do we offering ? What value do we deliver to the customer? Which customer needs are we satisfying? –Newness –Performance, cost reduction, risk reduction –Customization, usability –Getting the job done –Price 10

11. University of Southern California Center for Systems and Software Engineering 11 Similarity of OCD and LCP 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, Quality Assumptions OCD does this for the system. LCP for the project

12. University of Southern California Center for Systems and Software Engineering 10 Reasons That Projects Fail 1.Scope Creep 2.Overallocated Resources 3.Poor Communications 4.Bad Stakeholder Management 5.Unreliable Estimates 6.No Risk Management 7.Unsupported Project Culture 8.The Accidental Project Manager 9.Lack of Team Planning Sessions 10.Monitoring and Controlling 12 http://project-management.com/top-10-reasons-why-projects-fail/

13. University of Southern California Center for Systems and Software Engineering Completion Percentage of Project Artifacts in Exploration – Valuation - Foundations Phases Exploration Valuation Foundations OCD20%80%95% SSRD5%80%87% SSAD0%30%90% UML0%30%90% LCP5%79%89% FED5%75%90%

14. 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 14

15. 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) 15

16. 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 : NDI-intensive, Custom, Other –Key stakeholders’ requirements –Schedule As Independent Variable (SAIV), which is required in a university course 16

17. University of Southern California Center for Systems and Software Engineering Example Project Schedule 17

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

19. University of Southern California Center for Systems and Software Engineering 19 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 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 For Milestones and suggested deliverables, check lecture 3

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

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 577 Project Roles Roles – Exploration, Valuation, Foundations phases –Project Manager –Operational Concept Engineer –Requirements Engineer –Prototyper –Software Architect –Life Cycle Plan –Feasibility Analyst –Quality Focal Point Roles – Development phase –Implementer –Tester –Trainer 22

23. 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. Check the ICSM EPG for guided responsibilities 23

24. 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) 24

25. 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 –Check EC-10 for QM strategies 4.2 Methods, Tools, and Facilities 25

26. 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 26 Note : you may use COINCOMO tool Check COINCOMO Tutorial for more information http://greenbay.usc.edu/csci577/fall2013/tools

27. University of Southern California Center for Systems and Software Engineering Example of COCOMO II calculation 27 No.Module NameBrief DescriptionSLOCREV L 1Plant Service Recording Provide plant service recording system for worker 100010% 2Plant Service Management Provide plant service management system for manager 370010% 3AuthenticationUser authentication and authorization mechanism 3005% 4UtilityProvide essential utilities supporting the system 1005% 5Barcode GeneratingGenerate barcode using NDI, Barbecue java library 35610%

28. University of Southern California Center for Systems and Software Engineering Example of COCOMO II Scale Drivers 28 Scale DriverValueRationale PRECHIGHThe development team is familiar with this type of online application. Although, concurrent development associates with extensive new hardware and operational procedures. FLEXHIGHThe system needs to considerably conform to pre-established requirement from the client and external interface specifications, e.g. GPRS services and Internet protocols. RESLHIGHAll critical risk items, schedule, budget and internal milestones are identified. However, there is some uncertainty in hardware compatibility. TEAMHIGHEach stakeholder has considerable consistency of objectives and cultures, and considerable ability and willingness to accommodate others’ objectives. In addition, the stakeholders have basic experience in operating as a team. PMATNOMINALThe development team follows ICSM-EPG, which the processes are defined and repeatable but the result may not be consistent, CMM Level 2.

29. University of Southern California Center for Systems and Software Engineering Example of COCOMOII Cost factors 29 Cost DriverValueRationale RELYNOMIN AL Although, some modules in this project depend on this module, the effect of the software failure is moderate and losses are easily recoverable. DATALOWThe ratio of bytes in the testing database to SLOC in the program is approximately less than 10 because the database will store only information of plant services, which are employee id, check-in time, check-out time, each plant conditions, and short comments, of 20 locations in each week. DOCUNOMIN AL Because the development process follows ICM-EPG, the document for life-cycle needs is normal. CPLXNOMIN AL It contains simple message passing control, standard math and statistical routines for generating reports, and simple I/O process includes device selection from bar code scanner or user interface, status checking of bar code scanner, and error processing. Additionally, it has simple structural changes and uses simple widget set. RUSELOWIt is not intended to be reused for the future project. TIMENOMIN AL The percentage of available execution time expected to be used by the system and subsystem consuming the execution time resource is less than 50% because this system is used when a worker does plant services which are preformed once a week, and this system is used by a manager to review plant service reports which at most couple times a week. STORNOMIN AL The percentage of available storage expected to be used by the system and subsystem is less than 50% because the most data is general text and the information of plant services such as plant conditions and comments are condensed. PVOLLOWMajor changes of the platform, i.e. Apache Tomcat, JDK, MySQL, and web browsers, are approximately every year. ACAPVERY HIGH The analysts have the ability to analyze, design, communicate, and cooperate very well. PCAPVERY HIGH Programmers are capable, efficient and thorough. They are able to communicate and cooperate very well. PCONNOMIN AL We have 8 team members in CSCI577a and 5 team members in CSCI 577b that suitable for our project sizing. APEXNOMIN AL The average experience of the team members for this online web-based application is about one year. LTEXNOMIN AL The development team plans to develop this web-based application with JSP, HTML, and Java script, and uses SQL language to query information from the database. The tools for programming are Dreamweaver and Eclipse. Therefore, the language and tool experience is nominal because team members have at least one year experience with these languages and tools. PLEXLOWThe server platform is web server Apache Tomcat with JDK version 1.5, and database is MySQL. Although, all developers have this platform experience, this module need implementation an user interface on PDA and input with bar code scanner which our developers have less experience. TOOLLOWThe software tools development team plan to use is just simple, frontend, backend CASE, and supporting little integration. There is no support for life-cycle. SITEVERY HIGH Six of eight team members are on-campus students; only two team members are off-campus students. Additionally, we use wideband electronic communication and occasional video conference. SCEDNOMIN AL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester. COCOMOII Cost Drivers of Module 1 Plant Service Recording module Cost DriverValueRationale RELYNOMINALAlthough, some modules in this project depend on this module, the effect of the software failure is moderate and losses are easily recoverable. DATALOWThe ratio of bytes in the testing database to SLOC in the program is approximately less than 10 because the database will store only information of plant services, which are employee id, check-in time, check-out time, each plant conditions, and short comments, of 20 locations in each week. DOCUNOMINALBecause the development process follows ICM-EPG, the document for life-cycle needs is normal. CPLXNOMINALIt contains simple message passing control, standard math and statistical routines for generating reports, and simple I/O process includes device selection from bar code scanner or user interface, status checking of bar code scanner, and error processing. Additionally, it has simple structural changes and uses simple widget set. RUSELOWIt is not intended to be reused for the future project. TIMENOMINALThe percentage of available execution time expected to be used by the system and subsystem consuming the execution time resource is less than 50% because this system is used when a worker does plant services which are preformed once a week, and this system is used by a manager to review plant service reports which at most couple times a week. STORNOMINALThe percentage of available storage expected to be used by the system and subsystem is less than 50% because the most data is general text and the information of plant services such as plant conditions and comments are condensed. PVOLLOWMajor changes of the platform, i.e. Apache Tomcat, JDK, MySQL, and web browsers, are approximately every year. ACAPVERY HIGH The analysts have the ability to analyze, design, communicate, and cooperate very well. PCAPVERY HIGH Programmers are capable, efficient and thorough. They are able to communicate and cooperate very well. PCONNOMINALWe have 8 team members in CSCI577a and 5 team members in CSCI 577b that suitable for our project sizing. APEXNOMINALThe average experience of the team members for this online web- based application is about one year. LTEXVERY LOW The development team plans to develop this web-based application with JSP, HTML, and Java script, and uses SQL language to query information from the database. The tools for programming are Dreamweaver and Eclipse. Although, the language and tool experience is nominal because team members have experience with these languages and tools, this module is developed by using NDI java library for bar code generating that our developers have no experience. PLEXNOMINALThe server platform is web server Apache Tomcat with JDK version 1.5, and database is MySQL. All developers have this platform experience at least one year. TOOLLOWThe software tools development team plan to use is just simple, frontend, backend CASE, and supporting little integration. There is no support for life-cycle. SITEVERY HIGH Six of eight team members are on-campus students; only two team members are off-campus students. Additionally, we use wideband electronic communication and occasional video conference. SCEDNOMINALThe schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester. COCOMOII Cost Drivers of Module 5 Barcode Generating module ………..

30. University of Southern California Center for Systems and Software Engineering COCOMOII Estimation Result Justify your estimation result –Doable with 6 person team ? If not, then ? –More info about COCOMO II on EC07-Cost Estimation 30

31. University of Southern California Center for Systems and Software Engineering 10 Reasons That Projects Fail 1.Scope Creep 2.Overallocated Resources 3.Poor Communications 4.Bad Stakeholder Management 5.Unreliable Estimates 6.No Risk Management 7.Unsupported Project Culture 8.The Accidental Project Manager 9.Lack of Team Planning Sessions 10.Monitoring and Controlling 31 http://project-management.com/top-10-reasons-why-projects-fail/

32. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 USC CSSE32 Instructional Incremental Commitment Spiral Model – Software Engineering

33. University of Southern California Center for Systems and Software Engineering Exploration phase for CSCI577 33

34. University of Southern California Center for Systems and Software Engineering Valuation phase in CSCI577 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 34

35. University of Southern California Center for Systems and Software Engineering Valuation phase 35

36. University of Southern California Center for Systems and Software Engineering Valuation phase Use Single NDI process pattern 36

37. University of Southern California Center for Systems and Software Engineering Valuation phase NDI/Services-intensive process pattern 37

38. University of Southern California Center for Systems and Software Engineering Foundations phase in CSCI577 WinWin Spiral cycle for Foundations Development Architecture Review Board review 38

39. University of Southern California Center for Systems and Software Engineering Foundations phase in CSCI577 Architected Agile Process Pattern 39

40. 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 40

41. University of Southern California Center for Systems and Software Engineering Development phase in CSCI577 Construction Iteration I 41

42. University of Southern California Center for Systems and Software Engineering Development phase in CSCI577 Construction Iteration n 42

43. University of Southern California Center for Systems and Software Engineering Development phase in CSCI577 Transition Iteration 43

44. University of Southern California Center for Systems and Software Engineering 44 Transition Plan “Ensure that system’s operational stakeholders are able to successfully operate & maintain system” Plans for change from development mode to operational mode –Site installation & test –Load data –Pilot Operations –Preparations for roll-out ©USC-CSSE

45. University of Southern California Center for Systems and Software Engineering 45 Support Plan Guide system’s support stakeholders (administrators, operators, maintainers, …) on successful –Operation –Maintenance [and Enhancement?] ©USC-CSSE