Скачать презентацию Paul R Croll Chair IEEE Software Engineering Standards Скачать презентацию Paul R Croll Chair IEEE Software Engineering Standards

876b4a093a4fa980c38399940e4439a1.ppt

  • Количество слайдов: 55

Paul R. Croll Chair, IEEE Software Engineering Standards Committee Vice Chair, ISO/IEC JTC 1/SC Paul R. Croll Chair, IEEE Software Engineering Standards Committee Vice Chair, ISO/IEC JTC 1/SC 7 U. S. TAG Computer Sciences Corporation pcroll@csc. com Strategies and Technologies for CMMISM-Compliant Process Engineering Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440

A Preparatory Exercise Fifteenth Annual Software Technology Conference – Track 3 – 30 April A Preparatory Exercise Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 Paul R. Croll - 2

1 3 2 5 4 7 6 8 Fifteenth Annual Software Technology Conference – 1 3 2 5 4 7 6 8 Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 3

8 Steps to Success In CMMISMCompliant Process Engineering 1 5 Understand your business processes 8 Steps to Success In CMMISMCompliant Process Engineering 1 5 Understand your business processes Build or Refine Your Process Architecture 2 6 Look to the CMMISM for Process Completeness Execute Your Processes 3 7 Look to 4 Framework Standards for Life Cycle Definition Measure Your Results - Modify Processes as Necessary 8 3 Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 Look to Supporting Standards for Process Detail Confirm Your Status With Independent Appraisals 3 3 3 4

Step 1 – Understand your business processes Fifteenth Annual Software Technology Conference – Track Step 1 – Understand your business processes Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 5

Strategy: Your Business is Your Business – It’s Not CMMISM Implementation l You must Strategy: Your Business is Your Business – It’s Not CMMISM Implementation l You must fully understand your business processes before you can address process completeness or process compliance. u u u Decision Branch Else Activity 1 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 welldefined? Do your business processes satisfy your business goals? Decision Branch Else Activity 2 Activity 4 Activity 5 Activity 3 AND Activity 6 End Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 6

Technology: Use Business Process Modeling Aids to Capture Your Business Processes l Automated tools Technology: Use Business Process Modeling Aids to Capture Your Business Processes l Automated tools can help you capture and understand your business processes. u Business Process Management Initiative – BPML 1. 0 Specification n u CA’s All. Fusion Modeling Suite n u http: //www. popkin. com/ Proforma Pro. Vision Modeling Suite n u http: //www. casewise. com/ Popkin System Architect n u http: //www. asapsoftware. com/ca/allfusion. pdf Casewise Corporate Modeler n u http: //www. bpmi. org/ http: //www. proformacorp. com/ Rational Suite® Analyst. Studio® n 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 7

Step 2 - Look to the CMMISM for Process Completeness Fifteenth Annual Software Technology Step 2 - Look to the CMMISM for Process Completeness Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 8

Strategy: Use the CMMISM as a Guide to Process Completeness Determine if essential elements Strategy: Use the CMMISM as a Guide to Process Completeness Determine if essential elements of your processes are missing or incomplete Process Management · · Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance · Organizational Innovation and Deployment Engineering · · · Requirements Management Requirements Development Technical Solution Product Integration Verification Validation Project Management · · · · Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management for IPPD Risk Management Integrated Teaming Integrated Supplier Management Quantitative Project Management Support · Configuration Management · Process and Product Quality Assurance · Measurement and Analysis · Decision Analysis and Resolution · Organizational Environment for Integration · Causal Analysis and Resolution Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 9

Technology: Use Tools and Information Assets to the Understand Your Business Processes in the Technology: Use Tools and Information Assets to the Understand Your Business Processes in the CMMISM Context l Checklists and Mapping Tables u l SEI CMMI Adoption. Web Page u l http: //seir. sei. cmu. edu/ Basic Support for Cooperative Work (BSCW) Shared Workspace u l http: //www. sei. cmu. edu/cmmi/adoption. html SEI Software Engineering Information Repository u l http: //www. stsc. hill. af. mil/consulting/cmmi/documents. html http: //jo. sei. cmu. edu/pub/english. cgi/0/323123 Yahoo! CMMI Process Improvement Discussion Group u 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 10

Step 3 - Look to Framework Standards for Life Cycle Definition Fifteenth Annual Software Step 3 - Look to Framework Standards for Life Cycle Definition Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 11

