Life Cycle Plan (LCP)
City of Los Angeles
Public Safety Applicant Resource Center
Team No. 09
Team members and roles:
Vaibhav Mathur Project Manager
Preethi Ramesh Feasibility Analyst
Arijit Dey Requirements Engineer
Shreyas Devraj Prototyper
Gaurav Mathur Builder
Divya Nalam OCE
Rakesh Mathur IIV&V
09/26/2013
ii
Version History
Date Author Version Changes made Rationale
09/26/13
Vaibhav
Mathur,
Arijit
Dey,
Shreyas
Devaraj
1.0 First Draft of the Life Cycle Plan
To initiate the Life Cycle
Planning process and discuss the
skills required.
iii
Table of Contents
Life Cycle Plan (LCP) ..................................................................................................................................................i Version History ........................................................................................................................................................... ii Table of Contents ....................................................................................................................................................... iii Table of Tables ............................................................................................................................................................iv Table of Figures ........................................................................................................................................................... 1
1. Introduction ................................................................................................................................................ 1
2. Milestones and Products ............................................................................................................................ 3
3. Responsibilities ........................................................................................................................................... 4
3.1 Responsibilities by Phase ........................................................................................................................... 4
3.2 Skills ............................................................................................................................................................ 6
4. Approach .................................................................................................................................................... 7
4.1 Monitoring and Control ............................................................................................................................ 7
4.2 Methods, Tools and Facilities .................................................................................................................... 7
5. Resources .................................................................................................................................................... 8 6. Iteration Plan ......................................................................................................................................................... 13
6.1 Plan................................................................................................................................................................... 13
6.1.1 Capabilities to be implemented ................................................................................................................... 13
6.1.2 Capabilities to be tested ................................................................................................................................ 13
6.1.3 Capabilities not to be tested ......................................................................................................................... 14
6.1.4 CCD Preparation Plans ................................................................................................................................ 14 6.2 Iteration Assessment ....................................................................................................................................... 14
6.2.1 Capabilities Implemented, Tested, and Results ......................................................................................... 14
6.2.2 Core Capabilities Drive-Through Results .................................................................................................. 14 6.3 Adherence to Plan ........................................................................................................................................... 15
iv
Table of Tables
Table 1: Stakeholder's responsibilities .......................................................................................................................... 4 Table 2: COCOMOII Scale Driver ................................................................................................................................ 8 Table 3: COCOMOII Cost Driver ................................................................................................................................. 8 Table 4: Module lists and SLOC of each module - example .......................................................................................... 9 Table 5: COCOMOII Scale Drivers - example.............................................................................................................. 9 Table 6: COCOMOII Cost Drivers of Module 1 - Plant Service Recording module - example .................................. 10 Table 7: Construction iteration capabilities to be implemented .................................................................................. 13 Table 8: Construction iteration capabilities to be tested ............................................................................................. 13 Table 9: Capabilities implemented, tested, and results ............................................................................................... 14
1
Table of Figures
Figure 1: COCOMO Estimation Result ....................................................................................................................... 12
2
1. Introduction 1.1 Purpose
The Life Cycle plan helps the stakeholders to get a clear picture of what are the objectives to be achieved, when are the milestones & deadlines and what are the products which needs to be delivered, what are the responsibilities and what should be our approach towards it, what resources we have and what are the assumptions in regard to this project.
1.2 Status
The present status of the project is at the exploration phase, gathering the requirements, conducting win-win sessions with client, and checking the feasibility of the project.
1.3 Assumptions The system can be integrated with LDAP for authentication and
authorization.
The system will be readily accepted by the City of Los Angeles
Staff.
There needs to be no integration with the current Application
System.
There is no integration with data of current manual applicant
investigation process.
3
1. Milestones and Products
Overall Strategy The City of Los Angeles Application Resource Center is an online system
which built following the architected agile process as we have to develop the
project from scratch with minimum COTS involvement.
Exploration phase
Duration: 09/11/13- 09/26/13
Concept: In the Exploration Phase the team was formed and the project was selected. The
current system was analyzed. Team held several meetings to discuss on the requirements &
initial scope of the project. The team had also held meetings with its stakeholders to clarify
their doubts and establish a win-win state. The team also worked on what are the resources,
project plan and skills required for the project to be done which are mentioned in the initial
artifacts of the VC Package.
Deliverables: Client Interaction Report. Valuation Commitment Package which includes
Operational Concept Design, Life Cycle Plan and Feasibility Evidence Description.
Milestone: Valuation Commitment Review
Strategy: One Incremental Commitment Cycle
4
2. Responsibilities
2.1 Responsibilities by Phase
Table 1: Stakeholder's responsibilities
Name: Vaibhav Mathur
Role: Project Manager
Exploration Schedule Meetings, Assign Tasks
Valuation <<responsibilities>>
Foundations <<responsibilities>>
Development-
Construction
Iteration
<<responsibilities>>
Development-
Transition
Iteration
<<responsibilities>>
Name: Arijit Dey
Role: Requirements Engineer
Exploration Understanding Requirements, Life Cycle Plannig
Valuation <<responsibilities>>
Foundations <<responsibilities>>
Development-
Construction
Iteration
<<responsibilities>>
Development-
Transition
Iteration
<<responsibilities>>
Name: Divya Nalam
Role: Operational Concept Engineer
Exploration Building the Operational Concept Design Report.
Valuation <<responsibilities>>
Foundations <<responsibilities>>
Development-
Construction
Iteration
<<responsibilities>>
Development-
Transition
Iteration
<<responsibilities>>
5
Name: Preeti Ramesh
Role: Feasibility Analyst
Exploration Checking for Feasibility Evidence and COTS
Valuation <<responsibilities>>
Foundations <<responsibilities>>
Development-
Construction
Iteration
<<responsibilities>>
Development-
Transition
Iteration
<<responsibilities>>
Name: Shreyas Devaraj
Role: Prototyper
Exploration Project Plan and Progress Report Maintaining
Valuation <<responsibilities>>
Foundations <<responsibilities>>
Development-
Construction
Iteration
<<responsibilities>>
Development-
Transition
Iteration
<<responsibilities>>
Name: Gaurav Mathur
Role: Builder
Exploration Building and maintaining Project Website
Valuation <<responsibilities>>
Foundations <<responsibilities>>
Development-
Construction
Iteration
<<responsibilities>>
Development-
Transition
Iteration
<<responsibilities>>
Name: Rakesh Mathur
Role: IIV & V
Exploration Validation and Verification of COTS Interoperability
Valuation <<responsibilities>>
Foundations <<responsibilities>>
Development-
Construction
Iteration
<<responsibilities>>
Development- <<responsibilities>>
6
Transition
Iteration
2.2 Skills
Team members Role Skills
Vaibhav Mathur Project Manager
Life Cycle Planner
Current- ASP.Net, C#,
Javascript
Arijit Dey Requirements Engineer
Prototyper
Current- JAVA, Oracle 10g,
Visual Basic, HTML, UML.
Required- C#, MySQL
Shreyas Devaraj Prototyper
Project Manager
Current- JAVA, MySQL,
JavaScript
Required- ASP.Net, C#
Gaurav Mathur Builder
UML designer
Current-JAVA, C++,MySQL
Required-C#
Preethi Ramesh Feasibility Analyst
Requirement Engineer
Current-ASP.Net, C#
Divya Nalam Operational Concept Engineer
UML designer
Current-C/C++, Python
Required- ASP.Net, C#
Rakesh Mathur Validation and Verification of
COTS Interoperability
Current- ASP.Net, C#,
JavaScript
7
3. Approach
3.1 Monitoring and Control
<< Identify the approach you are using in monitoring and controlling your project. Examples are
Progress Report, Project plan, and etc. >>
3.1.1 Closed Loop Feedback Control
<< Explain how your team gets and provides feedback internally within the team. >>
3.1.2 Reviews
<<Describe various kinds of review that your team is using to control your project. >>
3.2 Methods, Tools and Facilities
<< Describe methods, tools, facilities and their usage and provider that you used in your
project>>
Tools Usage Provider
Red 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>
8
4. 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 to Barry 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 CSCI 577a and 12 weeks in
CSCI 577b.
9
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 REVL
1 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 Rationale
PREC 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.
10
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 Rationale
RELY 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.
11
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.
12
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. >>
13
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. >>
Table 7: Construction iteration capabilities to be implemented
ID Capability Description Priority Iteration
< ID > < Capability > < comments > <value> <value>
6.1.2 Capabilities to be tested
<< For the milestone identified above, identify the capabilities that will be tested in the
upcoming iteration.
Identify the software features and combinations of software features to be tested this iteration.
This may also include non-functional requirements or extra-functional requirements, such as
performance, portability, and so forth.
Additionally you may need to test every requirement listed in the WinWin Agreements DC
package, non-requirement component features such as COTS capabilities and quality, API
functionality, etc. >>
Table 8: Construction iteration capabilities to be tested
ID Capability Description Priority Iteration
< ID > < Capability > < comments > <value> <value>
14
6.1.3 Capabilities not to be tested
<< Identify notable features, and significant combinations of features, which will not be tested
this iteration and why (e.g. a given feature uses a feature which will be implemented in following
iteration). >>
6.1.4 CCD Preparation Plans
<< Identify the clients and other users who will be involved in the Core Capability Drive-
through, the usage scenarios that it will support, and the specific CCD preparation plans and
milestones. These may include
- user context-setting
- site preparation dry runs,
- feedback forms, and
- CCD risk management plans. >>
6.2 Iteration Assessment
6.2.1 Capabilities Implemented, Tested, and Results
<< Describes, in brief, the capabilities that were implemented and the test results. The
capabilities implemented and tested do not necessarily need to match the ones listed in section
6.1 because some capabilities may have been pushed to the next iteration. >>
Table 9: Capabilities implemented, tested, and results
ID Capability Test Case Test Results If fail, why?
< ID > < Capability > < TC-XX > Pass/Fail < comments >
…
6.2.2 Core Capabilities Drive-Through Results
<< Briefly summarize the feedback you received from your client(s). You need to be specific
enough to cover the critical capabilities or scenarios that were discussed, demoed, or shown.
Your descriptions MUST, but not limited to, cover the following areas:
Positive feedbacks
Improvements needed/suggested
Changes to‐be considered (Reprioritized capabilities, requirements, GUI, etc.)
Risks (New risks introduced, risks mitigated, etc.)
Note: Make sure to be specific to the capabilities shown/demonstrated/driven-through.
Simply stating that the clients liked the capabilities is not sufficient. >>
15
6.3 Adherence to Plan
<< Describe how well the iteration ran according to plan. Was it on budget and on time? Is there
any uncertainty in the Software Development Status? Provide some insight to avoid mistakes for
future iterations. >>
