Best Practice Information Aids for CMMI SM -Compliant Process Engineering Updated Mapping & Examples...

Best Practice Information Aidsfor CMMISM-Compliant Process

EngineeringUpdated Mapping & Examples

Paul R. CrollChair, IEEE Software Engineering Standards

CommitteeVice Chair, ISO/IEC JTC1/SC7 U.S. TAGComputer Sciences Corporation

[email protected]

A Preparatory Exercise

Paul R. Croll - 2

How many of you know that there are two Framework Standards

forSystem and SoftwareLife Cycle Processes?

Paul R. Croll - 3

How many of you know that there are thirty+ Supporting Standards

forSoftware and SystemsProcess Engineering?

Paul R. Croll - 4

2nd Annual CMMISM Technology Conference and Users Group – Practical Guidance Part 1 –13 November 2002Copyright 2002, Paul R. Croll, All rights reserved

Paul R. Croll - 5

8 Steps to Success With Best Practice Information Aids

1Understand

your business processes

2Look to the CMMISM for

Process Completeness

3Look to

Framework Standards for Life Cycle Definition

4Look to

Supporting Standards for Process Detail

5 Build or Refine Your Process Architecture

6 Execute Your Processes

7 Measure Your Results - Modify

Processes as Necessary

333

3

8 Confirm Your Status With Independent Appraisals


Paul R. Croll - 6

Step 1 – Understand your business processes


Paul R. Croll - 7

Your Business is Your Business – It’s Not CMMISM Implementation

You must fully understand your business processes before you can address process completeness or process compliance.

What are your business processes? Are they well-documented? Are roles and responsibilities well-defined? Are lines of authority well-defined? Are internal and external interfaces well-

defined? Do your business processes satisfy your

business goals?

Decision

Decision

Branch

Else

Branch

Else

Activity 1

Activity 2

Activity 5

Activity 4

Activity 3

Activity 6

End

AND

AND


Paul R. Croll - 8

Step 2 - Look to the CMMISM for Process Completeness


Paul R. Croll - 9

The CMMISM Is A Process Framework Model

Contains the essential elements of effective processes for one or more disciplines

Contains a framework that provides the ability to generate multiple models and associated training and assessment materials. These models may represent:

software and systems engineering integrated product and process development new disciplines combinations of disciplines

Provides guidance to use when developing processes


Paul R. Croll - 10

What The CMMISM Is Not

CMMI models are not processes or process descriptions. Actual processes depend on:

Application domain(s) Organization structure Organization size Organization culture Customer requirements or constraints


Paul R. Croll - 11

The CMMISM as a Guide to Process Completeness

Process Management Engineering

Organizational Process Focus Requirements Management Organizational Process Definition Requirements Development Organizational Training Technical Solution Organizational Process

Performance Product Integration Verification

Organizational Innovation andDeployment

Validation

Project Management Support

Project Planning Configuration Management Project Monitoring and Control Supplier Agreement Management

Process and Product Quality Assurance Measurement and Analysis

Integrated Project Management for IPPD Decision Analysis and Resolution Risk Management Integrated Teaming Causal Analysis and Resolution

Quantitative Project Management Integrated Supplier Management

Organizational Environment for Integration

Determine if essential elements of your processes are missing or incomplete


Paul R. Croll - 12

Step 3 - Look to Framework Standards for Life Cycle Definition


Paul R. Croll - 13

Standards As Sources of Best Practice Information

Standards, are consensus-based documents that codify best practice. Consensus-based standards have seven essential attributes that aid in process engineering. They:

represent the collected experience of others who have been down the same road,

tell in detail what it means to perform a certain activity, can be attached to or referenced by contracts, help to assure that two parties have the same meaning for an

engineering activity, increase professional discipline, protect the business and the buyer, improve the product.


Paul R. Croll - 14

Process Framework Standards

Systems Life Cycle ISO/IEC 15288

