models for software quality - cs.cmu.eduyuezhao/cam4cmmi/ipm.pdfmodels for software quality the...

Models forSoftware

Quality

The Capability Maturity Model Integratedfor Systems Engineering

and Software Engineering,Version 1.1

Integrated Project Management (IPM):The CMMI and collaborative

product development

Course Guide

Version 6 (Slides Version 16)

Copyright Software Systems Quality Consulting All rights reserved. No portion of this material may be reproducedwithout the prior, written permission of SSQC, 2269 Sunny Vista Drive, San Jose CA 95128, Tel 408-985-4476 FAX408-248-7772, E-mail [email protected], Home Page http://www.ssqc.com

® CMM, Capability Maturity Model, Capability Maturity Modeling, and Carnegie Mellon are registered in the U.S. Patentand Trademark Office.

CMMI is a service mark of Carnegie Mellon University.

About SSQC and Its ServicesSince 1990, SSQC has specialized in supporting organizations in the definition and implementation of SoftwareEngineering Practices, Software Quality Assurance and Testing, Business Process Reengineering, ISO 9000Registration and CMM implementation. SSQC is an official SEI transition partner licensed to provide SCAMPIappraisal services and the SEI’s Introduction to Capability Maturity Model Integration.

SSQC also offers HM2, a unique, hybrid appraisal method that defines and correlates the position of an organizationwith respect to both ISO 9001 and the CMM. HM2 grew out of SSQC’s ground-breaking 1993 paper Comparing,contrasting ISO 9001 and the SEI Capability Maturity Model, which was published in IEEE Computer. The results ofan HM2 assessment are a plan and framework for improving software engineering processes and for implementingthe requirements of the two models.

The principals of Software Systems Quality Consulting are William J. Deibler and Robert C. Bamford.

William J. Deibler II has an MSc. in Computer Science and over 20 years experience in the computer industry,primarily in the areas of software and systems development, software testing, and software quality assurance. Billhas extensive experience in managing and implementing CMM- and ISO 9001-based process improvement insoftware engineering environments. Bill is an SEI Authorized CBA IPI Lead Assessor and SCAMPI Lead Appraiserfor CMMI.

Robert C. Bamford has an MA in mathematics, and has managed training development, technical publications,professional services, and third-party software development. His over 20 years of experience include the facilitatingthe definition and implementation of management processes, designing and instructing courses, and managingengineering teams.

Bob and Bill have developed and published numerous training courses, auditing tools, research papers, and articleson interpreting and applying the ISO 9000 standards and guidelines and the SEI Capability Maturity Model forSoftware. Their articles have appeared in McGraw Hill's Quality Systems Update, IEEE COMPUTER, McGraw Hill’sISO 9000 Handbook, CrossTALK, and Software Marketing Journal. They were the principal authors and projecteditors of A Guide to Software Quality System Registration under ISO 9001.

They have presented research papers at numerous national and international conferences, including those sponsoredby the American Society for Quality (ASQ), Pacific Northwest Software Quality (PNSQC), the Software PublishersAssociation (SPA), Software Technology Support Center (STSC), the Software Engineering Institute (SEI) andSoftware Research Inc.. Their courses have been attended by software engineering professionals from many of theworld’s leading technology companies. Their courses, have been sponsored for their members by professionalassociations, including the ASQ, CSU Long Beach's Software Engineering Forum for Training, SemiconductorEquipment and Materials International (SEMI), Software Engineering Institute (SEI), UC Berkeley and UC Santa Cruz.

They have been active United States TAG members in the ISO/IEC JTC1 SC7 - Software Engineering Standardssubcommittee which is responsible for the development and maintenance of ISO 12207 and ISO 15504 (SPICE).Their software development clients have successfully achieved ISO registration and advanced CMM maturity levels.

They have also performed ISO 9000 registration and TickIT audits as external resources under contract to the BritishStandards Institution (BSi).

Relationship with the SEISince 1993, when SSQC received permission from the SEI to reproduce various SEI CMM 1.1 technical reports forresale to the public, SSQC has maintained a close relationship with the SEI. Since 1996, SSQC has offered a varietyof presentations and tutorials at the annual SEI-sponsored conferences (SEPG) and symposia in both the US andEurope (ESEPG). SSQC has presented numerous tutorials and presentations at local SPINs in the Silicon Valley.

Since early 1999, SSQC courses, tutorials, presentations, and panels have been successfully promoting the CMMItransition efforts (both staged and continuous representations) at a variety of conferences to include ESEPG 1999-2002, SEPG 1999-2002, Quality Week 1999-2001, PNSQC 1999-2000.

© Software Systems Quality Consulting2269 Sunny Vista Drive, San Jose CA 95128All rights reserved.

1 Tel 408-985-4476 FAX 408-248-7772 [email protected]

www.ssqc.com

Integrated ProjectManagement (IPM)

The CMMI and collaborativeproduct development

2© SSQC All rights reserved Version 16INTEGRATED PROJECT MANAGEMENT

Getting started

! About the presenters! Audience

" Some level of familiarity with theSoftware Capability Maturity ModelVersion 1.1

– Maintaining SW CMM 1.1 or migratingto CMMI

! Experience breeds … , well, opinions,concerns, etc.



www.ssqc.com


Project management: prioritizedissues! Develop an individual list of the challenges your

organization needs to address in managing projectsor programs" On-going problems" Impending needs

! Prioritize individual list! Develop a single prioritized list of five items as a team! Pick a representative who will present list in 3 minutes! Ensure course addresses your concerns to greatest

possible extent


About the rest of the presentation! Brief orientation

" Structure of CMMI SE/SW Staged - Representation v1.1– Process Areas, Goals, Practices, and Process Categories

" Chasing levels! Integrated Project Management (IPM)

" Metrics, models, Key Performance Indicators" IPM and the Project Management Category Process Areas

– Project Planning (PP)– Process Monitoring and Control (PMC)– Team exercise: Case study– Risk Management (RM)

" IPM and the Process Management Process Category Process Areas" IPM and the Support Process Category Process Areas" IPM and the Engineering Process Category Process Areas

! Integrated Product and Process Development (IPPD)! Tools, tips, checklists and implementation opportunities



www.ssqc.com

CMM and CMMI

The fiveMaturityLevels

2MANAGED

DISCIPLINEDPROJECTS

3DEFINED

STANDARD PROCESS,CONSISTENCY ACROSSPROJECTS

4QUANTITATIVELY

MANAGED

PREDICTABLEPROCESS, PROJECTS

1INITIAL

TYPICALLY AD HOC AND CHAOTIC,DEPENDENT ON SKILLS ANDKNOWLEDGE OF PEOPLE

5OPTIMIZING

CONTINUOUSIMPROVEMENT


CMMI Process Areas by Maturity Level

Maturity Level 2: Managed Maturity Level 3: Defined

! Requirements Management ! Requirements Development! Project Planning ! Technical Solution! Project Monitoring and Control ! Product Integration! Supplier Agreement Management ! Verification! Measurement and Analysis ! Validation! Process and Product Quality Assurance ! Organizational Process Focus! Configuration Management ! Organizational Process Definition

! Organizational Training! Integrated Project Management! Risk Management! Decision Analysis and Resolution

Maturity Level 4: Quantitatively Managed Maturity Level 5: Optimizing

! Organizational Process Performance ! Organizational Innovation and Deployment! Quantitative Project Management ! Causal Analysis and Resolution



www.ssqc.com


CMMI Process Areas (PA)PROCESS AREAS

SPECIFIC GOALS

ABILITY DIRECTING VERIFYING

GENERIC GOALS

GENERICPRACTICES

COMMONFEATURES

SUBORDINATE PRACTICES

COMMITMENT

GOALS -REQUIRED

PRACTICES -EXPECTED

SUBORDINATE PRACTICES -INFORMATIVE

SPECIFICPRACTICES

CMMI generic goalsPROCESS AREAS

SPECIFIC GOALS


GENERIC GOALS

COMMITMENT

GENERICGOAL

2 The process is institutionalized as amanaged process. [LEVEL 2 Process Areas only]

3 The process is institutionalized as adefined process.

SPECIFICPRACTICES



www.ssqc.com

CMMI generic practicesPROCESS AREAS

SPECIFIC GOALS


GENERIC GOALS

COMMITMENT

POLICY,EXPECTATIONS

PLAN, DEFINED PROCESS,RESOURCES, TRAIN

RESPONSIBILITIES, etc.

MANAGE WORK PRODUCTS,INVOLVE STAKEHOLDERS,

MONITOR, CONTROL,ACCRUE DATA, etc.

MANAGEMENTOVERSIGHT,OBJECTIVEEVALUATION

INFRASTRUCTURE

SPECIFICPRACTICES


CMMI specific practicesPROCESS AREAS

SPECIFIC GOALS


GENERIC GOAL

COMMITMENT

ESTIMATE, DEFINE,DETERMINE,DEVELOP, PLAN,VALIDATE, etc.

IMPLEMENTATION

INFRASTRUCTURE

SPECIFICPRACTICES



www.ssqc.com


CMMI Process categories: primary interactions(but not the only interactions)

Category Type Level Process Area3 Organizational Process Focus3 Organizational Process DefinitionBasic3 Organizational Training4 Organizational Process Performance

ProcessManagement

Advanced5 Organizational Innovation and Deployment2 Project Planning2 Project Monitoring and ControlBasic2 Supplier Agreement Management3 Integrated Project Management for IPPD3 Risk Management

ProjectManagement

Advanced4 Quantitative Project Management2 Requirements Management3 Requirements Development3 Technical Solution3 Product Integration3 Verification

Engineering

3 Validation2 Measurement and Analysis2 Process and Product Quality AssuranceBasic2 Configuration Management3 Decision Analysis and Resolution

SupportAdvanced

5 Causal Analysis and Resolution


Maturity levels are measured by the the achievement of thespecific and generic goals that apply to each pre-definedset of process areas. [2000-TR-30, paragraph 2, p. 23]

Conformance with a process area means that in the plannedand implemented processes there is an associated process(or processes) that addresses either the specific andgeneric practices of the process area or alternatives thatclearly and unequivocally accomplish a result that meetsthe goal associated with that specific or generic practice.[2000-TR-30, paragraph 2, p. 26]

… trying to skip maturity levels is usually counter-productive. [2000-TR-30, paragraph 2, p. 24]

Chasing levels



www.ssqc.com


Why Integrated ProjectManagement (IPM)?

! Shouldn’t I wait until Level 3?! For small organizations, small projects,

level 3 PAs can be set as the initial goal" Support for cross-functional teams" Significant benefits in going beyond monitoring and

control (Level 2)! S/W CMM v1.1 - transition, inspiration! Because sometimes skipping levels is

productive" Or, because sometimes not skipping levels is counterproductive


Importance TO PROCESS IMPROVEMENT

Support FOR VISION AND BUSINESS OBJECTIVESEstablish and manage the project and theinvolvement of relevant stakeholdersaccording to an integrated and defined process[v1.1, IPM, Purpose]

INTERNAL EXTERNAL

Selfimage

Customerperception:

product

Alignment of internalstakeholders

IPM is a cornerstone ofprocess improvement.It enhances everyEngineering, Support, andProject Management PA.

It enables continuous,systematic alignment ofresources, activities, andbusiness objectives -converging on customervalue.

TERMS OF REFERENCEQuality = Commitments

CostScheduleContent



www.ssqc.com


The way wewere

WELCOME HARDWARE ENGINEERS

WELCOME

SOFTWARE ENG.ENG.ENG.ENG.

OTHERSOTHERSOTHERSOTHERS


CMMI: Opportunities beyond the S/WCMM

SYSTEMSIntegrate engineeringdisciplines - one “book”• Reduce influence and

language of MIL-STD-2167A• Appears more flexible, life

cycle independent• More content for

engineering

SOFTWARE HARDWARE

IPPD - Expands scope from(software) engineering project toproduct delivery• Inclusion of groups outside

engineering is explicit

MANUFAC-TURING

SUPPORT

FIELD SERVICE

CUSTOMIZATION



www.ssqc.com


Benefits TO THE ORGANIZATION

Since the defined process of each project is tailored from theorganization’s set of standard processes, variability amongprojects is typically reduced and projects can more easily shareprocess assets, data, and lessons learned. [v1.1, IPM, Introductory Notes]

Reduced variability and asystematic multi-discipline view ofproduct delivery translates directlyinto satisfying commitments to allstakeholders, including customers.

Enforced reuse of assetsminimizes the cost of reinventionand lays a stable foundation forcontinuous improvement.

A

B


Relationships and dependenciesWITHIN THE PROJECT MANAGEMENT CATEGORY

Integrated Project Management (IPM) ...• Relies on Project Planning (PP)

and Project Monitoring andControl (PMC) for basic projectplanning and management.

• Adds requirements forsystematic coordination.

• Incorporates data to drive decisions.• Integrates Supplier Agreement Management

(SAM) to support outsourcing development.

IPM + PP + PMC



www.ssqc.com


IPM: Specific goalsand practices

SG 1 The project isconducted using adefined process thatis tailored from theorganization's set ofstandard processes.

SG 2 Coordination andcollaboration of theproject with relevantstakeholders isconducted.

SP1.1 Establish, maintain the project'sdefined process.

SP 1.2 Use the organizational processassets and measurementrepository for estimating andplanning the project’s activities.

SP 1.3 Integrate the project plan and theother plans that affect the projectto describe the project’s definedprocess.

SP 1.4 Manage the project using theproject plan, the other plans thataffect the project, and theproject’s defined process.

SP1.5 Contribute work products,measures, and documentedexperiences to the organizationalprocess assets.

SPECIFICGOALS

SPECIFIC PRACTICES


A critical specific practice1.4 Manage the project using the integrated

plansWHY: product delivery is beyond any one

group’s capabilities, responsibilitiesSIGNIFICANT INDICATOR(S):

SP1.3, SubPractice 5, peer reviewsSP1.4, SubPractice 2, thresholds

AFFECTED STAKEHOLDERS:Project team (Mktg … Mfg)

RESISTANCE:Accountability - being measured, reportingprogress

SPECIAL APPRAISAL CONSIDERATIONS ANDCHALLENGES: Prepare, prepare, and prepare- Ensure there is adequate preparation timeto review the volume of documentation

RECOMMENDATIONS:Pilot - pick your project wisely

• New ProductIntroduction

• Support• Manufacturing

Engineering• Training• Technology Transfer• Manufacturing Master

Plan

SPECIFICPRACTICE

TIME TOMARKET

PARALLELACTIVITIES

RISK



www.ssqc.com


Specific practice 1.4, subpractice 22. Monitor and control the project’s activities and work

products using the project’s defined process, project plan,and other plans that affect the project.This task typically includes the following:• Using the defined entry and exit criteria to authorize the

initiation and determine the completion of the tasks• Monitoring the activities that could significantly affect the

actual values of the project’s planning parameters• Tracking the project’s planning parameters using

measurable thresholds that will trigger investigation andappropriate actions

• Monitoring product and project interface risks• Managing external and internal commitments based on the

plans for the tasks and work products of implementing theproject's defined process.


Project management

! Metrics - track! Models - predict! Key performance indicators



www.ssqc.com

Modeling variation in planning: settingmanagement expectations

INITIAL

PRODUCT

DEFINITIONAPPROVED

PRODUCT

DEFINITIONREQUIREMENTS

SPECIFICATION DESIGN

SPECIFICATION DETAILED

DESIGN

SPECIFICATIONPRODUCT

COMPLETE

X COST X SCHEDULE

1.0

1.25

1.50

2.00

3.00

4.00

.25

.50

.801.0

1.1

1.15

1.25

1.6

