Software Process

Maturity
MekonnenWagaw
(PhD)

SOFTWARE PROCESS AND PROJECT MANAGEMENT 1

Conten
t◦ Software Process Maturity
◦ Software maturity Framework

◦ Principles of Software Process Change

◦ Software Process Assessment

◦ Process Reference Models

◦ Capability Maturity Model (CMM), CMMI, PCMM, PSP, TSP).
SOFTWARE PROCESS AND PROJECT MANAGEMENT 2
Introduction
◦ Software project management is the art and science
of planning and leading software projects.
◦ It comprises of a number of activities, which
contains planning of project, deciding scope of
software product, estimation of cost in various
terms, scheduling of tasks and events, and resource
management.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 3

…
Introduction
◦ It is extremely important for the following reasons:
◦ Software development is highly unpredictable

◦ Management has a greater effect on the success or failure of a

project than technology advances.
◦ Too often there is too much scrap and rework.

◦ The entire process is very immature, not enough reuse.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 4

Software Process
Maturity
◦ Software process maturity is the extent to which a
specific process is explicitly defined, managed,
measured, controlled, and effective.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 5

Software Process maturity
Framework
◦ The framework is developed at the SEI
◦ It addresses the five steps by characterizing a software process
into one of the five maturity levels.
◦ By establishing their organization’s position in this maturity
structure, software professionals and management can
more readily identify those areas where improvement
actions are most likely to produce results.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 6
The Five Maturity
Levels

SOFTWARE PROCESS AND PROJECT MANAGEMENT 7

A.
◦ It is also called “ad hoc Process”.
Initial
◦ The organization operates without formalized
procedures, cost estimates, and project
plans.
◦ If there are any formal procedures for project
control, there is no management mechanism to
ensure they are used.
◦ The best test to observe how such an organization
behaves in a crisis is, abandoning established
procedures and reverting to merely coding and
testing. SOFTWARE PROCESS AND PROJECT MANAGEMENT 8
…Initial
◦ Organizations at this level can improve their
performance by instituting basic project controls.
◦ The most important are:
◦ Project management
◦ Management oversight
◦ Quality assurance
◦ Change control
SOFTWARE PROCESS AND PROJECT MANAGEMENT 9
Project
management
◦ The fundamental role of a project management system is to ensure
effective control of commitments which requires adequate
preparation, clear responsibility, a public declaration, and a dedication
to performance.
◦ In any project, a plan must be developed to determine the
best schedule and the resources required.
◦ In the absence of such an orderly plan, no commitment can be
better than an educated guess.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 10
Management
oversight
◦ A disciplined software development organization
must have senior management oversight that review
and approve all major plans before official
commitment.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 11

Quality
assurance
◦ A quality assurance group is charged with assuring
management that the software development work is actually
done the way it is supposed to be done.
◦ To be effective, the assurance organization must have an
independent reporting line to senior management and sufficient
resources to monitor performance of all key planning,
implementation, and verification activities.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 12
Change
control
◦ To develop quality software on a predictable schedule, the
requirements must be maintained with reasonable
stability throughout the development cycle.
◦ Changes will have to be made, but must be managed
and introduced in an orderly way.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 13

B.
Repeatable
◦ The organization has achieved a stable process with a
repeatable level of statistical control by initiating
rigorous project management of commitments, cost,
schedule, and changes.
◦ This process has one important strength over the
initial process i.e. It provides commitment control.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 14
…
◦ Organizations at this level face major risks when
Repeatable
they are presented with new challenges.
◦ Examples of the changes that represent the highest
risk are:
◦ It is possible for a new technology to do more harm than good, if
there is no defined process framework.
◦ When the organization must develop a new kind of product, it is
entering new territory. These changes can be disruptive.
◦ In this level, a new manager has no orderly basis for
understanding what is going on and new team members must learn
the ropes through word of mouth.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 15
…
Repeatable
◦ The key actions required to advance from the
Repeatable Process to the Defined Process are:
◦ Establish a process group which is a technical group that focuses
exclusively on improving the software
◦ developing process. The responsibilities of process
groups include:
◦ Defining the development process,
◦ Identifying technology needs and opportunities,
◦ Conducting quarterly management that reviews
process status and performance.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 16
…
Repeatable
◦ Establish a software-development process architecture
that describes the technical and management activities
required for proper execution of the development process.
The architecture is a structural decomposition of the
development cycle into tasks, each of which has entry
criteria, fundamental descriptions, verification procedures,
and exit criteria.
◦ If they are not already in place, introduce a family
of software-engineering methods and technologies.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 17

