Practical Support for CMMI®-SW

Project Documentation:
Using IEEE Software Engineering Standards

John Walz
The Sutton Group
IEEE Computer Society
Standards Activities Board secretary

Chicago Software Process Improvement Network C-SPIN

Schaumburg, IL
1-Jun-06
1
© 2006 John Walz 1
 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
 Audience
MMI
C

• Software Project Managers

• Software Engineering Professionals
• Software Engineering Managers

• Organizations seeking to satisfy

documentation requirements for Levels 2 & 3
of Capability Maturity Model Integrated for
Software (CMMI®-SW)
3
© 2006 John Walz 3
 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 cost
overruns
• Good news J
– CMMI®-SW is free to use and flexible
• Bad news L
– Organizational difficulties with CMMI®-SW
implementation and assessments
4
© 2006 John Walz 4
 Audience questions

• Using / implementing CMM / CMMI?

• Using IEEE Software standards?

• Using / implementing ISO 9001?

• Using / implementing CobiT?

5
© 2006 John Walz 5
 Agenda

• CMMI-SW
• IEEE Software Standards
• Using Standards for CMMI-SW

6
© 2006 John Walz 6
 What is 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
7
© 2006 John Walz 7
 CMMI® Structure
Maturity Levels MLx

Process Area 1 Process Area 2 Process Area n

PA n

Specific Goals Generic Goals

GGx
SGx

Specific Practices Generic Practices

Capability Levels
CLx
SPx.y GPx.y

8
© 2006 John Walz 8
 CMMI‚-SW Process Areas
Maturity
Maturity Level
Level Process
Process Area
Area (PA)
(PA) Name
Name ##Practices
Practices
(ML)
(ML) GP/SP
GP/SP
5 Organizational Innovation and Deployment 19
Causal Analysis and Resolution 17
Optimizing
Measurements
4 Organizational Process Performance 17
Quantitative Project Management 20 Scope
Quant Managed
3 Requirements Development 20
Technical Solution 21
Defined Product Integration 21
Verification/Validation 20
Organizational Process Focus 19
Organizational Process Definition 17
Organizational Training 19
Integrated Project Management 20 Documentation
Risk Management 19 Scope
2 Requirements Management 15
Project Planning 24
Managed Project Monitoring and Control 20
Process and Product Quality Assurance 14
Configuration Management 17
Supplier Agreement Management 17
Measurement and Analysis 18
 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

10
© 2006 John Walz 10
 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

11
© 2006 John Walz 11
 Problem Details
• Difficulties
– CMMI®-SW creates many Work Products or Artifacts during the
Software 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

12
© 2006 John Walz 12
 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 documents
supported with IEEE standards best practices.

13
© 2006 John Walz 13
 Agenda

• CMMI-SW
• IEEE Software Engineering Standards
• Using Standards for CMMI-SW

14
© 2006 John Walz 14
 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
15
© 2006 John Walz 15
 Best Practices
(year first available)
Project planning & Management Design practices
Practices • Information hiding (1972)
• Automated estimation tools (1973) • Design for change (1979)
• Evolutionary delivery (1988) Construction practices
• Measurement (1977) • Source code control (1980)
• Productivity environments (1984) • Incremental integration (1979)
• Risk-management planning (1981) Quality assurance practices
Requirements engineering • Branch-coverage testing (1979)
practices • Inspections (1976)
• Change board (1978) Process improvement
• Throwaway user interface • SW-CMM (1987)
prototyping (1975)
• Software Engineering Process
• JAD sessions (1985) Groups (1988)

16
Steve McConnell, Construx Software
© 2006 John Walz 16
 Software Engineering
Body of Knowledge SWEBOK
10 Knowledge Areas 8 Related Disciplines

Software Requirements
Software Design Computer Engineering
Software Construction Computer Science
Software Testing Management
Software Maintenance Mathematics
Software Configuration Mgmt Project Management
Software Eng. Management Quality Management
Software Engineering Process Software Ergonomics
Software Eng. Tools & Methods Systems Engineering
Software Quality
The Guide to SWEBOK is 202 pages
17
John Harauz
© 2006 John Walz 17
 Value of Standards
A standard is a Name for an • What is “testing”?
• Sftw Engr needs
otherwise fuzzy concept standards to assign
names to practices or
In a complex, … a standard gives a name collections of
multidimensional to a bounded region. practices.
trade space of • This enables
solutions ... communication
between Buyer and
Seller
• Standards represent
It defines some the “minimum level of
characteristics that a responsible practice”
buyer can count on.
Jim Moore, 2004 -03 CSEE&T Panel 7

