Group 7

SOFTWARE PROCESS & QUALITY MANAGEMENT
GROUP PROJECT
Process Improvement - CMMI
The final version

Date: 12/12/2023
Instructor: Huy, Truong Dinh

Document Create by: Doanh, Le Quang
Team members :
 Doanh, Le Quang
 Khanh, Pham Phu
 Minh, Le Cong
 Phung, Dao Nguyen Trieu
1 SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project
PROJECT INFORMATION
Project Title
Start Date 12/09/2023 End Date: 12/12/2023
Lead Institution International School, Duy Tan University

Huy, Truong Dinh Msc
Instructor Email: huy.truongdinh@gmail.com
Phone: 0982.132.352
Doanh, Le Quang lequangdoanh888@gmail.com 038.787.0788
Team Members Khanh, Pham Phu khanhdanang12345@gmail.com 0898.507.615
Minh, Le Cong lecongminh0804@gmail.com 0796.026.120
Phung, Dao Nguyen Trieu trieuphung.2006@gmail.com 0934.845.549

CONTENTS
I. Introduction.................................................................................................................6
1.1. What Is Software Development Process ?................................................................6
1.2. What Is Software Process Improvement ?................................................................6
1.3. Software quality management...................................................................................7
1.4. Benefits of quality improvement...............................................................................7
1.5. Purpose......................................................................................................................8
1.6. Process Improvement – CMMI.................................................................................8
1.7. Difference between CMM and CMMI....................................................................11
II. CMMI Process...........................................................................................................12
2.1 What is CMMI?.......................................................................................................12
2.2 CMMI process guidance..........................................................................................12
2.2.1 Understand CMMI process template artifacts..................................................12
2.2.2 Plan and track work with CMMI......................................................................13
2.2.3 List work items with queries.............................................................................15
2.2.3.1 Add work item queries to a process template...................................................15
2.2.3.2 Create a work item query (.wiq) file.................................................................16
2.2.3.3 Specify queries to upload..................................................................................16
2.2.3.4 QUERY elements.............................................................................................16
2.2.4 Quick tips on shared queries.............................................................................17
2.2.5 Monitor progress...............................................................................................18
2.2.5.1 About dashboards, charts, reports and widgets.................................................18
2.2.5.2 Supported capabilities, permissions, and access...............................................18
2.2.5.3 Web portal data views and reports....................................................................18
2.2.5.4 Power BI reports...............................................................................................19
2.2.5.5 Supported features and access level..................................................................19
2.2.5.6 Default permissions..........................................................................................19
2.2.5.7 Configurable dashboards..................................................................................20
2.2.5.8 Charts: Work tracking status and trends...........................................................21
2.2.5.9 Charts: Manual testing progress, results, and trends........................................23
2.2.5.10 Widgets.............................................................................................................23
2.2.5.11 Sprint chart widgets..........................................................................................24
2.2.5.12 Sprint scope change..........................................................................................24
2.2.5.13 Sample Cumulative Flow Diagram widget.......................................................24
2.2.5.14 Monitor code activity, build progress and deployment status..........................25
2.2.5.15 Code, build, and release chart widgets.............................................................25
2.2.5.16 Analytics widgets and reports...........................................................................25

2.2.5.17 In-context reports: Work tracking.....................................................................25

2.2.5.18 Cumulative Flow Diagram................................................................................26
2.2.5.19 Velocity.............................................................................................................26
2.2.5.21 Sprint Burndown Trend....................................................................................27
2.2.5.22 In-context reports: Pipelines and Test..............................................................28
2.2.5.23 Pipeline pass rate report....................................................................................29
2.2.5.24 Test failures report............................................................................................29
2.2.5.25 Pipeline duration report....................................................................................30
2.2.5.26 Add custom work tracking fields......................................................................31
2.2.5.27 Marketplace widgets and extensibility.............................................................31
2.2.6 Create light-weight charts.................................................................................31
2.2.6.1 Analytics widgets and Power BI reports...........................................................31
2.2.6.2 Related notes.....................................................................................................31
2.2.7 CMMI process versions....................................................................................31
III CMMI Model.............................................................................................................32
3.1 Background to Capability Maturity Model Integration (CMMI)............................32
3.1.1 Why use a model?.............................................................................................32
3.1.2 What is the purpose of the CMMI model?.......................................................32
3.1.3 What's the best way to use the CMMI model?.................................................33
3.2 Evolution of CMMI.................................................................................................35
3.3 CMMI Maturity Level.............................................................................................37
3.3.1 Maturity Level 1 – Initial..................................................................................38
3.3.2 Maturity Level 2 – Managed............................................................................38
3.3.3 Maturity Level 3 – Define................................................................................39
3.3.4 Maturity Level 4 – Quantitatively managed.....................................................39
3.3.5 Maturity Level 5 – Quantitatively managed.....................................................40
3.4 CMMI Capability levels..........................................................................................41
3.4.1 Capability level 1 : Incomplete.........................................................................41
3.4.2 Capability level 2 : Managed............................................................................41
3.4.3 Capability level 3 : Defined..............................................................................41
3.4.4 Capability level 4 : Quantitatively Managed....................................................41
3.4.5 Capability level 5 : Optimizing.........................................................................41
3.5 Updated CMMI V2.0...............................................................................................42
3.6 CMMI certifications................................................................................................44
3.7 Process Improvement Steps.....................................................................................44
3.8 CMMI Appraisals....................................................................................................45
3.8.1 SCAMPI Class A Appraisal.............................................................................46

3.8.2 SCAMPI Class B Appraisal..............................................................................46

3.8.3 SCAMPI Class C Appraisal..............................................................................47
3.8.4 Appraisal Class Characteristics........................................................................47
3.9 CMMI Players - Roles Responsibilities..................................................................48
IV References..................................................................................................................49

TABLE OF FIGURES
Figure 1: CMMI – Software Development Cycle...............................................................6

Figure 2: CMMI – Continuous Representation...................................................................9
Figure 3: Staged Representation........................................................................................10
Figure 4: CMMI work items..............................................................................................12
Figure 5: CMMI Change Request Work Item...................................................................14
Figure 6: CMMI Issue Work Item.....................................................................................15
Figure 7: Configurable dashboards....................................................................................21
Figure 8:Sample Agile tool light-weight...........................................................................22
Figure 9: Sample light-weight test chart............................................................................23
Figure 10: Sample Lead time widget.................................................................................25
Figure 11: Cumulative Flow Diagram...............................................................................26
Figure 12: Velocity Diagram.............................................................................................27
Figure 13: Sprint Burndown Diagram...............................................................................28
Figure 14: Analytics Reports.............................................................................................28
Figure 15: Picture of Pipeline pass rate.............................................................................29
Figure 16: Test failures report...........................................................................................30
Figure 17: Pipeline duration report....................................................................................30
Figure 18: Orrganizational Maturity Leve.........................................................................34
Figure 19: Practice Capability Levels................................................................................35
Figure 20: The History of CMMS.....................................................................................36
Figure 21: Capability Maturity Model Int.........................................................................38
Figure 22: Capability maturity model int..........................................................................42
Figure 23: CMMI V2.0......................................................................................................44
Figure 24: Appraisal Class Characteristi...........................................................................48

