Software Process Improvement (SPI)

by Ronni Kahalani, Copenhagen School of Design & Technology.

With inspiration from the book Software Engineering - A Practitioner's Approach.

​

A set of activities that lead to better software processes and

higher quality software delivered in a timelier manner.

​

Who am I?

Thank you for stopping by.

​

I’m Ronni. I hope you’re well and wish you a safe and worthy journey.

​

This presentation is part of the Software Engineering Series, from my lectures at Copenhagen School of Design & Technology.

​

You can view the Introducing Myself, if you want to know a little more about who I am.

​

All my presentations and materials are free and available at my blog post: Software Engineering.

​

​

Don’t let me uphold you,

continue your journey, go to next slide.

2

X /Twitter

@RonniKahalani

�LinkedIn

https://www.linkedin.com/in/kahalani/

�Blog�LearningIsLiving

Agenda

• Intro
• Quick Look
• What Is SPI?
• The SPI Process
• The CMMI
• Other SPI Frameworks
• SPICE
• TickIT Plus
• Spi Return On Investment
• Spi Trends
• Summary

Intro

Extend your understanding of software engineering.

The following questions are addressed in the chapters that follow:

• What is software process improvement and how can it be used to improve the state of software engineering practice?
• What emerging trends can be expected to have a significant influence on software engineering practice in the next decade?
• What is the road ahead for software engineers?

Once these questions are answered, you'll understand topics that may have a profound impact on software engineering in the years to come.

Intro

Long before the phrase "software process improvement" was widely used, Roger S. Pressman (RSP), worked with major corporations in an attempt to improve the state of their software engineering practices.

• As a consequence of his experiences, he wrote the book entitled:

“Making Software Engineering Happen”

​

“For the past ten years I have had the opportunity to help a number of large companies implement software engineering practices. The job is difficult and rarely goes as smoothly as one might like - but when it succeeds, the results are profound...”

Intro

But all is not sweetness and light.

• Many companies give up in frustration
• Others do it half-way and never see the benefits
• Still others do it in a heavy-handed fashion that results in open rebellion among technical staff and managers and subsequent loss of morale

​

Even though these words were written almost three decades ago, they remain equally true today.

Quick Look

• What is it?
• Set of activities that will lead to a better software process
• Therefore, higher quality software delivered in a timelier manner
• Who does it?
• Technical managers
• Software engineers
• Individuals who have quality assurance responsibility
• Why is it important?
• An organization must address weaknesses in their existing process and work to improve their approach to software work

​

Quick Look

• What are the steps?
• SPI is iterative and continuous - It can be viewed in 5 steps:
• Assessment of the current software process
• Education and training of practitioners and managers
• Selection and justification of process elements, software engineering methods, and tools
• Implementation of the SPI plan
• Evaluation and tuning based on the results of the plan
• What is the work product?
• Improved software process that leads to higher quality software
• How do I ensure that I've done it right?
• Software delivered with fewer defects
• Rework at each stage will be reduced
• On-time delivery will become much more likely

What Is SPI?

Continually reducing waste, problems, defects, maintenance- and support costs and alike.

What Is SPI?

SPI…the term…implies many things…

• It implies that elements of an effective software process can be defined in an effective manner
• That an existing organizational approach to software development can be assessed against those elements
• That a meaningful strategy for improvement can be defined

​

Transforms the existing approach to software development into something that is more…

• Focused
• Repeatable
• Reliable

What Is SPI?

Because SPI is not free, it must deliver a return on investment.

​

The results of improved process and practice must lead to reduce…

• Software "problems" that cost time and money
• Number of defects that are delivered to end users
• Amount of rework due to quality problems
• Costs associated with software maintenance and support
• Indirect costs that occur when software is delivered late

Approaches to SPI

Although an organization can choose a relatively informal approach to SPI, the vast majority choose one of several SPI frameworks.

SPI framework defines:

• Set of characteristics that must be present if an effective software process is to be achieved
• Method for assessing whether those characteristics are present
• Mechanism for summarizing the results of any assessment
• Strategy for assisting a software organization in implementing those process characteristics that have been found to be weak or missing

