1 / 43

Chapter 4 Interpreting the CMM

Chapter 4 Interpreting the CMM. Cheng, Jing (2/04/04) Software School,Hunan University. Objectives. Interpreting the Key Practices Interpreting the KPA Template Interpreting the Common Features Organizational Structure and Roles Understanding Software Process

mandek
Download Presentation

Chapter 4 Interpreting the CMM

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 4 Interpreting the CMM Cheng, Jing (2/04/04) Software School,Hunan University

  2. Objectives • Interpreting the Key Practices • Interpreting the KPA Template • Interpreting the Common Features • Organizational Structure and Roles • Understanding Software Process • Definition • The Evolution of Processes • Using CMM with Good Judgment

  3. Provide a description of the essential elements of an effective software process. Describe the principles of SPI and leave their implementation to each organization, according to its culture and the expertise of its managers and technical staff. Organizations using the key practices should be aware of these conventions and map them appropriately to their own organization, project, and business environment. The Intention Of The Key Practices

  4. The KPA Template is a standard KPA Descriptor. It provides a generic “CMM” language for describing KPA Some key practices do not have to follow the template, such as SQA does not need Verifying implementation. The KPA Descriptor - Template

  5. Goals Signify the scope, boundaries and intent of each key process area. Common Features Commitment to perform Ability to perform Activity to perform Measurement and analysis Verifying implementation Attributes indicate if implementation of key process is effective, repeatable, and lasting Key Practices When implemented, help to satisfy the goals of that key process area Essential Elements in Template

  6. <LEVEL name= > <KPA name= > <GOALS><GOAL 1>…</GOAL 1><GOAL 2>….</GOAL 2></GOALS> <COMMON FEATURES> <COMMITMENT TO PEFORM> <COMMITMENT 1>…</COMMITMENT 1> </COMMITMENT TO PEFORM> <ABILITY TO PERFORM> <ABILITY 1>…. </ABILITY 1> <ABILITY 2>…. </ABILITY 2>…. </ABILITY TO PERFORM> <ACTIVITY TO PERFORM> <ACTIVITY 1>…</ACTIVITY 1> <ACTIVITY 2>…</ACTIVITY 2> </ACTIVITY TO PERFORM> <MEASUREMENT AND ANALYSIS> <MEASUREMENT 1>…. </MEASUREMENT 1> </MEASUREMENT AND ANALYSIS> <VERIFYING IMPLEMENTATION> <VERIFICATION 1>…</VERIFICATION 1> <VERIFICATION 2>…</VERIFICATION 2>…. </VERIFYING IMPLEMENTATION> </COMMON FEATURES> </KPA> </LEVEL> The KPA Descriptor - XML

  7. Policy statements: to emphasize the connection between organizational commitment and the process: (1) Organization Process Focus (2) Organization Process Definition (3) Training Program (4) Quantitative Process Management (5) Defect Prevention (6) Technology Change Management (7) Process Change Management Leadership: assignment of leadership role or particular sponsorship necessary for institutionalizing the key process area (1) Software Project Planning (2) Software Project Tracking and Oversight (3) Software Subcontract Management (4) Organization Process Focus (5)Technology Change Management (6) Process Change Management Commitment to Perform

  8. Organizational Structures: a particular organizational structure that supports The key process area (such as QA, CM) Resources and funding: for example access to special skills, adequate funding, and access to tools. Training: which may include formal as well as informal training and skill transfer mechanisms. Orientation: refer to less depth of skill or knowledge being transferred than would be expected via training. Prerequisite: the inputs required for a key process area (for example specific documents such as the project plan, or the output of another process, or delegation of responsibility). Ability to Perform

  9. Activities:roles and procedures necessary to implement a key process area and achieve its goals. Establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary. Types of plans:KPA includes two kind of plans (1) The formal plans: SP, SQA, SCM, SSM, TP, ISMP, QPM, SQM, PCM (2) The informal plans: Organization Process Focus, Intergroup Coordination, Peer Reviews, Defect Prevention, Technology Change Management Informal plans are usually described by a single key practice. Most of KPA contain one or more key practices that describe activities performed according to a documented procedure. System requirements allocated to software. Customer-supplier relationship Tracking and taking corrective action versus managing Reviewed versus undergoes peer review Placed under configuration management versus managed and controlled (1) version control (2) change control Activities Performed

  10. Basic measurement practices that are necessary to determine status related to the process. Other measures such as (1) functionality (2) quality of training (3) effectiveness of management (4) quality software products Measurement and Analysis

  11. Senior management oversight on a periodic basis: to gain awareness of, and insight into, software process activities at an appropriate level of abstraction and in a timely manner. Project management oversight: on both a periodic and event-driven basis at a more detailed level reflecting project management’s more active involvement in the operational aspects of a project. Software quality assurance: in the form of review/audit by the software quality assurance group or an independent group. Verifying Implementation

  12. Organization Roles

  13. Organizational Structure

  14. Groups in the CMM

  15. To avoid technical or organizational biases which may affect the quality or risks associated with the project. To ensure effective operation independence To ensure software testing without developers’ effect. To ensure software quality audit, SQA jobs, without being influenced by project schedule and cost pressure. Why KP Call For Independence?

  16. The SQA group has a reporting channel to senior management that is independent of the project manager, the project’s software engineering group, and the other software-related groups. The (system and acceptance) test cases and test procedures are planned and prepared by a test group that is independent of the software developers. Examples of Independence

  17. Provide the individuals performing the SQA role with the organizational freedom to be “eyes and ears” of senior management on the project. Protect the individuals performing the SQA role from adverse personnel actions when there is a need to escalate deviation outside the project. Provide senior management with confidence that objective information on the process and products of the project is being reported. Benefits of SQA Independence

  18. Software process definition is fundamental for achieving higher levels of maturity. A fundamental concept that supports the approach taken by SEI in its process definition work is that processes can be developed and maintained in a way similar to the way products are developed and maintained . Process Definition Concepts

  19. Help guide software professionals through alternative means of software production in an order way. Provide organizations with a consistent framework while permitting individual adjustment to unique needs. Process definitions help software professionals understand what they should do, what they can expect from their co-workers and what they are expected to provide in return. Defining Software Process Why (1)?

  20. DEMING “Operational definitions are something everyone can communicate about and work to”. Process standardization helps reduce problems of training, review and tool support With standard methods, each project’s experiences can contribute to overall process improvement Provide the basis for process and quality measurements Defining Software Process Why (2)? Source: “Managing the Software Process”, Watts Humphrey

  21. 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 widespread operation within the organization or project for which the process is intended. Process Development Discipline

  22. Software process assets are a collection of entities maintained by an organization, for use by projects in developing, tailoring, maintaining, and implementing their software processes. 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

  23. Note: The Figure from SEI Tech Report “Key Practices of the Capability Maturity”, V.1.1, by Mark C. Paulk, …

  24. The software process assets include: the organization’s standard software process (including the software process architecture and software process elements), the descriptions of software life cycles approved for use, the guidelines and criteria for tailoring the organization’s standard software process, the organization’s software process database, and the library of software process-related documentation. Organization’s Software Process Assets

  25. The Base of The Processes Capability Maturity Model Framework Organization’s standard software Process Software Process element Software Process element Software Process element Software Process element Software Process element Process 1 Process 2 Process N ………..

  26. Software Process Architecture System Engineering Process Architecture Software Process element Software Process element Software Process element Hardware Engineering Software Process element Software Process element Contract Management Interface Concrect Software Processes

  27. A software process element is a constituent element of a software process description. Each process element covers a well-defined, bounded, closely related set of activities, such as (1) software estimating element (2) software design element (3) implementation element (4) peer review element (5) ? Software Process Elements

  28. A software life cycles is the period of time that begins when a software product is conceived and ends when the software is no long available for use. The software life cycle typically includes: (IEEE-STD-610) (1) concept stage (2) requirements stage (3) design stage (4) implementation stage (5) test stage (6) installation and checkout stage (7) operation and maintenance stage (8) retirement stage Description of Software Life Cycles Approved for Use

  29. The organization’s standard software process is described at a general level that may not be directly usable by a project. Therefore the guidelines and criteria are needed for tailoring the SSP. Guidelines are established to guide the software process in (1) selecting a software life cycle from those approved for use (2) tailoring and elaborating the organization’s standard software process and the selected software life cycle to fit the specific characteristics of the project. These guidelines and criteria help ensure that there is a common basis across all software projects for planning, implementing, measuring, analyzing, and improving the projects’ defined software processes and the organization’s SSP. Guidelines And Criteria for Tailoring

  30. The purpose of the OSPD is to collect and make available data on the software processes and resulting software work products, particularly as they relate to OSSP. Examples of process and work product data include (1) estimates of software size, effort, and cost (2) actual data on software size, effort, and cost (3) productivity data (4) peer review coverage and efficiency (5) number and severity of defects found in the software code (6) ? Organization’s Software Process Database

  31. A library of software process-related document is established to Store process documents that are potentially useful to other current and future projects, particularly as they relate the OSSP. Make them available for sharing across the organization. Examples may cover artifacts such as (1) a project’s defined software process (2) standards, such as coding standard (3) procedures, such as building procedure, loading procedure (4) software development plans (5) measurement plans (6) process training materials Library of Software Process Related Documents

  32. At the organization level, the OSSP needs to be described, managed, controlled, and improved in a formal manner. At the project level, the emphasis is on the usability of the project’s defined software process and the value it adds to the project. It includes (1) Description of project’s defined software process (2) Stages (3) Tasks (4) Activities (5) Software work products (project results) (6) Software products Project’s Defined Software Process

  33. Project’s Defined Software Process

  34. The description of PDSP is usually not specific enough to be performed directly Define the generic roles and type of software work products to perform a task, but it does not specify the individual who will assume the roles, the specific software work products that will be created, or the schedule for performing the tasks and the activities. The PSDP, as either a single doc or a collection of plans, provides the bridge between the PDSP (what will be done and how it will be done) and the specifics of how the project will be performed (e.g., which individual will produce which software work products according to what schedule). The combination of PDSP and its PSDP makes it possible to actually perform the process. Relationship Between PDSP and PSDP

  35. The key practices require a number of process-related documents, each one covering specific areas of content. The key practices do not require a one-to-one relationship between the documents named within them and the actual work products of an organization or project.t The key practices require only that the applicable contents of these documents be part of the organization’s or project’s written work products. In terms of document structure, the contents of a document referred to in the key practices could be part of a larger document or separated into several individual documents. Documentation and the CMM

  36. One of the more controversial decision in developing the CMM was defining key process areas to reside at a single maturity level. Key process areas are not processes. A process is dynamic. A process change over time and hopefully matures. A key process area is static. It describes essential attributes (I.e., key practices) of a process when that process is fully realized. It describes a process at a high level of abstraction and does not tell how the process is performed. The Evolution of Processes

  37. Levels/ Process Categories Management Organizational Engineering 5 Optimizing Technology Change Management Process Change Management Defect Prevention 4 Managed Software Quality Management Quantitative Software Management Organization Process Focus Organization Process Definition Training Program 3 Defined Integrated Software Management Intergroup Coordination Software Product Engineering Peer Reviews 2 Repeatable Requirements Management Software Project Planning Software Project Tracking and Oversight Software Subcontract Management Software Quality Assurance Software Configuration Management 1 Initial Ad Hoc Processes

  38. Processes evolve through the maturity levels; KPA reside at a single maturity level. The CMM allows for this evolution by describing processes in general terms, and the practices in a KPA should be appropriately interpreted as a process evolves. Software project management evolves as the organization matures. Process Evolution via KPA Evolution

  39. Professional judgment is necessary for interpreting the key practices and how they contribute to the goal of a KPA. Professional judgment based on an information knowledge of both the CMM and the organization and its projects is helpful CMM implementation. Professional judgment is used to determine whether a specific interpretation or implementation satisfies the goal of a KPA. Applying Professional JudgmentWhy?

  40. A mature software process on the CMM is defined documented trained practiced supported maintained controlled verified validated measured able to improve What are the criteria for a “mature” software process?

  41. Theevolution of software project management Process Change management Optimizing Quantitative process management Managed Integrated Software management Defined Software Project planning Software Project Tracking and oversight Repeatable Initial Software project management done

  42. Key Points • Interpreting the CMM key practices • Describe the CMM key process area’s • template • Interpreting the CMM common features • Define Organizational Structure and • Roles under the CMM • Interpreting the Software Process • Definition

More Related