Software Life Cycle ISO/IEC 12207 IEEE/EIA 12207.0, 12207.1, 12207.2

Process Assessment ISO/IEC 15504


Paul R. Croll - 15

The ISO/IEC 15288 SystemsLife Cycle Process Framework

SYSTEM LIFE CYCLE

PROJECT ASSESSMENT

PROJECT PLANNING

PROJECT CONTROLDECISION MAKING

RISK MANAGEMENTCONFIGURATION MANAGEMENT

INFORMATION MANAGEMENT

ENTERPRISE(5)

SYSTEM LIFE CYCLE MANAGEMENT

RESOURCE MANAGEMENT

QUALITY MANAGEMENT

ENTERPRISE ENVIRONMENT MANAGEMENT

INVESTMENT MANAGEMENT

TECHNICAL (11)

PROJECT (7)

ACQUISITION

SUPPLYAGREEMENT (2)

TRANSITIONSTAKEHOLDER REQUIREMENTS DEFINITION

REQUIREMENTS ANALYSISARCHITECTURAL DESIGN

IMPLEMENTATIONINTEGRATION

VERIFICATION

VALIDATIONOPERATION

MAINTENANCEDISPOSAL

(25)


Paul R. Croll - 16

The IEEE/EIA 12207 Software Life Cycle Process Framework

SOFTWARE LIFE CYCLE

TAILORING

CONFIGURATION MANAGEMENTDOCUMENTATION

QUALITY ASSURANCEVERIFICATION

VALIDATIONJOINT REVIEW

AUDITPROBLEM RESOLUTION

PRIMARY (5)

DEVELOPMENT

OPERATION

MAINTENANCE

ACQUISITION

SUPPLY

ORGANIZATIONAL (4)MANAGEMENT

INFRASTRUCTUREIMPROVEMENT

TRAINING

SUPPORTING (8)

Source: Singh97

(17+1)


Paul R. Croll - 17

Relationship between ISO/IEC 15288 and ISO/IEC 12207

Hardware Implementation

Software ImplementationRefer to ISO/IEC 12207

Human TaskImplementation

Acquisition

Supply

Enterprise Environment Management

Investment Management

System Life Cycle Processes Management

Resource Management

Quality Management

Implementation

StakeholderRequirements

Definition

Requirements Analysis

Architectural Design Integration

Verification

Transition

Validation Operation

Disposal

Maintenance

Project Planning Project Assessment Project Control

Configuration ManagementRisk ManagementDecision Making Information Management

Usability

Source:ISO/IEC JTC 1/SC 7/WG 7 N0643, 2002-10-20, © ISO/IEC2002.

Projectprocesses

Enterpriseprocesses

Agreementprocesses

Technicalprocesses


Paul R. Croll - 18

But Wait . . . The Life Cycle Standards Are Not Consistent!!


Paul R. Croll - 19

Harmonization –Consistency Goals

Concepts Terminology Readability Level of detail Processes Document structure Normative references Common interfacing mechanism with the ISO 9000 family of

standards Conformance with requirements from ISO/IEC 15504 as

applicable


Paul R. Croll - 20

Harmonization –Priorities

Primary ISO/IEC 15288 ISO/IEC 12207

Secondary ISO/IEC 15939 - Software measurement process ISO/IEC TR 15271 Guide for 12207 ISO/IEC TR 19760 Guide for 15288 ISO/IEC TR 15504 - parts 5 and 6

Possible Additional ISO/IEC 14764 Software maintenance ISO/IEC TR 16326 Project management ISO/IEC 18019 Documentation process ISO/IEC TR 15846 Configuration management


Paul R. Croll - 21

Life Cycle Standards Harmonization Phasing

ISO/IEC 15288 & 12207

Guides

ISO/IEC 15939

others

ISO/IEC 15288 & 12207

Guides

ISO/IEC 15939

others

2002/2005 ?? ?? ??