.60

.80

.90.67 .85

Based on S.McConnell, “SoftwareProject SurvivalGuide”, page 7


CUMULATIVEDEFECTS -REPORTED

VS PLANNED

TIME0

20

40

60

80

100

120

140

160

180

200

220

240

260

280

300

320

340

PROJECT 3

EXPECTED

ACTUAL (PROJECT 3)

ACTUAL (PROJECT 4)

PROJECT 4ACTUAL (PROJECT 2)

PROJECT 2

Modeling performance: defects



www.ssqc.com


CU

MU

LATI

VED

EFEC

TS

CUMULATIVEREPORTED

FIXED

OPEN

TIME0

20

40

60

80

100

120

140

160

180

200

220

240

260

280

300

320

340

R 50F 18O 32

R 185F 81O 104

R 278F 91O 187

R 305F 110O 195

R 320F 225O 95

R 330F 302O 28

Reported:Fixed:Open:

Tracking performance: defects


LEVEL ADEFECTS(SHOW-STOPPER)

0

20

40

60

80

100

TIMER 50A 41 +9B 4 +41C 5 +85

R 185A 50 +12B 45 +13C 90 +68

R 278A 62 +8B 58 +12C 158 +7

R 305A 70 +3B 70 +0C 165 +12

R 320A 73 +0B 70 +0C 177 +10

R 330A 73B 70C 187

Total Reported:A:B:C:

Tracking performance: defects by severity

0

20

40

60

80

100

0

40

80

120

160

200

240

LEVEL BDEFECTS

(PRACTICALWORK-AROUND)

LEVEL CDEFECTS

(COSMETIC)

CUMULATIVEDEFECTS

12 3 8 3 1 0

3 23 28 20 12 3

CUMULATIVEREPORTED

OPEN



www.ssqc.com


Tracking performance: code

CUMULATIVEPRODUCT %

COMPLETE

TIME0

5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

100

20% 40% 60% 80% 100%

PHASE 1DESIGN

PHASE 2DETAILEDDESIGN,

IMPLEMENTATION

PHASE3

BETA,GCA

RELEASE1

RELEASE2

INITIALBETABEST RATE

ACHIEVED

POSSIBLE


Tracking performance: reviews

NUMBEROF

MODULES

TIME0

20

40

60

80

100

120

140

160

180

200

220

240

260

280

300

320

340

CODED

REVIEWED

LAG

REVIEWBACKLOG



www.ssqc.com


Tracking performance: reviews (cont.)

NUMBEROF

MODULES

TIME0

20

40

60

80

100

120

140

160

180

200

220

240

260

280

300

320

340

CODED

REVIEWED (example 1)

REVIEWED (example 2)


Tracking head count against the plan

HEADCOUNT

TIME0

2

4

6

8

10

12

14

16

18

20

22

24

26

28

30

32

PLANNED

ACTUAL



www.ssqc.com


Requirements stability

TIME0

1

2

3

4

5

6

7

8

9

10

PER CENTCHANGED

0

5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

100

NUMBER OFREQUIREMENTS


IPM: Specific goals and practices (cont.)

SG 1 The project isconducted using adefined process thatis tailored from theorganization's set ofstandard processes.

SP2.1 Manage the involvement of therelevant stakeholders in theproject.

SP 2.2 Participate with relevantstakeholders to identify,negotiate, and track criticaldependencies.

SP 2.3 Resolve issues with relevantstakeholders.

SG 2 Coordination andcollaboration of theproject with relevantstakeholders isconducted.

SPECIFICGOALS

SPECIFIC PRACTICES



www.ssqc.com


A critical specific practice2.2 Manage [critical] dependenciesWHY: make dependencies continuously visible,

mitigate or prevent impactSIGNIFICANT INDICATOR(S):

SP2.2, SubPractice 5 - document thecritical dependencies and commitments

AFFECTED STAKEHOLDERS:Project team (Mktg … Mfg)

RESISTANCE:Exposure - versus milestone chicken (or R= v / i)

SPECIAL APPRAISAL CONSIDERATIONS ANDCHALLENGES: Look carefully at SubPractice6 - track and take action

RECOMMENDATIONS: Pick a pilot project with astrong manager who under-stands the bigpicture; ensure team focuses on criticaldependencies - avoid blame, focus onsolutions

• Identify• Inform• Manage - SP 2.2.6

- Track and takecorrective andpreventive action

- Evaluate the effects oflate and earlycompletion for impactson future activities andmilestones

I wish someone

had told me ...


Specific practice 2.2, subpractice 5

5. Document the critical dependencies andcommitments.Documentation of commitments typically includes thefollowing:• Describing the commitment• Identifying who made the commitment• Identifying who is responsible for satisfying the

commitment• Specifying when the commitment will be satisfied• Specifying the criteria for determining if the

commitment has been satisfied



www.ssqc.com

Project Planning (PP)

SG 1 Estimates of projectplanningparameters areestablished andmaintained.

SG 2 A project plan isestablished andmaintained as thebasis for managingthe project.

SG 3 Commitments tothe project plan areestablished andmaintained.

SP 1.1 Establish … top-level Work BreakdownStructure (WBS)

SP 1.2 Establish and maintain estimates ofattributes [parameters] of the work productsand tasks

SP 1.3 Define project life cycle phases …SP 1.4 Estimate … effort and cost for work

products and tasks ...SP 2.1 Establish and maintain budget and scheduleSP 2.2 Identify and analyze risksSP 2.3 Plan for data management [documentation, all

forms]SP 2.4 Plan for ... resourcesSP 2.5 Plan for knowledge and skillsSP 2.6 Plan stakeholder involvementSP 2.7 Establish and maintain the overall project

plan

SP 3.1 Review all plans that affect the project ...SP 3.2 Reconcile plan to reflect available and

estimated resourcesSP 3.3 Obtain commitment from … stakeholders

SPECIFICGOALS

SPECIFIC PRACTICES


Life cycles and life cyclesFrom Project Planning (PP), Specific Practice 1.3

Define the project life-cycle phases upon which to scope theplanning effort.The determination of a project’s life-cycle phases provides for plannedperiods of evaluation and decision making. These are normallydefined to support logical decision points at which significantcommitments are made concerning resources and technical approach.Such points provide planned events at which project coursecorrections and determinations of future scope and cost can be made.

For Software EngineeringThe determination of project phases for software typically includes selectionand refinement of a software development model to addressinterdependencies and appropriate sequencing of software projectactivities.For Systems EngineeringIdentify the major product phase (e.g., concept exploration, development,etc.) for the current state of the product ...



www.ssqc.com


Life cycles and life cycles (cont.)More from Project Planning (PP), Specific Practice 1.3The project life cycle consists of phases that need to be defineddepending on the scope of requirements, the estimates for projectresources, and the nature of the project. Larger projects maycontain multiple phases, such as concept exploration,development, production, operations, and disposal. Within thesephases, subphases may be needed. A development phase mayinclude subphases such as requirements analysis, design,fabrication, integration, and verification. Depending on thestrategy for development, there may be intermediate phases forthe creation of prototypes, increments of capability, or spiral modelcycles.Understanding the project life cycle is crucial in determining thescope of the planning effort and the timing of the initial planning, aswell as the timing and criteria (critical milestones) for re-planning.


Guidance from IPM Specific Goal 1The project's defined process must include those processes from theorganization's set of standard processes that address all processesnecessary to develop and maintain the product. The product-related life-cycleprocesses, such as the manufacturing and support processes, are developedconcurrently with the product.

From Chapter 3A “product life cycle” is the period of time, consisting of phases, that beginswhen a product is conceived and ends when the product is no longeravailable for use. ... A product life cycle could consist of the followingphases: (1) concept/vision, (2) feasibility, (3) design/development, (4)production, and (5) phase out.

Life cycles and life cycles (cont.)



www.ssqc.com


Life cycles and life cycles (cont.)

