ieee std 730 software quality assurance: supporting cmmi ... · ieee standards working group has...

27
©2011 Walz IEEE Std 730 Software Quality Assurance: Supporting CMMI-DEV v1.3, Product and Process Quality Assurance 1 John Walz 2012 President, IEEE Computer Society Sue Carroll Principal Software Quality Analyst, SAS Software Quality Division 23rd System & Software Technology Conference SSTC 27-May-2011, Salt Lake City, UT

Upload: others

Post on 16-Mar-2020

13 views

Category:

Documents


0 download

TRANSCRIPT

©2011 Walz

IEEE Std 730 Software Quality Assurance: Supporting CMMI-DEV v1.3, Product and Process Quality Assurance

1

John Walz2012 President, IEEE Computer Society

Sue CarrollPrincipal Software Quality Analyst, SAS Software Quality Division

23rd System & Software Technology Conference SSTC

27-May-2011, Salt Lake City, UT

Report Documentation Page Form ApprovedOMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.

1. REPORT DATE MAY 2011 2. REPORT TYPE

3. DATES COVERED 00-00-2011 to 00-00-2011

4. TITLE AND SUBTITLE IEEE Std 730 Software Quality Assurance: Supporting CMMI-DEV v1.3,Product and Process Quality Assurance

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) IEEE Computer Society,2001 L Street N.W., Suite 700,Washington,DC,20036-4928

8. PERFORMING ORGANIZATIONREPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited

13. SUPPLEMENTARY NOTES Presented at the 23rd Systems and Software Technology Conference (SSTC), 16-19 May 2011, Salt LakeCity, UT. Sponsored in part by the USAF. U.S. Government or Federal Rights License

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT Same as

Report (SAR)

18. NUMBEROF PAGES

26

19a. NAME OFRESPONSIBLE PERSON

a. REPORT unclassified

b. ABSTRACT unclassified

c. THIS PAGE unclassified

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

©2011 Walz

Walz Bio highlights

• Standards: IEEE and US TAG to ISO TC 176 Quality Management

• Quality: ASQ, work experience

• Software: three books, consulting, work experience

• Systems: Telecom & DoD work experience

©2011 Walz

Abstract

The latest CMMI-DEV version 1.3 shows over 50 instances of Quality Assurance (QA). It is clear that CMMI-DEV and IEEE 730 SQA need to align. The P730 IEEE standards working group has expanded the scope of the SQA process standard to align with IS 12207 software life cycle processes. Presentation will cover IEEE 730 CMMI appendix on implementation if your organization uses the CMMI-DEV framework. We welcome audience feedback and support to enhance this IEEE 730 guidance

3IS: International Standard, IEEE/ISO/IEC

©2011 Walz

Life Cycle Process frameworks

4

CMMI-DEV

IEEE / ISO / IEC 15288 / 12207

Quality Assurance

©2011 Walz

IEEE Life Cycle Processes & Artifacts• Systems Life Cycle Processes (IS 15288)

– 25 processes including • life cycle management process• software implementation

• Software Life Cycle Processes (IS 12207)– 18 processes: Implementation, Technical,

Reuse, & Support • Support processes include Software QA (SQA)

• Life Cycle Information Products (IS 15289)• assist users to manage information items as products

of the system or software life cycle processes5

©2011 Walz

CMMI Life Cycle Process Areas• CMMI Architecture and Framework

– CMMI® for Acquisition, ACQ• 22 process areas

– include process & product quality assurance, PPQA

– CMMI® for Services, SVC• 24 process areas

– include process & product quality assurance, PPQA

– CMMI® for Development, DEV• 22 process areas

– including process & product quality assurance, PPQA

6

!"#$!%&'())*+,)**-.%/'!%%%'"01'())*+2)**-''