Source:ISO/IEC JTC 1/SC 7/WG 7 N0618, 2002-7-21 , © ISO/IEC2002.


Paul R. Croll - 22

Step 4 – Look to Supporting Standards For Process Detail


Paul R. Croll - 23

Best Practice Support for the System Life Cycle Framework

Source:Guide for ISO/IEC 15288 (System Life Cycle Processes), PDTR, © ISO/IEC2002.

Concept Development Production Utilization Support Retirement

ISO/IEC 15288 Life Cycle Model Stages

ISO/IEC 15288 system life cycle processes

Incr

easi

ng

le

vel

of

det

ail

Task

Life cycle progression

Concept Development Production Utilization Support Retirement

ISO/IEC 15288 Life Cycle Model Stages

ISO/IEC 15288 system life cycle processes

Task level detail from a

3rd Standard

For example,

IEEE 1220

Incr

easi

ng

le

vel

of

det

ail

Life cycle progression

Activity level detail from a 2nd StandardFor example, ANSI/EIA 632

Activity level detail from a 4th Standard

A1. ISO/IEC 15288 and other engineering standards

Task level detail from a

5th Standard


Paul R. Croll - 24

Best Practice Support for the Software Life Cycle Framework

Source:IEEE/EIA 12207.1-1997, © IEEE 1998.


Paul R. Croll - 25

CMMISM SE/SW/IPPD/SS v1.1 Mapping - Process Management

Process Management

EIA 632 - Processes for Engineering a System

IEEE 1220, Application and Management of the Systems Engineering Process

IEEE 1074, Developing Software Life Cycle Processes

1517-1999, Reuse Processes

ISO/IEC 15288, System Life Cycle Processes

IEEE 12207.0, Software Life Cycle Processes

IEEE 12207.1, Guide to Software Life Cycle Processes—Life Cycle Data

IEEE 12207.2, Guide to Software Life Cycle Processes—Implementation Considerations

CMMISM SE/SW/IPPD/SS v1.1Process Area/Specific Practice

Framework Standards

Supporting Standards


Paul R. Croll - 26

CMMISM SE/SW/IPPD/SS v1.1 Mapping – Project Management

Project Management

IEEE 1220, Application and Management of the Systems Engineering Process

IEEE 1058, Software Project Management Plans

IEEE 1490, A Guide to the Program Management Body of Knowledge

IEEE 1062, Recommended Practice for Software Acquisition

IEEE 1540, Risk Management IEEE 1028, Software Reviews






Paul R. Croll - 27

CMMISM SE/SW/IPPD/SS v1.1 Mapping – Engineering

Engineering

IEEE 1233, Guide for Developing System Requirements Specifications

IEEE 1362, Guide for Concept of Operations Document

IEEE 1471, Architectural Description of Software Intensive Systems

IEEE 830, Software Requirements Specifications

IEEE 1016, Software Design Descriptions

IEEE 1012, Software Verification and Validation

IEEE 1008, Software Unit Testing





IEEE 1228, Software Safety Plans IEEE 1063, Software User Documentation IEEE 1219, Software Maintenance IEEE 1320.1,.2, IDEF0, IDEF1X97 IEEE 1420.1, Data Model for Reuse

Library Interoperability


Paul R. Croll - 28

CMMISM SE/SW/IPPD/SS v1.1 Mapping – Support

Support

IEEE 828, Software Configuration Management Plans

IEEE 730, Software Quality Assurance Plans

IEEE 982.1, Dictionary of Measures to Produce Reliable Software

IEEE 1045, Software Productivity Metrics

IEEE 1061, Software Quality Metrics Methodology

IEEE 1219, Software Maintenance





IEEE 1465 (ISO/IEC 12119) - Software Packages - Quality Requirements and Testing

IEEE 14143.1 (ISO/IEC 1443-1) - Functional Size Measurement - Part 1: Definition of Concepts


Paul R. Croll - 29