Guidance from RD Specific Practice 1.2For Integrated Product and Process DevelopmentRelevant stakeholders representing all phases of theproduct’s life cycle should include business as well astechnical functions. In this way, concepts for allproduct-related lifecycle processes are consideredconcurrently with the concepts for the products.

IntegratedProduct andProcessDevelopment

A systematic approach to product development that achieves a timelycollaboration of relevant stakeholders throughout the product life cycle tobetter satisfy customer needs.

From the Glossary


PHA

SE 2

REV

IEW

PHA

SE 2

REV

IEW

Someintermediatetesting spanshardware andsoftware.

STAGE 1 - CONCEPT STAGE 2 - FEASIBILITY STAGE 3 - DESIGN/DEVELOP

MAR

KETI

NG

ENG

INEE

RIN

G

IDENTIFYBUSINESSOPPORT-

UNITY

ASSESSRISK

DOCUMENTBUSINESSPROPOSAL

DOCUMENTPRELIMI-

NARYDESIGN

DOCUMENTHIGH LEVEL

PLAN

PREPAREPROJECT

PRO-POSAL

DOCUMENTSYSTEM DESIGN

& ARCHI-TECTURE

REVISE PROJECTDEVELOPMENT

PLAN

ESTABLISHPROJECTREQUIRE-

MENTS

DEVELOPHARDWARE

UNIT

DEVELOPSOFTWARE

MODULE

ANALYZE,DESIGN,DEVELOP,UNIT TEST

DEVELOP-MENT TESTS

(UNIT,INTEGRA-

TION)

DEVELOPMENTTESTS (UNIT,

INTEGRATION)

PRE-PROD-UCTION

MANUFAC-TURING

PROCURECOMPO-NENTS

Procure items withlong lead times

Engineering may createthe Pre-Production Units

MAN

UFA

CTU

RIN

G/

DES

IGN

REV

IEW

DES

IGN

REV

IEW

PHA

SE 1

REV

IEW

PHA

SE 1

REV

IEW

PHA

SE 3

REV

IEW

PHA

SE 3

REV

IEW

ENG

INEE

RIN

MG

SYS

TEM

TES

TEN

GIN

EER

INM

G S

YSTE

M T

EST

SOFT

WA

RE

REL

EASE

REV

IEW

SOFT

WA

RE

REL

EASE

REV

IEW

PHA

SE 3

A R

EVIE

WPH

ASE

3A

REV

IEW



www.ssqc.com

PH 3: BUILD, TEST

S/WDEVINTE-GRA-TIONTEST

SW-1000

MFGPRE-PRO-DUC-TION

BUILD

OPS-2001

MAT

OPS-2004

PRELIM

SRB

S/WONLY

PA

TEST

ENG

REL

3

ENG

REL

3

DEV-1049

PHASE

3

REVIEW

PHASE

3

REVIEW

PDI-1004

SYSTEMREGULA-TORY AP-PROVAL

RAS-20012

SW-2000

PH 2: DESIGN, DEVELOP, DEVELOPMENT TEST

REGU-LATORY

APPROVAL

HSD-1220RAS-10012

FUNCTIONAL EVALUATION

DEV-1100

OEMPRODUCTS

UNIT

A-NAL-YSIS

DE-SIGN

LAY-OUT

DE-TAILDES

PRO-TO-

TYPETEST

LAY-OUT

DE-TAILDES

PRO-TO-

TYPE

PHYSICAL

LOGICAL

HSD-1218

DEVELOPED HARDWARE

INTER-MEDI-ATEDEV

TESTS

HSD-1218

TEST

HSD-1218

ENG

REL

2

ENG

REL

2

DEV-1049 P

HASE

2

REVIEW

PHASE

2

REVIEW

AUTHORIZE PRE-PRODUCTION

BUILD

PDI-1004

PH 1: DETAILEDFEASIBILITY, PLAN

PRD

MKT-1244

PB

DEV-1048

PDP

DEV-1049

PRO-1225OEM PRODUCT

SECONDARYQUALIFICATION

SUPPLIERPRE-AWARD

SURVEYREPORTS

PURCHASESPECIFICATION

PRO-1226

PSD

INCLUDES PA AND MATTEST REQUIREMENTS

DEV-1048

ENG

REL

1

ENG

REL

1

DEV-1049

PHASE

1

REVIEW

PHASE

1

REVIEW

AUTHORIZEPDP

PDI-1004

MODELS,HIGH-LEVEL

BOMS

The Product Development Life Cycle

PH 0: INITIALFEASIBILITY

MRS

MKT-1244

FD

MKT-1244

DEV-1023OEM

PRODUCTPRIMARY

EVALUATIONAND REPORT

PHASE

0

REVIEW

PHASE

0

REVIEW

AUTHORIZERESOURCES

FOR PH 1

PDI-1004

LEGENDDEV DevelopmentENG EngineeringFD Functional DescriptionH/W HardwareMAT Mfg. Acceptance testMFG ManufacturingMRS Market Requirements

Spec.PA Product AssurancePB Product BriefPDP Product Development PlanPRD Product Requirements Doc.PSD Product Specification Doc.PRO ProductionREL ReleaseSRB Software Release BoardSYS SystemS/W Software

1004-006-01 Issue 14.0

MODULEA-

NAL-YSIS

DE-SIGN

DE-VELOP

UNITTEST

SW-1000INCLUDES TEST SPECSAND DEVELOPMENT OF

TEST H/W AND S/W

INTER-MEDI-ATEDEV

TESTS

SW-1000

DEVELOPEDSOFTWARE

PH 4: PROOF SERVICEAND SUPPORT

1STPRO-DUC-TION

OPS-2011

ALPHA

TESTPDI-1005

BETA

TEST

S/WONLY

FINAL

SRB

ENG

REL

4

ENG

REL

4

DEV-1049OPS-2212

PHASE

4

REVIEW

PHASE

4

REVIEW

PDI-1004

SW-3000

PH 3: BUILD, TEST

S/WDEVINTE-GRA-TIONTEST

SW-1000

MFGPRE-PRO-DUC-TION

BUILD

OPS-2001

MAT

OPS-2004

PRELIM

SRB

S/WONLY

PA

TEST

ENG

REL

3

ENG

REL

3

DEV-1049

PHASE

3

REVIEW

PHASE

3

REVIEW

PDI-1004

SYSTEMREGULA-TORY AP-PROVAL

RAS-20012

SW-2000

PH 2: DESIGN, DEVELOP, DEVELOPMENT TEST

REGU-LATORY

APPROVAL

HSD-1220RAS-10012

FUNCTIONAL EVALUATION

DEV-1100

OEMPRODUCTS

UNIT

A-NAL-YSIS

DE-SIGN

LAY-OUT

DE-TAILDES

PRO-TO-

TYPETEST

LAY-OUT

DE-TAILDES

PRO-TO-

TYPE

PHYSICAL

LOGICAL

HSD-1218

DEVELOPED HARDWARE

INTER-MEDI-ATEDEV

TESTS

HSD-1218

TEST

HSD-1218

ENG

REL

2

ENG

REL

2

DEV-1049 P

HASE

2

REVIEW

PHASE

2

REVIEW

AUTHORIZE PRE-PRODUCTION

BUILD

PDI-1004

PH 1: DETAILEDFEASIBILITY, PLAN

PRD

MKT-1244

PB

DEV-1048

PDP

DEV-1049

PRO-1225OEM PRODUCT

SECONDARYQUALIFICATION

SUPPLIERPRE-AWARD

SURVEYREPORTS

PURCHASESPECIFICATION

PRO-1226

PSD

INCLUDES PA AND MATTEST REQUIREMENTS

DEV-1048

ENG

REL

1

ENG

REL

1

DEV-1049

PHASE

1

REVIEW

PHASE

1

REVIEW

AUTHORIZEPDP

PDI-1004

MODELS,HIGH-LEVEL

BOMS

PH 0: INITIALFEASIBILITY

MRS

MKT-1244

FD

