practical support for cmmi -sw project documentation...

© 2006 John Walz 11

Practical Support for CMMI®-SWProject Documentation:

Using IEEE Software Engineering Standards

John WalzThe Sutton Group

IEEE Computer SocietyStandards Activities Board secretary

Chicago Software Process Improvement Network C-SPINSchaumburg, IL

1-Jun-06

John Walz• Sr. Consultant, The Sutton Group

– Software / CMMI®

• Retired Lucent / AT&T• Sr. Member IEEE, Standards Assoc.• Secretary, IEEE Computer Standards

Activity Board• Vice-Chair Planning, IEEE Software & Systems

Standards Committee• Secretary TL 9000 SIG• Sr. Member ASQ• Blog Author, ASQ Sarbanes-Oxley


AudienceCMMI

• Software Project Managers• Software Engineering Professionals• Software Engineering Managers

• Organizations seeking to satisfydocumentation requirements for Levels 2 & 3of Capability Maturity Model Integrated forSoftware (CMMI®-SW)


Overview

• Problem Statement– Software Engineering organizations face pressures

and risks of missed deliveries and cost overruns

• Proposed Solution– Organizations using CMMI®-SW model, report

significant reductions in missed deliveries and costoverruns

• Good news J– CMMI®-SW is free to use and flexible

• Bad news L– Organizational difficulties with CMMI®-SW

implementation and assessments


Audience questions

• Using / implementing CMM / CMMI?

• Using IEEE Software standards?

• Using / implementing ISO 9001?

• Using / implementing CobiT?


Agenda

• CMMI-SW

• IEEE Software Standards

• Using Standards for CMMI-SW


• CMMI is a– Goal-oriented process model– Framework for reliable and consistent assessments– Mechanism for identifying & adopting best practices

• Lessons learned by high maturity organizations

• CMMI is NOT a– Prescription– Standard– Methodology

• Reference:– CMMI‚-SW, v1.1, Carnegie Mellon University,

Software Engineering Institute, Pittsburgh, PA, 2002

What is CMMI®-SW?


Generic Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific PracticesCapability Levels

Generic Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific PracticesCapability Levels

CMMI® Structure

SPx.y GPx.y

SGxGGx

PA n

Maturity Levels MLx

CLx

Maturity Level(ML)

Maturity Level(ML)

Process Area (PA) NameProcess Area (PA) Name #PracticesGP/SP

#PracticesGP/SP

5Optimizing

Organizational Innovation and DeploymentCausal Analysis and Resolution

1917

4Quant Managed

Organizational Process PerformanceQuantitative Project Management

1720

3Defined

Requirements DevelopmentTechnical SolutionProduct IntegrationVerification/ValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational TrainingIntegrated Project ManagementRisk Management

202121201917192019

2Managed

Requirements ManagementProject PlanningProject Monitoring and ControlProcess and Product Quality AssuranceConfiguration ManagementSupplier Agreement ManagementMeasurement and Analysis

15242014171718

CMMI‚-SW Process Areas

DocumentationScope

MeasurementsScope

© 2006 John Walz 1010

Organization Institutionalization Generic Practices 2.1 to 3.2 2.1 Adhering to organizational policies 2.2 Following established plans and process descriptions 2.3 Providing adequate resources 2.4 Assigning responsibility and authority for performing the process 2.5 Training the people performing and supporting the process 2.6 Placing work products under appropriate configuration management levels 2.7 Identifying and involving relevant stakeholders 2.8 Monitoring process performance agai nst performance plans and taking corrective actions are

when required 2.9 Evaluating the process, its work products, and its services for adherence to the process

descriptions, objectives, and standards, and addressing noncompliance issues 2.10 Reviewing all process activities, status, and results with higher level management, and taking

corrective action when required 3. Addressing all items that institutionalize a Managed process 3.1 Establishing the description of the defined process for the proje ct or organizational unit 3.2 Deriving work products, measures, and improvement information from information collected

from the planning and performance of defined processes Addressing all items that institutionalize a Defined process

© 2006 John Walz 1111

Work Product / Artifact

• CMMI®: any artifact produced by a process– Include files, documents, parts of the

product, services, processes, specifications, and invoices,etc.

• Scheduled by Project Managers• Stored in Configuration Management Systems• Tested for Quality• Used & shared by project staff members• Assessed for Organizational Capability or Maturity

© 2006 John Walz 1212

Problem Details• Difficulties

– CMMI®-SW creates many Work Products or Artifacts during theSoftware Life Cycle and these are inputs to the Assessment

• Artifact Problem– Which Artifact?– What is the Artifact content and format?– How to convince the organization to use our “standard Artifact”?

• Artifact Approaches– Mandate using existing Artifacts from best company’s project– Invent and design your own Artifacts– Benchmark & borrow Artifacts from the industry best company– Borrow Artifacts from Standards developed by the industry best

© 2006 John Walz 1313

Solution Overview

• Software engineering organizations– Strive for improvement– Seek customer assurances– Have freedom on the content and format of typical software

engineering project documents

• IEEE software engineering standards– Codifies industries best practices for all critical software

engineering processes and their outputs.

• This presentation– Steps that software engineering companies can take to

implement CMMI along with critical project documentssupported with IEEE standards best practices.

© 2006 John Walz 1414

Agenda

• CMMI-SW

• IEEE Software Engineering Standards


© 2006 John Walz 1515

Formalized Intellectual Property

• Good Techniques / Methods• Articles published with peer review• Case studies• Good Principles• Best Practices• Workshops• Body Of Knowledge• Standards developed• Books• Collegiate Curriculum• Certification of experts & organizations• Licenses

© 2006 John Walz 1616

Best Practices(year first available)

Project planning & ManagementPractices

• Automated estimation tools (1973)• Evolutionary delivery (1988)• Measurement (1977)• Productivity environments (1984)• Risk-management planning (1981)Requirements engineering

practices• Change board (1978)• Throwaway user interface

prototyping (1975)• JAD sessions (1985)

Design practices• Information hiding (1972)• Design for change (1979)Construction practices• Source code control (1980)• Incremental integration (1979)Quality assurance practices• Branch-coverage testing (1979)• Inspections (1976)Process improvement• SW-CMM (1987)• Software Engineering Process

Groups (1988)

Steve McConnell, Construx Software

© 2006 John Walz 1717

Software EngineeringBody of Knowledge SWEBOK

Software Requirements

Software Design

Software Construction

Software Testing

Software Maintenance

Software Configuration Mgmt

Software Eng. Management

Software Engineering Process

Software Eng. Tools & Methods

Software Quality

Computer Engineering

Computer Science

Management

Mathematics

Project Management

Quality Management

Software Ergonomics

Systems Engineering

8 Related Disciplines10 Knowledge Areas

John Harauz

The Guide to SWEBOK is 202 pages

© 2006 John Walz 1818

Value of Standards

• What is “testing”?

• Sftw Engr needsstandards to assignnames to practices orcollections ofpractices.

• This enablescommunicationbetween Buyer andSeller

• Standards representthe “minimum level ofresponsible practice”

Jim Moore, 2004 -03 CSEE&T Panel 7

A standard is a A standard is a NameName for an for an otherwise fuzzy conceptotherwise fuzzy concept

In a complex, multidimensional trade space of solutions ...

… a standard gives a name to a bounded region.

It defines some characteristics that a buyer can count on.

James Moore

© 2006 John Walz 1919

IEEE Standards Association (SA)

• American National Standards Institute (ANSI) accredited.• World-renowned standards-setting body that develops

industry-driven standards based on current scientificconsensus on par with ISO, IEC.

• Portfolio of more than 870 completed standards andmore than 400 standards in development.

• Composed of many Sponsors or Standards Committees– Software & Systems Engineering Standards Committee (S2ESC)

is one of most active

John Harauz

© 2006 John Walz 2020

IEEE Software and Systems EngineeringStandards Committee (S2ESC)

“To provide a family of products and services based on softwareengineering standards for use by practitioners, organizations, andeducators to improve the effectiveness and efficiency of theirsoftware engineering processes, to improve communicationsbetween acquirers and suppliers, and to improve the quality ofdelivered software and systems containing software.”

• Terms of Reference:• Codify the norms of professional software engineering practices

into standards;

• Promote use of software engineering standards among clients,practitioners, and educators;

• Harmonize national and international software engineeringstandards development.

• Forty+ Standards in Software and Systems Engineering.

John Harauz

© 2006 John Walz 2121

What areIEEE Software Engr. Standards?

• Represent industry best practices– having been developed by domain experts with broad expert

consensus.

• Specify content– Provide detailed procedure explanations and

offer section by section guidance on building the necessarydocumentation

– with no recommendation of exact techniques or formats– Used as tools to help in the painful process of

‘self-documentation’

• Specify the minimum required contents for eachCMMI® support document

© 2006 John Walz 2222

IEEE Computer Society

• Institute of Electrical and Electronics Engineers:– More than 365,000 members, including 68,000

students, in over 150 countries.– 39 societies and 5 technical councils representing

the wide range of technical interests.– 128 transactions, journals and magazines.– more than 300 conferences worldwide each year.– about 900 active IEEE standards and more than 400

in development.• The Computer Society is the largest of IEEE’s 39

technical societies:– Nearing100,000 members, 40% outside the US.– Founded in 1946, the Computer Society is the world’s

leading organization of computing professionals.

John Harauz

© 2006 John Walz 2323

Standards Development OrganizationsSupporting Software

ISO

Information Technology

JTC1

IEC

SC1 SC22

Terminology Software and Systems Engrg Language, OS

SC7 SC27

IT SecurityTechniques

ISO

IEC

IEEE CS

DoD/MoD

MIL-STDsPolicy Memos

MilitaryS2ESC IASC

Software andSystems Engineering

InformationAssurance

IEEE CS

IEEE-Std Assoc. &ANSI

Quality

TC176 TC56 SC65A

Dependability Functional Safety

Paul Croll

© 2006 John Walz 2424

IEEE

© 2006 John Walz 2525

Agenda

• CMMI-SW

• IEEE Software Engineering Standards


© 2006 John Walz 2626

8 Steps to Success In CMMI‚ -CompliantProcess Engineering

1Understand

your businessprocesses

2Look to theCMMISM for

ProcessCompleteness

3Look to

FrameworkStandards for LifeCycle Definition

4Look to

SupportingStandards forProcess Detail

5 Build or RefineYour ProcessArchitecture

6 Execute YourProcesses

7 Measure YourResults - Modify

Processes asNecessary

3333

8 Confirm YourStatus WithIndependentAppraisals

16th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004Copyright 2004, Paul R. Croll, All rights reserved

Practical Support for CMMI®-SW Project Documentation: Using IEEE Software Engineering Standards

Paul Croll

© 2006 John Walz 2727

The CMMI‚ and IEEE SE Standards

The CMMI is a compendium of

software engineering practices, which act as

the motivator for the continuous evolution

of improved software engineering processes

IEEE Standards can be used toprovide the basic beginning framework

for software process improvement

© 2006 John Walz 2828

In Other Words…Using IEEE Software EngineeringStandards to:

• Define software engineering (SE) processes• Perform software engineering gap analyses• Improve existing SE processes• Ensure CMMI®-SW Level 2 & 3 conformance

CMMI®-SW Level 2 & 3 Comparison toIEEE SE Standards

Level 2 CMMI-SW PALevel 2 CMMI-SW PA IEEE StandardsIEEE Standards

Requirements Management IEEE Std 830 – Practice for SoftwareRequirements Specifications

Project Planning

IEEE Std 1058 – Software ProjectManagement Plans;IEEE Std 1490 – PMBOK

Project Monitoring and Control

IEEE Std 1058 – Software ProjectManagement Plans

Process and Product QualityAssurance

IEEE Std 730 – Software QualityAssurance

Configuration Management

IEEE Std 828 – Software ConfigurationManagement Plans

Supplier Agreement Management

IEEE Std 1062 – Practice for SoftwareAcquisition

Measurement and Analysis

IEEE Std 1045 – Software ProductivityMetrics

CMMI®-SW Level 2 & 3 Comparison toIEEE SE Standards

Level 3 CMMI-SW PALevel 3 CMMI-SW PA IEEE StandardsIEEE Standards

Technical Solution IEEE 1016 – Software Design DescriptionsIEEE 1063 – Sftw. User Documentation;IEEE 1471 – Arch. Desc. of Sftw. Syst.

Validation IEEE 1028 – Software Reviews

Verification;Validation

IEEE 829 - Software Test Documentation

Project Planning;Project Monitoring & Control;Integrated Product Management

IEEE 1490 - Project Management Body ofKnowledge

Project Planning;Project Monitoring & Control

IEEE 1058 – Software Project ManagementPlans

Risk Management IEEE 1540 - Risk Management

. . .

. . .. . .. . .

© 2006 John Walz 3131

CMMI® Model Components

• Specific Goals

• Specific Practices

• Generic Goals

• Generic Practices– Typical work products

– Sub-practices

– Notes

– References

Required

Expected

Informative

IEEE SE Standards

• Specific Goals

• Specific Practices

• Generic Practices– Typical work products

– Sub-practices

– Notes

– References

CMMI®-SW Level 2 & 3 Support

© 2006 John Walz 3232

Artifact Creation ExampleProcess Area (PA): Requirements Management

© 2006 John Walz 3333

Specific and Generic Goals/Practices and Typical Work Products SG1 – Manage Requirements SP1.1 – Obtain an understanding of requirements List of criteria for distinguishing appropriate requirements providers Criteria for evaluation and acceptance of requirements Results of analyses against criteria An agreed-to set of requirements SP1.2 – Obtain commitments to requirements Requirements impact assessments Documented commitments to requirements and requirements changes SP1.3 – Manage requirements changes Requirements status Requirements database Requirements decision database SP1.4 – Maintain bi-directional traceability of requirements Requirements traceability matrix Requirements tracking system SP1.5 – Identify inconsistencies between projec t work and requirements Documentation of inconsistencies including sources, conditions, and rationale Corrective actions

Specific and Generic Goals/Practices and Typical Work Products GG2 – Institutionalize a Managed Process GP2.1 – Establish an organizational policy Organizational policy supporting requirements management GP2.2 – Plan the process Documentation in support of the requirements management planning process GP2.3 – Provide resources Identification of resources used in support of requirements identification and management GP2.4 – Assign responsibility Description of individuals responsible for requirements management activities GP2.5 – Train people Identify how in dividuals will be provided the appropriate training GP 2.6 – Manage configurations Description of how requirements and all associated artifacts are placed under configuration management GP 2.7 – Identify relevant stakeholders Identify who is responsible for the definition and management of requirements

PA: Requirements ManagementGoals and Practices


Specific and Generic Goals/Practices and Typical Work Products

Work Product or Artifact

SG1 – Manage Requirements SP1.1 – Obtain an understanding of requirements

List of criteria for distinguishing appropriate requirements providers

Requirements Management Plan

Criteria for evaluation and acceptance of requirements


Results of analyses against criteria Requirements Specification Review An agreed-to set of requirements Requirements Specification SP1.2 – Obtain commitments to requirements

Requirements impact assessments Requirements Specification Documented commitments to requirements and requirements changes

Signed SRS or approved change requests

SP1.3 – Manage requirements changes Requirements status Requirements database, baseline

change request Requirements database Requirements database Requirements decision database Requirements database SP1.4 – Maintain bi-directional traceability of requirements

Requirements traceability matrix Requirements Specification and database

Requirements tracking system Requirements database SP1.5 – Identify inconsistencies between project work and requirements

Documentation of inconsistencies including sources, conditions, and rationale

Requirements Specification Review

Corrective actions Revised SRS


Work Product or Artifact

GG2 – Institutionalize a Managed Process GP2.1 – Establish an organizational policy Organizational policy supporting requirements management

Organizational policy

GP2.2 – Plan the process Documentation in support of the requirements management planning process

