SMU CSE 7315 Planning and Managing a Software Project

Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project ManagementCSE7315 M36 - Version 9.01

SMU CSE 7315Planning and Managing a Software Project

Module 36

Details of the SEI CMM and CMMI

Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project ManagementCSE7315 M36 - Version 9.01 2

Objective of This Module

To examine the SEI CMM (capability maturity model) and CMMI (capability maturity model integrated) in further detail

Note: a thorough discussion of these models would require a half day or more – there are

many commercially available short courses on this subject.

Note: a thorough discussion of these models would require a half day or more – there are

many commercially available short courses on this subject.


Structure of the CMM and the "Staged" version of the CMMI

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity


Structure (continued)

“Each level comprises a set of process goals that, when satisfied, stabilize an important component of the process.

“Achieving each level of the maturity framework establishes a different component in the process, resulting in an increase in the process capability of the organization.”

As one moves up the levels, one exhibits greater maturity and capability and one EXPECTS to achieve better performance

As one moves up the levels, one exhibits greater maturity and capability and one EXPECTS to achieve better performance


Effects of Higher Levels

At higher levels, one expects the following characteristics:

Better visibility into what is happening

Less variability in outcomes

Less risk associated with software development, due to more accurate planning and better management


Better Visibility

Level 1Input Output

Level 2 Process Step



Input Output





Lower Variability / Less Risk

Level 1

Level 2

Level 3

etc.


What kind of Model is the CMM or CMMI?

The CMM/CMMI is a descriptive model and a normative model

A descriptive model acts as an example or a paradigm or an ideal

– A model home

– A fashion model

A normative model acts as a way to compare two or more instances of something

– A model of the human body

– A model of an automobile engine


Descriptive Model The model describes essential (or key)

attributes that would be expected to characterize an organization at a particular maturity level.

– Example: an organization at level 3 has documented its process for configuration management

One can use these attributes to evaluate one’s organization or to establish goals for an organization

– Example: if we do not document our process for CM, we are probably not at level 3

– If we want to be at level 3, we should probably document our process for CM


Uses of the Models

Appraisal teams will use the models to identify strengths and weaknesses in the organization.

– The SEI has defined processes for doing self-assessments and other forms of appraisals

Evaluation teams will use the models to identify the risks of selecting among different contractors for awarding business and to monitor contracts.

– The SEI has defined processes for doing capability evaluations

– There are many less extensive ways the models can be used to evaluate contractors


Uses (continued)

Managers and technical staff will use the models to understand the activities necessary to plan and implement a software process improvement program for their organization

– The models are sometimes followed too rigidly, but the goals tend to be universally applicable

Process improvement groups, such as an EPG [engineering process group], will use the models as a guide to help them define and improve the engineering processes in their organization.


Use as A Normative Model

The detailed practices in the models characterize the normal types of behavior that would be expected in an organization doing large-scale projects, such as those found in a government contracting context.

A given organization can compare itself with the models to determine how it “stacks up” with what is considered an example of best practices.


Do These Models Fit a Small Organization?

There is considerable debate about the extent to which these practices should be expected in other kinds of organizations.

Watts Humphrey (1) has shown that the principles, if not always the specific practices, are applicable to

individual, single-person projects (very small scale) that are not in a government contracting mode

(1) Humphrey, Watts, A Discipline of Software Engineering, Addison Wesley, 1994.


The Principles Seem to Be Universally Applicable

The intent is that the models are at a sufficient level of abstraction that it does not unduly constrain how the development process is implemented by an organization

Rather, the models describe what the essential attributes of a process would normally be expected to be

One must keep this in mind when applying the CMM or CMMI


Structure of the CMMI (CMM)

Maturity LevelsMaturity Levels

(Key) Process Areas(Key) Process Areas

Common FeaturesCommon Features

Specific or Generic (Key)

Practices

Specific or Generic (Key)

Practices

Goals

Implementation

Infrastructureor Activities

ProcessCapability

Address

Describe

Achieve

Contain

Organized by

Contain

Indicate

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity

Specific or Generic Goals in

CMMI


Example

