Software Process Improvement

(1)

Software Process Improvement

Dr. Marcello Visconti Departamento de Informática

Universidad Técnica Federico Santa María Valparaíso, Chile

Motivation

♦ Immaturity of software engineering - state of the

practice

♦ 3 critical factors: people, technology, and process

-main drivers of costs, schedules, productivity and software quality

♦ Basic principle: improve software product quality by

improving software process quality

♦ Capability - maturity measurement - predictor of

(2)

Universidad Técnica Federico Santa María, Chile Dr. Marcello Visconti

Motivation

♦ Important: differentiate change and process

improvement

♦ Important question: ¿what is the return on

software process improvement?

♦ Need for metrics and methods

♦ Difficulty of measuring certain aspects: lower

risks, productivity, quality increase, client satisfaction, and of associating return on

investment to software engineering process and technology

Goals

♦ Understand the present state of software engineering

practice and management in an organization

♦ Select improvement areas where the changes may mean

the highest long-term benefits

♦ Focus on adding value to business, not on achieving a

process utopia

♦ Prosper combining effective process with prepared,

(3)

Change possible

INCENTIVES SKILLS

VISION RESOURCES ACTION_PLAN CHANGE

INCENTIVES

SKILLS RESOURCES ACTION_PLAN CONFUSION

INCENTIVES

VISION RESOURCES ACTION_PLAN ANSIETY

SKILLS

VISION RESOURCES ACTION_PLAN GRADUAL

CHANGE

INCENTIVES SKILLS

VISION ACTION_PLAN FRUSTRATION

INCENTIVES SKILLS

VISION RESOURCES _FALSE

STARTS

10 traps to avoid

♦ Lack of high level commitment

♦ Unreal expectations from high level management

♦ Leaders who don´t assign the resources

♦ Inadecuate training

♦ Achieving a given model level is the goal

♦ Ill-applied at the micro level

♦ Ineffective evaluations

♦ Action plan implementation delay

♦ Process improvement becomes a game

(4)

Requisites

♦ Intelligent, trained, creative engineers and managers

♦ Effective team work

♦ Shared culture focused towards quality ♦ Clear improvement goals

♦ Metrics to control progress

♦ Honest evaluation of problem areas

♦ Time to select, pilot, and implement improved process ♦ Consistent high level leaderships and expectations ♦ Everyone involved in improvement efforts

♦ Common sense, combined with a commitment to improve

Software Engineering Institute

♦ Founded by the Department of Defense (USA), at

Carnegie Mellon University, in 1984

♦ First director: Watts Humphrey

♦ Goal: to establish standards of excellence in

software engineering and acelerate the transition of advanced technology and methods to practice

(5)

Software Engineering Institute

♦ Important result: Software Process Maturity

Model - developed to evaluate the capabilities of a software organization and identify the most

important improvement areas - considering the complete process of software development as a process that can be controled, measured and improved

SEI’s maturity model

♦ 5 level model (presented in 1987)

> initial (ad hoc/caotic)

> repeatable (intuitive)

> defined (qualitative)

> managed (quantitative)

> optimizing (feedback)

♦ Each level establishes an intermediate set of goals to achieve

the next higher level of maturity

(6)

Capability Maturity Model (CMM)

♦ Decompose each maturity level in key process areas

(KPA), key practices, and key indicators

♦ Key process areas: goals to be reached to get to a

particular maturity level

♦ Key practices: procedures and activities that

contribute to reach the goals

♦ Key indicators: help in the determination of goal

satisfaction, they form the basis for assessment procedure

Capability Maturity Model (CMM)

♦ De-emphasizes score (maturity level) out of an

assessment - final product is now a profile of key process areas, indicating their level of satisfaction

♦ The maturity level is established as that in which

(7)

Capability Maturity Model (CMM)

♦ CMM version 1.0: initial release, 1991-1992

♦ CMM version 1.1: 1993 (current)

♦ CMM version 2: released in 1996, then stopped

♦ Framework hasn’t changed, new versions improve

