# Planning Checkup
7. Does the project have a detailed, written Software Development Plan?
8. Does the project's task list include creation of an installation program, conversion of data from previous versions of the system, integration with third-party software, meetings with the customer, and other "minor" tasks?
9. Were the schedule and budget estimates officially updated at the end of the most recently completed phase?
10. Does the project have detailed, written architecture and design documents?
11. Does the project have a detailed, written Quality Assurance Plan that requires design and code reviews in addition to system testing?
12. Does the project have a detailed Staged Delivery Plan for the software, which describes the stages in which the software will be implemented and delivered?
13. Does the project's plan include time for holidays, vacation days, sick days, and ongoing training, and are resources allocated at less than 100 percent?
14. Was the project plan, including the schedule, approved by the development team, the quality assurance team, and the technical writing team—in other words, the people responsible for doing the work?

# Software Development Plan.
The document that describes how a software project will be conducted. The project plan includes schedules, budgets, estimates, and technical methodologies; it is updated to include detailed plans for each phase throughout the project.
At the beginning of the project, prepare a Software Development Plan that describes the project's vision, defines the team structure, and defines the development methods.
The plan should include estimates, major milestones, and other measures that will be used to track progress. The Software Development Plan should be a living document that is updated at the end of each major phase or stage.

# Milestone Targets:
- Architecture complete
- Stage 1 complete
- Stage 2 complete
- Stage 3 complete
- Software release (assuming only three stages)

# STAGE PLANNING OVERVIEW:
## Requirements updates
In the early stages, the requirements to be implemented during the stages should be exactly what the project team specified during prototyping and requirements development. During later stages, improved understanding of the software being built, changing market conditions, and other factors may necessitate changes to requirements. Time should be allocated at the beginning of each stage—especially the beginnings of the later stages—to evaluate possible changes to requirements.

## Detailed design
Near the beginning of each stage, developers flesh out the detailed design so that it adequately supports the software construction that will be done during the stage. If detailed design work uncovers flaws in the architecture, the project team revises the architecture using the change control procedure.

## Construction
After developers complete the detailed design for a stage, they code the software to be delivered during the stage. Coding is supported by a practice called "the daily build and smoke test process" (which is explained in Chapter 14, "Construction"). Detailed design flows easily into coding because on most software projects, the developer who creates the detailed design for a specific part of the software also writes the code for that part.

## Test case creation
At the same time the developers are working on a stage's construction, testers should create the full set of test cases needed to test the functionality developed during the stage. Test cases can be constructed in parallel with the code because they can be based partially on the detailed User Interface Prototype created during requirements development and partially on the code that developers informally turn over to testing before the code is officially declared complete. (Details of this practice are described in Chapter 14, "Construction.")

## User documentation updates
The User Manual/Requirements Specification is updated to describe the asbuilt software. Help files and other kinds of end-user documentation are created.

## Technical reviews
Developers participate in design and code reviews. Design and code reviews begin in earnest during the post-architecture period, and the Stage Plan should allow time for them.

## Defect corrections
Developers correct the defects uncovered by testing and reviews. One of the critical advantages of staged delivery is its ability to minimize the risk of low quality by forcing the software's quality to a releasable level by the end of each stage. The defects detected during a particular stage must be corrected during that stage and the corrections must be verified by testing, by technical reviews, or by both to mitigate the risk of low quality.

## Technical coordination
Every project requires coordination between developers and testers, and the schedule should allow time for that coordination. Managers of large projects will need to coordinate the activities of different groups of developers. Developers typically also need to be available to explain their implementations to technical writers and to review the technical writers' documents. When the approach described in this book is used, the project has already created a full-fledged User Interface Prototype and User Manual/Requirements Specification, so the amount of coordination required on the project will be less than on many other projects. Some changes to requirements and the user interface are inevitable as the software is developed in detail. Developers will need to be available to explain those changes to testers and technical writers.

## Risk management
Stage planning should be risk driven. The project manager should review the project's current Top 10 Risks List and determine whether the current project plan adequately addresses the current risks to the project. Many times, the top 10 risks at the end of a stage will have changed from the risks at the beginning of the stage, and different plans will be required. The "Survival Check" at the end of each chapter in this book provides a list of warning signs to look for throughout the project and particularly at the end of each stage.

## Project tracking
Tracking completed activities is the major management task during all stages. The section in this chapter called "Miniature Milestones" discusses project tracking in detail.

## Integration and release
At the end of each stage, the development team brings the software to a releasable state. Developers integrate the code for that release. They correct defects. They raise the software's fit and finish to release quality. (When I say "fit and finish," I mean that the software's install program works, the context-sensitive help displays the correct help topics, and so on.) At this point the software may be released in whatever way makes the most business sense:
- It can simply be declared to be "released," the team can celebrate its accomplishment, and work can begin immediately on the next stage.
- It can be released to specific in-house users, external users, or both.
- It can be released generally to in-house users for their review and evaluation.
- It can be released to the whole group of in-house users, external users, or both.

The decision about how widely to distribute the release should be based on business considerations rather than on technical considerations. The software's technical quality at the end of each stage should make it possible to release the software to virtually anyone. But the software might not contain enough new functionality to warrant distributing it widely, or the project team might not want to absorb the cost and schedule overhead associated with managing an external release. However, if external users are eager for new functionality and the development team has organized releases by priority, distributing staged releases to external users as the releases become available might be a good business decision. Whether ultimately released to users or not, the software should always be released to the quality assurance group. It doesn't do the project any good to have the software declared fit for release unless that claim is verified independently of this project team.

## End-of-stage wrap-up
At the end of a stage, the project team should pause to review its progress to date and make any necessary course corrections. The project team should identify practices that have worked and those that should change so that the project will work better. By the end of each stage, the project team will have developed a deeper understanding of the software it is implementing and can create increasingly accurate cost and schedule estimates.