strategies and technologies for cmmi sm -compliant process engineering paul r. croll chair, ieee...
TRANSCRIPT
Strategies and Technologies for CMMISM-CompliantProcess EngineeringPaul R. Croll
Chair, IEEE Software Engineering Standards Committee
Vice Chair, ISO/IEC JTC1/SC7 U.S. TAGComputer Sciences Corporation
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 3
1
2
3
4
5
6
7
8
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 4
8 Steps to Success In CMMISM-Compliant Process Engineering
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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 5
Step 1 – Understand your business processes
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 6
Strategy: 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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 7
Technology: Use Business Process Modeling Aids to Capture Your Business Processes
Automated tools can help you capture and understand your business processes.
Business Process Management Initiative – BPML 1.0 Specification http://www.bpmi.org/
CA’s AllFusion Modeling Suite http://www.asapsoftware.com/ca/allfusion.pdf
Casewise Corporate Modeler http://www.casewise.com/
Popkin System Architect http://www.popkin.com/
Proforma ProVision Modeling Suite http://www.proformacorp.com/
Rational Suite® AnalystStudio® http://www.rational.com/products/astudio/index.jsp
Disclaimer: Tools and services mentioned are for example only. Such mention is not to be construed as an endorsement by the author, CSC, IEEE, ISO. or IEC
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 8
Step 2 - Look to the CMMISM for Process Completeness
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 9
Strategy: Use 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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 10
Technology: Use Tools and Information Assets to the Understand Your Business Processes in the CMMISM Context
Checklists and Mapping Tables http://www.stsc.hill.af.mil/consulting/cmmi/documents.html
SEI CMMI AdoptionWeb Page http://www.sei.cmu.edu/cmmi/adoption/adoption.html
SEI Software Engineering Information Repository http://seir.sei.cmu.edu/
Basic Support for Cooperative Work (BSCW) Shared Workspace http://jo.sei.cmu.edu/pub/english.cgi/0/323123
Yahoo! CMMI Process Improvement Discussion Group http://groups.yahoo.com/group/cmmi_process_improvement/
Disclaimer: Tools and services mentioned are for example only. Such mention is not to be construed as an endorsement by the author, CSC, IEEE, ISO. or IEC
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 11
Step 3 - Look to Framework Standards for Life Cycle Definition
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 12
Strategy: Use Process Framework Standards to Aid in Life Cycle Definition
Systems Life Cycle ISO/IEC 15288, Systems engineering — System life cycle processes
Software Life Cycle ISO/IEC 12207, Standard for Information Technology —Software life
cycle processes IEEE/EIA 12207.0, Industry Implementation of International Standard
ISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology —Software life cycle processes
IEEE/EIA 12207.1, Industry Implementation of International Standard ISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology —Software life cycle processes – Life Cycle Data
IEEE/EIA 12207.2, Industry Implementation of International Standard ISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology —Software life cycle processes – Implementation considerations
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 13
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)
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 14
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)
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 15
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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 16
Step 4 – Look to Supporting Standards For Process Detail
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 17
Strategy: Use Supporting Standards as Best Practice Support for Your Defined System Life Cycle
Source:Systems Engineering – A Guide for the application of ISO/IEC 15288 System Life Cycle Processes, DTR 19760, © 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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 18
Strategy: Use Supporting Standards as Best Practice Support for Your Defined Software Life Cycle
Source:IEEE/EIA 12207.1-1997, © IEEE 1998.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 19
CMMISM SE/SW/IPPD/SS v1.1 Standards 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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 20
CMMISM SE/SW/IPPD/SS v1.1 Standards 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
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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 21
CMMISM SE/SW/IPPD/SS v1.1 Standards 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
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
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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 22
CMMISM SE/SW/IPPD/SS v1.1 Standards 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
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
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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 23
An Example - 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
ISO/IEC 15288, System Life Cycle Processes
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
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 24
An Example - 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
ISO/IEC 15288, System Life Cycle Processes
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
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
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.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 25
An Example - 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
ISO/IEC 15288, System Life Cycle Processes
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
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
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.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 26
An Example - 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
ISO/IEC 15288, System Life Cycle Processes
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
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
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.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 27
An Example - 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
ISO/IEC 15288, System Life Cycle Processes
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
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
Source: IEEE 1233-1998, © IEEE 1998.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 28
An Example - 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
ISO/IEC 15288, System Life Cycle Processes
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
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
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.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 29
An Example - 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
ISO/IEC 15288, System Life Cycle Processes
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
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
Source: IEEE 830-1998, © IEEE 1998.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 30
Technology: Use Mapping Tools and Reports to Select Supporting Standards and Identify Best Practice Detail
The IEEE CMMISM Mapping Project http://computer.org/standards/sesc/
The FAA-iCMM Project http://www2.faa.gov/aio/ProcessEngr/iCMM/index.htm
The Software Productivity Consortium’s Quagmap Tool http://www.software.org/pub/products/quagmap.asp
Disclaimer: Tools and services mentioned are for example only. Such mention is not to be construed as an endorsement by the author, CSC, IEEE, ISO. or IEC
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 31
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 1 7 5 . 1 - 2 0 0 2 I E E E G u i d e f o r C A S E T o o l I n t e r c o n n e c t i o n s - C l a s s i f i c a t i o n a n d D e s c r i p t i o n 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 2 0 0 1 - 1 9 9 9 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 I n t e r n e t P r a c t i c e s - - W e b p a g e E n g i n e e r i n g - - I n t r a n e t / E x t r a n e t
A p p l i c a t i o n s 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 /
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 32
The SPC Quagmap Tool
Source:Software Productivity Consortiumwww.software.org
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 33
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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 34
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
Standards mappings are generally done in both directions
Source: Software Productivity Consortium, www.software.org
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 35
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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 36
Quagmap Relationship Report
Source:Software Productivity Consortiumwww.software.org
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 37
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]
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 38
Step 5 – Build or Refine Your Process Architecture
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 39
Strategy: Use Best Practice Information to Build or Refine Your Process Architecture
Existing process assets CMMISM gap identification Framework and Supporting Standards Industry and DoD best practices
SEI CMMI AdoptionWeb Page http://www.sei.cmu.edu/cmmi/adoption/adoption.html
SEI Software Engineering Information Repository http://seir.sei.cmu.edu/
USAF Software Technology Support Center http://www.stsc.hill.af.mil
Navy SPAWAR Systems Engineering Process Office http://sepo.spawar.navy.mil/sepo/index2.html
Disclaimer: Tools and services mentioned are for example only. Such mention is not to be construed as an endorsement by the author, CSC, IEEE, ISO. or IEC
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 40
Technology: Use Tools to Support Process Definition
CMMISM Reference Card http://www.sei.cmu.edu/cmmi/
publications/ref-card.pdf Process Asset Libraries Knowledge Portals pragma Systems Corporation’s
processMax5
http://www.pragmasystems.com/max5fin.htm
Disclaimer: Tools and services mentioned are for example only. Such mention is not to be construed as an endorsement by the author, CSC, IEEE, ISO. or IEC
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 41
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 42
Step 6 – Execute Your Processes
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 43
Strategy: Base Your Business Activities on Your Defined Processes
Institutionalize your processes Train your workforce in your
defined processes Incentivize both management
and staff Check process performance
Goal Process Results (GPR)
A business-focused Plan Do Check Act cycle
For a given set of results either goals or processes may be modified
Goal
Results
Process
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 44
Technology: Use Tools to Facilitate Process Deployment, Training, and Execution
Process Asset Libraries Knowledge Portals Computer-Based Training (CBTs) Web-Based Training (WBT) Net-Based Collaboration
MS Windows NetMeeting http://www.microsoft.com/windows/netmeeting/default.asp
AT&T Web Meeting http://www.business.att.com/products/
productdetails.jsp;jsessionid=PM0HJK2YN2ZQFLAZBYZCFEY?productId=wms_eu
IBM Lotus Sametime http://www.lotus.com/products/lotussametime.nsf/wdocs/homepage
Disclaimer: Tools and services mentioned are for example only. Such mention is not to be construed as an endorsement by the author, CSC, IEEE, ISO. or IEC
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 45
Step 7 – Measure Your Results - Modify Processes as Necessary
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 46
Strategy: Establish an Active Measurement Program
For both Processes and Products: Identify measurement objectives that are aligned with your business
needs Choose specific measures, data collection and storage mechanisms,
analysis techniques, and reporting and feedback mechanisms that support your measurement objectives
Implement your measurement program Provide decision-makers with objective results that can be used in
making informed decisions Periodically assess your measurement program to ensure that it is
meeting current business needs
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 47
Technology: Use Tools to Support Measurement of Process Performance and Product Quality
Spreadsheets Control Charts
http://www.isixsigma.com/st/control_charts/ PSM Insight
http://www.psmsc.com/PSMI.asp Distributive Software’s DataDrill
http://www.distributive.com/solutions_maturitymodel.html SEI Software Engineering Measurement and Analysis Program
http://www.sei.cmu.edu/sema/welcome.html INCOSE Measurement Working Group
http://www.incosemwg.org/
Disclaimer: Tools and services mentioned are for example only. Such mention is not to be construed as an endorsement by the author, CSC, IEEE, ISO. or IEC
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 48
Step 8 – Confirm Your Status With Independent Appraisals
3
333
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 49
Strategy: Select an Appraisal Style Suited to Your Process Improvement Objectives
NoNoYesRating?
LowMediumHigh
Relative:• Cost/Duration• Confidence• Accuracy
• Quick Look• Incremental• Gap analysis
• Initial• Incremental• Self-assessment
• Benchmark• Baseline establishmentUsage Mode
Class CClass BClass AAttributes
http://www.sei.cmu.edu/cmmi/appraisals/appraisals.html
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 50
Technology: Use Process Appraisal Tools to Capture Appraisal Data and Facilitate Findings
Checklists Spreadsheets Databases Integrated Systems Diagnostics’ Appraisal Wizard
http://www.isd-inc.com/index.asp?q=1036& pragma Systems Corporation’s processMax5
http://www.pragmasystems.com/max5fin.htm SEI Transition Partner Appraisal Services
http://www.sei.cmu.edu/collaborating/partners/partners-tech.html#SCAMPI
Disclaimer: Tools and services mentioned are for example only. Such mention is not to be construed as an endorsement by the author, CSC, IEEE, ISO. or IEC
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 51
8 Steps to Success In CMMISM-Compliant Process Engineering
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
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 52
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/
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 53
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.
IEEE Standard 830-1998, Recommended Practice for Software Requirements Specifications, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998.
IEEE Standard 1233-1998, Guide for Developing System Requirements Specifications, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 54
References - 2
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.
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 – Life cycle data, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998.
IEEE/EIA Standard 12207.2-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.
Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300-1440 Paul R. Croll - 55
References - 3
ISO/IEC 15288 FDIS:2002, Systems Engineering — System Life Cycle Processes, ISO/IEC JTC1/SC7, 2002.
ISO/IEC 19760 DTR:2002, Systems Engineering – A Guide for the application of ISO/IEC 15288 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.