slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Brief Presentation on Software Process Improvement using the CMM Framework and How Some Development Corporations See Th PowerPoint Presentation
Download Presentation
Brief Presentation on Software Process Improvement using the CMM Framework and How Some Development Corporations See Th

Loading in 2 Seconds...

play fullscreen
1 / 31

Brief Presentation on Software Process Improvement using the CMM Framework and How Some Development Corporations See Th - PowerPoint PPT Presentation


  • 145 Views
  • Uploaded on

Brief Presentation on Software Process Improvement using the CMM Framework and How Some Development Corporations See Themselves… (in Jacksonville) Robert F. Roggio Pratibha Kashyap . Background / Previous Work.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Brief Presentation on Software Process Improvement using the CMM Framework and How Some Development Corporations See Th' - houston


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Brief Presentation on

Software Process Improvement using the CMM Framework

and

How Some Development Corporations See Themselves…

(in Jacksonville)

Robert F. Roggio

Pratibha Kashyap

31

background previous work
Background / Previous Work

This is a presentation emanating from a follow on paper to research conducted and reported on at the Pacific Northwest Software Quality Conference, October, 2000. The paper and this presentation were extracted from Pratibha’s project for her M.S.

Survey and resulting statistics came from a survey in a large metropolitan city in the South – two large, two medium, and two small software developers – based on numbers of developers

Built questionnaire based primarily on the CMM and its Key Process Areas (KPAs) and Key Practices (key terms in the CMM)

Reported results

Please note: There are newer and different versions of the CMM. These slides reflect the ‘first’ CMM Framework. Nevertheless, the thrust of the CMM slides presented herein still apply.

31

overview
Overview
  • 1. Introduction to the CMM
      • Maturity Levels, Key Process Areas, and other terms in the CMM architecture.
  • 2. Self-Organizational Assessment
  • 3. Survey Instruments and Process
  • 4. Factors affecting Software Process

Improvement (SPI)

31

capability maturity model cmm
Capability Maturity Model (CMM)
  • CMM – a framework/model for undertaking continuous process improvement of an organization’s software process.
  • Organizations are assessed as to the ‘maturity’ their software process exhibits.
  • Maturity levels consist of sets of process goals such that when satisfied, stabilize an important component of their software process.
    • Higher the level implies an increased process capability.
    • The framework prioritizes improvement actions for increasing software process maturity.
    • This all implies that an organization’s process must be ‘assessed.’

31

slide5

Lot of key words here…

Materials taken directly (or

almost directly) from The

Capability Maturity Model –

Guidelines for Improving the

Software Process, by several

authors most of whom are

affiliated with the SEI.

31

what do the level names mean
What do the level names mean?
  • Level 1: Initial Level:
    • Software processes ad hoc; sometimes chaotic. Laissez-faire.
    • Successes dependent upon individual(s) and heroics.
    • Few processes, if any, are defined.
    • Repeatable? only if same people assigned
    • Capability is a characteristic of the individuals and not the organization

31

maturity levels cmm
Maturity Levels - CMM
  • Level 2: Repeatable Level:
    • Basic projectmanagement processes:
      • established to track cost, schedule, and functionality.
    • A necessary process discipline in place.
      • repeat earlier successes on projects w/similar applications.
    • Software process capability (Level 2 organizations) Summarized as disciplined
    • Planning and tracking of project is stable
    • Earlier successes can be repeated.
    • Project’s process - under the effective control of a project management system w/realistic plans based on the performance of previous projects.
    •  Emphasis: Project Management

31

maturity levels continued
Maturity Levels (continued)
  • Level 3 – Defined Level:
    • The softwareprocess for both management and engineering activities is documented, standardized, andintegrated into a standard software process for the organization.
    • All projects use an approved, tailoredversion of the organization’s standard software process for developing and maintaining software.
    • An organization-wide training program is implemented to ensure that the staff and managers have the knowledge and skills required to fulfill their assigned roles.

31

level 3 defined continued
Level 3 – Defined (continued)
  • Level 3 – Defined (continued)
    • Projects tailor the organization’s standard software process to develop their own defined software process, for unique characteristics of a project.
      • This tailored process is referred to in the CMM as the project’s defined software process.
      • This defined software process contains a coherent, integrated set of well-defined software engineering and management processes.
    • A well-defined process will include:
      • readiness criteria,
      • inputs,
      • standards and
      • procedures for performing the work,
      • verification mechanisms (such as peer reviews),
      • outputs, and
      • completion criteria.

31

level 3 defined continued10
Level 3 – Defined (continued)
  • Level 3 – Defined (continued)
    • Because process is welldefined, management has good insight into technical progress on the project.
    • Characteristics:
      • The software process is standard and consistent with both software engineering and management activities
      • Stable and repeatable.
    • The process capability is based on a common, organization-wide understanding of the activities, roles, and responsibilities in a defined software process.

31

maturity levels continued11
Maturity Levels (continued)
  • Level 4 – Managed:
    • Organization’s set quantitative quality goals for both software products and processes.
    • All projects part of an organizational measurement program.
    • The capability is quantifiable and predictable because the process is measured and operates within quantitative limits.
    • Because process - both stable and measured - exceptional circumstances can address ‘special causes’ of the variation.
    • When predefined limits are exceeded, actions are taken to understand and correct the situation.
    • Software products are of predictably high quality.

31

maturity levels continued12
Maturity Levels (continued)
  • Level 5 – Optimized
    • Focus: continuous process improvement
    • At the Optimizing Level, the entire organization is focused on continuous process improvement.
      • The organization has the means to identify weaknesses and strengthen the process proactively, with the goal of preventing the occurrence of defects.
    • Innovations that exploit the best software engineering practices are identified and transferred throughout the organization.
    • These organizations continuously strive to improve the range of their process capability, thereby improving the process performance of their projects.

