Summary

The Process Areas for Maturity Level 2: Managed

Requirements Management

The purpose of Requirements Management is to manage the requirements of the project's products and product components , and to identify inconsistencies between those requirements and the project's plans and work products. Specific Goals (SGs) and Specific Practices (SPs) for this PA include:

• SG1: Managed Requirements

  • SP1.1: Obtain an understanding of requirements

  • SP1.2: Obtain commitment to requirements

  • SP1.3: Manage requirements changes

  • SP1.4: Maintain bi-directional traceability of requirements

  • SP1.5: Identify inconsistencies between project work and requirements

Why is Requirements Management at Maturity Level 2? Why is there another PA called Requirements Development at Level 3? What is the difference? Requirements Management for Maturity Level 2 is all about managing already existing requirements; that is, those requirements that have been elicited from the customer are documented and are ready to be worked or are in the process of being worked. This PA refers to capturing and managing the requirements that set the scope of the project. It is at this level because if you do not set the scope, you cannot control how much work will need to be done by the project. So, at this level, requirements already exist, and we are basically just managing the changes to them. Requirements Development at Maturity Level 3 is all about identifying requirements at a high level and decomposing them down to more detailed, testable levels. Because you need to have requirements in existence before you can manage changes to them, why is Requirements Development not at Maturity Level 2? Because eliciting requirements, developing them, and ensuring that they are "good" requirements is a much more difficult and sophisticated a concept. Because Level 2 is the first level in the CMMI with process areas, and Level 2 is about building a foundation for further process improvement, it sort of makes sense that managing requirements resides at this level, and creating requirements is at the next level. Another way of looking at it is to consider that the CMMI is not really a model for improvement (although it does lead to improvement), but is really a model for assessing or evaluating an organization's improvement effort. If you look at the model as an assessment model, then the first level assessed should be easier than the next, and the next, and the next.

The counterpoint is that we really do have an improvement model. The reason Requirements Development is at Maturity Level 3 is that technical organizations first have to do something to define and refine requirements before they can begin to manage them. Sometimes, this same technical organization will then forget that it has to manage the requirements it has defined, in addition to just defining requirements.

Another point to remember is that most organizations develop requirements first; so if it makes sense in your organization to form one team to improve processes for both gathering requirements and managing changes to them, fine do it. Most organizations handle process improvement this way. But assessment teams must remember that they cannot fault an organization during an appraisal for failing to attack requirements' development at Maturity Level 2 when the concept is not concentrated on until Level 3.

Items to note in this process area are that bi-directional traceability is listed as a practice, which means that it is an expected component. In the CMM for Software, requirements traceability was not mentioned until Level 3 in the Software Product Engineering Key Process Area. However, most organizations realized that they could not adequately manage changes to requirements without tracing those requirements in some way. Traceability tools are mentioned as part of the elaboration for GP 2.3: Provide Resources, and are examples of work products reviewed (Requirements Traceability Matrix RTM) for GP 2.9: Objectively Evaluate Adherence. Most organizations had actually constructed RTMs to manage their requirements, but now it is an expected practice in the CMMI. Constructing and using an RTM is not a trivial exercise. So this practice in this process area is an example of considerable growth beyond the CMM for software.

Organizations have asked how far forward and backward must they trace requirements. Our answer is: as far forward and backward as you can. It is not enough to trace one high-level requirement from the Requirements phase straight to the Test phase. Why? Because when problems occur in test (and they will), the fix for the problem may be found back in the Requirements phase, or the Design phase, or the Development phase. That is the purpose of tracing requirements to assist in finding where the problem occurred so it can be fixed more quickly.

This process area does not seem to address corrective actions that may be needed once inconsistencies are found. The model seems to assume that perhaps these problems will be addressed as part of Project Monitoring and Control (a later process area).

Requirements Management includes understanding the requirements for all parts and components of the system (not just software); obtaining customer, management, and developer commitment to the requirements; managing changes to the requirements; maintaining traceability from the requirements forward in the development cycle, as well as backward to discover where changes may have introduced problems; and identifying inconsistencies between the requirements, ensuing work products, and ensuing activities. Requirements Management feeds into Project Planning, Project Monitoring and Control, Technical Solution (Level 3), etc. This Process Area forms the basis of project development, so it touches just about every Process Area in the model. Remember: the scope of the model has greatly expanded; you are devising and managing requirements not only for software, but for all parts of the product.

