Examples Overview >
Small Project Development Case >
Project Lifecycle >
Elaboration
Examples Overview >
Small Project Development Case >
Project Lifecycle >
Elaboration
|
|
Table of Contents |
Topics (on this page) |
This illustration shows how the first elaboration iteration of a small project might be planned. The lengths of the bars in the chart (indicating duration) have no absolute significance. There is also no intention to suggest the application of a uniform level of effort across the duration of the workflows. You can navigate to the corresponding task description from each line of the chart - just click on the task name. This illustration was created from a Microsoft Project Plan.
Note that although this is a plan for a single iteration, not all Requirements and Analysis and Design work performed during this iteration is intended for Implementation and Test in this iteration. This explains why the relative effort, within an iteration, for Requirements, Analysis and Design, Implementation and Test, changes through the lifecycle. However, the Iteration Plan will dictate what requirements are explored and refined and what components are designed, even if they are intended for Implementation and Test in a later iteration.
At the start of the elaboration phase, the Inception Phase has been completed and the project has been funded. An initial Artifact: Software Development Plan exists, along with preliminary Artifact: Iteration Plans for at least the Elaboration Phase. The requirements of the system, captured by the Artifact: Use-Case Model and Artifact: Supplementary Specifications, have been briefly outlined.
| Project Management: | |
| Managing/Monitoring |
This represents ongoing project management activities, including the following workflow details: On this small project, the Project Manager is also the Test Manager, so this task also includes:
The principal output artifacts are: |
|
This includes workflow details:
The principal output artifacts are:
The results of status assessments and iteration assessments should be considered in determining if any changes to process and tools are necessary. |
|
| Requirements | |
|
This includes the Activity: Prototype the User Interface. The main output artifact is User-Interface Prototype. |
|
|
Requirements discovery and refinement continues in elaboration. The relevant workflow detail is: Manage Changing Requirements. |
|
|
This includes the workflow detail Refine the System Definition (except for user-interface related activities, which are a separate task). The main output artifacts are:
The effort to define requirements is divided into smaller tasks with shorter durations (around 1 week is typical). These are represented in the example plan as "Requirements Set 1", "Requirements Set 2", and so on. Tasks are typically organized around use cases or scenarios, with other tasks to detail supplemental requirements or investigate specific issues or risks. |
| Architectural Definition | |
| Define a Candidate Architecture |
This include the workflow detail Define a Candidate Architecture. |
| Structure the Implementation Model |
This includes the workflow detail Structure the Implementation Model. |
|
This includes the workflow detail Refine the Architecture. |
|
| Development Support | |
|
Maintaining the build environment, selecting and running regression tests on builds, is an ongoing task. The relevant workflow details are: |
|
| Defect Fixing | Fixing defects in previously developed code is an ongoing task. The relevant workflow details are the same as for the "Develop Components/Features" tasks. |
|
Many tasks are organized around a feature, use case, or
scenario being implemented. Thus one task will often include the following
workflow details:
Other tasks may design and implement components that then support multiple features, use cases, or scenarios. Large tasks (more than a couple of weeks) may be divided into subtasks of incremental functionality. Other large tasks may be subdivided by the principal activity being performed. For example, into:
|
Configuration Management tasks (workflow details: Change
and Deliver Configuration Items and Manage
Change Requests) are folded into the above tasks. Administrative and environment
support tasks have been omitted for simplification.
The result of this initial iteration would be a first cut at the architecture, consisting of fairly described architectural views (use-case view, logical view, process view, deployment view, implementation view) and an executable architecture prototype.
Subsequent iterations can be initiated to further enhance the understanding of the architecture. This might imply a further enhancement of the design or implementation model (that is, the realization of more use cases, in priority order, of course). Whether this needs to take place depends on considerations such as the complexity of the system and its architecture, associated risks, and domain experience.
In each iteration the supporting environment is further refined. If the first Elaboration iteration focused on preparing the environment for Analysis & Design, and Implementation, then the second iteration may focus on preparing the test environment. Preparing the test environment includes configuring the test process, and writing that part of the development case, preparing templates and guidelines for test and setting up the test tools.
|
Rational Unified
Process
|
