Capability Maturity Model Integration (CMMI)

Capability Maturity Model Integration (CMMI) is a successor of CMM and is a more evolved model that incorporates
best components of individual disciplines of CMM like Software CMM, Systems Engineering CMM, People CMM, etc.
Since CMM is a reference model of matured practices in a specific discipline, so it becomes difficult to integrate these
disciplines as per the requirements. This is why CMMI is used as it allows the integration of multiple disciplines as and
when needed.
Objectives of CMMI :
1. Fulfilling customer needs and expectations.
2. Value creation for investors/stockholders.
3. Market growth is increased.
4. Improved quality of products and services.
5. Enhanced reputation in Industry.
CMMI Representation – Staged and Continuous :
A representation allows an organization to pursue a different set of improvement objectives. There are two
representations for CMMI :
 Staged Representation :
 uses a pre-defined set of process areas to define improvement path.
 provides a sequence of improvements, where each part in the sequence serves as a foundation for the
next.
 an improved path is defined by maturity level.
 maturity level describes the maturity of processes in organization.
 Staged CMMI representation allows comparison between different organizations for multiple maturity
levels.
 Continuous Representation :
 allows selection of specific process areas.
 uses capability levels that measures improvement of an individual process area.
 Continuous CMMI representation allows comparison between different organizations on a process-area-
by-process-area basis.
 allows organizations to select processes which require more improvement.
 In this representation, order of improvement of various processes can be selected which allows the
organizations to meet their objectives and eliminate risks.
CMMI Model – Maturity Levels :
In CMMI with staged representation, there are five maturity levels described as follows :
1. Maturity level 1 : Initial
 processes are poorly managed or controlled.
 unpredictable outcomes of processes involved.
 ad hoc and chaotic approach used.
 No KPAs (Key Process Areas) defined.
 Lowest quality and highest risk.
2. Maturity level 2 : Managed
 requirements are managed.
 processes are planned and controlled.
 projects are managed and implemented according to their documented plans.
 This risk involved is lower than Initial level, but still exists.
 Quality is better than Initial level.
3. Maturity level 3 : Defined
 processes are well characterized and described using standards, proper procedures, and methods, tools, etc.
 Medium quality and medium risk involved.
 Focus is process standardization.
4. Maturity level 4 : Quantitatively managed
 quantitative objectives for process performance and quality are set.
 quantitative objectives are based on customer requirements, organization needs, etc.
 process performance measures are analyzed quantitatively.
 higher quality of processes is achieved.
 lower risk
5. Maturity level 5 : Optimizing
  continuous improvement in processes and their performance.
 improvement has to be both incremental and innovative.
 highest quality of processes.
 lowest risk in processes and their performance.
CMMI Model – Capability Levels
A capability level includes relevant specific and generic practices for a specific process area that can improve the
organization’s processes associated with that process area. For CMMI models with continuous representation, there are
six capability levels as described below :
1. Capability level 0 : Incomplete
 incomplete process – partially or not performed.
 one or more specific goals of process area are not met.
 No generic goals are specified for this level.
 this capability level is same as maturity level 1.
2. Capability level 1 : Performed
 process performance may not be stable.
 objectives of quality, cost and schedule may not be met.
 a capability level 1 process is expected to perform all specific and generic practices for this level.
 only a start-step for process improvement.
3. Capability level 2 : Managed
 process is planned, monitored and controlled.
 managing the process by ensuring that objectives are achieved.
 objectives are both model and other including cost, quality, schedule.
 actively managing processing with the help of metrics.
4. Capability level 3 : Defined
 a defined process is managed and meets the organization’s set of guidelines and standards.
 focus is process standardization.
5. Capability level 4 : Quantitatively Managed
 process is controlled using statistical and quantitative techniques.
 process performance and quality is understood in statistical terms and metrics.
 quantitative objectives for process quality and performance are established.
6. Capability level 5 : Optimizing
 focuses on continually improving process performance.
 performance is improved in both ways – incremental and innovation.
 emphasizes on studying the performance results across the organization to ensure that common causes or issues
are identified and fixed.

Requirement Engineering
Requirements engineering (RE) refers to the process of defining, documenting, and maintaining requirements in the engineering
design process. Requirement engineering provides the appropriate mechanism to understand what the customer desires, analyzing
the need, and assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system. Thus, requirement engineering is the disciplined
application of proven principles, methods, tools, and notation to describe a proposed system's intended behavior and its associated
constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
 4. Software Requirement Validation
5. Software Requirement Management

1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing the software that is acceptable to users, flexible to
change and conformable to established standards.

Types of Feasibility:Forward Skip 10s

1. Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to accomplish customer
requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the required software performs a series of
levels to solve business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial profits for an
organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified with the help of customers and existing
systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify inconsistencies, defects,
omission, etc. We describe requirements in terms of relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.
3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software analyst after the requirements collected
from the various sources - the requirement received by the customer written in ordinary language. It is the job of the analyst to write
the requirement in technical language so that they can be understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams (FDDs), data
dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows the flow of
data through a system. The system may be a company, an organization, a set of procedures, a computer hardware system,
a software system, or any combination of the preceding. The DFD is also known as a data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items defined in DFDs. At
the requirements stage, the data dictionary should at least define customer data items, to ensure that the customer and
developers use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the entity-relationship diagram, often called
an "E-R diagram." It is a detailed logical representation of the data for the organization and uses three main constructs
i.e. data entities, relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are validated. The user might demand
illegal, impossible solution or experts may misinterpret the needs. Requirements can be the check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.
 o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the requirements engineering process and
system development.

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be categorized into two categories:

1. Functional Requirements: Functional requirements define a function that a system or system element must be qualified
to perform and must be documented in different forms. The functional requirements are describing the behavior of the
system as it correlates to the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify the criteria that can be used to decide the
operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run time.
o Evolution qualities like testability, maintainability, extensibility, and scalability that embodied in the static
structure of the software system.