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

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.

Process Improvement Cycle

Elements of a SPI Framework

Other SPI Frameworks

SPICE

Bootstrap

PSP and TSP

Tick IT

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

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.

Four levels of Immaturity

Schorsch suggests four levels of immaturity

Level 0: Negligent– failure to allow processesLevel 1: Obstructive– counterproductive processes are imposedLevel 2: Contemptuous– disregard for good software engineeringLevel 3: Undermining– total neglect of own charter

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.

The SPI Process—I

Five activitiesAssessment 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.

The SPI Process—IIEducation 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.

The SPI Process—III

Selection and Justificationchoose 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.

The SPI Process—IVInstallation/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.

The SPI Process—VEvaluation

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.

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

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

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.

SEI Capability Maturity Model

Initial

Optimizing

Managed

Defined

Repeatable

Basic Management Control

Process Definition

Process Measurement

Process Control

45%

30%

< 1%

20%

2-3%

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

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

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

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

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.