1. Chapter 4 Interpreting the CMM

2. Group (3) Fahmi Alkhalifi Pam Page Pardha Mugunda

3. CMM Commonsense application of process management and quality improvement concepts to software development and maintenance. Written to address the process of large, complex software efforts. Broad-based agreement by software community of good engineering and management practices.

4. Interpreting Key Practices Provide a description of essential elements of an effective software process. Set principles that apply to variety of projects and organizations and a range of typical software applications. Although it’s meant to be independent, organizations should map these conventions appropriately to their own projects and business environments.

5. Terminologies Activity: Any step taken or function performed, both mental or physical, toward achieving some objectives. Activities include all the work the managers and technical staff do to perform the tasks of the project and organization. Audit: An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. Commitment: A pact (agreement) that is freely assumed, visible, and expected to be kept by all parties.

6. Terminologies – Cont. Configuration management: A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. Goals: A summary of the key practices of a key process area that can be used to determine whether an organization or project has effectively implemented the key process area. The goals signify the scope, boundaries, and intent of each key process area.

7. Terminologies – Cont. Key practices: The infrastructure and activities that contribute most of the effective implementation and institutionalization of a key process area. Key process area: A cluster of related activities that, when performed collectively, achieve a set of goals considered to be important for establishing process capability. Managed and controlled: The process of identifying and defining software work products that are not part of a baseline and therefore are not placed under configuration management, but that must be controlled for the project to proceed in a disciplined manner.

8. Terminologies – Cont. Orientation: An overview or introduction to a topic for those overseeing or interfacing with the individuals responsible for performing in the topic area. Periodic review: A review that occurs at specified, regular time interval. Procedure: A written description of a course of action to be taken to perform a given task. Process: A sequence of steps performed for a given purpose, e.g. software development process

9. Terminologies – Cont. Role: A unit of defined responsibilities that may be assumed by one or more individuals. Software work product: Any artifact created as part of defining, maintaining, or using a software process. They can include process descriptions, plans, procedures, computer programs, and associated documentation, which may or may not be intended for delivery to a customer or end user.

10. Key Process Area Template Notes:  Goals and common features are delimited by headers. e.g. Goals, Commitments to Perform  Key practices labeled with noun (common feature) and a number. e.g. Commitment 1, Ability 2  Key practices are in Bold type. e.g. A group that is responsible for exists.  Sub-practices preceded by preamble. e.g. key practices that include “according to a documented procedure” are preceded by “This procedure typically specifies that:”  Practices may be followed by boxed text. e.g. elaboration or cross-reference

11. a key area for Level n: The purpose of is. involves. Goals Goal 1 Goal 2 Commitment to Perform Commitment 1The project follows written organizational policy for. or The organization follows a written policy for. This policy typically specifies that: 1.

12. Ability to Perform Ability 1A group that is responsible for exists. 1. Ability 2Adequate resources and funding are provided for. 1. Tools to support activities for are made available. Ability 3 are trained. or receive required training. Ability 4 receive orientation in. Examples of tools include: Examples of training include: Examples of orientation include:

13. Activities Performed Activity 1 1. 2. 3. are placed under configuration management. Activity 2 according to documented procedure. This procedure typically specifies that: Examples of affected groups include: Refer to the Software Configuration Management key process area. Chapter (7).

14. 1. 2. 3. undergo peer review. 4. are managed and controlled. Refer to Activity N of the key process area for practices. Refer to the Peer Reviews key process area. Chapter 8 “Managed and controlled” implies that the version of the work product in use at a given time (past or present) is known (i.e. version control), and changes are incorporated in a controlled manner (i.e., change control). If a greater degree of formality than is implied by “managed and controlled” is desired, the work product can be placed under the full discipline of configuration management, as is described in the Software Configuration Management key process area.

15. Measurement and Analysis Measurement 1Measurements are made and used to determine status of the activities for. Verifying Implementation Verification 1Activities for are reviewed with senior management on a periodic basis. 1. Verification 2Activities for are reviewed with the project manager on both a periodic and event-driven basis. 1. Verification 3Software quality assurance group reviews and/or audits the activities and work products for and reports the results. At a minimum, these reviews and/or audits verify that: 1. Examples of measurements include: Refer to Software Quality Assurance key process area. Chapter 7

