6 THE PREFERRED OPTION

Introduction

The process of reaching a preferred option should be documented and the preferred option formally approved. Once this is done, a number of simple procedures should be carried out. The aim of these is to enable the project model to be used as "instrumentation" with which to guide the project.

Baseline the project model of your preferred option

Basically, this means taking a snapshot of your project model. Actuals will then be recorded against this so that the accuracy or otherwise of the model can be determined, and the model can be recalibrated where necessary.

All PC-based tools provide a facility for doing this. Alternatively you can merely lay out your plan with:

• two columns for estimated schedule and effort “ these will have values in them

• two columns for actual schedule and effort “ these can be filled in as the project proceeds

Extract major milestones

The major project milestones should be extracted from the project model and explicitly stated in the project plan. These will serve:

• As useful intermediate targets to be met

• As an early warning system if the milestones aren't met

7 SAMPLE WBS

1 Product requirements phase

1.1 Product requirements document

• Research

• Write

• Circulate

• Individual review

• Review meeting

• Updates/changes to document

• Circulate again

• Second review

• Sign-off

1.2 End product requirements phase

2 Software requirements phase

2.1 Software requirements document

• Research

• Write

• Circulate

• Individual review

• Review meeting

• Updates/changes to document

• Circulate again

• Second review

• Sign-off

2.2 Software acceptance test plan

• Research

• Write

• Circulate

• Individual review

• Review meeting

• Updates/changes to document

• Circulate again

• Second review

• Sign-off

2.3 End software requirements phase

3 Architectural design phase

3.1 Architectural design document

• Research

• Write

• Circulate

• Individual review

• Review meeting

• Updates/changes to document

• Circulate again

• Second review

• Sign-off

3.2 Software integration test plan

• Research

• Write

• Circulate

• Individual review

• Review meeting

• Updates/changes to document

• Circulate again

• Second review

• Sign-off

3.3 End architectural design phase

4 Detailed design phase

4.1 Detailed design document

• Research

• Write

• Circulate

• Individual review

• Review meeting

• Updates/changes to document

• Circulate again

• Second review

• Sign-off

4.2 Software unit test plan

• Research

• Write

• Circulate

• Individual review

• Review meeting

• Updates/changes to document

• Circulate again

• Second review

• Sign-off

4.3 End detailed design phase

Notes

1. During the first four phases, the cycle (circulate, individual review, review meeting, updates/changes to document) could be repeated more than once. You should state in your estimates how many iterations of this cycle you are assuming .

2. Research could be a significant project in its own right requiring much further detailed breakdown.

5 Coding phase

5.1 Produce code element

• Write code element

• Clean compile code element

• Link code element

• Walkthrough code element

  • Prepare for walkthrough

  • Attend walkthrough

  • Updates/changes to code

  • Sign-off on walkthrough

• Code element documentation

5.2 End coding phase

6 Unit test phase

6.1 Unit test code

• Prepare test plan and test set

• Test code

• Make corrections to code

• Test code again

• Prepare unit test document

6.2 End unit test phase

Note

1. The cycle (test code, make corrections to code) could be repeated more than once. You should state in your estimates how many iterations of this cycle you are assuming.

7 Integration testing phase

7.1 Integration testing of code

• Any remaining preparation of test plan and test set, not already covered by system integration test plan

• Test code

• Make corrections to code

• Test code again

• Prepare integration test document

7.2 End integration testing phase

Notes

1. The cycle (test code, make corrections to code) could be repeated more than once. You should state in your estimates how many iterations of this cycle you are assuming.

2. Both "Test code" and "Make corrections to code" could be significant projects in their own right requiring much further detailed breakdown.

8 System test phase

8.1 Execution of internal software acceptance test plan

8.2 End system test phase

9 Release phase

9.1 Installation

• Plans

• Activities

• Test

• Record results

9.2 Data conversion

• Plans

• Activities

• Test

• Record results

9.3 Reviews

9.4 Software release

9.5 End release phase

10 Operation and maintenance phase

10.1 Evaluation

10.2 Design reviews

10.3 Support and maintenance

10.4 Audit

10.5 End operation and maintenance phase

11 Other possible WBS elements in life cycle

11.1 Training

• Familiarization by project personnel

• Training of project personnel

• User training

11.2 Recruitment

11.3 Test environment development

• Overhead in dealing with software development staff

11.4 Development support

• Database administration

• Development environment

• System build

11.5 Project management

See Chapter 4 for a full breakdown of tasks . Allow 6 “8 percent of total project effort, as described in Chapter 4.

11.6 Configuration management

• Reviews

• Ongoing configuration management

11. 7 Documentation

• Reviews

• User (different types)

• Administrator

• Release notes

• Technical manuals, i.e. manuals describing how the software works

• Help texts

• Overhead in dealing with software development staff

11.8 Quality management/quality plans