(3'!"#$%&#'(")**+"!",--"./0123".434.546!"#'''")**+"!",--"./0123".434.546

"

"

"

"4506789':;<=4<7>'?84@9<<

.&>7A<9'BC3C((/

"4506789'D7;E09E7E@9'?84@9<<

.&>7A<9'BC3C(*/

"4506789'#=9870;4E'?84@9<<

.&>7A<9'BC3CF/

"4506789'G@@9=07E@9'"A==480'?84@9<<.&>7A<9'BC3C-/

"4506789'!E<07>>70;4E'?84@9<<

.&>7A<9'BC3C+/

"H<09I'JA7>;5;@70;4E'K9<0;EL'?84@9<<.&>7A<9'BC3CB/

"H<09I'!E09L870;4E'?84@9<<

.&>7A<9'BC3CM/

!I=>9I9E070;4E'?84@9<<'.&>7A<9'BC3C3/

"H<09I'G8@N;09@0A87>':9<;LE'?84@9<<.&>7A<9'BC3CO/

"H<09I'P9QA;89I9E0<'GE7>H<;<'?84@9<<.&>7A<9'BC3C)/

"07R9N4>198'P9QA;89I9E0<':95;E;0;4E'?84@9<<'.&>7A<9'BC3C(/

K9@NE;@7>'?84@9<<9<

"H<09I'&4E09S0'?84@9<<9< "4506789'"=9@;5;@'?84@9<<9<

D97<A89I9E0'?84@9<<.&>7A<9'BCOC+/

!E548I70;4E'D7E7L9I9E0'?84@9<<

.&>7A<9'BCOCB/

&4E5;LA870;4E'D7E7L9I9E0'?84@9<<

.&>7A<9'BCOCM/

P;<R'D7E7L9I9E0'?84@9<<'.&>7A<9'BCOC3/

:9@;<;4E'D7E7L9I9E0'?84@9<<

.&>7A<9'BCOCO/

?84T9@0'G<<9<<I9E0'7E1'&4E084>'?84@9<<.&>7A<9'BCOC)/

?84T9@0'?>7EE;EL'?84@9<<.&>7A<9'BCOC(/

?84T9@0'?84@9<<9<

JA7>;0H'D7E7L9I9E0'?84@9<<

.&>7A<9'BC)CM/

UAI7E'P9<4A8@9'D7E7L9I9E0'?84@9<<

.&>7A<9'BC)C3/

?84T9@0'?48054>;4'D7E7L9I9E0'?84@9<<

.&>7A<9'BC)CO/

!E587<08A@0A89'D7E7L9I9E0'?84@9<<

.&>7A<9'BC)C)/

V;59'&H@>9'D419>'D7E7L9I9E0'?84@9<<

.&>7A<9'BC)C(/

#8L7E;W70;4E7>?84T9@02%E7X>;EL'?84@9<<9<

"A==>H'?84@9<<.&>7A<9'BC(C)/

G@QA;<;0;4E'?84@9<<.&>7A<9'BC(C(/

GL899I9E0'?84@9<<9<

P9A<9'G<<90D7E7L9I9E0'?84@9<<

.&>7A<9'+COC)/

:4I7;E'%EL;E998;EL'?84@9<<

.&>7A<9'+COC(/

"4506789'JA7>;5;@70;4E'K9<0;EL'?84@9<<.&>7A<9'+C(C+/

"4506789'!E09L870;4E'?84@9<<

.&>7A<9'+C(CB/

"4506789'&4E<08A@0;4E'?84@9<<

.&>7A<9'+C(CM/

"4506789':907;>91':9<;LE'?84@9<<

.&>7A<9'+C(C3/

"4506789'G8@N;09@0A87>':9<;LE'?84@9<<.&>7A<9'+C(CO/

"4506789'P9QA;89I9E0<'GE7>H<;<'?84@9<<.&>7A<9'+C(C)/

"4506789'!I=>9I9E070;4E'?84@9<<

.&>7A<9'+C(C(/

"Y'!I=>9I9E0270;4E ?84@9<<9<

P9A<9'?84L87I'D7E7L9I9E0'?84@9<<

.&>7A<9'+COCO/

"4506789'P9A<9'?84@9<<9<

"4506789'?84X>9I'P9<4>A0;4E'?84@9<<.&>7A<9'+C)C-/

"4506789'GA1;0'?84@9<<.&>7A<9'+C)C+/

"4506789'P9Z;96'?84@9<<.&>7A<9'+C)CB/

"4506789'[7>;170;4E'?84@9<<

.&>7A<9'+C)CM/

"4506789'[98;5;@70;4E'?84@9<<

.&>7A<9'+C)C3/

"4506789'JA7>;0H'G<<A87E@9'?84@9<<.&>7A<9'+C)CO/

"4506789'&4E5;LA870;4E'D7E7L9I9E0'?84@9<<

.&>7A<9'+C)C)/

"4506789':4@AI9E070;4E'D7E7L9I9E0'?84@9<<

.&>7A<9'+C)C(/

"Y'"A==480'?84@9<<9<

\;LA89'(']'V;59'&H@>9'?84@9<<'L84A=<'

714"8.9:433";4<4.4=:4">964-" 6943" =92" .4?.434=2" @" [email protected]/:A-@." ?.9:433" /B?-4B4=2@2/9=" @??.9@:1" =9." 6943" /2"

?.43:./C4"@"3D324B&39<[email protected]"-/<4":D:-4"B964-F"B421969-90D"9."24:1=/GA4H"#=324@6"214".4<4.4=:4"B964-"/3"/=24=646"

29" C4" @69?246" CD" @=" 9.0@=/I@2/9=" C@346" 9=" /23" CA3/=433" =4463" @=6" @??-/:@2/9=" 69B@/=H" 714" 9.0@=/I@2/9=J3"

64</=46"?.9:433"/3"@69?246"CD"214"9.0@=/I@2/9=J3"?.9K4:23"/="214":9=24L2"9<"214":A329B4.".4GA/.4B4=23H"

8.9:433"9A2:9B43"@.4"A346" 29"64B9=32.@24"3A::433<A-"@:1/454B4=2"9<" 214"?A.?934"9<"@"?.9:433H"71/3"14-?3"

?.9:433"@334339.3"29"6424.B/=4"214":@?@C/-/2D"9<"214"9.0@=/I@2/9=J3"/B?-4B4=246"?.9:433"@=6"29"?.95/64"39A.:4"

B@24./@-"29"?-@="9.0@=/I@2/9=@-"?.9:433"/B?.954B4=2H"

MC)C)' "AII78H'45'V;59'&H@>9'?84@9<<9<'

714.4" @.4" 2E9" B@K9." 3ACM6/5/3/9=3" 9<" ?.9:433" /=" 21/3" #=24.=@2/9=@-" $2@[email protected]" (-@A34" N" ?.95/643" @" 3D324B"

:9=24L2"<9."64@-/=0"E/21"@"32@=6@-9=4"39<[email protected]"?.96A:2"9."34.5/:4"9."@"39<[email protected]"3D324BH"(-@A34"O":9=2@/=3"214"

39<[email protected]?4:/</:" ?.9:43343" <9." A34" /=" /B?-4B4=2/=0" @" 39<[email protected]" ?.96A:2" 9." 34.5/:4" 21@2" /3" @=" 4-4B4=2" 9<" @"

[email protected]."3D324BH"

79"@/6"214":9=:A..4=2"A34"9<"#$%&#'("PQ)++"@=6"#$%&#'("P))*OF":9..43?9=6/=0"?.9:43343"9<"(-@A34"N"1@54"

214"3@B4"3AC:-@A34"=ABC4."R@2"214"NHLHL"-454-SH""

#=" 04=4.@-F" 214" :9--4:2/9=" 9<" ?.9:43343" ?.95/646" /=" 21/3" #=24.=@2/9=@-" $2@[email protected]" @.4" 39<[email protected]@??.9?./@24"

3?4:/@-/I@2/9=3F"9.":9=2./CA2/9=3"29" 214"9A2:9B43"9<" 214"?.9:43343"?.95/646" /=" #$%&#'("PQ)++H" ">@=D"9<" 214"

#$%&#'(" PQ)++" ?.9:43343" 344B" 3/B/-@." 29" 39<[email protected]?4:/</:" ?.9:433" /B?-4B4=2@2/9=3F" CA2" 214D" ?.434.54"

:.A:/@-" 6/32/=:2/9=3" C@346" 9=" 214" ?A.?934F" 9A2:9B43" @=6" @A6/4=:43H" T34.3" 9<" C921" #$%&#'(" PQ)++" @=6"

#$%&#'("P))*O"319A-6"C4"3A.4"29":9=3/64."214"6/32/=:2"4L?-@=@2/9=3"@=6"=9243"/="4@:1"3?4:/</:"?.9:433H"

©2011 Walz

IEEE Life Cycle Process groups

7© IEEE

©2011 Walz

CMMI-DEV Categories of Process Areas

8buildsecurityin.us-cert.gov © Carnegie Mellon University 2005-2011

©2011 Walz

IEEE Life Cycle Processes

9

Process Purpose

Outcomes

Activities

Tasks,•shall,•should,•may

Information Products (Artifacts) •Records, •Documents e.g. Plans

Related processes

©2011 Walz

CMMI Model Components

10

CMMI for Development, Version 1.3

Process Area Components 10

Before goals can be considered to be satisfied, either their practices as described, or acceptable alternatives to them, must be present in the planned and implemented processes of the organization.

Informative Components

Informative components are CMMI components that help model users understand CMMI required and expected components. These components can be example boxes, detailed explanations, or other helpful information. Subpractices, notes, references, goal titles, practice titles, sources, example work products, and generic practice elaborations are informative model components.

The informative material plays an important role in understanding the model. It is often impossible to adequately describe the behavior required or expected of an organization using only a single goal or practice statement.

the correct understanding of goals and practices and thus cannot be ignored.

!"#$"%&%'()*(("+,-'&.)/,'0)1-2')3/")