Strategy: Use Process Framework Standards to Aid in Life Cycle Definition l Systems Life Strategy: Use Process Framework Standards to Aid in Life Cycle Definition l Systems Life Cycle u l ISO/IEC 15288, Systems engineering — System life cycle processes Software Life Cycle u u ISO/IEC 12207, Standard for Information Technology —Software life cycle processes IEEE/EIA 12207. 0, Industry Implementation of International Standard ISO/IEC 12207: 1995 — (ISO/IEC 12207) Standard for Information Technology —Software life cycle processes n n IEEE/EIA 12207. 1, Industry Implementation of International Standard ISO/IEC 12207: 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/IEC 12207: 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 12

The ISO/IEC 15288 Systems Life Cycle Process Framework ENTERPRISE ENVIRONMENT MANAGEMENT INVESTMENT MANAGEMENT SYSTEM The ISO/IEC 15288 Systems Life Cycle Process Framework ENTERPRISE ENVIRONMENT MANAGEMENT INVESTMENT MANAGEMENT SYSTEM LIFE CYCLE MANAGEMENT RESOURCE MANAGEMENT SYSTEM LIFE CYCLE (25) ENTERPRISE(5) AGREEMENT (2) PROJECT (7) QUALITY MANAGEMENT ACQUISITION SUPPLY PROJECT PLANNING PROJECT ASSESSMENT PROJECT CONTROL DECISION MAKING RISK MANAGEMENT CONFIGURATION MANAGEMENT INFORMATION MANAGEMENT TECHNICAL (11) STAKEHOLDER REQUIREMENTS DEFINITION REQUIREMENTS ANALYSIS ARCHITECTURAL DESIGN IMPLEMENTATION INTEGRATION VERIFICATION TRANSITION Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 VALIDATION OPERATION MAINTENANCE DISPOSAL 13

The IEEE/EIA 12207 Software Life Cycle Process Framework ACQUISITION SUPPLY DEVELOPMENT OPERATION SOFTWARE LIFE The IEEE/EIA 12207 Software Life Cycle Process Framework ACQUISITION SUPPLY DEVELOPMENT OPERATION SOFTWARE LIFE CYCLE (17+1) MAINTENANCE PRIMARY (5) SUPPORTING (8) DOCUMENTATION CONFIGURATION MANAGEMENT QUALITY ASSURANCE VERIFICATION VALIDATION JOINT REVIEW AUDIT PROBLEM RESOLUTION ORGANIZATIONAL (4) MANAGEMENT Source: Singh 97 INFRASTRUCTURE IMPROVEMENT TRAINING TAILORING Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 14

Relationship between ISO/IEC 15288 and ISO/IEC 12207 Project Planning Project Assessment Risk Management Decision Relationship between ISO/IEC 15288 and ISO/IEC 12207 Project Planning Project Assessment Risk Management Decision Making Project Control Configuration Management Stakeholder Requirements Definition Validation Usability Information Management Operation Transition Maintenance Requirements Analysis Verification Architectural Design Integration Project processes Technical processes Disposal Implementation Enterprise Environment Management Hardware Implementation Investment Management Software Implementation Refer to ISO/IEC 12207 Human Task Implementation System Life Cycle Processes Management Enterprise processes Resource Management Quality Management Source: ISO/IEC JTC 1/SC 7/WG 7 N 0643, 2002 -10 -20, © ISO/IEC 2002. Acquisition Supply Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 Agreement processes 15

Step 4 – Look to Supporting Standards For Process Detail Fifteenth Annual Software Technology Step 4 – Look to Supporting Standards For Process Detail Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 16

Strategy: Use Supporting Standards as Best Practice Support for Your Defined System Life Cycle Strategy: Use Supporting Standards as Best Practice Support for Your Defined System Life Cycle Life cycle progression ISO/IEC 15288 Life Cycle Model Stages Concept Development Production Utilization Support Retirement Increasing level of detail ISO/IEC 15288 system life cycle processes Activity level detail from a 2 nd Standard For example, ANSI/EIA 632 Task level detail from a 3 rd Standard For example, IEEE 1220 Activity level detail from a 4 th Standard Task level detail from a 5 th Standard A 1. ISO/IEC 15288 and other engineering standards Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 Source: Systems Engineering – A Guide for the application of ISO/IEC 15288 System Life Cycle Processes, DTR 19760, © ISO/IEC 2002. 17