Requirements Development

SP 2.1-1 Establish Product and Product Component Requirements

Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability


Clause 5.5.3 - Requirements Analysis Process

IEEE/EIA 12207.0, Software Life Cycle Processes

Clause 5.3.2 - System Requirements Analysis

Clause 5.3.4 - Software requirements analysis




Paul R. Croll - 30











5.5.3 Requirements Analysis Process5.5.3.1 Purpose of the Requirements Analysis ProcessThe purpose of the Requirements Analysis Process is to transform the stakeholder, requirement-driven view of desired services into a technical view of a required product that could deliver those services.This process builds a representation of a future system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the developer’s perspective, what characteristics it is to possess and with what magnitude in order to satisfy stakeholder requirements.5.5.3.2 Requirements Analysis Process OutcomesAs a result of the successful implementation of the Requirements Analysis Process:a) The required characteristics, attributes, and functional and performance requirements for a product solution are specified.b) Constraints that will affect the architectural design of a system and the means to realize it are specified.c) The integrity and traceability of system requirements to stakeholder requirements is achieved.. . .

Source: ISO/IEC CD 15288 FDIS, © ISO/IEC2002.


Paul R. Croll - 31











5.3.2.1 The specific intended use of the system to be developed shall be analyzed to specify system requirements. The system requirements specification shall describe: functions and capabilities of the system; business, organizational and user requirements; safety, security, human-factors engineering (ergonomics), interface, operations, and maintenance requirements; design constraints and qualification requirements. The system requirements specification shall be documented.5.3.4.1 The developer shall establish and document software requirements, including the quality characteristics specifications, described below. . . .a) Functional and capability specifications, including performance, physical characteristics, and environmental conditions under which the software item is to perform;b) Interfaces external to the software item; c) Qualification requirements;d) Safety specifications, including those related to methods of operation and maintenance, environmental influences, and personnel injury; e) Security specifications, including those related to compromise of sensitive information . . .

Source: IEEE/EIA 12207.0-1997, © IEEE 2001.


Paul R. Croll - 32











7.2 Build a well-formed requirementThe analysts carry out this subphase by doing the following:a) Ensuring that each requirement is a necessary, short, definitive statement of need (capability, constraints);b) Defining the appropriate conditions (quantitative or qualitative measures) for each requirement and avoiding adjectives such as “resistant” or “industry wide;”c) Avoiding requirements pitfalls (see 6.4);d) Ensuring the readability of requirements, which entails the following: 1) Simple words/phrases/concepts; 2) Uniform arrangement and relationship; 3) Definition of unique words, symbols, and notations; 4) The use of grammatically correct language and symbology.e) Ensuring testability.Example: Capability: Move people between Los Angeles and New York Condition: Cruising speed of 200 km/hr Constraint: Maximum speed of 300 km/hr Well-formed requirement: This system should move people between Los Angeles and New York at an optimal cruising speed of 200 km/hr with a maximum speed of 300 km/hr.

Source: IEEE 1233-1998, © IEEE 1998.


Paul R. Croll - 33











Source: IEEE 1233-1998, © IEEE 1998.


Paul R. Croll - 34











5.3.2 FunctionsFunctional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. These are generally listed as “shall” statements starting with “The system shall”These include:a) Validity checks on the inputsb) Exact sequence of operationsc) Responses to abnormal situations, including: 1) Overflow 2) Communication facilities 3) Error handling and recoveryd) Effect of parameterse) Relationship of outputs to inputs . . . 1) It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This doesnot imply that the software design will also be partitioned that way.5.3.3 Performance requirementsThis subsection should specify both the static and the dynamic numerical requirements placed on the soft-ware or on human interaction with the software as a whole. Static numerical requirements may include thefollowing:a) The number of terminals to be supported;b) The number of simultaneous users to be supported;c) Amount and type of information to be handled.

Source:IEEE 830-1998, © IEEE 1998.