C.
Defined
◦ To ensure consistent implementation and provide a basis for better
understanding of the process, the organization has defined the
process.
◦ At this point that the organization achieved the foundation for
major and continuing progress, advanced technology can usefully
be introduced.
◦ The development group, when faced with a crisis, will likely
continue to use the Defined Process.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 18
…
Defined
◦ The foundation has now been established for examining the process
and deciding how to improve it.
◦ As powerful as this step is, it is still only qualitative:
◦ There is little data to indicate what is going on or how effective the process really
is.
◦ There is considerable debate about the value of software process measurements and
the best ones to use.
◦ This uncertainty stems from a lack of process definition and the consequent confusion
about the specific items to be measured. With a defined process, we can focus the
measurements on specific tasks
SOFTWARE PROCESS AND PROJECT MANAGEMENT 19
…
◦ The key steps to advance to the Managed Process
Defined
are:
◦ Establish a minimum, basic set of process measurements to
identify the quality and cost parameters of each process step. The
objective is to quantify the relative costs and benefits of each
major process activity, such as the cost and yield of error detection
and correction methods.
◦ Establish a process database with the resources to manage and
maintain it. Cost and yield data should be maintained centrally to
guard against loss, to make it available for all projects, and to
facilitate process quality and productivity analysis.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 20

…
Defined
◦ Provide sufficient process resources to gather and maintain this
data and to advise project members on its use.
◦ Assign skilled professionals to monitor the quality of the data
before entry in the database and to provide guidance on analysis
methods and interpretation.
◦ Assess the relative quality of each product and inform
management where quality targets are not being met.
◦ An independent quality-assurance group should assess the quality
actions of each project and track its progress against its quality
plan.
◦ When this progress is compared with the historical experience on
similar projects, an informed assessment generally can be made.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 21
Manage
d◦ The organization has initiated comprehensive process
measurements, beyond those of cost and schedule performance.
This is when the most significant quality improvements begin.
◦ The greatest potential problem with the Managed Process is the
cost of gathering data.
◦ There are many number of potentially valuable measures of
software development and support, but such data is expensive to
gather and maintain.
◦ Process data must not be used to compare projects or individuals.
Its purpose is to illuminate the product being developed and to
provide an informed basis for improving the process.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 22
…
Managed
◦ The followings are two fundamental requirements to advance from
the Managed Process to the Optimizing Process:
◦ Support automatic gathering of process data. Some data cannot be gathered
by hand, and all manually gathered data is subject to error and omission.
◦ Analyzing and modifying the process by using this data to prevent problems
and improve efficiency.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 23

Optimizing
◦ The Process Optimization goes on at all levels of
process maturity.
◦ However, with the step from the Managed to
the Optimizing Process, there is a paradigm.
◦ Up to this point, software development managers have
largely focused on their products and will gather and
analyze data that directly relates to product
improvement.
◦ In the Optimizing Process, the data is available to
actually tune the process itself.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 24
…
Optimizing
◦ With a little experience, management will see that process optimization can
produce major quality and productivity improvements.
◦ For example, many errors can be identified and fixed far more economically
by code inspections than through testing.
◦ It takes about one to four working hours to find and fix a bug through
inspections and about 15 to 20 working hours to find and fix a bug in
a function or system test.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 25

…
Optimizing
◦ It is thus clear that testing is not a cost-effective way to find and fix most bugs.

◦ But it would be unwise to eliminate testing completely because it provides a useful

