When the functional specification document has been baselined, the Development team has primary ownership of the Code Complete milestone. Again, this is an iterative process that may include parallel development and integration of components from many sources. It is also likely to include a number of Beta or "pre-release" versions.
All team members have specific responsibilities as the overall team moves toward the Release of Product milestone. In this final phase, Testing/QA has primary responsibility for certifying readiness for release and turning over the project to Logistics Planning.
Risk-driven scheduling, as the name implies, is the early scheduling and prioritizing of those tasks and components that represent the highest risk factors in the development process.
The following list describes guidelines for implementing risk-driven scheduling in this process model.
Risk-driven scheduling encourages developers to aggressively work toward the early milestone rather than expanding work to fill the time allocated with risk factored in.
On the other hand, missing the early milestone serves as an early warning to project management, drawing attention to slippage in a proactive manner. The amount of slippage on earlier milestones in the project serves as a measure of estimating quality and provides forecasting information for adjusting milestones that fall later in the project.
In addition, customers have more visibility into risk areas of the project and their expectations are managed in a more productive manner.
The Development team uses a phased release schedule. This typically involves one or more interim releases. Release management and Test and QA are involved in each release as though it were the final one.
The milestone-based process model encourages the project team to think of the application under development as a product, and to manage both new development and maintenance as versioned releases. This concept impacts how expectations are set and how the entire project is planned and managed.
Versioned releases help to manage uncertainty and change, set clear and motivational goals, force closure on critical issues, and encourage continuous improvement.
The first release of a new system is a baseline for the application. It helps to think of the application as a "product" — there will be new releases. Features that are not included in the first release will be tracked and prioritized for subsequent releases. This is accomplished by using a database for tracking ideas, features, and issues. The database should include the following: