About Software Quality Assurance .org
It is targeted at the SQA professional that wants to leverage the benefits of CMMi within a medium sized team (25 to 100 developers)
The CMMi easy button
The idea behind the CMMi easy button is to provide a learning perspective to the SEI's CMMi vast documentation set for software development (CMMi-DEV). The intention is not to dumb down or over simplify the SEI material but rather to lead an individual through the concepts and value of the CMMi framework in order to enable its timely utilization.
The main reason that the CMMi documentation is considered complicated, by most people that first encounter it, is that the CMMi model contains a number of difficult interrelated concepts. Firstly the CMMi model is a software process improvement (SPI) framework that is targeted at a variable (i.e. project based) software deliverable. The lack of tangibility (not a physical product) of software compounds the complexity of many of the already difficult CMMi SPI concepts such as cause and effect analysis. Secondly the CMMi documentation set includes other complicated concepts related to SPI such as risk analysis, decision making and quality control that when positioned against the essential difficulties of software become a perfect storm in terms understanding the big picture.
What the CMMi easy button does is to breakdown CMMi for software development and isolate the essential difficulties of dealing with the software medium in order to provide a step by step guide to understanding and implementing the basic CMMi concepts.
Anyone that is completely new to CMMi would do well to read a basic overview such as the Software Quality Network's (SQA.net) CMMi introduction.
The basic approach of the CMMi easy button learning perspective is to:
Standalone CMMi concepts, and process areas.
CMMi maturity levels:
The concept of maturity levels is generally applicable to any process improvement initiative and can be isolated in terms of understanding. The software quality network's (sqa.net) CMMi introduction contains a good introduction to this subject.
CMMi assessments (appraisals):
The concept of CMMi (SCAMPI) appraisals is generally applicable to any assessment of processes maturity (including physical products) and can also be isolated in terms of understanding. The software quality network's (sqa.net) article on SCAMPI provides a good introduction to the CMMi appraisal methodology.
Standalone process areas, that are loosely coupled to project or software production.
The following process areas are independent or loosely coupled to other process areas (apart from the general SPI process area relationships for continuous improvement, discussed later).
Configuration Management (CM)
This process area is concerned with keeping track of related components (and work products) that come together to produce a complete product. Although there are special considerations for software the concept of Configuration Management is equally applied to a manufactured product in that the drawings (design) are subjected to revision control to keep in step with the production procedures.
In software the work products that are typically subjected to CM are Requirements, Design, Test Plans and Source code as each version of these will form a unique Configuration and the dependencies between these work products need to be subjected to version control so that as one changes (for example Design) the other interrelated work products are changed and referenced in unison.
Decision Analysis and Resolution (DAR)
This process area establishes a formal evaluation process for choosing between alternative solutions. Whilst there is a tie in to project and risk management the concepts of this process area can be seen as standalone for the purposes of understanding CMMi-DEV.
Organizational Training (OT)
Although the other organizational process areas tie in to process improvement, in a way that is not immediately obvious (and those process areas are described in the process improvement section the CMMi easy button) the organizational Training process area is self explanatory. This process area is concerned with developing skills and knowledge so that people are better able to perform their required roles.
Risk Management (RSKM)
There are aspects of Risk management that are complicated by the essential difficulties of software but the general theory and practice of Risk Management is universal in that a strategy is devised for identifying, analyzing and mitigating risks. This process area ties in to the project related process areas as each project will have unique risks associated, but that said (for the purposes of understanding) this process area can been isolated.
Supplier Agreement Management (SAM)
This is another process area that can be isolated in terms of understanding the big picture. The Suppler Agreement management process area is concerned with supplier management, which includes supplier selection, maintaining agreements, monitoring and evaluating supplier performance.
Project related CMMi-DEV process areas.
The following process areas relate to the concept of project, which in turn relates to customized production. The alternative to project driven production is a single process of production, for example a car production plant where one car is manufactured. In CMMi-DEV the concept of project is central to the planning and control of software production.
Organizational Process Definition (OPD)
Although this process area has a wider impact than projects it is essential to the project process areas, so a brief description of the OPD is appropriate.
The Organizational Process Definition process area is concerned with establishing and maintaining a process Asset library (PAL) which contains standards, procedure definitions, life cycle models (SDLC), best practices etc.
This process area is the logical starting place in terms of what would be a step by step guide to implementing CMMi-DEV. Every description of every significant process, procedure and work product is documented in the PAL as a central reference point.
Integrated Project Management (IPM)
The IPM process area is concerned with managing the project in the broadest context. This broad management begins with selecting, from the previously described Process Asset Library (PAL) the processes, including the SDLC and Project Planning processes that will be followed during this project. The IPM also defines the work environment for the project and communication channels with the stakeholders. This process area, IPM, can be seen as a basic context in which the project is executed and this includes defining the project's processes and activities (selected form the PAL), which include the Project Planning and Project Monitoring processes described next.
The assumption with IPM is that not all projects follow the same processes (which include Project Planning) and IPM takes care of the type of Project required and the broader communication channels with stakeholders.
Project Planning (PP)
The Project Planning process area is more concerned with what is generally thought to be traditional project management. The project planning activities include resource scheduling based on the requirements of the project and production of a project plan that lays out traditional timelines and work breakdown structures. Estimates for cost and developing a project budget are also a part of the Project Planning process area.
Project Monitoring and Control (PMC)
Given the project plan, produced from the activities contained in the Project Planning (PP) process area, the PMC process area concerns itself with continuous monitoring of the actual results compared with the plan. As well as monitoring the PMC process area is also concerned with analyzing issues and taking corrective action, when the project's actual deliverables deviate from the plan.
Measurement and Analysis (MA)
This process area is placed in the Project related process areas section (within the CMMi easy button learning path) as it is a prerequisite for the PMC activities. The relevance to PMC is that the criteria for monitoring the project, in terms of attributes and measurements, are defined in terms of what is to be measured and how this is to be done. The typical project measurements taken include effort (man hours), size of work products (i.e. number of pages, lines of code etc.), defect density and other quality measures. This information is first documented, as estimates, in the Project Plan, and then monitored in the PMC process area activities. The MA process area activities are also relevant to continuous improvement strategies and processes, discussed later in this CMMi easy button document.
Software production (SDLC) related process areas.
The following process areas relate directly to the production of software.
Requirements Development (RD)
This process area is the beginning of the software delivery process. This process area concerns needs elicitation and analysis as well as a statement of the requirements that would satisfy those needs. There are two types of requirement addressed in the RD process area, namely customer and product requirements. The customer requirements are typically stated in non-technical terms whilst the product requirements are a statement of the customer requirements in technical terms. Both the customer and product requirements address the "what is required", not "how it is implemented" in terms of the solution. The Technical Solution process areas, described below, breaks down the requirements into the technical and program specifications.
Requirements Management (REQM)
The REQM process area concerns the management and control of changes to the requirements as well as the maintenance of a bi-directional traceability matrix. The traceability matrix cross references the test cases and design sections back to the requirements so that a comprehensive check list, in terms of requirements coverage and rational for the design, can be established. The traceability matrix is discussed further in the REQM process area description. There is a strong relationship with the Configuration Management (CM) process area for the REQM activities that concern controlling and recording changes to the requirements.
Technical Solution (TS)
Many people first reading CMMi for software development will be looking for the design and programming (coding) process areas. The Technical Solution process area is the area that is concerned with design and coding. This process area also includes the documentation for supporting the delivered software. This process area takes in the product requirements (from the Requirements Development process area activities) and produces the design, detailed design and code needed to satisfy those requirements. Make or buy decisions are also addressed within the activities of this process area. In this process area the term "implement the design" refers to software being coded when programming is involved.
Product Integration (PI)
This process area is concerned with packaging and delivery (to production) of the software. Some people refer to the delivery activities as "implementation" but in CMMi the term implementation refers to coding or providing a solution that satisfies the design. The Product Integration process area also includes interface, system and acceptance testing (unit testing is performed during the Technical Solution process area activities). Although there are two areas that also concern testing, namely Verification and Validation, and these are discussed later in the CMMi easy button document. Product Integration is the last stage of the typical SDLC process areas, for software delivery.
The question of support and maintenance.
There are no separate support or maintenance process areas in CMMi for software development. The support and maintenance activities are considered to come under the above software production processes. For example a change request would come thru activities described in the Requirements Management (change) and Requirements Development process areas. Whilst a defect would be part of the Technical Solution process area activities. To differentiate the processes (SDLC) a separate Project type (for maintenance activities) would be established. The maintenance type of projects would have their own SDLC, selected for the Process Asset Library. In this way maintenance type of Projects (which would be continuous) would be established so that the maintenance activities can be covered within the above process areas.
Quality assurance and quality control process areas.
The following process areas relate the quality management, which includes audits and inspections to determine if the software is being produced correctly and will fulfill its purpose (specification) when produced.
Quantitative Project Management (QPM)
This is an interesting process area as it sets up a mini quality control framework specifically tailored to the project. Recall that the IPM process area activities, described above, lay out a custom process (SDLC) for each project. These processes are selected from a Process Asset Library (PAL). Just as each project follows an "appropriate" process or SDLC. Each project needs its own performance and monitoring process and setting up those activities is the concern of the QPM process area.
Process and Product Quality Assurance (PPQA)
The PPQA process area activities are traditional QA activities. The PPQA process area is concerned with making sure that the correct standards and processes are being followed. This audit style of activity applies to work products as well as processes. This process area differs from quality control process areas (such as Verification, described later) in that Verification ensures that the specified requirements are satisfied. In simple terms the PPQA activities would ensure that the requirements followed a given standard whist Verification activities (QC) would look at issues such as ambiguity, accuracy and completeness.
Validation and Verification are concerned with quality control (including testing). Both Validation and Verification use dynamic (traditional software testing) and static (inspections, audits etc.) testing methods. Where Validation differs for Verification is in the purpose of the testing, in that Validation looks at the ability of the software product to fulfill its goal, where as Verification addresses correctness, in terms of specification and standards. The phrases Validation answers the question "Are we building the correct product?" and Verification answers the question "Are we building the product correctly?" are often cited to differentiate these two quality control process areas.
As discussed in the Validation overview, Verification is concerned with making sure each work product meets its specification. The activities in this process area do not just apply to testing the final product (or components) but also apply to the requirements and other specifications. By way of example the software specification can be verified against the requirements in terms of answering the question "Does this specification satisfy these requirements?" In the previous question a walkthrough would take place and the attendees would look at the requirements and trace them to the section in the specification to make sure that each requirement was covered. Another, more traditional, Verification activity would be to test the software against the software specification to make sure the software met the specification (although strictly speaking testing can only reveal defects and not true correctness as such). Verification does not only apply to functionality but also to performance, security, supportability and the other so called non-functional requirements, all of which can be specified and verified.
Continuous improvement related process areas.
The CMMi-DEV is essentially a process improvement framework and the following process areas are directly related to process improvement.
Organizational Process Focus (OPF)
The whole point of this process area is to plan, implement and deploy process improvements. This process area is truly a process management process area and the 'organizational' label is often confusing when first encountered. The main concept of the OPF is that the process improvement has an organizational context, in that the objectives of the organization become the focus for process improvement. What this means is that within the organizational scope, the processes are analyzed and candidate processes are selected for improvement. These candidate process improvements are prioritized and implemented thru a plan which includes pilots and verification that an improvement has taken place. The OPF is really at the heart of the process improvement framework.
Organizational Process Performance (OPP)
This process area seeks to establish measurements that can be used to gauge the performance of a given process. By way of example effort, defect removal effectiveness, requirement changes etc. can be used to quantify a given process. This process area looks similar to the Quantitative Project management (QPM) process are previously described. However the QPM process area makes use of the process performance baselines that are established in the OPP process area. In this way QPM uses the models set up in OPP, whilst OPP gathers data from all projects to establish (and revaluate) the process benchmarks (baselines) themselves.
Organizational Innovation and Deployment (OID)
This process area is concerned with break thru or 'innovative' improvement. Within the activities of this process area ideas, for process improvement, are collected from a variety of sources (i.e. customer, user, internal staff and suppliers). These ideas are then analyzed and if deemed feasible put into a pilot for evaluation. The kind of innovative improvement suggestions would include new technology, new management techniques or interface standards. The main conceptual difference between the OID and the OPF process areas is that the OID is concerned with bringing a change based on a solution being proposed whereas the OPF looks at problems within the processes and then looks for a solution. The OID process area activities are proactively looking for ways to utilize new techniques, tools and methods based on gathering ideas from anyone connected to the processes.
Causal Analysis and Resolution (CAR)
In order to establish a continuous process improvement framework an organization has to put in place defined and repeatable processes and then subject them to measurement and improvement. This concept (process improvement) can be universally applied to the manufacture of any product (or service delivery) but one of the main issues with applying continuous improvement to software is the identification of the root cause of any given defect. The CAR process areas are concerned with tracing any defect back to its root cause and then eliminating that cause (by way of process improvement). In software the root cause could go back to the design documentation or the original requirements documentation or anyone of the process steps between requirements and the final application. It is essential, to process improvement, to be able to establish the real (root cause) process problem that created a defect.
As can be seen the process areas of CMMi-DEV are interrelated and in order to get the complete picture all the interlocking parts need to be understood. That said there is a divide and conquer approach to understanding the process areas that, hopefully, can make the learning curve less steep.
Software-Quality-Assurance.org is an independent Web Site that presents information about CMMi and Software Quality Assurance.
No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-