The model components associated with Part Two are summarized in Figure 2.1 to illustrate their relationships.

!Process Area

Generic PracticesGeneric Practices

Generic GoalsGeneric Goals

Expected InformativeInformativeRequiredKEY:

Purpose Statement

IntroductoryNotes

RelatedProcess Areas

SubpracticesSubpractices

Specific GoalsSpecific Goals

Specific PracticesSpecific Practices

Typical WorkProducts

Example WorkProducts

SubpracticesSubpractices SubpracticesGeneric Practice Elaborations

!

Figure 2.1: CMMI Model Components

The following sections provide detailed descriptions of CMMI model components.

© Carnegie Mellon University 2005-2011

©2011 Walz

Processes and Products QA

ISO/IEC/IEEEProcess → Activities → Tasks → Artifacts, Records, Documents (Plans)

CMMI-DEV v1.3Process Area → Goals → Practices → Artifacts, Records, Documents (Plans)

IEEE 730 SQA Process-2011 IEEE 730 SQA Plan-2002, 2011

PPQA Process & Product QAVER Verification SG Process Specific Goal

SP Process Specific Practices

11

GP Generic Practices

©2011 Walz

Basic Support Process Areas

12

CMMI for Development, Version 1.3

Relationships Among Process Areas 51

Causal Analysis and Resolution (CAR) Configuration Management (CM) Decision Analysis and Resolution (DAR) Measurement and Analysis (MA) Process and Product Quality Assurance (PPQA)