18
James Moore
© 2006 John Walz 18
 IEEE Standards Association (SA)

• American National Standards Institute (ANSI) accredited.

• World-renowned standards-setting body that develops
industry-driven standards based on current scientific
consensus on par with ISO, IEC.
• Portfolio of more than 870 completed standards and
more than 400 standards in development.
• Composed of many Sponsors or Standards Committees
– Software & Systems Engineering Standards Committee (S2ESC)
is one of most active

19
John Harauz
© 2006 John Walz 19
 IEEE Software and Systems Engineering
Standards Committee (S2ESC)
“To provide a family of products and services based on software
engineering standards for use by practitioners, organizations, and
educators to improve the effectiveness and efficiency of their
software engineering processes, to improve communications
between acquirers and suppliers, and to improve the quality of
delivered 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 engineering
standards development.
• Forty+ Standards in Software and Systems Engineering.
20
John Harauz
© 2006 John Walz 20
 What are
IEEE 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 necessary
documentation
– 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 each
CMMI® support document

21
© 2006 John Walz 21
 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.
22
John Harauz
© 2006 John Walz 22
 Standards Development Organizations
Supporting Software

ISO IEC

TC176 JTC1 TC56 SC65A

Quality Information Technology Dependability Functional Safety

SC1 SC7 SC22 SC27

Terminology Software and Systems Engrg Language, OS IT Security
Techniques

ISO
IEEE CS DoD/MoD
IEC
MIL-STDs
Policy Memos
IEEE CS IEEE-Std Assoc.
Military
& S2ESC IASC
ANSI Software and
Systems Engineering
Information
Assurance

23
Paul Croll
© 2006 John Walz 23
 24
IEEE
© 2006 John Walz 24
 Agenda

• CMMI-SW
• IEEE Software Engineering Standards
• Using Standards for CMMI-SW

25
© 2006 John Walz 25
8 Steps to Success In CMMI‚ -Compliant
Process Engineering
Practical Support for CMMI®-SW Project Documentation: Using IEEE Software Engineering Standards

Understand Look to the Look to Look to

1 your business 2 CMMISM for 3 Framework 4 Supporting
processes Process Standards for Life Standards for
Completeness Cycle Definition Process Detail

Build or Refine Execute Your Measure Your Confirm Your

5 6 7 8
Your Process Processes Results - Modify Status With
Architecture Processes as Independent
Necessary Appraisals

3
3
3 3

16th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004 26
Copyright 2004, Paul R. Croll, All rights reserved
Paul Croll
© 2006 John Walz 26
 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 to

provide the basic beginning framework
for software process improvement

27
© 2006 John Walz 27
 In Other Words…
Using IEEE Software Engineering
Standards to:

• Define software engineering (SE) processes

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

28
© 2006 John Walz 28
 CMMI®-SW Level 2 & 3 Comparison to
IEEE SE Standards
Level
Level 22 CMMI-SW
CMMI-SW PA
PA IEEE
IEEE Standards
Standards

Requirements Management IEEE Std 830 – Practice for Software

Requirements Specifications

Project Planning IEEE Std 1058 – Software Project

Management Plans;
IEEE Std 1490 – PMBOK
Project Monitoring and Control IEEE Std 1058 – Software Project
Management Plans

Process and Product Quality IEEE Std 730 – Software Quality

Assurance Assurance

Configuration Management IEEE Std 828 – Software Configuration

Management Plans

Supplier Agreement Management IEEE Std 1062 – Practice for Software

Acquisition

Measurement and Analysis IEEE Std 1045 – Software Productivity

Metrics
 CMMI®-SW Level 2 & 3 Comparison to
IEEE SE Standards
Level
Level 33 CMMI-SW
CMMI-SW PA
PA IEEE
IEEE Standards
Standards

Technical Solution IEEE 1016 – Software Design Descriptions

IEEE 1063 – Sftw. User Documentation;
IEEE 1471 – Arch. Desc. of Sftw. Syst.
Validation IEEE 1028 – Software Reviews

Verification; IEEE 829 - Software Test Documentation

Validation
Project Planning;
Project Monitoring & Control;
Integrated Product Management
Project Planning;
Project Monitoring & Control
IEEE 1490 - Project Management Body of
Knowledge
IEEE 1058 – Software Project Management
Plans

Risk Management IEEE 1540 - Risk Management

... ...
... ...
 CMMI® Model Components
• Specific Goals Required
• Specific Practices
• Generic Goals Expected

• Generic Practices
IEEE SE Standards
– Typical work products
– Sub-practices
Informative
– Notes
– References

CMMI®-SW Level 2 & 3 Support

31
© 2006 John Walz 31
 Artifact Creation Example
Process Area (PA): Requirements Management

32
© 2006 John Walz 32
 PA: Requirements Management
Goals and Practices
CMMI®-SW Level 2 & 3 Support
Specific and Generic Goals/Practices and Typical Work Products Specific and Generic Goals/Practices and Typical Work Products
SG1 – Manage Requirements GG2 – Institutionalize a Managed Process
SP1.1 – Obtain an understanding of requirements GP2.1 – Establish an organizational policy
List of criteria for distinguishing appropriate requirements providers Organizational policy supporting requirements management
Criteria for evaluation and acceptance of re quirements GP2.2 – Plan the process
Results of analyses against criteria Documentation in support of the requirements management planning
An agreed-to set of requirements process
SP1.2 – Obtain commitments to requirements GP2.3 – Provide resources
Requirements impact assessments Identification of resources used in support of requirements identification and
Documented commitments to requirements and requirements changes management
SP1.3 – Manage requirements changes GP2.4 – Assign responsibility
Requirements status Description of individuals responsible for requirements management
Requirements database activities
Requirements decision database GP2.5 – Train people
SP1.4 – Maintain bi-directional traceability of requirements Identify how in dividuals will be provided the appropriate training
Requirements traceability matrix GP 2.6 – Manage configurations
Requirements tracking system Description of how requirements and all associated artifacts are placed
under configuration management
SP1.5 – Identify inconsistencies between projec t work and requirements
GP 2.7 – Identify relevant stakeholders
Documentation of inconsistencies including sources, conditions, and rationale
Identify who is responsible for the definition and management of
Corrective actions
requirements

33
© 2006 John Walz 33
 PA: Requirements Management
Goals and Practices
CMMI®-SW Level 2 & 3 Support
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 project work and requirements
Documentation of inconsistencies
including sources, conditions, and
rationale
Corrective actions
Work Product or Artifact
Requirements Management Plan
Requirements Management Plan
Requirements Specification Review
Requirements Specification
Requirements Specification
Signed SRS or approved change
requests
Requirements database, baseline
change request
Requirements database
Requirements database
Requirements Specification and
database
Requirements database
Requirements Specification Review
Revised SRS
Specific and Generic Goals/Practices and Work Product or
Typical Work Products Artifact
GG2 – Institutionalize a Managed Process
GP2.1 – Establish an organizational policy
Organizational policy supporting requirements Organizational policy
management
GP2.2 – Plan the process
Documentation in support of the requirements Requirements
management planning process management plan
GP2.3 – Provide resources
Identification of resources used in support of Project plan,
requirements identification and management requirements
management plan
GP2.4 – Assign responsibility
Description of individuals responsible for Requirements
requirements management activities management plan,
project plan, or
organizational policy
GP2.5 – Train people
Identify how in dividuals will be provided the Training plan or project
appropriate training plan
GP 2.6 – Manage configurations
Description of how requirements and all Configuration
associated artifacts are placed under management plan
configuration management
GP 2.7 – Identify relevant stakeholders
Identify who is responsible for the definition and CCB meeting minutes,
management of requirements traceability reporting,
and requirements
reviews
 PA: Requirements Management
Goals and Practices
CMMI®-SW Level 2 & 3 Support
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 project work and requirements
Documentation of inconsistencies
including sources, conditions, and
rationale
Corrective actions
© 2006 John Walz
Book Plan or Artifact
Requirements Manageme nt Plan
Requirements Management Plan
Requirements Specification Review
Requirements Specification
Requirements Specification
Signed SRS or approved change
requests
Requirements datab ase, baseline
change request
Requirements database
Requirements database
Requirements Specification and
database
Requirements database
Requirements Specification Review
Revised SRS
35
Specific and Generic Goals/Practices and Book Plan or Artifact
Typical Work Products
GG2 – Institutionalize a Managed Process
GP2.1 – Establish an organizational policy
Organizational policy supporting requirements Organizational policy
management
GP2.2 – Plan the process
Documentation in support of the requirements Requirements
management planning process management plan
GP2.3 – Provide resources
Identification of resources used in support of Project p lan,
requirements identification and management requirements
management plan
GP2.4 – Assign responsibility
Description of individuals responsible for Requirements
requirements management activities management plan,
project plan, or
organizational policy
GP2.5 – Train people
Identify how indiv iduals will be provided the Training plan or project
appropriate training plan
GP 2.6 – Manage configurations
Description of how requirements and all Configuration
associated artifacts are placed under management plan
configuration management
GP 2.7 – Identify relevant stakeholders
Identify who is responsible for the definition and CCB meeting minutes,
management of requirements traceability reporting,
and requirements
reviews
35
PA – Requirements Management Artifact
Software Requirements Management Plan

IEEE Std 830-1998, IEEE Recommended Practice for

Software Requirements Specifications.

Outlines the requirements for what comprises a good Software

Requirements Specification (SRS):

• Establishes basis for agreement between customers and

suppliers 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
36
IEEE
© 2006 John Walz 36
IEEE 830
Cover
page

37
IEEE
© 2006 John Walz 37
IEEE 830
Table of
Contents

38
IEEE
© 2006 John Walz 38
IEEE 830
SRS
Template

39
IEEE
© 2006 John Walz 39
 Software Requirements Management Plan
Document Outline

Table of Contents 5.1.3 Dynamic Analysis

Revision Sheet 5.2 Software Requirements Management Process
1.0 Introduction 5.2.1 Requirements Elicitation
2.0 Purpose 5.2.2 Requirements Analysis
2.1 Scope 5.2.3 Requirements Specification
2.2 Definitions 5.3 Characteristics of a Good SRS
2.3 Goals 5.3.1 Correct
3.0 References 5.3.2 Nonambiguous
3.1 Key Acronyms 5.3.3 Complete
3.2 Key Terms 5.3.4 Verifiable
3.3 Key References 5.3.5 Consistent
4.0 Management 5.3.6 Modifiable
4.1 Organization 5.3.7 Traceable
4.2 Tasks 5.3.8 Usable During Operation and Maintenance
4.3 Responsibilities 6.0 Standards and Practices
4.3.1 Management 7.0 Software Measurement and Metrics
4.3.2 Program Manager 8.0 Verification and Validation
4.3.3 Project Lead 9.0 Software Configuration Management
4.3.4 Team Members 10.0 Developing a Software Requirements Specification
4.3.5 Customer
5.0 Software Requirements Management Overview Appendix A // Project Software Requirements
5.1 Software Requirements Modeling Techniques Specification Template
5.1.1 Functional Analysis Appendix B// Requirements Traceability Matrix
5.1.2 Object -Oriented Analysis

40
© 2006 John Walz 40
 Software Requirements Management Plan
Document Guidance
• Purpose - ………………………..
• Scope - ………………………..
• Definitions - ………………………..
• Goals - ………………………..
• Management Organization - ………………………..
• Tasks - ………………………..
• Responsibilities - ………………………..
• Software Requirements Management -
………………………..
• Software Requirements Modeling Techniques -
……………………….. Provides section-by-section
• ……………………….. guidance in support of the
document creation
• ………………………..
41
© 2006 John Walz 41
 Software Requirements Management Plan
Document 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 of
the document creation
• ………………………..
42
© 2006 John Walz 42
 In Conclusion
• Understand your business
processes
• Look to the CMMI for Process
Completeness
– Use CMMI building blocks for
higher maturity set at each
stage
• Look to Framework Standards
for Life Cycle Definition
– IEEE 12207
• Look to Supporting Standards
for Process Detail
– Use IEEE standards to
perform a gap analysis
Make a plan. Then follow the plan.
- Watts Humphrey
© 2006 John Walz 43
• Build or Refine Your Process
Architecture
– Fix timelines to produce goal
driven process improvement
– Define your processes in outline
form
– Redefine your processes
– Use IEEE standards to develop
your baseline process
documentation
• 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 Appraisals
43
 IEEE Software Engineering Standards
Collection
• Over 40 of the most current IEEE software
engineering standards on CD-ROM

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

44
© 2006 John Walz 44
 Wiley and IEEE Computer
Society Press Book Series
• Software Engineering, Vol. 1 & 2, The Development Process, 3rd
Edition by Richard H. Thayer, Mark J. Christensen
• Trustworthy Systems Through Quantitative Software Engineering
by Lawrence Bernstein, C. M. Yuhas
• Software Quality Engineering: Testing, Quality Assurance, and
Quantifiable Improvement
by Jeff Tian
• Jumpstart CMM/CMMI Software Process Improvements: Using
IEEE Software Engineering Standards
by Susan K. Land
• Information Security : A Strategic Approach
by Vincent LeVeque
• The Road Map to Software Engineering: A Standards-Based Guide
by James W. Moore
• Practical Support for CMMI-SW Software Project
Documentation: Using IEEE Software Engineering
Standards by Susan K. Land, John W. Walz

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

http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471738492.html
 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)
47
© 2006 John Walz 47
 Questions?

48
© 2006 John Walz 48