chapter 4 interpreting the cmm. group (3) fahmi alkhalifi pam page pardha mugunda

Chapter 4

Interpreting the CMM

Group (3)

Fahmi AlkhalifiPam PagePardha Mugunda

CMM

Commonsense application of process management and quality improvement concepts to software development and maintenance.

Written to address the process of large, complex software efforts.

Broad-based agreement by software community of good engineering and management practices.

Interpreting Key Practices

Provide a description of essential elements of an effective software process.

Set principles that apply to variety of projects and organizations and a range of typical software applications.

Although it’s meant to be independent, organizations should map these conventions appropriately to their own projects and business environments.

Terminologies

Activity: Any step taken or function performed, both mental or physical, toward achieving some objectives. Activities include all the work the managers and technical staff do to perform the tasks of the project and organization.

Audit: An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria.

Commitment: A pact (agreement) that is freely assumed, visible, and expected to be kept by all parties.

Terminologies – Cont.

Configuration management: A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

Goals: A summary of the key practices of a key process area that can be used to determine whether an organization or project has effectively implemented the key process area. The goals signify the scope, boundaries, and intent of each key process area.


Key practices: The infrastructure and activities that contribute most of the effective implementation and institutionalization of a key process area.

Key process area: A cluster of related activities that, when performed collectively, achieve a set of goals considered to be important for establishing process capability.

Managed and controlled: The process of identifying and defining software work products that are not part of a baseline and therefore are not placed under configuration management, but that must be controlled for the project to proceed in a disciplined manner.


Orientation: An overview or introduction to a topic for those overseeing or interfacing with the individuals responsible for performing in the topic area.

Periodic review: A review that occurs at specified, regular time interval.

Procedure: A written description of a course of action to be taken to perform a given task.

Process: A sequence of steps performed for a given purpose, e.g. software development process


Role: A unit of defined responsibilities that may be assumed by one or more individuals.

Software work product: Any artifact created as part of defining, maintaining, or using a software process. They can include process descriptions, plans, procedures, computer programs, and associated documentation, which may or may not be intended for delivery to a customer or end user.

Key Process Area TemplateNotes:

Goals and common features are delimited by headers.

e.g. Goals, Commitments to Perform Key practices labeled with noun (common

feature) and a number. e.g. Commitment 1, Ability 2

Key practices are in Bold type. e.g. A group that is responsible for <X> exists.

Sub-practices preceded by preamble. e.g. key practices that include “according to a

documented procedure” are preceded by “This procedure typically specifies that:”

Practices may be followed by boxed text. e.g. elaboration or cross-reference

<Key Process Area X>a key area for Level n: <Level name>

The purpose of <Key Process Area X> is <Statement>.

<Key Process Area X> involves <summary>.<Additional elaboration on Key Process Area X as appropriate.>

GoalsGoal 1 <Process summary statement as goal.>Goal 2 <Process summary statement as goal…>

Commitment to PerformCommitment 1 The project follows written organizational

policy for <X>.

orThe organization follows a written policy

for <X>.This policy typically specifies that:1. <Sub-practices for Commitment 1…>

Ability to PerformAbility 1 A group that is responsible for <X> exists.

1. <Sub-practices for Ability 1…>Ability 2 Adequate resources and funding are provided for

<X>.1. Tools to support activities for <X> are made

available.

Ability 3 <Roles> are trained <to perform their X activities>.

or<Roles>receive required training<to perform X

activities>.

Ability 4 <Roles> receive orientation in <X>.

Examples of <X> tools include: <examples of tools>

Examples of training include: <examples of training>

Examples of orientation include: <examples of orientation>

Activities PerformedActivity 1 <Activity performed in Key Process Area X.>

1. <Sub-practice for Activity 1, possibly affecting different groups.>

2. <Additional sub-practices for Activity 1…>3. <Software work products, as appropriate> are

placed under configuration management.

Activity 2 <Activity performed in Key Process Area X> according to documented procedure.

This procedure typically specifies that:

Examples of affected groups include: <list of affected groups>

Refer to the Software Configuration Management key process area. Chapter (7).

1. <Sub-practice for Activity 2, possibly cross reference(s) to key practice(s) in another key process area.>

2. <Additional sub-practices for Activity 2…>3. <Software work products> undergo peer review <according to appropriate criteria>.

4. <Software work products, as appropriate> are managed and controlled.

Refer to Activity N of the <Z> key process area for practices <related to Activity 2.1>.

Refer to the Peer Reviews key process area. Chapter 8

“Managed and controlled” implies that the version of the work product in use at a given time (past or present) is known (i.e. version control), and changes are incorporated in a controlled manner (i.e., change control).If a greater degree of formality than is implied by “managed and controlled” is desired, the work product can be placed under the full discipline of configuration management, as is described in the Software Configuration Management key process area.

