CPSC4175Intro to Software Engineering

Neal Rogers

Process Foundations

• Lesson: Process Raison d’être• Strategic Objective: understand the rationale of

using processes• Tactical Objectives:

– know the work of the contemporary quality movement– Know how manufacturing processes have been applied

to software– Know the contemporary and classical schools of SwE– Understand the purpose and benefits of processes– Be able to identify “ingredients” of a process – Know the common processes currently in use– Understand the difference between a process model and

a model process– Understand the Capability Maturity Model (Integrated) for

Software; know the model’s key processes

• Support material:– Text 2, 3– Readings 2, 3, and 4– References 1, 2, 3, 8, and 9

• Immediate-use skills provided– interview buzzwords

• References:– CMMI Product Team 2002. Capability Maturity Model Integration

(CMMISM), Version 1.1. CMU/SEI-02-TR-01, 02-TR-28, 02-TR-29. Software Engineering Institute.

– IEEE. 1997. IEEE Standard for Developing Software Life Cycle Processes. IEEE Std 1074-1997.

– Paulk, M. et al. 1993. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24. Software Engineering Institute.

– Schmauch, C. 1995. ISO 9000 for Software Developers. Revised edition. ASQC Quality Press.

– Schulmeyer, G. G. 1987. Software quality lessons from the quality experts. From Handbook of Software Quality Assurance. Van Nostrand Reinhold. pp. 25-45.

• Software engineering raison d’être • Process foundations • Common process elements • Conceptual design • Size estimation• Task decomposition• Scheduling• Measurements• Reviews• Technical templates• Scaling up• Misc processes• Process descriptions• Infrastructure• Retrospective

Syllabus

Process foundations Industrial quality movement Software quality movement

Processes a la SwE Classical school Contemporary school

Processes explored further Processes rationale Function of processes Process model

Process Models Introduction Sample models

Discussion point …

How do we ensure the quality* of software?

*quality = software meeting customer needs, known software characteristics (e.g., defects, performance, content)

Follow-up point …

What stands in the way of your achieving “quality” the first time, every

time?

Contemporary Quality Movement• Kaoru Ishikawa

– company-wide quality control– top management buy-in– industrial education and training– application of statistical methods

• Joseph Juran– structured approach to manufacturing:

• study the symptoms of the defects and failures• develop a theory on the causes of these symptoms

– specifically, examine worker-controllable vs management-controllable aspects

• test the theory until the causes are known• stimulate remedial action

Contemporary Quality Movement• W. Edwards Deming

– statistical control– common method of attacking and describing problems

• P-D-C-A approach– plan– do– check– analyze

A C

P D

Contemporary Quality Movement• W. Edwards Deming (con’t)

– 13 pts• create constancy of purpose for improvement• adopt the new philosophy• cease dependence on mass inspection• end the practice of awarding business on price tag alone• improve constantly the system of production and service• institute training and retraining• institute leadership• drive out fear• break down barriers between staff areas• eliminate slogans, exhortations, and targets• remove barriers to pride of workmanship• institute a vigorous program of education and retraining• take action to accomplish transformation

Contemporary Quality Movement• Philip Crosby

– guiding principles:• “quality is conformance to requirements”• “quality is free, but only to those who are willing to pay heavily

for it.”

– Quality management maturity grid• 5 levels of maturity: uncertainty, awakening, enlightenment,

wisdom, certainty• 6 measurement categories

– management understanding– quality organization status– problem handling– cost of quality as % of sales– quality improvement actions– summation of company quality posture

Stage I: Uncertainty• Management understanding and attitude

– No comprehension of quality as a management tools. Tend to blame quality dept for “quality problems”

• Quality organization status– Quality is hidden in manufacturing or engineering departments.

Inspection probably not part of organization.

• Problem handling– Problems are fought as they occur; no resolution; inadequate

definition; lots of yelling and accusations.

• Cost of quality as % of sales– Reported: unknown– Actual: 20%

• Quality improvement actions– No organized activities. No understanding of such activities

• Summation of company quality posture– “We don’t know why we have problems with quality.”

Stage II: Awakening• Management understanding and attitude

– Recognizing that quality mgmt may be of value but not willing to provide money or time to make it happen

• Quality organization status– A stronger quality leader is appointed but main emphasis is still

on appraisal and moving the product. Still part of manufacturing or other

• Problem handling– Teams are set up to attack major problems. Long-range