check against human errors.
◦ In the optimizing process, the organization has the means to identify the weakest elements
of the process and fix them, the data is available to justify the application of technology to
various critical tasks.
◦ The Optimizing Process provides a disciplined environment for professional work.
Discipline is required in large software projects to ensure, for example, that the people
involved use the same conventions, don’t damage each other’s products, and properly
synchronize their work.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 26
◦ There is little data on how long it takes for software organizations to advance through these maturity
levels toward the Optimizing Process. Based on author’s experience, transition from level 1 to level 2
or from level 2 to level 3 takes from one to three years, even with a dedicated management
commitment to process improvement. To date, no complete organizations have been observed at levels
4 or 5.
◦ How to use this framework? This process-maturity structure is intended to be used with an assessment
methodology and a management system. Using this framework, the SEI has developed an assessment
questionnaire and methodology.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 27

II. Principles of Software Process
Change
◦
The basic principles of software change are
Automation of Poorly Defined. The process will produce

Automation of poorly defined results

 Improvement should be made in small steps.

 Educate / Train again & again.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 28

…
Principles
◦ The Software Process management has two key areas.
◦ People:
◦ A Good mix of Talent is required
◦ The best people are always in short supply.
◦ With Proper leadership, education, training & support, most people can do better
that what currently doing.

◦ Design Methods:
◦ Quality product = Domain Knowledge + ability to produce the good design

SOFTWARE PROCESS AND PROJECT MANAGEMENT 29

Six basic principles of Software Process
change
1. Major changes to software process must start at top.
◦ It requires leadership
◦ Managers should provide good leadership, get good priorities, continue support.

2. Everyone must be involved.

◦ Within an unmatured software process, Software professionals are forced to
improvise solutions
◦ In mature process, these individual actions are structured and efficient.
◦ Need to repair the process, not the people.

3. Effective changes require the team to have common

goals and knowledge of current process.
◦ Assessment is effective way to gain this.
◦ Professionals need more help in controlling Requirements, Plans, coding with system
design issues.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 30
…
Six
4.
◦
Change is continuous.
Prevention is better than recovery.
◦ Every defect is an improve opportunity
◦ Relative changes generally make things worse.

5. Software process changes will not be retained without

conscious effort & periodic Re-enforcements.
◦ Precise and accurate work is so hard

6. Software process improvement requires investment.

◦ Someone must work in improvement
◦ Unplanned process improvement is wishful thinking.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 31

III. Software Process
Assessment
◦ A software process assessment is a disciplined examination of
the software processes used by an organization, based on a
process model.
◦ The assessment includes
◦ the identification and characterization of current practices,
◦ identifying areas of strengths and weaknesses, and
◦ the ability of current practices to control or avoid significant causes of
poor (software) quality, cost, and schedule.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 32

…Process
Assessment
◦ A software assessment can be of three types.
◦ A self-assessment (first-party assessment) is performed internally by
an
organization's own personnel.
◦ A second-party assessment is performed by an external assessment
team or the organization is assessed by a customer.
◦ A third-party assessment is performed by an external party.

◦ Software process assessments are performed in an open and

collaborative environment.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 33
Software Process Assessment
Cycle
The CMM-based assessment approach uses a six-step cycle.
1. Select a team - The members of the team should be professionals
knowledgeable in software engineering and management.
2. The representatives of the site to be appraised complete the standard
process maturity questionnaire.
3. The assessment team performs an analysis of the questionnaire
responses and identifies the areas that warrant further exploration
according to the CMM key process areas.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 34
…Assessment
Cycle
4. The assessment team conducts a site visit to gain an
understanding of the software process followed by the site.

5. The assessment team produces a list of findings that identifies the

strengths and weakness of the organization's software process.

6. The assessment team prepares a Key Process Area (KPA) profile

analysis and presents the results to the appropriate audience.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 35

…Assessment
Cycle
◦ With regard to data collection, there are four methods:

◦ The standard maturity questionnaire

◦ Individual and group interviews