Process Assessment in SPI

• Software process is examined by Assessment.
• Assessment leads to Capability determination and Improvement strategy
• Capability determination is a foundation for Improvement strategy
• Capability determination identifies maturity of capabilities, strengths and weaknesses of Software process
• Improvement strategy suggests improvement approach and identifies changes to Software process

Approaches to SPI

An SPI framework assesses the "maturity" of an organization’s software process and provides a qualitative indication of a maturity level.

​

Note: There is no universal SPI framework.

​

As applied, the sponsoring constituency must establish mechanisms to:

• Support technology transition
• Determine the degree to which an organization is ready to absorb process changes that are proposed
• Measure the degree to which changes have been adopted

Maturity Models

The intent of the maturity model is to provide an overall indication of the "process maturity" exhibited by a software organization.

That is…

• An indication of the quality of the software process
• The degree to which practitioners understand and apply the process
• The general state of software engineering practice

​

Example

The Software Engineering Institute's original Capability Maturity Model suggests 5 levels of maturity ranging from initial to optimized.

Is SPI for Everyone?

For many years, SPI was viewed as a "corporate" activity.

• But today, a significant percentage of all software development is being performed by companies that employ fewer than 100 people.

​

Can a small company initiate SPI activities and do it successfully?

• Within small organizations the implementation of an SPI framework requires resources that may be in short supply
• Managers must allocate people and money to make software engineering happen

Therefore, regardless of the size of the software organization, it's reasonable to consider the business motivation for SPI.

If it feels like overkill, it probably is…

The SPI Process

Initiating, diagnosing, establishing, acting, and learning.

The SPI Process

The hard part of SPI isn't the definition of characteristics that define a high-quality software process or the creation of a process maturity model.

• The hard part is establishing a consensus for initiating SPI and defining an ongoing strategy for implementing it

​

The Software Engineering Institute has developed IDEAL.

“An organizational improvement model that serves as a road map�for initiating, planning, and implementing improvement actions”

​

Defining 5 distinct activities that guide through SPI activities:

• Initiating, diagnosing, establishing, acting, and learning

The SPI Process

Here is a different road map for SPI, based on the process model for SPI originally proposed.

​

It applies a commonsense philosophy that requires an organization to…

• Look in the mirror
• Then get smarter so it can make intelligent choices
• Select the process model (and related technology elements) that best meets its needs
• Instantiate the model into its operating environment and its culture
• Evaluate what has been done

​

These 5 activities are applied in an iterative manner in an effort to foster continuous process improvement.

Assessment and Gap Analysis

Stated simply, before you begin any journey, it's a good idea to know precisely where you are.

Assessment examines a wide range of actions and tasks that will lead to a high-quality process.

• The intent is to uncover both strengths and weaknesses

​

The software organization must establish generic mechanisms such as:

• Defined approaches for customer communication
• Established methods for representing user requirements
• A project management framework that includes scoping, estimation, scheduling, and project tracking
• Risk analysis methods
• Change management procedures
• Quality assurance and control activities including reviews

…and many others

Assessment and Gap Analysis

Each is assessed to determine whether all the following questions have been addressed.

• Is the objective of the activity clearly defined?
• Are work products required as input and produced as output identified and described?
• Are the work tasks to be performed clearly described?
• Are the people who must perform the activity identified by role?
• Have entry and exit criteria been established?
• Have metrics for the activity been established?
• Are tools available to support the activity?
• Is there an explicit training program that addresses the activity?
• Is the activity performed uniformly for all projects?

Assessment and Gap Analysis

As the process assessment is conducted, focus on the following issues:

• Consistency: Are important activities, actions, and tasks applied consistently across all software projects and by all software teams?�
• Sophistication: Are management and technical actions performed with a level of sophistication that implies a thorough understanding of best practice?�
• Acceptance: Is the software process and software engineering practice widely accepted by management and technical staff?�
• Commitment: Has management committed the resources required to achieve consistency, sophistication, and acceptance?

​

These indicates the amount of cultural change that will be required to achieve meaningful improvement.

Education and Training