solutions are not solicited.• Cost of quality as % of sales

– Reported: 3%– Actual: 18%

• Quality improvement actions– Trying obvious “motivational” short-range efforts

• Summation of company quality posture– “Is it absolutely necessary to always have problems with

quality?””

Stage III: Enlightenment• Management understanding and attitude

– While going thru quality improvement program learn more about quality management

• Quality organization status– Quality dept reports to top management

• Problem handling– Corrective action communication established. Problems are

faced openly and resolved in an orderly way.• Cost of quality as % of sales

– Reported: 8%– Actual: 12%

• Quality improvement actions– Implementation of a specified quality program with thorough

understanding of each step• Summation of company quality posture

– “Through management commitment and quality improvement we are identifying and resolving our problems.”

Stage IV: Wisdom• Management understanding and attitude

– Participating. Recognize their personal role in continuing emphasis

• Quality organization status– Quality manager is officer of company

• Problem handling– Problems identified early in their development. All functions open

to suggestion and improvement

• Cost of quality as % of sales– Reported: 6.5%– Actual: 8%

• Quality improvement actions– Continuing specific quality program

• Summation of company quality posture– “Defect prevention is a routine part of our operation.”

Stage V: Certainty• Management understanding and attitude

– Consider quality management an essential part of company system

• Quality organization status– Quality manager on board of directors. Prevention is main

concern. Quality is a thought leader.

• Problem handling– Except in the most unusual cases, problems are prevented.

• Cost of quality as % of sales– Reported: 2.5%– Actual: 2.5%

• Quality improvement actions– Quality improvement is a normal and continued activity

• Summation of company quality posture– “We know why we do not have problems with quality.”

Quality Movement wrt Software• Lennart Sandholm

– quality policy• statement of corporate-wide commitment to quality• promulgated by senior software executive

– quality objectives• statements of measurable improvements• e.g., number of errors per thousand LOC

– quality system• used to achieve the quality objectives• e.g., standards, procedures, etc.

– quality assurance organization• facilitating body• may process and/or product oriented

Premise that has evolved:• The quality of a product is largely determined

by the quality of the process that is used to develop and maintain it.

Ghost of SwE Past• Classical software development philosophy

– tenets:• software engineering = building software = technical activity• grab-bag of disjoint technical actions• software projects can be orchestrated no differently than

other projects in other fields

TOOLS

Identify Synthesize Articulate Interpret

People

Technical

Organize Staff DirectPlan Control

Product+ =

Ghost of SwE Present (sorta)• Contemporary software development philosophy

– tenets• software engineering = technical facets + managerial facets

orchestrated by process• focus on process activities

– teach the troops correct principles and they will govern themselves

– Humphrey [1995]:» “The quality of software is governed by the quality of

its worst components.”» “The quality of a software component is governed by

the individuals who developed it.”– teams with comprehensive processes are more likely to

contain cost and ensure quality than those without– processes can exist on a project-by-project basis, but are

leveraged best on an organization-wide basis

SwE now (sorta)• Contemporary software development philosophy

(con’t)– hence

TOOLS

Product with known “quality”

+ =

Identify Synthesize Articulate Interpret

Process

People

Technical

Organize Staff DirectPlan Control

Product Property SuccessLifecycle Infra

Processes Explored Further• Process

– ... is the set of all enterprise tasks needed to produce software

– ... “sets out the technical and management framework for applying methods, tools, and people.”

[Humphrey 1995]– our goal: use process measurements and controls to

guide production

PROJECTP

roce

ss 1

Pro

cess

n

Pro

cess

2

Pro

cess

3

Pro

cess

4

Consider: Example: % of requirements allocated to software: *

• B-2 -- 65%

• F-22 -- 80%

Process Rationale• Processes help ...

[Humphrey1995]

– ... identify the principal activities of doing a job– ... separate routine from complex tasks– ... establish starting and stopping criteria– ... facilitate tracking progress and measuring

performance– ... judge accuracy of work projections– ... provide orderly mechanism for learning– ... establish corporate memory of necessary activities– ... create a defined baseline for improvement

Example Process• PSP0 process script

• Problem description• Defect standard type

• Produce a requirements statement• Estimate and record the required development time• Record time spent planning

• Design the program• Implement the design• Compile program; fix and log all defects found• Test the program and fix and log all defects found.• Record time spent in development

