This section presents the project plan for our case study, the ACIC project. The first section of the PMP gives the main players, milestones, and an overview of the project. (Chapter 4 explains how the schedule and milestones were determined.)
Section 2 contains details about planning. First, it lists the output of process planning. The plan states that the "development process" will be used and gives the tailoring that has been done for the project. In this project the Rational Rose Unified Process (RUP) will be used because it is a commitment to the customer. In RUP, the main phases are inception, elaboration, construction, and transition. Elaboration and construction are usually done in iterations. In the elaboration phase, analysis and design are the primary tasks, whereas in the construction phase, coding and unit testing are the primary activities. The project will employ two elaboration iterations and three construction iterations. To accommodate this approach requires that the standard development process of Infosys be tailored. The tailoring notes specify the tailoring done to the standard process.
For requirements change management, the plan specifies where the change requests will be logged and the process of handling them. It also specifies that if any change request takes more than 2% of the total effort, it will be reestimated. For requirements traceability, it states that a tool will be used.
The subsection on effort estimation gives the effort estimates and the basis for estimation. (Chapter 4 discusses the estimation of the ACIC project.) Along with the effort estimate, it specifies the project schedule (which is the same as the milestones committed to the customer) and the people it needs to meet the schedule commitments. The people requirement is also specified by skill. The training plan for the team is also given, along with the criteria that will be used for someone to waive the training.
The subsection on the quality plan gives the quality goals and intermediate goals for defects. (Chapter 5 discusses the development of this plan.) Because the project has set higher goals for itself, the strategy for meeting those goals is also given, along with the reviews that the project aims to do.
The planning section also specifies the hardware and software resources that are needed and the risk management plan (discussed in Chapter 6).
The project tracking section (section 3) mentions that Microsoft Project (MSP) will be used for task scheduling, assignment, and status monitoring. BugsBunny, a tool developed in-house, will be used to track issues local to the project. The project manager is responsible for reviewing and ensuring resolution of these problems, except for the issues relating to the business manager. BugsBunny will also be used for tracking customer complaints and feedback. Status reports will be sent every two weeks, and the customer will receive a report at each milestone. Detailed analysis is planned at milestones. Escalation channels at both ends are established.
Section 4 specifies the team structure. The team is headed by the project leader (PL) (referred to elsewhere in this book as the project manager), who manages a defect prevention (DP) team, a module leader, and the configuration controller. The DP team is responsible for analyzing the defects and proposing solutions to prevent them. (Chapter 5 discusses DP planning, and Chapter 11 explains the execution of the DP activities. The role of the CC is discussed further in Chapter 9.) The team structure specifies that a software quality adviser is associated with the team but does not report to the PL. The plan also specifies the roles and responsibilities of each person on the team.
Project Management Plan for the ACIC Project
1. PROJECT SUMMARY
1.1 Project Overview
ACIC is a U.S.-based investment firm. This application has two components: first, a Brokerage Account Opening application on ACIC's Web site that will allow any Internet user to open a brokerage account with ACIC; second, an account opening and maintenance application, which is primarily for ACIC's representatives to open accounts for the applications received in paper format. This is an Intranet application. The application will provide features such as account history viewing and account balance, status, and activity information. This will allow ACIC to effectively evolve to a client/account servicing application in addition to being an account opening engine. This is an enhancement of an existing application; the earlier development was also done by Infosys.
Project Code | Project Name | Customer |
xxxxxxxxx | ACIC Project | ACIC Corporation |
Project Leader (PL) | Configuration Controller (CC) | Business Manager (BM) | Backup PL | Backup CC |
BB | SB | HR | BJ | HP |
Project Type | Platform | Number of Phases |
Development | Java, Win NT, DB2 | Four |
Project Start Date (including onsite, offshore) | Project End Date | Total Estimated Revenue | |
Onsite | Offshore |
|
|
April 3, 2000 | May 15, 2000 | Nov. 3, 2000 | US $ xxx,xxx |
Project and Customer Contact Personnel | |||
Name and Designation | Phone Number | Fax Number | E-mail ID |
Project Scope |
To provide an effective, efficient means of account maintenance activities To allow reps to access information To provide a complete picture to the client rep for account status, valuation, order status, and trade activity To increase the intelligence of the update process To provide an interface that can display required account history elements To provide the capability to close and reactivate an account |
Project's Value-add to the Customer |
This project will allow ACIC to effectively evolve to a client account servicing application in addition to being the account opening engine. |
Infosys Objectives |
Strengthen relationship with ACIC by delivering high-quality software on time. Become preferred vendor by developing expertise on ACIC products and systems. |
1.2 Commitments Made to the Customer
Sequence Number | Milestone Date | Milestones | Deliverables |
1 | 26 May 2000 | Inception: Requirements sign-off | Business analysis and requirements specifications, use case catalog, screens, iteration plan |
2 | 15 May 23 June 2000 | Elaboration: Iteration 1 | Sequence diagrams, class diagram, source code, plan for the next cycle |
3 | 26 June 7 July 2000 | Elaboration: Iteration 2 | Supplementary specifications, sequence diagrams, class diagram, architecture document, source code, iteration plan for the next cycle |
4 | 10 July 21 July 2000 | Construction: Iteration 1 | Source code, review reports, test reports, iteration plan for the next cycle |
5 | 20 July 28 July 2000 | Construction: Iteration 2 | Source code, review reports, test reports, iteration plan for the next cycle |
6 | 31 July 8 Aug 2000 | Construction: Iteration 3 | Source code, review reports, test reports, iteration plan for the next cycle, deployment plan for the product |
7 | 9 Aug 1 Sep 2000 | Integration testing phase | Test plans, test reports |
8 | 4 Sep 15 Sep 2000 | Onsite code delivery and setup | Code |
9 | 18 Sep 22 Sep 2000 | Acceptance test and production migration | Test reports |
10 | 18 Sep 29 Sep 2000 | Onsite reconciliation and regression test | Code |
11 | 2 Oct 26 Oct 2000 | Acceptance test | Test results |
12 | 27 Oct 3 Nov 2000 | Rollout and support | Project sign-off |
Other Commitments | |
Sequence Number | Commitments |
1 | This project will follow the Rational Unified Methodology (RUP). |
1.3 Assumptions
Assumptions Made while Planning |
Migration to Visual Age for Java 3.0 will not be done by this team. Intelligent update to business partners will be incorporated in only the maintenance part of the application and not in the "Account opening" engine. Qualified people will approve Rational Unified Process methodology for implementing this project. Changes in functional and technical requirements during the life cycle of the project may have an impact on the schedule. Any impact on cost or schedule due to these changes will be intimated to ACIC. ACIC reviewers will get seven days to approve a milestone document. If no comments are received within this time period, it will be considered as approved. |
2. PROJECT PLANNING
2.1 Project Processes
Standard Process Followed
The standard development process of Infosys will be followed. However, it will be enhanced with Rational Unified Process methodology (RUP), as it is a commitment. The development process will be tailored to match the RUP.
Tailoring Notes
Deviations from Standard Process | Added/Modified/Deleted | Reasons for Deviations |
Only those use cases that are going to be taken up in a particular iteration will be elaborated at that point in time. | Modified | Iteration-based development is being done. |
Development of logical object model will be done incrementally in the first few iterations. | Modified | Conformance to RUP methodology. |
Development of physical object model will be done incrementally in the first few iterations. | Modified | Conformance to RUP methodology. |
Physical database design may be refined in later iterations. | Modified | Conformance to RUP methodology. |
Development of unit test plan will be done in each iteration. | Modified | Iterative approach is being used. |
Logging of defects will be iteration-wise. | Modified | Iterative approach is being used. |
Requirement traceability will be done through the Requisite Pro tool. | Modified | Conformance to RUP methodology. |
No vision document and business case as we started with the Scope document, which serves the same purpose. | Modified | Deviation from RUP. |
Requirements Change Management Process
Change Requests Tracking |
Changes requested by customer will be logged in ChangeRequest.xls and analyzed for impact on the project. A change request form will be submitted to customer for approval. Change requests that are approved will be attached to the project contract as addenda. Major changes usually have an effort/delivery-on-time impact on the project. The customer needs to formally approve these. Because this is a short-duration project, if any one or a group of change requests takes more than 2% of the total estimated effort for the project, reestimation of the project schedule and effort will be done. |
Requirements Traceability
Requisite Pro tool will be used.
2.2 Estimated Size and Effort
Estimation Criteria | |
Program/Function (Use Case ) | Criteria |
Simple use case | 3 or fewer transactions |
Medium use case | 4 to 7 transactions |
Complex use case | > 7 transactions |
Use Case Number | Description | Complexity |
Use Case 1 | Navigate screen | Complex |
Use Case 2 | Update personal details | Medium |
Use Case 3 | Add address | Medium |
Use Case 4 | Update address | Complex |
Use Case 5 | Delete address | Complex |
Use Case 6 | Add telephone number | Medium |
Use Case 7 | Update telephone number | Complex |
Use Case 8 | Delete telephone number | Complex |
Use Case 9 | Add e-mail | Medium |
Use Case 10 | Update e-mail | Medium |
Use Case 11 | Delete e-mail | Medium |
Use Case 12 | Update employment details of a party | Medium |
Use Case 13 | Update financial details of a party | Medium |
Use Case 14 | Update details of an account | Medium |
Use Case 15 | Maintain activities of an account | Complex |
Use Case 16 | Maintain memos of an account | Simple |
Use Case 17 | View history of party details | Complex |
Use Case 18 | View history of account details | Complex |
Use Case 19 | View history of option level and service options | Simple |
Use Case 20 | View history of activities and memos | Simple |
Use Case 21 | View history of roles | Complex |
Use Case 22 | View account details | Simple |
Use Case 23 | View holdings of an account | Complex |
Use Case 24 | View pending orders of an account | Complex |
Use Case 25 | Close/reactivate account | Simple |
Use Case 26 | Make intelligent update to business partner of ACIC | Complex |
Estimated Build Effort | |||
Program/Function | Effort (Based on Data from Earlier Project) | Number of Units | Total Build Effort (in person-days) |
Simple use cases | 1 Person-days | 5 | 5 |
Medium use cases | 5 Person-days | 9 | 45 |
Complex use cases | 8 Person-days | 12 | 96 |
Total |
|
| 146 |
Phase-wise Effort Estimate | ||
Activity/Phase | Person-days | % of total effort |
Requirements | 50 | 10 |
Design | 60 | 12 |
Build | 146 | 29 |
Integration testing | 35 | 7 |
Regression testing | 10 | 2 |
Acceptance testing | 30 | 6 |
Project management | 75 | 15 |
Configuration management | 16 | 3 |
Training | 50 | 10 |
Others | 40 | 6 |
Estimated effort | 501 | 100% |
Effort Estimate by Iterations | Person-days | % of Total Effort |
Project initiation | 25 | 5 |
Inception phase | 24 | 5 |
Elaboration phase: Iteration 1 | 45 | 9 |
Elaboration phase: Iteration 2 | 34 | 7 |
Construction phase: Iteration 1 | 27 | 5 |
Construction phase: Iteration 2 | 24 | 5 |
Construction phase: Iteration 3 | 21 | 4 |
Transition phase | 110 | 22 |
Project closure | 10 | 2 |
Project management | 75 | 15 |
Configuration management | 16 | 3 |
Training | 50 | 10 |
Others | 40 | 8 |
Total estimated effort | 501 Person-days | 100% |
2.3 Schedule
Specified as milestones in the section on Commitments to the Customer.
2.4 People
People by Role | ||
Role | Required Number | Date |
PL | 1 | 4 May 2000 |
Onsite coordinator | 1 ( 50% time ) | 4 May 2000 |
Module leader | 1 | 15 May 2000 |
Developers | 3 | 15 May 2000 |
Developers | 1 | 17 July 2000 |
Developers | 1 | 1 August 2000 |
Developers | 1 | 14 August 2000 |
Total | 9 (actually 8.5) |
|
People by Skill and Experience | |||
Area | Total # | 0 12 months' experience | > 12 months' experience |
Java | 7 | 7 | 0 |
DB2 | 2 | 0 | 2 |
Total | 9 | 7 | 2 |
People Requirement Plan | |||
Month | Offshore | Onsite | Total |
May 2000 | 4 | 1 (50%) | 5 |
June 2000 | 5 | 1 | 6 |
July 2000 | 5 | 1 | 6 |
Aug 2000 | 8 | 1 | 9 |
Sep 2000 | 7 | 2 | 9 |
Oct 2000 | 3 | 2 | 5 |
2.5 Development Environment
Hardware | Software |
NT Server | Win NT |
MainFrame | DB2 |
Intel PC | VisualAge for Java, Java, Win NT |
2.6 Hardware and Software Resources Required
Item Description | Required # | Date |
PCs with 128 RAM | 6 | 1 May 2000 |
1GB space on server | 1 | 1 May 2000 |
VisualAge for Java | 6 | 4 May 2000 |
DB2 | 6 | 4 May 2000 |
Rational Rose | 5 | 15 May 2000 |
Requisite Pro | 1 | 15 May 2000 |
2.7 Tools
Tools List | |
Tools to be developed in the project | None |
In-house tools to be used in the project | BugsBunny, WAR |
2.8 Training Plan
Training Area | Duration | Waiver Criteria |
Technical | ||
Java Language | 7 days | If already trained |
VisualAge for Java | 3days | Exposed as part of initial training |
Java Applets | 4 hrs | If already trained |
Java Swing | 4 hrs | If already trained |
Persistence Builder | 4 hrs | If already trained |
Rational Rose and Requisite Pro | 8 hrs | Mandatory |
OOAD | 1day | If already trained |
Business Domain | ||
System appreciation | 7 days | If already trained |
Process-Related | ||
Quality system | 3 hrs | If already trained |
Configuration management | 2 hrs | If already trained for CC. For others, on-the-job training |
Group review | 4 hrs | If already trained |
Defect prevention | 4.5 hrs | Mandatory |
SPC tool | 4.5 hrs | If already trained |
RUP methodology | 2 hrs | Mandatory |
2.9 Quality Plan
Quality Goals
Project Quality Goals | |||
Goals | Value | Basis for Setting Goals | Org.-wide Norms |
Total number of defects injected | 145 | 0.033 defects/person-hour. This is 10% better than Synergy, which is 0.036 defects/person-hour. | 0.052 defects/person-hour |
Quality (acceptance defect density) | 5 | 3% or less of total estimated number of defects. | 6% of estimated number of defects |
Productivity | 57 | 3.4% productivity improvement over Synergy. | 50 |
Schedule | Delivery on time |
| 10% |
Cost of quality (in %) | 32% | 31.5% | 32% |
Estimates of Defects to Be Detected
Review/Testing Stage | Estimated Number of Defects to Be Detected | % of Defects to Be Detected | Basis for Estimation |
Requirements and design review | 29 | 20% | Referenced similar project estimations (Synergy) and PCB |
Code review | 29 | 20% | Referenced similar project estimations (Synergy) and PCB |
Unit testing | 57 | 40% | Referenced similar project estimations (Synergy) and PCB |
Integration and regression testing | 25 | 17% | Referenced similar project estimations (Synergy) and PCB |
Acceptance testing | 5 | 3% | Referenced similar project estimations (Synergy) and PCB |
Total estimated number of defects to be detected | 143 | 100% |
|
Strategy for Meeting Quality Goals
Strategy | Expected Benefits |
Do defect prevention using the standard defect prevention guidelines and process; use standards developed in Synergy for coding. | 10 20% reduction in defect injection rate and about 2% improvement in productivity |
Group review of program specs for first few/logically complex use cases. Group review of design docs/first time-generated code by project leader, developer, and one consultant. | Improvement in quality as overall defect removal efficiency will improve; some benefits in productivity as defects will be detected early |
Introduction of RUP methodology and implementing the project in iterations. Milestone analysis and defect prevention exercise will be done after each Iteration. | Approximately 5% reduction in defect injection rate and 1% improvement in overall productivity |
Reviews
Review Point | Review Item | Type of Review |
End of project planning | Project plan DCS set up Project schedule | Group review SQA review SQA review |
End of project planning | CM Plan | Group review |
End of 90% of requirements (This should be at the end of first elaboration iteration) | Business analysis and requirements specification document, Use Case catalog | Group review |
End of 90% design (This should be at the end of second elaboration iteration) | Design document, object model | Group review |
Beginning of each iteration | Iteration plans | One-person review |
End of detailed design | Complex/first time generated program specs incl. test cases, interactive diagrams | Group review |
After coding for first few programs | Code | Group review |
After self-testing of a process | Code | One-person review |
End of unit test plan | Unit test plan | One-person review |
Beginning of integration test | Integration test plan | Group review |
2.10 Risk Management Plan
Sequence Number | Risks | Probability | Impact | Risk Exposure | Mitigation Plan |
1 | Support from database architect and the database administrator of the customer. | 0.5 | 8 | 4 | Plan carefully for the time required from each of these groups and give enough prior notice. Onsite coordinator to work closely with these groups. |
2 | As RUP is being used for the first time, the understanding of the team may not be complete. | 0.9 | 3 | 2.7 | Work closely with experts in the R&D lab of Infosys. Keep the customer in the loop throughout the project and escalate for any schedule/effort deviations. Train the team on RUP methodology. |
3 | Personnel attrition: Team members might leave on short notice. | 0.3 | 7 | 2.1 | Assign tasks so that more than one person is aware of the units/use cases in the project. |
4 | Working with customer's mainframe DB2 over the link; link may not be as efficient as it is expected. | 0.1 | 8 | 0.8 | Do extra code reviews, desk checking, etc. to minimize the reliance on link. Escalate as soon as the link goes down. |
3. PROJECT TRACKING
3.1 Measurement Plan
Metric to Be Collected | Unit of Measurement | Tools Used |
Size | LOC, FP, S/M/C count | Line counters |
Effort | Person-days | WAR |
Defects | Number of defects | BugsBunny |
Schedule | Elapsed time | MSP |
3.2 Task Tracking
Activity | Procedure |
Task scheduling | The PL schedules tasks using MS Project. Refinement and rescheduling will be done when necessary. |
Task assignment | The latest schedule is made available to the team members. Once the schedule is uploaded to WAR-MSP system, the tasks will show in their respective WARs. |
Task status tracking | Task tracking is done daily. |
Project meeting | Once a week. |
Causal analysis meeting | After every iteration. |
3.3 Issues Tracking
Issue Types | Where Logged | Who Can Log | Who Reviews, When | When Escalated |
Onsite issues | IssueTracker.xls | Any member of the project | PL, daily | 2 days |
Customer issues | Issues Log.xls | Onsite team, PL | PL, daily | 2 days |
Business manager issues | Weekly Status report | BM | BM, PL weekly | 5 days |
Issues with support services | Request Tracker | Any team member | Support services, daily | 2 days |
3.4 Customer Feedback
Item | Logging and Tracking Process |
Customer feedback | The AM/PL gets the customer feedback. The BM files it. |
Customer complaints | Customer complaints received will be entered and tracked using CustomerComplaints.xls. |
3.5 Quality Tracking
Quality Activity | Action |
Defect tracking | Use DCS for logging defects and tracking them to closure. |
Reviews (requirements, high-level design, detailed design) | Check against project goals in quality plan. |
Code review | Check against limits for each program through SPC tool. |
Independent unit testing | Check against limits for each program through SPC tool. |
Integration testing/System testing | Check against project goals in quality plan. |
3.6 Review by Senior Management (BM)
Sequence Number | Item for Review | Frequency of Review |
1 | Schedule | Every version change |
2 | Project plan | When significant changes are made |
3 | Milestone report | End of milestones |
3.7 Status Reporting
Report To | Frequency |
Business manager | Weekly on Monday by e-mail |
Customer | Weekly on Monday |
3.8 Deviation Limits at Milestones
Actual vs Estimated of: | For the First Five Milestones | For the Rest of the Milestones |
Effort | 10% | 5% |
Schedule | 10% | 5% |
Defects | 20% | 20% |
3.9 Report to the Customer
Milestones reports and weekly status reports
Issues requiring clarifications
Escalation, if any
3.10 Report to the BM
Customer feedback
Milestones and weekly status reports
Issues requiring clarifications/attention
Escalation, if any
Number of requirement changes and estimated effort for them
Major changes in plan
3.11 Escalation Procedures
Escalate Where | Threshold Period | Name of the Person | Designation of the Person |
At ACIC | 3 days | Xxxx | Project manager |
At Infosys | 3 days | Xxxx | Account manager |
At Infosys | 3 days | Xxxx | Business manager |
4. PROJECT TEAM
4.1 Project Organization
4.2 Project Team
Sequence Number | Initials | Responsibility | Start Date | Expected End Date |
1 | BB | Project manager | 4 April 2000 | 3 November 2000 |
2 | KP | Onsite coordinator | 4 April 2000 | 3 November 2000 |
3 | BJ | Module leader, backup project lead | 15 May 2000 | 3 November 2000 |
4 | SP | Configuration controller | 22 May 2000 | 13 October 2000 |
5 | DD | Developer | 22 May 2000 | 29 September 2000 |
6 | HP | Developer, backup configuration controller | 22 May 2000 | 29 September 2000 |
7 | NA | Developer | 17 July 2000 | 3 November 2000 |
8 | SH | Developer | 1 August 2000 | 15 September 2000 |
9 | AL | Developer | 14 August 2000 | 31 August 2000 |
10 | JP | Developer | 1 September 2000 | 22 September 2000 |
11 | SDS | Account manager | 4 April 2000 | 3 November 2000 |
12 | SB | SQA | 15 May 2000 | 3 November 2000 |
4.3 Roles and Responsibilities
Role | Responsibilities |
Business manager (BM) | Resolve escalated issues Review project status Participate in critical technical reviews |
Customer | Review design Resolve escalated issues Acceptance test planning and testing |
Account manager (AM) | Customer satisfaction Business growth Project financial plan Interface with sales and marketing Training-related issues Employee-related issues |
Project manager (PM) | Project planning and scheduling Design Customer interaction Reviews Testing Reporting Task assignment and tracking Interact with software quality adviser from SEPG Ensure delivery as per contract Interface with other departments as per need Ensure open issues/customer complaints are closed properly Ensure project members are adequately trained |
Module leader (ML) | Design Development Testing Reporting |
Defect prevention (DP) team | Spread awareness in the team on defects and their prevention Analyze defect data Identify methods to reduce defect injection |
Developer (DV) | Detail design for use cases Development Unit testing and integration testing |
Configuration controller (CC) | Prepare the CM plan Manage the configuration as per the CM plan |
Software quality adviser (SQA) from the SEPG | Process consultancy Quality assurance (audits) Install measurement tools and train project personnel Participate in reviews of project plan and processes as necessary |
Onsite coordinator | Resolve any issues from customer/offshore Support during development |
5. REFERENCES
Omitted.
6. ABBREVIATIONS USED
Omitted.