Level 2: RepeatableLevel 2:

Repeatable

SW Project PlanningSW Project Planning

Activities PerformedActivities Performed

DocumentedProcedure forSize Estimates

DocumentedProcedure forSize Estimates

Goal:

SW Estimatesare Documented

...

Implementation:

ImplementationActivities

Infrastructureor Activities

ProcessCapability:

DisciplinedProcess

Address

Describe

Achieve

Contains

Organized by

Contains

Indicate


Process Areas

Except for Level 1, each level of the CMMI is defined in terms of a series of Process Areas or PAs

Process areas indicate the areas an organization should focus on to improve its software process.

Process areas identify the issues that must be addressed to achieve a maturity level.

– Level 2 PAs are what you focus on when you are at level 1

– Level 3 PAs are what you focus on when you are at level 2

– And so forth.

Process AreasProcess Areas


Structure of PAs

Each process area identifies a

cluster of related activities

that, when performed collectively,

achieve a set of goals considered important for enhancing process

capability.

– Note that PAs are artificially associated with specific levels in the CMM

– In actual fact, each PA evolves as an organization moves up the maturity scale

Key Process AreasKey Process Areas


Continuous Model of CMMI

This is an alternative perspective that, instead of looking at maturity as a series of five levels (Staged model) looks, instead, at the maturity of each individual process area

This approach was originated in the systems engineering CMM, but is not as widely used as the Staged model


Staged Model Scorecard

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity

You are Level 3


Continuous Model Scorecard

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

1st Qtr

PA 1

PA 2

PA 3

PA 4

PA 5

PA 6

PA 7

PA 8

PA 9

PA 10

PA 11

PA 12

PA 13

PA 14

PA 15

PA 16

PA 17

PA 18

PA 19

etc.


PA DefinitionEach PA is defined in terms of the following:

Goals - why you do it - what you hope to achieve

– The goals signify the scope, boundaries, and intent of each key process area.

– Generic goals apply to all PAs; specific goals apply to specific PAs

Practices (generic or specific) - what you (typically) do to achieve the goals

– Infrastructure elements, such as policies or practices or resources

– Activities, such as reviews or processes



Achievement of PAs

Certain attributes indicate whether the implementation and institutionalization of a process area are effective, repeatable, and lasting.

The attributes are:

– Commitment to Perform

– Ability to Perform

– Activities Performed

– Measurement and Analysis

– Verifying Implementation



Commitment to Perform

Commitment to Perform describes the actions the organization must take to ensure that the process is established and will endure

– Example: establishing a policy that mandates a particular activity

We WILL do

this!


Commitment to Perform typically involves

establishing organizational policies

and demonstrating senior management sponsorship.

Commitment to Perform typically involves

establishing organizational policies

and demonstrating senior management sponsorship.


Ability to Perform

Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently


Boss

SEPGSW

Manager

Ability to Perform typically involves resources, organizational structures, and

training

Ability to Perform typically involves resources, organizational structures, and

training


Activities Performed

Activities Performed describes the roles and procedures necessary to implement a key process area


Activities Performed typically involve: -- Establishing plans and procedures, -- Performing the work, -- Tracking it, and -- Taking corrective actions as necessary

Activities Performed typically involve: -- Establishing plans and procedures, -- Performing the work, -- Tracking it, and -- Taking corrective actions as necessary


Measurement and Analysis

Measurement and Analysis describes the need to measure the process and analyze the measurements


Measurement and Analysis typically includes examples of the measurements

that could be taken to determine the status and effectiveness of the activities

performed.

Measurement and Analysis typically includes examples of the measurements

that could be taken to determine the status and effectiveness of the activities

performed.


Verifying Implementation

Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established


Verification typically encompasses reviews

and audits by management and software quality

assurance.

Verification typically encompasses reviews

and audits by management and software quality

assurance.


Practices

The specific and generic practices describe "what" is to be done

-- Example: a practice for risk management might be periodic evaluation of risks and the status of known risk areas

But they should not be interpreted as mandating "how" the goals should be achieved

PracticesPractices


Alternative Practices

