Iteration Plan Sample Schedule :
Elaboration Phase
This example schedule is for a typical iteration in the Elaboration 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 dependencies and show where workflows occur 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 for Next Iteration and Manage the Scope of the System 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 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.
A walk-through of the schedule outline
| Start up: Outline the iteration plan, risks, and architectural objectives. | The Artifact: Iteration Plan for this iteration was constructed by the Role: Project Manager after the previous iteration was assessed and the project scope and risk reevaluated. The evaluation criteria for the architecture are outlined by the Role: Software Architect in the Artifact: Software Architecture Document, taking into consideration the "architectural risks" that are to be mitigated (see Artifact: Risk List). Remember that one of the goals of Elaboration is establishing a robust, executable architecture; the plan for doing this needs to be developed in the initial Elaboration iteration. |
|---|---|
| Environment: Prepare environment for the iteration | The Role: Process Engineer and the Role: Tool Specialist prepare the environment for the iteration (see the Workflow Detail: Prepare Environment for an Iteration). An important input is the evaluation of the previous iteration. The Role: Process Engineer completes the Artifact: Development Case and tailor templates (see Artifact: Project-Specific Templates) and guidelines (see Artifact: Project-Specific Guidelines), to be ready for the iteration, by tailoring (at least) the Analysis & Design discipline and the Implementation discipline. The Role: Tool Specialist sets up the tools (see Artifact: Tools) to be used in the iteration. |
| Requirements: Decide what will "drive" the development of the architecture. | The Role: Software Architect and the Role: Project Manager then determine which use cases and/or scenarios should be addressed in the current iteration; these use cases and/or scenarios drive the development of the architecture (see Workflow Detail: Manage the Scope of the System in the Requirements Discipline). The Artifact: Iteration Plan created in previous step should be updated accordingly. |
| Understand the "drivers" in detail, if necessary; inspect results. | A number of Role: Requirements Specifiers then describe in detail the architecturally significant subsets of the selected use cases or scenarios (see Workflow Detail: Refine the System Definition in the Requirements discipline). As the model evolves, the Role: System Analyst may restructure the Artifact: Use-Case Model to improve the comprehensibility of the model. The changes to the Artifact: Use-Case Model are then reviewed and approved (see Workflow Detail: Manage Changing Requirements in the Requirements Discipline) |
| The "drivers" of the architecture are reconsidered according to new information; risks also need to be reconsidered. | The use-case view is revisited again by the Role: Software Architect, taking into consideration new use-case descriptions, and possibly a new structure of the Artifact: Use-Case Model (revisit Workflow Detail: Manage the Scope of the System in the Requirements Discipline). The task now is to select what set of use cases and/or scenarios should be analyzed, designed and implemented in the current iteration. Note again that the development of these use cases and/or scenarios set the software architecture. The Role: Project Manager again updates the current iteration plan accordingly (see Artifact: Iteration Plan), and might also reconsider risk management, because new risks might have been made visible according to new information (see Artifact: Risk List). |
| Use-Case Analysis: Find obvious classes, do an initial (high-level) subsystem partitioning, and start looking at the "drivers" in detail. |
To get a general feeling of the obvious classes needed, the Role: Software Architect then considers the system requirements, the glossary, the use-case view (but not use case descriptions), and the team's general domain knowledge to sketch the outline of the subsystems, possibly in a layered fashion (see Activity: Identify Design Elements in the Analysis & Design Discipline). The analysis mechanisms (common solutions to frequent analysis problems) are also identified by the software architect. In parallel with this effort, a team of Role: Designers, possibly together with the software architect, will start finding Artifact: Analysis Classes for this iteration's use cases and/or scenarios, as well as beginning to allocate responsibilities to the identified classes and analysis mechanisms, in the process updating the Artifact: Use-Case Realizations. The designers will use the obvious classes found by the software architect as input. Then, a number of designers refine the classes identified in the previous step by allocating responsibilities to the classes, and updating their relationships and attributes. It is determined in detail how the available analysis mechanisms are used by each class. When this is done, the Role: Software Architect identifies a number of classes that should be considered as architecturally significant, and includes these classes in the logical view section of the Artifact: Software Architecture Document. The resulting analysis artifacts are then reviewed. |
| Design: Adjust to the implementation environment, decide how the "drivers" are to be designed, and refine the definition of classes, packages and subsystems; inspect results. |
The Role: Software Architect then refines the architecture by deriving the design mechanisms (e.g. programming language, database, distribution mechanism, communication mechanism) needed by the earlier identified analysis mechanisms (see Activity: Identify Design Mechanisms in the Analysis & Design Discipline). Artifact: Design Subsystems are defined and design classes are allocated to them; the interfaces to subsystems are identified. Remaining design classes are partitioned into packages, and responsibilities for subsystems and packages are allocated to Role: Designers. Instances of classes and subsystems are used by designers to describe the realizations of the selected use cases and/or scenarios (see Workflow Detail: Design Components in the Analysis & Design discipline). This puts requirements on the employed model elements and their associated design mechanisms; in the process the interaction diagrams previously created are refined. The requirements put on each design mechanism are handled by the software architect (revisit Activity Identify Design Mechanisms in the Analysis & Design discipline). The logical view is updated accordingly by the software architect. The resulting design artifacts are then reviewed. |
| Consider the concurrency and distribution aspect of the architecture. | The next step for the software architect is to consider the concurrency and distribution required by the system. This is done by studying the tasks and processes required and the physical network of processors and other devices (see Activity: Describe the Run-time Architecture and Activity: Describe Distribution in the Analysis & Design Discipline). An important input to the software architect here are the designed use cases in terms of collaborating objects in interaction diagrams; these objects are allocated to tasks and processes, which in turn are allocated to processors and other devices. This results in both a logical and physical distribution of functionality. |
| Inspect the architecture | The architecture is reviewed. See Activity: Review the Architecture. |
| Implementation: Consider the physical packaging of the architecture. | A Role: Software Architect now considers the impact of the architectural design onto the implementation model, and defines the initial structure of the implementation model (revisit Activity: Structure the Implementation Model in the Analysis & Design discipline). |
| Implementation: Plan the integration. | A system integrator (Role: Integrator) now studies the use cases that are to be implemented in this iteration, and defines the order in which subsystems should be implemented, and later integrated into an architectural prototype (see Workflow Detail: Plan the Integration in the Implementation discipline). The results of this planning should be reflected in the Artifact: Software Development Plan. |
| 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 |
The test designer (Role: Test Designer) and tester (Role: Tester) now implement enough of the test infrastructure to verify that the test approach will work and is of value. The test analyst (Role: Test Analyst) details these 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 test approach. |
| Implementation: Implement the classes and integrate. | A number of implementers (Role: Implementer) now implement and unit test the classes identified in the architectural design (Step 5, 6, and 7). The implementations of the classes are physically packaged as defined by the implementation model. The implementers (Role: Implementer) also fix defects (see Workflow Detail: Implement Components in the Implementation discipline). The developers and testers integration test the implementation subsystem (see Workflow Detail: Integrate Each Subsystem in the Implementation discipline and Workflow Detail: Test and Evaluate in the Test discipline), and then the implementers (Role: Implementer) release the tested implementation subsystems to system integration. |
| Integrate the implemented parts. | The system integrators (Role: Integrator) incrementally integrate the subsystems into an executable architectural prototype (see Workflow Detail: Integrate the System in the Implementation discipline). Each build is normally tested to ensure it is stable enough to warrant further testing (see Workflow Detail: Validate Build Stability in the Test discipline), detailed testing work commences and (see Workflow Detail: Test and Evaluate in the Test discipline). |
| Test: Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets |
Testing proceeds through the following cycle (organized around major builds, and involving all test roles):
|
| Assess the iteration itself. |
Lastly, the Role: Project Manager compares the iteration's actual cost, schedule, and content with the iteration plan; determine if rework needs to be done, and if so, assign to future iterations; update the risk list (see Artifact: Risk List); update the project plan (see Artifact: Software Development Plan); and prepare an outline of an 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 Role: Project Manager, in cooperation with the Role: Process Engineer and the Role: Tool Specialist, evaluate the use process and tools. |
Result
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 In Elaboration
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.
