© 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
© 2006 John Walz 33
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)
© 2006 John Walz 44
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
© 2006 John Walz 55
Audience questions
• Using / implementing CMM / CMMI?
• Using IEEE Software standards?
• Using / implementing ISO 9001?
• Using / implementing CobiT?
© 2006 John Walz 66
Agenda
• CMMI-SW
• IEEE Software Standards
• Using Standards for CMMI-SW
© 2006 John Walz 77
• 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?
© 2006 John Walz 88
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
• Using Standards for CMMI-SW
© 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
• Using Standards for CMMI-SW
© 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
CMMI®-SW Level 2 & 3 Support
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
Requirements Management Plan
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
Specific and Generic Goals/Practices and Typical Work Products
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
PA: Requirements ManagementGoals and Practices
CMMI®-SW Level 2 & 3 Support
© 2006 John Walz 3535
Specific and Generic Goals/Practices and Typical Work Products
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
PA: Requirements ManagementGoals and Practices
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
Requirements Management Plan
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 3737
IEEE 830Coverpage
IEEE
© 2006 John Walz 3838
IEEE 830Table ofContents
IEEE
© 2006 John Walz 3939
IEEE 830SRS
Template
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)
© 2006 John Walz 4848
Questions?