To support those using the continuous representation, all CMMI models reflect capability levels in their design and content. A capability level consists of a generic goal and its related generic practices as they relate to a process area, which can improve the organization’s processes associated with that process area. As you satisfy the generic goal and its generic practices at each capability level, you reap the benefits of process improvement for that process area.
The six capability levels, designated by the numbers 0 through 5, are as follows:
0. Incomplete
1. Performed
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
The fact that capability levels 2 through 5 use the same terms as generic goals 2 through 5 is intentional because each of these generic goals and practices reflects the meaning of the capability levels in terms of goals and practices you can implement. (See the Generic Goals and Generic Practices section on page 75 for more information about generic goals and practices.) A short description of each capability level follows.
Capability Level 0: Incomplete
An “incomplete process” is a process that either is not performed or partially performed. One or more of the specific goals of the process area are not satisfied, and no generic goals exist for this level since there is no reason to institutionalize a partially performed process.
Capability Level 1: Performed
A capability level 1 process is characterized as a “performed process.” A performed process is a process that satisfies the specific goals of the process area. It supports and enables the work needed to produce work products.
Although capability level 1 results in important improvements, those improvements can be lost over time if they are not institutionalized. The application of institutionalization (the CMMI generic practices at capability levels 2 through 5) helps to ensure that improvements are maintained.
Capability Level 2: Managed
A capability level 2 process is characterized as a “managed process.” A managed process is a performed (capability level 1) process that has the basic infrastructure in place to support the process. It is planned and executed in accordance with policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. The process discipline reflected by capability level 2 helps to ensure that existing practices are retained during times of stress.
Capability Level 3: Defined
A capability level 3 process is characterized as a “defined process.” A defined process is a managed (capability level 2) process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines, and contributes work products, measures, and other process improvement information to the organizational process assets.
A critical distinction between capability levels 2 and 3 is the scope of standards, process descriptions, and procedures. At capability level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (e.g., on a particular project). At capability level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit and therefore are more consistent, except for the differences allowed by the tailoring guidelines.Another critical distinction is that at capability level 3, processes are typically described more rigorously than at capability level 2. A defined process clearly states the purpose, inputs, entry criteria, activities, roles, measures, verification steps, outputs, and exit criteria. At capability level 3, processes are managed more proactively using an understanding of the interrelationships of the process activities and detailed measures of the process, its work products, and its services.
Capability Level 4: Quantitatively Managed
A capability level 4 process is characterized as a “quantitatively managed process.” A quantitatively managed process is a defined (capability level 3) process that is controlled using statistical and other quantitative techniques. Quantitative objectives for quality and process performance are established and used as criteria in managing the process. Quality and process performance is understood in statistical terms and is managed throughout the life of the process.
Capability Level 5: Optimizing
A capability level 5 process is characterized as an “optimizing process.” An optimizing process is a quantitatively managed (capability level 4) process that is improved based on an understanding of the common causes of variation inherent in the process. The focus of an optimizing process is on continually improving the range of process performance through both incremental and innovative improvements.
Advancing through Capability Levels
The capability levels of a process area are achieved through the application of generic practices or suitable alternatives to the processes associated with that process area.
Reaching capability level 1 for a process area is equivalent to saying that the processes associated with that process area are “performed processes.”
Reaching capability level 2 for a process area is equivalent to saying that there is a policy that indicates you will perform the process. There is a plan for performing it, resources are provided, responsibilities are assigned, training to perform it is provided, selected work products related to performing the process are controlled, and so on. In other words, a capability level 2 process can be planned and monitored just like any project or support activity.
Reaching capability level 3 for a process area assumes that an organizational standard process exists associated with that process area, which can be tailored to the needs of the project. The processes in the organization are now more consistently defined and applied because they are based on organizational standard processes.
Reaching capability level 4 for a process area assumes that this process area is a key business driver that the organization wants to manage using quantitative and statistical techniques. This analysis gives the organization more visibility into the performance of selected subprocesses that will make it more competitive in the marketplace.Reaching capability level 5 for a process area assumes that you have stabilized the selected subprocesses and that you want to reduce the common causes of variation within that process. Remember that variation is a natural occurrence in any process, so although it is conceptually feasible to improve all processes, it would not be economical to improve all processes to level 5. Again, you would concentrate on those processes that would help you to meet your business objectives.
.
Understanding Levels
Levels are used in CMMI to describe an evolutionary path recommended for an organization that wants to improve the processes it uses to develop and maintain its products and services. Levels can also be the outcome of the rating activity of appraisals. Appraisals can be performed for organizations that comprise entire (usually small) companies, or for smaller groups such as a group of projects or a division within a company.
CMMI supports two improvement paths. One path enables organizations to incrementally improve processes corresponding to an individual process area (or process areas) selected by the organization. The other path enables organizations to improve a set of related processes by incrementally addressing successive sets of process areas.
Regardless of which representation you select, the concept of levels is the same. Levels characterize improvement from an ill-defined state to a state that uses quantitative information to determine and manage improvements that are needed to meet an organization’s business objectives.To reach a particular level, an organization must satisfy all of the appropriate goals of the process area or set of process areas that are targeted for improvement, regardless of whether it is a capability or a maturity level.Both representations also provide ways to implement process improvement to achieve business objectives.
Both representations provide the same essential content and use the same model components.
CMMI supports two improvement paths. One path enables organizations to incrementally improve processes corresponding to an individual process area (or process areas) selected by the organization. The other path enables organizations to improve a set of related processes by incrementally addressing successive sets of process areas.
Regardless of which representation you select, the concept of levels is the same. Levels characterize improvement from an ill-defined state to a state that uses quantitative information to determine and manage improvements that are needed to meet an organization’s business objectives.To reach a particular level, an organization must satisfy all of the appropriate goals of the process area or set of process areas that are targeted for improvement, regardless of whether it is a capability or a maturity level.Both representations also provide ways to implement process improvement to achieve business objectives.
Both representations provide the same essential content and use the same model components.
Numbering Scheme
Specific and generic goals are numbered sequentially. Each specific goal begins with the prefix SG (e.g., SG 1). Each generic goal begins with the prefix GG (e.g., GG 2).
Each specific practice begins with the prefix SP, followed by a number in the form x.y (e.g., SP 1.1). The x is the same number as the goal to which the specific practice maps. The y is the sequence number of the specific practice under the specific goal.
An example of specific practice numbering is in the Project Planning process area. The first specific practice is numbered SP 1.1 and the second is SP 1.2.
Each generic practice begins with the prefix GP, followed by a number in the form x.y (e.g., GP 1.1).The x corresponds to the number of the generic goal. The y is the sequence number of the generic practice under the generic goal. For example, the first generic practice associated with GG 2 is numbered GP 2.1 and the second is GP 2.2.
Each specific practice begins with the prefix SP, followed by a number in the form x.y (e.g., SP 1.1). The x is the same number as the goal to which the specific practice maps. The y is the sequence number of the specific practice under the specific goal.
An example of specific practice numbering is in the Project Planning process area. The first specific practice is numbered SP 1.1 and the second is SP 1.2.
Each generic practice begins with the prefix GP, followed by a number in the form x.y (e.g., GP 1.1).The x corresponds to the number of the generic goal. The y is the sequence number of the generic practice under the generic goal. For example, the first generic practice associated with GG 2 is numbered GP 2.1 and the second is GP 2.2.
Supporting Informative Components
In many places, further information is needed to describe a concept. This informative material is provided in the form of the following components:
· Notes
· Examples
· Amplifications
· References
Notes
A note is text that can accompany nearly any other model component. It may provide detail, background, or rationale. A note is an informative model component.
For example, a note that accompanies the specific practice “Implement the selected action proposals that were developed in causal analysis” in the Causal Analysis and Resolution process area is “Only changes that prove to be of value should be considered for broad implementation.”
Examples
An example is a component comprising text and often a list of items, usually in a box, that can accompany nearly any other component and provides one or more examples to clarify a concept or described activity. An example is an informative model component.The following is an example that accompanies the subpractice “Document noncompliance issues when they cannot be resolved within the project” under the specific practice “Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers” in the Process and Product Quality Assurance process area.
Examples of ways to resolve noncompliance within the project include the following:
· Fixing the noncompliance
· Changing the process descriptions, standards, or procedures that were violated
· Obtaining a waiver to cover the noncompliance issue
Amplifications
An amplification is a note or example that is relevant to a particular discipline. The disciplines covered in this model are hardware engineering, systems engineering, and software engineering.
Each amplification is labeled with a heading that indicates the discipline to which it applies. For example, an amplification for software engineering is labeled “For Software Engineering.” An amplification is an informative model component.
An example of an amplification is the one that accompanies the specific practice “Establish and maintain the overall project plan content” in the Project Planning process area. The amplification states “For Hardware Engineering: For hardware, the planning document is often referred to as a hardware development plan. Development activities in preparation for production may be included in the hardware development plan or defined in a separate production plan.”
References
A reference is a pointer to additional or more detailed information in related process areas and can accompany nearly any other model component. A reference is an informative model component.
For example, a reference that accompanies the specific practice “Select the subprocesses that compose the project's defined process based on historical stability and capability data” in the Quantitative Project Management process area is “Refer to the Organizational Process Definition process area for more information about the organization's process asset library, which might include a process element of known and needed capability.”
· Notes
· Examples
· Amplifications
· References
Notes
A note is text that can accompany nearly any other model component. It may provide detail, background, or rationale. A note is an informative model component.
For example, a note that accompanies the specific practice “Implement the selected action proposals that were developed in causal analysis” in the Causal Analysis and Resolution process area is “Only changes that prove to be of value should be considered for broad implementation.”
Examples
An example is a component comprising text and often a list of items, usually in a box, that can accompany nearly any other component and provides one or more examples to clarify a concept or described activity. An example is an informative model component.The following is an example that accompanies the subpractice “Document noncompliance issues when they cannot be resolved within the project” under the specific practice “Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers” in the Process and Product Quality Assurance process area.
Examples of ways to resolve noncompliance within the project include the following:
· Fixing the noncompliance
· Changing the process descriptions, standards, or procedures that were violated
· Obtaining a waiver to cover the noncompliance issue
Amplifications
An amplification is a note or example that is relevant to a particular discipline. The disciplines covered in this model are hardware engineering, systems engineering, and software engineering.
Each amplification is labeled with a heading that indicates the discipline to which it applies. For example, an amplification for software engineering is labeled “For Software Engineering.” An amplification is an informative model component.
An example of an amplification is the one that accompanies the specific practice “Establish and maintain the overall project plan content” in the Project Planning process area. The amplification states “For Hardware Engineering: For hardware, the planning document is often referred to as a hardware development plan. Development activities in preparation for production may be included in the hardware development plan or defined in a separate production plan.”
References
A reference is a pointer to additional or more detailed information in related process areas and can accompany nearly any other model component. A reference is an informative model component.
For example, a reference that accompanies the specific practice “Select the subprocesses that compose the project's defined process based on historical stability and capability data” in the Quantitative Project Management process area is “Refer to the Organizational Process Definition process area for more information about the organization's process asset library, which might include a process element of known and needed capability.”
Components Associated in CMMI (3)
Generic Practices
Generic practices are called “generic” because the same practice applies to multiple process areas. A generic practice is the description of an activity that is considered important in achieving the associated generic goal. A generic practice is an expected model component.
For example, a generic practice for the generic goal “The process is institutionalized as a managed process” is “Provide adequate resources for performing the process, developing the work products, and providing the services of the process.”
Only the statement of the generic practice is an expected model component. The title of a generic practice (preceded by the practice number) and any notes associated with the practice are considered informative model components.
To reduce the repetitiveness of this information and to conserve the number of pages required to present this information, only the generic practice title, statement, and elaborations appear in the process areas. (See the Generic Goals and Generic Practices section on page 75 for a complete description of the generic practices.)
Generic Practice Elaborations
A generic practice elaboration appears after a generic practice in a process area to provide guidance on how the generic practice should be applied uniquely to the process area. A generic practice elaboration is an informative model component.
For example, a generic practice elaboration after the generic practice “Establish and maintain an organizational policy for planning and performing the project planning process” in the Project Planning process area is “This policy establishes organizational expectations for estimating the planning parameters, making internal and external commitments, and developing the plan for managing the project.”
Generic practices are called “generic” because the same practice applies to multiple process areas. A generic practice is the description of an activity that is considered important in achieving the associated generic goal. A generic practice is an expected model component.
For example, a generic practice for the generic goal “The process is institutionalized as a managed process” is “Provide adequate resources for performing the process, developing the work products, and providing the services of the process.”
Only the statement of the generic practice is an expected model component. The title of a generic practice (preceded by the practice number) and any notes associated with the practice are considered informative model components.
To reduce the repetitiveness of this information and to conserve the number of pages required to present this information, only the generic practice title, statement, and elaborations appear in the process areas. (See the Generic Goals and Generic Practices section on page 75 for a complete description of the generic practices.)
Generic Practice Elaborations
A generic practice elaboration appears after a generic practice in a process area to provide guidance on how the generic practice should be applied uniquely to the process area. A generic practice elaboration is an informative model component.
For example, a generic practice elaboration after the generic practice “Establish and maintain an organizational policy for planning and performing the project planning process” in the Project Planning process area is “This policy establishes organizational expectations for estimating the planning parameters, making internal and external commitments, and developing the plan for managing the project.”
Components Associated in CMMI (2)
Specific Goal and Practice Summaries
The specific goal and practice summary provides a high-level summary of the specific goals, which are required components, and the specific practices, which are expected components. The specific goal and practice summary is an informative component.
Specific Practices
A specific practice is the description of an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities that are expected to result in achievement of the specific goals of a process area. A specific practice is an expected model component.
For example, a specific practice from the Project Monitoring and Control process area is “Monitor commitments against those identified in the project plan.”
Only the statement of the specific practice is an expected model component. The title of a specific practice (preceded by the practice number) and any notes associated with the specific practice are considered informative model components.
Typical Work Products
The typical work products section lists sample output from a specific practice. These examples are called typical work products because there are often other work products that are just as effective but are not listed. A typical work product is an informative model component.
For example, a typical work product for the specific practice “Monitor the actual values of the project planning parameters against the project” in the Project Monitoring and Control process area is “Records of significant deviations.”
Subpractices
A subpractice is a detailed description that provides guidance for interpreting and implementing a specific or generic practice. Subpractices may be worded as if prescriptive, but are actually an informative component meant only to provide ideas that may be useful for process improvement.
For example, a subpractice for the specific practice “Take corrective action on identified issues” in the Project Monitoring and Control process area is “Determine and document the appropriate actions needed to address the identified issues.”
The specific goal and practice summary provides a high-level summary of the specific goals, which are required components, and the specific practices, which are expected components. The specific goal and practice summary is an informative component.
Specific Practices
A specific practice is the description of an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities that are expected to result in achievement of the specific goals of a process area. A specific practice is an expected model component.
For example, a specific practice from the Project Monitoring and Control process area is “Monitor commitments against those identified in the project plan.”
Only the statement of the specific practice is an expected model component. The title of a specific practice (preceded by the practice number) and any notes associated with the specific practice are considered informative model components.
Typical Work Products
The typical work products section lists sample output from a specific practice. These examples are called typical work products because there are often other work products that are just as effective but are not listed. A typical work product is an informative model component.
For example, a typical work product for the specific practice “Monitor the actual values of the project planning parameters against the project” in the Project Monitoring and Control process area is “Records of significant deviations.”
Subpractices
A subpractice is a detailed description that provides guidance for interpreting and implementing a specific or generic practice. Subpractices may be worded as if prescriptive, but are actually an informative component meant only to provide ideas that may be useful for process improvement.
For example, a subpractice for the specific practice “Take corrective action on identified issues” in the Project Monitoring and Control process area is “Determine and document the appropriate actions needed to address the identified issues.”
Components Associated in CMMI (1)
Purpose Statements
The purpose statement describes the purpose of the process area and is an informative component.
For example, the purpose statement of the Organizational Process Definition process area is “The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards.”
Introductory Notes
The introductory notes section of the process area describes the major concepts covered in the process area and is an informative component.
An example from the introductory notes of the Project Planning process area is “Planning begins with requirements that define the product and project.”
Related Process Areas
The related process areas section lists references to related process areas and reflects the high-level relationships among the process areas. The related process area section is an informative component.
An example of a reference found in the related process areas section of the Project Planning process area is “Refer to the Risk Management process area for more information about identifying and managing risks.”
Specific Goals
A specific goal describes the unique characteristics that must be present to satisfy the process area. A specific goal is a required model component and is used in appraisals to help determine whether a process area is satisfied.
For example, a specific goal from the Configuration Management process area is “Integrity of baselines is established and maintained.”Only the statement of the specific goal is a required model component. The title of a specific goal (preceded by the goal number) and any notes associated with the goal are considered informative model components.
Generic Goals
Generic goals are called “generic” because the same goal statement applies to multiple process areas. A generic goal describes the characteristics that must be present to institutionalize the processes that implement a process area. A generic goal is a required model component and is used in appraisals to determine whether a process area is satisfied. (See the Generic Goals and Generic Practices section on page 75 for a more detailed description of generic goals.)
An example of a generic goal is “The process is institutionalized as a defined process.”Only the statement of the generic goal is a required model component. The title of a generic goal (preceded by the goal number) and any notes associated with the goal are considered informative model components.
The purpose statement describes the purpose of the process area and is an informative component.
For example, the purpose statement of the Organizational Process Definition process area is “The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards.”
Introductory Notes
The introductory notes section of the process area describes the major concepts covered in the process area and is an informative component.
An example from the introductory notes of the Project Planning process area is “Planning begins with requirements that define the product and project.”
Related Process Areas
The related process areas section lists references to related process areas and reflects the high-level relationships among the process areas. The related process area section is an informative component.
An example of a reference found in the related process areas section of the Project Planning process area is “Refer to the Risk Management process area for more information about identifying and managing risks.”
Specific Goals
A specific goal describes the unique characteristics that must be present to satisfy the process area. A specific goal is a required model component and is used in appraisals to help determine whether a process area is satisfied.
For example, a specific goal from the Configuration Management process area is “Integrity of baselines is established and maintained.”Only the statement of the specific goal is a required model component. The title of a specific goal (preceded by the goal number) and any notes associated with the goal are considered informative model components.
Generic Goals
Generic goals are called “generic” because the same goal statement applies to multiple process areas. A generic goal describes the characteristics that must be present to institutionalize the processes that implement a process area. A generic goal is a required model component and is used in appraisals to determine whether a process area is satisfied. (See the Generic Goals and Generic Practices section on page 75 for a more detailed description of generic goals.)
An example of a generic goal is “The process is institutionalized as a defined process.”Only the statement of the generic goal is a required model component. The title of a generic goal (preceded by the goal number) and any notes associated with the goal are considered informative model components.
Process Areas in CMMI
A process area is a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvement in that area.
There are 22 process areas, presented here in alphabetical order by acronym:
· Causal Analysis and Resolution (CAR)
· Configuration Management (CM)
· Decision Analysis and Resolution (DAR)
· Integrated Project Management +IPPD (IPM+IPPD)
· Measurement and Analysis (MA)
· Organizational Innovation and Deployment (OID)
· Organizational Process Definition +IPPD (OPD+IPPD)
· Organizational Process Focus (OPF)
· Organizational Process Performance (OPP)
· Organizational Training (OT)
· Product Integration (PI)
· Project Monitoring and Control (PMC)
· Project Planning (PP)
· Process and Product Quality Assurance (PPQA)
· Quantitative Project Management (QPM)
· Requirements Development (RD)
· Requirements Management (REQM)
· Risk Management (RSKM)
· Supplier Agreement Management (SAM)
· Technical Solution (TS)
· Validation (VAL)
· Verification (VER)
This process area has "+IPPD" after its name because it contains a goal and practices that are specific to IPPD. The material specific to IPPD is called an "IPPD addition." All process areas with IPPD additions have "+IPPD" after their name.
There are 22 process areas, presented here in alphabetical order by acronym:
· Causal Analysis and Resolution (CAR)
· Configuration Management (CM)
· Decision Analysis and Resolution (DAR)
· Integrated Project Management +IPPD (IPM+IPPD)
· Measurement and Analysis (MA)
· Organizational Innovation and Deployment (OID)
· Organizational Process Definition +IPPD (OPD+IPPD)
· Organizational Process Focus (OPF)
· Organizational Process Performance (OPP)
· Organizational Training (OT)
· Product Integration (PI)
· Project Monitoring and Control (PMC)
· Project Planning (PP)
· Process and Product Quality Assurance (PPQA)
· Quantitative Project Management (QPM)
· Requirements Development (RD)
· Requirements Management (REQM)
· Risk Management (RSKM)
· Supplier Agreement Management (SAM)
· Technical Solution (TS)
· Validation (VAL)
· Verification (VER)
This process area has "+IPPD" after its name because it contains a goal and practices that are specific to IPPD. The material specific to IPPD is called an "IPPD addition." All process areas with IPPD additions have "+IPPD" after their name.
Required, Expected, and Informative Components
Model components are grouped into three categories—required, expected, and informative—that reflect how to interpret them.
Required Components
Required components describe what an organization must achieve to satisfy a process area. This achievement must be visibly implemented in an organization’s processes. The required components in CMMI are the specific and generic goals. Goal satisfaction is used in appraisals as the basis for deciding whether a process area has been achieved and satisfied.
Expected Components
Expected components describe what an organization may implement to achieve a required component. Expected components guide those who implement improvements or perform appraisals. Expected components include the specific and generic practices.
Before goals can be considered satisfied, either the practices as described, or acceptable alternatives to them, are present in the planned and implemented processes of the organization.
Informative Components
Informative components provide details that help organizations get started in thinking about how to approach the required and expected components. Subpractices, typical work products, amplifications, generic practice elaborations, goal and practice titles, goal and practice notes, and references are examples of informative model components.The CMMI glossary of terms is not a required, expected, or informative component of CMMI models. You should interpret the terms in the glossary in the context of the model component in which they appear.
Required Components
Required components describe what an organization must achieve to satisfy a process area. This achievement must be visibly implemented in an organization’s processes. The required components in CMMI are the specific and generic goals. Goal satisfaction is used in appraisals as the basis for deciding whether a process area has been achieved and satisfied.
Expected Components
Expected components describe what an organization may implement to achieve a required component. Expected components guide those who implement improvements or perform appraisals. Expected components include the specific and generic practices.
Before goals can be considered satisfied, either the practices as described, or acceptable alternatives to them, are present in the planned and implemented processes of the organization.
Informative Components
Informative components provide details that help organizations get started in thinking about how to approach the required and expected components. Subpractices, typical work products, amplifications, generic practice elaborations, goal and practice titles, goal and practice notes, and references are examples of informative model components.The CMMI glossary of terms is not a required, expected, or informative component of CMMI models. You should interpret the terms in the glossary in the context of the model component in which they appear.
Why Not Both Representations?
Whether used for process improvement or appraisals, both representations are designed to offer essentially equivalent results. Nearly all of the CMMI model content is common to both representations. Therefore, an organization need not select one representation over another.
In fact, an organization may find utility in both representations. It is rare that an organization will implement either representation exactly as prescribed. Organizations that are successful in process improvement often define an improvement plan that focuses on the unique needs of that organization and therefore use the principles of both the staged and the continuous representations.
For example, organizations that select the staged representation and are at maturity level 1 often implement the maturity level 2 process areas but also the Organizational Process Focus process area, which is included at maturity level 3. Another example is an organization that chooses the continuous representation for guiding its internal process improvement effort and then chooses the staged representation to conduct an appraisal.
In fact, an organization may find utility in both representations. It is rare that an organization will implement either representation exactly as prescribed. Organizations that are successful in process improvement often define an improvement plan that focuses on the unique needs of that organization and therefore use the principles of both the staged and the continuous representations.
For example, organizations that select the staged representation and are at maturity level 1 often implement the maturity level 2 process areas but also the Organizational Process Focus process area, which is included at maturity level 3. Another example is an organization that chooses the continuous representation for guiding its internal process improvement effort and then chooses the staged representation to conduct an appraisal.
Comparison of the Continuous and Staged Representations
Compares the advantages of each representation and may assist you with determining which representation is right for your organization.
Comparative Advantages of Continuous and Staged Representations
Continuous Representation
Comparative Advantages of Continuous and Staged Representations
Continuous Representation
- Grants explicit freedom to select the order of improvement that best meets the organization’s business objectives and mitigates the organization’s areas of risk
- Enables increased visibility of the capability achieved in each individual process area
- Allows improvements of different processes to be performed at different rates
- Reflects a newer approach that does not yet have the data to demonstrate its ties to return on investment
Staged Representation
- Enables organizations to have a predefined and proven improvement path
- Focuses on a set of processes that provide an organization with a specific capability that is characterized by each maturity level
- Summarizes process improvement results in a simple form—a single maturity level number
- Builds on a relatively long history of use that includes case studies and data that demonstrate return on investment
Staged Representation
The staged representation offers a systematic, structured way to approach model-based process improvement one stage at a time. Achieving each stage ensures that an adequate process infrastructure has been laid as a foundation for the next stage.
Process areas are organized by maturity levels that take some of the guess work out of process improvement. The staged representation prescribes an order for implementing process areas according to maturity levels, which define the improvement path for an organization from the initial level to the optimizing level. Achieving each maturity level ensures that an adequate improvement foundation has been laid for the next maturity level and allows for lasting, incremental improvement.If you do not know where to start and which processes to choose to improve, the staged representation is a good choice for you. It gives you a specific set of processes to improve at each stage that has been determined through more than a decade of research and experience with process improvement.
Process areas are organized by maturity levels that take some of the guess work out of process improvement. The staged representation prescribes an order for implementing process areas according to maturity levels, which define the improvement path for an organization from the initial level to the optimizing level. Achieving each maturity level ensures that an adequate improvement foundation has been laid for the next maturity level and allows for lasting, incremental improvement.If you do not know where to start and which processes to choose to improve, the staged representation is a good choice for you. It gives you a specific set of processes to improve at each stage that has been determined through more than a decade of research and experience with process improvement.
Continuous Representation
The continuous representation offers maximum flexibility when using a CMMI model for process improvement. An organization may choose to improve the performance of a single process-related trouble spot, or it can work on several areas that are closely aligned to the organization’s business objectives. The continuous representation also allows an organization to improve different processes at different rates. There are some limitations on an organization’s choices because of the dependencies among some process areas.If you know the processes that need to be improved in your organization and you understand the dependencies among the process areas described in CMMI, the continuous representation is a good choice for your organization.
Choosing a Representation
If you are new to process improvement and are not familiar with either the staged or the continuous representation, you cannot go wrong if you choose one representation or the other. There are many valid reasons to select either representation.
If you have been using a CMM and you are familiar with a particular representation, we suggest that you continue to use that representation because it will make the transition to CMMI easier. Once you have become completely comfortable with CMMI, you might then decide to use the other representation.
Because each representation has advantages over the other, some organizations use both representations to address particular needs at various times in their improvement programs. In the following sections, we provide the advantages and disadvantages of each representation to help you decide which representation is best for your organization.
If you have been using a CMM and you are familiar with a particular representation, we suggest that you continue to use that representation because it will make the transition to CMMI easier. Once you have become completely comfortable with CMMI, you might then decide to use the other representation.
Because each representation has advantages over the other, some organizations use both representations to address particular needs at various times in their improvement programs. In the following sections, we provide the advantages and disadvantages of each representation to help you decide which representation is best for your organization.
Resolving Different Approaches of CMMs
The definition of a CMM allows the community to develop models supporting different approaches to process improvement. As long as a model contains the essential elements of effective processes for one or more disciplines and describes an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness, it is considered a CMM. CMMI enables you to approach process improvement and appraisals using two different representations: continuous and staged.
The continuous representation enables an organization to select a process area (or group of process areas) and improve processes related to it. This representation uses capability levels to characterize improvement relative to an individual process area.The staged representation uses predefined sets of process areas to define an improvement path for an organization. This improvement path is characterized by maturity levels. Each maturity level provides a set of process areas that characterize different organizational behaviors.
The continuous representation enables an organization to select a process area (or group of process areas) and improve processes related to it. This representation uses capability levels to characterize improvement relative to an individual process area.The staged representation uses predefined sets of process areas to define an improvement path for an organization. This improvement path is characterized by maturity levels. Each maturity level provides a set of process areas that characterize different organizational behaviors.
The Group of IPPD Additions
In CMMI, “additions” are used to include material that may be of interest to particular users. For the CMMI for Development constellation, additional material was included to address IPPD.
The IPPD group of additions covers an IPPD approach that includes practices that help organizations achieve the timely collaboration of relevant stakeholders throughout the life of the product to satisfy customers’ needs, expectations, and requirements [DoD 1996]. When using processes that support an IPPD approach, you should integrate these processes with other processes in the organization. To support those using IPPD-related processes, the CMMI for Development constellation allows organizations to optionally select the IPPD group of additions.
When you select CMMI for Development +IPPD, you are selecting the CMMI for Development model plus all the IPPD additions. When you select CMMI for Development, you are selecting the model without the IPPD additions. In the text in Part One of this document, we may use “CMMI for Development” to refer to either of these models, for the sake of brevity.
The IPPD group of additions covers an IPPD approach that includes practices that help organizations achieve the timely collaboration of relevant stakeholders throughout the life of the product to satisfy customers’ needs, expectations, and requirements [DoD 1996]. When using processes that support an IPPD approach, you should integrate these processes with other processes in the organization. To support those using IPPD-related processes, the CMMI for Development constellation allows organizations to optionally select the IPPD group of additions.
When you select CMMI for Development +IPPD, you are selecting the CMMI for Development model plus all the IPPD additions. When you select CMMI for Development, you are selecting the model without the IPPD additions. In the text in Part One of this document, we may use “CMMI for Development” to refer to either of these models, for the sake of brevity.
The Scope of CMMI for Development
CMMI for Development is a reference model that covers the development and maintenance activities applied to both products and services. Organizations from many industries, including aerospace, banking, computer hardware, software, defense, automobile manufacturing, and telecommunications, use CMMI for Development.Models in the CMMI for Development constellation contain practices that cover project management, process management, systems engineering, hardware engineering, software engineering, and other supporting processes used in development and maintenance. The CMMI for Development +IPPD model also covers the use of integrated teams for development and maintenance activities.
CMMI for Development
The CMMI for Development constellation consists of two models: CMMI for Development +IPPD and CMMI for Development (without IPPD). Both models share much of their material and are identical in these shared areas. However, CMMI for Development +IPPD contains additional goals and practices that cover IPPD.
Currently, only one model is published since the CMMI for Development +IPPD model contains the full complement of practices available in this constellation, and you can derive the other model from this material. If you are not using IPPD, ignore the information that is marked “IPPD Addition,” and you will be using the CMMI for Development model. If the need arises or the development constellation is expanded, the architecture will allow other models to be generated and published.
CMMI for Development is the designated successor of the three source models. The SEI has retired the Software CMM and the IPD-CMM. EIA has retired the SECM. All three of these models are succeeded by CMMI for Development.
The best practices in the CMMI models have gone through an extensive review process. CMMI version 0.2 was publicly reviewed and used in pilot activities.
The CMMI Product Team evaluated more than 3,000 change requests to create CMMI version 1.0. Shortly thereafter, version 1.02 was released, which incorporated several minor improvements.
Version 1.1 incorporated improvements guided by feedback from early use, with more than 1,500 change requests submitted as part of the public review, and hundreds of comments as part of the change control process.CMMI version 1.2 was developed using input from nearly 2,000 change requests submitted by CMMI users. More than 750 of those requests were directed at CMMI model content. As you can see, not only is CMMI widely adopted, but it is improved based on the feedback received from the community.
Currently, only one model is published since the CMMI for Development +IPPD model contains the full complement of practices available in this constellation, and you can derive the other model from this material. If you are not using IPPD, ignore the information that is marked “IPPD Addition,” and you will be using the CMMI for Development model. If the need arises or the development constellation is expanded, the architecture will allow other models to be generated and published.
CMMI for Development is the designated successor of the three source models. The SEI has retired the Software CMM and the IPD-CMM. EIA has retired the SECM. All three of these models are succeeded by CMMI for Development.
The best practices in the CMMI models have gone through an extensive review process. CMMI version 0.2 was publicly reviewed and used in pilot activities.
The CMMI Product Team evaluated more than 3,000 change requests to create CMMI version 1.0. Shortly thereafter, version 1.02 was released, which incorporated several minor improvements.
Version 1.1 incorporated improvements guided by feedback from early use, with more than 1,500 change requests submitted as part of the public review, and hundreds of comments as part of the change control process.CMMI version 1.2 was developed using input from nearly 2,000 change requests submitted by CMMI users. More than 750 of those requests were directed at CMMI model content. As you can see, not only is CMMI widely adopted, but it is improved based on the feedback received from the community.
Evolution of CMMI
Since 1991, CMMs have been developed for myriad disciplines. Some of the most notable include models for systems engineering, software engineering, software acquisition, workforce management and development, and integrated product and process development (IPPD).
Although these models have proven useful to many organizations in different industries, the use of multiple models has been problematic. Many organizations would like their improvement efforts to span different groups in their organizations. However, the differences among the discipline-specific models used by each group, including their architecture, content, and approach, have limited these organizations’ capabilities to broaden their improvements successfully. Further, applying multiple models that are not integrated within and across an organization is costly in terms of training, appraisals, and improvement activities.
The CMM IntegrationSM project was formed to sort out the problem of using multiple CMMs. The CMMI Product Team’s initial mission was to combine three source models:
1. The Capability Maturity Model for Software (SW-CMM) v2.0 draft C [SEI 1997b]
2. The Systems Engineering Capability Model (SECM) [EIA 1998]
3. The Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 [SEI 1997a]
The combination of these models into a single improvement framework was intended for use by organizations in their pursuit of enterprise-wide process improvement.
These three source models were selected because of their widespread adoption in the software and systems engineering communities and because of their different approaches to improving processes in an organization.
Using information from these popular and well-regarded models as source material, the CMMI Product Team created a cohesive set of integrated models that can be adopted by those currently using the source models, as well as by those new to the CMM concept. Hence, CMMI is a result of the evolution of the SW-CMM, the SECM, and the IPD-CMM.
Developing a set of integrated models involved more than simply combining existing model materials. Using processes that promote consensus, the CMMI Product Team built a framework that accommodates multiple disciplines and is flexible enough to support the different approaches of the source models [Ahern 2003].
The Systems Engineering Capability Model is also known as Electronic Industries Alliance 731 (EIA 731).
Since the release of CMMI v1.1, we have seen that this improvement framework can be applied to other areas of interest [SEI 2002a, SEI 2002b]. To apply to multiple areas of interest, the framework groups best practices into what we call “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 services (CMMI for Services) and the other for acquisition (CMMI for Acquisition). 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), which 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.
Although these models have proven useful to many organizations in different industries, the use of multiple models has been problematic. Many organizations would like their improvement efforts to span different groups in their organizations. However, the differences among the discipline-specific models used by each group, including their architecture, content, and approach, have limited these organizations’ capabilities to broaden their improvements successfully. Further, applying multiple models that are not integrated within and across an organization is costly in terms of training, appraisals, and improvement activities.
The CMM IntegrationSM project was formed to sort out the problem of using multiple CMMs. The CMMI Product Team’s initial mission was to combine three source models:
1. The Capability Maturity Model for Software (SW-CMM) v2.0 draft C [SEI 1997b]
2. The Systems Engineering Capability Model (SECM) [EIA 1998]
3. The Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 [SEI 1997a]
The combination of these models into a single improvement framework was intended for use by organizations in their pursuit of enterprise-wide process improvement.
These three source models were selected because of their widespread adoption in the software and systems engineering communities and because of their different approaches to improving processes in an organization.
Using information from these popular and well-regarded models as source material, the CMMI Product Team created a cohesive set of integrated models that can be adopted by those currently using the source models, as well as by those new to the CMM concept. Hence, CMMI is a result of the evolution of the SW-CMM, the SECM, and the IPD-CMM.
Developing a set of integrated models involved more than simply combining existing model materials. Using processes that promote consensus, the CMMI Product Team built a framework that accommodates multiple disciplines and is flexible enough to support the different approaches of the source models [Ahern 2003].
The Systems Engineering Capability Model is also known as Electronic Industries Alliance 731 (EIA 731).
Since the release of CMMI v1.1, we have seen that this improvement framework can be applied to other areas of interest [SEI 2002a, SEI 2002b]. To apply to multiple areas of interest, the framework groups best practices into what we call “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 services (CMMI for Services) and the other for acquisition (CMMI for Acquisition). 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), which 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.
About Capability Maturity Models
In its research to help organizations develop and maintain quality products and services, the Software Engineering Institute (SEI) has found several dimensions that an organization can focus on to improve its business.
But what holds everything together? It is the processes used in your organization. Processes allow you to align the way you do business. They allow you to address scalability and provide a way to incorporate knowledge of how to do things better. Processes allow you to leverage your resources and to examine business trends.
This is not to say that people and technology are not important. We are living in a world where technology is changing by an order of magnitude every ten years. Similarly, people typically work for many companies throughout their careers. We live in a dynamic world. A focus on process provides the infrastructure necessary to deal with an ever-changing world, and to maximize the productivity of people and the use of technology to be more competitive.
Manufacturing has long recognized the importance of process effectiveness and efficiency. Today, many organizations in manufacturing and service industries recognize the importance of quality processes. Process helps an organization’s workforce meet business objectives by helping them work smarter, not harder, and with improved consistency. Effective processes also provide a vehicle for introducing and using new technology in a way that best meets the business objectives of the organization.
In the 1930s, Walter Shewhart began work in process improvement with his principles of statistical quality control [Shewhart 1931]. These principles were refined by W. Edwards Deming [Deming 1986], Phillip Crosby [Crosby 1979], and Joseph Juran [Juran 1988]. Watts Humphrey, Ron Radice, and others extended these principles even further and began applying them to software in their work at IBM and the SEI [Humphrey 1989]. Humphrey’s book, Managing the Software Process, provides a description of the basic principles and concepts on which many of the capability maturity models (CMMs®) are based.
The SEI has taken the process management premise, “the quality of a system or product is highly influenced by the quality of the process used to develop and maintain it,” and defined CMMs that embody this premise. The belief in this premise is seen worldwide in quality movements, as evidenced by the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) body of standards.
CMMs focus on improving processes in an organization. They contain the essential elements of effective processes for one or more disciplines and describe an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness.
The SEI created the first CMM designed for software organizations and published it in a book, The Capability Maturity Model: Guidelines for Improving the Software Process [SEI 1995].The SEI’s book applied the principles introduced almost a century ago to this never-ending cycle of process improvement. The value of this process improvement approach has been confirmed over time. Organizations have experienced increased productivity and quality, improved cycle time, and more accurate and predictable schedules and budgets
But what holds everything together? It is the processes used in your organization. Processes allow you to align the way you do business. They allow you to address scalability and provide a way to incorporate knowledge of how to do things better. Processes allow you to leverage your resources and to examine business trends.
This is not to say that people and technology are not important. We are living in a world where technology is changing by an order of magnitude every ten years. Similarly, people typically work for many companies throughout their careers. We live in a dynamic world. A focus on process provides the infrastructure necessary to deal with an ever-changing world, and to maximize the productivity of people and the use of technology to be more competitive.
Manufacturing has long recognized the importance of process effectiveness and efficiency. Today, many organizations in manufacturing and service industries recognize the importance of quality processes. Process helps an organization’s workforce meet business objectives by helping them work smarter, not harder, and with improved consistency. Effective processes also provide a vehicle for introducing and using new technology in a way that best meets the business objectives of the organization.
In the 1930s, Walter Shewhart began work in process improvement with his principles of statistical quality control [Shewhart 1931]. These principles were refined by W. Edwards Deming [Deming 1986], Phillip Crosby [Crosby 1979], and Joseph Juran [Juran 1988]. Watts Humphrey, Ron Radice, and others extended these principles even further and began applying them to software in their work at IBM and the SEI [Humphrey 1989]. Humphrey’s book, Managing the Software Process, provides a description of the basic principles and concepts on which many of the capability maturity models (CMMs®) are based.
The SEI has taken the process management premise, “the quality of a system or product is highly influenced by the quality of the process used to develop and maintain it,” and defined CMMs that embody this premise. The belief in this premise is seen worldwide in quality movements, as evidenced by the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) body of standards.
CMMs focus on improving processes in an organization. They contain the essential elements of effective processes for one or more disciplines and describe an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness.
The SEI created the first CMM designed for software organizations and published it in a book, The Capability Maturity Model: Guidelines for Improving the Software Process [SEI 1995].The SEI’s book applied the principles introduced almost a century ago to this never-ending cycle of process improvement. The value of this process improvement approach has been confirmed over time. Organizations have experienced increased productivity and quality, improved cycle time, and more accurate and predictable schedules and budgets
The IDEAL Model
Initiating, Diagnosing, Establishing, Acting & Learning
The IDEAL model is an organizational improvement model that serves as a roadmap for initiating, planning, and implementing improvement actions. The IDEAL model is named for the five phases it describes: initiating, diagnosing, establishing, acting, and learning.
The IDEAL model forms an infrastructure to guide organizations in planning and implementing an effective software process improvement program, and is the founding strategy employed in delivering many Software Engineering Institute (SEI) services. Organizations that follow the IDEAL approach to software process improvement (SPI) can effectively integrate SEI technologies, courses, workshops, and services into a comprehensive method for managing and improving their overall capacity.
INTRo Builds From IDEAL
IDEAL offers a high-level approach to software process improvement (SPI). IDEAL-Based New Technology Rollout (INTRo) takes advantage of the lessons learned from using IDEAL in SPI, and extends and applies those lessons to the domain of information technology (IT) package selection and deployment. INTRo goes further than IDEAL by providing a greater level of detail, content, and support for users.
The IDEAL model is an organizational improvement model that serves as a roadmap for initiating, planning, and implementing improvement actions. The IDEAL model is named for the five phases it describes: initiating, diagnosing, establishing, acting, and learning.
The IDEAL model forms an infrastructure to guide organizations in planning and implementing an effective software process improvement program, and is the founding strategy employed in delivering many Software Engineering Institute (SEI) services. Organizations that follow the IDEAL approach to software process improvement (SPI) can effectively integrate SEI technologies, courses, workshops, and services into a comprehensive method for managing and improving their overall capacity.
INTRo Builds From IDEAL
IDEAL offers a high-level approach to software process improvement (SPI). IDEAL-Based New Technology Rollout (INTRo) takes advantage of the lessons learned from using IDEAL in SPI, and extends and applies those lessons to the domain of information technology (IT) package selection and deployment. INTRo goes further than IDEAL by providing a greater level of detail, content, and support for users.
The "sashimi" model
The sashimi model (so called because it features overlapping phases, like the overlapping fish of Japanese sashimi) was originated by Peter DeGrace. It is sometimes referred to as the "waterfall model with overlapping phases" or "the waterfall model with feedback". Since phases in the sashimi model overlap, information of problem spots can be acted upon during phases of the waterfall model that would typically "precede" others in the pure waterfall model. For example, since the design and implementation phases will overlap in the sashimi model, implementation problems may be discovered during the "design and implementation" phase of the development process.This helps alleviate many of the problems associated with the Big Design Up Front philosophy of the waterfall model.
Modified waterfall models
In response to the perceived problems with the "pure" waterfall model, many modified waterfall models have been introduced. These models may address some or all of the criticisms of the "pure" waterfall model. Many different models are covered by Steve McConnell in the "lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.
While all software development models will bear at least some similarity to the waterfall model, as all software development models will incorporate at least some phases similar to those used within the waterfall model, this section will deal with those closest to the waterfall model. For models which apply further differences to the waterfall model, or for radically different models seek general information on the software development process.
While all software development models will bear at least some similarity to the waterfall model, as all software development models will incorporate at least some phases similar to those used within the waterfall model, this section will deal with those closest to the waterfall model. For models which apply further differences to the waterfall model, or for radically different models seek general information on the software development process.
Criticism of the waterfall model
The waterfall model is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible, for any non-trivial project, to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them. For example, clients may not be aware of exactly what requirements they want before they see a working prototype and can comment upon it; they may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested into "Big Design Up Front". Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas.
Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) refers to design as a "wicked problem" - a problem whose requirements and limitations cannot be entirely known before completion. The implication is that it is impossible to get one phase of software development "perfected" before time is spent in "reconnaissance" working out exactly where and what the big problems are.
Additional criticisms of a non-iterative development approach (such as the waterfall model) include:
Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) refers to design as a "wicked problem" - a problem whose requirements and limitations cannot be entirely known before completion. The implication is that it is impossible to get one phase of software development "perfected" before time is spent in "reconnaissance" working out exactly where and what the big problems are.
Additional criticisms of a non-iterative development approach (such as the waterfall model) include:
Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it. That is, feedback from following phases is needed to complete "preceding" phases satisfactorily. For example, the design phase may need feedback from the implementation phase to identify problem design areas. The counter-argument for the waterfall model is that experienced designers may have worked on similar systems before, and so may be able to accurately predict problem areas without time spent prototyping and implementing.
Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Constant "prototype design" work is needed to ensure that requirements are non-contradictory and possible to fulfill; constant implementation is needed to find problem areas and inform the design process; constant integration and verification of the implemented code is necessary to ensure that implementation remains on track. The counter-argument for the waterfall model here is that constant implementation and testing to validate the design and requirements is only needed if the introduction of bugs is likely to be a problem. Users of the waterfall model may argue that if designers (et cetera) follow a disciplined process and do not make mistakes that there is no need for constant work in subsequent phases to validate the preceding phases.
Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client.
It is difficult to estimate time and cost for each phase of the development process without doing some "recon" work in that phase, unless those estimating time and cost are highly experienced with the type of software product in question.
The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself.
Very specific skill sets are required for each phase, thus there is a requirement for multiple projects to run in sequence to optimize resource use if all members stay through the course of a given project, or to suffer skill levels by using "jack of all trades" resources throughout each stage.
Arguments for the waterfall model
Time spent early on in software production can lead to greater economy later on in the software lifecycle; that is, it has been shown many times that a bug found in the early stages of the production lifecycle (such as requirements specification or design) is cheaper, in terms of money, effort and time, to fix than the same bug found later on in the process. ([McConnell 1996], p. 72, estimates that "a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time.") To take an extreme example, if a program design turns out to be impossible to implement, it is easier to fix the design at the design stage than to realize months later, when program components are being integrated, that all the work done so far has to be scrapped because of a broken design.
This is the central idea behind Big Design Up Front (BDUF) and the waterfall model - time spent early on making sure that requirements and design are absolutely correct will save you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, one should make sure that each phase is 100% complete and absolutely correct before proceeding to the next phase of program creation. Program requirements should be set in stone before design is started (otherwise work put into a design based on "incorrect" requirements is wasted); the program's design should be perfect before people begin work on implementing the design (otherwise they are implementing the "wrong" design and their work is wasted), etc.
A further argument for the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as source code. In less designed and documented methodologies, should team members leave, much knowledge is lost and may be difficult for a project to recover from. Should a fully working design document be present (as is the intent of Big Design Up Front and the waterfall model) new team members or even entirely new teams should be able to familiarize themselves by reading the documents.
As well as the above, some prefer the waterfall model for its simple and arguably more disciplined approach. Rather than what the waterfall adherent sees as "chaos", the waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable "phases" and is thus easy to understand; it also provides easily markable "milestones" in the development process. It is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and courses.
It is argued that the waterfall model and Big Design Up Front in general can be suited to software projects which are stable (especially those projects with unchanging requirements, such as with "shrink wrap" software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started. The waterfall model also requires that implementers follow the well made, complete design accurately, ensuring that the integration of the system proceeds smoothly.
Sunil sees the two big advantages of the pure waterfall model as producing a "highly reliable system" and one with a "large growth envelope", but rates it as poor on all other fronts. On the other hand, he views any of several modified waterfall models (described below) as preserving these advantages while also rating as "fair to excellent" on "work[ing] with poorly understood requirements" or "poorly understood architecture" and "provid[ing] management with progress visibility", and rating as "fair" on "manag[ing] risks", being able to "be constrained to a predefined schedule", "allow[ing] for midcourse corrections", and "provid[ing] customer with progress visibility". The only criterion on which he rates a modified waterfall as poor is that it requires sophistication from management and developers. (Rapid Development, 156)
This is the central idea behind Big Design Up Front (BDUF) and the waterfall model - time spent early on making sure that requirements and design are absolutely correct will save you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, one should make sure that each phase is 100% complete and absolutely correct before proceeding to the next phase of program creation. Program requirements should be set in stone before design is started (otherwise work put into a design based on "incorrect" requirements is wasted); the program's design should be perfect before people begin work on implementing the design (otherwise they are implementing the "wrong" design and their work is wasted), etc.
A further argument for the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as source code. In less designed and documented methodologies, should team members leave, much knowledge is lost and may be difficult for a project to recover from. Should a fully working design document be present (as is the intent of Big Design Up Front and the waterfall model) new team members or even entirely new teams should be able to familiarize themselves by reading the documents.
As well as the above, some prefer the waterfall model for its simple and arguably more disciplined approach. Rather than what the waterfall adherent sees as "chaos", the waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable "phases" and is thus easy to understand; it also provides easily markable "milestones" in the development process. It is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and courses.
It is argued that the waterfall model and Big Design Up Front in general can be suited to software projects which are stable (especially those projects with unchanging requirements, such as with "shrink wrap" software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started. The waterfall model also requires that implementers follow the well made, complete design accurately, ensuring that the integration of the system proceeds smoothly.
Sunil sees the two big advantages of the pure waterfall model as producing a "highly reliable system" and one with a "large growth envelope", but rates it as poor on all other fronts. On the other hand, he views any of several modified waterfall models (described below) as preserving these advantages while also rating as "fair to excellent" on "work[ing] with poorly understood requirements" or "poorly understood architecture" and "provid[ing] management with progress visibility", and rating as "fair" on "manag[ing] risks", being able to "be constrained to a predefined schedule", "allow[ing] for midcourse corrections", and "provid[ing] customer with progress visibility". The only criterion on which he rates a modified waterfall as poor is that it requires sophistication from management and developers. (Rapid Development, 156)
Waterfall model Usage
The Waterfall model is widely used, including by such large software development houses as those employed by the US Department of Defense and NASA and upon many large government projects (see "the standard waterfall model" on the Internet Archive). Those who use such methods do not always formally distinguish between the "pure" waterfall model and the various modified waterfall models, so it can be difficult to discern exactly which models are being used to what extent.
Waterfall model
The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. The origin of the term "waterfall" is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Ironically, Royce was actually presenting this model as an example of a flawed, non-working model.
History of the waterfall model
In 1970 Royce proposed what is presently referred to as the waterfall model as an initial concept, a model which he argued was flawed. His paper explored how the initial model could be developed into an iterative model, with feedback from each phase influencing subsequent phases. It is only the initial model that received notice; his own criticism of this initial model has been largely ignored. The "waterfall model" quickly came to refer not to Royce's final, iterative design, but rather to his purely sequentially ordered model. This article will use this popular meaning of the phrase waterfall model. For an iterative model similar to Royce's final vision.Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of the "waterfall model" as a purely sequential process is still popular, and, for some, the phrase "waterfall model" has since come to refer to any approach to software creation which is seen as inflexible and non-iterative. Those who use the phrase "waterfall model" pejoratively for non-iterative models that they dislike usually see the waterfall model itself as naive and unsuitable for an "iterative" process.
The model
The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.
In Royce's original waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA validation)
6. Installation
7. Maintenance
To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes "requirements specification" — they set in stone the requirements of the software. When the requirements are fully completed, one proceeds to design. The software in question is designed and a "blueprint" is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated. After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs.
Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are discrete, and there is no jumping back and forth or overlap between them.
However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.
History of the waterfall model
In 1970 Royce proposed what is presently referred to as the waterfall model as an initial concept, a model which he argued was flawed. His paper explored how the initial model could be developed into an iterative model, with feedback from each phase influencing subsequent phases. It is only the initial model that received notice; his own criticism of this initial model has been largely ignored. The "waterfall model" quickly came to refer not to Royce's final, iterative design, but rather to his purely sequentially ordered model. This article will use this popular meaning of the phrase waterfall model. For an iterative model similar to Royce's final vision.Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of the "waterfall model" as a purely sequential process is still popular, and, for some, the phrase "waterfall model" has since come to refer to any approach to software creation which is seen as inflexible and non-iterative. Those who use the phrase "waterfall model" pejoratively for non-iterative models that they dislike usually see the waterfall model itself as naive and unsuitable for an "iterative" process.
The model
The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.
In Royce's original waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA validation)
6. Installation
7. Maintenance
To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes "requirements specification" — they set in stone the requirements of the software. When the requirements are fully completed, one proceeds to design. The software in question is designed and a "blueprint" is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated. After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs.
Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are discrete, and there is no jumping back and forth or overlap between them.
However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.
Agile
Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.
There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.
Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.
History
The modern definition of agile software development evolved in the mid 1990s as part of a reaction against "heavyweight" methods, as typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software engineers actually perform effective work. A case can be made that agile and iterative development methods are a return to development practice seen early in the history of software development. Initially, agile methods were called "lightweight methods." In 2001, prominent members of the community met at Snowbird, Utah, and adopted the name "agile methods." Later, some of these people formed The Agile Alliance, a non-profit organization that promotes agile development.
Comparison with other methods
Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive".Agile methods exist on the "adaptive" side of this continuum.
Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.
Agile methods have much in common with the "Rapid Application Development" techniques from the 1980's as espoused by James Martin and others.
There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.
Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.
History
The modern definition of agile software development evolved in the mid 1990s as part of a reaction against "heavyweight" methods, as typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software engineers actually perform effective work. A case can be made that agile and iterative development methods are a return to development practice seen early in the history of software development. Initially, agile methods were called "lightweight methods." In 2001, prominent members of the community met at Snowbird, Utah, and adopted the name "agile methods." Later, some of these people formed The Agile Alliance, a non-profit organization that promotes agile development.
Comparison with other methods
Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive".Agile methods exist on the "adaptive" side of this continuum.
Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.
Agile methods have much in common with the "Rapid Application Development" techniques from the 1980's as espoused by James Martin and others.
LEAN implementation
System engineering
Lean is about more than just cutting costs in the factory. One crucial insight is that most costs are assigned when a product is designed. Often an engineer will specify familiar, safe materials and processes rather than inexpensive, efficient ones. This reduces project risk, that is, the cost to the engineer, while increasing financial risks, and decreasing profits. Good organizations develop and review checklists to review product designs.
Companies must often look beyond the shop-floor to find opportunities for improving overall company cost and performance. At the system engineering level, requirements are reviewed with marketing and customer representatives to eliminate costly requirements. Shared modules may be developed, such as multipurpose power-supplies or shared mechanical components or fasteners. Requirements are assigned to the cheapest discipline. For example, adjustments may be moved into software, and measurements away from a mechanical solution to an electronic solution. Another approach is to choose connection or power-transport methods that are cheap or that used standardized components that become available in a competitive market.
Lean is about more than just cutting costs in the factory. One crucial insight is that most costs are assigned when a product is designed. Often an engineer will specify familiar, safe materials and processes rather than inexpensive, efficient ones. This reduces project risk, that is, the cost to the engineer, while increasing financial risks, and decreasing profits. Good organizations develop and review checklists to review product designs.
Companies must often look beyond the shop-floor to find opportunities for improving overall company cost and performance. At the system engineering level, requirements are reviewed with marketing and customer representatives to eliminate costly requirements. Shared modules may be developed, such as multipurpose power-supplies or shared mechanical components or fasteners. Requirements are assigned to the cheapest discipline. For example, adjustments may be moved into software, and measurements away from a mechanical solution to an electronic solution. Another approach is to choose connection or power-transport methods that are cheap or that used standardized components that become available in a competitive market.
LEAN
Lean manufacturing is the production of goods using less of everything compared to mass production: less human effort, less manufacturing space, less investment in tools, and less engineering time to develop a new product. Lean manufacturing is a generic process management philosophy derived mostly from the Toyota Production System (TPS) and also from other sources. It is renowned for its focus on reduction of the original Toyota 'seven wastes' in order to improve overall customer value but has some key new perspectives on how to do this. Lean is often linked with Six Sigma because of that methodology's emphasis on reduction of process variation (or its converse smoothness) and Toyota's combined usage (with the TPS). Toyota's steady growth from a small player to the most valuable and the biggest car company in the world has focused attention upon how it has achieved this, making "Lean" a hot topic in management science in the first decade of the 21st century."Lean" is viewed by many as the latest management fad in the cost-reduction arena. It has for many the advantage of a very descriptive active name and has been, in many cases, used like any other cost-reduction approach. This has meant that the "Lean" word can be found in many places, projects and proposals. This has meant that for many it has hit the same implementation other approaches which has created a level of cynicism in some quarters about its effectiveness. However, there are enough high-profile high-success implementations (headed by Toyota) that attitudes to it are quite mixed overall.
Overview
For many, Lean is the set of TPS 'tools' that assist in the identification and steady elimination of waste, the improvement of quality, and production time and cost reduction. The Japanese terms from Toyota are quite strongly represented in "Lean". To solve the problem of waste, Lean Manufacturing has several 'tools' at its disposal. These include continuous process improvement, the "5 Whys" and mistake-proofing. In this way it can be seen as taking a very similar approach to other improvement methodologies.
There is a second approach to Lean Manufacturing, which is promoted by Toyota, in which the focus is upon improving the 'flow' or smoothness of work (thereby steadily eliminating mura, unevenness) through the system and not upon 'waste reduction' per se. Techniques to improve flow include production leveling, "pull" production (by means of kanban) and the Heijunka box. This is a fundamentally different approach to most improvement methodologies which may partially account for its lack of popularity.
The difference between these two approaches is not the goal but the prime approach to achieving it. The implementation of smooth flow exposes quality problems which already existed and thus waste reduction naturally happens as a consequence. The advantage claimed for this approach is that it naturally takes a system-wide perspective whereas a 'waste' focus has this perspective, sometimes wrongly, assumed. Some Toyota staff have expressed some surprise at the 'tool' based approach as they see the tools as work-arounds made necessary where flow could not be fully implemented and not as aims in themselves.
Both Lean and TPS can be seen as a loosely connected set of potentially competing principles whose goal is cost reduction by the elimination of waste. These principles include: Pull processing, Perfect first-time quality, Waste minimization, Continuous improvement, Flexibility, Building and maintaining a long term relationship with suppliers, Autonomation, Load leveling and Production flow and Visual control. The disconnected nature of some of these principles perhaps springs from the fact that the TPS has grown pragmatically since 1948 as it responded to the problems it saw within its own production facilities. Thus what one sees today is the result of a 'need' driven learning to improve where each step has built on previous ideas and not something based upon a theoretical framework. Toyota's view is that the methodology is not the tools but the method of application of muda, mura, muri to expose problems systematically and to use the tools where the ideal cannot be achieved. Thus the 'tools' are, in their view, 'workarounds' adapted to different situations which explains any apparent incoherence of the 'principles' above.
The TPS has two pillar concepts: JIT (flow) and autonomation (smart automation).Adherents of the Toyota approach would say that the smooth 'flowing’ delivery of 'value' achieves all these improvements as a side-effect. If production 'flows' perfectly then there is no inventory, if customer valued features are the only ones produced then product design is simplified and effort is only expended on features the customer values. The other of the two TPS pillars is the very human aspect of 'autonomation' whereby automation is achieved with a human touch. This aims to give the machines enough 'intelligence' to recognize when they are working abnormally and flag this for human attention. Thus humans do not have to monitor normal production and only have to focus on abnormal, or fault, conditions. A reduction in human workload that is probably much desired by all involved since it removes much routine and repetitive activity that humans often do not enjoy and where they are therefore not at their most effective.
Lean implementation is therefore focused on getting the right things, to the right place, at the right time, in the right quantity to achieve perfect work flow while minimizing waste and being flexible and able to change. These concepts of flexibility and change are principally required to allow production leveling, using tools like SMED, but have their analogues in other processes such as R&D. The flexibility and ability to change are not open-ended and therefore often not expensive capability requirements. More importantly, all of these concepts have to be understood, appreciated, and embraced by the actual employees who build the products and therefore own the processes that deliver the value. The cultural and managerial aspects of Lean are just as, and possibly more, important than the actual tools or methodologies of production itself. There are many examples of Lean tool implementation without sustained benefit and these are often blamed on weak understanding of Lean in the organization.
Lean aims to make the work simple enough to understand, to do and to manage. To achieve these three at once there is a belief held by some that Toyota's mentoring process (loosely called Senpai and Kohai relationship), so strongly supported in Japan, is one of the best ways to foster Lean Thinking up and down the organizational structure. This is the process undertaken by Toyota as it helps its suppliers to improve their own production. The closest equivalent to Toyota's mentoring process is the concept of Lean Sensei, which encourages companies, organizations, and teams to seek out outside, third-party "Sensei" that can provide unbiased advice and coaching.
Overview
For many, Lean is the set of TPS 'tools' that assist in the identification and steady elimination of waste, the improvement of quality, and production time and cost reduction. The Japanese terms from Toyota are quite strongly represented in "Lean". To solve the problem of waste, Lean Manufacturing has several 'tools' at its disposal. These include continuous process improvement, the "5 Whys" and mistake-proofing. In this way it can be seen as taking a very similar approach to other improvement methodologies.
There is a second approach to Lean Manufacturing, which is promoted by Toyota, in which the focus is upon improving the 'flow' or smoothness of work (thereby steadily eliminating mura, unevenness) through the system and not upon 'waste reduction' per se. Techniques to improve flow include production leveling, "pull" production (by means of kanban) and the Heijunka box. This is a fundamentally different approach to most improvement methodologies which may partially account for its lack of popularity.
The difference between these two approaches is not the goal but the prime approach to achieving it. The implementation of smooth flow exposes quality problems which already existed and thus waste reduction naturally happens as a consequence. The advantage claimed for this approach is that it naturally takes a system-wide perspective whereas a 'waste' focus has this perspective, sometimes wrongly, assumed. Some Toyota staff have expressed some surprise at the 'tool' based approach as they see the tools as work-arounds made necessary where flow could not be fully implemented and not as aims in themselves.
Both Lean and TPS can be seen as a loosely connected set of potentially competing principles whose goal is cost reduction by the elimination of waste. These principles include: Pull processing, Perfect first-time quality, Waste minimization, Continuous improvement, Flexibility, Building and maintaining a long term relationship with suppliers, Autonomation, Load leveling and Production flow and Visual control. The disconnected nature of some of these principles perhaps springs from the fact that the TPS has grown pragmatically since 1948 as it responded to the problems it saw within its own production facilities. Thus what one sees today is the result of a 'need' driven learning to improve where each step has built on previous ideas and not something based upon a theoretical framework. Toyota's view is that the methodology is not the tools but the method of application of muda, mura, muri to expose problems systematically and to use the tools where the ideal cannot be achieved. Thus the 'tools' are, in their view, 'workarounds' adapted to different situations which explains any apparent incoherence of the 'principles' above.
The TPS has two pillar concepts: JIT (flow) and autonomation (smart automation).Adherents of the Toyota approach would say that the smooth 'flowing’ delivery of 'value' achieves all these improvements as a side-effect. If production 'flows' perfectly then there is no inventory, if customer valued features are the only ones produced then product design is simplified and effort is only expended on features the customer values. The other of the two TPS pillars is the very human aspect of 'autonomation' whereby automation is achieved with a human touch. This aims to give the machines enough 'intelligence' to recognize when they are working abnormally and flag this for human attention. Thus humans do not have to monitor normal production and only have to focus on abnormal, or fault, conditions. A reduction in human workload that is probably much desired by all involved since it removes much routine and repetitive activity that humans often do not enjoy and where they are therefore not at their most effective.
Lean implementation is therefore focused on getting the right things, to the right place, at the right time, in the right quantity to achieve perfect work flow while minimizing waste and being flexible and able to change. These concepts of flexibility and change are principally required to allow production leveling, using tools like SMED, but have their analogues in other processes such as R&D. The flexibility and ability to change are not open-ended and therefore often not expensive capability requirements. More importantly, all of these concepts have to be understood, appreciated, and embraced by the actual employees who build the products and therefore own the processes that deliver the value. The cultural and managerial aspects of Lean are just as, and possibly more, important than the actual tools or methodologies of production itself. There are many examples of Lean tool implementation without sustained benefit and these are often blamed on weak understanding of Lean in the organization.
Lean aims to make the work simple enough to understand, to do and to manage. To achieve these three at once there is a belief held by some that Toyota's mentoring process (loosely called Senpai and Kohai relationship), so strongly supported in Japan, is one of the best ways to foster Lean Thinking up and down the organizational structure. This is the process undertaken by Toyota as it helps its suppliers to improve their own production. The closest equivalent to Toyota's mentoring process is the concept of Lean Sensei, which encourages companies, organizations, and teams to seek out outside, third-party "Sensei" that can provide unbiased advice and coaching.
IT Governance
Information Technology Governance, IT Governance or ICT Governance, is a subset discipline of Corporate Governance focused on information technology (IT) systems and their performance and risk management. The rising interest in IT governance is partly due to compliance initiatives (e.g. Sarbanes-Oxley (USA) and Basel II (Europe)), as well as the acknowledgment that IT projects can easily get out of control and profoundly affect the performance of an organization.
Problems with IT governance
Nicholas Carr has emerged as a prominent critic of the idea that information technology confers strategic advantage. This line of criticism might imply that significant attention to IT governance is not a worthwhile pursuit for senior corporate leadership. However, Carr also indicates counterbalancing concern for effective IT risk management.
The manifestation of IT governance objectives through detailed process controls (e.g. in the context of project management) is a frequently controversial matter in large scale IT management. See Agile methods. The difficulties in achieving a balance between financial transparency and cost-effective data capture in IT financial management (i.e., to enable chargeback) is a continual topic of discussion in the professional literature, and can be seen as a practical limitation to IT governance.
Relationship to other IT disciplines
IT governance is supported by disciplines such as:
- Business Service Management
- Business Technology Optimization
- Enterprise architecture
- IT asset management
- IT portfolio management
- IT security assessment
- IT service management
- Project governance Project management and Program management in the enterprise IT context (including software engineering where appropriate)
Problems with IT governance
Nicholas Carr has emerged as a prominent critic of the idea that information technology confers strategic advantage. This line of criticism might imply that significant attention to IT governance is not a worthwhile pursuit for senior corporate leadership. However, Carr also indicates counterbalancing concern for effective IT risk management.
The manifestation of IT governance objectives through detailed process controls (e.g. in the context of project management) is a frequently controversial matter in large scale IT management. See Agile methods. The difficulties in achieving a balance between financial transparency and cost-effective data capture in IT financial management (i.e., to enable chargeback) is a continual topic of discussion in the professional literature, and can be seen as a practical limitation to IT governance.
Relationship to other IT disciplines
IT governance is supported by disciplines such as:
- Business Service Management
- Business Technology Optimization
- Enterprise architecture
- IT asset management
- IT portfolio management
- IT security assessment
- IT service management
- Project governance Project management and Program management in the enterprise IT context (including software engineering where appropriate)
SQA and SQC in CMMI Validation (VAL)
Validation confirms that the product, as provided, will fulfill its intended use. In other words, validation ensures that “you built the right thing.” As with Verification, Validation is mainly the domain of SQC. The term Acceptance Test could also apply to Validation, in most cases the Acceptance test is carried out by a different group of people from the SQC team that performed Verification, as the product was being built. In the case where an application is going to be used internally, then the end user or business representative would perform the Acceptance testing. Wherever this is done it is in essence a SQC activity. As with Verification, SQA makes sure that these processes conform to standards and documented procedures. The Validation process itself is subject to continuous improvement and measurement.
SQA and SQC in CMMI Verification (VER)
The purpose of Verification is to ensure that selected work products meet their specified requirements Theses activities are only carried out by SQC, the role of SQA would be to make sure that SQC had documented procedures, plans etc. by audit. SQA would also measure the effectiveness of the Verification processes by tracking defects that were missed by SQC during Verification. Note the term Verification, as opposed to Validation. In essence Verification answers the question ‘Are we building the product correctly’ while Validation answers the question ‘Are we building the correct product’. Validation demonstrates that the product satisfies its intended purpose when place in the correct environment while Verification refers to building to specification. The FURPS+ model identifies both Customer and Product requirements; Verification applies to both these types of requirements and can be applied to the intermediary work products. Design or Code reviews are examples of Verification. These terms Verification and Validation are often mixed, CMMI makes this comment about the distinction:- Although “verification” and “validation” at first seem quite similar in CMMI models, on closer inspection you can see that each addresses different issues. Verification confirms that work products properly reflect the requirements specified for them. In other words, verification ensures that “you built it right.” While SQC carries out all the Verification activities the Verification process itself is still subject to SQA and process improvement.
SQA & SQC in CMMI Technical solution (TS)
The purpose of Technical Solution is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related life-cycle processes either singly or in combinations as appropriate.
SQA role To observe that documented standards, processes, and procedures are followed. SQA would also establish metrics in order to measure the effectiveness of this process. Clearly testing the end product against the requirements (which is itself a SQC activity) will reveal any defects introduced during this process. The number of defects is a common measure for the Design\Build phase. This metric is usually further quantified by some form of scope, for example defects per 100 lines of code, or per function.
SQC role The major SQC role during this process will be testing.
The finished product does not have to be present before testing can begin. Unit and Component can both take place before the product is complete. Design and Code reviews are also something that SQC could get involved with.
SQA role To observe that documented standards, processes, and procedures are followed. SQA would also establish metrics in order to measure the effectiveness of this process. Clearly testing the end product against the requirements (which is itself a SQC activity) will reveal any defects introduced during this process. The number of defects is a common measure for the Design\Build phase. This metric is usually further quantified by some form of scope, for example defects per 100 lines of code, or per function.
SQC role The major SQC role during this process will be testing.
The finished product does not have to be present before testing can begin. Unit and Component can both take place before the product is complete. Design and Code reviews are also something that SQC could get involved with.
SQA & SQC in CMMI Requirements Management (REQM)
The purpose of REQM 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.
This process involves version control of the requirements and the relationship between the requirements and other work products. One tool used in Requirements Management is a Traceability Matrix.
The Traceability Matrix maps where in the Software a given requirement is implemented, it is a kind of cross reference table. The traceability matrix also maps which test case verify a given requirement.
SQA role To observe (audit) that documented standards, processes, and procedures are followed. SQA would also establish metrics in order to measure the effectiveness of this process. A common metric for measuring the Requirements Management would be the how many times the wrong Version was referenced. Another measure (for the Traceability Matrix) would be lack of test coverage, that is defects detected in the shipped product that were not tested due to the fact that they were not referenced in the Traceability matrix that referenced the requirements.
SQC role As with the actual Requirements Development, SQC would be involved in inspecting the actual deliverable’s (e.g. Traceability Matrix) from this process.
This process involves version control of the requirements and the relationship between the requirements and other work products. One tool used in Requirements Management is a Traceability Matrix.
The Traceability Matrix maps where in the Software a given requirement is implemented, it is a kind of cross reference table. The traceability matrix also maps which test case verify a given requirement.
SQA role To observe (audit) that documented standards, processes, and procedures are followed. SQA would also establish metrics in order to measure the effectiveness of this process. A common metric for measuring the Requirements Management would be the how many times the wrong Version was referenced. Another measure (for the Traceability Matrix) would be lack of test coverage, that is defects detected in the shipped product that were not tested due to the fact that they were not referenced in the Traceability matrix that referenced the requirements.
SQC role As with the actual Requirements Development, SQC would be involved in inspecting the actual deliverable’s (e.g. Traceability Matrix) from this process.
SQA & SQC in CMMI Requirement Development(RD)
The CMMI Requirements Development process area describes three types of requirements:- customer requirements, product requirements, and product-component requirements.
SQA role To observe that documented standards, processes, and procedures are followed. SQA would also establish software metrics in order to measure the effectiveness of this process. A common metric for measuring the Requirements process would be the number of errors (found during system testing) that could be traced to inaccurate or ambiguous requirements (note: SQC would perform the actual system testing but SQA would collect the metrics for monitoring and continuous improvement).
SQC role SQC takes an active role with Verification (this is a process itself that is described later). Verification of the requirements would involve inspection (reading) and looking for clarity and completeness. SQC would also verify that any documentated requirement standards are followed. Note there is a subtle difference between SQA and SQC with regard to standards, SQC’s role is in verifying the output of this process (that is the Requirement document itself) while SQA’s role is to make sure the process is followed correctly. SQA is more of an audit role here, and may sample actual Requirements whereas SQC is involved in the Verification of all Requirements. The type of requirement need not be just the functional aspect (or customer\user facing requirements) they could also include product and\or component requirements.
SQA role To observe that documented standards, processes, and procedures are followed. SQA would also establish software metrics in order to measure the effectiveness of this process. A common metric for measuring the Requirements process would be the number of errors (found during system testing) that could be traced to inaccurate or ambiguous requirements (note: SQC would perform the actual system testing but SQA would collect the metrics for monitoring and continuous improvement).
SQC role SQC takes an active role with Verification (this is a process itself that is described later). Verification of the requirements would involve inspection (reading) and looking for clarity and completeness. SQC would also verify that any documentated requirement standards are followed. Note there is a subtle difference between SQA and SQC with regard to standards, SQC’s role is in verifying the output of this process (that is the Requirement document itself) while SQA’s role is to make sure the process is followed correctly. SQA is more of an audit role here, and may sample actual Requirements whereas SQC is involved in the Verification of all Requirements. The type of requirement need not be just the functional aspect (or customer\user facing requirements) they could also include product and\or component requirements.
SQA, SQC and CMMI Definitions
Software Quality Assurance
The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.
Software Quality Control
The function of software quality that checks that the project follows its standards, processes, and procedures, and that the project produces the required internal and external (deliverable) products.
CMMI
A process improvement approach to software development. CMMi identifies a core set of Software Engineering process areas as:-
- Requirements Development
- Requirements Management
- Technical Solution
- Product Integration
- Verification
- Validation
CMMI also covers other process areas, such as Process Management, Project Management and Support but only the core Software Engineering development processes are used here by way of example.
It is also interesting to note that SQA and SQC are processes defined within CMMI, they are under the Support process area. In CMMI SQA\SQC is defined as Process and Product Quality Assurance.
CMMI is an approach to process improvement, in which SQA\SQC play a major but not exclusive role.Everyone in a software development organization takes part in both the CMMI processes and any improvement initiatives for those processes. Each of the main Engineering process areas is now described together with the role that SQA\SQC plays within those areas.
The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.
Software Quality Control
The function of software quality that checks that the project follows its standards, processes, and procedures, and that the project produces the required internal and external (deliverable) products.
CMMI
A process improvement approach to software development. CMMi identifies a core set of Software Engineering process areas as:-
- Requirements Development
- Requirements Management
- Technical Solution
- Product Integration
- Verification
- Validation
CMMI also covers other process areas, such as Process Management, Project Management and Support but only the core Software Engineering development processes are used here by way of example.
It is also interesting to note that SQA and SQC are processes defined within CMMI, they are under the Support process area. In CMMI SQA\SQC is defined as Process and Product Quality Assurance.
CMMI is an approach to process improvement, in which SQA\SQC play a major but not exclusive role.Everyone in a software development organization takes part in both the CMMI processes and any improvement initiatives for those processes. Each of the main Engineering process areas is now described together with the role that SQA\SQC plays within those areas.
SCAMPI
The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the official SEI method to provide benchmark-quality ratings relative to CMMI models. SCAMPI appraisals are used to identify strengths and weaknesses of current processes, reveal development/acquisition risks, and determine capability and maturity level ratings. They are mostly used either as part of a process improvement program or for rating prospective suppliers. The method defines the appraisal process as consisting of preparation; on-site activities; preliminary observations, findings, and ratings; final reporting; and follow-on activities.
Class A, B, and C Appraisals
The suite of documents associated with a particular version of the CMMI includes a requirements specification called the Appraisal Requirements for CMMI (ARC), which specifies three levels of formality for appraisals: Class A, B, and C. Formal (Class A) SCAMPIs are conducted by SEI-authorized Lead Appraisers who use the SCAMPI A Method Definition Document (MDD) to conduct the appraisals. Class A, the most formal, is required to achieve a rating (Level 1 (lowest) to Level 5 (highest)) for public record or for response to U.S. Department of Defense requirements.
Class A, B, and C Appraisals
The suite of documents associated with a particular version of the CMMI includes a requirements specification called the Appraisal Requirements for CMMI (ARC), which specifies three levels of formality for appraisals: Class A, B, and C. Formal (Class A) SCAMPIs are conducted by SEI-authorized Lead Appraisers who use the SCAMPI A Method Definition Document (MDD) to conduct the appraisals. Class A, the most formal, is required to achieve a rating (Level 1 (lowest) to Level 5 (highest)) for public record or for response to U.S. Department of Defense requirements.
CMMI Benefits
The CMMI Product Suite is at the forefront of process improvement because it provides the latest best practices for product and service development and maintenance. The CMMI models improve the best practices of previous models in many important ways. CMMI best practices enable organizations to do the following:
· more explicitly link management and engineering activities to their business objectives
· expand the scope of and visibility into the product lifecycle and engineering activities to ensure that the product or service meets customer expectations
· incorporate lessons learned from additional areas of best practice (e.g., measurement, risk management, and supplier management)
· implement more robust high-maturity practices
· address additional organizational functions critical to their products and services
· more explicitly link management and engineering activities to their business objectives
· expand the scope of and visibility into the product lifecycle and engineering activities to ensure that the product or service meets customer expectations
· incorporate lessons learned from additional areas of best practice (e.g., measurement, risk management, and supplier management)
· implement more robust high-maturity practices
· address additional organizational functions critical to their products and services
Benefits of Process Improvement
The following are some of the benefits and business reasons for implementing process improvement:
· The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it.
· Process improvement increases product and service quality as organizations apply it to achieve their business objectives.
· Process improvement objectives are aligned with business objectives.
· The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it.
· Process improvement increases product and service quality as organizations apply it to achieve their business objectives.
· Process improvement objectives are aligned with business objectives.
What is CMMI?
Capability Maturity Model® Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.
Subscribe to:
Posts (Atom)