• Calculate and record performance statistics

• Tested program• Completed plan, defect log, time log

Entry

Planning

Development

Postmortem

Exit

Tasks

Processes Explored Further• Function of processes: engineering insight

IN OUT

IN OUT

INOUT

INOUT

INOUT

[Paulk et al 1993a]

incr

easi

ng s

ophi

stic

atio

n

Processes Explored Further• Function of processes: enhance predictability

planned delivery

Well-defined processes

Ad hoc processes

[Paulk et al 1993a]time

prob

abili

ty

.

0 %

140%

-140%

....

.

..

. .. .

.

. . .. . .

.

.

..

..

. ...

..

. . .. ..

Without Historical Data With Historical DataVariance between + 20% to - 145% Variance between - 20% to + 20%

(Mostly Level 1 & 2) (Level 3)

Ove

r/U

nd

er P

erce

nta

ge

.

(Based on 120 projects in Boeing Information Systems)

.. . .

.

.. .

...

. .

. ..

.. .

..

...

. . .. . .. . . . .

. . . . .. . . . . .. . . . .. . . . . .

. . . . . . . .

. . . .. . . . . . .. . . .. .. . . . . ... .. .. .. ...... . .. . ... . ... .. .. . . . . .. . . . . .. . . . . .. . . .. . . . . . . . . . .. . . . .. . .. . . . . . . . .

. . . . . .. . . . . .

Reference: John D. Vu. “Software Process Improvement Journey:From Level 1 to Level 5.” 7th SEPG Conference, San Jose, March 1997.

Empirical evidence

Before After

Historical Perspective

X* Engineeringguarantors of

quality

* where X = civil, mechanical, electrical, etc.

codes

physical laws

mathematical analysis

Traditional engineering focuses on the product; software engineering focuses on the process of building the product

Software Engineeringguarantors of

quality

process (i.e., the way in which we build the software)

certification (i.e., rigorous examination of end product)

Historical Perspective

No process Process

?

Process Darwinism

Heavy-weight processes

Light-weight processes

IEEE 1074, CMM, ISO 9001 XP, Scrum, ASD, FDD

requirements containment vsrequirements adaptation

design-oriented vsconstruction-oriented

predictive vsadaptive

Common Processes• Pre-defined processes (a.k.a. model processes)

– MIL-STD 2167A– MIL-STD-498 -> IEEE 12207.0– IEEE 1074– XP– NASA xxx, Boeing xxx, etc., etc.

• Process model– “a structured collection of elements that describe

characteristics of effective processes” - SEI

– Examples• ISO 9001• CMMI (Capability Maturity Model – Integrated)• SPICE (Software Process Improvement and Capability

dEtermination … ISO/IEC TR 15504)

Common Process Model Ingredients• life cycle model

– sequence of technical tasks required to produce a product (e.g., analysis, design, code, test, etc.)

• product model– tasks needed to produce an artifact in a specific form

• property model– tasks needed to attain desired cost, schedule,

security, reuse, etc.

• success model– tasks needed to assure and assess correctness

• infrastructure model– administrative tasks needed to ensure day-to-day

activities are carried out

Samples• MIL-STD-2167A

– Planning, management, engineering procedures, standards, quality, configuration management

interface design

preliminary design

detailed design

req analysis

design code test

Samples• MIL-STD-2167A (con’t)

Preliminary design process

• develop prelim design

• develop interface design

• document rationale

• establish test requirements

• allocate/document FQT

• evaluate design docs

• baseline design docs

• conduct PDR

Samples• IEEE Std 1074-1997

– … “provides a set of Activities that constitute the Processes that are mandatory for the development and maintenance of software”

[IEEE 1997]– Processes:

• Software life cycle model processSoftware life cycle model

• Project management processesproject initiationproject monitoring and controlsoftware quality management

• Pre-development processesconcept explorationsystem allocation

• Development processesrequirementsdesignimplementation

• Post-development processesinstallationoperation and supportmaintenanceretirement

• Integral processesverification and validationsoftware configuration managementdocumentation developmenttraining

Samples• Extreme Programming (XP)

Customer

Customer

DeveloperDeveloper

Define values

Estim

ate

cost

Choose

value

Build va

lue

user stories

estimation via risk,

priority

spike solution

test first, sds, CM

Samples• ISO 9000 [Schmauch 1995]

– … defines minimum process requirements that must be met to ensure quality