Strategy: Use Supporting Standards as Best Practice Support for Your Defined Software Life Cycle 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 18

CMMISM SE/SW/IPPD/SS v 1. 1 Standards Mapping - Process Management ISO/IEC 15288, System Life CMMISM SE/SW/IPPD/SS v 1. 1 Standards Mapping - Process Management ISO/IEC 15288, System Life Cycle Process Management Processes l IEEE 12207. 0, Software Life Cycle Processes EIA 632 - Processes for l Engineering a System SE/SW/IPPD/SSIEEE 12207. 1, Guide to Software Life CMMISM v 1. 1 Cycle Processes—Life Cycle Data IEEE 1220, Application and Process Area/Specific Practice l IEEE 12207. 2, Guide to Software Life Management of the Systems Cycle Processes—Implementation Engineering Process Considerations IEEE 1074, Developing Software Life Cycle Processes Framework Standards 1517 -1999, Reuse Processes l l l Supporting Standards Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 19

CMMISM SE/SW/IPPD/SS v 1. 1 Standards Mapping – Project Management 1. l l l CMMISM SE/SW/IPPD/SS v 1. 1 Standards Mapping – Project Management 1. l l l 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 l l 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 20

CMMISM SE/SW/IPPD/SS v 1. 1 Standards Mapping – Engineering l l l l l CMMISM SE/SW/IPPD/SS v 1. 1 Standards Mapping – Engineering l l l l l 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 l l l l 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, IDEF 0, IDEF 1 X 97 IEEE 1420. 1, Data Model for Reuse Library Interoperability Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 21

CMMISM SE/SW/IPPD/SS v 1. 1 Standards Mapping – Support l 1. Support l l CMMISM SE/SW/IPPD/SS v 1. 1 Standards Mapping – Support l 1. Support l l l l 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 l l 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 22

An Example - Requirements Development SP 2. 1 -1 Establish Product and Product Component An Example - Requirements Development SP 2. 1 -1 Establish Product and Product Component Requirements u Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability l ISO/IEC 15288, System Life Cycle Processes u l IEEE/EIA 12207. 0, Software Life Cycle Processes u u l l Clause 5. 5. 3 - Requirements Analysis Process 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 23

An Example - Requirements Development SP 2. 1 -1 Establish Product and Product Component An Example - Requirements Development SP 2. 1 -1 Establish Product and Product Component Requirements l ISO/IEC 15288, System Life Cycle Processes u Clause 5. 5. 3 - Requirements Analysis Establish and maintain, from the Process customer requirements, product and 5. 5. 3 Requirements Analysis Process product component requirements l 5. 5. 3. 1 Purpose of the Requirements Analysis Process IEEE/EIA 12207. 0, Software Life Cycle essential to product and product Process is to transform The purpose of the Requirements Analysis Processes the componentrequirement-driven view of desired services into a stakeholder, effectiveness and technical view of a required product that could deliver those services. u Clause 5. 3. 2 - System Requirements affordability a representation of a future system that will meet This process builds Analysis stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable Clause 5. 3. 4 - Software requirements u system requirements that specify, from the developer’s perspective, analysis u what characteristics it is to possess and with what magnitude in order to satisfy stakeholder requirements. 5. 5. 3. 2 Requirements Analysis Process Outcomes l IEEE As a result of the successful implementation of the Requirements 1233, Guide for Developing System Analysis Process: Requirements Specifications a) The required characteristics, attributes, and functional and performance requirements for a product solution are specified. l IEEE 830, Software Requirements b) Constraints that will affect the architectural design of a system and Specifications the means to realize it are specified. c) The integrity and traceability of system requirements to Source: ISO/IEC CD 15288 FDIS, © ISO/IEC 2002. stakeholder requirements is achieved. . Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 24

