CSC 508 Lecture Notes Week 10

CSC 508 Lecture Notes Week 10
Final Customer Interviews
CMM -- The Capability Maturity Model




  1. Proposed meetings for Nov 30, Dec 1:

  2. Leftovers from Week 9 lecture notes.

  3. Software process assessment using the Capability Maturity Model (CMM)

    1. CMM has been developed at Carnegie Mellon since around 1987; it is still undergoing refinement.
    2. The five CMM levels (in order of increasing maturity) are:

      1. Initial -- ad hoc
      2. Repeatable -- basic project management techniques are used
      3. Defined -- a software engineering process is used
      4. Managed -- quantitative Q/A process is used
      5. Optimizing -- the process itself can be refined to improve efficiency

    3. Improvements claimed for more mature processes:

      1. More reliable software
      2. Better visibility into process, particularly from top-level management perspective
      3. Less risk in contracting with firms that have a mature process in place.

  4. Details of the five CMM levels

    1. Level 1: completely ad hoc
    2. Level 2:

      1. Requirements management
        1. Goal 1: System requirements allocated to software are controlled to establish a baseline for software engineering and management use.
        2. Goal 2: Software plans, products, and activities are kept consistent with the system requirements allocated to the software.

      2. Project planning
        1. Goal 1: Software estimates are documented for use in planning and tracking the software project.
        2. Software project activities and commitments are planned and documented.
        3. Goal 3: Affected groups and individuals agree to their commitments related to the software project.

      3. Project tracking and oversight
        1. Goal 1: Actual results and performances are tracked against toe software plans.
        2. Goal 2: Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.
        3. Goal 3: Changes to software commitments are agreed to by the affected groups and individuals.

      4. Subcontract management
        1. Goal 1: The prime contractor selects qualified software subcontractors.
        2. Goal 2: The prime contractor and the software subcontractor agree to their commitments to each other.
        3. Goal 3: The prime contractor and the software subcontractor maintain ongoing communications.
        4. Goal 4: The prime contractor tracks the software subcontractor's actual results and performance against its commitments.

      5. Software quality assurance
        1. Goal 1: Software quality assurance activities are planned.
        2. Goal 2: Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.
        3. Goal 3: Affected groups and individuals are informed of software quality assurance activities and results.
        4. Goal 4: Noncompliance issues that cannot e resolved within the software project are addressed by senior management.

      6. Configuration management
        1. Goal 1: Software configuration management activities are planned.
        2. Goal 2: Selected software work products are identified, controlled, and available.
        3. Goal 3: Changes to identified software work products are controlled.
        4. Goal 4: Affected groups and individuals are informed of the status and content of software baselines

    3. Level 3

      1. Organization process focus
        1. Goal 1: Software process development and improvement activities are coordinated across the organization.
        2. Goal 2: The strengths and weaknesses of the software processes used are identified relative to a process standard.
        3. Goal 3: Organization-level process development and improvement activities are planned.

      2. Organization process definition
        1. Goal 1: A standard software process for the organization is developed and maintained.
        2. Goal 2: Information related to the use of the organization's standard software process by the software projects is collected, reviewed, and made available.

      3. Training program
        1. Goal 1: Training activities are planned.
        2. Goal 2: Training for developing the skills and knowledge needed to perform software management and technical roles is provided.
        3. Goal 3: Individuals in the software engineering group and software-related groups receive the training necessary to perform their roles.

      4. Integrated software management
        1. Goal 1: The project's defined software process is a tailored version of the organization's standard software process.
        2. Goal 2: The project is planned and managed according to the project's defined software process.

      5. Software product engineering
        1. Goal 1: The software engineering tasks are defined, integrated, and consistently performed to produce the software.
        2. Goal 2: Software work products are kept consistent with each other.

      6. Intergroup coordination
        1. Goal 1: The customer's requirements are agreed to by all affected groups.
        2. Goal 2: The commitments between the engineering groups are agreed to by the affected groups.
        3. Goal 3: The engineering groups identify, track, and resolve intergroup issues.
      7. Peer reviews
        1. Goal 1: Peer review activities are planned.
        2. Goal 2: Defects in the software work products are identified and removed.

    4. Level 4

      1. Quantitative process management
        1. Goal 1: The quantitative process management activities are planned.
        2. Goal 2: The process performance of the project's defined software process is controlled quantitatively.
        3. Goal 3: The process capability of the organization's standard software process is known in quantitative terms.

      2. Software quality management
        1. Goal 1: The project's software quality management activities are planned.
        2. Goal 2: Measurable goals for software product quality and their priorities are defined.
        3. Goal 3: Actual progress toward achieving the quality goals for the software products is quantified and managed.

    5. Level 5

      1. Defect prevention
        1. Goal 1: Defect prevention activities are planned.
        2. Goal 2: Common causes of defects are sought out and identified.
        3. Goal 3: Common causes of defects are prioritized and systematically eliminated.

      2. Technology change management
        1. Goal 1: Incorporation of technology changes are planned.
        2. Goal 2: New technologies are evaluated to determine their effect on quality and productivity.
        3. Goal 3: Appropriate new technologies are transferred into normal practice across the organization.

      3. Process change management
        1. Goal 1: Continuous process improvement is planned.
        2. Goal 2: Participants in the organization's software process improvement activities is organization wide.
        3. Goal 3: The organization's standard software process and the projects' defined software processes are improved continuously.

  5. A technologist's view of how to build quality software

    1. The developers of CMM focus almost exclusively on the management aspects of the software process, not the technical aspects.

      1. From their perspective, proper management is far more important to achieving quality software than is proper software engineering technology.
      2. Technologists tend to believe the opposite (but this belief is probably mistaken).
      3. For example, when technologists read that
        "CMM does not currently address expertise in particular application domains, advocate specific software technologies, or suggest how to select, hire, motivate, and retain competent people."
        technologists view CMM of limited utility when it comes to assessing what it really takes to build quality software.

    2. So, if we assume that a mature software process is in place, here is one technologist's view of the the top ten things that really count for achieving quality software:
      1. A good requirements specification, produced with copious end-user feedback.
      2. Thorough and formal test procedures at all levels of development.
      3. The 7+/-2 hierarchy rule, 25-public-operation rule, and 25-line rule,
      4. A document-as-you-go policy, where document commentary is written with the following question in mind: "What will I need to know when I come back here in six months and want to understand what's going on?"
      5. Thoughtfully written version control log messages and/or explicit log files.
      6. One set of conventions per project, and one extremely nasty manager to enforce them.
      7. Thorough and formal revision control procedures, including readily accessible access to at least the last three working versions of the system.
      8. Teamwork, including frequent critical reviews.
      9. Good specification and design roadmaps, in whatever diagraming style(s) you like.
      10. Real deadlines.

        Honorable Mentions
      11. Emacs
      12. Top-of-the-line Sparc workstation
      13. Sleep deprivation when necessary
      14. High-quality junk food

        Noteworthy Omissions
      • Any particular methodology, object-oriented or otherwise; just choose one and stick with it.
      • Any particular programming language; just choose one (except for Visual Basic) and stick with it.

    3. These are among the things we will attempt to put into practice next quarter.