Project Planning

The purpose of Project Planning is to establish and maintain plans that define project activities. Specific Goals and Practices for this Process Area include:

• SG1: Establish estimates

  • SP1.1: Estimate the scope of the project

  • SP1.2: Establish estimates of work product and task attributes

  • SP1.3: Define project life cycle

  • SP1.4: Determine estimates of effort and cost

• SG2: Develop a project plan

  • SP2.1: Establish the budget and schedule

  • SP2.2: Identify project risks

  • SP2.3: Plan for data management

  • SP2.4: Plan for project resources

  • SP2.5: Plan for needed knowledge and skills

  • SP2.6: Plan stakeholder involvement

  • SP2.7: Establish the project plan

• SG3: Obtain commitment to the plan

  • SP3.1: Review plans that affect the project

  • SP3.2: Reconcile work and resource levels

  • SP3.3: Obtain plan commitment

Although we have used the labels of the practices (the shortened names of the practices), the actual practice itself uses the term "establish and maintain," not just "establish." Let us talk about that phrase "establish and maintain." Sometimes in the CMMI, a word is just a word. Other times, the words have special meanings. That is the case here. "Establish and maintain" does not just mean to create and control; it means that you must define the plans, document the plans, use the plans, monitor what happens when using the plans, and measure the results of the plans. This phrase should be applied to all documentation created for process improvement. We say, "Just because you have crates of documentation, if you don't use it, you ain't got it." So use the plan; do not just stick it up on your shelf and show it to the auditors when they come to town.

SP1.1 discusses Estimating the Scope of the Project, but in actuality is expecting a Work Breakdown Structure (WBS). The CMM for Software did not expect a WBS, although this instance is probably an inclusion of a best practice from other organizations.

A Data Management Plan is now expected (SP2.3). That plan covers how to manage all the data and documentation your project will create, acquire, or require. Listed as work products are privacy and security requirements, security procedures, schedule for collection of project data, format descriptions, and mechanisms for reproduction and distribution. It sounds like a lot of work.

Project Planning includes identifying and documenting the scope of the project in order to define and maintain work boundaries; estimating the size and complexity of work products; estimating tasks , effort, and cost; defining the project life cycle or selecting a preexisting life cycle that matches the project; determining preliminary and follow-on budgets and schedules; identifying and documenting project risks; planning the extent to which stakeholders should become involved to ensure success; planning for managing information, staff, computer resources, and hardware; and planning for the training needs of project team members . The scope of work here has greatly expanded from just planning the software portion of a project to planning the design, development, and delivery of the entire product. This work will include systems engineering.

Project Monitoring and Control

The purpose of Project Monitoring and Control is to provide an understanding of the project's progress so that appropriate corrective actions can be taken when the project's performance deviates significantly from the plan. Specific Goals and Practices for this Process Area include:

• SG1: Monitor project against plan

  • SP1.1: Monitor project planning parameters

  • SP1.2: Monitor commitments

  • SP1.3: Monitor project risks

  • SP1.4: Monitor data management

  • SP1.5: Monitor stakeholder involvement

  • SP1.6: Conduct progress reviews

  • SP1.7: Conduct milestone reviews

• SG2: Manage corrective action to closure

  • SP2.1: Analyze issues

  • SP2.2: Take correction action

  • SP2.3: Manage corrective action

SP1.1 talks about Monitoring Project Planning Parameters. In this case, parameters is just a big word for project planning "stuff," things like cost, size, effort, actuals, estimates. Some of the subpractices for this practice suggest that this monitoring effort may be done simultaneously with Project Planning, not after. For example, most of the subpractices discuss reviewing the project plan (which comes out of the previous Project Planning Process Area). However, subpractices 5 and 6 specifically describe monitoring project personnel skill levels and documenting "significant" deviations in project planning parameters. So perhaps this Process Area has some linkage back to what is occurring in the Planning area.

Reviews are held "regularly," rather than event-driven. While we encourage regular reviews of project activities, we also encourage event-driven reviews. Event-driven reviews may be held when an "event" occurs, which usually means when something bad has happened or might happen like missing a due date, or funding being temporarily suspended . One simple method to determine whether you are holding your meetings regularly enough, is to measure the number of issues or action items coming out of each review meeting. If the number of issues increases , you may need to hold your meetings a bit more regularly that means more meetings. Also make sure that any Steering Committees that exist are actively playing a role, and the role they play is appropriate. While some Steering Committees take too hands-on an approach, most just want to know "How's it going?". And of course, the answer they expect to hear, and want to hear, is "fine." Keep your Steering Committee informed. Also, are your process improvement leaders getting feedback and comments back from the project members? No news is not good news.

How many reviews should be held? Who knows? It depends on your organization, the size of the project, the complexity, the visibility, etc. If your project is a six-month project with only three or four people, you probably hold informal meetings every day. The Project Manager is probably another programmer, and everyone basically knows what everyone else is doing, what is working, and what is not working. You probably share the same cubicle . In larger projects that take up to six years with 600 people, this is not the case. In this case, formal meetings must be coordinated and held on a regular basis, with minutes taken, and issues formally entered into an action item database for tracking. In this case, we would normally expect to see a weekly meeting held within every organizational unit (software, systems engineering, hardware, etc.) between the manager of the unit and his supervisors and workers, and then another meeting held weekly that includes the managers of the units and senior-level management. Meetings held twice a week or once a month with the customer would probably work, unless the project is in the early stages of requirements gathering, in the test phase, or in trouble. In such cases, we would expect meetings to be held either once a week, or even every day.

Reviews should be scheduled in the project plan. If the reviews are documented in the schedule, they will probably occur. Meetings should produce meeting minutes, action items should be tracked, and people who attend should also be monitored . Informal meetings may occur, but do not substitute informal meetings when formal ones are needed.

Project Monitoring and Control includes monitoring the attributes of the project specified in the project plan; monitoring the staff availability and stakeholder involvement; monitoring and revising project risks; monitoring information handling; conducting reviews to ensure progress is being made (usually conducted at least at major milestone completion); bringing to light potential problems and issues, and analyzing those issues; and taking corrective action to ameliorate project issues.

Supplier Agreement Management

The purpose of Supplier Agreement Management is to manage the acquisition of products and services from suppliers for which there exists a formal agreement. Specific Goals and Practices for this Process Area are:

• SG1: Establish supplier agreements

  • SP1.1: Determine acquisition type

  • SP1.2: Select suppliers

  • SP1.3: Establish supplier agreements

• SG2: Satisfy supplier agreements

  • P2.1: Review COTS products

  • SP2.2: Execute the supplier agreement

  • SP2.3: Accept the acquired product

  • SP2.4: Transition products

As discussed previously, this book uses the practice labels, and not the entire practice. However, please review SP1.2: select suppliers. The entire practice is much different from the label. The entire practice reads: "Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria." SP1.3: Establish Supplier Agreements is really about that phrase "establish and maintain" formal agreements with the supplier. Commercial-off-the-shelf (COTS) products are specifically covered in SP2.1, not just buried as an example, as in the CMM for Software.

If your organization does not have external suppliers (including contractors providing services), this Process Area may be "Not Applicable" (N/A) for your organization. However, considering the expanded nature of the model, this N/A seems less and less likely. Your organization probably will have formal agreements for delivery or development or installation of hardware, tools, COTS products, simulators, etc. This area is not just about subcontracting , as in the CMM for Software.

While Release Management is not covered extensively in the CMMI, some guidance for releasing the product built by suppliers is described here. Evaluating project risks that might occur, and Acceptance Testing, are also discussed in this process area.

Supplier Agreement Management includes determining the type of acquisition the project requires; determining the type of products or product components to be acquired; selecting appropriate suppliers; deciding to purchase COTS products when appropriate; defining and executing agreements with the chosen suppliers; and accepting and deploying products developed by suppliers into the project.

Measurement and Analysis

The purpose of Measurement and Analysis is to develop and sustain a measurement capability that is used to support management information needs. Specific Goals and Practices for this Process Area include:

• SG1: Align measurement and analysis activities

  • SP1.1: Establish measurement objectives

  • SP1.2: Specify measures

  • SP1.3: Specify data collection and storage procedures

  • SP1.4: Specify analysis procedures

• SG2: Provide measurement results

  • SP2.1: Collect measurement data

  • SP2.2: Analyze measurement data

  • SP2.3: Store data and results

  • SP2.4: Communicate results

This Process Area describes what to do when instituting a measurement process in your organization, not just which measurements to collect. This Process Area should be considered global because all processes should be measured, and most work products also produce meaningful metrics.

Measurement and Analysis (M&A) appeared throughout the CMM for Software as a Common Feature. M&A is now its own Process Area at Maturity Level 2. Why? Because high-maturity organizations have stated quite clearly that the key to success in process improvement is measurement and actually using those measurements to make decisions and monitor the process improvement effort. The authors of this book agree that measurement is key, but also feel that this one process area, while well-written and certainly necessary, is too sophisticated to reside at Maturity Level 2. We feel that most organizations will find this area very difficult to implement when operating at the degree of sophistication required for a Maturity Level 2 organization; that is, Level 2 is usually referred to as "the baby steps" of process improvement. That is not to say that it is easy to get to Level 2 (watch any toddler learning to walk and watch how they learn to stop). The M&A Process Area expects that measurements are aligned with business goals. This expectation may be too much for low-maturity organizations. With little or no experience in measurement, it is easy for organizations to go either too far and measure everything, or not far enough and only measure things that they "already know" are important.

The Common Feature Directing Implementation has replaced the previous Measurement and Analysis Common Feature. Directing Implementation seems quite weak, with few meaningful examples. The Directing Implementation Common Feature does not actually state that measures are taken and used. Measures are the only examples given in the common feature, but a dysfunctional organization or a dysfunctional appraisal team might not use the "informative" examples correctly.

The other reason for breaking out measurement into its own process area was that organizations were good at collecting measurements, but not in actually using the measurements. It seems that just creating a process area will not handle that problem. Anyone can make a case for ignoring something, or just paying superficial compliance to the process area and its practices.

Measurement and Analysis includes defining measurement objectives; defining measures and procedures for collecting, storing, and analyzing metrics; executing the procedures to collect and analyze measurement data; storing the data and results in a manner fostering their usage by appropriate parties; and reporting measurement information to individuals and groups requiring the information.

A basic step-by-step approach to measurement is:

1. Select the process to measure.

2. Select the measures.

3. Determine when to collect data.

4. Determine how to collect data.

5. Record and store the information.

6. Analyze data for consistency and accuracy.

7. Chart the results.

8. Review the chart.

9. Do something (corrective actions).

Process and Product Quality Assurance

The purpose of the Process and Product Quality Assurance Process Area is to provide staff and management with objective insight into processes and associated work products. Specific Goals and Practices for this process area include:

• SG1: Objectively evaluate processes and work products

  • SP1.1: Objectively evaluate processes

  • SP1.2: Objectively evaluate work products and services

• SG2: Provide objective insight

  • SP2.1: Communicate and ensure resolution of noncompliance issues

  • SP2.2: Establish records

The term used is to "objectively evaluate adherence." This term is defined in the Glossary as reviewing activities and work products against criteria that minimize subjectivity and bias by the reviewer. The reference to the term "audit" is further defined in the Glossary as "an independent examination of a work product or set of work products to determine whether requirements are being met." The concept of independence is addressed by the Generic Practice 2.4: Assign responsibility, and states that those people assigned to perform this role should have "sufficient" independence and objectivity. In the verbiage following the purpose statement (Introductory Notes) at the beginning of the process area itself, some discussion of objectivity and independence may be found. These paragraphs discuss embedded quality assurance and independent QA groups. It is stated that "Those performing quality assurance activities for a work product should be separated from those directly involved in developing or maintaining the work product. An independent reporting channel to the appropriate level of organizational management must be available so that noncompliance issues may be escalated as necessary." We remind the authors of the CMMI that processes are not products ; and that Notes are simply informative and not normative that is, these dicta may prove useful for understanding the intent of the area but are not mandatory for process improvement implementation or assessment. We also find that by burying the definition of objectivity and independence in these paragraphs, a less-than - stellar implementation of this process area will be promoted.

Notice that the CMMI specifically calls out quality assurance reviews and activities for both product and process. Under the CMM for Software, Verifying Implementation 3 involved Software Quality Assurance (SQA). SQA groups were directed to review both products and processes. However, organizations tended to either focus on SQA reviews for products (reviewing documentation against formatting standards) or on reviewing process adherence (whether SQA reviews were held as documented in the process descriptions and the procedures). Few organizations realized that both types of reviews were necessary. So now the CMMI emphasizes that both must occur by including both in the name of the process area and in the specific practices.

To audit processes, simply review whether they were followed as documented, why or why not, where the problems are, and where improvements are needed. To audit products, use product standards and checklists to ensure compliance. Reviewing for content (as opposed to form or image) may best be left to the Peer Review process and the Technical Review process. It is often simply too difficult to get Quality Assurance personnel to review for "good" content, as this requires vast technical knowledge. Most techies prefer to stay techies, and getting superior technical experts into a QA role is difficult not impossible , just difficult. If your organization would like to attempt this feat, we suggest rotating developers into QA, and QA personnel into the development arena. In some organizations, before someone can become a project manager, he or she must have served duty in both QA and technical development areas. Another way of trying to incorporate technical expertise into QA reviews is to perform audits with both technicians and QA individuals participating side-by-side.

SP2.1: Communicate and ensure resolution of noncompliance issues at first seems to indicate that all the QA people must do is report the problem and move on. But the full practice reads: "Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers," with Subpractice 7 describing tracking issues to resolution.

Process and Product Quality Assurance includes providing a strategy and procedures for objectively evaluating processes and products; identifying personnel to fulfill this role objectively; reporting quality issues and noncompliance; and producing reports that provide verification that quality reviews were conducted and their results.

Configuration Management

The purpose of the Configuration Management process area is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. Specific Goals and Practices for this process area include:

• SG1: Establish baselines

  • SP1.1: Identify configuration items

  • SP1.2: Establish a configuration management system

  • SP1.3: Create or release baselines

• SG2: Track and control changes

  • SP2.1: Track change requests

  • SP2.2: Control configuration items

• SG3: Establish integrity

  • SP3.1: Establish configuration management records

  • SP3.2: Perform configuration audits

Configuration Management is not just setting up libraries for files and then migrating files back and forth. It is also not about buying tools that will migrate files and tell you when they were moved, or that a change has been made. Configuration Management is about defining configuration items. "Configuration items" is a well-known term for DoD clients , but is not so well known outside that arena. We use the following example. When a software system is being designed, it can be broken up into several pieces. Those pieces can be the files, the data elements within those files, programs, reports, and integrated or called modules. Those pieces can be termed "configuration items." An organization can have both high-level configuration items and then lower-level configuration items that result from decomposing the high-level items into lower-level, more detailed, smaller pieces. Each piece (or configuration item) is assigned a label and a number to aid in tracking that all pieces of the desired system are included as part of the delivered product. It also helps in tracking changes, planning the effort, and auditing functionality satisfied.

Configuration Management is also about establishing baselines. Baselines are basically where you draw a line in the sand and say, "OK. Anything developed past this point, or any changes made past this point, must go through some sort of official review before being incorporated into the rest of the system." Factors such as impacts to already existing modules, costs, skillsets required, schedules and due dates, and technical feasibility are all analyzed before the modification or addition is made. The CMMI does not tell you when to establish a baseline; it just encourages you to do so. So when should baselines be established? Well, once again, we do not know your particular organization, but usually baselines are set after requirements have been approved and signed off, the design has been signed off, testing has finished, and the product has been delivered and is ready to enter the maintenance phase.

Configuration Management duties include verifying the contents of libraries and files. A tool may be used to track that changes were made, but a tool is usually not sophisticated enough to tell you what the change was, and how this change affects the rest of the system. So, a human being must be involved in reviewing and analyzing the effects of any changes. This type of review is called a configuration audit. Although both the CMMI and the CMM for Software discuss ensuring the "completeness and correctness" of the material in the libraries, the CMM for Software does not define what "completeness and correctness" means. Because of that, some organizations included physical configuration audits (where the physical structure of the system is reviewed against changes) and not functional configuration audits (where requirements are traced to confirm that they have been satisfied within elements of the system). Subpractice 4 of SP3.2: Perform configuration audits seems to imply that to ensure "completeness and correctness," both must occur.

Although throughout the CMMI, specific groups are generally not mentioned, in Configuration Management, subpractice 1 of SP1.3: Create or release baselines does specifically mention the Configuration Control Board (CCB). A "release" is the product that is released to the customer for use. A "build" is the work product that is passed onto other internal departments for further usage or work. Formal procedures for Release Management are not covered. This area also focuses on having a formal change request process in place.

Configuration Management includes defining configuration items; developing or implementing support tools, techniques, procedures, and storage media; generating and maintaining baselines; tracking change requests and controlling changes; documenting the results of the configuration management effort; and performing configuration audits.