Alternative practices may accomplish the goals of the key process area

The key practices should be interpreted rationally to judge whether the goals of the key process area are effectively, although perhaps differently, achieved.

PracticesPractices

Key Practice per CMMI Example

Key Practice for Our Situation


Reviewing the Five Levels for the Software Portion of the CMMI

The five levels correspond to Humphrey’s five levels (see text)

But the CMM and CMMI provide additional detail and many “best practices”

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity


Level 1- Initial

The software process is characterized as ad hoc, and occasionally even chaotic.

Few processes are defined, and success depends on individual effort (heroes).

Unstable environment is subject to catastrophe if key people leave

– “Bus sensitive projects”

Planning is ineffective -- reaction is the order of the day

Plans are routinely ignored or abandoned

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity

“You can be very successful, but you cannot count on it.”

“You can be very successful, but you cannot count on it.”


Level 2 - Repeatable

Basic project management processes are established to track cost, schedule, and functionality.

The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

Stability is present, even when heroes leave, so long as the overall environment is consistent

Everyone knows how to do it, although they do not always know why

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity

“You can expect consistent behavior.”

“You can expect consistent behavior.”


Process Areas for Level 2

Configuration Management

Project Planning

Process & Product Quality Assurance

Requirements Management

Supplier Agreement Management (**)

Project Monitoring and Control (**)

(*) Measurement and Analysis

(*) Was not in the CMM

(**) Different Title in the CMM


Level 3 - Defined

The process for both management and engineering activities is documented, standardized, and integrated into a standard process for the organization.

All projects use an approved, tailored version of the organization's standard process for developing and maintaining products.

People know why, not just how to do the job

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity

“You can expect stability in a changing environment.”

“You can expect stability in a changing environment.”


Process Areas for Level 3Part 1 – Similar to CMM

Organizational Process Focus

Organization Process Definition

Organizational Training

Integrated Project Management

Integrated Teaming

Organizational Environment for Integration

Technical Solution


Process Areas for Level 3Part 2 – New in CMMI (not found in CMM)

Requirements Development

Product Integration

Verification

Validation

Risk Management

Integrated Supplier Management

Decision Analysis and Resolution


Level 4 – Quantitatively Managed

Detailed measures of the process and product quality are collected.

Both the process and products are quantitatively understood and controlled.

Decisions are based on fact

Process behavior is quantified

Processes are instrumented to facilitate data collection

Measurements are applied across the organization so that norms and exceptions can be identified

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity



Quantitative Project Management

-- Metrics are defined, collected, analyzed and acted upon to improve the project

Organizational Process performance

-- Metrics are defined, collected, analyzed and acted upon to improve the process


Level 5 - Optimizing

Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity



Causal Analysis and Resolution

– You not only find defects, you correct or remove the process steps that cause them

Organizational Innovation and Deployment

– You insert technology in an orderly and managed fashion

– New methods and tools do not disrupt performance


A Closer Look at a Few Parts of CMMI Level 2

Configuration Management

Project Planning

Quality Assurance

Requirements Management

Supplier Agreement Management

Project Monitoring and Control

Measurement and Analysis

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity


We Will Review Two of the PAs

Requirements Management and Supplier Agreement Management have not been discussed very much in the course up until now

So we will examine what the CMMI has to say about them

The other PAs have been discussed in the course, and are discussed further in other courses


Requirements Management TYPICAL SYMPTOMS

The product is “perfect,” but the customer doesn’t like it

– Often because the developers “know what’s best for the customer”

Finger pointing

– Multiple versions of the requirements

– Multiple interpretations of the requirements

The system will not integrate

– The parts do not fit together

– Some functions are duplicated in software & hardware

– Some functions are missing entirely


Requirements Management PA

Purpose:

To establish a common understanding between the customer and the software project

Practices:

– Reaching agreement on the requirements

– Documenting the requirements

– Controlling changes to the requirements

– Communicating changes to the requirements

– Allocating requirements - to software, hardware, etc. - in a clear, unambiguous manner


Requirements ManagementGoals I

1.System requirements allocated to software or other disciplines are controlled to establish a baseline

