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.