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 in Activity: Fix a Defect, 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

As with unit tests, the focus for subsystem and system level tests during transition is on the verification and validation of changes and the avoidance of regression. In addition, there will often be a requirement for formal acceptance testing, which usually involves a repeat of all or part of the system level tests. The planning for test during transition (in Workflow Detail: Plan Test) thus has to provide effort and resources for some level of continued test design and implementation in Workflow Details: Design Test and Implement Test (because there will be changes during transition); regression testing, for which the effort and resources will depend on the chosen approach (for example, retest everything, retest to an operational profile, or retest changed software), and acceptance testing, which should not require the development of new tests.

As defects are fixed and beta feedback incorporated, successive builds are tested (in Workflow Details: Execute Tests in Integration Test Stage and Execute Tests in System Test Stage) until the system is deemed fit to undergo acceptance testing (usually through a repeat of all or part of the system level tests in Workflow Detail: Execute Tests in System Test Stage). In transition, particularly during acceptance testing, the Customer, Test Designer and Deployment Manager will collaborate during Workflow Detail: Evaluate Test, 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.