Requirements management plan

GP2.3 – Provide resources Identification of resources used in support of requirements identification and management

Project plan, requirements management plan

GP2.4 – Assign responsibility Description of individuals responsible for requirements management activities

Requirements management plan, project plan, or organizational policy

GP2.5 – Train people Identify how in dividuals will be provided the appropriate training

Training plan or project plan

GP 2.6 – Manage configurations Description of how requirements and all associated artifacts are placed under configuration management

Configuration management plan

GP 2.7 – Identify relevant stakeholders Identify who is responsible for the definition and management of requirements

CCB meeting minutes, traceability reporting, and requirements reviews



© 2006 John Walz 3535


Book Plan or Artifact

GG2 – Institutionalize a Managed Process GP2.1 – Establish an organizational policy Organizational policy supporting requirements management

Organizational policy

GP2.2 – Plan the process Documentation in support of the requirements management planning process

Requirements management plan

GP2.3 – Provide resources Identification of resources used in support of requirements identification and management

Project p lan, requirements management plan

GP2.4 – Assign responsibility Description of individuals responsible for requirements management activities

Requirements management plan, project plan, or organizational policy

GP2.5 – Train people Identify how indiv iduals will be provided the appropriate training

Training plan or project plan

GP 2.6 – Manage configurations Description of how requirements and all associated artifacts are placed under configuration management

Configuration management plan

GP 2.7 – Identify relevant stakeholders Identify who is responsible for the definition and management of requirements

CCB meeting minutes, traceability reporting, and requirements reviews


CMMI®-SW Level 2 & 3 SupportSpecific and Generic Goals/Practices and Typical Work Products

Book Plan or Artifact

SG1 – Manage Requirements SP1.1 – Obtain an understanding of requirements

List of criteria for distinguishing appropriate requirements providers

Requirements Manageme nt Plan

Criteria for evaluation and acceptance of requirements


Results of analyses against criteria Requirements Specification Review An agreed-to set of requirements Requirements Specification SP1.2 – Obtain commitments to requirements

Requirements impact assessments Requirements Specification Documented commitments to requirements and requirements changes

Signed SRS or approved change requests

SP1.3 – Manage requirements changes Requirements status Requirements datab ase, baseline

change request Requirements database Requirements database Requirements decision database Requirements database SP1.4 – Maintain bi-directional traceability of requirements

Requirements traceability matrix Requirements Specification and database

Requirements tracking system Requirements database SP1.5 – Identify inconsistencies between project work and requirements

Documentation of inconsistencies including sources, conditions, and rationale

Requirements Specification Review

Corrective actions Revised SRS

© 2006 John Walz 3636

PA – Requirements Management ArtifactSoftware Requirements Management Plan

IEEE Std 830-1998, IEEE Recommended Practice forSoftware Requirements Specifications.

Outlines the requirements for what comprises a good SoftwareRequirements Specification (SRS):

• Establishes basis for agreement between customers andsuppliers on what the software product is to do

• Reduces the development effort• Provides a basis for estimating costs and schedules• Provides a baseline for validation and verification• Facilitates transfer• Serves as a basis for enhancement

IEEE

© 2006 John Walz 4040

Software Requirements Management PlanDocument Outline

Table of Contents Revision Sheet 1.0 Introduction 2.0 Purpose 2.1 Scope 2.2 Definitions 2.3 Goals 3.0 References 3.1 Key Acronyms 3.2 Key Terms 3.3 Key References 4.0 Management 4.1 Organization 4.2 Tasks 4.3 Responsibilities 4.3.1 Management 4.3.2 Program Manager 4.3.3 Project Lead 4.3.4 Team Members 4.3.5 Customer 5.0 Software Requirements Management Overview 5.1 Software Requirements Modeling Techniques 5.1.1 Functional Analysis 5.1.2 Object -Oriented Analysis