◦ Document reviews

◦ Feedback from the review of the draft findings with the

assessment participants

SOFTWARE PROCESS AND PROJECT MANAGEMENT 36

Standard CMMI Assessment Method
for Process Improvement (SCAMPI)
◦ SCAMPI was developed to satisfy the CMMI
model requirements.
◦ It consists of three phases:
1. Plan and preparation

2. Conduct the assessment onsite

3. Report results
SOFTWARE PROCESS AND PROJECT MANAGEMENT 37
…
◦ The activities for the plan and preparation phase
SCAMPI
include
◦ Identify the assessment scope
◦ Develop the assessment plan
◦ Prepare and train the assessment team
◦ Make a brief assessment of participants
◦ Administer the CMMI Appraisal Questionnaire
◦ Examine the questionnaire responses
◦ Conduct an initial document review

SOFTWARE PROCESS AND PROJECT MANAGEMENT 38

…
SCAMPI
◦ The activities for the onsite assessment phase
include:
◦ Conduct an opening meeting
◦ Conduct interviews
◦ Consolidate information
◦ Prepare the presentation of draft findings
◦ Present the draft findings
◦ Consolidate, rate, and prepare the final findings

SOFTWARE PROCESS AND PROJECT MANAGEMENT 39

…
SCAMPI
◦ The activities of the reporting results phase include:
◦ Present the final findings

◦ Conduct an executive session

◦ Wrap up the assessment

SOFTWARE PROCESS AND PROJECT MANAGEMENT 40

Process Reference
Models
SOFTWARE PROCESS AND PROJECT MANAGEMENT 41
Capability Maturity
Model
◦ Capability Maturity Model is a bench-mark for measuring the
maturity of an organization’s software process, also to develop and
refine an organization’s software development process.
◦ CMM can be used to assess an organization against a scale of five
process maturity levels based on certain Key Process Areas (KPA).
◦ It describes the maturity of the company based upon the project
the company is dealing with and the clients.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 42

CM
M
◦ A maturity model provides:
◦ A place to start

◦ The benefit of a community’s prior experiences

◦ A common language and a shared vision

◦ A framework for prioritizing actions

◦ A way to define what improvement means for your organization

SOFTWARE PROCESS AND PROJECT MANAGEMENT 43
CM
M
◦ There are five maturity
levels as shown below…
◦ Initial

◦ Managed

◦ Defined

◦ Quantitatively Managed

◦ Optimizing

SOFTWARE PROCESS AND PROJECT MANAGEMENT 44

CM
M
◦ Maturity levels consist of a predefined set of process areas. The maturity
levels are measured by the achievement of the specific and generic goals that
apply to each predefined set of process areas.
◦ Maturity Level 1 – Initial: Company has no standard process for software
development. Nor does it have a project-tracking system that enables
developers to predict costs or finish dates with any accuracy.
◦ Maturity Level 2 – Managed: Company has installed basic
software management processes and controls. But there is no
consistency or coordination among different groups.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 45
CM
Mand controls for the entire organization so that developers can move between projects
◦ Maturity Level 3 – Defined: Company has pulled together a standard set of processes

more easily and customers can begin to get consistency from different groups.
◦ Maturity Level 4 – Quantitatively Managed: In addition to implementing standard
processes, company has installed systems to measure the quality of those
processes across all projects.
◦ Maturity Level 5 – Optimizing: Company has accomplished all of the above and can
now begin to see patterns in performance over time, so it can tweak its processes in
order to improve productivity and reduce defects in software development across the
entire organization.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 46

Capability Maturity Model
Integration (CMMI)
◦ The CMMI helps organizations streamline process
improvement, encouraging a productive, efficient
culture that decreases risks in software, product and
service development.
◦ It starts with an appraisal process that evaluates
three specific areas:
◦ process and service development,
◦ service establishment and management, and
◦ product and service acquisition.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 47

CMM
I◦ It’s designed to help improve performance by providing businesses with
everything they need to consistently develop better products and services.
◦ But the CMMI is more than a process model; it’s also a behavioral model.