I. Introduction
1.1. What is Software Development Process?
Software development is the process programmers use to build computer programs. The process, also
known as the Software Development Life Cycle (SDLC), includes several phases that provide a method for
building products that meet technical specifications and user requirements.
The SDLC provides an international standard that software companies can use to build and improve
their computer programs. It offers a defined structure for development teams to follow in the design,
creation and maintenance of high-quality software. The aim of the IT software development process is to
build effective products within a defined budget and timeline.
Figure 1. CMMI – Software Development Cycle
1.2. What is Software Process Improvement?

Process improvement is a methodology within project management, specifically in manufacturing,
that helps you take in and evaluate feedback about your processes to ensure continual improvement. Its aim
is to always be improving the efficiency and effectiveness of your business strategy, customer or
manufacturing processes. Some project management software provides tools to help identify potential issues
so you can rectify them.

1.3. Software quality management

Software quality management (SQM) is a management process that aims to develop and manage
the quality of software in such a way so as to best ensure that the product meets the quality standards
expected by the customer while also meeting any necessary regulatory and developer requirements, if
any. Software quality managers require software to be tested before it is released to the market, and they do
this using a cyclical process-based quality assessment in order to reveal and fix bugs before release. Their
job is not only to ensure their software is in good shape for the consumer but also to encourage a culture of
quality throughout the enterprise.
1.4. Benefits of quality improvement
When done correctly, software quality management (SQM) benefits organizations significantly. By
improving the quality of software products and services, SQM can help organizations to improve customer
satisfaction, reduce costs, and increase revenue.
Some of the specific benefits of software quality management include:
 Improved software quality: SQM is designed to improve the quality of software products and
services. This improved quality can increase customer satisfaction and loyalty and reduce
support and warranty costs.
 Reduced development costs: SQM can help reduce software development costs by identifying
and addressing quality issues early in the development process. This can lead to fewer reworks
and re-tests and shorter development cycles.
 Improved software development process: SQM can help to improve the software development
process by providing insight into areas where quality improvements can be made. This can
lead to more efficient and effective development processes and improved software quality.
 Increased revenue: By increasing the quality of software products and services, SQM can help
to increase revenue through increased sales and fewer returns.
 Implementing software quality management can be challenging, but the benefits are clear.
Organizations that implement SQM effectively can improve the quality of their software
products and services and their bottom line.

1.5. Purpose
A primary goal of CMMI is the creation of “reliable environments where products, services and
departments are proactive, efficient and productive.”
More specifically, CMMI’s objectives for businesses include enabling your organization to:
 Produce quality services or products
 Improve customer satisfaction
 Increase value for stockholders
 Achieve industry-wide recognition for excellence
 Grow market share
 According to the Carnegie Mellon Software Engineering Institute, which was integral in its
development, CMMI is intended to:
Help “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.”
1.6. Process Improvement – CMMI
Model Representation - Continuous or Staged
There are two predominant CMMI models in use. An organization should decide which
representation best fits its' process-improvement requirements. The representation, either continuous or
staged, will determine the bodies of knowledge you want to be included in the model used by the
organization. The following lists describe some of the possible advantages and disadvantages to selecting
each of the two representations.

Figure 2. CMMI – Continuous Representation

 Highlight :
 Specific goals organize specific practices and the generic goals organize generic practices.
 Each specific and generic practice corresponds to a capability level.
 Specific goals and specific practices apply to individual process areas.
 Generic goals and generic practices apply to multiple process areas.
 Generic goals and generic practices define a sequence of capability levels that represent
improvements in the implementation and effectiveness of all the processes you choose to
improve.
 Uses capability levels to measure process improvement,
 Permits flexibility in the order of improvement that best meets the organization’s business
objectives and mitigates the organization’s areas of risk
 Enables comparisons across and among organizations on a process area by process area basis
or by comparing results through the use of equivalent staging
 Affords an easy comparison of process improvement to International Organization for
Standardization and International Electronically Commission (ISO/IEC) 15504, because the
organization of process areas is similar to ISO/IEC 15504

 Uses six capability levels, capability profiles, target staging, and equivalent staging as
organizing principles for the model components.
 Groups process areas by affinity categories and designates capability levels [Note] for process
improvement within each process area.
 Capability levels provide a recommended order for approaching process improvement within
each process area.
 Allows some flexibility for the order in which the process areas are addressed.
Figure 3. Staged Representation

 Highlight :
 Maturity levels provide a recommended order for approaching process improvement in stages.
 Maturity levels organize the process areas.
 Within the process areas are generic and specific goals as well as generic and specific
practices.
 Common features organize generic practices.
 focuses on best practices for an organization to improve processes in the process areas within
a designated maturity level
 uses maturity levels to measure process improvement,

 Provides a proven sequence of improvements, beginning with basic management practices and
progressing through a predefined and proven path of successive levels, each serving as a
foundation for the next
 Permit comparisons across and among organizations by the use of maturity levels
 Provide a single rating that summarizes appraisal results and allows comparisons among
organizations
 Provides a way to predict the future performance of an organization within a given discipline
or set of disciplines.
1.7. Difference between CMM and CMMI
The CMMI structure and the Software CMM structure are similar with respect to maturity levels, key
process areas, goals (divided into specific and general goals in CMMI), and practices.
A big difference however is that CMMI offers two representations of the maturity of the processes.
CMMI offers a staged representation with five maturity levels just like the Software CMM and a continuous
model where each process area has its own maturity level.

II. CMMI Process

II.1 What is CMMI?
The CMMI is an integrated maturity competency model that provides a clear definition of the actions
that need to be promoted by an organization to improve operational productivity. With five “Maturity
Levels” or three “Levels of Competency”, CMMI identifies the most important factors for building a good
product, or providing a good service, and embedding them in a mature model.
II.2 . CMMI process guidance

II.2.1 Understand CMMI process template artifacts
The CMMI workflow supports the following types of work items (WITs) for work planning and
tracking, testing, feedback, and code review. With different WITs, you can track different types of work —
such as requests, change requests, tasks, bugs, and more. These artifacts are created when you create a
project using the CMMI process. They are based on the Capability Maturity Model Integration (CMMI)
process.
Figure 4. CMMI work items

II.2.2 Plan and track work with CMMI

Teams plan their projects by capturing features and requirements. As teams work in sprints, they
define tasks and link them to requirements. To better understand the aggregation of requirements across
teams, program managers associate requirements with a feature. Blocking issues are tracked using issues.
For details on using these WITs, see CMMI workflow and workflow item types
The essential flow for getting started is as shown. To get started using Scrum or Kanban tools.
 Epics: Epics within the CMMI process are the same as Epics within the Basic process. Epics
