Iteration Plan Sample Schedule :
Transition Phase
This example schedule is for a typical iteration in the Transition 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 late in the Transition Phase. If the Workflow Detail 'Close-Out Project' is invoked, then this would be the final iteration. It is constructed from the Workflow Details as they would appear 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 Integrate the System and Improve Test Assets have similar 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.
A walk-through of the schedule outline
| Project Management |
Late in the Transition Phase, the main driver for planning in Activity: Develop Iteration Plan is the delivery of reliable software, with acceptable performance and complete functionality, to the customer. Accordingly, Change Requests (mainly defects and feedback from beta testing) are the Project Manager's major planning input for continuing development. Based on the number and severity of the Change Requests, the Project Manager may invoke risk management activities (through the Artifact: Risk List), for example in the management of changing requirements, or architecture refinement. The Project Manager has also to plan for the production of end-user support and installation material, and the contractually formal aspects of acceptance test. The Project Manager initiates the iteration in Activity: Initiate Iteration, then monitors and reports on project status in Workflow Detail: Monitor and Control Project. At completion, the results of the iteration are examined in Activity: Assess Iteration, and if this is the final iteration, the project manager prepares the project for shutdown. |
|---|---|
| Requirements and Analysis & Design |
Given the nature of the iterative development process, it is expected that the requirements will be very stable, if not completely frozen, by this time. Even so, some feedback that affects system requirements, or their interpretation, should be anticipated and the impact of this on scope has to be understood and controlled in Workflow Detail: Manage Changing Requirements. It is important that the system not be allowed to change in an ad hoc way during transition. Equally, the objective of analysis and design in this phase, in Workflow Detail: Refine the Architecture, is to maintain architectural integrity and perform the necessary run-time tuning and physical distribution adjustments to meet requirements for performance, capacity, and reliability. |
| Implementation | The planning for implementation during transition in Workflow Detail: Plan the Integration is driven by the feedback from beta test and other Change Requests raised during test by the project itself. As defects are fixed, and subsystems mature, they are integrated into builds for testing. In transition, the main work is in fixing defects in components, not adding new components. Unit testing (in Activity: Perform Unit Tests) is still required, but the purpose in transition is to verify changes and avoid regression, not complete functional verification. In subsystem and system integration during transition, (in Workflow Details: Integrate Each Subsystem and Integrate the System), completed components are available, so the use of 'stubs' is unnecessary, and again the purpose is to verify and validate changes and check for regressions. It is not usually necessary to perform integration in the piecewise fashion used during construction because the interfaces are stable by this time, and the Integrator can take a more optimistic approach. |
| Test |
The focus of testing during transition shifts towards improving quality and avoiding regression. In addition, there will often be a requirement for formal acceptance testing, which may involve a repeat of all or part of the system level tests. The planning for test during transition (in Workflow Detail: Define Evaluation Mission) thus has to provide effort and resources for some level of continued test design and implementation (because of ongoing development); regression testing, for which the effort and resources will depend on the chosen approach (for example, re-test everything, re-test to an operational profile, or re-test changed software), and acceptance testing, which may not require the development of new tests. As defects are fixed and beta feedback incorporated, successive builds are tested using the normal test cycle of Workflow Details:
When the system is deemed fit to undergo acceptance testing (perhaps through a repeat of all or part of the system level tests), a separate cycle of testing is performed which focuses on executing tests and evaluation of results. In transition, particularly during acceptance testing, the Customer, Test Designer and Deployment Manager will collaborate during Workflow Detail: Achieve Acceptable Mission, to decide which test results are acceptable, whether to continue testing, and which tests must be repeated. |
| Deployment |
Deployment Planning (in Workflow Detail: Plan Deployment) at this stage in transition is concerned with establishing the schedule and resources (in the Artifact: Deployment Plan) for (continued) development of end-user support material, acceptance testing, and production, packaging and distribution of software deployment units. Beta testing has been completed in previous iterations in transition. The Deployment Manager also produces the Artifact: Bill of Materials in this workflow detail. Any remaining work to produce the Artifact: End-User Support Material (for example, user guides, operational guides, maintenance guides) and the Artifact: Training Materials is completed by the Role: Technical Writer and Role: Course Developer respectively, in Workflow Detail: Develop Support Material. Once the system is deemed fit, acceptance testing commences, managed by the Deployment Manager in Activity: Manage Acceptance Test. After successful testing at the development site, the Deployment Manager initiates the production of the deployment units (for installation at the customer's site), by producing the Artifact: Release Notes. These and the Artifact: Installation Artifacts, produced by the Role: Implementer, are input (with others) to the Activity: Create Deployment Unit (in the Configuration Management discipline). Frequently, at least a portion of acceptance testing is performed at the customer's site, usually after initial acceptance testing at the development site. In parallel with acceptance testing, the artwork for the product packaging is developed by the Role: Graphic Artist in Activity: Create Product Artwork. Finally, the deployment manager initiates the production of the product for distribution in Activity: Release to Manufacturing, and quality checks the result in Activity: Verify Manufactured Product, before the product is shipped. |
| Environment |
There should be little or no development work to be done on the environment by this stage, the work during transition should be almost wholly support and maintenance, in the Workflow Detail: Support Environment During an Iteration. |
| Configuration Management |
The configuration management activities continue in parallel with the remaining implementation and test with increasing emphasis on the formality of change control. The Artifact: Deployment Unit is created in Workflow Detail: Manage Baselines and Releases, by the Configuration Manager, as a precursor to final product packaging. All requests for change will require sanction by a project-level CCB (and the customer) during transition, as part of Workflow Detail: Manage Change Requests. Finally, as part of acceptance, it is usually necessary to do a Functional Configuration Audit (FCA) and a Physical Configuration Audit (PCA) in Activity: Perform Configuration Audit. |
Result
This final iteration in the transition phase culminates in the delivery to the customer of a complete system (and ancillary support artifacts) with functionality and performance as specified, and demonstrated in acceptance testing. The customer takes ownership of the software after a successful acceptance test.