◦ Businesses can use the CMMI to tackle the logistics of improving

performance by developing measurable benchmarks, but it can also create a
structure for encouraging productive, efficient behavior throughout the
organization

SOFTWARE PROCESS AND PROJECT MANAGEMENT 48

Standard CMMI Appraisal Method
for Process Improvement (SCAMPI)
◦ SCAMPI is the official appraisal method used by the CMMI institute.

◦ It is outlined in the SCAMPI Method Definition Document, which

is included in the CMMI appraisal reference documents.
◦ The goal of the CMMI is to create reliable environments, where
products, services and departments are proactive, efficient and
productive.
◦ There are three appraisal classes: Class A, B and C.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 49

SCAMPI
A
◦ The most rigorous appraisal method, SCAMPI A is most
useful after multiple processes have been implemented.
◦ It provides a benchmark for businesses and is the only level that
results in an official rating.
◦ It must be performed by a certified lead appraiser, who is part of
the on-site appraisal team.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 50

SCAMPI B
◦ This appraisal is less formal than SCAMPI A; it helps
find a target CMMI maturity level, predict success for
evaluated practices and give the business a better idea of
where they stand in the maturity process.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 51

SCAMPI
C◦ This appraisal method is shorter, more flexible and less expensive
than Class A or B.
◦ It’s designed to quickly assess a business’s established practices and
how those will integrate or align with CMMI practices.
◦ It can be used at a high-level or micro-level, to address
organizational issues or smaller process or departmental issues.
◦ It involves more risk than Class A or B, but it’s more cost-
effective. SOFTWARE PROCESS AND PROJECT MANAGEMENT 52
CMMI’s five Maturity
Levels
1. Initial - Processes are viewed as unpredictable and reactive. At this stage,
“work gets completed but it’s often delayed and over budget.”

2. Managed: There’s a level of project management achieved. Projects are

“planned, performed, measured and controlled” at this level, but there
are still a lot of issues to address.

3. Defined: At this stage, organizations are more proactive than reactive.

There’s a set of “organization-wide standards” to “provide guidance across
projects, programs and portfolios.”
SOFTWARE PROCESS AND PROJECT MANAGEMENT 53
…CMMI
Levels
4. Quantitatively managed: This stage is more measured and controlled.
The organization is working off quantitative data to determine predictable
processes that align with stakeholder needs. The business is ahead of risks,
with more data-driven insight into process deficiencies.
5. Optimizing: Here, an organization’s processes are stable and flexible. At
this final stage, an organization will be in constant state of improving
and responding to changes or other opportunities. The organization is
stable, which allows for more “agility and innovation,” in a predictable
environment.
SOFTWARE PROCESS AND PROJECT MANAGEMENT 54
People Capability Maturity Model
(PCMM)
◦ PCMM is a maturity structure that focuses on continuously improving the
management and development of the human assets of an organization.
◦ It defines an evolutionary improvement path from Adhoc, inconsistently
performed practices, to a mature, disciplined, and continuously improving
the development of the knowledge, skills, and motivation of the workforce
that enhances strategic business performance.
◦ PCMM is a framework that helps the organization successfully address
their critical people issues
SOFTWARE PROCESS AND PROJECT MANAGEMENT 55
Personal Software Process
(PSP)
◦ PSP is a series of defined processes that allow software engineers to
produce high-quality products on time and within budget.
◦ PSP shows engineers how to:
 Manage the quality of their projects

 Make commitments they can meet

 Improve estimating and planning

 Reduce defects in their products

SOFTWARE PROCESS AND PROJECT MANAGEMENT 56

Team Software Process
(TSP)
◦ TSP along with the Personal Software Process helps
the high-performance engineer to:
 Ensure quality software products

 Create secure software products

 Improve process management in an organization.

SOFTWARE PROCESS AND PROJECT MANAGEMENT 57

 Many
thanks
SOFTWARE PROCESS AND PROJECT MANAGEMENT 58