contain the high level process of what is to be delivered. An example of this would be the
delivery of different channels e.g phone or chat within a call center.
 Features: Epics contain one or more features. Features allows the definition of different focus
points which must be delivered in order for the epic to be delivered. E.g telephony integration
and call verification features would be required in order to deliver an epic related to the
delivery of a telephone channel in a call center.
 Requirements: Requirements describe the needs of the business and also defines what is
required for the feature to be completed. Requirements can be associated to one or more
Features. It should be noted that a requirement is not a feature and should contain enough
information for both testers and developers to understand the business need and what the
system is expected to do to satisfy the need. Requirements which define how the system will
satisfy the need to reduce the flexibility of designing the system and may create issues later in
the project as technically and strictly speaking, changing how the requirement is implemented
would mean that a change request should be generated. An example of a requirement that
would be associated to the call verification feature above would be that the customer must
validate three pieces of information which could contain their name, address, date of birth or
credit limit.
 Tasks: Tasks provide a breakdown of what needs to be completed in order to complete a
requirement. An example of a task which could be associated with the above requirement
could be to create the credit limit field on the contact record. (Assuming you're using a CDS
database the name, address and date of birth fields should already exist).
 Change Requests: Deviations from the agreed scope, should be logged as a change request.
The CMMI process provides a work item which can be associated to the original
requirement/s or feature/s being affected by the change and also allows the impact of the

change to be documented. The below image shows an example of the change request work
item.
Figure 5. CMMI Change Request Work Item

 Review: The review work item allows users to document meetings within Azure DevOps. These
could be review meetings, design meetings or even team meetings. Attendees who are also Azure
DevOps users can be selected and other work items which was discussed within the meeting
associated for reference. This work item is only available by default with the CMMI process
template.
 Issue: The issue work item available within the CMMI process template concerns to project
related problems and is not the same issue work item used within the Basic process template.

Figure 6. CMMI Issue Work Item

 The CMMI issue work item allows users to describe the issue as well as detail the corrective
actions needed to resolve the issue
 Risk: No project is without risks. Within the CMMI process, these risks can be logged and
tracked associated if necessary to the work items it concerns to. Within the risk work item users
are able to describe the risk, specify the probability as well as make plans that allows everyone
(with access) to know what to do in the event that this risk becomes an issue.
II.2.3 List work items with queries
You can use work item queries to list work items based on their type, such as change requests, bugs,
tasks, and requirements.
II.2.3.1 . Add work item queries to a process template
By adding work item queries to your process template, you can define the initial set of shared queries
and query folder structure for a project. All team members use queries to find the bugs, tasks, and other
work items on which they must take action.
Work item queries specify criteria for generating a list of work items, such as a list of active bugs or
closed tasks. Files for work item queries have a .wiq extension and are stored in the Queries subfolder of the
WorkItem Tracking folder for the default process templates. You specify the query definitions to upload as
a task within the WorkItemTracking plug-in. This task may be required because several artifacts in a
process template may depend on a query. In addition, the task to upload queries depends on the successful

completion of the task for uploading work item types. You specify each query file to upload within the
taskXml element.
II.2.3.2 Create a work item query (.wiq) file
Each query definition must be specified in its own file with an extension of .wiq, using the
WorkItemQuery parent element, and conform to the schema that is defined in the wiq.xsd file.
II.2.3.3 Specify queries to upload
To include the work item queries in the process template, create one or more tasks in the
workitems.xml file, which you can find in the \WorkItem Tracking folder, which is in the folder to which
you downloaded your process template. Use the Query element to specify the file for the work item query.
For example, the following XML specifies the query that is defined in the ActiveBugs.wiq file to be
uploaded and named Active Bugs.
You add the set of queries to upload as a task in the WorkItemTracking plug-in.
II.2.3.4 . QUERY elements
The following syntax shows the structure of the QUERIES element and its children.
<QUERIES
<Permission /
<QueryFolder
<Query/
</QueryFolder
</QUERIES
The following table describes the elements that you use to specify the query folder structure,
permissions, and queries to upload. You specify these elements within a taskXml container element
in the WorkItemTracking plug-in file.
Element  Description and syntax

Permission  Optional child element of Query. Specifies the
default permissions that are assigned to shared
queries. For more information, see Assign
permissions for work item queries.
<permission allow="ListOfPermissions"
identity="GroupName" />

Query  Required child element of QUERIES. Specifies

the name and the path of the .wiq file that defines
a query to upload.
<Query name="QueryName"
fileName="QueryFilePathName" />
 As the following example shows, you can upload
the query that is labeled "Active Bugs? and that is
defined in the ActiveBugs.wiq file:
<Query name="Active Bugs"

fileName="WorkItem Tracking\Queries\
ActiveBugs.wiq" />
QueryFolder  Optional child element of QUERIES. Specifies
the name of a query folder.
<QueryFolder name="FolderName">
<Query />
</QueryFolder>
QUERIES  Optional child element of the taskXml element for
the WorkItemTracking plug-in. Specifies which
query definition files to use to create default
queries.
<QUERIES>
...
</QUERIES>
II.2.4 Quick tips on shared queries

If you are new to Azure Boards, work tracking, and shared queries, review these tips to learn how
you can manage work more effectively:
 To find work items that are assigned to you, add @Me as the value for the Assigned To field
in one of the query clauses.

 All valid users with standard access can create queries and folders under the My Queries area.
To create queries and query folders under Shared Queries, you must have the Contribute
permission set and have been assigned Basic access or greater. For more information, see Set
permissions on queries.
 You can modify any query by adding criteria to focus on a product area, an iteration, or
another field. To modify a query, open the query editor.
 You can open any query in Excel where you can update the fields of one or more work items
and publish your changes to the database for tracking work items.
 You can visualize status or progress by creating a pie-chart, column chart, or trend chart for
flat-list queries.
II.2.5 Monitor progress
All processes—Agile, Scrum, and CMMI—support building status and trend charts and dashboards.
Also, several charts are automatically built based on the Agile tools you use. These charts display within the
web portal.
II.2.5.1 . About dashboards, charts, reports and widgets
Gain visibility into your team's progress by adding one or more widgets or charts to your dashboard.
Customizable, highly configurable dashboards provide you and your teams with the flexibility to share
information, monitor progress and trends, and improve your workflow processes. Each team can tailor their
dashboards to share information and monitor their progress.
II.2.5.2 . Supported capabilities, permissions, and access
Access to Azure DevOps web portal features are managed through access levels assigned to users.
2.2.5.3. Web portal data views and reports
The following features provide support for viewing Azure DevOps data through the web portal:
 Dashboards are customizable interactive signboards that provide real-time information.
Dashboards are associated with a team or a project and display configurable charts and
widgets.
 Charts are query-based status or trend charts derived from a work item query or test results.
 Widgets display configurable information and charts on dashboards. The widget catalog
provides brief descriptions of those widgets available to you. Also, you can add widgets
provided through the Azure DevOps Marketplace.

 In-context reports are system-generated charts that support specific services. Examples are
team velocity, sprint burndown, and the Cumulative Flow Diagram (CFD), and the Test
Failures Report. These reports are displayed on the Analytics tab for a specific service and
derive data from Analytics.
2.2.5.4. Power BI reports
The following features provide support for viewing Azure DevOps data using Power BI:
Analytics views provide a simplified way to specify the filter criteria for a Power BI report based on
Analytics data for Azure Boards data. To learn more, see What are Analytics views?.
Power BI reports allow users to create rich, customized Power BI reports or other reports using
OData queries of Analytics data and the returned JSON data. For on-premises Azure DevOps environments,
project collections must be configured to support the Inherited process.
2.2.5.5. Supported features and access level
Users granted Stakeholder access have limited access to select features as indicated in the following
table. To learn more, see About access levels. In addition to access levels, select features require
permissions to execute.
Supported features and tasks Stakeholders Basic
Dashboards (View)
Dashboards (Create and edit)
Charts, Widgets (View)
Charts, Widgets (Add and configure)
In-context reports
Analytics views
Power BI reports
2.2.5.6 Default permissions

2.2.5.6.1 Dashboards
You can set individual dashboard permissions to grant or restrict the ability to edit or delete dashboards.
Task Readers Contributors Team admins Project admins
View team and project
dashboards
Add and configure

project dashboards
2.2.5.6.2 Power BI Integration and Analytics views

You set permissions for the service at the project level, and for shared Analytics views at the object
level.
Task Readers Contributors Project admins
View Analytics ✔️ ✔️ ✔️
View a shared Analytics ✔️ ✔️
view
Add a private or shared ✔️ ✔️
Analytics view
Edit and delete shared ✔️
Analytics views
2.2.5.7. Configurable dashboards

 With dashboards, you can configure an array of charts and widgets.
 Each team can add and configure multiple dashboards to:
 Share information.
 View status, progress, and trends
 Access quick links and other functions.
 Easily add and rearrange widgets on the dashboard to show recent changes made to view build
status, bug trends, and more.

Figure 7. Configurable dashboards
1.5.7.1 Sequence for adding and customizing a dashboard
2.2.5.8. Charts: Work tracking status and trends

With flat-list queries, you can create various charts to monitor status, progress, and trends. Before
you monitor work progress and trends, you'll need to have planned your project and made progress on work
you're tracking.

You can open a shared query, create a chart, and add it to the dashboard. Once it's been added to the
dashboard, you can change the Chart for work items widget configuration to resize or change the chart
parameters. Or, from the dashboard, you can add a Chart for work items widget and choose a shared query
and set the chart parameters. Chart types include status—pie, bar, column, stacked bar, and pivot—and
trend—stacked area, line, and area—charts.
For details, see:
Define a query
Track progress with status and trend query-based charts
Figure 8 :Sample Agile tool light-weight
Sequence for adding query-based charts to a dashboard

2.2.5.9. Charts: Manual testing progress, results, and trends

The steps to creating charts that track manual testing progress and results are similar to the ones for
tracking work. The starting point, however, begins with the test plan rather than a query. For example, you
can find out how many test cases are ready to run, or how many tests are passing and failing in each test
suite. And, just like work item query-based charts, you can add these charts to a dashboard.
 For details, see:
 Create test plans and test suites
 Create manual test cases
 Track test status charts
Figure 9. Sample light-weight test chart
2.2.5.10 Widgets
You add widgets to a dashboard to display a chart, information, or set of links. Most widgets are
configurable. For a description of each supported widget for your platform and version, see the Widget
catalog. Here are the widgets that support the indicated service.
 Widgets are annotated as follows:
 Analytics: Widget derives data from Analytics data
 Build: Widget derives data for a selected build pipeline
 Project: indicates you can select the project and team when configuring the widget

 Release: Widget derives data for a selected release pipeline

 Team: Widget is scoped to a single team
 Teams: Widget is scoped to one or more teams
 User: Widget is scoped to the logged in user account
2.2.5.11. Sprint chart widgets
2.2.5.12. Sprint scope change

There's no chart or widget that tracks changes to sprint scope. However, you can determine work
items added to a sprint or moved out of a sprint using the Query Editor.
2.2.5.13. Sample Cumulative Flow Diagram widget

2.2.5.14. Monitor code activity, build progress and deployment status

With the code tile widgets, you can monitor the activity occurring within a repository or branch
folder. Build history displays a histogram of all builds run for a specific build pipeline. Bar color indicates:
green-completed, red-failed, and yellow-completed without tests.
2.2.5.15. Code, build, and release chart widgets
 Code Tile : Displays the number of recent changes in a code repository.
 Pull Requests: Check on the status of your pull request.
 Chart for Build History: Shows the build history of a selected build definition.
 Deployment status: Shows the deployment and test status of a branch across the environments in
your release definition.
2.2.5.16. Analytics widgets and reports
Figure 10. Sample Lead time widget

2.2.5.17. In-context reports: Work tracking
Azure Boards provides several in-context reports that derive from Analytics data. From your backlog
or board, you can view the Cumulative Flow Diagram and team Velocity reports by selecting the Analytics

tab. Each report provides interactive controls to provide each user the view of interest to them. From a
Sprint backlog, you can view the sprint burndown trend.
2.2.5.18. Cumulative Flow Diagram
Use the interactive controls to choose the time frame, swimlanes, and workflow states or Kanban
board columns.
Figure 11. Cumulative Flow Diagram

2.2.5.19 Velocity
Use the interactive controls to choose the count or sum field and number of iterations.

Figure 12. Velocity Diagram
2.2.5.21. Sprint Burndown Trend

Use the interactive controls to choose the start and end of the sprint and count or sum field to use in
the burndown. If you don't track Remaining Work in tasks, you can view burndown based on a count of
work items/tasks.

Figure 13. Sprint Burndown Diagram

2.2.5.22 In-context reports: Pipelines and Test
Several in-context reports are provided for Azure Pipelines. These reports derive from Analytics
data. Open a pipeline (or release summary for Test failure) to view the reports and select the Analytics tab.
Select View full report on a summary card for a detailed report.
Figure 14. Analytics Reports

2.2.5.23. Pipeline pass rate report

The Pipeline pass rate report provides a trend of pipeline failure and task failure of the pipeline. You
can view the pass rate of the pipeline over a configurable period of time (7/14/30 days). You can view more
details in Task failure details, which not only highlights the trend, but also list the top failing tasks.
Figure 15. Picture of Pipeline pass rate

2.2.5.24. Test failures report
The Test failures report provides a granular view of the top failing tests in the pipeline, along with
the failure details. Summary charts are also provided for builds that indicate code coverage and test failures
or success.

Figure 16. Test failures report

2.2.5.25. Pipeline duration report
The Pipeline duration report provides the duration trend of a pipeline. It also highlights the average
run time of the total successful runs over a period of time (7/14/30 days) and provides insights on the tasks
that have affected the duration of the pipeline.
Figure 17. Pipeline duration report

2.2.5.26. Add custom work tracking fields