the structure of key process areas, practices, indicators, and improve the questionnaire

♦ Extension to CMM family and CMMI

Capability Maturity Model (CMM)

♦

Level 1 - KPA

(8)

Capability Maturity Model (CMM)

♦

Level 2 - KPA

> requirements management

> software project planning

> software project oversight and tracking

> software subcontract management

> software quality assurance

> software configuration management

Capability Maturity Model (CMM)

♦

Level 3 - KPA

> organizational process focus

> organizational process definition

> training program

> integrated software administration

> software product engineering

> intergroup coordination

(9)

Capability Maturity Model (CMM)

♦

Level 4 - KPA

> process quantitative management

> software quality management

Capability Maturity Model (CMM)

♦

Level 5 - KPA

> defect prevention

> management of technology change

(10)

Capability Maturity Model (CMM)

♦ Development of CBA-IPI, CMM-based appraisal

for internal process improvement

♦ It has emphasized identification of problems and

improvement actions over the numerical score

♦ It lacks conclusive validation; preliminary data are

favorable (high ROI)

♦ It has become a de facto standard in the

software industry (USA)

(11)

State of the practice

(12)

State of the practice

(13)

State of the practice

(14)

CMM Projections

♦ USA: level 3 minimum established by Department

of Defense for its contractors

♦ Relation CMM - ISO 9000: ¿CMM level 3 implies

certification ISO 9001? ¿ and viceversa?

♦ CMM -> SW-CMM -> CMMI

♦ CMM family

1994 1995 1996 1997 1998 .... 2000

SQA & Doc. Maturity models INTEC Project SPIN-CHILE S:PRIME Assessments ISO-9000 Certification Initiative First 2 companies certified ISO First results

(15)

S:PRIME Assessments

♦ S:PRIME approach

> Based on

• SEI’s Taxonomy-Based Risk Identification

• Levels 2 and 3 of CMM plus Customer service and Corporate culture

> Designed especially for small and medium size

organizations (between 10 and 100 professionals)

> Required effort is 10 times less than CMM (CBA/IPI)

> Uses 2 questionnaires: risks and practices

♦ Agreement INTEC Chile - ASEC (CRIM, Canada)

♦ Perception of S:PRIME

• fast and relatively inexpensive • appropriate for Chilean companies

S:PRIME = Software Process Risk Identification Mapping and Evaluation

S:PRIME assessments, experience in

Chile

♦

9 organizations

♦

40+ projects

♦

150+ participants

♦

60+ risk questionnaires answered

♦

100+ practice questionnaires

(16)

Promedio de la Industria de Software en Chile

64 55 56 46 44 34 44 37 32 55 48 40 24 62 52 47 17 31 30 45 45 58 47 53 63 43 41 52 70 24 35 42 0 10 20 30 40 50 60 70 80 Gestió n de R eque rimien tos Planif icació n de Proy ectos Segu imien to y C ontro l de Pr oyec tos Ges tión d e Su bcon tratos Garan tía d e Ca lidad de So ftware Ges tión de C onfigura ción Enfoq ue en el P roces o Defin ición del P roceso Capacitación Gestión Integ rada Ingen iería de Prod uctos Coord inació n Inte rgrup al Revis iones de Pa res Cultu ra Co rporat iva Servicio al Cliente Cons olidad o Areas de Prácticas % % Cumplimiento % Riesgo

Some implications ....

♦

A recent study of typical development in

Chile shows the following results

> 5% management, 35% requirements, 60%

coding, testing and integration

> risk level 43%

> direct development cost : X (base)

> non-quality cost : 0.75 X

(17)

What can be done?

♦

Investing in practice improvement (p.ej.

35%) can result in

> 9% management, 6% quality assurance, 40%

requirements, 45% coding, testing and integration

> risk level 28%

> direct development cost : 1.08 X

> non-quality cost : 0.42 X

> total cost : 1.5 X

Source : INTEC-Chile

Other results

♦

Two software companies ISO Certified in

1996 (out of 7) ….. one lost certification in

2000

♦

Software Process Improvement