5.1.3 Dynamic Analysis 5.2 Software Requirements Management Process 5.2.1 Requirements Elicitation 5.2.2 Requirements Analysis 5.2.3 Requirements Specification 5.3 Characteristics of a Good SRS 5.3.1 Correct 5.3.2 Nonambiguous 5.3.3 Complete 5.3.4 Verifiable 5.3.5 Consistent 5.3.6 Modifiable 5.3.7 Traceable 5.3.8 Usable During Operation and Maintenance 6.0 Standards and Practices 7.0 Software Measurement and Metrics 8.0 Verification and Validation 9.0 Software Configuration Management 10.0 Developing a Software Requirements Specification Appendix A // Project Software Requirements Specification Template Appendix B// Requirements Traceability Matrix

© 2006 John Walz 4141

Software Requirements Management PlanDocument Guidance

• Purpose - ………………………..• Scope - ………………………..• Definitions - ………………………..• Goals - ………………………..• Management Organization - ………………………..• Tasks - ………………………..• Responsibilities - ………………………..• Software Requirements Management -

………………………..• Software Requirements Modeling Techniques -

………………………..• ………………………..• ………………………..

Provides section-by-sectionguidance in support of thedocument creation

© 2006 John Walz 4242

Software Requirements Management PlanDocument Template

• Purpose - ………………………..• Scope - ………………………..• Definitions - ………………………..• Goals - ………………………..• Management Organization - ………………………..• Tasks - ………………………..• Responsibilities - ………………………..• Software Requirements Management -

………………………..• Software Requirements Modeling Techniques -

………………………..• ………………………..• ………………………..

Provides section-by-section“fill-in the blanks” support ofthe document creation

© 2006 John Walz 4343

In Conclusion• Understand your business

processes• Look to the CMMI for Process

Completeness– Use CMMI building blocks for

higher maturity set at eachstage

• Look to Framework Standardsfor Life Cycle Definition– IEEE 12207

• Look to Supporting Standardsfor Process Detail– Use IEEE standards to

perform a gap analysis

• Build or Refine Your ProcessArchitecture– Fix timelines to produce goal

driven process improvement– Define your processes in outline

form– Redefine your processes– Use IEEE standards to develop

your baseline processdocumentation

• Execute Your Processes• Measure Your Results - Modify

Processes as Necessary– Perform self-audit using CMMI

PAs– Readjust processes/plans based

upon audit results.• Confirm Your Status With

Independent AppraisalsMake a plan. Then follow the plan.

- Watts HumphreyMake a plan. Then follow the plan.

- Watts Humphrey

© 2006 John Walz 4444

IEEE Software Engineering StandardsCollection

• Over 40 of the most current IEEE softwareengineering standards on CD-ROM

ISBN 0-7381-3757-X, Sep03, Catalog # ST01121, $370.00 Members / $465.00 List

Wiley and IEEE ComputerSociety Press Book Series

• Software Engineering, Vol. 1 & 2, The Development Process, 3rdEdition by Richard H. Thayer, Mark J. Christensen

• Trustworthy Systems Through Quantitative Software Engineeringby Lawrence Bernstein, C. M. Yuhas

• Software Quality Engineering: Testing, Quality Assurance, andQuantifiable Improvementby Jeff Tian

• Jumpstart CMM/CMMI Software Process Improvements: UsingIEEE Software Engineering Standardsby Susan K. Land

• Information Security : A Strategic Approachby Vincent LeVeque

• The Road Map to Software Engineering: A Standards-Based Guideby James W. Moore

• Practical Support for CMMI-SW Software ProjectDocumentation: Using IEEE Software EngineeringStandards by Susan K. Land, John W. Walz

www.wiley.com/WileyCDA/Section/id-11028.html

ExpertGuidance

http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471738492.html

© 2006 John Walz 4747

Book Chapters

• Introduction and Overview• CMMI®-SW Summary• Organization Institutionalization – ML 2 & 3 GP• Implementation Guidance• CMMI®-SW Level 2 Support• CMMI®-SW Level 3 Support• CMMI®-SW Level 2 for Small Projects• CMMI®-SW Level 2 & 3 Comparison to

IEEE SE Standards• Software Process Work Products (102)• Software Process Work Products Templates (38)

practical support for cmmi -sw project documentation...

Documents