Capability Pattern: Inception Phase Iteration
This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Inception phase. Each activity and related goals are described.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Relationships
Context
Description

Introduction

The project starts with the assumption that the business case has been created, the project manager has been identified, the team (at least for the first iteration) has been defined, the development environment (including tools and infrastructure) is in place, and the process to be followed is the delivery process suggested by OpenUP/Basic. The number and length of each Inception iteration will vary, depending upon the needs of the project.

In the next sections we describe the activities performed in a typical iteration during Inception phase.

Initiate project

This activity takes place at the beginning of the first iteration, when the project starts. The goal of this activity is to establish the vision for the project and the project plan at a high level of granularity.

The people in the roles involved at this time collaborate to perform this activity:

  • Analyst and stakeholder roles work together to define the vision for the project, capturing the customer needs and features for the system under development. Needs and features are captured to the extent required to reach agreement about the scope of the project.
  • Project manager (with collaboration and agreement of team and stakeholders) proposes a high-level project plan that includes the milestones for the four phases and time-boxed iterations for each phase. This plan and the allocation of staff to the project evolve throughout the phases to reflect the project pace, as necessary.

Manage iteration

This activity is about the ongoing work performed by the project manager and the development team to initiate and conduct a given iteration. It consists of status reporting, handling of exceptions and problems, identifying risks, and reprioritizing work, as needed.

At the end of the iteration, the project manager conducts a status assessment with the development team and stakeholders.

If the iteration end coincides with the phase end, meeting the objectives for that phase should be used as success criteria for leaving the iteration. The iteration assessment should verify that the objectives for the Iteration phase have been achieved, including agreement on the key functionalities and at least one possible solution for the system under development, as well as a reasonable understanding of cost, schedule and risks associated with the project.

Based on demonstration of key functionalities and architectural feasibility during the assessment, it becomes clear that either the project can proceed at the given pace or that a reprioritization of work needs to happen. As a consequence, the project manager may need to refine the project scope and duration.

Manage requirements

This activity is first performed in the first iteration, and repeated throughout the lifecycle.  The goal of this activity is to understand and prioritize stakeholder needs, and associated requirements for the system, and capture these in a form that will support effective communications and collaboration between the stakeholders and development team.

As the project is initiated, the analyst gathers requirements from stakeholders and captures associated work items for development in the work items list to facilitate prioritization and planning. As needed, requirements are outlined and detailed in use-case specifications and supporting requirements to the extent needed to provide information for the architect to create a prototype of the architecture and for the project manager to scope and plan the next iteration.

Determine architectural feasibility

This activity is initiated in the Inception phase and completed in the Elaboration phase. The goal of this activity is to establish an architecture for the system that provides the high-level design that maximizes stakeholder benefit, while respecting the constraints placed on the system and the development team.

Based on requirements being captured and detailed in parallel with this activity, the architect analyzes the architectural constraints and leverages the available assets and technology to propose an architectural proof of concept. This early architectural prototype is used both to demonstrate the feasibility of the project, by using the selected candidate architecture, and to mitigate one or more architecturally significant risks.



Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable