Life Cycle Plan (LCP)

University of Southern California

Center for Systems and Software Engineering

Life Cycle Plan (LCP)

Supannika Koolmanojwong

CS577a Fall 2012

1



2

Problems With Computer System Acquisition and Use in U.S. Government, 1965-1976

0 10 20 30 40 50 60

Govt.-Wide Management

Technology Factors

Acquisition Mechanics

Underutilization of Equipment

Poor Control

Poor Planning

Percent of GAO Reports Identifying Problem

Source: GAO Report FGMSD-77-14

1



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 (individualAnd location/organization)

Approach

Resources

Assumptions



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



Completion Percentage of Project Artifacts in Exploration – Foundations Phase



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



Completion progress of project artifacts in each phase



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

8



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)

9



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

10



Example LCP 2.1 Overall StrategyFrom 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.

11



Process Model Decision Table

12



Exploration phase for CSCI577

13



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

14



Valuation phase

15



Valuation phaseUse Single NDI process pattern

16



Valuation phaseNDI/Services-intensive process pattern

17



Foundations phase in CSCI577

• WinWin Spiral cycle for Foundations• Development Architecture Review Board

review

18



Foundations phase in CSCI577Architected Agile Process Pattern

19



Process model for CS 577

• Development phase– Construction iteration

• WinWin Spiral Cycle• Core Capability Review• Transition Readiness Review

– Transition iteration• Operation Commitment Review

20



Development phase in CSCI577Construction Iteration I

21



Development phase in CSCI577Construction Iteration n

22



Development phase in CSCI577Transition Iteration

23



Process model for CS 577 (contd.)

• Operation phase (Customer responsibility)– Release 1– Release Readiness Review– Release 2– Release Readiness Review– …

24



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

25



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

-



Example Project Schedule

28



29

Example Detailed Schedule



30

2.2.1 Exploration PhaseDuring this phase, explore current system and identify initial scope of the system.2.2.2 Valuation PhaseDuring 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 PhaseDuring 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 Phase2.2.5 Development Phase

Example 2.3 Phase Deliverables and Completion Criteria

see Default Project Deliverables in Each Phase in ICM EPG

Artifact Due date Format MediumClient Interaction Report 9/17/2006 .doc, .pdf Soft copyValuation Commitment PackageOperational Concept Description (OCD) Early Section Life Cycle Plan (LCP) Early SectionFeasibility Evidence Description (FED) Early Section

09/18/2006 .doc, .pdf Soft copy

Evaluation of Valuation Commitment Package 09/27/2006 .xls Soft copyProject Effort Every Monday Text ER systemProject Plan Every Wednesday .mpp, .pdf Soft copyProgress Report Every Wednesday .xls Soft copyRisk Analysis Every Wednesday Text DART system



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

31



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.

32



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)

33



4. Approach

• 4.1 Monitoring and Control– 4.1.1 Closed loop feedback control– 4.1.2 Reviews

• 4.2 Methods, Tools, and Facilities

34



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

35



Example of COCOMO II calculation

36

No. Module Name Brief Description SLOC

REVL

1 Plant Service Recording

Provide plant service recording system for worker

1000 10%

2 Plant Service Management

Provide plant service management system for manager

3700 10%

3 Authentication User authentication and authorization mechanism

300 5%

4 Utility Provide essential utilities supporting the system

100 5%

5 Barcode Generating Generate barcode using NDI, Barbecue java library

3561 0%



Example of COCOMO II Scale Drivers

37

Scale Driver Value RationalePREC HIGH The development team is familiar with this type of online

application. Although, concurrent development associates with extensive new hardware and operational procedures.

FLEX HIGH The system needs to considerably conform to pre-established requirement from the client and external interface specifications, e.g. GPRS services and Internet protocols.

RESL HIGH All critical risk items, schedule, budget and internal milestones are identified. However, there is some uncertainty in hardware compatibility.

TEAM HIGH Each 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.

PMAT NOMINAL The development team follows ICSM-EPG, which the processes are defined and repeatable but the result may not be consistent, CMM Level 2.



Example of COCOMOII Cost factors

38

Cost Driver Value RationaleRELY NOMIN

ALAlthough, some modules in this project depend on this module, the effect of the software failure is moderate and losses are easily recoverable.

DATA LOW The 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.

DOCU NOMINAL

Because the development process follows ICM-EPG, the document for life-cycle needs is normal.

CPLX NOMINAL

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.

RUSE LOW It is not intended to be reused for the future project.TIME NOMIN

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

STOR NOMINAL

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.

PVOL LOW Major changes of the platform, i.e. Apache Tomcat, JDK, MySQL, and web browsers, are approximately every year.

ACAP VERY HIGH

The analysts have the ability to analyze, design, communicate, and cooperate very well.

PCAP VERY HIGH

Programmers are capable, efficient and thorough. They are able to communicate and cooperate very well.

PCON NOMINAL

We have 8 team members in CSCI577a and 5 team members in CSCI 577b that suitable for our project sizing.

APEX NOMINAL

The average experience of the team members for this online web-based application is about one year.

LTEX NOMINAL

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.

PLEX LOW The 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.

TOOL LOW The software tools development team plan to use is just simple, frontend, backend CASE, and supporting little integration. There is no support for life-cycle.

SITE VERY 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.

SCED NOMINAL

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 Driver Value RationaleRELY NOMINAL Although, some modules in this project depend on this module,

the effect of the software failure is moderate and losses are easily recoverable.

DATA LOW The 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.

DOCU NOMINAL Because the development process follows ICM-EPG, the document for life-cycle needs is normal.

CPLX NOMINAL 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.

RUSE LOW It is not intended to be reused for the future project.TIME NOMINAL 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.

STOR NOMINAL 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.

PVOL LOW Major changes of the platform, i.e. Apache Tomcat, JDK, MySQL, and web browsers, are approximately every year.

ACAP VERY HIGH

The analysts have the ability to analyze, design, communicate, and cooperate very well.

PCAP VERY HIGH

Programmers are capable, efficient and thorough. They are able to communicate and cooperate very well.

PCON NOMINAL We have 8 team members in CSCI577a and 5 team members in CSCI 577b that suitable for our project sizing.

APEX NOMINAL The average experience of the team members for this online web-based application is about one year.

LTEX VERY 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.

PLEX NOMINAL The 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.

TOOL LOW The software tools development team plan to use is just simple, frontend, backend CASE, and supporting little integration. There is no support for life-cycle.

SITE VERY 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.

SCED NOMINAL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester.

COCOMOII Cost Drivers of Module 5 Barcode Generating module

………..



COCOMOII Estimation Result• Justify your estimation result

– Doable with 6 person team ? If not, then ? – More info about COCOMO II on EC07-Cost Estimation

39

Life Cycle Plan (LCP)

Documents

Transcript of Life Cycle Plan (LCP)