A key element of any SPI strategy is education and training for practitioners, technical managers, and more senior managers who have direct contact with the software organization.

​

3 types of education and training should be conducted:

• Generic software engineering concepts and methods
• Specific technology and tools
• Communication and quality-oriented topics

​

In a modern context, education and training can be delivered in a variety of different ways.

• Podcasts, YouTube videos, Internet-based training, e-books and classroom courses can be offered as part of an SPI strategy.

Selection and Justification

Once the initial assessment activity has been completed and education has begun, a software organization should begin to make choices.

​

Methods and tools are chosen to populate the software process.

Decide…

• Which of the set of framework activities will be applied
• Major work products that will be produced
• Quality assurance checkpoints that will enable your team to assess progress

​

If the SPI assessment activity indicates specific weaknesses (e .g., you have no formal SQA functions), you should focus attention on process characteristics that will address these weaknesses directly.

Selection and Justification

Develop an adaptable work breakdown for each frame work activity.

• Defining the task set that would be applied for a typical project
• Also consider the software engineering methods that can be applied to achieve these tasks

​

As choices are made, education and training should be coordinated to ensure that understanding is reinforced.

​

Selection and Justification

Be sure to consider the culture of the organization and the level of acceptance that each choices will likely elicit.

• It is often difficult to achieve consensus among different constituencies

​

It is true that a bad choice can do more harm than good, but "paralysis by analysis" means that little if any progress occurs and process problems remain.

​

…it's sometimes better to pull the trigger and make a choice, rather than waiting for the perfect solution.

Installation/Migration

Installation is the 1^st point at which a software organization feels the effects of changes triggered by following the SPI road map.

​

• In some cases, an entirely new process is recommended for an organization
• Such changes represent a substantial organizational and technological transition and must be managed very carefully
• In other cases, changes associated with SPI are relatively minor, representing small, but meaningful modifications to an existing process model
• Often referred to as process migration
• Many software organizations have a "process" in place, but the problem is that it doesn't work in an effective manner.
• Therefore, an incremental migration from one process to another process is a more effective strategy

Installation/Migration

Installation and migration are actually software process redesign (SPR) activities.

“SPR is concerned with identification, application, and refinement of new ways�to dramatically improve and transform software processes .”

…stated by Scacchi

When a formal approach to SPR is initiated, 3 different process models are considered:

• Existing "as is" process
• Transitional "here to there" process
• Target "to be" process

​

If the target process is significantly different from the existing process, the only rational approach to installation is an incremental strategy.

– Small changes over time.

Evaluation

Although it is listed as the last activity in the SPI road map, evaluation occurs throughout SPI.

​

Assesses the…

• degree of changes that have been instantiated and adopted
• degree of changes which result in better software quality or other tangible process benefits
• overall status of the process and the organizational culture as SPI activities proceed

​

Both qualitative factors and quantitative metrics are considered during the evaluation activity.

Risk Management for SPI

In fact, more than half of all SPI efforts end in failure.

Risk Management for SPI

SPI often fails because risks were not properly thought through and no contingency planning occurred.

“In fact, more than half of all SPI efforts end in failure”

​

Among the most common risks are:

• lack of management support
• cultural resistance by technical staff
• poorly planned SPI strategy
• overly formal approach to SPI
• selection of inappropriate processes

• lack of buy-in by key stakeholders
• inadequate budget
• lack of staff training
• organizational instability
• …and a myriad of other factors

Risk Management for SPI

A software organization should manage risk at 3 key points.

• Prior to the initiation of the SPI road map
• During the execution of SPI activities (assessment, education , selection, installation)
• During the evaluation activity that follows the instantiation of some process characteristic

SPI risk factor categories:

• Process stakeholders
• Schedule for SPI development
• SPI development environment
• SPI development process
• SPI project management
• SPI staff

• Budget and cost
• Content and deliverables
• Culture
• Maintenance of SPI deliverables
• Mission and goals
• Organizational management
• Organizational stability

Risk Management for SPI

Within each category, a number of generic risk factors can be identified.

​

Example:

The organizational culture has a strong bearing on risk.

​

Generic Risk Factors:

