LCP_LCA_F06a_T03_V2.0.doc - Software … · Web viewTools Usage Provider Microsoft Word 2003 Construct documents for all artifacts USC Microsoft Project 2003 Create Gantt charts for

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


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


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


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


2.1 Added table 5 Make clarification on role and skill

for existing and new members in 577b


3.0 Modified estimated COCOMO cost

driver Identify developer discontinuity and

recruited new comer


6.0 Updated 2 Updated 3,4, and 5 Updated COCOMO KLOC

Update for RLCA New & changed developer


6.2 Updated COCOMO Scale Factor and

Cost Drivers Added table 7

Taking uncertainties in to consideration

577b version


7.0 Update section 2.1 Update COCOMO

IOC Working Set#1 Reconstruct COCOMO module

according to the plan


7.3 Update delivery date Date assigned by Team 0


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


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


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


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


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


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



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



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


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


http://greenbay.usc.edu/csci577/spring2007/projects/team3/PR/index.html


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


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


http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCO/index.html


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


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


Rebaselined Development Commitment Package Operational Concept Description System and Software



Document

02/02/2007 .doc, .pdf, .zip

Soft copy

Respond to Rebaselined Development Commitment Package Evaluation


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


http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/index.html


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


Evaluation of Construction Set #0 02/16/2007 .doc, .pdf Soft copyOperations Commitment Package Operational Concept Description System and Software



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


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


Evaluation of Support and Transition Set


Project Effort Every Monday Text ER systemProject Plan Every Wednesday .mpp, .pdf Soft copy



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


Operations Commitment Package Operational Concept Description System and Software



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


http://greenbay.usc.edu/csci577/spring2007/projects/team3/IOC/index.html

http://greenbay.usc.edu/csci577/spring2007/projects/team3/IOC/index.html


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


Review and test the product and provide feedback as appropriate



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


Track system progress

Coordinate with user, maintainer and developer

Provide information and feedback



Track system progress


Review and test the product




Support system’s transition


Receive training for the new system

Provide training for regular users


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


Receive training for the new system



WinWin negotiation, weekly meeting, and commitment review


review Commit to the

agreed project progress

and commitment review


Provide training for users

Provide training other users

Maintain the system


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.


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


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


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.




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


stakeholders Plan for testing Perform

configuration management

Secondary Responsibility Review artifacts


stakeholders Plan for project

transition, and support

Secondary Responsibility Maintain



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


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


teams 0,1, 2 Perform integration

test Review project

artifacts Prepare for project

transition and support

Secondary Responsibility Prepare for training


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


Primary Responsibility Prepare the

operational environment

Finalize all project documents

Secondary Responsibility Perform final test Provide initial

support



concepts Review project

artifacts


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


all project artifacts Perform unit testsSecondary Responsibility Prepare final

project artifacts


all project artifacts Perform acceptance

testSecondary Responsibility Prepare for project

releaseJerome WanIntegrated & Independent validation and verification / Quality Focal Point


all project artifactsSecondary Responsibility


all project artifacts Develop Quality

Management Plan

Primary Responsibility N/ASecondary Responsibility N/A

Primary Responsibility N/ASecondary Responsibility N/A




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


about developed modules

Secondary Responsibility Provide necessary

support


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


about prototypeSecondary Responsibility Provide project data

Primary Responsibility Prepare the


Secondary Responsibility Provide necessary

support

Primary Responsibility Provide the


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



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



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.



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



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


http://greenbay.usc.edu/csci577/spring2007/projects/team3/PR/index.html


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:



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.



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


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




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




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.












Table 16: Rationale for Cost Drivers of Module 4-Volunteer Management module


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















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













Table 18: Rationale for Cost Drivers of Module 6-Report and Certificate Generation


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















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.



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


http://greenbay.usc.edu/csci577/spring2007/projects/team3/ABS/%20COCOMO_AsBuilt_S07b_T03_V8.0.est

http://greenbay.usc.edu/csci577/spring2007/projects/team3/ABS/%20COCOMO_AsBuilt_S07b_T03_V8.0.est

Documents

LCP_LCA_F06a_T03_V2.0.doc - Software … · Web viewTools Usage Provider Microsoft Word 2003 Construct documents for all artifacts USC Microsoft Project 2003 Create Gantt charts for