Unified Process for EDUcation: Lifecycle and Phases


Phases and Milestones To top of page

The phases and milestones of a project

From a management perspective, the software lifecycle of the Unified Process for EDUcation (UPEDU) is decomposed over time into four sequential phases, each concluded by a major milestone; each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase.

Planning Phases To top of page

All phases are not identical in terms of schedule and effort. Although this varies considerably depending on the project, a typical initial development cycle for a medium-sized project should anticipate the following distribution between effort and schedule:

  Inception Elaboration Construction Transition
Effort ~5 % 20 % 65 % 10%
Schedule 10 % 30 % 50 % 10%

which can be depicted graphically as

Click on a phase for more information

For an evolution cycle, the inception and elaboration phases would be considerably smaller. Tools which can automate some portion of the Construction effort can mitigate this, making the construction phase much smaller than the inception and elaboration phases together.

One pass through the four phases is a development cycle; each pass through the four phases produces a generation of the software. Unless the product "dies," it will evolve into its next generation by repeating the same sequence of inception, elaboration, construction and transition phases, but this time with a different emphasis on the various phases. These subsequent cycles are called evolution cycles. As the product goes through several cycles, new generations are produced.

Evolution cycles may be triggered by user-suggested enhancements, changes in the user context, changes in the underlying technology, reaction to the competition, and so on. Evolution cycles typically have much shorter Inception and Elaboration phases, since the basic product definition and architecture are determined by prior development cycles.   Exceptions to this rule are evolution cycles in which a significant product or architectural redefinition occurs.