An Example - Requirements Development 5. 3. 2. 1 The specific intended use of An Example - Requirements Development 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. l SP 2. 1 -1 Establish Product and 5. 3. 4. 1 The developer shall establish and document software Product Component Requirements requirements, including the quality characteristics specifications, described below. . and maintain, from the u Establish a) Functional and capability specifications, including performance, customer requirements, product and physical characteristics, and environmental conditions under product component requirements which the software item is to perform; l b) Interfaces external to the software item; essential to product and product c) Qualification requirements; component effectiveness and d) Safety specifications, including those related to methods of affordability operation and maintenance, environmental influences, and personnel injury; e) Security specifications, including those related to compromise of sensitive information. . . l l Source: IEEE/EIA 12207. 0 -1997, © IEEE 2001. ISO/IEC 15288, System Life Cycle Processes u Clause 5. 5. 3 - Requirements Analysis Process IEEE/EIA 12207. 0, Software Life Cycle Processes u u 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 25

An Example - Requirements Development 7. 2 Build a well-formed requirement The analysts carry An Example - Requirements Development 7. 2 Build a well-formed requirement The 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 ISO/IEC 15288, System Life Cycle l SP 2. 1 -1 Establish Product and “resistant” or “industry wide; ” Processes Product Component Requirements c) Avoiding requirements pitfalls (see 6. 4); d) Ensuring the readability of requirements, which entails the following: Clause 5. 5. 3 - Requirements Analysis u u Establish and maintain, from the 1) Simple words/phrases/concepts; Process 2) Uniformcustomer requirements, product and arrangement and relationship; product component requirements 3) Definition of unique words, symbols, and notations; l IEEE/EIA 12207. 0, Software Life Cycle 4) The useessential to product and product symbology. of grammatically correct language and Processes e) Ensuring testability. component effectiveness and Example: u Clause 5. 3. 2 - System Requirements Capability: affordability Move people between Los Angeles and New York Analysis Condition: Cruising speed of 200 km/hr Constraint: Maximum speed of 300 km/hr u Clause 5. 3. 4 - Software requirements Well-formed requirement: This system should move people between Los Angeles and New York at an optimal cruising speed of 200 km/hr analysis with a maximum speed of 300 km/hr. l l Source: IEEE 1233 -1998, © IEEE 1998. 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 26

An Example - Requirements Development SP 2. 1 -1 Establish Product and Product Component An Example - Requirements Development SP 2. 1 -1 Establish Product and Product Component Requirements u Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability l ISO/IEC 15288, System Life Cycle Processes u l IEEE/EIA 12207. 0, Software Life Cycle Processes u u l l Clause 5. 5. 3 - Requirements Analysis Process 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 27

An Example - Requirements Development 5. 3. 2 Functions Functional requirements should define the An Example - Requirements Development 5. 3. 2 Functions Functional 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 inputs l ISO/IEC 15288, System Life Cycle b) Exact 2. 1 -1 Establish Product and SP sequence of operations c) Responses to abnormal situations, including: Processes Product Component Requirements 1) Overflow 2) Communication facilities u Clause 5. 5. 3 - Requirements Analysis u Establish and maintain, from the 3) Error handling and recovery Process customer requirements, product and d) Effect of parameters product component requirements e) Relationship of outputs to inputs. . . l IEEE/EIA 12207. 0, Software Life Cycle 1) It mayessential to product and product requirements into be appropriate to partition the functional Processes subfunctions or subprocesses. This does component effectiveness and partitioned that way. not imply that the software design will also be u Clause 5. 3. 2 - System Requirements affordability 5. 3. 3 Performance requirements Analysis This subsection should specify both the static and the dynamic numerical requirements placed on the softu Clause 5. 3. 4 - Software requirements ware or on human interaction with the software as a whole. Static analysis numerical requirements may include the following: a) The number of terminals to be supported; l IEEE 1233, Guide for Developing System b) The number of simultaneous users to be supported; c) Amount and type of information to be handled. l Source: IEEE 830 -1998, © IEEE 1998. Requirements Specifications IEEE 830, Software Requirements Specifications Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 28

An Example - Requirements Development SP 2. 1 -1 Establish Product and Product Component An Example - Requirements Development SP 2. 1 -1 Establish Product and Product Component Requirements u Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability l ISO/IEC 15288, System Life Cycle Processes u l IEEE/EIA 12207. 0, Software Life Cycle Processes u u l l Clause 5. 5. 3 - Requirements Analysis Process 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 29

Technology: Use Mapping Tools and Reports to Select Supporting Standards and Identify Best Practice Technology: Use Mapping Tools and Reports to Select Supporting Standards and Identify Best Practice Detail l The IEEE CMMISM Mapping Project u l The FAA-i. CMM Project u l http: //computer. org/standards/sesc/ http: //www 2. faa. gov/aio/Process. Engr/i. CMM/index. htm The Software Productivity Consortium’s Quagmap Tool u 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 30

