Share via

From Code Complete to Release

  • Article

   

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

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.

  • The way in which Development's role is defined while constructing the functional specification encourages the use of early proof-of-concepts and implementation prototypes to explore and mitigate risk. Before Development approves the functional specification, it will want to make sure that it understands the risks involved. The team will then commit to a development and delivery schedule and prioritize the development releases.
  • Prioritization is built into the definition of the functional specification. The team and customers agree on priorities, based on technical risk. This ensures that potentially risky functions and functions of particular importance to the business are available first.
  • The major milestones are not points at which deliverables are frozen, but rather points at which sets of assumptions are placed under change control so that risks identified after that point can be planned and focused.
  • As the functional specification solidifies, Development may begin work before the formal milestone is reached. There is no magical constraint that says that what happens prior to this milestone is not development work. This can aid in the early identification of risk.
  • Development uses a phased release schedule. This typically involves one to three interim (beta or "test") releases. Release management and Test and QA are involved in each release as though it were the final one.
  • The concept of versioned releases is part of the process model. This enables a project team to be responsive to tradeoffs in functions, schedules, and risks. It also sets the stage for incremental enhancement to the first release baseline.

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.

Versioned Releases

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:

  • The prioritized features identified in the functional specification. This way, development stays focused on high-priority features, while explicit decisions can be made regarding tradeoffs for the release. Also, any features that did not make it into the current release can be captured for a subsequent release.
  • Great ideas that surface during the planning and development stages. If these ideas are outside the scope of the vision statement for the current release, they too are captured to ensure that they get considered for a subsequent release.
  • Issues and noncritical problems in the final release. These are captured so that they can be prioritized and addressed in the next release.