You can add data to support reporting requirements by adding a custom field.
2.2.5.27. Marketplace widgets and extensibility
In addition to the widgets available in the widget catalog, you may find interesting widgets in the
Marketplace.
2.2.6 Create light-weight charts
To get started, you can define a shared flat query and create a chart based on your tracking interests.
Chart types include status—pie, bar, column, stacked bar, and pivot—and trend—stacked area, line, and
area—charts.
Steps to take
2.2.6.1Analytics widgets and Power BI reports
The Analytics Service can answer quantitative questions about the past or present state of your
projects. You can add Analytics widgets to a dashboard or use Power BI to create charts and reports.
2.2.6.2 Related notes
Before you start tracking work, you must have a project. To create one, see Create a project.
 If you have a project, start tracking work:
 Add work items to manage a project - to gain more familiarity with the work item form
features
 Create a backlog - to develop your product backlog
 Kanban - to start working in Kanban
 Plan a sprint - to start working in Scrum
 Excel.
2.2.7 CMMI process versions
As updates are made to the CMMI process template, the version number is updated. The following
table provides a mapping of the versioning applied as updates are made to the Azure DevOps on-premises

process templates. For Azure Boards, the latest version is always used. Each template provides a version
element. This element specifies a major and minor version.
TFS version CMMI name Major version
Azure DevOps Services CMMI 18
Azure DevOps Server 2022
Azure DevOps Server 2020 CMMI 17
Azure DevOps Server 2019
TFS 2018 CMMI 16
III CMMI Model

I.1 Background to Capability Maturity Model Integration (CMMI)
I.1.1 Why use a model?
Improvement efforts require a model of how your organization works, which functions they need,
and how those functions interact. A model gives you an understanding of organizational elements and
assists in discussions of how and what can and should be improved.
 A model offers the following benefits:
 Provides a common framework and language to help communicate
 Leverages years of experience
 Helps users consider the large picture while focusing n improvement
 Is often supported by trainers and consultants
 Can help solve disagreements by providing agreed-upon standards
I.1.2 What is the purpose of the CMMI model?

The purpose of the CMMI model is to assess the maturity of an organization's processes and to
provide guidance on improving processes, with a goal of improved products. Also, CMMI is a model for
risk management and provide a way to measure an organization's ability to manage risk. The ability to
manage risk factors factors into an organizations ability to deliver high-quality products. Another
perspective on managing risk is how well an organization will perform under stress. A high maturity, high
capability organization can easily respond to unexpected, stressful events. A low maturity and lower

capability organization tends to panic under stress, blindly follow obviated procedures, or throw out all
process altogether and retrench back to chaos.
The CMMI, however, isn't a proven indicator of the economic performance of an organization.
Although higher maturity organizations may manage risk better and be more predictable, evidence exists
that higher maturity firms tend to be risk-averse. Risk aversion can lead to a lack of innovation or evidence
of greater bureaucracy that results in long lead times and a lack of competitiveness. Lower maturity firms
tend to be more innovative and creative but chaotic and unpredictable. When results are achieved, they are
often the result of heroic effort by individuals or managers.
I.1.3 What's the best way to use the CMMI model?
The model was designed to be used as the basis for a process improvement initiative, with its use in
assessment only a support system for measuring improvement. There has been mixed success with this
usage. It is all too easy to mistake the model for a process definition and try to follow it, instead of a map
that identifies gaps in existing processes that may need to be filled. The fundamental building block of
CMMI is a process area that defines goals and several activities that are often used to meet them. One
example of a process area is Process and Product Quality Assurance. Another is Configuration
Management. It is important to understand that a process area is not a process. A single process may cross
multiple process areas, and an individual process area may involve multiple processes.
The CMMI-DEV is really two models that share the same underlying elements. The first and most
familiar is the Staged Representation, which presents the 22 process areas mapped into one of five
organizational maturity levels. An appraisal of an organization would assess the level at which it was
operating, and this level would be an indicator of its ability to manage risk and, as, deliver on its promises.
Levels 4 and 5 are often referred to as higher maturity levels. There is often a clear difference
between higher maturity organizations, which demonstrate the quantitative management and optimizing
behaviors, and lower maturity organizations, which are merely managed or following defined processes.
Higher maturity organizations show lower variability in processes and often use leading indicators as part of
a statistically defensible management method. As a result, higher maturity organizations tend to be both
more predictable and faster at responding to new information, assuming that other bureaucracy doesn't get
in the way. Where low maturity organizations tend to demonstrate heroic effort, high maturity organizations
may blindly follow processes when under stress and fail to recognize that a process change may be a more
appropriate response. The Continuous Representation models process capability within each of the 22
process areas individually, which allows the organization to tailor their improvement efforts to the processes

that offer the highest business value. This representation is more in line with Crosby's original model.
Appraisals against this model result in profiles of capability rather than a single number. Because the
organizational maturity level is the level that most managers and executives understand, there are ways of
mapping the results of a continuous model assessment into the five stages.
Figure 18. Orrganizational Maturity Leve
Using the staged model as a basis for a process improvement program can be dangerous when
implementers forget that the CMMI isn't a process nor a workflow model. Instead, the CMMI is designed to
provide goals for process and workflow to achieve. Meeting such goals will improve the maturity of the
organization and the likelihood that events unfold as planned. Perhaps the biggest failure mode is making
achieving a level the goal and then creating processes and infrastructure simply to pass the appraisal. The
goal of any process improvement activity should be measurable improvement, not a number. The
Continuous model has enjoyed success as a guide to process improvement. Some consulting firms choose
only to offer guidance around the Continuous model. The most obvious difference is that a process
improvement program that is designed around the Continuous model doesn't have artificial goals that are
determined by maturity levels. The Continuous model also lends itself to applying process improvement in
areas where it is most likely to leverage an economic benefit for the organization. Therefore, those who
follow the Continuous model are more likely to receive positive feedback from an initiative that is based on
the CMMI model. Moreover, positive feedback is more likely to lead to the development of a virtuous cycle
of improvements.

Figure 19. Practice Capability Levels

I.2 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 IntergrationSM 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].
Figure 20. The History of CMMS

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.
I.3 CMMI Maturity Level
A maturity level is a well-defined evolutionary plateau toward achieving a mature software process.
Each maturity level provides a layer in the foundation for continuous process improvement.
In CMMI models with a staged representation, there are five maturity levels designated by the numbers 1
through 5
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing

Figure 21. Capability Maturity Model Int
I.3.1 Maturity Level 1 – Initial

At maturity level 1, processes are usually ad hoc and chaotic. The organization usually does not
provide a stable environment. Success in these organizations depends on the competence and heroics of the
people in the organization and not on the use of proven processes.
Maturity level 1 organizations often produce products and services that work; however, they frequently
exceed the budget and schedule of their projects.
Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the
time of crisis, and not be able to repeat their past successes.
I.3.2 Maturity Level 2 – Managed
At maturity level 2, an organization has achieved all the specific and generic goals of the maturity
level 2 process areas. In other words, the projects of the organization have ensured that requirements are
managed and that processes are planned, performed, measured, and controlled.
The process discipline reflected by maturity level 2 helps to ensure that existing practices are retained
during times of stress. When these practices are in place, projects are performed and managed according to
their documented plans.
At maturity level 2, requirements, processes, work products, and services are managed. The status of
the work products and the delivery of services are visible to management at defined points.

Commitments are established among relevant stakeholders and are revised as needed. Work products
are reviewed with stakeholders and are controlled.
The work products and services satisfy their specified requirements, standards, and objectives.
I.3.3 Maturity Level 3 – Define
At maturity level 3, an organization has achieved all the specific and generic goals of the process
areas assigned to maturity levels 2 and 3.
At maturity level 3, processes are well characterized and understood, and are described in standards,
procedures, tools, and methods.
A critical distinction between maturity level 2 and maturity level 3 is the scope of standards, process
descriptions, and procedures. At maturity level 2, the standards, process descriptions, and procedures may
be quite different in each specific instance of the process (for example, on a particular project). At maturity
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. The organization's set of standard
processes includes the processes addressed at maturity level 2 and maturity level 3. As a result, the
processes that are performed across the organization are consistent except for the differences allowed by the
tailoring guidelines.
Another critical distinction is that at maturity level 3, processes are typically described in more detail
and more rigorously than at maturity level 2. At maturity 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.
3.3.4 Maturity Level 4 – Quantitatively managed
At maturity level 4, an organization has achieved all the specific goals of the process areas assigned
to maturity levels 2, 3, and 4 and the generic goals assigned to maturity levels 2 and 3.
At maturity level 4 Subprocesses are selected that significantly contribute to overall process
performance. These selected subprocesses are controlled using statistical and other quantitative techniques.
Quantitative objectives for quality and process performance are established and used as criteria in
managing processes. Quantitative objectives are based on the needs of the customer, end users,
organization, and process implementers. Quality and process performance are understood in statistical terms
and are managed throughout the life of the processes.

For these processes, detailed measures of process performance are collected and statistically
analyzed. Special causes of process variation are identified and, where appropriate, the sources of special
causes are corrected to prevent future occurrences.
Quality and process performance measures are incorporated into the organization.s measurement
repository to support fact-based decision making in the future.
A critical distinction between maturity level 3 and maturity level 4 is the predictability of process
performance. At maturity level 4, the performance of processes is controlled using statistical and other
quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only
qualitatively predictable.
3.3.5 Maturity Level 5 – Quantitatively managed
At maturity level 5, an organization has achieved all the specific goals of the process areas assigned
to maturity levels 2, 3, 4, and 5 and the generic goals assigned to maturity levels 2 and 3.
Processes are continually improved based on a quantitative understanding of the common causes of
variation inherent in processes.
Maturity level 5 focuses on continually improving process performance through both incremental
and innovative technological improvements.
Quantitative process-improvement objectives for the organization are established, continually revised
to reflect changing business objectives, and used as criteria in managing process improvement.
The effects of deployed process improvements are measured and evaluated against the quantitative
process-improvement objectives. Both the defined processes and the organization's set of standard processes
are targets of measurable improvement activities.
Optimizing processes that are agile and innovative depends on the participation of an empowered
workforce aligned with the business values and objectives of the organization. The organization's ability to
rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning.
Improvement of the processes is inherently part of everybody's role, resulting in a cycle of continual
improvement.
A critical distinction between maturity level 4 and maturity level 5 is the type of process variation
addressed. At maturity level 4, processes are concerned with addressing special causes of process variation
and providing statistical predictability of the results. Though processes may produce predictable results, the
results may be insufficient to achieve the established objectives. At maturity level 5, processes are
concerned with addressing common causes of process variation and changing the process (that is, shifting

the mean of the process performance) to improve process performance (while maintaining statistical
predictability) to achieve the established quantitative process-improvement objectives.
3.4 CMMI Capability levels
3.4.1 Capability level 1 : 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.
 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.4.2 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.
3.4.3 Capability level 3 : Defined
 A defined process is managed and meets the organization’s set of guidelines and standards.
 Focus is process standardization.
3.4.4 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.
3.4.5 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.
Figure 22. Capability maturity model int
3.5 Updated CMMI V2.0

The CMMI Institute has focused on simplifying both the model and appraisal method. Here are some
of their original goals for the changes:
 Model :
 A simplified model that reduces redundancy.
 One model that includes Development, Services, Security, Supply Chain and People practices.
Appropriate topics are selected for different types of organizations.
 Each Practice Area contains an evolutionary pathway (e.g., Capability Level 1, 2 and 3
practices).
 Appraisal Method :
 Increase quality, reliability, and consistency.
 Reduce the overall lifecycle cost to conduct an appraisal.
 Minimize organizational and work effort disruption.
 Provide greater insight into performance improvement.
The main communication points from the CMMI Institute for V2.0 are:
 Improve Business Performance: Business goals are tied to operations in order to drive
measurable improved performance.
 Leverage Current Best Practices: CMMI V2.0 is a trusted source of proven best practices.

 Build Agile Resiliency and Scale: The model contains direct guidance on how to strengthen
Agile with Scrum.
 Benchmark Capability and Performance: The new performance-oriented appraisal method
improves the reliability and consistency of benchmarking while reducing preparation time and
lifecycle costs.
 Accelerate Adoption: Online platform and adoption guidance make the benefits of CMMI
more rapidly achievable.
 Changed “Process Area” to “Practice Area”: This emphasizes that the model is not a
collection of (rote) processes to be implemented, but a collection of practices to be used to run
and manage projects.
 Organized practices within each Practice Area: Practices are organized by levels instead of
Specific Goals. Levels provide a clear, methodical path for building capability and improving
performance within each Practice Area.
 Replaced the Generic Practices with two new Practice Areas: Governance (GOV) &
Implementation Infrastructure (II) to reduce the redundancy and complexity of the Generic
Practices. They foster the persistence and habit of an organization’s processes and their
business value rather than compliance to the model.

Figure 23. CMMI V2.0

Major Model Changes
The new layout includes levels (similar to the old Capability Levels) that provide a simple process
maturity pathway. For example, to be Maturity Level 3 (ML3), Practice groups at Levels 1, 2 and 3 (the
“Level” columns in Figure 2) have to be satisfied.
3.6 CMMI certifications
CMMI certifications are offered directly through the CMMI Institute, which certifies individuals,
appraisers, instructors, and practitioners.
 The CMMI Institute offers the following certifications:
 CMMI Associate: The CMMI Associate Certification demonstrates your commitment and
abilities when it comes to capability and performance improvement. The certification
validates that you have the skills and knowledge to connect the CMMI model to business
value and to participate as an Appraisal Team Member (CTM).
 CMMI Professional: The next level of certification is the CMMI Professional
certification, which demonstrates your ability to apply the CMMI model in an organization
structure through road maps for performance, team coaching, organizational change
management and fostering a culture of improvement.
 Certified CMMI Lead Appraiser: As a certified CMMI Lead Appraiser, you will be