– … is a framework: states what, not how– written originally for manufacturing, but also applied to

software

Samples• ISO 9000 (con’t)

– collection of individual, but related standards

• 9000-1 Guidelines for selection and use

• 9000-3 Guidelines for application of 9001 to software

• 9001 Model for quality assurance in design, development, production, installation,

servicing

• 9002 Model for QA in production, installation, servicing

• 9003 Model for QA in final inspection and test

• 9004 Guidelines for interpretation of 9001, 9002, 9003

Req Code Test Install MaintDesign

9001

90029003

Samples• ISO 9000 (con’t)

– 9001 Processes (interpreted through 9000-3)• Framework

management responsibilityquality systeminternal quality system auditscorrective action

• Life cycle activitiescontract reviewpurchaser’s requirements specdevelopment planningquality planningdesign and implementationtesting and validationacceptancereplication, delivery, and installationmaintenance

• Supporting activitiesconfig managementdocument controlquality recordsmeasurementrules, practices, and

conventionstools and techniquespurchasingincluded software

product training

Samples• Capability Maturity Model (Integrated)

– Basics• … gauges organizations’ ability to predict and control software

activities• identifies processes necessary for software production• provides a framework for measuring production

capability

– Views• continuous

– Q: how well am I performing software functions?• staged

– Q: how well can I control cost, schedule, performance?

– Misc• is called “integrated” because it is integrated with other CMMs

Requirements ManagementRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidation

Engineering

ProjectManagement

Project PlanningProject Monitoring and ControlSupplier Agreement ManagementIntegrated Project ManagementIntegrated Supplier Management Integrated Teaming Risk ManagementQuantitative Project Management

Organizational Process FocusOrganizational Process DefinitionOrganizational TrainingOrganizational Process PerformanceOrganizational Innovation and Deployment

ProcessManagement

Configuration ManagementProcess and Product Quality AssuranceMeasurement and AnalysisCausal Analysis and ResolutionDecision Analysis and ResolutionOrganizational Environment for Integration

Support

Category Process Area

CMMI – Process Areas

Samples• CMMI (con’t)

– continuous representation

pro

cess

are

a 1

pro

cess

are

a 2

pro

cess

are

a 3

pro

cess

are

a 4

pro

cess

are

a n

…

0

12

3

4

5

cap

abil

ity

process areas

CMMI process areas – staged

Organizational Innovation and DeploymentCausal Analysis and Resolution5 Optimizing

4 Quantitatively Managed

3 Defined

2 Managed

Continuous process improvement

Quantitativemanagement

Processstandardization

Basicprojectmanagement

Organizational Process PerformanceQuantitative Project Management

Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational Training Integrated Project ManagementIntegrated Supplier ManagementRisk ManagementDecision Analysis and ResolutionOrganizational Environment for IntegrationIntegrated Teaming

Requirements Management Project PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality AssuranceConfiguration Management

1 Performed

Process AreasLevel Focus

Samples• CMMI (con’t)

– staged representation

Focus on process improvement

4 Quantitatively Managed

3 Defined

2 Managed

1 Performed

0 Not Performed

5 Optimized

Process matured and controlled

Process at org level

Process at project level

Process ad hoc

No process

incr

easin

g pr

edict

abilit

y;

decr

easin

g m

anag

emen

t risk

Empirical Data

Samples• PSP

– instantiation of CMMI for small organizations– includes:

• measurement and analyses framework to help characterize processes

• defined procedure to help improve performance

– CPSC4175 approach• introduce PSP in several upwardly compatible steps• write small programs at each step• gather and analyze data on work• use data and analyses to gain insight into process

management• scale up to multiple person efforts (CPSC4176)

Samples• PSP (con’t)

PSP0Current processTime recording

Defect recordingDefect type standard

PSP1Size estimating

Test report

PSP2Code reviews

Design reviews

PSP3Cyclic development

PSP1.1Task planning

Schedule planning

PSP0.1Coding standard

Size measurement

TSPTeam coordination

Summary Key Points• The manufacturing community

discovered processes long ago• SwE then = technical activities

SwE now = process orientation• A process is a set of enterprise

tasks• Processes have benefits: most

notable is management containment

• Process models describe what to do; model processes describe how to do it. Many exist

Topics• Process foundations• Processes a la SwE• Processes explored• Process Models

Next time: Common process elements