Planning
Plans for release and deployment will be linked into the overall Service Transition plan and adopt the selected release and deployment model. The approach is to derive a sound set of guidelines for the release into production and subsequent deployment that can be scaled from small organizations to large multinationals. Although smaller organizations will have less complex environments, the disciplines detailed here are still relevant. Even within a single organization, the release and deployment plans need to be scalable since the extent of their scale of impact on the organization will vary, perhaps from impacting only one small specialist team in one location through to multinational impact on all users when introducing new desktop equipment and services, or transferring services to
different suppliers. Release and deployment plans should be authorized through Change Management. They should define the:
- · Scope and content of the release
- · Risk assessment and risk profile for the release
- · Organizations and stakeholders affected by the release
- · Stakeholders that approved the change request for the release and/or deployment
· Team responsible for the release
· Approach to working with stakeholders and deployment groups to determine the:
· Delivery and deployment strategy
· Resources for the release and deployment
· Amount of change that can be absorbed.
Pass/fail criteria
Service Transition is responsible for planning the pass/fail situations. At a minimum these should be defined for each authorization point through the release and deployment stage. It is important to publish these criteria to relevant stakeholders well in advance to set expectations correctly. An example of a pass situation before build and test is:
- · All tests are completed successfully; the evaluation report and RFC for build and test are signed off. Examples of fail situations include:
- · Insufficient resources to pass to the next stage. For example, anautomated build is not possible and so the resource requirement becomes error-prone, too onerous and expensive; testing identifies that there will not be enough money to deliver the proposed design in the operations phase.
- · Service Operation does not have capabilities to offer particular serviceattributes.
- · Service Design does not conform to the service operation standards for technologies, protocols, regulations, etc.
- · The service cannot be delivered within the boundaries of the design constraints.
- · Service acceptance criteria are not met.
- · Mandatory documents are not signed off.
- · SKMS and CMS are not updated, perhaps due to a process that ismanually intensive.
- · The incidents, problems and risks are higher than predicted, e.g. by over 5%.
Build and test prior to production
Build and test planning establishes the approach to building, testing and
maintaining the controlled environments prior to production. The activities
include:
- · Developing build plans from the SDP, design specifications andenvironment configuration requirements
- · Establishing the logistics, lead times and build times to set up theenvironments
- · Testing the build and related procedures
- · Scheduling the build and test activities
- · Assigning resources, roles and responsibilities to perform key activities,e.g.:
- · Security procedures and checks
- · Technical support
- · Preparing build and test environments
- · Managing test databases and test data
- · Software asset and licence management
- · Configuration Management – configuration audit, build and baseline management
- · Defining and agreeing the build exit and entry criteria.
 |
| Service V-model to represent configuration levels and testing |
Figure above provides an example of a model that can be used to represent the different configuration levels to be built and tested to deliver a service capability. The left-hand side represents the specification of the service requirements down to the detailed Service Design. The right-hand side focuses on the validation and test activities that are performed against the specifications defined on the lefthand side. At each stage on the left-hand side, there is direct involvement by the equivalent party on the right-hand side. It shows that service validation and acceptance test planning should start with the definition of the service requirements. For example, customers who sign off the agreed service requirements will also sign off the service Acceptance Criteria and test plan. The V-model approach is traditionally associated with the waterfall lifecycle, but is, in fact, just as applicable to other lifecycles, including iterative lifecycles, such as prototyping, RAD approaches. Within each cycle of the iterative development, the V-model concepts of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered
for the degree of integrity and competence that would justify release to the customer for trial and assessment. Further details on validation, testing and service evaluation are provided in sections 4.5 and 4.6. The test strategy defines the overall approach to validation and testing. It includes the organization of validation and testing activities and resources and can apply to the whole organization, a set of services or an individual service.
