Requirements

This is the phase during which the requirements 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 requirements, 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 standards
• Interface requirements, where there are dependencies between existing applications or tools and the new application
• Service Level Requirements, which specify how the service should perform, the quality of its output and any other qualitative aspects measured by the user or customer.

Design

This is the phase during which requirements are translated into specifications. 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.

Build

In the Build phase, both the application and the operational model are made ready for deployment. Application components 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 environments 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.

Deploy

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

Date: 2014-12-29; view: 900