MKT-1244

DEV-1023OEM

PRODUCTPRIMARY

EVALUATIONAND REPORT

PHASE

0

REVIEW

PHASE

0

REVIEW

AUTHORIZERESOURCES

FOR PH 1

PDI-1004

LEGENDDEV DevelopmentENG EngineeringFD Functional DescriptionH/W HardwareMAT Mfg. Acceptance testMFG ManufacturingMRS Market Requirements

Spec.PA Product AssurancePB Product BriefPDP Product Development PlanPRD Product Requirements Doc.PSD Product Specification Doc.PRO ProductionREL ReleaseSRB Software Release BoardSYS SystemS/W Software

1004-006-01 Issue 14.0

MODULEA-

NAL-YSIS

DE-SIGN

DE-VELOP

UNITTEST

SW-1000INCLUDES TEST SPECSAND DEVELOPMENT OF

TEST H/W AND S/W

INTER-MEDI-ATEDEV

TESTS

SW-1000

DEVELOPEDSOFTWARE

PH 4: PROOF SERVICEAND SUPPORT

1STPRO-DUC-TION

OPS-2011

ALPHA

TESTPDI-1005

BETA

TEST

S/WONLY

FINAL

SRB

ENG

REL

4

ENG

REL

4

DEV-1049OPS-2212

PHASE

4

REVIEW

PHASE

4

REVIEW

PDI-1004

SW-3000


Extreme programming and pair programmingPlan

Releases

Plan iterations

Assign tasks

Establish pairs

MONTHS

WEEKS

ONE DAY

MINUTES

SECONDS

HOURS

End users, development team determine which requirements will be implemented and set intended release dates

Development team factors in tasks from the release plan, unfinished tasks, bugs that must be addressed

Programmers create new unit tests; reexamine past unit tests that failed; assess failed user acceptance tests

Programmers work in pairs on the same code to complete tasks more quickly and to increase code quality

Stand-up meeting; individual tasks assigned; pair negotiation begins

Programmers paired so that they may begin pair programming process

Based on Wells, WEL1

EFFORT: +60%COMPLETED: 40% FASTER

Williams, WIL1



www.ssqc.com


Extreme programming - as a process flow

User Stories

ArchitecturalSpike

ReleasePlanning

Spike

Iteration AcceptanceTests

SmallReleases

TEST SCENARIOS

BUGS

LATESTVERSION

NEXTITERATION

CUSTOMERAPPROVAL

NEW USER STORY,PROJECT VELOCITY

RELEASEPLAN

SYSTEM METAPHOR

REQUIREMENTS

CONFIDENTESTIMATES

UNCERTAINESTIMATES

Wells, WEL2

INCEPTION ELABORATION CONSTRUCTION TRANSITION

Unified Process Life CyclePHASES

CORE PROCESSESBusiness Modeling

Requirements

Analysis and Design

Implementation

Deployment

Config./Change Mgt.

Project Management

Environment

Test

CORE SUPPORTING PROCESSES

ITER.1

ITER.2

ITER.m

ITER.m+1

ITER.m+2

ITER.n

ITER.n+1

PRELIMINARYPRELIMINARYPRELIMINARYPRELIMINARYITERATION(S)ITERATION(S)ITERATION(S)ITERATION(S)

Scott Ambler, Enhancing the Unified Process, Software Development , Vol. 7, No. 10, Oct. 1999, p.33



www.ssqc.com

PRODUCTIONINCEPTION ELABORATION CONSTRUCTION TRANSITION

Enhanced Unified Process Life CyclePHASES

CORE PROCESSES

BusinessModeling

Requirements

Analysis andDesign

Implementation

Deployment

Config./Change Mgt.

Project Management

Environment

Test

CORE SUPPORTINGPROCESSES

ITER.1

ITER.2

ITER.m

ITER.m+1

ITER.m+2

ITER.n

ITER.n+1

PRELIMINARYPRELIMINARYPRELIMINARYPRELIMINARYITERATION(S)ITERATION(S)ITERATION(S)ITERATION(S)

Scott Ambler, Enhancing the Unified Process, Software Development , Vol. 7, No. 10, Oct. 1999, p.33

InfrastructureManagement

Operations andSupport

The Object-Oriented Process (OOSP) Life Cycle

Scott Ambler, Enhancing the Unified Process, Software Development , Oct. 1999, p.33

ASSURE QUALITY• Manage the project• Train and educate• Manage people• Manage risk

• Manage reuse• Manage metrics• Manage deliverables• Manage infrastructure

INITIATESINITIATESINITIATESINITIATES CONSTRUCTCONSTRUCTCONSTRUCTCONSTRUCT DELIVERDELIVERDELIVERDELIVER MAINTAIN, SUPPORTMAINTAIN, SUPPORTMAINTAIN, SUPPORTMAINTAIN, SUPPORT

JUSTIFY

DEFINE ANDVALIDATE

INITIALREQUIRE-

MENTS

DEFINEINITIAL

MGTDOCUMENTS DEFINE

INFRASTRUCTURE

MODELTEST INSMALLSCALE

GENERALIZE PROGRAM

TEST INLARGESCALE

RELEASE

REWORK ASSESS

SUPPORT

IDENTIFYDEFECTS AND

ENHANCE-MENTS



www.ssqc.com


Project Monitoring and Control (PMC)

SG 1 Actual performance andprogress of the projectare monitored againstthe project plan.

SG 2 Corrective actions aremanaged to closurewhen the project'sperformance or resultsdeviate significantlyfrom the plan.

Monitor actuals against the plan: SP 1.1 Parameters SP 1.2 Commitments SP 1.3 Risks SP 1.4 Data management SP 1.5 Stakeholder involvementSP 1.6 Periodically review progress,

performance, issuesSP 1.7 Review accomplishments and

results at selected milestones

SP 2.1 Collect and analyze the issues anddetermine the corrective actionsnecessary to address the issues.

SP 2.2 Take corrective action on identifiedissues.

SP 2.3 Manage corrective actions toclosure … complete ... effective.

SPECIFICGOALS

SPECIFIC PRACTICES

NOTE The word dependency does not appearin Project Monitoring and Control.


Integrated Product and ProcessDevelopment (IPPD)

! With IPPD you get:" Two new specific goals for Integrated

Product Management (IPM)" Two new Process Areas (PA)s" Amplification in various other Process

Areas" Only 64 more pages



www.ssqc.com

IPPD: Specific goals for Integrated ProjectManagement (IPM)

SG 1 The project is conductedusing a defined process thatis tailored from theorganization's set ofstandard processes.

SG 2 Coordination andcollaboration of the projectwith relevant stakeholders isconducted.

SG 3 The project is conductedusing the project’s sharedvision.

SG 4 The integrated teams neededto execute the project areidentified, defined,structured, and tasked.

SP3.1 Identify expectations,constraints, interfaces, andoperational conditionsapplicable to the project’sshared vision.

SP 3.2 Establish and maintain ashared vision for theproject.

SP 3.3 Resolve issues withrelevant stakeholders.

SPECIFICGOALS

SPECIFIC PRACTICES

IPPD: Specific goals for Integrated ProjectManagement (IPM) (cont.)

SG 1 The project is conductedusing a defined process thatis tailored from theorganization's set ofstandard processes.

SG 2 Coordination andcollaboration of the projectwith relevant stakeholders isconducted.

SG 3 The project is conductedusing the project’s sharedvision.

SG 4 The integrated teams neededto execute the project areidentified, defined,structured, and tasked.

SP 4.1 Determine the integratedteam structure that will bestmeet the project objectivesand constraints.

SP 4.2 Develop a preliminarydistribution ofrequirements,responsibilities, authorities,tasks, and interfaces toteams in the selectedintegrated team structure.

SP 4.3 Establish and maintainteams in the integratedteam structure.

SPECIFIC PRACTICES

SPECIFICGOALS



www.ssqc.com

51INTEGRATED PROJECT MANAGEMENT© SSQC All rights reserved Version 16