qualified to appraise organizations to determine their capability or maturity level as
outlined in the CMMI model. Applications are reviewed by the ISACA Appraiser
Application Review committee, who will evaluate your qualifications for the certification.
 Certified CMMI Instructor: The Certified CMMI Instructor certification enables you to
lead instructional courses on CMMI. You’ll need a sponsoring organization that also is an
ISACA partner and that is licensed for use of the CMMI product suite to qualify for the
exam.
3.7 Process Improvement Steps
Broadly speaking Process Improvement in a CMMI Organization has following steps:
1.Documentation: Process Improvement starts with defining Processes and associated artifacts
like Templates, Checklists, Guidelines, and Manuals etc.
2.Training: Providing Training to staff and different roles that will use these Processes and other
artifacts.

3.Implementation: Starts implementing processes in projects.

4.Getting Feedback: Process Implementers provides their feedback and asks for
changes/enhancement in the processes. Collect, Document and Evaluate these Change
Requests. At High Maturity Levels i.e. 4 and 5 Statistical Tools are used to collect these
improvement points.
5.Plan Improvement/Enhancements: Based on the evaluation and approval from Management,
certain changes/enhancements are selected for implementation and a Process Improvement Plan
is prepared for this.
6.Piloting: Certain Staff/Projects are selected to carry out these improvements.
7.Evaluate Improvements: Once improvements are done, they are evaluated for their benefits
after certain period of implementation.
8.Organization wide rollout: Once satisfied with results these improvements are rollout at Org
level and training are planned and provided to staff for these changes.
9.Support and Facilitation: Providing regular support and facilitation to process implementers.
3.8 CMMI Appraisals
The CMMI Appraisal is an examination of one or more processes by a trained team of professionals
using an appraisal reference model as the basis for determining strengths and weaknesses of an
organization.
Appraisals require planning. When planning an appraisal of your organization, determine the scope
of the organizational unit, which disciplines to include, whether the appraisal team will consist of members
internal or external to your organization, projects to be included, individuals to be interviewed, and the type
or class of appraisal necessary.
 Appraisals consider three categories of model components as defined in the CMMI
 Required − specific and generic goals only.
 Expected − specific and generic practices only.
 Informative − includes sub-practices and typical work products.
The SEI has released two guiding documents for CMMI assessments
 Appraisal Requirements for CMMI (ARC) − It contains the requirements for three classes
of appraisal methods Class A, Class B, and Class C. These requirements are the rules for
defining each class of appraisal method.

 Standard CMMI Appraisal Method for Process Improvement (SCAMPI) − Method

Description Document (MDD) is currently the only approved Class A appraisal method.
SCAMPI is currently the only approved CMMI Class A Appraisal Method. That is, SCAMPI
satisfies all the requirements of an ARC Class A Appraisal Method and has been approved by the SEI.
There are three classes of CMMI Appraisal Methods: Class A, Class B, and Class C.
3.8.1 SCAMPI Class A Appraisal
A SCAMPI Class A appraisal is typically conducted when an organization has implemented a
number of significant process improvements and needs to formally benchmark its process relative to the
CMMI. A SCAMPI A is the only appraisal method that provides CMMI Maturity Level or Capability Level
ratings.
 You can expect following outcomes from a SCAMPI A
 A Maturity Level rating or Capability Level ratings.
 Findings that describe the strengths and weaknesses of your organization's process relative to
the CMMI.
 Consensus regarding the organization's key process issues.
 An appraisal database that the organization can continue to use, to monitor process
improvement progress and to support future appraisals.
3.8.2 SCAMPI Class B Appraisal
A SCAMPI B is called for when an organization needs to assess its progress towards a target CMMI
Maturity Level, but at a lower cost than a SCAMPI A. SCAMPI B appraisals provide detailed findings and
indicate the likelihood that the evaluated practices would be rated as satisfactorily implemented in a
SCAMPI A appraisal.
A SCAMPI Class B appraisal, one of three SEI appraisal methods, helps an organization understand,
with a relatively high degree of confidence, the status of its software and systems engineering process
relative to the CMMI. A SCAMPI B is often performed when an organization needs to accurately assess its
progress towards a target CMMI Maturity Level.
 You can expect following outcomes from a SCAMPI B
 Detailed findings that describe the strengths and weaknesses of your organization's process relative
to the CMMI.
 Practice characterizations indicating the likelihood that the examined practices would satisfy the
goals and meet the intent of the CMMI.

 Consensus regarding the organization's key process issues.

 A FIDO database that the organization can continue to use, to monitor process improvement progress
and to support future appraisals.
3.8.3 SCAMPI Class C Appraisal
SCAMPI C appraisals are shorter and more flexible than SCAMPI A and B appraisals and are
conducted to address a variety of special needs, from a quick gap analysis to determining an organization's
readiness for a SCAMPI A.
SCAMPI Class C appraisals, the least formal of the SEI's suite of appraisal methods, are highly
flexible and can be conducted to address a variety of needs. Typically much shorter in duration than Class A
and B appraisals, SCAMPI C appraisals are often performed for reasons such as −
 Provide a quick gap analysis of an organization's process relative to the CMMI.
 Assess the adequacy of a new process before it is implemented.
 Monitor the implementation of a process.
 Determine an organization's readiness for a SCAMPI A.
 Support the selection of a supplier.
 You can expect following outcomes from a SCAMPI C
 Findings that describe the strengths and weaknesses of the assessed processes. Depending on
the appraisal scope and strategy, findings may be mapped to the relevant CMMI components.
 Characterizations that summarize the adequacy of the assessed processes vis-a-vis the CMMI.
 Recommended process improvement actions.
 A FIDO database that the organization can continue to use to monitor process improvement
progress and to support future appraisals.
3.8.4 Appraisal Class Characteristics
SCAMPI C appraisals are shorter and more flexible than SCAMPI A and B appraisals and are
conducted to address a variety of special needs, from a quick gap analysis to determining an organization's
readiness for a SCAMPI A.
SCAMPI Class C appraisals, the least formal of the SEI's suite of appraisal methods, are highly
flexible and can be conducted to address a variety of needs. Typically much shorter in duration than Class A
and B appraisals, SCAMPI C appraisals are often performed for reasons such as −
 Provide a quick gap analysis of an organization's process relative to the CMMI.

 Assess the adequacy of a new process before it is implemented.

 Monitor the implementation of a process.
 Determine an organization's readiness for a SCAMPI A.
 Support the selection of a supplier.
 You can expect following outcomes from a SCAMPI C
 Findings that describe the strengths and weaknesses of the assessed processes. Depending on
the appraisal scope and strategy, findings may be mapped to the relevant CMMI components.
 Characterizations that summarize the adequacy of the assessed processes vis-a-vis the CMMI.
 Recommended process improvement actions.
 A FIDO database that the organization can continue to use to monitor process improvement