Measurement and AnalysisMeasurement 1 Measurements are made and used to determine

status of the activities for <X>.

Verifying ImplementationVerification 1 Activities for <X> are reviewed with senior

management on a periodic basis.1. <Sub-practices for Verification 1…>

Verification 2 Activities for <X> are reviewed with the project manager on both a periodic and event-driven basis.

1. <Sub-practices for Verification 2…>Verification 3 Software quality assurance group reviews and/or

audits the activities and work products for <X> and reports the results.

At a minimum, these reviews and/or audits verify that:1. <Sub-practices for Verification 3…>

Examples of measurements include: <measurement examples>

Refer to Software Quality Assurance key process area. Chapter 7

Interpreting the Common Features

Commitment to PerformAbility to PerformActivities PerformedMeasurement and AnalysisVerifying Implementation


Commitment to Perform Policy Statements

Written, organizational policy for practices of the key process areas


Leadership Assigns leadership roles to key process

areas or describes sponsorship activities that are required for the key process area to be successfully institutionalized


Ability to Perform - the preconditions in the project or organization necessary to implement the software process competently Organizational Structures Resources and Funding Training

Orientation Prerequisites


Organizational Structures May need to develop independence or

objectivity that may require developing into a special group


Resources and Funding Access to special skills Adequate funding Access to tools


Training Informal or formal

Classroom, videos, computer-aided or a formal mentor and apprenticeship programs

Different organizational situations will drive the training needs


Orientation Overview

Prerequisites Items expected to be obtained from

outside the realm of the software project


Activities Performed: Types of Plans

Informal Plans Formal Plans

Documented Procedures System requirements Customer-supplier relationship

Internal External


Tracking and taking corrective action vs. managing

Reviewed vs. undergoes peer reviews Placed under configuration

management vs. managed and controlled


Measurement and Analysis Quality of the training program Effectiveness of management Functionality and quality of software

products


Verifying Implementation Senior management oversight on a

periodic basis Project management oversight

Periodic basis Event-driven basis

Software quality assurance activities

Organizational Structure and Roles

Organizational Roles Manager Senior manager Project manager Project software manager First-line software manager Software task leader Staff, software engineering staff, individuals


Organizational Structure Organization Project Group


CMM referred groups: Software engineering group Software related groups Software engineering process group System engineering group System test group Software quality assurance group Software configuration management group Training group

Independence and Organizational Structure

Independence should provide: Those individuals should be the “eyes

and ears” of senior management Protect the individuals from adverse

personnel actions Provide senior management with

confidence on results of the project

Understanding Software Process Definition

Process Definition Concepts

Requirements that define what process is to be described,

An architecture and design that provide information on how the process will be defined,

Implementation of the process design in a project or organizational situation,

Validation of the process description via measurement, and

Deployment of the process into wide spread operation within the organizational or project for which the process is intended

Concepts Related to the Organization’s Software Process Assets

Software process assets are a collection of entities maintained by an organization, for use by projects in developing, tailoring, maintaining, and implementing their software process.Any entity that the organization considers useful in performing the activities of process definition and maintenance could be included as a process asset.

Organization’s Software Process Assets

The organization establishes and maintains a set of software process assets.The organizations standard software process,The description of software life cycles approve for use,The guidelines and criteria for tailoring the organization’s standard software process.

Organizations Standard Software Process

An organizations standard software process is the operational definition of the basic process that guide the establishment of a common software process across the software projects in the organization.

Software Process Architecture

The software process architecture is a high level description of the organization’s standard.

Software Process Element

A software process element is a constituent of a software process description.

Description of Software Life Cycles Approved for Use

A software life cycle is the period of time that begins when a software product is conceived and ends when the software is no longer available for use.

Concepts Related to the Project’s Defined Software Process

Description of projects defined software processStagesTasksActivitiesSoftware work productsSoftware products

The Evolution of Processes

The management process category contains the project management activitiesThe organizational process category contains the cross process responsibilities.The engineering process category contains the technical activities such as requirement analysis, design, code, and test.

Applying Professional Judgment

Professional judgment is necessary for interpreting the key practices and how they contribute to the goals of a key area.To provide complete set of valid principles that apply to a wide range of situations, the key practices are intentionally stated to allow for flexibility.


The goals of the key process areas provide a structure for making the interpretation.Professional judgment is used to determine whether a specific interpretation or implementation satisfies the goals of key area.


What are the criteria for a mature software process?It is Defined Documented Trained Practiced Supported


Both maturity and effectiveness should be interpreted in the context of the business environment and the specific circumstances of the project and the organization.

chapter 4 interpreting the cmm. group (3) fahmi alkhalifi pam page pardha mugunda

Documents