– Requirements may come directly from the customer on a software-only project

– Requirements may come from a system engineering function on a hardware & software project

– “Controlled” means you don’t change without approval and communication


Requirements ManagementGoals II

2.Plans, products and activities are kept consistent with the requirements

– If you change the requirements, you must consider changing the plans, etc.


Sample Behaviors System engineer or project lead:

– Allocates requirements to all parts of the system

Don’t forget support, installation, documentation, etc.

Include platform selection, network configuration, and other tasks that are not part of software development

– Controls and communicates changes

May use a system configuration control board

– Listens to understand the impact of changes


Sample Behaviors (continued)

Software manager:

– Participates in system configuration control process

– Determines the impact of changes on software cost and schedule

– Communicates the impact to affected parties (system engineers, customers, program managers, etc.)


Sample Behaviors (continued)

Software engineers:

– Review requirements (and changes)

– Communicate the cost/impact of requirements/changes

– For example, which modules need to be redesigned, recoded, retested, etc.

– (This works best if the software engineer can document the estimated cost and schedule impact of each change.)


Special Issues - I The basic responsibility for requirements

management may lie outside of the software engineering function

– Software may be only part of a larger system product

– Many large projects use a system engineer responsible for design, control and integration of the whole system

Subsystem(segment)

Subsystem(segment)

Subsystem(segment)

Product or Item(configuration

item)


item)


item)

System

Subsystem(segment)

Requirements Management Responsibility

Requirements Implementation Responsibility

}

}


Special Issues - II

The symptoms of poor requirements management tend to show up toward the end of the project -- when it costs the most to fix the problems

– Often the fixes require extensive software changes, but the “fault” may lie outside the software function


Special Issues - III The cost of proper requirements

management comes at the front end of the project

Integrate& Test

Design theArchitecture& Allocate

Requirements

Buildthe

System

AnalyzeRequirements

The penalty for improper requirements management comes at the back end



TYPICAL SYMPTOMS

They were supposed to deliver it today. They just called and told us

they have a three month delay!

They always delivered on

time in the past!


More Typical Symptoms

We’ve been hit by a $25,000 fine because our user interface does not meet EPA standards.

The supplier did not know

about the regulations.

The big cost will be the

recall - about $200,000


Further Typical Symptoms

They delivered the software

module, but no test cases and no documentation

The contract was vague on

this point.

They thought that was our

responsibility.



Purpose:

– To select qualified suppliers

– To manage suppliers effectively

Practices:

– Establish policies for supplier management

– Select suppliers based on ability to do the job

– Communicate effectively with suppliers

– Document commitments

– Flow down standards, processes, etc.

– Track and review supplier performance and results.


Supplier Management -- Goals

1. Select qualified suppliers

– Include software management in selection process

2. Agree to commitments

– Get them in writing

3. Maintain ongoing communication

4. Track performance against commitments

– Reviews, audits, etc.


Sample Behaviors

Program manager:

– Includes software manager in software supplier selection process

– Establishes policies and procedures for managing suppliers

Software manager and subcontract manager:

– Track supplier schedule, effort, size, risks, etc.

– Take corrective action when there are significant deviations from plan

– Hold periodic reviews of supplier project status


Special Issues

Suppliers may not like to be reviewed and audited

– Diplomacy, tact, and firm management skills are needed

– A cooperative approach based on mutual goals for quality can lead to more openness and more accurate information

– Standards and regulations can provide leverage in negotiations

“We trust you, but ISO 9000 requires that we do an audit”


Special Issues

Other parts of your own company are suppliers too!

– They may not require all the formality, but the principles are still the same:

Statement of work, commitment, tracking, etc.


Module Summary

The CMM and CMMI can be used as a descriptive or a normative model

Each level has process areas and other common elements

The level 2 process areas are fundamental to good management and correspond to major sections of this course


END OF

MODULE 36

Date post:	01-Jan-2016
Category:	Documents
Upload:	hilda-brooks
View:	27 times
Download:	2 times

SMU CSE 7315 Planning and Managing a Software Project

Documents