Paul R. Croll - 36

8 Steps to Success With Best Practice Information Aids

1Understand

your business processes

2Look to the CMMISM for

Process Completeness

3Look to

Framework Standards for Life Cycle Definition

4Look to

Supporting Standards for Process Detail

5 Build or Refine Your Process Architecture

6 Execute Your Processes

7 Measure Your Results - Modify

Processes as Necessary

333

3

8 Confirm Your Status With Independent Appraisals


Paul R. Croll - 37

The IEEE CMMISM Mapping Project


Paul R. Croll - 38

The IEEE CMMISM Mapping Project – Background

Study Group on External Standards Coordination formed

Initial Task: Map the IEEE Software Engineering Standards Collection to the CMMISM.

Software Productivity Consortium’s Quagmap selected as the mapping tool.

License agreements for distribution of Standards and the Quagmap tool to Study Group members negotiated and signed.

Results to be published on the SESC web site.

B e s t P r a c t i c e I n f o r m a t i o n A i d s f o r

C M M I S M - C o m p l i a n t P r o c e s s E n g i n e e r i n g 6 1 0 . 1 2 - 1 9 9 0 I E E E S t a n d a r d G l o s s a r y o f S o f t w a r e E n g i n e e r i n g T e r m i n o l o g y 7 3 0 - 1 9 9 8 I E E E S t a n d a r d f o r S o f t w a r e Q u a l i t y A s s u r a n c e P l a n s 8 2 8 - 1 9 9 8 I E E E S t a n d a r d f o r S o f t w a r e C o n f i g u r a t i o n M a n a g e m e n t P l a n s 8 2 9 - 1 9 9 8 I E E E S t a n d a r d f o r S o f t w a r e T e s t D o c u m e n t a t i o n 8 3 0 - 1 9 9 8 I E E E R e c o m m e n d e d P r a c t i c e f o r S o f t w a r e R e q u i r e m e n t s S p e c i f i c a t i o n s 9 8 2 . 1 - 1 9 8 8 I E E E S t a n d a r d D i c t i o n a r y o f M e a s u r e s t o P r o d u c e R e l i a b l e S o f t w a r e 1 0 0 8 - 1 9 8 7 I E E E S t a n d a r d f o r S o f t w a r e U n i t T e s t i n g 1 0 1 2 - 1 9 9 8 I E E E S t a n d a r d f o r S o f t w a r e V e r i f i c a t i o n a n d V a l i d a t i o n 1 0 1 2 a - 1 9 9 8 I E E E S t a n d a r d f o r S o f t w a r e V e r i f i c a t i o n a n d V a l i d a t i o n - S u p p l e m e n t t o 1 0 1 2 - 1 9 9 8 - C o n t e n t M a p

