Roadmap: Evaluating Quality throughout the Lifecycle

Topics

1. Introduction
2. Inception Phase Activities
3. Elaboration Phase Activities
4. Construction Phase Activities
5. Transition Phase Activities

Introduction

The development of software is a complex process taking months (or years) and includes the combined efforts of many roles, producing many artifacts. Achieving quality under these constraints, while attainable, cannot be achieved through a single assessment or evaluation (usually performed at the end of the lifecycle, just before deployment). Instead, quality is achieved by evaluating process activities and artifacts, and taking the appropriate action upon completion of the evaluations, throughout the entire lifecycle. As the product progresses through different phases and iterations in the process, managing quality will focus on different artifacts and activities. Additionally, what is deemed as "acceptable quality", as defined by acceptance or evaluation criteria, will also change, based upon the goal of the iteration or phase.

In the following sections, arranged by Rational Unified Process phase, are matrices listing the artifacts and quality efforts (reviews, assessments, milestones, and so on) performed throughout the lifecycle.

Inception Phase Activities

The inception phase is focused on establishing the business case and a baselined vision for the project. The inception phase is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do.

See Phase: Inception for a greater description of the Inception Phase.

The matrix below identifies the artifacts created and/or reviewed during the inception phase:

Elaboration Phase Activities

In the elaboration phase, the focus of the project shifts to discovery of the architecture of the system, to provide a stable basis for the bulk of the design and implementation effort in the construction phase. The architecture evolves out of a consideration of the most significant requirements, those that have a great impact on the architecture of the system. The stability of the architecture is evaluated through the use of architectural prototypes. The elaboration phase culminates in the establishment of an architectural baseline of the system.

See the Elaboration Phase for more information.

The matrix below identifies the artifacts created and/or reviewed during the elaboration phase:

Construction Phase Activities

In the construction phase, the architecture and requirements have been baselined and changes are controlled by a strict change-management process. During the construction phase, the focus is on fleshing-out the remaining requirements and the baselined architecture. By the end of the construction phase, all requirements have been analyzed, designed, built and tested.

Some of the characteristics of the late construction phase are that requirements are stable, and a great deal of the functionality has been implemented and integrated in preparation for test.

See the Construction Phase for more information.

The matrix below identifies the artifacts created and/or reviewed during the construction phase:

Transition Phase Activities

During the transition phase you transition the software to the user community. Once the product has been put in the hands of the end users, issues often arise that require additional development to adjust the system, correct undetected problems, or finish some of the features that may have been postponed. This phase typically starts with a "beta release" of the system. At the end of the transition phase you decide whether the lifecycle objectives have been met, and possibly if you should start another development cycle. This is also a point where you wrap up some of the lessons learned on this project to improve the process.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process