Basic Support Process Areas

The Basic Support process areas address fundamental support functions that are used by all process areas. Although all Support process areas rely on the other process areas for input, the Basic Support process areas provide support functions that also help implement several generic practices.

-eye view of the interactions among the Basic Support process areas and with all other process areas.

!

All process areas

Measurements and analyses

Information needs

Controlled configuration items, baselines, and audit reports

Processes and work products, standards, and procedures

Quality and noncompliance issues

Configuration items and change requests

PPQAMA

CM

MA = Measurement and AnalysisCM = Configuration Management

PPQA = Process and Product Quality Assurance Figure 4.6: Basic Support Process Areas

The Measurement and Analysis process area supports all process areas by providing specific practices that guide projects and organizations in aligning measurement needs and objectives with a measurement approach that is used to support management information needs. The results can be used in making informed decisions and taking appropriate corrective actions.

The Process and Product Quality Assurance process area supports all process areas by providing specific practices for objectively evaluating performed processes, work products, and services against the applicable

© Carnegie Mellon University 2005-2011

©2011 Walz

Engineering Process Areas

13

CMMI for Development, Version 1.3

Relationships Among Process Areas 48

!

RD PI

VAL

TS

VER

Requirements

Customer needs

Product and product component requirements

Requirements, Product components, work products, verification and validation reports