Case Study:AJ OY


IPMINTEGRATED

PROJECTMANAGEMENT

QPMQUANTITA-

TIVEPROJECTMANAGE-

MENT

RSKMRISK

MANAGE-MENT

• QUANTITATIVE OBJECTIVES• SUBPROCESSES TO

MANAGE STATISTICALLY

• COORDINATIONRISKS

• PROJECT’S DEFINEDPROCESS

HISTORICALDATA VIA OPD

PPPROJECTPLANNING PMC

PROJECTMONITORING

ANDCONTROL

SAMSUPPLIER

AGREEMENT MANAGE-

MENT

• PROJECT’S DEFINEDPROCESS (PDP)

• REQUIREMENT TOINTEGRATE PLANS

• OSSP AND ARTIFACTS• PDP• REQUIREMENT

TO INTEGRATEPLANMANAGEMENT

• PDP• REQUIREMENT TO

INTEGRATE PLANS• REQUIREMENT TO

INTEGRATE MANAGEMENT

INTEGRATEDPROJECTPLANNING

INTEGRATEDPROJECT

MONITOR-ING AND

CONTROL PROJECT PLAN,PROJECT

MANAGEMENT

ADVANCED

BASIC

RISK STATUS ANDMANAGEMENT(VIA PP, PMC)

FROM PP:IDENTIFIEDRISKS

FROM PMC:RISK ACTIVITY

PROGRESS

PLAN



www.ssqc.com

Risk Management(RISKM)SG 1 Preparation for risk

management isconducted.

SG 2 Risks are identifiedand analyzed todetermine theirrelative importance.

SG3 Risks are handledand mitigated, whereappropriate, toreduce adverseimpacts on achievingobjectives.

SPECIFICGOALS

SPECIFIC PRACTICES

SP 1.1 Determine risk sources and categoriesSP 1.2 Define the parameters used to analyze

and categorize risks, and the parametersused to control the risk managementeffort.

SP 1.3 Establish and maintain the strategy to beused for risk management.

SP 2.1 Identify and document the risks [in allappropriate product life cycle phasesSP2.1.1 ]

SP 2.2 Evaluate and categorize each identifiedrisk using the defined risk categories andparameters, and determine its relativepriority.

SP 3.1 Develop a risk mitigation plan for themost important risks to the project, asdefined by the risk management strategy.

SP 3.2 Monitor the status of each riskperiodically and implement the riskmitigation plan as appropriate.


Risk and the new spiral model - the win-winelaboration

1. Identify next levelstakeholders

2. Identify stakeholders’win conditions

3. Reconcile win conditions.Establish next levelobjectives, constraints,alternatives

4. Evaluate product andprocess alternatives.Resolve risks.

5. Define next level ofproduct and process -including partitions.

6. Review, commitment.7. Validate product and

process definitions.

[BOE1]



www.ssqc.com


19951. Personnel shortfalls2. Schedules, budgets, process3. COTS, external components4. Requirements mismatch5. User interface mismatch6. Architecture, performance, quality7. Requirements changes8. Legacy software9. Externally-performed tasks10. Straining computer science

19891. Personnel shortfalls2. Schedules and budgets3. Wrong software functions4. Wrong user interface5. Gold plating6. Requirements changes7. Externally-furnished components8. Externally-performed tasks9. Real-time performance10. Straining computer science

Top 10 Risks

Barry Boehm


How do you alreadyincorporate risk prevention

and mitigation into yourprojects?

A COMMENTSome activities, which are not perceived as havingintrinsic importance, may be parts of a mitigationstrategy (cross training, reviews, investigation ofalternatives).If the mitigation strategy is not clearlycommunicated and managed, there is a significantrisk that the mitigation will be OBE*.

A COMMENTSome activities, which are not perceived as havingintrinsic importance, may be parts of a mitigationstrategy (cross training, reviews, investigation ofalternatives).If the mitigation strategy is not clearlycommunicated and managed, there is a significantrisk that the mitigation will be OBE*.

* OBE Overcome by Events



www.ssqc.com


ORGANIZATION

PROJECT

If we run out ofqualified teamleaders, … .

If I lose teamleader X, … .

If the newmicroprocessor doesn'thave the promisedperformance, … .

TEAM A

If the idea for thealgorithm doesn'tprove out, … .

CONDITION EFFECT CONSEQUENCE

IF ... THEN ... SO ...

Risks to be managed

! Future! Significant probability of future occurrence! Significant potential impact! Specific and manageable

How a specific plannedbehavior or outcome is

adversely affected

Specific relationship todefined process, plan,assigned responsibility,customer commitment,schedule, cost



www.ssqc.com


If Engineering personnel are unavailable, we won't be able to supportour customers.

If key Engineering personnel are unavailable, then wewon't be able to respond to escalated calls fromcustomers with our legacy Accounting software.

IF knowledgeable Engineering personnel areunavailable, THEN we won't be able to respondin a timely manner to calls from customerswith our legacy Accounting software. [SO]We won't be able to fulfill these customers’current maintenance contracts.

We won't haveenough

engineers.

We’ll get toomany customer

calls

We won't be ableto support our

customers.


A common failing in softwareprojects is optimism.

As engineers, we do not clearlycommunicate the risks we know

about.

Why would that be the case?What can we do about it?

See Carr, CRL1See Carr, CRL1See Carr, CRL1See Carr, CRL1



www.ssqc.com


Formal risk identification! Systematic investigation

A. Product Engineering1. Requirements2. Design3. Code and Unit Test4. Integration and Test5. Engineering

Specialties

B. DevelopmentEnvironment1. Development Process2. Development System3. Management Process4. Management Methods5. Work Environment

C. ProgramConstraints1. Resources2. Contract3. Program

Interfaces

RISK

CLASSCLASSCLASSCLASS

ELEMENTELEMENTELEMENTELEMENT

ATTRIBUTESATTRIBUTESATTRIBUTESATTRIBUTES

Carr, CRL1Carr, CRL1Carr, CRL1Carr, CRL1

CONDITION CONSEQUENCE

TIME FRAMES - DURATION,TO OCCURRENCE

PROBABILITIES/FREQUENCY

MITIGATION POTENTIAL: INDICATORS [WARNING],METHODS [PREVENT, REDUCE, REACT] AND COSTS,POTENTIAL FOR SUCCESS, LIABILITY (DO NOTHING)

"PLANPRIORITIZE AND AGGREGATE RISKS

SELECT STRATEGIES FOR MITIGATIONSELECT METHODS TO CONTROL

IDENTIFY RESOURCES

#MANAGE MONITOR, ADJUST, COMMUNICATE

$STATE IF ...IF ...IF ...IF ... SO ...SO ...SO ...SO ...

DEFINE

ELABORATE ASAPPROPRIATE

Formal Risk Analysis

EFFECTTHEN ...THEN ...THEN ...THEN ...

APPROPRIATEDETAIL -

BASED ONIMPACT



www.ssqc.com


Last year Supportreceived 20 calls aboutthe accounting package,3 were escalated toEngineering, onerequired a patch, whichtook 2 weeks.

We don't quote response times in ourmaintenance contracts, but these areloyal customers who only call withobscure problems, when they needhelp. We have 16 customers with ourlegacy package. None of them arecandidates to upgrade and all are happywith what they have.

When we release thenext version of the newaccounting package andif we get the WPIoutsource contract, wewill be really stretchedin engineering

Condition# Effect ConsequenceIfknowledgeableengineeringpersonnel areunavailable

1 We won't be ableto respond in atimely manner toescalated callsfrom customerswith our legacyAccountingsoftware

So we won't beable to fulfillthesecustomers'currentmaintenancecontracts.

ImpactLO (1)MED (5)HI (7)V HI (9)

ProbLO (1)MED (5)HI (7)V HI (9)

RELRISK

45

Elaborate as appropriate


Plan: Variables and mitigationtechniques

QUALITY