• Attitude toward change, based on prior efforts to change
• Experience with quality programs, level of success
• Action orientation for solving problems versus political struggles
• Use of facts to manage the organization and business
• Patience with change; ability to spend time socializing

…continues on next slide…

Risk Management for SPI

• Tools orientation-expectation that tools can solve the problems
• Level of "planfulness" - ability of organization to plan
• Ability of organization members to participate with various levels of organization openly at meetings
• Ability of organization members to manage meetings effectively
• Level of experience in organization with defined processes

​

Using the risk factors and generic attributes as a guide, a risk table (Chapter 26) can be developed to isolate those risks that warrant further management attention.

CMMI - Capacity Maturity Model Integration

A complete SPI framework developed by the Software Engineering Institute since 1990s.

​

CMMI represents a process meta-model in 2 different models, as a:

• Continuous model
• Staged model

Describes a process in 2 dimensions

• Each process area is formally assessed against specific goals and practices.
• Rated according to the capability levels.

CMMI Capability Level

Software Process Improvement (SPI)

• A maturity model is applied within the context of an SPI framework.
• The intent is to provide an overall indication of the “process maturity” exhibited by the software organization.
• An indication of the quality of the software process, the degree to which the practitioners understand and can apply the process.
• The general state of process maturity practice.

Helps increase Productivity and reduce Time to market and Defect reports.

Capacity Maturity Model Integration (CMMI)

Process Areas

CMMI Divides the process in to 22 different process-areas

​

Project Management

• Supplier Agreement Management (SAM)
• Integrated Project Management (IPM)
• Project Monitoring and Control (PMC)
• Project Planning (PP)
• Quantitative Project Management (QPM)
• Requirements Management (REQM)
• Risk Management (RSKM)�

Engineering

• Product Integration (PI)
• Requirements Development (RD)
• Technical Solution (TS)
• Validation (VAL)
• Verification (VER)�

Process Management

• Org. Performance Management (OPM)
• Org. Process Definition (OPD)
• Org. Process Focus (OPF)
• Org. Process Performance (OPP)
• Org. Training (OT)�

Support

• Causal Analysis and Resolution (CAR)
• Configuration Management (CM)
• Decision Analysis and Resolution (DAR)
• Measurement and Analysis (MA)
• Process and Product Quality Assurance (PPQA)

​

Maturity Levels

0 – Incomplete

Work may or may not get completed.

​

1 – Initial

This level contains no process areas.

​

2 – Managed (Basic Product Management)

• Supplier Agreement Management (SAM)
• Project Monitoring and Control (PMC)
• Project Planning (PP)
• Process and Quality Assurance (QA)
• Requirements Management (REQM)
• Configuration Management (CM)
• Measurement and Analysis (MA)

​

3 – Defined (Process Standardization)

• Technical Solution (TS)
• Verification (VER)
• Org. Training (OT)
• Integrated Project Management (IPM)
• Integrated Teaming
• Requirements Development (RD)
• Validation (VAL)
• Decision Analysis and Resolution (DAR)
• Org. Process Definition (OPD)
• Product Integration (PI)
• Regulatory Process Focus
• Risk Management
• Org. Process Focus (OPF)

​

4 – Quantitatively Managed

• Org. Process Performance (OPP)
• Quantitative Project Management (QPM)

​

5 – Optimizing (Continuously)

• Causal Analysis and Resolution (CAR)
• Corporate Performance Management

CMMI - Capability Levels

• Level 0: Incomplete - The process area (e .g., requirements management) is either not performed or does not achieve all goals and objectives defined by the CMMI for level 1 capability for the process area.
• Level 1: Performed - All the specific goals of the process area (as defined by the CMMI) have been satisfied. Work tasks required to produce defined work products are being conducted.
• Level 2: Managed - All capability level 1 criteria have been satisfied. In addition, all work associated with the process area conforms to an organizationally defined policy; all people doing the work have access to adequate resources to get the job done; stakeholders are actively involved in the process area as required; all work tasks and work products are "monitored, controlled, and reviewed; and are evaluated for adherence to the process description".

CMMI - Capability Levels

Capability levels:

