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

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, retest everything, retest to an operational profile, or retest 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:

• Validate Build Stability - execute a subset of tests to validate that the build is stable enough for detailed test and evaluation effort to commence.
• Test and Evaluate - tests are implemented, executed, and evaluated
• Achieve Acceptable Mission - test results are evaluated against testing objectives. Additional testing is done as necessary.
• Improve Test Assets - test artifacts are improved as needed to support the next cycle of testing.

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 focusses 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.