16. Interpreting the Common Features Commitment to Perform Ability to Perform Activities Performed Measurement and Analysis Verifying Implementation

17. Interpreting the Common Features Commitment to Perform Policy Statements  Written, organizational policy for practices of the key process areas

18. Interpreting the Common Features Leadership  Assigns leadership roles to key process areas or describes sponsorship activities that are required for the key process area to be successfully institutionalized

19. Interpreting the Common Features Ability to Perform - the preconditions in the project or organization necessary to implement the software process competently Organizational Structures Resources and Funding Training  Orientation  Prerequisites

20. Interpreting the Common Features Organizational Structures May need to develop independence or objectivity that may require developing into a special group

21. Interpreting the Common Features Resources and Funding Access to special skills Adequate funding Access to tools

22. Interpreting the Common Features Training Informal or formal  Classroom, videos, computer-aided or a formal mentor and apprenticeship programs  Different organizational situations will drive the training needs

23. Interpreting the Common Features Orientation Overview Prerequisites Items expected to be obtained from outside the realm of the software project

24. Interpreting the Common Features Activities Performed: Types of Plans  Informal Plans  Formal Plans Documented Procedures System requirements Customer-supplier relationship  Internal  External

25. Interpreting the Common Features Tracking and taking corrective action vs. managing Reviewed vs. undergoes peer reviews Placed under configuration management vs. managed and controlled

26. Interpreting the Common Features Measurement and Analysis Quality of the training program Effectiveness of management Functionality and quality of software products

27. Interpreting the Common Features Verifying Implementation Senior management oversight on a periodic basis Project management oversight  Periodic basis  Event-driven basis Software quality assurance activities

28. Organizational Structure and Roles Organizational Roles Manager Senior manager Project manager Project software manager First-line software manager Software task leader Staff, software engineering staff, individuals

29. Organizational Structure and Roles Organizational Structure Organization Project Group

30. Organizational Structure and Roles CMM referred groups:  Software engineering group  Software related groups  Software engineering process group  System engineering group  System test group  Software quality assurance group  Software configuration management group  Training group

31. Independence and Organizational Structure Independence should provide: Those individuals should be the “eyes and ears” of senior management Protect the individuals from adverse personnel actions Provide senior management with confidence on results of the project

32. Understanding Software Process Definition

33. Process Definition Concepts 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 wide spread operation within the organizational or project for which the process is intended

34. Concepts Related to the Organization’s Software Process Assets Software process assets are a collection of entities maintained by an organization, for use by projects in developing, tailoring, maintaining, and implementing their software process. Any entity that the organization considers useful in performing the activities of process definition and maintenance could be included as a process asset.

35. Organization’s Software Process Assets The organization establishes and maintains a set of software process assets. The organizations standard software process, The description of software life cycles approve for use, The guidelines and criteria for tailoring the organization’s standard software process.

36. Organizations Standard Software Process An organizations standard software process is the operational definition of the basic process that guide the establishment of a common software process across the software projects in the organization.

37. Software Process Architecture The software process architecture is a high level description of the organization’s standard.

38. Software Process Element A software process element is a constituent of a software process description.

39. Description of Software Life Cycles Approved for Use A software life cycle is the period of time that begins when a software product is conceived and ends when the software is no longer available for use.

40. Concepts Related to the Project’s Defined Software Process Description of projects defined software process Stages Tasks Activities Software work products Software products

41. The Evolution of Processes The management process category contains the project management activities The organizational process category contains the cross process responsibilities. The engineering process category contains the technical activities such as requirement analysis, design, code, and test.

42. Applying Professional Judgment Professional judgment is necessary for interpreting the key practices and how they contribute to the goals of a key area. To provide complete set of valid principles that apply to a wide range of situations, the key practices are intentionally stated to allow for flexibility.

43. Applying Professional Judgment The goals of the key process areas provide a structure for making the interpretation. Professional judgment is used to determine whether a specific interpretation or implementation satisfies the goals of key area.

44. Applying Professional Judgment What are the criteria for a mature software process? It is Defined Documented Trained Practiced Supported

45. Applying Professional Judgment Both maturity and effectiveness should be interpreted in the context of the business environment and the specific circumstances of the project and the organization.