Extreme Programming Perspectives

The Capability Maturity Model for Software [Paulk+1993; Paulk+1995] is a model for building organizational capability that has been widely adopted in the software community and beyond. The Software CMM is a five-level model that describes good engineering and management practices and prescribes improvement priorities for software organizations. The five maturity levels are summarized in Table 42.1

Table 42.1. An Overview of the Software CMM
Level Focus Key Process Areas
5: Optimizing Continual process improvement

Defect Prevention

Technology Change Management

Process Change Management
4: Managed Product and process quality

Quantitative Process Management

Software Quality Management
3: Defined Engineering processes and organizational support

Organization Process Focus

Organization Process Definition

Training Program

Integrated Software Management

Software Product Engineering

Intergroup Coordination

Peer Reviews
2: Repeatable Project management processes

Requirements Management

Software Project Planning

Software Project Tracking and Oversight

Software Subcontract Management

Software Quality Assurance

Software Configuration Management
1: Initial Competent people and heroics

The Software CMM is intended to be:

  • A commonsense application of process management and quality improvement concepts to software development and maintenance the CMM practices are not rocket science (even the statistical process control concepts at Levels 4 and 5 have been successfully applied in other industries for decades).

  • A community-developed guide input from hundreds of software professionals was solicited in developing the current release of the CMM.

  • A model for organizational improvement which implies a set of priorities that may differ from those of any specific project, but which have been proven effective in organizational transformation.

  • The underlying structure for reliable and consistent CMM-based appraisal methods assessments and evaluations based on the Software CMM are widely used by software organizations for improvement and by customers for understanding the risks associated with potential suppliers.

Although the CMM is described in a book of nearly 500 pages, the requirements to be a Level 5 organization can be concisely stated in 52 sentences: the goals of the 18 key process areas (KPAs) that formally describe the model. The practices, subpractices, and examples that flesh out the model are informative material that guide software professionals in making reasonable, informed decisions about the adequacy of a broad range of process implementations in environments as diverse as two- to three-person projects in a Web environment and 500-person projects building hard real-time, life-critical systems.

The informative material in the Software CMM is focused on large projects and large organizations, primarily in a custom development or maintenance environment. Even so, the degree of interpretation and tailoring required to use the CMM in radically different environments, such as small start-up companies, small projects, or e-commerce environments, is relatively minor so long as common sense is applied [Paulk1999; Johnson+2000]. The Software CMM's rating components are intended to be abstract enough to capture "universal truths" about high-performance software organizations, at least from a perspective of organizational excellence, and are listed in Table 42.2.

With the exception of Software Subcontract Management, which is not applicable if an organization does not do subcontracting, the key process areas and their goals should be applicable to any software organization. Companies that focus on innovation more than operational excellence may downplay the importance of consistency, predictability, and reliability, but performance excellence is important even in highly innovative environments. It is difficult to identify any goals in Table 42.2 that will not provide value to an organization, if thoughtfully implemented.

Table 42.2. Purpose and Goals of Software CMM Key Process Areas
Tag KPA Purpose and Goals
Maturity Level 2 Repeatable
Requirements Management … to establish a common understanding between the customer and the software project of the customer's requirements that will be addressed by the software project.
RM Goal 1 System requirements allocated to software are controlled to establish a baseline for software engineering and management use.
RM Goal 2 Software plans, products, and activities are kept consistent with the system requirements allocated to software.
Software Project Planning … to establish reasonable plans for performing the software engineering and for managing the software project.
SPP Goal 1 Software estimates are documented for use in planning and tracking the software project.
SPP Goal 2 Software project activities and commitments are planned and documented.
SPP Goal 3 Affected groups and individuals agree to their commitments related to the software project.
Software Project Tracking and Oversight … to provide adequate visibility into actual progress so that management can take effective actions when the software project's performance deviates significantly from the software plans.
SPTO Goal 1 Actual results and performance are tracked against the software plans.
SPTO Goal 2 Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.
SPTO Goal 3 Changes to software commitments are agreed to by the affected groups and individuals.
Software Subcontract Management … to select qualified software subcontractors and manage them effectively.
SSM Goal 1 The prime contractor selects qualified software subcontractors.
SSM Goal 2 The prime contractor and the software subcontractor agree to their commitments to each other.
SSM Goal 3 The prime contractor and the software subcontractor maintain ongoing communications.
SSM Goal 4 The prime contractor tracks the software subcontractor's actual results and performance against its commitments.
Software Quality Assurance … to provide management with appropriate visibility into the process being used by the software project and of the products being built.
SQA Goal 1 Software quality assurance activities are planned.
SQA Goal 2 Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.
SQA Goal 3 Affected groups and individuals are informed of software quality assurance activities and results.
SQA Goal 4 Noncompliance issues that cannot be resolved within the software project are addressed by senior management.
Software Configuration Management … to establish and maintain the integrity of the products of the software project throughout the project's software life cycle.
SCM Goal 1 Software configuration management activities are planned.
SCM Goal 2 Selected software work products are identified, controlled, and available.
SCM Goal 3 Changes to identified software work products are controlled.
SCM Goal 4 Affected groups and individuals are informed of the status and content of software baselines.
  Maturity Level 3 Defined