progress and to support future appraisals.
Each class is distinguished by the degree of rigor associated with the application of the method. Class
A is the most rigorous, Class B is slightly less rigorous, and Class C is the least rigorous. Following table
gives some idea of the expected differences between the methods in each class.
Figure 24. Appraisal Class Characteristi

3.9 CMMI Players - Roles Responsibilities

This chapter discusses the major players involved with a process improvement effort. However, your
organization may require more or fewer groups.
Note that one person can fulfill many of these roles simultaneously or serially, depending on the size of
your organization and the complexity of your process improvement (PI) effort.
Process Improvement Process improvement efforts generally require the following individuals and
groups − PI Sponsor − The person from the organization responsible for over-seeing the entire PI effort.
This person generally has the power to allocate funds and personnel. This person is usually at the directorate
level or above.
 PI Champion − This is the public relations person for the PI effort, who may or may not serve as the
EPG Lead. This person markets the idea, approach, and results of PI.
 Engineering Process Group (EPG) Lead − This person leads the group that reviews processes. This
person assigns tasks to the EPG members, monitors their efforts, and plans the daily duties of the
EPG.
 EPG Members − These individuals serve on the EPG as committee members. They are responsible
for ensuring that process improvement documentation is written and followed. They are also
responsible for generating metrics to track the process improvement process. They lead the PATs.
 Process Action Teams (PATs) − These teams generate the process improvement documentation,
policies, processes, procedures, charters, and Action Plans.
 Transition Partner − Usually one or two individuals who are outside consultants brought in to help
set up, plan, lead, and monitor progress in organizational process improvement. These individuals
bring experience doing process improvement from several other organizations and industries.

IV References
[1]. https://www.bmc.com/blogs/cmmi-capability-maturity-model-integration/
[2].https://www.cio.com/article/274530/process-improvement-capability-maturity-model-integration-cmmi-
definition-and-solutions.html
[3].https://www.cmmiconsultantblog.com/cmmi-faqs/what-is-cmmi-process-improvement-and-how-to-do-
it/
[4].https://processimprovementco.com/?p=88
[5].https://learn.microsoft.com/en-us/azure/devops/boards/work-items/guidance/cmmi/guidance-
background-to-cmmi?view=azure-devopshttps://www.cio.com/article/274530/process-improvement-
capability-maturity-model-integration-cmmi-definition-and-solutions.html
[6].https://viden.io/knowledge/cmmi?
utm_campaign=creator_campaign&utm_medium=referral&utm_source=youtube&utm_term=ajaze-khan-1
[7].https://www.cmmiconsultantblog.com/cmmi-faqs/what-is-cmmi-process-improvement-and-how-to-do-
it/
[8].https://processimprovementco.com/?p=88
[9].https://learn.microsoft.com/en-us/azure/devops/boards/work-items/guidance/cmmi/guidance-
background-to-cmmi?view=azure-devops
[10].https://www.tutorialspoint.com/cmmi/cmmi_quick_guide.htm
[11].https://www.scribd.com/read/480283639/CMMi-A-Complete-Guide-2021-Edition
[12].https://www.oreilly.com/library/view/project-management-success/9780132333054/
[13].https://books.google.com.vn/books?
id=KEbODQAAQBAJ&printsec=frontcover&hl=vi&source=gbs_ge_summary_r&cad=0#v=onepage&q&f
=false
[14].https://amis.misa.vn/45629/cmmi-la-gi/
[15].https://luanvan.net.vn/luan-van/de-tai-mo-hinh-cmmcmmi-trong-sqa-76126/
[16].https://xemtailieu.net/tai-lieu/ung-dung-mo-hinh-cmmi-tai-fsoft-luan-van-do-an-de-tai-tot-nghiep-
46507.html
[17].https://tailieumienphi.vn/doc/tieu-luan-phan-tich-thuc-trang-ap-dung-cmmi-tai-cong-ty-gia-cong-phan-
mem-tma-ez86tq.html
[18].https://viblo.asia/p/cmmi-phan-1-57rVRqVQM4bP
[19].http://tapchi.ueb.edu.vn/Fuploads/20130718143841418.pdf

[20].https://luanvan.co/luan-van/ung-dung-mo-hinh-cmmi-tai-fsoft-57728/
[21].https://khotrithucso.com/doc/p/cmmi-for-development-guidelines-for-process-integration-3rd-201184
[22].https://www.apexglobal.com.vn/vi/trien-khai-he-thong-quan-ly-phat-trien-phan-mem-cmmi/
[23].https://taxplus.vn/cmmi/

Group 7

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Group 7

Uploaded by

Copyright:

Available Formats

SOFTWARE PROCESS & QUALITY MANAGEMENT

Process Improvement - CMMI

The final version

Instructor: Huy, Truong Dinh

Start Date 12/09/2023 End Date: 12/12/2023

Lead Institution International School, Duy Tan University

Process Improvement - CMMI

Process Improvement - CMMI

2.2.5.17 In-context reports: Work tracking.....................................................................25

Process Improvement - CMMI

3.8.2 SCAMPI Class B Appraisal..............................................................................46

Process Improvement - CMMI

Figure 1: CMMI – Software Development Cycle...............................................................6

Process Improvement - CMMI

Figure 1. CMMI – Software Development Cycle

1.2. What is Software Process Improvement?

Process Improvement - CMMI

1.3. Software quality management

Process Improvement - CMMI

Process Improvement - CMMI

Figure 2. CMMI – Continuous Representation

Process Improvement - CMMI

Figure 3. Staged Representation

Process Improvement - CMMI

Process Improvement - CMMI

II. CMMI Process

II.2 . CMMI process guidance

Figure 4. CMMI work items

Process Improvement - CMMI

II.2.2 Plan and track work with CMMI

Process Improvement - CMMI

Figure 5. CMMI Change Request Work Item

Process Improvement - CMMI

Figure 6. CMMI Issue Work Item

Process Improvement - CMMI

Element  Description and syntax

Process Improvement - CMMI

Query  Required child element of QUERIES. Specifies

<Query name="Active Bugs"

II.2.4 Quick tips on shared queries

Process Improvement - CMMI

Process Improvement - CMMI

2.2.5.6 Default permissions

Process Improvement - CMMI

2.2.5.6.2 Power BI Integration and Analytics views

2.2.5.7. Configurable dashboards

Process Improvement - CMMI

Figure 7. Configurable dashboards

1.5.7.1 Sequence for adding and customizing a dashboard

2.2.5.8. Charts: Work tracking status and trends

Process Improvement - CMMI

Figure 8 :Sample Agile tool light-weight

Sequence for adding query-based charts to a dashboard

Process Improvement - CMMI

2.2.5.9. Charts: Manual testing progress, results, and trends

Figure 9. Sample light-weight test chart

Process Improvement - CMMI

 Release: Widget derives data for a selected release pipeline

2.2.5.12. Sprint scope change

Process Improvement - CMMI

2.2.5.14. Monitor code activity, build progress and deployment status

Figure 10. Sample Lead time widget