Capability Pattern: Transition Phase Iteration |
Activities performed in a typical iteration in Transition phase, the involved roles and main objectives.
| Description |  | Work Breakdown Structure |  | Team Allocation |  | Work Product Usage |  |
Relationships
Context | OpenUPBasic
Description
#### Introduction In Transition, most activities happen in parallel. The main objectives are to fine-tune functionality, performance and overall quality of the beta product “released” at the end of Construction phase. Below you find the activities performed in a typical iteration during Transition phase. ##### Manage Iteration Similar to other phases: an activity led by the Project Manager (in collaboration with the team) to launch the iteration, to allocate work, to track status, and to handle risks and issues. It’s unlikely that risks of high impact will happen during Transition, but it is recommended that the Project Manager and team identify any potential issues while delivering the product to the end-users. ##### Ongoing Tasks Submission of change requests during Transition works differently than in other phases. New requirements will rarely be identified at late stages of the software development lifecycle in a way they can be implemented in the current release. If there are enhancement requests though, they can be captured in the Work Items List and allocated to a future release, when a new software development lifecycle begins. In that opportunity, requirements will be outlined and detailed accordingly. However, defects are typically dealt with during Transition, thus a stable release can be accepted by user community. In the case there is general agreement from Stakeholders, correction of low priority defects can be postponed to subsequent evolutionary releases. ##### Develop Solution (for requirement) (within context) During Transition, most requirements will have been already implemented and validated, which is the focus of the previous phase. Nevertheless, there may be a few, low priority requirements that could be accommodated into the release being developed. Despite of that, enhancement requests and defects found in previous iterations may need to be allocated to Developers. This is when this activity gets performed (for each change request or requirement within a given context) and allocated to Developers. ##### Validate Build This activity happens in parallel with development of solution for enhancement request and defects (and possibly remaining requirements), in order to make sure a stable release can be presented to the users community. Users can be involved in performing tests to accept the release. ##### Assess and close-out project Results are assessed against phase objectives, and Stakeholders concurrence about the project objectives is obtained. The team conducts a retrospective review in order to capture lessons learned and make improvements to the process for next projects. The project is then closed.
Properties
Event-Driven |
Multiple Occurrences |
Ongoing |
Optional |
Planned |
Repeatable |
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright