Yes. CMMI models permit the flexible application of Engineering practices (i.e., those contained in the Requirements Management, Requirements Development, Technical Solution, Product Integration, Verification, and Validation process areas) to software engineering, systems engineering, or other product engineering functions. Each organization selects a CMMI model and the parts of the organization to participate in the process improvement program (i.e., the scope).

The SCAMPI appraisal method can be used to perform discipline-specific appraisals by simply selecting the scope of the appraisal using the "organizational unit" concept and using the appropriate CMMI model. An organizational unit typically has an identifiable senior manager, deploys one or more processes that have a coherent process context, and operates within a coherent set of business objectives. An organizational unit is typically part of a larger organization, although in a small organization, the organizational unit may be the whole organization. Such an appraisal is not termed "CMMI-SE" or "CMMI-SW" as in the past, nor can "SE" or "SW" be appended to the new formal model definition (i.e., CMMI-DEV/SE is not allowed).

As part of every appraisal, an Appraisal Disclosure Statement (ADS) must be completed. This statement must indicate not only the CMMI model used for the appraisal, but also the organizational unit(s) included in the appraisal. This statement clearly communicates the nature of the appraisal, including whether software engineering or systems engineering processes of the organization were appraised.

CMMI for Development covers the acquisition discipline as it relates to product development and maintenance, which includes the use of commercial off-the-shelf (COTS) products and outsourcing.

The CMMI Acquisition Module (CMMI-AM) builds on relevant best practices extracted from the CMMI Framework to define effective and efficient practices for government acquisition organizations. This is a non-appraisable element of the CMMI Product Suite.

CMMI for Acquisition (CMMI-ACQ), a CMMI model designed for acquisition organizations, is planned for release in 2007. An initial draft of the model is now available.

The Software Acquisition Capability Maturity Model (SA-CMM) is a capability maturity model for organizations that acquire solutions such as hardware, software, services, and systems. It is used to appraise an organization's process maturity and help improve its acquisition processes.

Yes. CMMI for Development meets the broader needs of product development by guiding the engineering development of products. These products can be electrical or mechanical. Examples and typical work products often apply to software, hardware, and firmware products.

Organizations applying discipline areas such as electrical and mechanical engineering may wish to supplement CMMI model elements with information that has not been covered but would be helpful in applying the best practices to the organization's environment. For that and similar reasons, CMMI models are available in Microsoft Word format that easily can be tailored.

Yes. CMMI for Development is designed to include hardware engineering as part of product development and maintenance. There are amplifications that specifically address hardware engineering practices. (Look for the words "For Hardware Engineering.") Further, many examples demonstrate that CMMI practices are designed for hardware as well as software and systems engineering.

Yes, if when improving its organization's processes, a manufacturing organization includes manufacturing functions as part of its process improvement program.

When planning an appraisal of a manufacturing organization, the role of the manufacturing function in the organization determines if that function should be within the scope of a SCAMPI appraisal. The SCAMPI appraisal method permits a wide range of tailoring options, including the organizational scope and model scope of the appraisal. In general, the portions of the organization involved in performing the practices in the model scope must be included.

For example, if the Technical Solution process area is included in the model scope and some of the specific practices within the process area are performed by practitioners that are part of the manufacturing function, then manufacturing should be included in the appraisal.

Yes. Generic practice 3.2, "Collect work products, measures, measurement results, and improvement information derived from planning and performing the process to support the future use and improvement of the organization's processes and process assets." can be performed using a single process that collects artifacts and information from multiple process areas. A separate collection process for each process area is not required. A "cross-PA" approach is consistent with the intent of generic practice 3.2 and is a good example of an effective and efficient approach to its implementation.

 The answer depends on your business and your organization's business objectives. Consider which improvements to both operations and maintenance activities will bring the greatest benefit to the organization. How important is it to the success of the business that

• "small maintenance deliveries" are performed correctly and efficiently?
• operations are performed correctly and efficiently?

If maintenance activities matter significantly more to the business than operations, then improvement efforts might focus on maintenance. There is often a service-level agreement defining what level of service must be sustained. (This may mean that you want to treat the maintenance activity as a service and use [or in addition, use] the new CMMI for Services model when it becomes available.)

If you use the CMMI for Development model, the maintenance activities could be collectively treated as a single overarching project. Individual maintenance deliveries above a certain size or criticality could be treated as subprojects. There could be one lifecycle for the overarching project identifying when major reviews of the level of service delivered would take place; and another lifecycle model identifying the phases of an individual critical maintenance delivery.

If operations matter significantly more to the business than maintenance, then improvement efforts might focus on operations. Likewise, the overall set of activities in the operation could be treated as a single overarching project. Individual transactions or components of the operation above a certain criticality may benefit from individual planning and monitoring as subprojects. There would again be one lifecycle model for this overarching project identifying major milestones and when major interactions or reviews with the customer might take place. There is often a natural sequence to some of the activities in an operation (e.g., the handling of customer order forms, product installations, end-user questions, and change requests). Additional lifecycle models based on these natural sequences might facilitate planning, monitoring, and controlling transactions or components of the operation above a certain criticality.

Most likely, both operations and maintenance will be critical to the business. The improvement opportunity that results is a combination of the two special cases considered above. The organization's set of standard processes would cover maintenance as well as operations. Either separate lifecycle models or a single merged lifecycle model would be used, depending on whether the operations and maintenance activities are focused on the same product and on how they depend on each other. Conversely, if there are no significant dependencies between operations and maintenance, then there might be some benefit to treating these as separate organizational units.

In summary, whether "small maintenance deliveries" satisfies the intent of a full product lifecycle depends on an analysis of what is critical to the organization and where the greatest opportunity lies for process improvement.

Yes. Systems engineering practices are best identified by looking first at the definition of systems engineering in the CMMI model glossary:

The interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a product solution and support that solution throughout the product's life.

This includes the definition of technical performance measures, the integration of engineering specialties toward the establishment of a product architecture, and the definition of supporting product lifecycle processes that balance cost performance and schedule objectives.

From this definition, you can see that hardware and software design are covered by systems engineering. The systems engineering and software engineering practices in CMMI models significantly overlap. In fact, the model amplifications, which are informative clarifications of practices, are the only differences between how these practices are applied.

With the release of version 1.2, the names of CMMI models have changed from listing the legacy constituent disciplines addressed in a model toward a more comprehensive and integrated approach. Therefore, CMMI-SE/SW/IPPD/SS has become CMMI for Development (CMMI-DEV).

 No, not specifically, but yes by implication. The model's emphasis on relevant stakeholders and on validating [customer] requirements can be seen as confirming the importance of this area as customers are most assuredly relevant stakeholders.

If you think that customer management should be emphasized more in CMMI, submit a change request using the CMMI User Feedback Process described on the SEI Web site at http://www.sei.cmu.edu/cmmi/tools/cr/index.cfm.

The Validation process area applies to both the finished product and intermediate work products.

The focus of validation is whether the product or product component, as provided (or as it will be provided), will fulfill its intended use in its operational environment. In many cases, validation of product components will occur on intermediate work products early in the lifecycle to ensure that the product meets its intended use. In rare cases acceptance testing may be an adequate implementation of this process. Also seeWhen does Validation (VAL) occur in the product development lifecycle? below for more information.

 Each CMMI constellation is given a name by the CMMI Product Team, which is then approved by the CMMI Steering Group.

The name of each model produced by a constellation consists of "CMMI" and the constellation name, followed by the names of the group of additions included. For example, a model in the Development constellation that does not have a group of additions is named CMMI for Development or CMMI-DEV. If the model has the IPPD group of additions, its name will be CMMI for Development +IPPD or CMMI-DEV +IPPD.

CMMI users drive all requirements by submitting change requests. However, full implementation and expansion decisions derived from these requirements are made by the CMMI Steering Group.

There are two primary venues in which you can meet and communicate with other CMMI users: conferences and the Web.

CMMI issues have been a focus at events such as

• Software Engineering Process Group (SEPG) conferences in locations including
• • United States
  • Europe
  • Australia
  • Latin America
• the Systems and Software Technology Conference (SSTC)
• the CMMI Technology Conference and User Group

See our upcoming events.

Discussion of CMMI issues on the Web include the following:

• The SEI's Software Engineering Information Repository (SEIR) has over 25,000 registered users and provides a forum for the discussion of software engineering improvement activities, including CMMI.
• The BSCW Shared Workspace is another forum used to contribute and exchange CMMI-related work products and tools.
• The CMMI discussion group on Yahoo! is used to exchange ideas about CMMI-based process improvement.
• CMMI en Francais is a Yahoo! discussion group available to French speaking users.
• CMMI-Turkiye is a Yahoo! discussion group for the Turkish-speaking CMMI community.
• You can also contact individual CMMI experts by finding their contact information at the SEI Directory of Partner Organizations.

Finally, you can ask the SEI questions about CMMI by sending email to cmmi-comments@sei.cmu.edu. Your question will be answered within a few days unless further research is required.

Visit the SEI Partner Network Directory at http:/www.sei.cmu.edu/partners/directory to search for SEI Partner organizations. You can search for Partners by name, services provided, or by location. Many Partners provide CMMI training service, SCAMPI Lead Appraiser services, and additional process improvement assistance.

The SEI does not recommend a particular SEI Partner organization or their employees. Your decision should be based on discussions with the partners that you contact. If you have a question about whether an organization you are working with is an authorized member of the SEI Partner Network, check the directory. If they do not appear, contact SEI Customer Relations at customer-relations@sei.cmu.edu for more information.

 You can submit change requests and comments about CMMI using the CMMI User Feedback Process. Use the change request forms or the comment form. See the instructions at http://www.sei.cmu.edu/cmmi/tools/cr/.

The best time to get help in tailoring a CMMI model correctly is in the early stages of CMMI adoption. A process improvement consultant can help you.

To interpret CMMI practices, consider the overall context in which these practices are used and determine how well these practices satisfy the goals of a process area within that context. CMMI models do not imply which processes are right for the organization or project. Instead, CMMI models establish minimal criteria to meet in planning and implementing processes selected by the organization for improvement based on business objectives.

Organizations adopting CMMI must use professional judgment to interpret CMMI practices. Although process areas describe behavior that may be exhibited in any organization, practices must be interpreted using an in-depth knowledge of the CMMI model being used, the organization, the business environment, and the specific circumstances involved.

CMMI practices purposely use nonspecific phrases such as "relevant stakeholders," "as appropriate," and "as necessary" to accommodate the needs of different organizations or projects. Specific needs may also differ at various points during a project's life.

Organizations map their processes to CMMI process areas and use this mapping to track their level of conformance to the CMMI model they are using. Typically, there is not a one-to-one correspondence between the CMMI process areas and an organization's processes.

In 1990, Congress passed the Defense Acquisition Work Force Improvement Act (DAWIA), which provided structure to the acquisition workforce by creating the concept of the acquisition corps. DAWIA sets forth training and education requirements for civilian positions and military billets that are in the acquisition work force. Many of the technical courses taught to the acquisition work force contain information on CMMs in general. CMMI now provides an additional source of training material for future DAWIA course updates and offerings.

EIA 731, the Systems Engineering Capability Model, is a source document for CMMI. A mapping that compares EIA 731 and CMMI v1.1 is available on the SEI Web site, including a mapping from CMMI v1.1 to EIA 731 at http://www.sei.cmu.edu/cmmi/casestudies/mappings/cmmimappings.cfm, from EIA 731 to CMMI v1.1 available at http://www.sei.cmu.edu/cmmi/casestudies/mappings/cmmimappings.cfm, and a document to help you interpret these mappings at http://www.sei.cmu.edu/cmmi/casestudies/mappings/cmmimappings.cfm. An article that discusses Transitioning from EIA/IS 731 to CMMI is also available at http://www.stsc.hill.af.mil/crosstalk/2000/07/clouse.html. (Even though these mappings, interpretation document, and article discuss CMMI v1.1, which is no longer the current version, this material should still prove useful to organizations seeking to transition from EIA/IS 731 to CMMI. At some future date, if there is sufficient demand, the SEI will update this material.)

The CMMI A-Specification Version 1.6 includes a requirement that the CMMI Product Suite be consistent and compatible with ISO/IEC 15504. Some of those involved in the CMMI effort are also involved in related ISO/IEC efforts as members of the JTC1/SC7 US Technical Advisory Group. This involvement assures that future compatibility can be continually improved.

A mapping that compares ISO 9001:2000 with CMMI v1.1 is available on the Web at http://www.sei.cmu.edu/cmmi/casestudies/mappings/cmmimappings.cfm. A presentation is also available at http://www.sei.cmu.edu//library/assets/cmmi-iso.pdf that discusses Exploring CMMI-ISO 9001:2000 Synergy When Developing a Process Improvement Strategy. (Even though the mapping and presentation discuss CMMI v1.1, which is no longer the current version, this material should still be useful to organizations transitioning from SW-CMM to CMMI. At some future date, if there is sufficient demand, the SEI will update this material.)

In general, national standards address development disciplines such as software engineering, systems engineering, configuration management, data management, and quality assurance. National standards strive to define top-level process requirements inherent in these disciplines.

CMMI supports product and process improvement, reduces redundancy, and eliminates inconsistency when using separate stand-alone models. As such, the CMMI Product Suite is consistent with the general guidelines set forth in current national standards.

CMMI is an upgrade to the SW-CMM. These two models have a lot in common. SW-CMM, Version 2.0, Draft C is a source document for CMMI. A detailed mapping of SW-CMM v1.1 and CMMI v1.1 is available on the SEI Web site at http://www.sei.cmu.edu/cmmi/casestudies/mappings/cmmimappings.cfm. There is also a whitepaper available that discusses upgrading from SW-CMM to CMMI available at http://www.sei.cmu.edu/library/abstracts/whitepapers/upgrading.cfm. (Even though the mapping and whitepaper discuss CMMI v1.1, which is no longer the current version, this material should still be useful to organizations transitioning from SW-CMM to CMMI. At some future date, if there is sufficient demand, the SEI will update this material.)

CMMI Product Suite objectives are consistent with the tenets of acquisition reform. CMMI emphasizes an integrated "systems" view, which is also emphasized in various acquisition reform initiatives. The concept of performance-based acquisition is also reflected in the CMMI concept. CMMI will enhance an organization's ability to manage risk and improve internal processes, both of which are integral to acquisition reform.

CMMI for Acquisition is currently being developed and will be released in 2007. This CMMI constellation directly addresses the objectives of acquisition reform.

There is no simple answer to this question because organizations change as their marketplace changes to remain competitive and different markets change at different rates, but for example, six months is typically insufficient to firmly establish new processes that can be comprehensively appraised.

From the perspective of a SCAMPI appraisal team, the more relevant issue is not how long, but to what extent the processes and procedures have been implemented and how confident the appraisal team is that these processes and procedures will persist.

Organizations with institutionalized processes have the infrastructure and feedback mechanisms needed to support both the persistence and consistency of processes and procedures, and to easily improve these processes and procedures when appropriate. However, to help ensure that process maturity and capability does not erode over time, organizations are encouraged to carefully monitor process compliance and the deployment of the set of standard processes across the organization.

Process performance baselines and models (OPP specific practice1.4, "Establish and maintain the organization's process-performance baselines." and specific practice 1.5, "Establish and maintain the process-performance models for the organization's set of standard processes.") summarize the historical performance of selected processes (or subprocesses). Process performance baselines are often represented as statistical summaries (e.g., mean and variation) of how a process or subprocess has performed across the organization (appropriately normalized, e.g., for work product or task size). Process performance models are often represented as predictive models (e.g. Regression, Correlation, Analysis of Variance, Chi-Square Analysis, Logistic Regression, Discrete Event, and Monte Carlo simulation modeling) that indicate the statistical relationship among measures of selected process or work product attributes from different lifecycle phases.

Both process performance models and baselines are used in project planning to assess the impact of including certain processes and subprocesses in the project's defined process (QPM specific practice 1.2, "Select the subprocesses that compose the project's defined process based on historical stability and capability data." and specific practice 1.3, "Select the subprocesses of the project's defined process that will be statistically managed.") on the achievement of the project's quality and process performance objectives.

Process performance models are used during project execution to estimate and predict the value of process performance measures in later lifecycle phases of the project from other measures now available. They are used both at the beginning of the project and regularly thereafter to determine whether the project is on track (QPM specific practice 1.4, "Monitor the project to determine whether the project's objectives for quality and process performance will be satisfied, and identify corrective action as appropriate.") to achieve its quality and process performance objectives (QPM specific practice 1.1, "Establish and maintain the project's quality and process-performance objectives.").

Process performance baselines and models are important to achieving CL and ML 4 because they, together with quantitative objectives for quality and process performance and statistical management of selected subprocesses, are important to quantitatively managing project performance.

Process performance baselines and models support the OID process area in terms of identifying and understanding innovative approaches and the relationship to the current organizational performance.

 Independence is not required; however, objectivity is required. For a more detailed explanation, see the Introductory Notes of the Process and Product Quality Assurance process area.

Yes. The architecture of the CMMI Framework is designed to allow the future addition of other disciplines and the coverage of other areas of interest within CMMI. To apply to multiple areas of interest, the framework groups best practices into what are called "constellations." A constellation is a collection of CMMI components that are used to build models, training materials, and appraisal documents.

Recently, the CMMI model architecture was improved to support multiple constellations and the sharing of best practices among constellations and their member models. Work has begun on two new constellations: one for acquisition (CMMI for Acquisition) and the other for services (CMMI for Services). Although CMMI for Development incorporates the development of services, including the combination of components, consumables, and people intended to meet service requirements, it differs from the planned CMMI for Services (CMMI-SVC) constellation, which largely focuses on the delivery of services. The CMMI models that have been available in the community prior to 2006 are now considered part of the CMMI for Development constellation.

Every process area has a generic practice (GP 2.2) that addresses planning. Generic practice 2.2, "Establish and maintain the plan for performing the process," addresses the planning of the overall process for a particular process area. The purpose of this generic practice is to determine what is needed to perform the process and achieve the established objectives, prepare a plan for performing the process, prepare a process description, and get agreement on the plan from relevant stakeholders.

In some process areas (Causal Analysis and Resolution, Integrated Project Management, Organizational Innovation and Deployment, Organizational Process Focus, Organizational Training, and Risk Management), there are specific practices that cover plan or strategy development. Where there are such specific practices, GP 2.2 addresses overall planning for the entire process area, whereas the specific practices address more detailed and focused planning. In these same process areas, the elaboration that accompanies GP 2.2 explains the differences between the generic practice and the specific practice.

 Articles, papers, presentations, and FAQs about various aspects of CMMI are available on the CMMI Web site at http://cmsauth.sei.cmu.edu/cmmi/start/index.cfm.

In the Requirements Management (REQM) process area, specific practice 1.4 states, "Maintain bidirectional traceability among the requirements and work products." Bidirectional traceability is the ability to trace both forward and backward (i.e., from requirements to end products and from end product back to requirements).

Typically, traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, bidirectional traceability is achieved from the source requirements to lower-level requirements and selected work products and verifications and then back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements and selected work products can be traced to a valid source.

The term "stakeholder" is defined in CMMI models as

a group or individual who is affected by or is in some way accountable for the outcome of an undertaking.

The term "relevant stakeholder" is a subset of the term "stakeholder" and describes people or roles that are designated in a plan for stakeholder involvement.

Since "stakeholder" may describe a very large number of people, a lot of time and effort would be consumed by attempting to deal with all of them. For this reason, "relevant stakeholder" is used in most practice statements to describe the people identified to contribute to a specific task.

If you contrast generic practice 2.10 and generic practice 2.8, you can see that the focus of generic practice 2.8 is on the performance of the process and involves the immediate level of management; while the focus of generic practice 2.10 is on implementation of the process and the results of that implementation and involves reviews held with higher level management.

The purpose of the reviews described in generic practice 2.10 is to provide higher level management with insight into whether the planning and performance of the process is consistent with senior management expectations (as communicated in policies; see generic practice 2.1). These reviews will typically touch on any noteworthy process performance issues identified through the monitoring and review activities described in generic practice 2.8 and process implementation issues identified via objective evaluation activities described in generic practice 2.9.

Verification ensures that you are building a product according to its requirements, specifications, and standards. For Verification, you should ask the following questions:

• Are you meeting the specified requirements?
• Are you building the product right?

Validation ensures that your product will be usable once it is in its intended environment. For Validation, you should ask the following questions:

• Are you meeting the operational need?
• Does this product meet its intended use in the intended environment?
• Are you building the right product?

These concepts were separated into two process areas to stress both concepts. Both are applicable throughout the product development lifecycle and can be addressed using the same test or activity. The difference between the two can be seen in the purpose of the test or activity. When prototypes are developed to ensure that specific requirements can be addressed, it is an example of a verification practice. When end users are asked to evaluate prototypes to ensure that the product will meet their needs, it is an example of a validation practice.

The focus of validation is whether the product or product component, as provided (or as it will be provided), will fulfill its intended use in its operational environment. In many cases, the validation of product components will occur on intermediate work products early in the lifecycle to ensure that the product meets its intended use.

The following are examples of validation on products and work products throughout the product lifecycle:

• Validation begins early in the lifecycle with validation of requirements in specific goal 3 of Requirements Development.
• Prototypes are often developed and used to test design concepts and to confirm with end users that the product works as expected.
• Acceptance testing is used near the end of the lifecycle to ensure the product meets its intended use.
• Independent verification and validation (IV&V) also is employed near the end of the lifecycle to ensure the product meets its intended use in its intended environment. This environment may be simulated if the actual environment is not available.

In rare cases, acceptance testing may be an adequate implementation of this process area because, as stated above, there are usually a series of validation activities that will occur to ensure that the product works as intended.

The term "functional analysis" was used in CMMI to be universally applicable, and there is no intention to exclude an object oriented approach. In Requirements Development, specific practice 3.2, it says

The definition of functionality, also referred to as "functional analysis," is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.

Functional analysis is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining what are called "services" or "methods." The definition of functions, their logical groupings, and their association with requirements is referred to as a functional architecture.

Configuration management and quality assurance plans are not explicitly addressed in CMMI specific practices. Instead, generic practice 2.2, "Establish and maintain the plan for performing the process," covers the activities expected in a configuration management and quality assurance plan. These may be separate plans, or part of a more inclusive plan that meets organizational needs.

Senior management review is covered in generic practice 2.10, "Review the activities, status, and results of the process with higher level management and resolve issues." The first section within Part Two of the model provides a description of the generic practice that says

The purpose of this generic practice is to provide higher level management with the appropriate visibility into the process.

The concept of a documented procedure is handled in CMMI models by the generic goals that state that you perform a process according to a managed or defined process. The generic practices associated with these generic goals include documenting the processes and procedures that you use (e.g., see GP 2.2, subpractice 2).

Although the term "according to a documented procedure" is not explicitly used in CMMI models, the phrase "establish and maintain" is used. This phrase represents a meaning that includes not only establishing and maintaining, but also documenting and using.

For example, "Establish and maintain an organizational policy for planning and performing the organizational process focus process" means that you must formulate a policy, document it, maintain it, and use it.

Examples of system testing are provided in SP 1.1 of the Verification process area and SP 1.1 of the Validation process area. However, system testing is not a term used in CMMI, since the terms "system" and "testing" can be interpreted in many ways.

The term "system" was not used in CMMI because of its multiple interpretations across disciplines. Instead of "system," the term "product" and "product component" were used for consistency and clarity. The terms "verification" or "validation" were used instead of "testing" since (1) testing can be either part of verification or validation, and (2) testing is only one method used for verification or validation.

So, to find information on system testing, look instead for "product verification," "product validation," "product component verification," or "product component validation."

The models that were designated as the starting point for CMMI Product Suite development and were identified as source documents in the A-Spec are no longer being updated or supported by their issuing organizations. The product suite has replaced these source models. As other disciplines or constellations are incorporated into the CMMI Product Suite, their source models will follow the same process. As improvements are incorporated into the CMMI Product Suite, the original source documents will become obsolete and less representative of industry practice.

The CMMI Framework is designed to accommodate additional areas of interest. These new areas of interest will be added to the CMMI Framework as requested by CMMI users and approved by the CMMI Steering Group.

The process for adding new disciplines is documented in the Concept of Operations (CONOPS) for CMMI.