The IEEE CMMISM Mapping Project – Background l Study Group on External Standards Coordination The IEEE CMMISM Mapping Project – Background l Study Group on External Standards Coordination formed u l l l 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. Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 31

The SPC Quagmap Tool Source: Software Productivity Consortium www. software. org Fifteenth Annual Software The SPC Quagmap Tool Source: Software Productivity Consortium www. software. org Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 32

Quagmap Information Structure Framework A Data Item Framework B Mapping Data Item Data Item Quagmap Information Structure Framework A Data Item Framework B Mapping Data Item Data Item Relationship Data Item … Data Item Mapping … Data Item Source: Software Productivity Consortium, www. software. org Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 33

Quagmap Mappings and Relationships l l Mappings define how well one framework (the Source) Quagmap Mappings and Relationships l l 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] u u u l [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 34

Quagmap Reports l l l Framework: Description and all data items Relationship: Source framework Quagmap Reports l l l 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 35

Quagmap Relationship Report Source: Software Productivity Consortium www. software. org Fifteenth Annual Software Technology Quagmap Relationship Report Source: Software Productivity Consortium www. software. org Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 36

How You Can Help. . . l Get involved in the mapping effort u How You Can Help. . . l Get involved in the mapping effort u u l What you will receive u u l Initial mapping Peer reviewer 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 u Contact me at: pcroll@csc. com to let me know of your interest Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 37

Step 5 – Build or Refine Your Process Architecture Fifteenth Annual Software Technology Conference Step 5 – Build or Refine Your Process Architecture Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 38

Strategy: Use Best Practice Information to Build or Refine Your Process Architecture l l Strategy: Use Best Practice Information to Build or Refine Your Process Architecture l l Existing process assets CMMISM gap identification Framework and Supporting Standards Industry and Do. D best practices u SEI CMMI Adoption. Web Page n u SEI Software Engineering Information Repository n u http: //seir. sei. cmu. edu/ USAF Software Technology Support Center n u http: //www. sei. cmu. edu/cmmi/adoption. html http: //www. stsc. hill. af. mil Navy SPAWAR Systems Engineering Process Office n http: //sepo. spawar. navy. mil/sepo/index 2. 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 39

Technology: Use Tools to Support Process Definition l CMMISM Reference Card u l l Technology: Use Tools to Support Process Definition l CMMISM Reference Card u l l l http: //www. sei. cmu. edu/cmmi/public ations/ref-card. pdf Process Asset Libraries Knowledge Portals pragma Systems Corporation’s process. Max 5 u http: //www. pragmasystems. com/max 5 fin. 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 40

Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440

Step 6 – Execute Your Processes Fifteenth Annual Software Technology Conference – Track 3 Step 6 – Execute Your Processes Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 42

Strategy: Base Your Business Activities on Your Defined Processes l Institutionalize your processes u Strategy: Base Your Business Activities on Your Defined Processes l Institutionalize your processes u u l Train your workforce in your defined processes Incentivize both management and staff Check process performance u Goal Process Results (GPR) n n Goal Process A business-focused Plan Do Check Act cycle For a given set of results either goals or processes may be modified Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 Results 43

Technology: Use Tools to Facilitate Process Deployment, Training, and Execution l l l Process Technology: Use Tools to Facilitate Process Deployment, Training, and Execution l l l Process Asset Libraries Knowledge Portals Computer-Based Training (CBTs) Web-Based Training (WBT) Net-Based Collaboration u MS Windows Net. Meeting n u AT&T Web Meeting n u http: //www. microsoft. com/windows/netmeeting/default. asp http: //www. business. att. com/products/productdetails. jsp; jsessionid=PM 0 HJK 2 YN 2 ZQFLAZBYZCFEY? product. Id=wms_eu IBM Lotus Sametime n 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 44

Step 7 – Measure Your Results Modify Processes as Necessary Fifteenth Annual Software Technology Step 7 – Measure Your Results Modify Processes as Necessary Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 45

Strategy: Establish an Active Measurement Program l For both Processes and Products: u u Strategy: Establish an Active Measurement Program l For both Processes and Products: u u u 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 46

Technology: Use Tools to Support Measurement of Process Performance and Product Quality l l Technology: Use Tools to Support Measurement of Process Performance and Product Quality l l Spreadsheets Control Charts u l PSM Insight u l http: //www. distributive. com/solutions_maturitymodel. html SEI Software Engineering Measurement and Analysis Program u l http: //www. psmsc. com/PSMI. asp Distributive Software’s Data. Drill u l http: //www. isixsigma. com/st/control_charts/ http: //www. sei. cmu. edu/sema/welcome. html INCOSE Measurement Working Group u 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 47

Step 8 – Confirm Your Status With Independent Appraisals 3 3 Fifteenth Annual Software Step 8 – Confirm Your Status With Independent Appraisals 3 3 Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 48

Strategy: Select an Appraisal Style Suited to Your Process Improvement Objectives Attributes Usage Mode Strategy: Select an Appraisal Style Suited to Your Process Improvement Objectives Attributes Usage Mode Class A • Benchmark • Baseline establishment Class B • Initial • Incremental • Self-assessment Class C • Quick Look • Incremental • Gap analysis Relative: • Cost/Duration • Confidence • Accuracy High Medium Low Rating? Yes No No http: //www. sei. cmu. edu/cmmi/appraisals. html Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 49

Technology: Use Process Appraisal Tools to Capture Appraisal Data and Facilitate Findings l l Technology: Use Process Appraisal Tools to Capture Appraisal Data and Facilitate Findings l l Checklists Spreadsheets Databases Integrated Systems Diagnostics’ Appraisal Wizard u l pragma Systems Corporation’s process. Max 5 u l http: //www. isd-inc. com/index. asp? q=1036& http: //www. pragmasystems. com/max 5 fin. htm SEI Transition Partner Appraisal Services u http: //www. sei. cmu. edu/collaborating/partnerstech. 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 50

8 Steps to Success In CMMISMCompliant Process Engineering 1 5 Understand your business processes 8 Steps to Success In CMMISMCompliant Process Engineering 1 5 Understand your business processes Build or Refine Your Process Architecture 2 6 Look to the CMMISM for Process Completeness Execute Your Processes 3 7 Look to 4 Framework Standards for Life Cycle Definition Measure Your Results - Modify Processes as Necessary 8 3 Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 Look to Supporting Standards for Process Detail Confirm Your Status With Independent Appraisals 3 3 3 51

For More Information. . . Paul R. Croll Computer Sciences Corporation 5166 Potomac Drive For More Information. . . Paul R. Croll Computer Sciences Corporation 5166 Potomac Drive King George, VA 22485 -5824 Phone: Fax: e-mail: +1 540. 644. 6224 +1 540. 663. 0276 pcroll@csc. com For IEEE Standards: http: //computer. org/standards/sesc/ http: //computer. org/cspress/CATALOG/st 01110. htm For ISO/IEC Standards: http: //saturne. info. uqam. ca/Labo_Recherche/Lrgl/sc 7/ Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 52

References CMMISM -SE/SW/IPPD/SS, V 1. 1, CMMI for Systems Engineering/Software Engineering/Integrated Product and Process References CMMISM -SE/SW/IPPD/SS, V 1. 1, CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development, and Supplier Sourcing Version 1. 1, CMMISM -SE/SW/IPPD/SS, V 1. 1, Continuous Representation. 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 53

References - 2 IEEE/EIA Standard 12207. 0 -1996, Industry Implementation of International Standard ISO/IEC References - 2 IEEE/EIA Standard 12207. 0 -1996, Industry Implementation of International Standard ISO/IEC 12207: 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/IEC 12207: 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/IEC 12207: 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 54

References - 3 ISO/IEC 15288 FDIS: 2002, Systems Engineering — System Life Cycle Processes, References - 3 ISO/IEC 15288 FDIS: 2002, Systems Engineering — System Life Cycle Processes, ISO/IEC JTC 1/SC 7, 2002. ISO/IEC 19760 DTR: 2002, Systems Engineering – A Guide for the application of ISO/IEC 15288 System Life Cycle Processes, ISO/IEC JTC 1/SC 7, 2002. [Singh 97] Raghu Singh, An Introduction to International Standards ISO/IEC 12207, Software Life Cycle Processes, 1997. Fifteenth Annual Software Technology Conference – Track 3 – 30 April 2003, 1300 -1440 55