Product components

Alternative solutions Product

Customer

PI = Product IntegrationRD = Requirements DevelopmentTS = Technical SolutionVAL = ValidationVER = Verification

Project Management process areas

Requirements

Figure 4.5: Engineering Process Areas

The Requirements Development process area identifies customer needs and translates these needs into product requirements. The set of product requirements is analyzed to produce a high-level conceptual solution. This set of requirements is then allocated to establish an initial set of product component requirements.

Other requirements that help define the product are derived and allocated to product components. This set of product and product component

design features, verification requirements, etc., in terms the developer understands and uses.

The Requirements Development process area supplies requirements to the Technical Solution process area, where the requirements are converted into the product architecture, product component designs, and product components (e.g., by coding, fabrication). Requirements are also supplied to the Product Integration process area, where product components are combined and interfaces are verified to ensure that they meet the interface requirements supplied by Requirements Development.

© Carnegie Mellon University 2005-2011

©2011 Walz

Process and ProductQuality Assurance - SGs

Reports and Records

SG 1: Objectively Evaluate Processes and Work Products

SG 2: Provide Objective Insight

Objectively

EvaluateProcesses

EstablishRecords

Communicateand Ensure

Resolution ofNoncompliance

Issues

ObjectivelyEvaluate

Work Products

& Services

Copyright 2002 Carnegie Mellon University

RelevantStakeholders

•Project Manager•Sr. Managers•Team Members•Other functional areas

Systems Engineering Process Office – SSC San Diego, US Navy 14

©2011 Walz

Verification - SGs

15

Select Work Products forVerification

SG 1: Prepare for Verification

Establish theVerification

Environment

EstablishVerification Proceduresand Criteria

- Verification Environment- Verification Procedures and Criteria- List of Work Products- Selected for Verification

Preparefor Peer Reviews Requirement for Data

CollectionEntry and Exit CriteriaPeer Review Plan

Review ResultsReview IssuesReview DataAction Items

ConductPeer

Reviews

SG 2: Perform Peer Reviews

AnalyzePeer Review

Data

PerformVerification

Verification ResultsDeficienciesVerification DataCorrective Actions

SG 3: Verify Selected Work Products

Analyze Verification

Results

Copyright 2002 Carnegie Mellon University

Systems Engineering Process Office – SSC San Diego, US Navy

©2011 Walz

CMMI-DEV PPQA & VER Specific Goals (SGx) & Specific Practices (SPx.y)

PPQA & VER Specific Practices (SP)PPQA SP1.1 Objectively evaluate selected performed processes against applicable process descriptions, standards, and procedures.PPQA SP1.2 Objectively evaluate selected work products against applicable process descriptions, standards, and procedures.PPQA SP 2.1 Communicate quality issues and ensure the resolution of noncompliance issues with the staff and managers.PPQA SP 2.2 Establish and maintain records of the quality assurance activities.VER SP 1.1 Select work products to be verified and verification methods to be UsedVER SP 2.2 Conduct peer reviews of selected work products and identify issues resulting from these reviews.VER SP 2.3 Analyze data about the preparation, conduct, and results of the peer reviewsVER SP 3.2 Analyze results of all verification activities

CMMI-DEV v1.3 PPQA & VER Specific Goals (SG)PPQA SG 1 Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.

PPQA SG 2 Noncompliance issues are objectively tracked and communicated, and resolution is ensured.

VER SG 1 Preparation for verification is conducted.VER SG 2 Peer reviews are performed on selected work products.VER SG 3 Selected work products are verified against their specified requirements.

16

©2011 Walz

P730 SQA Outcomes - CMMI Goals

17

P730 / IS 12207 SQA Outcomes CMMI-DEV Goalsa) a strategy for conducting quality assurance is developed;

GP 2.2 Establish and maintain the plan for performing the process.

b) evidence of software quality assurance is produced and maintained;

