1 / 39

Life Cycle Plan (LCP)

Life Cycle Plan (LCP). Supannika Koolmanojwong CS577a Fall 2012. Problems With Computer System Acquisition and Use in U.S. Government, 1965-1976. 1. Source: GAO Report FGMSD-77-14. Project Plans May Look Complicated, But They Aren’t!. Just Answer the Simple Questions: - Why?

Download Presentation

Life Cycle Plan (LCP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Life Cycle Plan (LCP) Supannika Koolmanojwong CS577a Fall 2012

  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. Completion Percentage of Project Artifacts in Exploration – Foundations Phase

  6. Completion percentage of project artifacts in each phase Note: % shown is the percentage of artifacts completion in Rebaselined Foundations Phase OCD: Operational Concept Description; SSRD: System and Software Requirements Description ; SSAD: System and Software Architecture Description ; UML: UML Models; LCP: Life Cycle Plan ; FED: Feasibility Evidence Description ; SID: Supporting Information Document ; QMP: Quality Management Plan; IP: Iteration Plan ; IAR: Iteration Assessment Report ; TP: Transition (Preparation) Plan; TPC: Test Plan and Cases ; TPR: Test Procedures and Result ; PRP: Peer Review Plan ; PRR: Peer Review Report ; UM: User Manual ; SP: Support Plan ; TM: Training Materials; RTP: Regression Test Package ; PTP: Packaged Tools and Procedure

  7. Completion progress of project artifacts in each phase

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

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

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

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

  12. Process Model Decision Table

  13. Exploration phase for CSCI577

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

  15. Valuation phase

  16. Valuation phaseUse Single NDI process pattern

  17. Valuation phaseNDI/Services-intensive process pattern

  18. Foundations phase in CSCI577 • WinWin Spiral cycle for Foundations • Development Architecture Review Board review

  19. Foundations phase in CSCI577Architected Agile Process Pattern

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

  21. Development phase in CSCI577Construction Iteration I

  22. Development phase in CSCI577Construction Iteration n

  23. Development phase in CSCI577Transition Iteration

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

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

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

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

  28. Example Project Schedule

  29. Example Detailed Schedule

  30. 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 ICM EPG

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

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

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

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

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

  36. Example of COCOMO II calculation

  37. Example of COCOMO II Scale Drivers

  38. Example of COCOMOII Cost factors COCOMOII Cost Drivers of Module 1 Plant Service Recording module COCOMOII Cost Drivers of Module 5 Barcode Generating module ………..

  39. COCOMOII Estimation Result • Justify your estimation result • Doable with 6 person team ? If not, then ? • More info about COCOMO II on EC07-Cost Estimation

More Related