COST SCHEDULEAdd people,

change skillsmix, tools

Extend,overlap,run in parallel

CONTENT PROCESSEliminate,redefine,

stage, or deferfunctionality

Reduce hand offs,integrated teams,empowerment,increase risk



www.ssqc.com


Manage risks: levels of response and thresholds

PRO

BA

BIL

ITY

IMPACT(1) LOW (5) MEDIUM (7) HIGH (9) VERY HIGH

REACT

OBSERVE(DISCUSS)

MONITOR(INSTRUMENT)

MIP (EXECUTEMITIGATION,INCORPORATE INDEVELOPMENTPLAN)

Establish levels ofresponse fordifferent types ofprojects based onpast experience(“should have”)

LOW (1)

MEDIUM (5)

HIGH (7)

VERY HIGH (9)

≤≤≤≤ 9> 9

≤≤≤≤ 7

≤≤≤≤ 35> 35

≤≤≤≤ 5

≤≤≤≤ 25

≤≤≤≤ 35> 35

≤≤≤≤ 5

≤≤≤≤ 7> 7


Report to executive management:the risk profile

Impact REACT OBS MON MIP TotalLOW - - 11 2 -MED 2 17 8 0 27HIGH 0 8 4 7 19V. HIGH 6 1 7

Observe

Monitor Mitiga

tion

in progr

ess



www.ssqc.com


Relationships and dependenciesWITHIN THE PROJECT MANAGEMENT CATEGORY

IPMINTEGRATED

PROJECTMANAGEMENT

QPMQUANTITA-

TIVEPROJECTMANAGE-

MENT

RSKMRISK

MANAGE-MENT

PPPROJECTPLANNING

PMCPROJECT

MONITORINGAND

CONTROL

SAMSUPPLIER

AGREEMENT MANAGE-

MENT

##

#


Relationships and dependenciesBEYOND THE PROJECT MANAGEMENT CATEGORY

The development of the project plan should account for current and projectedneeds, objectives, and requirements of the organization, customer, and end users, asappropriate.This process area ... addresses the coordination of all activities associated with theproject including … technical activities … and support activities.

Integrated Project management (IPM) …• Advances the organization from monitoring and

controlling projects to managing projects.• Requires the coordination of all activities

associated with product delivery and lays afoundation for global process improvement andoptimization.



www.ssqc.com

Relationships and dependenciesBEYOND THE PROJECT MANAGEMENT CATEGORY (cont.)

IPMINTEGRATED

PROJECTMANAGE-

MENT

ENGINEERING

SUPPORT

P MR AO NC AE GS ES M

ENT

OPFORGANIZA-

TIONALPROCESS

FOCUS

VERVERIFICA-

TION

CMCONFIGURA-

TIONMANAGE-

MENT

PPQAPRODUCT &PROCESS

QA

MAMEASURE-MENT ANDANALYSIS

TSTECHNI-

CALSOLUTION

PIPRODUCTINTEGRA-

TION

VALVALIDA-

TION

OPDORGANIZA-

TIONALPROCESS

DEFINITION

OTORGANIZA-

TIONALTRAINING

RDREQUIRE-

MENTSDEVELOP-

MENTREQMREQUIRE-

MENTSMANAGE-

MENT

OIDORGANIZA-

TIONALINNOV ATION

& DEPLOY-MENT

Relationships and dependencies:IPM ANDPROCESSMANAGEMENT

IPMINTEGRATED

PROJECTMANAGE-

MENT

OPFORGANIZA-

TIONALPROCESS

FOCUS

OPDORGANIZA-

TIONALPROCESS

DEFINITION

OTORGANIZA-

TIONALTRAINING

Lessonslearned

Organizationalprocess needsand objectives

• Best fit standard processes• Lifecycles• Artifacts (samples)• Tailoring guidelines, historical

estimates, plans

• Projectestimates, actuals

• Measures• Documentation• Lessons learned• Proposed improvements

• Project training needs• Requirement to provide plan for integration

OIDORGANIZA-

TIONALINNOV ATION

& DEPLOY-MENT.

Process andtechnologyimprovementsCoordinate

(plan, manage)deployment



www.ssqc.com

Relationships and dependencies:IPM ANDSUPPORT

IPMINTEGRATED

PROJECTMANAGE-

MENT

CMCONFIGURA-

TIONMANAGE-

MENT

PPQAPRODUCT

ANDPROCESS QA

MAMEASURE-MENT ANDANALYSIS

• Project’s definedprocess (PDP)

• Requirement toprovide plan forintegration

Measures and analysesto manage the project(SP1.4)

• PDP• Requirement to

provide plan forintegration

Relationships and dependencies:IPM AND ENGINEERING

IPMINTEGRATED

PROJECTMANAGE-

MENT

VERVERIFICA-

TION

TSTECHNI-

CALSOLUTION

PIPRODUCTINTEGRA-

TION

VALVALIDA-

TION RDREQUIRE-

MENTSDEVELOP-

MENT

REQMREQUIRE-

MENTSMANAGE-

MENT

• Project’s definedprocess (PDP)

• Intended work products• Requirement to provide

plan for integration

• PDP• Intended work products• Requirement to provide

plan for integration -including peerreview

PDP

• PDP• Require-

ment toprovideplan forintegration

PDP

Commitmentsimpacting

definedprocesses

Stakeholder requirements• Customer• Product, component• Life cycle

PDP



www.ssqc.com


Integrated Product and ProcessDevelopment (IPPD) - Beyond IPM

! Two new Process Areas" Level" Category" Goals

! Implementation considerations andrecommendations" Tools and techniques" A road map


Integrated Product and Process Development(IPPD): Process Areas

Maturity Level 2: Managed Maturity Level 3: Defined

! Requirements Management ! Requirements Development! Project Planning ! Technical Solution! Project Monitoring and Control ! Product Integration! Supplier Agreement Management ! Verification! Measurement and Analysis ! Validation! Process and Product Quality Assurance ! Organizational Process Focus! Configuration Management ! Organizational Process Definition

! Organizational Training! Integrated Project Management for IPPD! Risk Management! Integrated Teaming! Decision Analysis and Resolution! Organizational Environment for

Integration

Maturity Level 4: Quantitatively Managed Maturity Level 5: Optimizing

! Organizational Process Performance ! Organizational Innovation and Deployment! Quantitative Project Management ! Causal Analysis and Resolution



www.ssqc.com

Integrated Product and Process Development(IPPD): Process categories

Category Type Level Process Area3 Organizational Process Focus3 Organizational Process DefinitionBasic3 Organizational Training4 Organizational Process Performance

ProcessManagement

Advanced5 Organizational Innovation and Deployment2 Project Planning2 Project Monitoring and ControlBasic2 Supplier Agreement Management3 Integrated Project Management for IPPD3 Risk Management3 Integrated Teaming

ProjectManagement

Advanced

4 Quantitative Project Management2 Requirements Management3 Requirements Development3 Technical Solution3 Product Integration3 Verification

Engineering

3 Validation2 Measurement and Analysis2 Process and Product Quality AssuranceBasic2 Configuration Management3 Organizational Environment for Integration3 Decision Analysis and Resolution

SupportAdvanced

5 Causal Analysis and Resolution


IPPD: Process categories and maturity levelsProcess Project Engi-

Level Process Area Management Management neering SupportRequirements Management XProject Planning BProject Monitoring and Control B

2 Supplier Agreement Management BMeasurement and Analysis BProcess and Product Quality Assurance BConfiguration Management BRequirements Development XTechnical Solution XProduct Integration XVerification XValidation X

3 Organizational Process Focus BOrganizational Process Definition BOrganizational Training BIntegrated Project Management for IPPD ARisk Management AIntegrated Teaming ADecision Analysis and Resolution AOrganizational Environment for Integration A

4 Organizational Process Performance AQuantitative Project Management A

5 Organizational Innovation and Deployment ACausal Analysis and Resolution A



www.ssqc.com


