The Transition Phase

The transition phase of the tailored version of the PosoMAS sees a shift away from feature design and implementation to bug fixing, testing, and making the system production ready. At the end of the transition, the system will be delivered to the end users. The work breakdown structure of the phase can be found here and is depicted in Figure 1. One iteration has been performed in this phase with a focus on deployment.

Figure 1: The activity chart for the PosoMAS transition phase.

Plan and Manage Iteration

A total of 3 hours was alotted for the transition phase in the Project Plan. In this final phase, the objectives are to finalise the product and the necessary documentation, as indicated in the Iteration Plan. This is reflected in the Work Items List that no longer lists any design items. The Product Release Milestone encompasses the deployment of a fully functional intial release product satisfying all selected user requirements.

Since work focuses on release activities, only Prepare for Release was scheduled for this iteration and the Deployment Plan was refined to contain Release Communications and a Backout Plan as well as Infrastructure considerations and a time table.

The assessment of the transition phase iteration conducted in the simulated development effort revealed no issues. Work was finished within the alotted time frame.

Activities and Tasks	Work Products
Activity: Plan and Manage Iteration Task: Plan Iteration Task: Manage Iteration Task: Assess Iteration	Iteration Plan Work Items List (Start of Iteration) Work Items List (End of Iteration)

Prepare for Release

The tentative Deployment Plan created during the Construction phase was refined by going through the tasks in the Prepare for Release activity. The list of stakeholders affected by the release was updated to include only relevant stakeholders and Release Communications. These include the relevant features and the business value generated by these features for the individual stakeholders. Furthermore, the timing of deploying the software to the different nodes was refined. It now includes estimates of the rollout speed, considerations of integrated system tests, and estimates of a minimal deployed system capable of reaching the desired objectives.

Furthermore, a Backout Plan was developed to accompany the existing Release Risk Assessment and define how a rollback of the release could be conducted. Furtunately, due to the highly modular nature of the system, partial rollouts can be implemented to remove faulty or problematic components from the system easily. A fallback solution is always to deactivate remote control and let the power plants run at their own discretion as they would without the system being installed. This allows the deployment team and operations much leeway and makes a complete rollback virtually unnecessary in all but the most dire situations. Even if the system unexpectedly behaves hazardous (e.g., by destabilising the network frequency), deactivation of the offending features is an easy solution. Business value might not be realised in such a case but the current mode of operation will be able to stabilise the system.

Finally, a list of required infrastructure and a time table for the procurement and installation of this hardware was created. Naturally, in a real development effort, such considerations would have to be made much earlier so there is sufficient time to select and test the hardware and roll it out in the field.

Activities and Tasks	Work Products
Activity: Prepare for Release Review and Conform to Release Controls Install and Validate Infrastructure Develop Backout Plan Develop Release Communications	Deployment_Plan

Copyright

This material is made available under the Creative Commons—Attribution-ShareAlike License v3.0.