t o I E E E 1 2 2 0 7 . 1 1 0 1 6 - 1 9 9 8 I E E E R e c o m m e n d e d P r a c t i c e f o r S o f t w a r e D e s i g n D e s c r i p t i o n s 1 0 2 8 - 1 9 9 7 I E E E S t a n d a r d f o r S o f t w a r e R e v i e w s 1 0 4 4 - 1 9 9 3 I E E E S t a n d a r d C l a s s i f i c a t i o n f o r S o f t w a r e A n o m a l i e s 1 0 4 5 - 1 9 9 2 I E E E S t a n d a r d f o r S o f t w a r e P r o d u c t i v i t y M e t r i c s 1 0 5 8 - 1 9 9 8 I E E E S t a n d a r d f o r S o f t w a r e P r o j e c t M a n a g e m e n t P l a n s 1 0 5 8 . 1 - 1 9 8 7 I E E E S t a n d a r d f o r S o f t w a r e P r o j e c t M a n a g e m e n t P l a n s 1 0 6 1 - 1 9 9 8 I E E E S t a n d a r d f o r S o f t w a r e Q u a l i t y M e t r i c s M e t h o d o l o g y 1 0 6 2 , 1 9 9 8 I E E E R e c o m m e n d e d P r a c t i c e f o r S o f t w a r e A c q u i s i t i o n ( i n c l u d e s I E E E 1 0 6 2 a ) 1 0 6 3 - 2 0 0 1 I E E E S t a n d a r d f o r S o f t w a r e U s e r D o c u m e n t a t i o n 1 0 7 4 - 1 9 9 7 I E E E S t a n d a r d f o r D e v e l o p i n g S o f t w a r e L i f e C y c l e P r o c e s s e s 1 2 1 9 - 1 9 9 8 I E E E S t a n d a r d f o r S o f t w a r e M a i n t e n a n c e 1 2 2 0 - 1 9 9 8 I E E E S t a n d a r d f o r t h e A p p l i c a t i o n a n d M a n a g e m e n t o f t h e S y s t e m s E n g i n e e r i n g P r o c e s s 1 2 2 8 - 1 9 9 4 I E E E S t a n d a r d f o r S o f t w a r e S a f e t y P l a n s 1 2 3 3 , 1 9 9 8 I E E E G u i d e f o r D e v e l o p i n g S y s t e m R e q u i r e m e n t s S p e c i f i c a t i o n s ( i n c l u d i n g I E E E 1 2 3 3 a ) 1 3 2 0 . 1 - 1 9 9 8 I E E E S t a n d a r d f o r F u n c t i o n a l M o d e l i n g L a n g u a g e - S y n t a x a n d S e m a n t i c s f o r I D E F 0 1 3 2 0 . 2 - 1 9 9 8 I E E E S t a n d a r d f o r C o n c e p t u a l M o d e l i n g L a n g u a g e S y n t a x a n d S e m a n t i c s f o r I D E F 1 X 9 7 ( I D E F o b j e c t ) 1 3 6 2 - 1 9 9 8 I E E E G u i d e f o r I n f o r m a t i o n T e c h n o l o g y - S y s t e m D e f i n i t i o n - C o n c e p t o f O p e r a t i o n D o c u m e n t 1 4 2 0 . 1 - 1 9 9 5 I E E E S t a n d a r d f o r I n f o r m a t i o n T e c h n o l o g y - - S o f t w a r e R e u s e - - D a t a M o d e l f o r R e u s e L i b r a r y I n t e r o p e r a b i l i t y : B a s i c I n t e r o p e r a b i l i t y D a t a M o d e l ( B I D M ) 1 4 2 0 . 1 a - 1 9 9 6 I E E E S u p p l e m e n t t o S t a n d a r d f o r I n f o r m a t i o n T e c h n o l o g y - - S o f t w a r e R e u s e - - D a t a M o d e l f o r R e u s e L i b r a r y I n t e r o p e r a b i l i t y : A s s e t C e r t i f i c a t i o n F r a m e w o r k 1 4 2 0 . 1 b - 1 9 9 9 I E E E T r i a l - u s e S u p p l e m e n t t o I E E E S t a n d a r d f o r I n f o r m a t i o n T e c h n o l o g y - - S o f t w a r e R e u s e - - D a t a M o d e l f o r R e u s e L i b r a r y I n t e r o p e r a b i l i t y : I n t e l l e c t u a l P r o p e r t y R i g h t s F r a m e w o r k 1 4 6 5 - 1 9 9 8 ( 1 2 1 1 9 : 1 9 9 8 I S O / I E C ) I n f o r m a t i o n T e c h n o l o g y - S o f t w a r e P a c k a g e s - Q u a l i t y R e q u i r e m e n t s a n d T e s t i n g 1 4 7 1 - 2 0 0 0 I E E E R e c o m m e n d e d P r a c t i c e f o r A r c h i t e c t u r a l D e s c r i p t i o n o f S o f t w a r e I n c e n t i v e S y s t e m s 1 4 9 0 - 1 9 9 8 I E E E G u i d e ( © I E E E ) - A d o p t i o n o f P M I S t a n d a r d - A G u i d e t o t h e P r o j e c t M a n a g e m e n t B o d y o f K n o w l e d g e ( © P M I ) 1 5 1 7 - 1 9 9 9 I E E E S t a n d a r d f o r I n f o r m a t i o n T e c h n o l o g y - S o f t w a r e L i f e C y c l e P r o c e s s e s - R e u s e P r o c e s s e s 1 5 4 0 - 2 0 0 1 I E E E S t a n d a r d f o r S o f t w a r e L i f e C y c l e P r o c e s s e s - R i s k M a n a g e m e n t 1 2 2 0 7 . 0 - 1 9 9 6 I E E E / E I A S t a n d a r d : I n d u s t r y I m p l e m e n t a t i o n o f I n t e r n a t i o n a l S t a n d a r d I S O / I E C 1 2 2 0 7 : 1 9 9 5 S t a n d a r d f o r I n f o r m a t i o n T e c h n o l o g y - - S o f t w a r e L i f e C y c l e P r o c e s s e s 1 2 2 0 7 . 1 - 1 9 9 7 I E E E / E I A S t a n d a r d : I n d u s t r y I m p l e m e n t a t i o n o f I n t e r n a t i o n a l S t a n d a r d I S O / I E C 1 2 2 0 7 : 1 9 9 5 S t a n d a r d f o r I n f o r m a t i o n T e c h n o l o g y - - S o f t w a r e L i f e C y c l e P r o c e s s e s - - L i f e c y c l e d a t a 1 2 2 0 7 . 2 - 1 9 9 7 I E E E / E I A S t a n d a r d : I n d u s t r y I m p l e m e n t a t i o n o f I n t e r n a t i o n a l S t a n d a r d I S O / I E C 1 2 2 0 7 : 1 9 9 5 S t a n d a r d f o r I n f o r m a t i o n T e c h n o l o g y - - S o f t w a r e L i f e C y c l e P r o c e s s e s - - I m p l e m e n t a t i o n c o n s i d e r a t i o n s 1 4 1 4 3 . 1 - 2 0 0 0 I m p l e m e n t a t i o n N o t e f o r I E E E A d o p t i o n o f I S O / I E C 1 4 1 4 3 - 1 : 1 9 9 8 , I n f o r m a t i o n T e c h n o l o g y -

