Category list

Interpreting the CMMI (R): A Process Improvement Approach, Second Edition - page 50

Summary

This chapter covers some of the things to consider when combining or aligning multiple process improvement initiatives. Considerations include process improvement team structure, integration of existing procedures, measurement programs, and training programs. Different improvement models have placed different levels of importance on some of these areas. This has naturally resulted in different levels of implementation across the disciplines.

None of the ideas presented in this chapter are difficult to understand. Mainly, they concern understanding the policies, processes, procedures, plans, courses, and people you currently have in place, understanding how they fit together within the expanded scope of the CMMI, and the vision the organization has created for its process improvement journey.

While we have presented these concepts in a simple, straightforward fashion, this effort actually will take many hours of hard work. Do not underestimate the level of effort required to successfully accomplish these tasks .

Notes

1. Chapter 16 is our "meat and potatoes" chapter on policies, processes, and procedures that will give you more details on some of these concepts, along with Chapter 14 that discusses documentation guidelines.

2. Measures in this section refer to both base and derived measures. Base measures are simple values of some attribute, for example, the size of a document in pages or effort to produce a document in hours. Derived measures are defined to be a function of two or more base measures, for example, productivity in hours per page to produce a document.

3. We really do mean many, but not all. We have had the opportunity to work with both systems and acquisition program that exhibit high measure maturity but these are the exceptional cases; and while it may be politically incorrect to talk about software success and systems and acquisition, we think it is important to share our experiences.

Chapter 10: Is the CMMI Right for Small Organizations?

Overview

This chapter presents two viewpoints concerning implementing the CMMI within a small organization. A small organization is defined as an organization with 20 or fewer technical personnel developing systems. In a small organization, it is not uncommon for a project to consist of three people. One individual may serve as the project manager, developer, and tester; another individual may serve as a coder , tester, and database administrator; and the third individual may serve as a part-time quality assurance representative. The project may only last from three to six weeks.

A point-counterpoint approach is presented to discuss the pros and cons associated with various issues and their operational impacts. The reader should be somewhat familiar with both the CMMI effort and the previous models developed by the Software Engineering Institute (SEI).

The authors of this book do not make any claims as to these arguments. We believe the readers should be able to make up their own minds.

Definitions

Before continuing, let us discuss some basic terms to avoid any confusion later.

Systems Engineering

There seems to be no real agreement as to what systems engineering really is. The Systems Engineering Capability Maturity Model, version 1.1, states that "Systems Engineering is the selective application of scientific and engineering efforts to:

Transform operational need into descriptions of the system configuration which best satisfies operational need according to measures of effectiveness
Integrate related technical parameters and ensure compatibility of all physical, functional, and technical program interfaces in a manner that optimizes total system definition and design
Integrate efforts of all engineering disciplines and specialties into the total engineering effort."

The definition of Systems Engineering from the draft version 0.5 of the Systems Engineering Capability Model EIA 731-1 states that "Systems Engineering is an inter-disciplinary approach and means to enable the realization of successful systems."

The CMMI v1.1 defines Systems Engineering as:

The interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a product solution, and support that solution, throughout the product's life. This includes the definition of technical performance measures , the integration of engineering specialties towards the establishment of a product architecture, and the definition of supporting life-cycle processes that balance cost, performance, and scheduled objectives.

What do these definitions mean as they relate to CMMI? Basically, Systems Engineering covers the development of total systems, which may or may not include software. Systems Engineering integrates all parts , areas, personnel, and characteristics of a project that are necessary to produce a completed system for delivery to the customer. Projects may begin with feasibility, cost-benefit, and concept of operations analyses to justify any subsequent software or non-software activities.

Software Engineering

This covers the development of software-focused systems. Projects begin once a software project manager is assigned and funding has been received. Software Engineering may be a subset of Systems Engineering or it may stand alone as its own area of focus. It is possible to have some systems that are entirely made up of software-only tasks .

Integrated Product and Process Development

This covers the usage of large product development teams , with each team member focusing on specific areas of expertise. Each team's results are then integrated into one product.

Acquisition

This covers the identification of a need, selection of vendors , and monitoring their ability to produce the system according to contract constraints.

The Staged Model Representation

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

This is the architecture in use by the Software CMM. This structure focuses an organization's improvement activities on undertaking the practices depicted in each process area (PA) within each level. For example, an organization would choose to attain Level 2 (by satisfying the goals for each process area in Level 2) before trying to undertake Process Areas in levels 3, 4, or 5. Each level provides the foundation for further improvements. This representation begins with basic management practices, and continues with increasingly sophisticated focus areas that belong within a specific level. Practices reside within Process Areas within levels. There are five maturity levels, each serving as process boundaries.

Staged models provide guidance to organizations on the order of improvement activities they should undertake, based on (Key) Process Areas at each stage/maturity level. Performing practices in the appropriate process area at a given level will help stabilize projects, thus allowing the execution of further improvement activities. Incremental improvement is supported in each maturity level/stage because that stage contains a collection of process areas on which to focus current activities. ^[1]

The Continuous Model Representation

This is the architecture in use by the systems engineering models. This structure focuses process improvement on actions to be completed within process areas. Organizations are expected to select the process areas of interest to them. Processes may span different levels and are grouped by functional categories. More sophistication in implementing the practices for each process area is expected at the different levels. There are six capability levels, which group process areas into functional categories of increasing evolution.

Continuous models provide more flexibility in defining process improvement programs. They recognize that individual Process Areas are performed at distinct capability or maturity levels. Organizations need to perform an analysis of how the various process areas address the needs of the organization. This exercise also provides an opportunity to gain consensus on the sequence of improvement activities that are appropriate to the organization as a whole. ^[2]

Maturity Levels

These belong to the Staged Representation. These apply to an organization's overall process capability and organizational maturity. Each maturity level comprises a predefined set of process areas and generic goals. There are five maturity levels, numbered 1 through 5. These components suggest a recommended order for approaching process improvement in stages by grouping process areas into actionable groups. ^[3]

Capability Levels

These belong to the Continuous Representation. These apply to an organization's process improvement achievement for each process area. There are six capability levels, numbered 0 through 6. Capability levels focus on maturing an organization's ability to perform, control, and improve its performance in a process area. ^[4] These levels enable an organization to track, evaluate, and demonstrate an organization's progress as it improves its processes associated within a specific process area. A recommended order of process improvement is also suggested by these levels, due to the groupings of the process areas into functional categories.

SCAMPI

This stands for Standard CMMI Assessment Method for Process Improvement, an assessment technique that is similar to both the former CBA-IPI and Software Capability Evaluation methods . SCAMPI uses the CMMI as its reference model. (See Chapter 11 for more information.)

Small Organizations

This encompasses those organizations having 20 or fewer people, in total, supporting software or system development. Each member of a project may wear several hats (i.e., may perform several different roles) as part of normal daily tasks. Projects are short-lived, that is, between three and six weeks.

^[1] Capability Maturity Model (CMM) for Software, version 1.1.

^[2] Capability Maturity Model Integration (CMMI) for Systems Engineering (SE)/Software Engineering (SW)/Integrated Product and Process Development (IPPD), version 1.1.

^[3] Architectural and Functional Comparison of the CMMI Model Representation, Draft, Mike Konrad and Sandy Shrum, December 1999.

^[4] Expanding the Focus of Software Process Improvement to Include Systems Engineering, Kent Johnson and Joe Dindo, TeraQuest Metrics, Incorporated, Crosstalk, October 1998.

Buy on amazon.com >>

Kulpa M. K., Johnson K. A.

<< Previous page

Table of contents

Next page >>