Organization Process Focus … to establish the organizational responsibility for software process activities that improve the organization's overall software process capability.
OPF Goal 1 Software process development and improvement activities are coordinated across the organization.
OPF Goal 2 The strengths and weaknesses of the software processes used are identified relative to a process standard.
OPF Goal 3 Organization-level process development and improvement activities are planned.
Organization Process Definition … to develop and maintain a usable set of software process assets that improve process performance across the projects and provide a basis for cumulative, long-term benefits to the organization.
OPD Goal 1 A standard software process for the organization is developed and maintained.
OPD Goal 2 Information related to the use of the organization's standard software process by the software projects is collected, reviewed, and made available.
Training Program … to develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently.
TP Goal 1 Training activities are planned.
TP Goal 2 Training for developing the skills and knowledge needed to perform software management and technical roles is provided.
TP Goal 3 Individuals in the software engineering group and software-related groups receive the training necessary to perform their roles.
Integrated Software Management … to integrate the software engineering and management activities into a coherent, defined software process that is tailored from the organization's standard software process and related process assets.
ISM Goal 1 The project's defined software process is a tailored version of the organization's standard software process.
ISM Goal 2 The project is planned and managed according to the project's defined software process.
Software Product Engineering … to consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.
SPE Goal 1 The software engineering tasks are defined, integrated, and consistently performed to produce the software.
SPE Goal 2 Software work products are kept consistent with each other.
Intergroup Coordination … to establish a means for the software engineering group to participate actively with the other engineering groups so the project is better able to satisfy the customer's needs effectively and efficiently.
IC Goal 1 The customer's requirements are agreed to by all affected groups.
IC Goal 2 The commitments between the engineering groups are agreed to by the affected groups.
IC Goal 3 The engineering groups identify, track, and resolve intergroup issues.
Peer Reviews … to remove defects from the software work products early and efficiently. An important corollary effect is to develop a better understanding of the software work products and of defects that might be prevented.
PR Goal 1 Peer review activities are planned.
PR Goal 2 Defects in the software work products are identified and removed.
  Maturity Level 4 Managed
Quantitative Process Management … to control the process performance of the software project quantitatively. Software process performance represents the actual results achieved from following a software process.
QPM Goal 1 The quantitative process management activities are planned.
QPM Goal 2 The process performance of the project's defined software process is controlled quantitatively.
QPM Goal 3 The process capability of the organization's standard software process is known in quantitative terms.
Software Quality Management … to develop a quantitative understanding of the quality of the project's software products and achieve specific quality goals.
SQM Goal 1 The project's software quality management activities are planned.
SQM Goal 2 Measurable goals for software product quality and their priorities are defined.
SQM Goal 3 Actual progress toward achieving the quality goals for the software products is quantified and managed.
  Maturity Level 5 Optimizing
Defect Prevention … to identify the cause of defects and prevent them from recurring.
DP Goal 1 Defect prevention activities are planned.
DP Goal 2 Common causes of defects are sought out and identified.
DP Goal 3 Common causes of defects are prioritized and systematically eliminated.
Technology Change Management … to identify new technologies (that is, tools, methods, and processes) and transition them into the organization in an orderly manner.
TCM Goal 1 Incorporation of technology changes is planned.
TCM Goal 2 New technologies are evaluated to determine their effect on quality and productivity.
TCM Goal 3 Appropriate new technologies are transferred into normal practice across the organization.
Process Change Management … to continually improve the software processes used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development.
PCM Goal 1 Continuous process improvement is planned.
PCM Goal 2 Participation in the organization's software process improvement activities is organization wide.
PCM Goal 3 The organization's standard software process and the projects' defined software processes are improved continuously.

Related

Категории