S o f t w a r e M e a s u r e m e n t - F u n c t i o n a l S i z e M e a s u r e m e n t - P a r t 1 : D e f i n i t i o n o f C o n c e p t s S M

C M M I i s a s e r v i c e m a r k o f C a r n e g i e M e l l o n U n i v e r s i t y

F o r m o r e i n f o r m a t i o n : h t t p : / / s t a n d a r d s . c o m p u t e r . o r g / s e s c /


Paul R. Croll - 39

The SPC Quagmap Tool

Source:Software Productivity Consortiumwww.software.org


Paul R. Croll - 40

Framework A Framework B

Quagmap Information Structure

Data Item

Data Item

Data Item

Data Item

Data Item

Data Item

…

Data Item

Data Item

Data Item

Data Item

Data Item

Data Item

Data Item

…

Data Item

Mapping

Relationship

Mapping

Source: Software Productivity Consortium, www.software.org


Paul R. Croll - 41

Quagmap Mappings and Relationships

Mappings define how well one framework (the Source) meets the intent of the second (the Target)

Relationships define how well each source framework data item meets the intent of the associated target framework item[s]

[none] Partial Complete

These are M:M mappings and relationships Standards mappings are generally done in both directionsSource: Software Productivity Consortium, www.software.org


Paul R. Croll - 42

Quagmap Reports

Framework: Description and all data items Relationship: Source framework items and related

data items from one or more target frameworks Coverage: Target framework items and the source

data items that meet them Gap Identification: Target items not fully satisfied

