Integrated Product Life Cycle Management for Software: CMMI1, SPICE, and ISO/IEC 20000

Integrated Product Life Cycle Management for Software: CMMI1, SPICE, and ISO/IEC 20000

Dirk Malzahn
DOI: 10.4018/978-1-60566-008-0.ch024
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

This chapter describes how models for software development and service delivery can be integrated into a common approach to reach an integrated product life cycle for software. The models covered by this chapter are the capability maturity model integration (CMMI), SPICE (software process improvement and capability determination, ISO 15504) and ISO 20000 (service management). Whilst the CMMI constellation approach delivers an integration perspective defined in three models (development, acquisition and services), SPICE and ISO 20000 need additional alignment to be usable in an integrated approach.
Chapter Preview
Top

Background

The Wall Between Software Development and Service Delivery

When IT systems are planned, the focus of the planning is mostly restricted to software development. Topics like operation environment or data management are discussed, but the strategy usually ends with the delivery of the software product.

On the other hand, service-delivering organizations mostly just provide “services” and are not really interested in the software development process.

This behavior leads to multiple difficulties and inefficiencies:

  • Software developers and service people do not understand each other. They work in different worlds and have their own “language” and processes.

  • The efficiency and effectiveness of service delivery highly depends on the architecture of and assumptions for the software, therefore the service organization has to be integrated early into the software development.

  • Service level agreements can be optimized, when both sides reach a common understanding. The development of service level agreements is often based on the “what we need” position of both sides and not on the “what will be best for the customer” position.

  • Problem Management is not transparent to the customer. The customer is not interested whether he has a service problem or a software problem—the customer wants a quick and reliable solution. If the software side does not understand the service side, problems often become ping-pong balls.

  • Software usually lives longer than the original developer intends. Systems often have to be enhanced just to fulfil the requirements of a new service platform. If this is not taken into account when the software is developed, the effort for updating software may become enormous. Sometimes software has to be retired, just because it is not executable on the new platform!

  • New approaches like service oriented architectures (SOA) demand the high integration of software and service elements. Future trends will rather lead to small combined software/service environments than to big software solutions operated by massive computer environments.

Just to ensure that I am not misunderstood: software developing and service delivering organizations will still deliver and operate solutions with high quality—but the will not do it in the most efficient and effective way. Organizations and companies aiming for the delivery of sustainable and reliable solutions have to ensure, that the solutions are not only developed in the best way but will meet the requirements of the future efficiently, effectively and still with high quality.

Complete Chapter List

Search this Book:
Reset