GP 2.9 Objectively evaluate adherence of the process and selected work products against the process description, standards, and procedures, and address noncompliance.

b) evidence of software quality assurance is produced and maintained;

PPQA SG 1 Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.

c) problems and/or non-conformance with requirements are identified and recorded; and

PPQA SG 2 Noncompliance issues are objectively tracked and communicated, and resolution is ensured.

d) adherence of products, processes and activities to the applicable standards, procedures and requirements are verified.

VER SG 1 Preparation for verification is conducted.d) adherence of products, processes and activities to the applicable standards, procedures and requirements are verified. VER SG 2 Peer reviews are performed on selected

work products.

d) adherence of products, processes and activities to the applicable standards, procedures and requirements are verified.

VER SG 3 Selected work products are verified against their specified requirements.

IEEE 730 has four outcomes which related to CMMI Goals

©2011 Walz

P730 / IS 12207 SQA Tasks

18

IS 12207 SQA Process Tasks

1.1 A quality assurance process suited to the project shall be established. The objectives of the quality assurance process shall be to assure that the software products and the processes employed for providing those software products comply with their established requirements and adhere to their established plans.

1.2 The quality assurance process should be coordinated with the related Software Verification (subclause 7.2.4), Software Validation (subclause 7.2.5), Software Review (subclause 7.2.6), and Software Audit (subclause 7.2.7) Processes.

1.3 A plan for conducting the quality assurance process activities and tasks shall be developed, documented, implemented, and maintained for the life of the contract. The plan shall include the following:

a) Quality standards, methodologies, procedures, and tools for performing the quality assurance activities (or their references in organization's official documentation).

b) Procedures for contract review and coordination thereof.c) Procedures for identification, collection, filing, maintenance, and disposition of quality records.d) Resources, schedule, and responsibilities for conducting the quality assurance activities.e) Selected activities and tasks from supporting processes, such as Software Verification (subclause 7.2.4), Software

Validation (subclause 7.2.5), Software Review (subclause 7.2.6), Software Audit (subclause 7.2.7), and Software Problem Resolution (subclause 7.2.8).

1.4 Scheduled and on-going quality assurance activities and tasks shall be executed. When problems or non-conformances with contract requirements are detected, they shall be documented and serve as input to the Problem Resolution Process (subclause 7.2.8). Records of these activities and tasks, their execution, problems, and problem resolutions shall be prepared and maintained.

1.5 Records of quality assurance activities and tasks shall be made available to the acquirer as specified in the contract.

1.6 It shall be assured that persons responsible for assuring compliance with the contract requirements have the organizational freedom, resources, and authority to permit objective evaluations and to initiate, effect, resolve, and verify problem resolutions.

©2011 Walz

P730 / IS 12207 Tasks

19

IS 12207 SQA Process Tasks

2.1 It shall be assured that all the plans required by the contract are documented, comply with the contract, are mutually consistent, and are being executed as required.

2.2 It shall be assured that software products and related documentation comply with the contract and adhere to the plans.

2.3 In preparation for the delivery of the software products, it shall be assured that they have fully satisfied their contractual requirements and are acceptable to the acquirer.

3.1 It shall be assured that those software life cycle processes (supply, development, operation, maintenance, and support processes including quality assurance) employed for the project comply with the contract and adhere to the plans.

3.2 It shall be assured that the internal software engineering practices, development environment, test environment, and libraries comply with the contract.

3.3 It shall be assured that applicable prime-contract requirements are passed down to the subcontractor, and that the subcontractor's software products satisfy prime-contract requirements.

3.4 It shall be assured that the acquirer and other parties are provided the required support and cooperation in accordance with the contract, negotiations, and plans.

3.5 It should be assured that software product and process measurements are in accordance with established standards and procedures.

3.6 It shall be assured that the staff assigned have the skill and knowledge needed to meet the requirements of the project and receive any necessary training.

4.1 Additional quality management activities may be assured in accordance with the clauses of ISO 9001.

©2011 Walz

Map Process Areas to P730 Tasks

20

CMMI has several Process Areas whose Specific Practices (SP) and two overall General Practices (GP) related to IEEE 730 15 of the 16 Tasks.CMMI Specific Practices (SP) and General Practices (GP)