by the source data items Inferred Mapping: Given a mapping from A:B, and

B:C; what is a likely set of relationships from A:C?Source: Software Productivity Consortium, www.software.org


Paul R. Croll - 43

Quagmap Relationship Report



Paul R. Croll - 44

Quagmap Relationship Details



Paul R. Croll - 45

How You Can Help . . .

Get involved in the mapping effort Initial mapping Peer reviewer

What you will receive A Copyright Notice and License Agreement An electronic copy of the standard(s) to be mapped

the associated framework standard (s) A copy of the Quagmap tool A mapping guide

How to get started Contact me at: [email protected] to let me know of

your interest

License Agreement: By returning the registration information requested below and accepting these Standards and the Quagmap software and databases, I agree to participate in the Study Group. I also agree to use Quagmap to map the Standards referenced above to external standards, knowledge products and tools, such as the CMMISM and PSM, as directed by the Study Group Chair. I understand that these Standards are IEEE-copyrighted materials and that I may not duplicate or use these standards for any purposes other than those of this Study Group. I further understand that Quagmap is the sole property of the Software Productivity Consortium and that I have been granted a limited license to use Quagmap only for the purposes of standards mapping. I agree to destroy these Standards and uninstall and destroy the Quagmap software and databases, upon completion of my Study Group activities.

Name: ___________________________________________________ Organization: ___________________________________________________ Telephone: ___________________ Fax: _______________________

e-mail: ___________________ Return to: Paul R. Croll Chair, IEEE Software Engineering Standards Committee Computer Sciences Corporation 5166 Potomac Drive King George, VA 22485-5824

Phone: +1 540.644.6224 Fax: +1 540.663.0276 e-mail: [email protected]


Paul R. Croll - 46

Questions?


Paul R. Croll - 47

For More Information . . .

Paul R. CrollComputer Sciences Corporation5166 Potomac DriveKing George, VA 22485-5824

Phone: +1 540.644.6224Fax: +1 540.663.0276e-mail: [email protected]

For IEEE Standards:http://computer.org/standards/sesc/http://computer.org/cspress/CATALOG/st01110.htm

For ISO/IEC Standards:http://saturne.info.uqam.ca/Labo_Recherche/Lrgl/sc7/


Paul R. Croll - 48

References

CMMISM -SE/SW/IPPD/SS, V1.1, CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development, and Supplier Sourcing Version 1.1, CMMISM -SE/SW/IPPD/SS, V1.1, Continuous Representation. CMU/SEI-CMU/SEI-2002-TR-011, ESC-TR-2002-011, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA, March 2002.

Guide for ISO/IEC 15288 (System Life Cycle Processes), PDTR, ISO/IEC JTC1/SC7, 2002.

IEEE Standard 830-1998, Recommended Practice for Software Requirements Specifications, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998.


Paul R. Croll - 49

References - 2

IEEE Standard 1233-1998, Guide for Developing System Requirements Specifications, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998.

IEEE Standard 1540-2001, IEEE Standard for Software Life Cycle Processes — Risk Management, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 2001.

IEEE/EIA Standard 12207.0-1996, Industry Implementation of International Standard ISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology —Software life cycle processes, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998.


Paul R. Croll - 50

References - 3

IEEE/EIA Standard 12207.1-1997, Industry Implementation of International Standard ISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology —Software life cycle processes - Implementation Considerations, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998.

ISO/IEC CD 15288 FDIS:2002, Systems Engineering — System Life Cycle Processes, ISO/IEC JTC1/SC7, 2002.

[Singh97] Raghu Singh, An Introduction to International Standards ISO/IEC 12207, Software Life Cycle Processes, 1997.

Best Practice Information Aids for CMMI SM -Compliant Process Engineering Updated Mapping & Examples...

Documents

Transcript of Best Practice Information Aids for CMMI SM -Compliant Process Engineering Updated Mapping & Examples...