Work Breakdown Structure

Project Information

Project: PIMS
Project Time-frame: 2004-2009
Attached worksheets:
Related Documents:
Process impact: This work breakdown helps ensure that resources are allocated for all necessary tasks. It should be reviewed regularly.

Estimating

Estimating software work is not easy. To know how long the coding will take it is necessary to know all the details. Determining the details is doing the coding.

At the start of a coding task, it is possible to make high and low estimates for the time required. These may differ by a factor of 2:1. Developers who are experienced in making estimates may be able to make tighter ones, especially when doing a type of job they have done before. Estimates are more reliable if the job is smaller, so to get a good estimate of a large task, it is better to do the design work needed to divide it into mini-milestones. The development team will use this approach to gain the ability to give customers estimates of the work needed to meet different requirements.

One way of improving estimates is to do first the work that is hardest to estimate. The development team will point out opportunities to do this to customers when is is time to decide the content of the next release.

Work Breakdown Structure

It is not possible to provide a full WBS because the full requirements are not yet known. Because of the difficulties of estimation described above, we will also not attempt to create a CPA, Gantt chart, or resource scheduling chart.

After we have gained some confidence in our estimates, we will begin to create a more detailed WBS listing requirements, grouped by scientific goal, and the high and low estimates for effort to deliver them. When customers have chosen requirements for a forthcoming release, we will move the associated tasks into a WBS heading for that release. We do not expect to be able to do this before version 0.2 is released.

Tasks shown like this are fixed costs of the project. These should be estimated soon.

Tasks shown like this are proportional to the size ofthe requirements. A more detailed work breakdown structure will be produced for these tasks when the requirements are better known.

Tasks shown like this depend on the defect rate in the delivered code. These will be estimated after 12 months experience.

TIP: Label each step uniquely to show its position in the WBS, e.g., Step 1.1.4.A. Use numbers for steps that you intend to do in sequence, and use letters for steps that you intend to do in parallel. E.g., Step 1.1 comes before Steps 1.2.A and 1.2.B, but those two steps may be done in parallel, and Step 1.3 will be done after all 1.2.* steps have been finished. Don't worry about renumbering if you delete a step.
StepDescriptionEstimate
1.Preparation
1.1.Developer orientationTBD
1.2.Requirements gathering
1.2.A.
Use Cases
TBD
1.2.B.
Changes to data model
TBD
1.2.C.Non-functional requirementsTBD
1.2.D.Requirements validationTBD
1.3.Design
1.3.A.Software architectureTBD
1.3.B.User interface designTBD
1.4.Development toolsTBD
2.Construction
2.1.A.
System implementation
2.1.A.1
Unit tests
TBD
2.1.A.2
Production code
TBD
2.1.A.3.
Integrate Components
(mostly done during component implementation)
TBD
2.1.B.
Maintenance documentation
TBD
2.1.C.
User documentation
TBD
3.Quality assurance
3.1.
Fixing defects reported by users
TBD
3.2.Testing
3.2.D.1.
Test planning
TBD
3.2.D.2.
Test implementation
TBD
3.2.D.3.
Test execution
TBD
3.3.
Reviews of design and code
TBD
3.4.
Fixing defects found by testing and review
TBD
4.Transition
4.A.Release packagingTBD
4.B.Documentation for other groupsTBD
5.Reflection
5.1. Postmortem reportTBD
Total fixed costsTBD