PROJECT ESTIMATE FOR EXTENDING THE PERFORCE DEFECT TRACKING INTEGRATION
Gareth Rees, Ravenbrook Limited, 2000-10-24
1. Introduction
This is a draft plan outlining the steps required to extend the Perforce
Defect Tracking Integration to work with a new defect tracking system,
together with a rough initial estimate of the effort and cost.
2. Project steps
These are the basic steps that the project will go through. The project
will use evolutionary delivery to meet the requirements, so these steps
will to some extent proceed in parallel, with appropriate feedback and
iteration when requirements change, or defects are discovered.
1. Define the goal.
2. Gather requirements.
3. Define architecture.
4. Detailed planning and design.
5. Implementation.
6. Testing.
3. Outline plan
See
for a general discussion of what's involved at each of these steps.
3.1. Goal definition
We establish your goals for the integration. The goals must answer
these questions:
1. Why are you integrating your defect tracker with Perforce?
2. What benefits will you get from the integration?
3. How will we know if the project succeeds?
3.2. Gathering requirements
We will select and interview potential users of the integration to
discover their requirements for integration.
The requirements will include functional requirements and attribute
requirements such as maintainability, portability, usability,
performance, robustness and so on. We will review the requirements
against the goals and agree them with you.
We expect the requirements for the new integration to be very similar to
the requirements for the Perforce Defect Tracking Integration project
. If this is the
case, then we expect to be able to reuse much of that project's
architecture, design, implementation, documentation and test code.
3.3. Define architecture
The project architecture is a document giving an overview of how the
project will meet the requirements.
We will also decide how the integration will be maintained and
supported.
3.4. Planning
The project plan is a list of versions we will deliver, the dates on
which they will be delivered and which requirements they will meet. The
delivered versions will probably consist of an alpha test version, to
check the requirements, a beta test version, to check the
implementation, and the first release.
At this stage we will be able to offer a budget for the whole project.
3.5. Design and implementation
3.6. Testing
There will be an alpha test to check that the requirements are correct.
If the requirements are sufficiently similar to the current Perforce
Defect Tracking Integration Project requirements then we may be able to
skip the alpha test.
There will be a beta test to check that the implementation is correct.
4. Estimation of effort
Effort usually divides up as follows: one third in steps 1 to 4, one
sixth in stage 5, and one half in stage 6 [Brooks 1995].
The estimates below are based on our expectation that the requirements
for the new integration are sufficiently similar to the requirements for
the Perforce Defect Tracking Integration Project that that project's
architecture, design, implementation and testing can be re-used. If
your requirements differ significantly, then it will be necessary to
make new estimates as the work will be significantly greater.
This table is a rough initial estimate, subject to change.
Initial meetings, goal definition and review 1w
Requirements interviews, definition and review 3w
Studying the defect tracker 2w
Detailed design and planning 2w
Implementation 4w
Unit and system tests 4w
Project management, tracking, and oversight by RB 4w
Alpha, beta programme 4w
Rework following alpha, beta testing 4w
--------------------------------------------------------------
Total 28w
The estimate for implementation and testing (16 weeks) falls into the
estimated range for extending the Perforce Defect Tracking Integration
to work with a new defect tracking system .
My base rate is $120/h, and Richard's is $160/h. We offer a discount of
20% for a project larger than one month of effort.
Given the above rough estimates of effort, the following table gives a
rough estimate of cost for the definition and requirements stages, and
for the whole project, assuming 35 hours of effort per week. I've
divided up the work into two stages: project definition and
requirements; and design, implementation and testing, so that you can
see how much it will cost to define the project and reach the point
where a budget can be determined.
Project definition and requirements stages
6 weeks of effort at $120/h $ 25200
Discount of 20% $- 5040
1 week of effort at $160/h $ 5600
Discount of 20% $- 1120
1 trip to the US at $2500 per trip $ 2500
-----------------------------------------------------------------
Total (project definition and requirements) $ 27140
Project design, implementation and testing stages
18 weeks of effort at $120/h $ 75600
Discount of 20% $- 15120
3 weeks of effort at $160/h $ 16800
Discount of 20% $- 3360
4 trips to the US at $2500 per trip $ 10000
-----------------------------------------------------------------
Total (design, implementation and testing, x equipment) $ 83920
Total (whole project, excluding equipment) $ 111060
Equipment $ unknown
The purpose of the trips to the US to be for detailed design, alpha
testing, beta testing, and release. Richard will need to come along at
least once.
Equipment will include hardware to run the defect tracker, and any
third-party software needed to run the defect tracker (for example,
Windows NT or Oracle). We can make an estimate once we know the
equipment requirements.
Note that these are initial rough estimates, subject to change. A firm
budget can't be made until the requirements for the project have been
analysed and agreed.
5. Counter-requirements
In order for the project to succeed, you must commit effort. In
particular, you should be prepared to do alpha and beta testing at your
site: that is, install, use and evaluate the integration.
A. References
[Brooks 1995] "The Mythical Man-Month: Essays on Software Engineering"
(second edition); Frederick P. Brooks Jr.; Addison-Wesley; 1995; ISBN
0201835959.
[RB 2000-02-02] "Steps to Defect Tracking"; Richard Brooksby; Ravenbrook
Limited; 2000-02-02; .
[GDR 2000-05-24] "Perforce Defect Tracking Integration Project
Requirements"; Gareth Rees; Ravenbrook Limited; 2000-05-24; .
[GDR 2000-05-30] "Analysis of architectures for defect tracking
integration "; Gareth Rees; Ravenbrook Limited; 2000-05-30; .
B. Document History
2001-02-16 RB Generalized to other defect trackers and edited for
distribution.
---
Copyright 2000, 2001 Ravenbrook Limited. This document is provided "as
is", without any express or implied warranty. In no event will the
authors be held liable for any damages arising from the use of this
document. You may make and distribute verbatim copies of this document
provided that you do not charge a fee for this document or for its
distribution.