31

structure of the model
Structure of the Model
  • The CMM is a framework representing a path of improvements recommended for software organizations that want to increase their software process capability.
  • The model describes essential (key) attributes that would be expected to characterize an organization at a particular maturity level.
  • A maturity level is a well-defined evolutionary plateau toward achieving a mature software process.
  • The five maturity levels provide the top-level structure of the CMM.
    • Each level indicates a level of process capability.

31

slide14

Structure of the Model

Top level…

Lots of key terms!!

31

key process areas
Key Process Areas
  • ‘Maturity levels’ contain several KPAs
  • Each KPA has a set of goals that must be satisfied to satisfy that KPA.
  • KPAs address a cluster of related activities (Key Practices - ahead) that, collectively when addressed, achieve a set of goals.
  • Key Practices are the ‘whats’ (not hows) that must be satisfied to meet the goals of a specific maturity level.

31

slide16

Optimizing

Key Process Areas (KPAs)

by Maturity Level

Defect Prevention

Technology Change Management

Process Change Management

Managed

Quantitative Process Management

Software Quality Management

Levels and their

respective KPAs

are shown.

Defined

Organization process focus

Organization process definition

Training Program

Integrated Software Management

Software Product Engineering

Intergroup coordination

Peer Reviews

Notice Level 3

More to do with

Process Management

(also organizational thrust)

Notice Level 2

More to do with

Project Management

When the Key Practices

for each KPA are satisfied,

the goals for that KPAs

are met. For a given

maturity level,

all KPAs must be satisfied.

Repeatable

Requirements Management

Software Project Planning

Software project tracking and oversight

Software subcontract management

Software Quality Assurance

Software Configuration Management

31

Initial

key practices for a kpa
Key Practices for a KPA
  • Each KPA - described in terms of Key Practices.
  • Satisfying the Key Practices = essential to meeting the goals of that KPA.
    • Equivalently, key practices describe the activities and infrastructure that contribute most to the effective implementation and institutionalism of the KPA.
  • Important to note: Key Practices evolve as organization achieves higher level of maturity.
  • They do NOT go away.
  • A level-3 shop satisfies all KPAs of a level-2 shop

31

key practice evolution example
Key Practice – Evolution Example
  • Many of the project estimating capabilities described in the Software Project Planning KPA at Level 2 must evolve to handle additional project data available at Level 3, described in Integrated Software Management, a level 3 KPA
  • Key Practices describe WHAT is to do – not how. Again, satisfaction of KP necessary to meet goal of KPA.
  • Each Key Practice consists of a single sentence often followed by a more detailed description, which may include examples and elaboration.

31

2 organizational self assessment
2. Organizational Self-Assessment
  • Now a bit of Student Research
    • 65 companies; 55 responses – with pressure!
  • Ms. Pratibha Kashyap surveyed a number of business in Jax
    • Size: (Six: two of each ‘size’, where size based on number of developers)
    • Self-perceptions as to how theymet the maturity levels (hence KPAs and then Key Practices…)
  • Analysis of their perceptions

31

slide20

Organization's Position at CMM Level-2

5.0

4.0

3.0

Range (1-Never

Thru 5-Always)

2.0

1.0

0.0

1

2

3

4

5

6

Organizations

Requirements management

Project Planning

Project Tracking

Software Quality Assurance

Configuration Management

Key Process Areas for Level 2

31

slide21

Organization's Position at CMM Level-3

5.0

4.0

3.0

Range (1-Never thru 5-Always)

2.0

1.0

0.0

1

2

3

4

5

6

Organizations

Key Process Areas for Level 3

Organization Process Focus

Software Process Definition

Training program

Integrated Software Management

Software Product Engineering

Inter-group Coordination

31

Peer Reviews

Defects are Tracked

slide22

KPAs:

Organization's Position at CMM Level-4

Quantitative

4.0

Process

Management

3.0

Measurable

2.0

Range (1-Never thru 5-Always)

Quality Goals

1.0

are defined

0.0

Progress

1

2

3

4

5

6

towards these

Goals are

Organizations

tracked

31

slide23

Organizations' Position at CMM Level-5

4.0

3.5

3.0

Range (1-Never thru 5-Always)

2.5

2.0

1.5

1.0

0.5

0.0

1

2

3

4

5

6

Organizations

Defect Prevention activities are planned

Common Causes of Defects are Identified

Technology Change Management

Appropriate New Technologies are transferred in to normal practice

Process Change Management to improve continually

KPAs:

Key Process Areas for Level 5

31

3 survey instruments and process
3. Survey Instruments and Process
  • Instruments divided into components administered to
    • Project Leaders and to
    • Developers.
    • Sometimes both.
  • Designed to ascertain their perceptions of how well these companies perceived themselves satisfying the KPAs of the individual levels via the Key Practices.

31

slide26

* Are software processes, procedures, and standards defined (what and how), documented, validated for correctness, practiced (used), improved (new technology) etc.

Figure 3. Section 2 of Survey (Developers and Management)

31

slide29

Graph 7 - Factors Affecting Business Goals

35

30

25

20

Number of Responses

15

10

5

0

Budget Overrun

Rework due to

Scope changed

Missed Schedule

Customer satisfaction

Poor Productivity due to

Poor Quality products due to

Affected Areas

Poor Estimates

Poor Planning

Poor requirements

Poor Skills

Poor Design

Poor Coding

Poor QA

Poor Inspections

Poor Reviews

31

slide30

4. Factors Affecting

  • Software Process Improvement (SPI)
  • Management’s commitment and support
  • Dedicated group
  • Projects driven by schedule
  • Personal involvement in overseeing
  • Middle management’s involvement
  • Organizational structure and politics

31