OrganizationalEnvironment forIntegration (OEI)

SG 1 An infrastructure thatmaximizes theproductivity of peopleand affects thecollaboration necessaryfor integration isprovided.

SG 2 People are managed tonurture the integrativeand collaborativebehaviors of an IPPDenvironment.

Integrated Teaming(IT)

SG1 A team compositionthat provides theknowledge and skillsrequired to deliver theteam’s product isestablished andmaintained.

SG2 Operation of theintegrated team isgoverned according toestablished principles.

SPECIFIC GOALS SPECIFIC GOALS

SW/SE/IPPD/SS


Suggestions and comments: tools andtechniques for integrated teams

! Periodic project reviews" The Key Deliverables Review (KDR)

! Milestone/Phase reviews" Checklists

! Earned Value as an approach! Planning and replanning

" Granularity



www.ssqc.com


KDRs - Avoiding SOS

DEFERRED START REPORT - 01/14 START

WBS DESCRIPTION ORIGINAL LAST CURRENT ACTUAL RISK12.1 Beta Algorithm Detailed Design 01/07 01/21 HI15.1 Alpha Algorithm Test Specification 01/07 01/14 01/1315.1 Fault Tree Test Specification 01/07 01/14 01/21 LO19.1 High Performance Beta Plan 12/01 01/14 01/21 HI

COMMENTS ON HIGH RISK ITEMS12.1 The assigned engineer has still not been released from the previous assignment.

Current release date is 1/15. Another engineer has been assigned as a back up, but isjust starting to learn the class library.

19.1 Marketing has still not identified a target customer. This is not a significant issuesince the generic high-performance beta plan only needs to be tailored for the specificcustomer's configuration.

At an appropriate level ofdetail from the WBS


Tracking performance against theplan: Earned Value

! Assumes regular time or effort reporting" Sufficient detail to identify

work product and activity! System(s) to report

" Cost or effort againstplan

" Completion of workagainst plan

JAN FEB

MAR

SEP

OCT

NOV

DEC

APRM

AY

JUNJULAUG



www.ssqc.com


Planning versus reality

As planned

DESIGN CODE TEST

As performed

TESTCODE

DESIGN

CODE

DE-SIGN

TEST

DESIGN

Q May I please seethe design.

A Well, we just pulledit back to do somemore work on it,but we're wayahead of scheduleon the code andwe’re about to startsome testing.


A familiar example: How am I doing?

THIS MONTH

1 8 15 22 29

$1,700

TELEPHONE: $50

FOOD: $100 FOOD: $150

TRANSPORTATION: $300

BALANCE:

DAY:

EXPENSE BUDGETUtilities $100Housing $1,000Telephone $30Food ($125/wk) $500Transportation $70TOTAL $1,700

NATURAL FACTORS– AMOUNT BUDGETED– ACTUAL AMOUNT SPENT– SPEND RATE - incremental

expenses

$1,100



www.ssqc.com


Performance indices

1 2 3 4 5 6 7 8 9 10TIME

SchedulePerformanceIndex

CostPerformanceIndex

1

1

0

0

Monitor Late Starts

Myth 1: Add staff, compress the schedule

! Brook's Law: manpower and time are not interchangeable! Based on a nominal schedule, 2x staff:

" 20% faster ● 6x defects! Supported by core metrics: Size, Time, Effort, Defects

(Anita Carleton, CAR1)! GATHER DATA - Identify, learn from experience

PROJECT SIZE

DU

RA

TIO

N (M

ON

THS)

X

XX

X

X

X

X

X

X

X

X

X

PROJECT SIZE

EFFO

RT

(PER

SON

MO

NTH

S)

X X

X

X

X

XX

X

X

X

X

X

Michael Mah, MAH1

Diminishing, disappearing returns



www.ssqc.com


Myth 1: Add staff ... (cont.)

IMPOSSIBLEREGION

td to = 2td.75td

DEVELOPMENT TIME

RES

OU

RC

E

Roetzheim, ROE1; DOD1

td = Calculated optimal timeto = Cost optimal time

Requires a change in thefundamental characteristicsof the project (e.g., volume,environment)

Putnam-Norden-Rayleigh (PNR)Curve


Myth 2: Reuse will save us

! To build in reusability: 2x effort" Per class library - from 20 to 40 days" Design, inspection, documentation

! Library maintenance" Coordinating obsolescence

! Learning curve (6 to 12 months)" Library consultant per 4 projects" Maintain, communicate, advise, mentor

PAG1, Meilir Page-Jones



www.ssqc.com


Myth 3: We’ll make it up later

! Projects over budget when only 15%complete usually complete with overruns

! Actual completion costs will not improve bymore than 10% of the current percentageoverrun

! For commercial projects" 10% late ~ 30% loss in profit" 50% cost overrun ~ 3% loss in profit


IPM: Required ordering? No, but... Establish the project’s

defined process

Use organizational processassets for planning project

activities

Integrate plans

Manage the project using theintegrated plans

Contribute to theorganization’s process assets

SP1.1

SP1.2

SP1.3

SP1.4

SP1.5

TIME

Managestakeholderinvolvement

SP2.1

Managedependen-

cies

SP2.2

Resolvecoordina-

tion issues

SP2.3

There is a natural, logicalordering.

And GP2.7



www.ssqc.com


IPM: The generic practices (GP)

! Special significance? - look for elaboration" GP2.1 (CO1) Establish an organizational policy$GP2.3 (AB3) Provide resources

■ Note the reference to integrated support environments" GP2.5 (AB5) Train people$GP2.7 (DI2) Identify and involve relevant stakeholders

■ At beginning - start with tailoring" GP2.8 (DI3) Monitor and control the process$GP2.9 (VE1) Objectively evaluate adherence

■ Significant if PPQA (Quality Assurance) is embedded in theproject


The generic practices (cont.)

! Resistance?" All the usual suspects

– Management commitment (CO1, AB3, AB4, AB5, VE2)

– Politics (DI2, DI3, VE1, VE2)

– CMMI regurgitation (ALL)

" To evaluating adherence - if PPQAbecomes a “police” function (VE1)

– Ensure PPQA is value-added - it can be



www.ssqc.com


Tools and tips

! No shortage of tools (free and otherwise)! BUT ...

" Process first" Tools second


Start-up checklist for projectmanagement processes% Establish status reporting process& Establish risk management process' Establish change management process( Apply appropriate metrics) Align organization with life cycle* Align working environment+ Align development/test environment, Ensure training takes place



www.ssqc.com


Typical implementation opportunities -Business acquisition

% Define interfaces with internalorganizations

& Requirements analysis - capability' Requirements definition( Requirements change management


Typical implementation opportunities -Development

% Engineering lifecycle definition& Requirements management' Planning and project management

" Development" Verification and validation



www.ssqc.com


( Configuration management" Controls for change

) Maintenance" Lifecycle scaleability" External problem resolution


Typical implementation opportunities -Manufacturing

% Define interface with Engineering/Development& Planning to ensure capability to meet

commitments" New business (resources and training)" New types of product (process engineering)

' Integrate quality functions( Automate systems to greatest extent practical



www.ssqc.com


Typical implementation opportunities -Services and Support

% Define interfaces with internal organizations& Planning to ensure capability to meet

commitments" New business (resources and training)" New types of service (process

engineering)' Automate systems to greatest extent

practical


Contact Information

Bill DeiblerSoftware Systems Quality Consulting2269 Sunny Vista DriveSan Jose, CA 95128Phone +1-408-985-4476 Fax [email protected]

www.ssqc.com

IPM PA Workbook 50 Version 6

23rd printing

Software ◆ Systems ◆ Quality ◆ Consulting2269 Sunny Vista Drive ◆ San Jose CA USA ◆ Tel 408-985-4476

Internet: [email protected] ◆ http://www.ssqc.com

models for software quality - cs.cmu.eduyuezhao/cam4cmmi/ipm.pdfmodels for software quality the...

Documents