Point-Counterpoint

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

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.