Iteration Plan Sample Schedule :
Construction Phase
This example schedule is for a typical iteration in the Construction Phase of a project following the Classic RUP configuration (or similar). This illustration shows how the work to be conducted in each discipline relates to the overall schedule, and is based on the Workflow Details as they would be enacted at that time. The intent is to indicate schedule dependencies and show where work occurs in parallel. The lengths of the bars in the chart (indicating duration) have no absolute significance. For example, it is not intended to convey that Plan the Integration and Prepare Environment for Iteration must have the same duration. There is also no intention to suggest the application of a uniform level of effort across the disciplines. An indication of the relative effort can be seen in the Process Overview. You can navigate to the corresponding Workflow Detail pages from each line of the chart by clicking on the Workflow Detail name. This Gant Chart illustration was created from a Microsoft® Project® Plan.
Note that there is significant continuing design work shown in this iteration, indicating that it is early in the construction phase. In later construction iterations, this will diminish as design work completes. In this example, Requirements discovery and refinement is shown as complete, the remaining requirements effort relating entirely to the management of change.
A walk-through of the schedule outline
| Project Management: Plan the Iteration. | The project manager has updated the iteration plan based on what new functionality is to be added during the new iteration, factoring in the current level of product maturity, lessons learned from the previous iterations, and any risks that need to be mitigated in the upcoming iteration (see Artifact: Iteration Plan and Artifact: Risk List). |
|---|---|
| Environment: Prepare the environment for the iteration. |
Based on the evaluation of process and tools in the previous iteration, the Role: Process Engineer further refines the development case, templates, and guidelines. The Role: Tool Specialist does the necessary changes to the tools. |
| Implementation: Plan system-level integration. | Integration planning takes into account the order in which functional units are to be put together to form a working/testable configuration. The choice depends on the functionality already implemented, and what aspects of the system need to be in place to support the overall integration and test strategy. This is done by the system integrator (see Workflow Detail: Plan the Integration in the Implementation discipline), and the results are documented in the Artifact: Integration Build Plan. The Integration Build Plan defines the frequency of builds and when given 'build sets' will be required for ongoing development, integration, and test. |
| Analysis & Design: Refine Use-Case Realizations. | Designers refine the model elements identified in previous iterations by allocating responsibilities to specific model elements (classes or subsystems) and updating their relationships and attributes. New elements may also need to be added to support possible design and implementation constraints (see Workflow Detail: Design Components) Changes to elements may require changes in package and subsystem partitioning (see Activity: Incorporate Existing Design Elements). Results of the analysis need to be followed by review(s). |
| Test: Define Evaluation Mission | The test manager (Role: Test Manager) gains agreement with stakeholders on the test objectives for this iteration. The test analyst (Role: Test Analyst) and test designer (Role: Test Designer) define the details of the approach - what will be tested and how. |
| Test: Verify Test Approach |
If the test approach has changed significantly from the previous iteration, then the change in approach needs to be verified. The test designer (Role: Test Designer) and tester (Role: Tester) implements new test infrastructure. The test analyst (Role: Test Analyst) details specific verification tests which are then implemented and executed by the tester. The test manager (Role: Test Manager) ensures that the development team is committed to supporting the revised test approach. |
| Implementation: Develop Code and Test Unit | Implementers develop code, in accordance with the project's programming guidelines, to implement the Artifact: Implementation Elements in the implementation model. They fix defects and provide any feedback that may lead to design changes based on discoveries made in implementation (see Workflow Detail: Implement Components in the Implementation discipline). |
| Implementation: Plan and Implement Unit Tests. | The Implementer needs to design unit tests so that they address what the unit does (black-box), and how it does it (white-box). Under black-box (specification) testing the Implementer needs to be sure that the unit, in its various states, performs to its specification, and can correctly accept and produce a range of valid and invalid data. Under white-box (structure), testing the challenge for the Implementer is to ensure that the design has been correctly implemented, and that the unit can be successfully traversed through each of its decision paths (see Workflow Detail: Implement Components in the Implementation discipline). |
| Implementation: Test Unit within Subsystem. | Unit Test focuses on verifying the smallest testable components of the software. Unit tests are designed, implemented, and executed by the Implementer of the unit. |
| Implementation: Integrate Subsystem. |
The purpose of subsystem integration is to combine units that may come from many different developers within the subsystem (part of the implementation model), into an executable 'build set'. The Implementer in accordance with the plan integrates the subsystem by bringing together completed and stubbed classes that constitutes a build (see Workflow Detail: Integrate Each Subsystem in the Implementation discipline). The Implementer integrates the subsystem incrementally from the bottom-up based on the compilation-dependency hierarchy. Once the subsystem is ready for integration at the system level, the Implementer 'releases' the subsystem from the team integration area into an area where it becomes visible, and usable, for system-level integration. |
| Implementation: Integrate System. | The purpose of system integration is to combine the currently available implementation model functionality into a build. The system integrator incrementally adds subsystems, and creates a build that is handed over to testers for overall integration testing (see Workflow Detail: Integrate the System in the Implementation discipline). |
| Test: Validate Build Stability, Test and Evaluate, Achieve Acceptable Mission, and Improve Test Assets. |
Testing proceeds through the following cycle of Workflow Details (organized around major builds, and involving all test roles):
|
| Project Management: Assess the iteration itself. |
Lastly, the project manager compares the iteration's actual cost, schedule, and content with the iteration plan; determines if rework needs to be done, and if so, assigns it to future iterations; updates the risk list (see Artifact: Risk List); updates the project plan (see Artifact: Software Development Plan); prepares the iteration plan for the next iteration (see Artifact: Iteration Plan). Productivity figures, size of code, and size of database might be interesting to consider here. The project manager, in cooperation with the process engineer and the tool specialist, evaluates the process and the use of tools. These lessons-learned will be used when preparing the environment for the following iteration. |
Result
The main result of a late iteration in the construction phase is that more functionality is added, which yields an increasingly more complete system. The results of the current iteration are made visible to developers to form the basis of development for the subsequent iteration.