• Level 3: Defined - All capability level 2 criteria have been achieved. In addition, the process is "tailored from the organization's set of standard processes according to the organization's tailoring guidelines, and contributes work products, measures, and other process-improvement information to the organizational process assets.
• Level 4: Quantitatively managed - All capability level 3 criteria have been achieved. In addition, the process area is controlled and improved using measurement and quantitative assessment. Quantitative objectives for quality and process performance are established and used as criteria in managing the process.
• Level 5: Optimized - AII capability level 4 criteria have been achieved. In addition, the process area is adapted and optimized using quantitative (statistical) means to meet changing customer needs and to continually improve the efficacy of the process area under consideration.

CMMI

The CMMI defines each process area in terms of "specific goals" and the "specific practices" required to achieve these goals.

• Specific practices refine a goal into a set of process-related activities

​

In addition, the CMMI also defines a set of 5 generic goals and related practices for each process area.

• Each of the 5 generic goals corresponds to one of the 5 capability levels

​

Relation between maturity levels and process area - See Figure 28.3

CMMI - People CMM

A software process, no matter how well conceived, will not succeed without talented, motivated software people.

• People CMM – Suggests practices that continuously improve the workforce competence and culture

​

The goal of the People CMM is…

• To encourage continuous improvement of generic workforce knowledge (called "core competencies")
• Specific software engineering and project management skills�(called "workforce competencies")
• Process-related abilities

Other SPI Frameworks

Although the SEI's CMM and CMMI are the most widely applied SPI frameworks, several alternatives have been proposed and are in use.

​

• SPICE - Software Process Improvement and Capability dEtermination
• The purpose of SPICE was to provide a framework to assess a process and provide information on the strengths, weakness and capabilities to help an organization achieve its goal. – Chapter 28.4.1

​

• TickIT Plus
• A generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides.
• Ticklt can be used throughout the “plan-do-check-act“ (PDCA) cycle to ensure that SPI progress is being made – ISO9001:2015 - Chapter 28.4.2

SPI Return on Investment

SPI is hard work and requires substantial investment of dollars and people. A manager will ask the question:

"How do I know that we'll achieve a reasonable return for the money we're spending?"

​

They contend that improved process will result in...

• implementation of better -quality filters (resulting in fewer propagated defects)
• better control of change (resulting in less project chaos)
• less technical rework (resulting in lower cost and better time-to-market)

​

But can these qualitative benefits be translated into quantitative results?

The classic return on investment (ROI) equation is:

SPI Return on Investment

Benefits

• Include the cost savings associated with higher product quality (fewer defects), less rework, reduced effort associated with changes, and the income that accrues from shorter time-to-market.�

Costs

• Include both direct SPI costs (e .g., training, measurement) and indirect costs associated with greater emphasis on quality control and change management activities and more rigorous application of software engineering methods (e .g., the creation of a design model).

​

In the real world, these quantitative benefits and costs are sometimes difficult to measure with accuracy, and all are open to interpretation.

• But that doesn’t mean that a software organization should conduct an SPI program without careful analysis of the costs and benefits that accrue.

SPI Trends

David Rico - Reports that a typical application of an SPI framework such as the SEI CMM can cost between $25,000 and $70,000 per person and take years to complete!

​

• It should come as no surprise that the future of SPI should emphasize a less costly and time-consuming approach
• To be effective in the twenty-first-century world of software development, future SPI frameworks must become significantly more agile.
• SPI efforts should focus on the project level, working to improve a team process in weeks, not months or years

Summary

The goal is to improve process quality and, as a consequence, improve software quality and timeliness.

• Assessment is the tool that allows a software organization to develop an overall SIP plan

To successfully improve its software process, an organization must exhibit the following characteristics:

• Management commitment and support for SPI
• Staff involvement throughout the SPI process
• Process integration into the overall organizational culture
• An SPI strategy that has been customized for local needs
• Solid management of the SPI project

Questions?

Anything? What’s on your mind? Come on ask me anything…

​

Feedback?

Thank you for your precious time.

I hope it was worth it and would love to get your feedback.

​

Please share your feedback here