lcp_lca_f06a_t03_v2.0.doc - software … · web viewtools usage provider microsoft word 2003...
TRANSCRIPT
Life Cycle Plan (LCP)
California Science Center Volunteer Tracking System
Team #3
Phongphan Danphitsanuphan Project Manager
Charlie Lormanometee Project Coordinator / QA
Deepak Pandey System Analyst / Tester
Pongtip Aroonvatanaporn System Architect / Programmer
Natachart Laoteppitak Software Architect / Programmer
Amit Shah Quality Focal Point Personnel
Jeremy Stoller Client
Vincent Tsan Maintainer
May 16 2008
LCP_AsBuilt_S07b_T03_V9.0 Version Date: 05/16/08
Life Cycle Plan (LCP) Version 9.0
Version HistoryDate Author Versio
nChanges made Rationale
10/10/06 Charlie Lormanometee
1.0 Filled in information in all sections
from LCP template in 577a web site LCO draft following lean MBASE
guideline version 1.7
10/17/06 Charlie Lormanometee
1.1 Added link for COCOMO model and
modified COCOMO model. Updated table 2
Missing a link for COCOMO and changed development model from early design to post architecture.
Making table 2 more specific
10/21/06 Charlie Lormanometee
1.2 Update PCON value and other values Update table 2 Update table 4
The team just found out how many people are going to continue in 577b
The Spring 07 schedule is posted online
11/17/06 Charlie Lormanometee
2.0 Update table 2 Update table 4 Update table 8 Update section 4.1.2
Elaborate more on deliverables in production stage
Added required qualification Make modification on some of the
cost drivers Added number of review methods
11/22/06 Charlie Lormanometee
2.1 Added table 5 Make clarification on role and skill
for existing and new members in 577b
12/2/06 Charlie Lormanometee
3.0 Modified estimated COCOMO cost
driver Identify developer discontinuity and
recruited new comer
01/31/06 Charlie Lormanometee
6.0 Updated 2 Updated 3,4, and 5 Updated COCOMO KLOC
Update for RLCA New & changed developer
02/15/06 Charlie Lormanometee
6.2 Updated COCOMO Scale Factor and
Cost Drivers Added table 7
Taking uncertainties in to consideration
577b version
04/1/07 Charlie Lormanometee
7.0 Update section 2.1 Update COCOMO
IOC Working Set#1 Reconstruct COCOMO module
according to the plan
04/30/07 Charlie Lormanometee
7.3 Update delivery date Date assigned by Team 0
05/02/07 Charlie Lormanometee
8.0 Update COCOMO COCOMO for TRR
05/16/08 Supannika Koolmanojwong
9.0 Update all sections To comply with ICM guidelines
LCP_AsBuilt_S07b_T03_V9.0 ii Version Date: 05/16/08
Life Cycle Plan (LCP) Version 9.0
Table of ContentsLife Cycle Plan (LCP)......................................................................................................................iVersion History...............................................................................................................................iiTable of Contents...........................................................................................................................iiiTable of Tables...............................................................................................................................ivTable of Figures...............................................................................................................................v
1. Introduction..................................................................................................................................................1
1.1 Purpose of the LCP......................................................................................................................................1
1.2 Status of the LCP.........................................................................................................................................1
1.3 Assumptions................................................................................................................................................1
2. Milestones and Products..............................................................................................................................3
2.1 Overall Strategy...........................................................................................................................................3
2.2 Phases..........................................................................................................................................................4
2.3 Project Deliverables.....................................................................................................................................5
3. Responsibilities..........................................................................................................................................10
3.1 Overall Summary.......................................................................................................................................10
3.2 By Phase / Stage........................................................................................................................................12
4. Approach....................................................................................................................................................16
4.1 Monitoring and Control.............................................................................................................................16
4.2 Methods, Tools and Facilities....................................................................................................................18
5. Resources...................................................................................................................................................19
LCP_AsBuilt_S07b_T03_V9.0 iii Version Date: 05/16/08
Life Cycle Plan (LCP) Version 9.0
Table of TablesTable 1: Project Milestones............................................................................................................................................3
Table 2: Artifact deliverables in Valuation Phase..........................................................................................................4
Table 3: Artifact Deliverables in Architecting Phase.....................................................................................................5
Table 4: Artifact deliverables in Development Stage.....................................................................................................7
Table 5: Artifact Deliverables in Operation Phase........................................................................................................8
Table 6: Stakeholder responsibilities during software life cycle....................................................................................9
Table 7: Stakeholder responsibilities during each phase.............................................................................................10
Table 8: Role and required skills for 577b members....................................................................................................13
Table 9: Authorized Stakeholder Representatives in CSCI577a..................................................................................13
Table 10: Authorized Stakeholder Representatives in CSCI577b................................................................................13
Table 11: Tools being used in the project.....................................................................................................................16
Table 12: Rationale for Project Scale Factors.............................................................................................................18
Table 13: Rationale for Cost Drivers of Module 1-Volunteer candidate module........................................................18
Table 14: Rationale for Cost Drivers of Module 2-Volunteer portal module..............................................................19
Table 15: Rationale for Cost Drivers of Module 3-Supervisor module........................................................................20
Table 16: Rationale for Cost Drivers of Module 4-Volunteer Management module...................................................20
Table 17: Rationale for Cost Drivers of Module 5-Personnel Information Management module...............................21
LCP_AsBuilt_S07b_T03_V9.0 iv Version Date: 05/16/08
Life Cycle Plan (LCP) Version 9.0
Table of FiguresFigure 1: COCOMO Estimation Result of 6 modules..................................................................................................24
Figure 2: COCOMO Estimation Result of 5 modules..................................................................................................25
LCP_AsBuilt_S07b_T03_V9.0 v Version Date: 05/16/08
Life Cycle Plan (LCP) Version 9.0
1.Introduction
1.1 Purpose of the LCP
The purpose of the Life Cycle Plan (LCP) for the California Science Center Volunteer Tracking System is to plan, monitor and control the progress of the project in order to maximize the productivity of people and resources throughout the system’s life cycle for development and after delivery. This LCP document status is in an Operation Commitment Package. There is no major significant difference between the content of the LCP and the WinWin negotiated agreements.
1.2 Status of the LCP The status of the LCP is currently at the As-Builtoperation commitment package version
number 9.0. This is the version that will be delivered to the client. There have been quite significant changes to the project when we moved from the LCA to the Re-baselined LCA phase due to time and personnel constraints as well as teams dependencies (Teams 0,1 and 2). The scope and life cycle plan of the Volunteer Tracking System project has been re-evaluated to accommodate those challenges.
1.3 AssumptionsThe assumptions are the following:
1. The duration of the project is 24 weeks, which is 12 weeks in Fall 2006 and 12 weeks in Spring 2007.
2. Each development team member must follow the project schedule.3. The core requirements will be stable. System capability requirements are
The system shall provide online application form for volunteer candidate. The system shall volunteer clock in/out, volunteer comment log, and volunteer time
card view capabilities. The system shall provide job request capability for supervisor. The system shall provide volunteer list, job assignment, requested task list. The system shall provide Person Information Management module, which is a sharing
module among team 1, 2, and 3 about personnel information.4. The development team collaborates with team 1 and team 2 to discuss about shared
module implementation in CSC. 5. Team 0, or integration team, has been formed to resolve issues among team 1, 2, and 3.
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/081
Life Cycle Plan (LCP) Version 9.0
6. Client, maintainer and Team 0-3 will collaborate with the development team throughout the software development life cycle
7. All project artifacts must follow the LeanICM Guideline.
2.Milestones and Products
2.1 Overall StrategyOverall strategy for developing the California Science Center (CSC) Volunteer Tracking System is scheduled using the Independent Variable (SAIV) strategy since the project duration has been defined to fit the class schedule. With this strategy, the team is going to prioritize all capabilities and develop them in increments. In the first increment, the team will develop all the essential, or must-have, capabilities, and in the next increments, the team will develop lower-priority features based on time limitation. The schedule for this project is 24 weeks, which is divided into 2 12-week periods: Fall semester (CSCI577a) and Spring semester (CSCI577b). The process model implemented in this project is the Incremental Commitment Model, which will mainly emphasize on stakeholders’ commitment and risk analysis.
The project type is a custom development project as we need to develop a system in which complies with the CSC intranet infrastructure and architecture as well as the CSC template for user interface.
The process model includes the following key milestones: Architecture Commitment Review (ACR) Development Commitment Review (DCR) Rebaselined Development Commitment Review (RDCR) Core Capability Drive-through (CCD) Transition Readiness Review (TRR) Operations Commitment Review (OCR)
The development period can be categorized as follows:
Valuation and Architecting phasesDuration: Fall 2006 in CSCI577a subject and beginning of Spring 2008 Concept: Conducting WinWin negotiation process. Identifying project operational concept, system and software requirement, system and software architecture, and life-cycle plan. Prioritizing the capabilities. Conducting investment and feasibility analysis. Implementing software prototype.
o Valuation phaseDeliverables: WikiWinWin negotiation report, Initial prototype, Architecting Commitment PackageMilestone: Architecting Commitment Review
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/082
Life Cycle Plan (LCP) Version 9.0
Strategy: At least one Incremental Commitment Cycleo Architecting phase
Deliverables: Updated Wiki WinWin negotiation report, Updated prototype, Development Commitment PackageMilestone: Development Commitment Review Strategy: At least one Incremental Commitment Cycle
o Rebaselined Architecting phaseDeliverables: Rebaselined WinWin negotiation report, Updated Prototype, Rebaselined Development Commitment Package Milestone: Rebaselined Development Commitment Review Strategy: At least one short Incremental Commitment Cycle
Development and Operation phases Duration: Spring 2007 in CSCI577b subjectConcept: There are 2 increments in the Development phase. All core capabilities are developed in the first increment and deployed in the second increment, while the lower priority capabilities will be developed in the second increment. Furthermore, the development team has to prepare for transitioning, testing, and installing the system. In the operation phase, the development team delivers the system and ensures the quality of work product.
o Development phase - Increment 1 Deliverables: Executable core capabilities, Operations Commitment Package, Construction SetEnding Milestone: Core Capability Drive-through Strategy: One Incremental Commitment Cycle
o Development phase - Increment 2Deliverables: Executable system, Construction Set, Support and Transition SetMilestone: Transition Readiness ReviewStrategy: One Incremental Commitment Cycle
o Operation phaseDeliverables: System Installation, Operations Commitment Package, Support and Transition SetMilestone: Operations Commitment ReviewStrategy: One Incremental Commitment Cycle
2.2 PhasesFollowing is the list of major milestones of the project
Table 1: Project Milestones
Milestone DateArchitecture Commitment Review 10/16/2006Development Commitment Review 11/27/2006
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/083
Life Cycle Plan (LCP) Version 9.0
Rebaselined Development Commitment Review 02/07/2007Core Capability Drive through 02/28/2007Transition Readiness Review 04/10/2007Operations Commitment Review 04/24/2007Project Release 05/05/2007
For the most recent project schedule, it can be found in at:http://greenbay.usc.edu/csci577/spring2007/projects/team3/PR/index.html
2.3 Project Deliverables
2.3.1 Valuation Phase
Table 2: Artifact deliverables in Valuation Phase
Artifact Due date Format MediumOperational Concept Description (OCD) Early Section
09/18/2006 .doc, .pdf Soft copy
Evaluation of OCD Early Section 09/27/2006 .xls Soft copyInitial Prototype 09/29/2006 .doc, .pdf Soft copyWiki WinWin Report 10/02/2006 .doc, .pdf Soft copyEvaluation of Initial Prototype 10/04/2006 .xls Soft copyCore Architecting Commitment Package Operational Concept Description System and Software Requirements
Definition Supporting Information Document
10/04/2006 .doc, .pdf Soft copy
Evaluation of Core Architecting Commitment Package
10/09/2006 .doc Soft copy
Draft Architecting Commitment Package Operational Concept Description System and Software Requirements
Definition System and Software Architecture
Description UML Model Life Cycle Plan Feasibility Rationale Description Supporting Information Document
10/11/2006 .doc, .pdf, .zip
Soft copy
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/084
Life Cycle Plan (LCP) Version 9.0
Respond to Evaluation of Core Architecting Commitment Package
10/16/2006 .xls, .doc Soft copy
Evaluation of Draft Architecting Commitment Package
10/16/2006 .xls Soft copy
Architecting Commitment Package Operational Concept Description System and Software Requirements
Definition System and Software Architecture
Description UML Model Life Cycle Plan Feasibility Rationale Description Supporting Information Document
10/23/2006 .doc, .pdf, .zip
Soft copy
Quality Management Plan – I 10/23/2006 .doc, .pdf Soft copyResponse to Draft Architecting Commitment Package Evaluation
10/25/2006 .xls, .doc Soft copy
Evaluation of Architecting Commitment Package
10/30/2006 .xls Soft copy
Response to Architecting Commitment Package Evaluation
11/06/2006 .xls, .doc Soft Copy
Project Effort Every Monday Text ER systemProject Plan Every Wednesday .mpp, .pdf Soft copyProgress Report Every Wednesday .xls Soft copyRisk Analysis Every Wednesday Text DART systemClient’s Meeting Notes After the meeting .doc, .pdf Soft copy
All of the artifacts in Valuation phase can be found on the team website.http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCO/index.html
2.3.2 Architecting Phase
Table 3: Artifact Deliverables in Architecting Phase
Artifact Due date Format MediumUpdated Wiki Win-Win Report 11/08/2006 .doc, .pdf Soft copyQuality Management Plan –II 11/10/2006 .doc, .pdf Soft copyDraft Development Commitment Package Operational Concept Description System and Software
Requirements Definition System and Software Architecture
Description
11/20/2006 .doc, .pdf, .zip
Soft copy
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/085
Life Cycle Plan (LCP) Version 9.0
UML Model Life Cycle Plan Feasibility Rationale Description Supporting Information
DocumentEvaluation of Draft Development Commitment Package
11/27/2006 .xsl Soft copy
Development Commitment Package Operational Concept Description System and Software
Requirements Definition System and Software Architecture
Description UML Model Life Cycle Plan Feasibility Rationale Description Supporting Information
Document
12/04/2006 .doc, .pdf, .zip
Soft copy
Respond to Draft Development Commitment Package Evaluation
12/04/2006 .xls, .doc Soft copy
Rebaselined Development Commitment Package Operational Concept Description System and Software
Requirements Definition System and Software Architecture
Description UML Model Life Cycle Plan Feasibility Rationale Description Supporting Information
Document
02/02/2007 .doc, .pdf, .zip
Soft copy
Respond to Rebaselined Development Commitment Package Evaluation
02/07/2007 .xls, .doc Soft copy
Evaluation of Rebaselined Development Commitment Package
02/09/2007 .xsl Soft copy
Project 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
All of the artifacts in Architecting phase can be found on the team website.http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/index.html
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/086
Life Cycle Plan (LCP) Version 9.0
2.3.3 Development Phase
Table 4: Artifact deliverables in Development Stage
Artifact Due date Format MediumConstruction Set #0 Quality Management Plan Iteration Plan Acceptance Test Plan and Cases Peer Review Plan
02/02/2007 .doc, .pdf Soft copy
Evaluation of Construction Set #0 02/16/2007 .doc, .pdf Soft copyOperations Commitment Package Operational Concept Description System and Software
Requirements Definition System and Software Architecture
Description UML Model Life Cycle Plan Feasibility Rationale Description Supporting Information
Document
03/02/2007 .doc, .pdf, .zip
Soft copy
Construction Set #1 Quality Management Plan Iteration Plan Acceptance Test Plan and Cases Peer Review Plan Transition Plan Peer Review Report Acceptance Test Procedure and
Results Iteration Assessment Report
03/02/2007 .doc, .pdf Soft copy
Evaluation of Construction Set #1 03/16/2007 .doc, .pdf Soft copySupport and Transition Set Draft Transition Plan User Manual Support Plan Training Material Regression Test Package Packaged Tools and Procedure
04/06/2007 .doc, .pdf Soft copy
Evaluation of Support and Transition Set
04/20/2007 .doc, .pdf Soft copy
Project Effort Every Monday Text ER systemProject Plan Every Wednesday .mpp, .pdf Soft copy
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/087
Life Cycle Plan (LCP) Version 9.0
Progress Report Every Wednesday .xls Soft copyRisk Analysis Every Wednesday Text DART system
All of the artifacts in Development phase can be found on the team website.http://greenbay.usc.edu/csci577/spring2007/projects/team3/IOC/index.html
2.3.4 Operation Phase
Table 5: Artifact Deliverables in Operation Phase
Artifact Due date Format MediumSupport and Transition Set Transition Plan User Manual Support Plan Training Material Regression Test Package Packaged Tools and Procedure
04/27/2007 .doc, .pdf Soft copy
Operations Commitment Package Operational Concept Description System and Software
Requirements Definition System and Software Architecture
Description UML Model Life Cycle Plan Feasibility Rationale Description Supporting Information
Document
05/02/2007 zip, .doc, .pdf
Soft copy
Product Archiving Source Code Files Component Executables Release Description
05/02/2007 .zip, .doc, .pdf
Soft copy
All of the artifacts in operation phase can be found on the team website.http://greenbay.usc.edu/csci577/spring2007/projects/team3/IOC/index.html
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/088
Life Cycle Plan (LCP) Version 9.0
3.Responsibilities
3.1 Overall SummaryStakeholders are assigned with different roles. Each role has different tasks and responsibilities during the development of the project. This table shows responsibilities for role during different phases of the project.
Table 6: Stakeholder responsibilities during software life cycle
Role Valuation Architecting Development OperationUser Articulate win
conditions and operation concept
Provide project-related information
Participate in the WinWin negotiation, weekly meeting, and commitment review
Commit to the agreed project progress
Provide project-related information and feedback
Participate in weekly meeting and commitment review
Commit to the agreed project progress
Review and test the product and provide feedback as appropriate
Participate in weekly meeting and commitment review
Commit to the agreed project progress
Test and deploy the product in operational environment
Commit to the agreed project result
Client Articulate win conditions and operation concept
Provide information
Participate in the WinWin negotiation, weekly meeting, and commitment review
Commit to the agreed project progress
Track system progress
Coordinate with user, maintainer and developer
Provide information and feedback
Participate in weekly meeting and commitment review
Commit to the agreed project progress
Track system progress
Coordinate with user, maintainer and developer
Review and test the product
Participate in weekly meeting and commitment review
Commit to the agreed project progress
Test and deploy the product in operational environment
Support system’s transition
Coordinate with user, maintainer and developer
Receive training for the new system
Provide training for regular users
Commit to the agreed project result
Maintainer Articulate win conditions and operation concept
Provide information
Participate in the
Provide information and feedback
Participate in weekly meeting and commitment
Review and test the product
Prepare operational environment
Participate in weekly meeting
Test and deploy the product in operational environment
Receive training for the new system
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/089
Life Cycle Plan (LCP) Version 9.0
WinWin negotiation, weekly meeting, and commitment review
Commit to the agreed project progress
review Commit to the
agreed project progress
and commitment review
Commit to the agreed project progress
Provide training for users
Provide training other users
Maintain the system
Commit to the agreed project result
Developer Gather all project related information and transformed into requirement specification, operational concepts and initial architecture
Develop project plan and investment analysis
Initiate and complete Win-Win negotiation.
Coordinate with clients
Develop prototype Require to attend
WinWin negotiation and all reviews, and weekly meeting.
Commit to the agreed project progress
Refine architecture, prototype, and design.
Develop project artifacts to meet milestone requirements
Mitigate risks Plan for testing Update project
progress with client Commit to the
agreed project progress
Attend weekly meeting and commitment review
Develop the system based on the agreed architecture.
Conduct tests Prepare for support
and transition Develop project
artifacts to meet milestone requirements
Mitigate risks Update project
progress with client Commit to the
agreed project progress
Attend weekly meeting and commitment review
Conduct acceptance test
Perform system transition
Provide training for client and maintainer
Deliver all project artifacts to clients
Provide product support in operational environment to customer.
Commit to the agreed project progress
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0810
Life Cycle Plan (LCP) Version 9.0
3.2 By Phase / StageThese are the current responsibilities for each team member. Each one plays different roles and responsibilities. Since 2 of our team members are not going to continue developing CSC project in CSCI577b, their responsibility is N/A.
Table 7: Stakeholder responsibilities during each phase
Team Member / Role
Primary / Secondary ResponsibilityValuation Architecting Development Operation
Phongphan Danphitsanuphan:Project Manager
Primary Responsibility Manage project Coordinate with all
stakeholders Analyze project
investment Plan for
configuration Management
Secondary Responsibility Review artifacts
Primary Responsibility Manage project Coordinate with all
stakeholders Plan for testing Perform
configuration management
Secondary Responsibility Review artifacts
Primary Responsibility Manage project Coordinate with all
stakeholders Plan for project
transition, and support
Secondary Responsibility Maintain
configuration management
Primary Responsibility Manage project Coordinate with all
stakeholders Perform final testSecondary Responsibility Provide training
Charlie Lormanometee:Quality Assurance/ Life Cycle Planner
Primary Responsibility Coordinate with
teams 1, 2 Generate project
plan and cost estimation
Assure high quality of the project
Review project artifacts
Secondary Responsibility Coordinate with
team members
Primary Responsibility Coordinate with
teams 1, 2 Update project plan
and cost estimation Assure high quality
of the project Review project
artifactsSecondary Responsibility Plan for testing Coordinate with
team members
Primary Responsibility Coordinate with
teams 0,1, 2 Perform integration
test Review project
artifacts Prepare for project
transition and support
Secondary Responsibility Prepare for training
Primary Responsibility Coordinate with
teams 0,1, 2 Finalize all project
documentsSecondary Responsibility Provide initial
support
Deepak Pandey:System Analyst / Assistant Shaper
Primary Responsibility Gather win
conditions Generate
requirements specification
Facilitate WinWin negotiation
Secondary Responsibility Define operational
Primary Responsibility Maintain
consistencies between win conditions and requirements
Verify prototypeSecondary Responsibility Review system
architecture
Primary Responsibility Prepare testing
environment Perform unit test Review project
artifactsSecondary Responsibility Maintain
configuration management
Primary Responsibility Prepare the
operational environment
Finalize all project documents
Secondary Responsibility Perform final test Provide initial
support
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0811
Life Cycle Plan (LCP) Version 9.0
concepts Review project
artifacts
Facilitate WinWin negotiation
Pongtip Aroonvatanaporn:Software Architect / Programmer
Primary Responsibility Define operational
concepts and initial system architecture
Analyze all possible COTS
Secondary Responsibility Develop prototype Coordinate with
teams 1, 2
Primary Responsibility Define system
architecture Generate UML
models Revise prototypeSecondary Responsibility Review
requirement specification
Coordinate with teams 1, 2
Primary Responsibility Develop software
modulesSecondary Responsibility Perform integration
testing Coordinate with
teams 0,1, 2
Primary Responsibility Prepare for system
release Provide initial
support Secondary Responsibility Prepare operational
environment Coordinate with
teams 0,1, 2
Natachart Laoteppitak:Software Architect / Programmer
Primary Responsibility Develop prototype Design architecting
frameworkSecondary Responsibility Analyze all possible
COTS
Primary Responsibility Define system
architecture Revise prototype Generate UML
modelsSecondary ResponsibilityInspection, OCD
Primary Responsibility Develop software
modules Integrate software
modules Secondary Responsibility Perform unit tests
Primary Responsibility Perform final test Provide initial
support Secondary Responsibility Prepare operational
environment
Ritesh Kothari:Tester / Programmer
Primary Responsibility Define operational
concepts Analyze investment
analysisSecondary Responsibility Analyze all possible
COTS
Primary Responsibility Maintain
consistencies between win conditions, requirements, and system architecture
Prepare test casesSecondary Responsibility Verify prototype
Primary ResponsibilityN/ASecondary ResponsibilityN/A
Primary ResponsibilityN/ASecondary ResponsibilityN/A
Amit Shah:Integrated & Independent validation and verification / Shaper
Primary Responsibility Shaping WinWin
negotiation Verify and validate
all project artifactsSecondary Responsibility Facilitate WinWin
negotiation
Primary Responsibility Verify and validate
all project artifacts Update WinWin
negotiationSecondary Responsibility Prepare acceptance
test cases
Primary Responsibility Verify and validate
all project artifacts Perform unit testsSecondary Responsibility Prepare final
project artifacts
Primary Responsibility Verify and validate
all project artifacts Perform acceptance
testSecondary Responsibility Prepare for project
releaseJerome WanIntegrated & Independent validation and verification / Quality Focal Point
Primary Responsibility Verify and validate
all project artifactsSecondary Responsibility
Primary Responsibility Verify and validate
all project artifacts Develop Quality
Management Plan
Primary Responsibility N/ASecondary Responsibility N/A
Primary Responsibility N/ASecondary Responsibility N/A
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0812
Life Cycle Plan (LCP) Version 9.0
Facilitate WinWin negotiation
Shaping WinWin negotiation
Secondary Responsibility Prepare acceptance
test casesRaul Pereyra:User
Primary Responsibility Articulate existing
and new system operational concepts
Express win conditions
Secondary Responsibility Provide feedback to
development team
Primary Responsibility Provide feedback
about prototypeSecondary Responsibility Provide project data
Primary Responsibility Provide feedback
about developed modules
Secondary Responsibility Provide necessary
support
Primary Responsibility Provide feedback
about developed modules
Get trainedSecondary Responsibility Prepare for training
to others
Vincent Tsan:Maintainer
Primary Responsibility Articulate existing
systems win conditions, and operational concepts
Secondary Responsibility Provide feedback to
development team
Primary Responsibility Provide feedback
about prototypeSecondary Responsibility Provide project data
Primary Responsibility Prepare the
operational environment
Secondary Responsibility Provide necessary
support
Primary Responsibility Provide the
operational environment
Maintain the operational system
Secondary Responsibility Get trained
Table 8: Role and required skills for 577b members
Developer and IV&V Role SkillsPhongphan Danphitsanuphan,
Project Manager / Tester Project management, configuration management, and investment analysis, symfony
Charlie Lormanometee Life cycle planner/QA Project coordination,Quality Management, COCOMO, MS project, symfony
Pongtip Aroonvatanaporn
System Architect/ Programmer
UML, RSA, PHP, MySQL, AJAX, PEAR, symfony
Natachart Laoteppitak Software Architect/ Programmer
UML, RSA, PHP, MySQL, AJAX, PEAR, symfony
Deepak Pandey System Analyst/ Tester Wiki WinWin, PHP, RSA, symfonyAmit Shah Quality Focal Point
PersonnelWiki WinWin, RSA, symfony
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0813
Life Cycle Plan (LCP) Version 9.0
Table 9: Authorized Stakeholder Representatives in CSCI577a
Stakeholders Category OrganizationPhongphan Danphitsanuphan,Charlie Lormanometee,Pongtip Aroonvatanaporn,Natachart Laoteppitak,Deepak Pandey,Ritesh Kothari
Developer University of Southern California
Amit Shah,Jerome Wan
IIV & V University of Southern California
Jeremy Stoller Client/ Customer California Science CenterRaul Pereyra User California Science CenterVincent Tsan Maintainer California Science Center
Table 10: Authorized Stakeholder Representatives in CSCI577b
Stakeholders Category OrganizationPhongphan Danphitsanuphan,Charlie Lormanometee,Pongtip Aroonvatanaporn,Natachart Laoteppitak,Deepak Pandey
Developer University of Southern California
Amit Shah Quality Focal Point Personnel University of Southern CaliforniaJeremy Stoller Client/ Customer California Science CenterRaul Pereyra User California Science CenterVincent Tsan Maintainer California Science Center
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0814
Life Cycle Plan (LCP) Version 9.0
4.Approach
4.1 Monitoring and ControlThe purpose of monitoring and control for California Science Center Volunteer Tracking System is to ensure the appropriate quality of software work products. Every team member is responsible for the quality of the product when it meets the deliverable date and milestones. The strategies for monitoring and control used in this project are the following:
1. Weekly Client Meeting Report This report informs all stakeholders about this content of each meeting. They can
track and open issue and other concerns from last meeting and prepare themselves for upcoming tasks and responsibilities.
2. Weekly Progress Report This allows stakeholder to keep track of the status of the project and thus
determine efficiency of the team contribution to the project.3. Weekly Effort Report
Weekly effort by individual is shown in number of hours. This can determine whether every team member has balance workload or not.
4. Project schedule ManagementGantt chart is prepared to determine tasks and responsibilities for each member.
This help monitor and control project plan and make everyone aware of upcoming dateline and critical issue.
5. Risk management and mitigation (DART) Risk is identified and prioritized. It can be used toward risk mitigation and
prevention. Therefore, it helps project from making major changes, which effects in the increase of project schedule and effort.
6. Software Cost Estimation (UCS COCOMO tool) Estimate schedule and effort is calculated for the completion of the project
7. Regular Team meeting After class, developers hold short meeting to discuss about plans, issues, and
status of the project. 8. Team 0 meeting
Team 0 is formed to monitor and control the integration between team 1, 2, and 3. Issues such as PHP framework and shared module are discussed and resolved during the meeting. This meeting is held every week. Additional team 0 meeting is scheduled by developers to discuss about other issues.
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0815
Life Cycle Plan (LCP) Version 9.0
4.1.1 Closed Loop Feedback Control
Closed loop feedback control involves monitoring progress and resource expenditures in planning, which are achieved through the Weekly Client Meeting, Progress report, and Effort report. If problem occurs, the team can plan and reschedule to resolve them shortly. In addition, it assesses in balancing out the workload for each team member. Team members meet frequently after class to distribute work and settle any uprising issues.
4.1.2 Reviews
There are many kinds of review conducted in the project life cycle. Reviews determine the maturity of the artifacts and readiness to continue to the next phase.
1. Review Board – At the end of each phase, the review board meeting is held to determine the readiness and commitment level of the project. Required participants are all critical stakeholders. There are 4 ARBs as follows:
a. Valuation Commitment Reviewb. Architecting Commitment Reviewc. Development Commitment Reviewd. Transition Readiness Review
2. Core Capability Drive through (CCD) – towards the end of the development phase, the development team presents the project’s core capabilities to the clients. The clients will conduct hands on review and testing the system.
3. Design Code Review – before transitioning the project to the client, the development team has to present the fully functional system to class staff in order to cross check between the developed system and the agreed architecture and requirements.
4. Configuration Management – It ensures completeness and conformance among artifacts as well as source code for each dateline. Developers are able to trace back to the previous versions artifacts, which allows them to have the ability to analyze and manage current version artifacts with better consistency. This is when at the same time as the Fagan’s inspection. Subversion is used in this project to build a version control system.
5. Peer Review – Team members will help each other to check the correctness, completeness and consistency of all project artifacts.
6. Agile Internal Review – the purpose is to verify the artifacts to satisfy with the exit criteria. Agile internal review is conducted by the development team using Fagan’s inspection technique.
7. Agile Independent Review – this review is conducted by IIV&V student who acts as an independent reviewer.
4.1.3 Status Reporting
The team produces weekly progress reports, which identifies all the tasks in progress, the problems occurred, and the risk items associated with each task. It also includes plan to minimize or avoid issue, problem reports, and defects. Weekly individual report summarizes detail of hours work by individual in specific area of project. In addition, in the beginning of
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0816
Life Cycle Plan (LCP) Version 9.0
each weekly client meeting, all attendees must sign for approval of previous client meeting report to show that they are aware of the current status and progress of the project.
Progress report can be found at: http://greenbay.usc.edu/csci577/spring2007/projects/team3/PR/index.html
4.2 Methods, Tools and FacilitiesThe following tables will show the tools, methods and facilities that will be used in the project in preparing and operating project facilities:
Table 11: Tools being used in the project
Tools Usage ProviderMicrosoft Word 2003
Construct documents for all artifacts USC
Microsoft Project 2003
Create Gantt charts for Progress reports and LCP USC
Microsoft PowerPoint 2003
Create presentation for client meeting and ARB reviews
USC
Internet Explorer and Mozilla Firefox
Download course material and medium for communication among stakeholders.
USC
Wiki Win-Win tool Facilitate and support Win-Win negotiation USCRational Software Architect V6.0
Create UML, sequence diagram and other diagrams for SSAD
USC
Macromedia Dream Weaver
Develop team website. Involve in the create of the system using PHP
Developer
Adobe Acrobat 6.0 Documentation dissemination. DeveloperER and iCard System
Keep track of project effort USC
DART tools Assess and mitigate risks in the system development life cycle
USC
Red Ridge 3.0 Provide examples for user interface and system functionality. It is helpful in the development of prototype.
CSC
PEAR A framework and distribution system for reusable PHP components
Open source
Symfony A web application framework for PHP projects Open sourceEclipse 3.3 An open development platform Open sourceSubversion Version control system is implemented to maintain
artifact integrity and traceability. Open source
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0817
Life Cycle Plan (LCP) Version 9.0
5.ResourcesThis section describes the result of using COCOMO II tool to estimate cost for the project development in terms of effort and schedule. Since we are using SAIV-Schedule As Independent Variable, the estimates will tell us the effort required for the given project specification.
Estimated 577a Effort: 8 team members at 14 hrs/week for 12 weeks
Total estimated Effort: 1344 hours
Estimated 577b Effort: 6 at 14 hrs/week for 12 weeks
Total estimated Effort: 1008 hours
Total estimated 577 Effort:2352 hours
The following are conditions applied for estimating the cost of the California Science Center Volunteer Tracking System:
1. Project schedule is 24 weeks, 12 weeks each in 577a and 577b.2. Zero monetary budget 3. There are 8 developers in 577a and 6 developers in 577b4. There are 5 modules in the project
a. Volunteer candidate module – online application form for volunteer candidateb. Volunteer portal module – volunteer clock in/out, comment log, and view
history (clock in/out)c. Supervisor module – online job request form for supervisord. Volunteer management module – volunteer list, job assignment, and job request
liste. Personnel Information Management module – shared personnel information
database among team 1, 2, and 3 f. Report and Certificate Generation- generate Volunteer’s report and certificate
5. Most modules use PHP, JavaScript language.
The rationale for choosing the values of the scale factors is discussed below:
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0818
Life Cycle Plan (LCP) Version 9.0
Table 12: Rationale for Project Scale Factors
Scale Factor Value RationalePREC NOMINAL The development team have somewhat unprecedented
experience with this type of online application but need to learn about the new technology that client asked to implement in this project
FLEX LOW Need for conformance with Team 1, 2 and the client has specific request for development framework
RESL NOMINAL Around 60 percent of top software architects available to project and there are 2-4 risk items, which are most critical. Schedule and budget are fixed.
TEAM HIGH All team members meet up on regular basis and they are all willing to spend 14 hours per week on this project throughout the entire life cycle.
PMAT NOMINAL The development team follows Incremental Commitment Model guideline, which is CMM level 2 maturity level
The rationale for Scale Factors of each module is discussed below:
Table 13: Rationale for Cost Drivers of Module 1-Volunteer candidate module
Cost Driver Value RationaleRELY NOMINAL Some modules in this project depend on this module. Moderate
financial lostDATA LOW Volunteer candidate module is essential to the system but the
data/program size ratio less than 10 d/p and the database size is not too big hence it does not require a large amount of test data.
CPLX NOMINAL This module contains simple widget, basic math and statistical routine, simple input output process, and simple structural changes.
RUSE LOW This module is not intended to be reused in the projectDOCU NOMINAL This module requires some moderate amount of documentationTIME NOMINAL The percentage of available execution time expected to be used
by the system is less than 50%STOR NOMINAL This module does not require large amount of storage at
execution time.PVOL LOW The major change of the platform could happen every 12 monthsACAP HIGH The analysts are able analyze, design, communicate, and
cooperate very well. PCAP HIGH Programmers are capable and efficient. They are able to
communicate and cooperate very well. PCON HIGH Six of eight team members continue to CSCI577bAPEX NOMINAL The average experience of the team members for this online
application form is about one year.
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0819
Life Cycle Plan (LCP) Version 9.0
PLEX LOW The average experience of the team members for this PEAR/Symfony is less than one year.
LTEX NOMINAL The average experience of the team members for PHP is about one year.
TOOL LOW The tools are moderately integrated and provide various functionalities
SITE VERY HIGH
Six of eight team members are on campus, only two team members are in different city
SCED NOMINAL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester
Table 14: Rationale for Cost Drivers of Module 2-Volunteer portal module
Cost Driver Value RationaleRELY NOMINAL Failure of this module affects other modules and would cause
moderate financial lost.DATA NOMINAL Volunteer portal module is essential to the system but the
data/program size ratio less than 10 d/p and the database size is not too big hence it does not require a large amount of test data
CPLX NOMINAL This module contains simple widget, basic math and statistical routine, simple input output process, and simple structural changes.
RUSE LOW This module is not intended to be reused in the projectDOCU NOMINAL This module requires some moderate amount of documentationTIME HIGH The percentage of available execution time expected to be used
by the system is about 70%STOR NOMINAL This module does not require large amount of storage at
execution time.PVOL LOW The major change of the platform could happen every 12 monthsACAP HIGH The analysts are able analyze, design, communicate, and
cooperate very well. PCAP HIGH Programmers are capable and efficient. They are able to
communicate and cooperate very well. PCON HIGH Six of eight team members continue to CSCI577bAPEX NOMINAL The average experience of the team members for this online
application form is about one year. PLEX LOW The average experience of the team members for this
PEAR/Symfony is less than one year.LTEX NOMINAL The average experience of the team members for PHP is about
one year.TOOL NOMINAL The tools are moderately integrated and provide various
functionalitiesSITE VERY
HIGHSix of eight team members are on campus, only two team members are in different city
SCED NOMINAL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0820
Life Cycle Plan (LCP) Version 9.0
Table 15: Rationale for Cost Drivers of Module 3-Supervisor module
Cost Driver Value RationaleRELY NOMINAL Failure of this module affects other module but moderate
financial lost.DATA LOW Supervisor module requires little amount of testing data CPLX NOMINAL This module contains simple widget, basic math and statistical
routine, simple input output process, and simple structural changes.
RUSE LOW This module is not intended to be reused in the projectDOCU NOMINAL This module requires some moderate amount of documentationTIME NOMINAL The percentage of available execution time expected to be used
by the system is about 50%STOR NOMINAL This module does not require large amount of storage at
execution time.PVOL LOW The major change of the platform could happen every 12 monthsACAP HIGH The analysts are able analyze, design, communicate, and
cooperate very well. PCAP HIGH Programmers are capable and efficient. They are able to
communicate and cooperate very well. PCON HIGH Six of eight team members continue to CSCI577bAPEX NOMINAL The average experience of the team members for this online
application form is about one year. PLEX LOW The average experience of the team members for this
PEAR/Symfony is less than one year.LTEX NOMINAL The average experience of the team members for PHP is about
one year.TOOL NOMINAL The tools are moderately integrated and provide various
functionalitiesSITE VERY
HIGHSix of eight team members are on campus, only two team members are in different city
SCED NOMINAL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester
Table 16: Rationale for Cost Drivers of Module 4-Volunteer Management module
Cost Driver Value RationaleRELY NOMINAL Failure of this module affects other module but moderate
financial lost.DATA HIGH Volunteer management module is essential to the system but the
data/program size ratio less than 10 d/p and the database size is not too big hence it does not require a large amount of test data
CPLX NOMINAL This module contains simple widget, basic math and statistical routine, simple input output process, and simple structural changes.
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0821
Life Cycle Plan (LCP) Version 9.0
RUSE LOW This module is not intended to be reused in the projectDOCU NOMINAL This module requires some moderate amount of documentationTIME NOMINAL The percentage of available execution time expected to be used
by the system is about 50%STOR NOMINAL This module does not require large amount of storage at
execution time.PVOL LOW The major change of the platform could happen every 12 monthsACAP HIGH The analysts are able analyze, design, communicate, and
cooperate very well. PCAP HIGH Programmers are capable and efficient. They are able to
communicate and cooperate very well. PCON HIGH Six of eight team members continue to CSCI577bAPEX NOMINAL The average experience of the team members for this online
application form is about one year. PLEX LOW The average experience of the team members for this
PEAR/Symfony is less than one year.LTEX NOMINAL The average experience of the team members for PHP is about
one year.TOOL NOMINAL The tools are moderately integrated and provide various
functionalitiesSITE VERY
HIGHSix of eight team members are on campus, only two team members are in different city
SCED NOMINAL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester
Table 17: Rationale for Cost Drivers of Module 5-Personnel Information Management module
Cost Driver Value RationaleRELY HIGH Team 1 and 2 have to share this module, so failure of this
module affects other modules with high financial lost.DATA NOMINAL Personnel Information Management module requires moderate
amount of testing data as well as execution timeCPLX NOMINAL This module contains simple widget, basic math and statistical
routine, simple input output process, and simple structural changes.
RUSE LOW This module is not intended to be reused in the projectDOCU NOMINAL This module requires some moderate amount of documentationTIME HIGH The percentage of available execution time expected to be used
by the system is about 70%STOR NOMINAL This module does not require large amount of storage at
execution time.PVOL LOW The major change of the platform could happen every 12 monthsACAP HIGH The analysts are able analyze, design, communicate, and
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0822
Life Cycle Plan (LCP) Version 9.0
cooperate very well. PCAP HIGH Programmers are capable and efficient. They are able to
communicate and cooperate very well. PCON HIGH Six of eight team members continue to CSCI577bAPEX NOMINAL The average experience of the team members for this online
application form is about one year. PLEX LOW The average experience of the team members for this
PEAR/Symfony is less than one year.LTEX NOMINAL The average experience of the team members for PHP is about
one year.TOOL NOMINAL The tools are moderately integrated and provide various
functionalitiesSITE VERY
HIGHSix of eight team members are on campus, only two team members are in different city
SCED NOMINAL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester
Table 18: Rationale for Cost Drivers of Module 6-Report and Certificate Generation
Cost Driver Value RationaleRELY NOMINAL Failure of this module affects other module but moderate
financial lost.DATA HIGH Report and Certificate Generation module is essential to the
system but the data/program size ratio less than 10 d/p and the database size is not too big hence it does not require a large amount of test data
CPLX NOMINAL This module contains simple widget, basic math and statistical routine, simple input output process, and simple structural changes.
RUSE LOW This module is not intended to be reused in the projectDOCU NOMINAL This module requires some moderate amount of documentationTIME NOMINAL The percentage of available execution time expected to be used
by the system is about 50%STOR NOMINAL This module does not require large amount of storage at
execution time.PVOL LOW The major change of the platform could happen every 12 monthsACAP HIGH The analysts are able analyze, design, communicate, and
cooperate very well. PCAP HIGH Programmers are capable and efficient. They are able to
communicate and cooperate very well. PCON HIGH Six of eight team members continue to CSCI577bAPEX NOMINAL The average experience of the team members for this online
application form is about one year. PLEX LOW The average experience of the team members for this
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0823
Life Cycle Plan (LCP) Version 9.0
PEAR/Symfony is less than one year.LTEX NOMINAL The average experience of the team members for PHP is about
one year.TOOL NOMINAL The tools are moderately integrated and provide various
functionalitiesSITE VERY
HIGHSix of eight team members are on campus, only two team members are in different city
SCED NOMINAL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester
Following is the result of COCOMO estimation based on discussed cost drivers and scale factors settings.
Figure 1: COCOMO Estimation Result of 6 modules
Using COCOMO II to estimate cost for the project, the pessimistic effort is 12.3. We have to divide 1.67 to convert into CSCI577 developer effort (12.3/1.67) = 7.36.
Since we are an 8-person team including off campus students, it seemed highly likely that we will be able to finish the project in time.
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0824
Life Cycle Plan (LCP) Version 9.0
However, in CSCI577b, two students did not continue on the project, so we selected to move Report and Certificate Generation Module from core capability to add-on capability. If we have enough time, we will complete this module. As you can see from the following figure, the pessimistic effort estimation is 10.2. This means that the project could be done with (10.2 /1.67 = 6.1) 6.1, or a 6-person team.
Figure 2: COCOMO Estimation Result of 5 modules
COCOMO model can be found at the following URL:http://greenbay.usc.edu/csci577/spring2007/projects/team3/ABS/ COCOMO_AsBuilt_S07b_T03_V8.0.est
LCP_AsBuilt_S07b_T03_V9.0 Version date: 05/16/0825