Cmm Repeatable Project Management Processes by wpc52419


More Info
									     Brief Presentation on
Software Process Improvement
  using the CMM Framework
   How Some Development
Corporations See Themselves…
       (in Jacksonville)

      Robert F. Roggio
      Pratibha Kashyap
              31               1
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                                   2
   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                         3
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.’                                                 4
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
                         31                                5
                              affiliated with the SEI.
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                     6
            Maturity Levels - CMM
   Level 2: Repeatable Level:
    – Basic project management 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                              7
          Maturity Levels (continued)
   Level 3 – Defined Level:
     – The software process for both management
       and engineering activities is documented,
       standardized, and integrated into a standard
       software process for the organization.
     – All projects use an approved, tailored version
       of the organization’s standard software
       process for developing and maintaining
     – 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                      8
            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
                                  31                                9
        •   completion criteria.
        Level 3 – Defined (continued)
   Level 3 – Defined (continued)
     – Because process is well defined,
       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                             10
         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                           11
       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
                               31                               12
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                         13
Structure of the Model
                              Top level…
                              Lots of key terms!!

                         31                         14
          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                  15
    Key Process Areas (KPAs)                                    Defect Prevention
    by Maturity Level                                           Technology Change Management
                                                                Process Change Management

                                     Quantitative Process Management
Levels and their                     Software Quality Management
respective KPAs
are shown.
                                     Organization process focus
Notice Level 3                       Organization process definition
More to do with                      Training Program
Process Management                   Integrated Software Management
(also organizational thrust)         Software Product Engineering
                                     Intergroup coordination
Notice Level 2                       Peer Reviews
More to do with
Project ManagementRepeatable                                          When the Key Practices
                      Requirements Management                         for each KPA are satisfied,
                      Software Project Planning
                      Software project tracking and oversight         the goals for that KPAs
                      Software subcontract management                 are met. For a given
                      Software Quality Assurance
                      Software Configuration Management
                                                                      maturity level,
                                                                      all KPAs must be satisfied.
       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                             17
     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

   Each Key Practice consists of a single sentence often
    followed by a more detailed description, which may
    include examples and elaboration.
                               31                           18
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 they met the maturity
       levels (hence KPAs and then Key Practices…)

    Analysis of their perceptions

                             31                          19
             Organization's Position at CMM Level-2

Range (1-Never
Thru 5-Always)

                       1   2        3       4   5      6
Key Process Areas for Level 2
     Requirements management     Project Planning
     Project Tracking            Software Quality Assurance
     Configuration Management 31
                                              Organization's Position at CMM Level-3

        Range (1-Never thru 5-Always)
                                                 1      2        3          4       5       6
Key Process Areas for Level 3
  Organization Process Focus                                         Software Process Definition
  Training program                                                   Integrated Software Managemen
  Software Product Engineering                                       Inter-group Coordination
                                                                31 Defects are Tracked             21
  Peer Reviews
                                Organization's Position at CMM Level-4
Range (1-Never thru 5-Always)
                                  4.0                                Process
                                                                     Quality Goals
                                  1.0                                are defined

                                  0.0                                Progress
                                        1   2   3   4   5     6      towards these
                                                                     Goals are
                                                        31                           22
                                           Organizations' Position at CMM Level-5
Range (1-Never thru 5-Always)
KPAs:                                           1         2        3         4         5         6
                                Key Process Areas for Level 5
                                 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                     23
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                     24
31   25
* Aresoftware 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                                           26
31   27
31   28
                            Graph 7 - Factors Affecting Business Goals

Number of Responses

                                          Affected Areas

                      Poor Estimates   Poor Planning   Poor requirements
                      Poor Skills      Poor Design     Poor Coding
                      Poor QA          Poor Inspections Poor Reviews
                                               31                          29
            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              30
Thank You!

    31       31

To top