Life Cycle Plan (LCP)
Mission Science Information and Data Management System 3.0
Team 03
Fei Yu: Project Manager, Life Cycle Planner
Yinlin Zhou: Prototyper, Operational Concept Engineer
Yunpeng Chen: Requirements Engineer
Jingwen Peng: Builder, UML Modeler
Chenguang Liu: System Architect
Steven Lee: Requirements Engineer, IIV&V, Quality Focal Point
9/27/2013
13
Version History
Date / Author / Version / Changes made / Rationale /09/26/13 / FY / 1.0 / · Skills of different members are added / · Based on the exploration phase requirement
Table of Contents
Life Cycle Plan (LCP) i
Version History ii
Table of Contents iii
Table of Tables iv
Table of Figures v
1. Introduction 1
2. Milestones and Products 2
3. Responsibilities 3
3.1 Responsibilities by Phase 3
3.2 Skills 4
4. Approach 5
4.1 Monitoring and Control 5
4.2 Methods, Tools and Facilities 5
5. Resources 6
6. Iteration Plan 11
6.1 Plan 11
6.1.1 Capabilities to be implemented 11
6.1.2 Capabilities to be tested 11
6.1.3 Capabilities not to be tested 12
6.1.4 CCD Preparation Plans 12
6.2 Iteration Assessment 12
6.2.1 Capabilities Implemented, Tested, and Results 12
6.2.2 Core Capabilities Drive-Through Results 12
6.3 Adherence to Plan 13
13
1 Table of Contents
Table of Tables
Table 1: Stakeholder's responsibilities 3
Table 2: COCOMOII Scale Driver 6
Table 3: COCOMOII Cost Driver 6
Table 4: Module lists and SLOC of each module - example 7
Table 5: COCOMOII Scale Drivers - example 7
Table 6: COCOMOII Cost Drivers of Module 1 - Plant Service Recording module - example 8
Table 7: Construction iteration capabilities to be implemented 11
Table 8: Construction iteration capabilities to be tested 11
Table 9: Capabilities implemented, tested, and results 12
13
1 Table of Contents
Table of Figures
Figure 1: COCOMO Estimation Result 10
13
1. Introduction
< Discuss the purpose of the LCP>
< Discuss the status of the LCP especially key differences from previous version, for example
“The status of the LCP is currently at the Operation Commitment Package version number 10.0. This is the version that will be delivered to the client. The major changes from Rebaselined Foundations phase are:
· Two team members, Ritesh Kothari and Jerome Wan, did not continue in Development Phase.
· One core capability, Report and Certificate Generation, is deferred.” >
2. Milestones and Products
< Identify the life cycle phases and its dates, deliverables, milestone and strategy of each phase. For example:
“Exploration phase
Duration: 08/24/09- 9/21/09
Concept: They identify project operational concept, system and software requirement, system and software architecture, and life-cycle plan. These phases prioritize the capabilities, conduct investment and feasibility analysis, and implement the software prototype.
Deliverables: Valuation Commitment Package
Milestone: Valuation Commitment Review
Strategy: One Incremental Commitment Cycle”
Note: Schedule of the class and its milestone can be found in the first lecture of the class.
3. Responsibilities
3.1 Responsibilities by Phase
< Identify responsibilities of each team member including client, user, and maintainer in each phase. Please note that a document name such as OCD, WinWin Agreements or Prototype is not a responsibility. Examples of responsibilities are identify project risk, develop prototype, acquire NDI, and etc.
The following table is a template for each stakeholder’s responsibilities. Repeat the table for each stakeholder.
Table 1: Stakeholder's responsibilities
Name: <name>Role: < role name>
Exploration / <responsibilities>
Valuation / <responsibilities>
Foundations / <responsibilities>
Development- Construction Iteration / <responsibilities>
Development- Transition Iteration / <responsibilities>
3.2 Skills
< Identify current and required skills for each role. Please note that if some of your team member does not continue in 477b, you should identify the required role(s) and skills of the new team member. >
>
Team members / Role / SkillsFei YU / Project Manager
Life Cycle Planner
Implementer / Integration Development, Java C++, Javascript, HTML CSS, Python
Required skills:
Visual Basic for Microsoft Access
Yunpeng CHEN / Requirement Engineer
Feasibility / Java, C++, HTML CSS
Required skills:
Visual Basic for Microsoft Access
Yinlin ZHOU / Prototyper
Operational Concept Engineer / Java, C++
Required skills:
Visual Basic for Microsoft Access
Katherine LIU / System Architect
Tester / Java, C++, HTML CSS, C#
Required skills:
Visual Basic for Microsoft Access
Amy PENG / UML Modeler
System Architect / Java, C++, C#
Required skills:
Visual Basic for Microsoft Access
Steven LEE / Requirement Engineer
Quality focal point / Python
Required skills:
Visual Basic for Microsoft Access
4. Approach
4.1 Monitoring and Control
< Identify the approach you are using in monitoring and controlling your project. Examples are Progress Report, Project plan, and etc. >
4.1.1 Closed Loop Feedback Control
< Explain how your team gets and provides feedback internally within the team. >
4.1.2 Reviews
<Describe various kinds of review that your team is using to control your project. >
4.2 Methods, Tools and Facilities
< Describe methods, tools, facilities and their usage and provider that you used in your project>
Tools / Usage / ProviderRed Ridge 3.0 / Provides examples for user interface and system functionality, is helpful in the development of prototype / CSC
PEAR / Creates a framework and distribution system for reusable PHP components / Open source
<Tool> / <Usage> / <Tool Provider>
5. Resources
< Identify the following information in order to estimate the software cost:
- Estimated CSCI577a Effort : X team members at X hrs/week for 12 weeks
- Estimated CSCI577b Effort : X team members at X hrs/week for 12 weeks
- Total estimated effort
- Budget information
- Project duration
- Component modules in your development project.
- Programming language used
You should provide rationale for every cost driver and scale factor of each module.
Note: Refer toBarry W. Boehm, et al, Software Cost Estimation With COCOMO II, Prentice all PTR, New Jersey, 2000 on how to estimate software cost . >
Table 2: COCOMOII Scale Driver
Scale Driver / Value / Rationale<Driver name> / <value> / <comments>
… / … / …
Table 3: COCOMOII Cost Driver
Cost Driver / Value / Rationale<Driver name> / <value> / <comments>
… / …
< Provide screenshot of your COCOMO II analysis result and interpret what does that mean to your project. Please note the number of COCOMOII Cost Driver tables is equal to the number of software modules in your project. >
< ------The following is an example of section 5 ------>
In this section, we present the project effort and schedule estimation of the project using COCOMO II.
The following conditions were used to estimate the cost of our system, the Plant Service Tracking System.
1. This project has no budget for our development efforts. However, the client must provide some necessary equipment for development and testing, e.g. handheld device.
2. The duration of the project is 24 weeks, which are 12 weeks in CSCI477a and 12 weeks in CSCI477b.
3. There are ten developers.
4. There are five modules in this system.
a. Plant Service Recording module
b. Plant Service Management module
c. Authentication module
d. Utility module
e. Barcode Generating module (NDI)
5. All modules are developed with Java technology, i.e. JSP, Java bean and JavaScript.
6. Only one NDI for Barcode Generating module is calculated effort because we never use it and need effort to research and test.
7. The SLOC of NDI, Barbecue java library, in Barcode generating module is counted with USC CodeCount toolset.
The following is module listed in the system and its estimated size with Source Lines of Code (SLOC)
Table 4: Module lists and SLOC of each module - example
No. / Module Name / Brief Description / SLOC / REVL1 / Plant Service Recording / Provide plant service recording system for worker / 500 / 10%
2 / Plant Service Management / Provide plant service management system for manager / 2000 / 10%
3 / Authentication / User authentication and authorization mechanism / 300 / 5%
4 / Utility / Provide essential utilities supporting the system / 200 / 5%
5 / Barcode Generating / Generate barcode using NDI, Barbecue java library / 3561 / 0%
The following is COCOMOII Scale Drivers and rationales of choosing the values.
Table 5: COCOMOII Scale Drivers - example
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 guidelines, which the processes are defined and repeatable but the result may not be consistent, CMM Level 2.
//Since each module is not the same as other modules in various aspects, then you should have one cost driver table for one module. If you have 5 modules, you should have 5 tables of cost drivers. //
The following is COCOMOII Cost Drivers of each module and rationales of choosing the values.
Table 6: COCOMOII Cost Drivers of Module 1 - Plant Service Recording module - example
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 ICSM, 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 10 team members in CSCI477a and 8 team members in CSCI477b 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 handheld device 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 / In CSCI477a, six of eight team members are on-campus students, In CSCI477b, four of six 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.
The following is the result from COCOMOII estimation based on Scale Drivers and Cost Drivers discussed above.
Figure 1: COCOMO Estimation Result
The form of schedule our project uses is the Independent Variable (SAIV) strategy, 24–week schedule drives development of a set of top priority core capabilities. Therefore, the estimates show the effort required for the project.
According to COCOMO II Estimates for CSCI477, one team member effort = 0.83 COCOMO II person months. The pessimistic effort from the COCOMO estimation above is 5.1, so the total team members need for this project = 5.1/0.83 = 6.14
Since, we have 10 people, from this effort estimation; we would be able to finish the project in time. >
6. Iteration Plan
6.1 Plan
< Provide a high-level overview of the content of the given iteration. Indicate which Life cycle milestones will be addressed. >
6.1.1 Capabilities to be implemented
< For the milestone identified above, identify the capabilities that will be implemented in the upcoming iteration. Identify the features, requirements or use–cases that are being developed (implemented, tested, etc.) for this iteration. Each component should be accounted for in at least one iteration. All requirements should be implemented and tested (or re-negotiated) by the completion of all the iterations. Be mindful of implementation dependencies. Document complex dependencies and communicate them to the appropriate development staff. >