730 Tasks

PPQA SP1.1 Objectively evaluate selected performed processes against applicable process descriptions, standards, and procedures.

1.1 3.1 3.2 3.5

PPQA SP1.2 Objectively evaluate selected work products against applicable process descriptions, standards, and procedures.

1.1 2.1 2.3 3.5

PPQA SP 2.1 Communicate quality issues and ensure the resolution of noncompliance issues with the staff and managers.

1.4 1.6

PPQA SP 2.2 Establish and maintain records of the quality assurance activities.

1.5

VER SP 1.1 Select work products to be verified and verification methods to be Used

2.13.3

VER SP 2.2 Conduct peer reviews of selected work products and identify issues resulting from these reviews.

2.2

VER SP 2.3 Analyze data about the preparation, conduct, and results of the peer reviews

2.23.3

VER SP 3.2 Analyze results of all verification activities 2.22.33.3

©2011 Walz

Map PPQA & VER to P730 Tasks, continued

CMMI Specific Practices (SP) and General Practices (GP)

730 Tasks

OPD SP 1.1 Establish and maintain the organization’s set of standard processes. (especially subpratice 6 -- Ensure that there is appropriate integration among processes that are included in the organization’s set of standard processes)

OPF SP 3.2 Deploy the organization’s set of standard processes to projects at their startup and deploy changes to them as appropriate throughout the life of each project. (especially subpractice 6 -- Ensure that the defined processes resulting from process tailoring are incorporated into plans for process-compliance audits)

1.2

OT SP 2.1 Deliver training following the organizational training tactical plan. 3.6

GP 2.1 Establish and maintain the plan for performing the process. 1.3

GP 2.3 Provide adequate resources for performing the process, developing the work products, and providing the services of the process.

3.4

Missing from CMMI 4.1

21

©2011 Walz

Mapping Typical Work Products (WP)

SP WP SP Work Products examples IS 15289 SQA Info Products1.1.WP.1 Evaluation reports 10.22 Evaluation report1.1.WP.2 Noncompliance reports 10.41 Problem report1.1.WP.3 Corrective actions Quality Activity Record1.2.WP.1 Evaluation reports 10.22 Evaluation report1.2.WP.2 Noncompliance reports 10.41 Problem report1.2.WP.3 Corrective actions Quality Activity Record2.1.WP.1 Corrective action reports Quality Activity Record2.1.WP.2 Evaluation reports 10.22 Evaluation report2.1.WP.3 Quality trends2.2.WP.1 Evaluation logs 10.22 Evaluation report2.2.WP.2 Quality assurance reports Quality Activity Record2.2.WP.3 Status reports of corrective actions Quality Activity Record2.2.WP.4 Reports of quality trends

22

Each CMMI Process Area Specific Practices have examples of Work Products. Below table show the best match to IEEE 730 Outcome typical deliverables as named by IS 15289 Information Products.

©2011 Walz

Conclusion: Good Fit

23

CMMI-DEV

IEEE / ISO / IEC 15288 / 12207

PPQA

SQA

©2011 Walz

Acronyms• CMMI ! Capability Maturity Model Integration• CMMI-DEV ! CMMI for Development• GP ! ! generic practice• IEEE ! Institute of Electrical and Electronics Engineers• IEEE 15288 system engineering life cycle processes • IEEE 12207 software engineering life cycle processes• IS ! ! International Standard, IEEE/ISO/IEC• ISO/IEC ! International Organization for Standardization and

International Electrotechnical Commission• PPQA ! Process and Product Quality Assurance (process area)• SQA ! software quality assurance• SCAMPI ! Standard CMMI Appraisal Method for Process Improvement• SG ! ! specific goal• SP ! ! specific practice• VER ! Verification (process area)

24

©2011 Walz 30

Where you can help?

• Attend a working group meeting in person or via LiveMeeting and phone,or

• Follow the working group progress, or• Review the draft standard, or• Ballot for the final standard, or• Participant in the User Group

• Send email to [email protected] and ask to be part of the listserv

26

Questions?