There are number of direct and indirect relationships between ITUP processes and RUP disciplines. These indirect
or direct relationships are called "touch points". They are described briefly on this page. For
more detailed information, see information about "RUP with ITSM/ITUP Connection" at the following page:
http://www.ibm.com/developerworks/rational/downloads/07/rmc_v7.2/itsm_connection/.
Capacity Management Touchpoint
Determine performance characteristics for an application
During the requirements definition and design of an application being developed, modeling and sizing should be
performed by Capacity Management to determine the performance characteristics of the application.
Change Management Touchpoint
Change Management Change Requests may spawn application development
Change Requests that are submitted to Change Management may initiate application development. This may
initiate development of new applications or updates to existing applications.
Application development should be aware of these Change Requests. This information may create further insights into
what should be developed.
The Change Management process should monitor development that is in response to a Change Request.
New application releases may initiate new Change Requests for deployment
Once a new version of an application has been released, a Change Request should be submitted to Change Management
to deploy the release. If development is done internally, this may be performed by the development
team. If the application was developed by a vendor, then the Change Request should be submitted by the
Supplier Relationship Management process.
Known errors feed development requirements and design
During Problem Management, application errors may be discovered. These known errors may be a valuable source of
information to application requirements and design teams by helping to identify errors or weaknesses that should be
fixed in the next release. In addition, Problem Management may initiate Change Requests in Change Management
to address known errors related to an application.
In addition, application development teams may either perform or help in the diagnosing of application errors
during Problem Management.
Proposed new service may initiate application development
An IT customer may propose a new service to the Service Level Manager, who normally maintains a catalog of existing
services. When a new service is submitted, it becomes a Change Request in Change Management. If new
application development is needed for this new service, a new application development project must be
initiated.
Emergency changes may require subsequent maintenance
Emergency changes are high-priority changes that must be implemented immediately without a full understanding of
all ramifications. This is because the risk of not making the change is considered to be very high. However,
because emergency changes are often made without a full assessment of the ramifications, undesirable side-effects
may occur. When this happens, subsequent changes, including application patches, may be necessary.
Configuration Management Touchpoint
Test environment should mirror production environment
During application testing, a test environment should be created that mirrors the production environment. This
means that the testing team should use information in the CMDB to determine the characteristics of targeted
configuration items in the production environment and attempt to duplicate those conditions. This includes labeling
configuration item (CI)s in the test environment in the same way as the
production environment.
Problem Management Touchpoint
Development known bugs become known errors
Before release of an application, a number of bugs will be known to exist in the completed application. The
documentation of these known bugs are examined by Problem Management proactively to uncover previously unknown
errors and reactively to determine the root cause behind an existing problem. These known bugs are documented as
known errors by Problem Management.
Release Management Touchpoint
Putting approved software applications in the DML
After a software system has completed development and is accepted for internal use, a "golden" copy of the software
may be put into the Definitive Media Library (DML) for use by Release Management. This
library allows for secure storage of approved software.
Service Execution Touchpoint
Instrumenting applications for monitoring
Operational software applications are monitored by the IT operations to monitor and ensure service levels.
Applications that are instrumented for monitoring during development are much easier to monitor. Thus,
software development should include consideration for monitoring during requirements and design.
In addition, operational monitoring data collected during the operation of an application may be useful feedback
for an application development team in the following ways:
-
Identification of monitoring weaknesses
-
Identification of unreported errors
-
Identification of tuning and efficiency opportunities
Service Level Management Touchpoint
Service levels and development requirements
The results of monitoring service levels may be useful for development. Specifically, services that fail to
meet target service levels may require enhancements to applications that help provide that service.
Conversely, non-functional requirements identified during application development may also provide a basis for
service level targets. For instance, if an application has a requirement to provide access to 500 simultaneous
users, then an SLA for a service based on that application may have that capacity target.
|
