THE ACIC PROJECT PLAN

8.4 THE ACIC PROJECT PLAN

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

graphics/08fig01.gif

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.

 



Software Project Management in Practice
Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It
ISBN: 0596008015
EAN: 2147483647
Year: 2005
Pages: 83
Authors: Michael Jang

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net