Operate

Deploy

Build

Design

Requirements

This is the phase during which the requirement s for a new application are gathered, based on the business needs of the organization. This phase is active primarily during the Service Design phase of the ITSM Lifecycle.

There are six types of requirements for any application, whether being developed in-house, outsourced or purchased:

• Functional requirements are those specifically required to support a particular business function
• Manageability requirement s, looked at from a Service Management perspective, address the need for a responsive, available and secure service, and deal with such issues as deployment, operations, system management and security
• Usability requirements are those that address the needs of the end user, and result in features of the system that facilitate its ease of use
• Architectural requirements, especially if this requires a change to existing architecture standard s
• Interface requirements, where there are dependencies between existing application s or tools and the new application
• Service Level Requirement s, which specify how the service should perform, the quality of its output and any other qualitative aspects measured by the user or customer.

This is the phase during which requirements are translated into specification s. Design includes the design of the application itself, and the design of the environment, or operational model that the application has to run on. Architectural considerations are the most important aspect of this phase, since they can impact on the structure and content of both application and operational model. Architectural considerations for the application (design of the application architecture) and architectural considerations for the operation model (design of the system architecture) are strongly related and need to be aligned.

In the case of purchased software, most organizations will not be allowed direct input to the design of the software (which has already been built). However, it is important that Application Management is able to provide feedback to the software vendor about the functionality, manageability and performance of the software. This will, in turn, be taken up by the software vendor as part of the continual improvement of the software.

Part of the evaluation process for purchased software should include an evaluation of whether the vendor is responsive to such feedback. At the same time, they should ensure that there is a balance between being responsive and changing their software so much that it is disruptive or that it changes some basic functionality.

Design for purchased software will also include the design of any customization that is required. Of special importance here is an evaluation of whether future version of the software will support the customization.

In the Build phase, both the application and the operational model are made ready for deployment. Application component s are coded or acquired, integrated and tested.

Please note that Test is not a separate stage in the lifecycle, even though it is a discrete activity, and even though tests are conducted independently of both the development and operational activities. Without the Build and Deploy phases, there would be nothing to test and, without testing, there would be no control over what is developed and deployed.

Testing is an integral component of both the Build and Deploy phases as a validation of the activity and output of those phases – even if it uses different environment s and staff. Testing in the Build phase focuses on whether the application meets its functionality and manageability specifications. Often the distinction is made between a development and test environment. The test environment allows for testing the combination of application and operational model. Testing is covered in the ITIL Service Transition publication.

For purchased software, this will involve the actual purchase of the application, any required middleware and the related hardware and networking equipment. Any customization that is required will need to be done here, as will the creation of tables, categories, etc. that will be used. This is often done as a pilot implementation by the relevant Application Management team or department.

In this phase, both the operational model and the application are deployed. The operational model is incorporated in the existing IT environment and the application is installed on top of the operational model, using the Release and Deployment Management process described in the ITIL Service Transition publication.

Testing also takes place during this phase, although here the emphasis is on ensuring that the deployment process and mechanisms work effectively, e.g. testing whether the application still function s to specification after it has been downloaded and installed. This is known as Early Life Support and covers a pre-defined guarantee period that testing, validation and monitoring of a new application or service during that period occurs. Early Life Support is covered in detail in the Service Transition publication.

In the Operate phase, the IT service s organization operates the application as part of delivering a service required by the business. The performance of the application in relation to the overall service is measured continually against the Service Level s and key business driver s. It is important to distinguish that applications themselves do not equate to a service. It is common in many organizations to refer to applications as ‘services’; however, applications are but one component of many needed to provide a business service.

The Operate phase is not exclusive to applications and is discussed throughout this publication, with a more detailed list of activities given in section 6.5.5 below.

Дата добавления: 2014-12-23