SPI (software process improvement) aims to define an organization's software development process and improve it over time. Key aspects of SPI include assessing an organization's current process, identifying areas for improvement, and implementing changes. Several frameworks exist to guide SPI efforts, including maturity models that assess a process across different levels of definition and management. Successful SPI requires management commitment, staff involvement, and customizing activities to an organization's unique needs and goals.

1. What is SPI?
SPI implies that elements of an effective software process can be defined in an effective manner an existing
organizational approach to software development and a meaningful strategy for improvement can be
defined.
The SPI strategy transforms the existing approach to software development into something that is more
focused, more repeatable, and more reliable
SPI implies a defined software process, an organizational approach, and a strategy for
improvement

2. Approaches to SPI
• a set of characteristics that must be present if an effective software process is
to be achieved
• a method for assessing whether those characteristics are present
• a mechanism for summarizing the results of any assessment, and
• a strategy for assisting a software organization in implementing those
process characteristics that have been found to be weak or missing.
• An SPI framework assesses the “maturity” of an organization’s software
process and provides a qualitative indication of a maturity level.

3. Process Improvement Cycle

4. Elements of a SPI Framework

5. Other SPI Frameworks
SPICE
Bootstrap
PSP and TSP
Tick IT

6. Constituencies
Quality certifiers
Quality(Process) --> Quality(Product)
Formalists: process modeling languages
Tool advocates
Practitioners: little formal process modeling
Reformers: organizational change
Ideologists: particular SP for specific organization

7. Maturity Models
A maturity model is applied within the context of an SPI
framework.
The intent of the maturity model is to provide an overall
indication of the “process maturity” exhibited by a software
organization.
an indication of the quality of the software process, the
degree to which practitioner’s understand and apply the
process,
the general state of software engineering practice.

8. Four levels of Immaturity
Schorsch suggests four levels of immaturity
Level 0: Negligent– failure to allow processes
Level 1: Obstructive– counterproductive processes are imposed
Level 2: Contemptuous– disregard for good software engineering
Level 3: Undermining– total neglect of own charter

9. Is SPI for Everyone?
Can a small company initiate SPI activities and do it
successfully?
Answer: INDEED, they can as it is a good practice.
It should come as no surprise that small organizations are
more informal, apply fewer standard practices, and tend to
be self-organizing.

10. The SPI Process—I
Five activities
Assessment and Gap Analysis
Assessment examines a wide range of actions and tasks that will lead to a high
quality process.
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?
Gap analysis—The difference between local application and best practice represents
a “gap” that offers opportunities for improvement.

11. The SPI Process—II
Education and Training
Three types of education and training should be conducted:
1. Generic concepts and methods.
2. Specific technology and tools.
3. Business communication and quality-related topics.

12. The SPI Process—III
Selection and Justification
choose the process model that best fits your
organization, its stakeholders, and the software that
you build decide on the set of framework activities
that will be applied, the major work products that will
be produced and the quality assurance checkpoints
that will enable your team to assess progress
develop a work breakdown for each framework
activity defining the task set that would be applied for
a typical project
Once a choice is made, time and money must be
expended to install it within an organization and these
resource expenditures should be justified.

13. The SPI Process—IV
Installation/Migration
Scacchi [Sca00] states that “SPR is concerned with
identification, application, and refinement of new
ways to dramatically improve and transform software
processes.”
three different process models are considered:
the existing (“as-is”) process,
a transitional (“here-to-there”) process, and
the target (“to be”) process.

14. The SPI Process—V
Evaluation
assesses the degree to which changes have been
instantiated and adopted,
the degree to which such changes result in better
software quality or other tangible process benefits,
and
the overall status of the process and the
organizational culture as SPI activities proceed
From a qualitative point of view, past management
and practitioner attitudes about the software process
can be compared to attitudes polled after installation
of process changes.

15. Risk Management for SPI
In general, the following categories can be identified for SPI risk factors:
o budget and cost
o content and deliverables culture
o maintenance of SPI deliverables
o mission and goals
o organizational management and organizational stability
o process stakeholders
o schedule for SPI development
o SPI development environment and process
o SPI project management and SPI staff

16. Critical Success Factors
The top five CSFs are :
Management commitment and support
Staff involvement
Process integration and understanding
A customized SPI strategy
A customized SPI strategy

17. The CMMI model
An integrated capability model that includes software and systems engineering capability assessment.
The model has two instantiations
Staged where the model is expressed in terms of capability levels;
Continuous where a capability rating is computed.

18. SEI
Capability Maturity Model
Initial
Optimizing
Managed
Defined
Repeatable
Process Control
Process Measurement
Process Definition
Basic Management Control
45%
30%
< 1%
20%
2-3%

19. CMM - Initial (Level 1)
•The software process is characterized as ad hoc, occasionally even chaotic
•Few processes are defined
•Success depends on individual effort and heroics

20. CMM - Repeatable (Level 2)
•Basic project management processes are established to track
cost, schedule, and functionality
•The necessary process discipline is in place to repeat earlier
successes on projects with similar applications
•Success achieved through basic project management; not
advanced technologies

21. CMM - Defined (Level 3)
•The software process for both management and engineering
activities is documented, standardized, and integrated into a
standard software process for the organization
•All projects use an approved, tailored version of the
organization’s standard software process for developing and
maintaining software
•Formality lends itself to improvement

22. CMM - Managed (Level 4)
•Detailed measures of the software process and product
quality are collected
•Both the software process and products are quantitatively
understood and controlled
•A software metrics program is in use

23. Summary Regarding SPI
• SPI is an ongoing effort; your process will evolve over time.
• You need to invest in, and support, SPI efforts for them to be successful.
• The goal of SPI is to ensure that your organization can define, implement, and
evolve one or more appropriate processes to help you meet your IT goals.
• There are many proven software processes; one or more of them will likely help
you to meet your needs.
• Your software process must be tailored to reflect your organization's strengths,
weaknesses, culture, and business needs.