+SAFE, V1.2 A Safety Extension to CMMI-DEV, V1.

2
Defence Materiel Organisation, Australian Department of Defence

March 2007

TECHNICAL NOTE CMU/SEI-2007-TN-006 Software Engineering Process Management Program Unlimited distribution subject to the copyright.

This report was prepared for the SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2007 Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works. External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. This work was created in the performance of Federal Government Contract Number FA8721-05-C0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013. For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html).

Table of Contents

Executive Summary Abstract 1 Introduction 1.1 Background and Acknowledgements 1.1.1 1.1.2 1.2 1.3 1.4 1.5 1.6 1.7 Version 1.0 Version 1.1

vii viii 1 1 1 2 2 2 4 4 5 5 6 6 7 7 7 7 8 9 9 12 14 67 67 67 68 69 71 73

1.1.3 Version 1.2 Purpose and Scope Uses of +SAFE +SAFE Relationships with CMMI-DEV +SAFE Relationships with Safety Standards Structure of the Safety Extension Intended Audiences 1.7.1 1.7.2 1.7.3 Appraisers (Internal or Acquirers) Organizations to Be Appraised Organizations Undertaking Process Improvement

1.8

1.7.4 Safety Specialists CMMI Prerequisites for the Use of +SAFE 1.8.1 Key CMMI Concepts

1.9

1.8.2 CMMI Framework Interactions Acronyms and Definitions

1.10 Changes Forecast 2 3 +SAFE Usage Guidelines 3.1 Process Appraisal Considerations 3.1.1 3.2 Appendix Using +SAFE with CMMI

3.1.2 Tailoring for an Appraisal Process Improvement Considerations Contact for Further Information

References/Bibliography

SOFTWARE ENGINEERING INSTITUTE | i

ii | CMU/SEI-2007-TN-006

List of Figures Figure 1: Context of +SAFE 3 SOFTWARE ENGINEERING INSTITUTE | iii .

iv | CMU/SEI-2007-TN-006 .

List of Tables Table 1: Table 2 Table 3: Table 4: Table 5: Structure of the Safety Extension Structure of the Safety Extension Acronyms and Definitions Summary of Cross References to CMMI Version 1.2 Sample Selection of Process Areas vii 6 12 68 69 SOFTWARE ENGINEERING INSTITUTE | v .

vi | CMU/SEI-2007-TN-006 .

V1. Accidents. CMMI provides a framework within which safety activities can take place. and Sources of Hazards SG2 Analyze Hazards and Perform Risk Assessments SG3 Define and Maintain Safety Requirements SG4 Design for Safety SG5 Support Safety Acceptance Table 1: Structure of the Safety Extension SOFTWARE ENGINEERING INSTITUTE | vii .Executive Summary +SAFE. skills. adding safety amplifications to CMMIDEV would not provide sufficient guidance to make consistent judgments regarding supplier safety capability or improvement priorities. This extension consists of two process areas added to CMMI-DEV to provide an explicit and focused basis for appraising or improving an organization’s capabilities for providing safetycritical products. techniques. and experience within an organization. The structure of the safety extension is shown in Table 1: CMMI PA Category Project Management Safety Process Area Safety Management Specific Goals SG1 Develop Safety Plans SG2 Monitor Safety Incidents SG3 Manage Safety-Related Suppliers Engineering Safety Engineering SG1 Identify Hazards. These overlaps are identified in this document. however. style. Developing safety-critical products requires specialized processes. This extension was developed for standalone use. and to address identified weaknesses early in the acquisition process. and informative content provided to reduce dependence on safety domain expertise. It is not intended to be embedded in a CMMI model and it does not rely on any specific safety standards. The extension was developed because the Australian Defence Materiel Organisation recognized that CMMI is a generically structured framework that requires amplification for specialized areas of engineering such as safety engineering. A key aim of +SAFE is to identify the safety strengths and weaknesses of product and service suppliers. The safety extension was developed so that CMMI appraisers and users can become familiar with the structure.2) [SEI 2006].2 (CMMI-DEV.2 is an extension to the continuous representation of CMMI® for Development. V1. There are intentional overlaps with CMMI model content and with some safety standards. Version1.

and managing safetycritical products. +SAFE is designed to identify safety strengths and weaknesses and to address identified weaknesses early in the acquisition process. and experience. there are intentional overlaps with CMMI model content and some safety standards. However.Abstract +SAFE is an extension to CMMI® for Development (CMMI-DEV) that covers safety management and safety engineering. skills. This extension was developed for standalone use. Since +SAFE is an extension of CMMI. it adopts the same assumptions. +SAFE supplements CMMI-DEV with two additional process areas that provide a basis for appraising or improving an organization’s processes for providing safety-critical products. nor does it rely on any specific safety standards. This technical report describes the +SAFE extension and how to use it to appraise an organization’s capability in developing. Developing such products requires specialized processes. viii | CMU/SEI-2007-TN-006 . conventions. It is not intended to be embedded in a CMMI model document. sustaining. +SAFE was designed to reduce the dependence of CMMI appraisers on safety domain expertise. model structure. maintaining. and terminology as CMMI and is affected by the general process-area and capability-level interactions inherent in CMMI.

These risks arise from a variety of causes including: lack of training. including aerospace. software. inability to provide guidance to acquirer project offices. +SAFE was developed by DMO to permit a closer appraisal of an organization's ability to conduct safety-related work for the following reasons: • DMO’s experience has been that safety-related activities can create risks to acquisition cost and schedule performance if not managed and performed with disciplined.1 Introduction +SAFE is an extension of the continuous representation of CMMI for Development. DMO is using CMMI and associated appraisal methods as an acquisition risk management tool. and the Software Engineering Institute (SEI) jointly developed the CMMI Framework. and these references are slight. banking. in conjunction with the Software Verification Research Centre (SVRC) at the University of Queensland.2) and is intended to specifically address safety. the required and expected parts of CMMI models do not mention it. manufacturing. developed a safety extension to CMMI called +SAFE version 1. Version 1. Although CMMI models provide a framework in which safety management and engineering can take place. There is a risk that an organization that has been evaluated as adequately capable using the CMMI Framework may have inadequate process capability for safety management and safety engineering. and telecommunications use CMMI-DEV [SEI 2006]. 1.1. The only references to safety are in informative parts. Organizations from industry. Organizations from many industries. government.1 The original version of +SAFE was developed using input from government. industry. defense. DMO acknowledges the following contributing authors: SOFTWARE ENGINEERING INSTITUTE | 1 . a set of integrated models. V1. and supporting products. and academia. training materials. the appraisal method. part of the Australian Department of Defence. and a lack of understanding of safety requirements and safety engineering. insufficient consultation between acquirers and stakeholders. The +SAFE extension of CMMI-DEV presents safety-specific practices for improving the capability of an organization to develop safety-critical products. CMMI-DEV is the CMMI model released in 2006 that covers the development and maintenance activities applied to both products and services. which was released to a limited audience for trial and evaluation.0.0 • • 1.1 BACKGROUND AND ACKNOWLEDGEMENTS The Defence Materiel Organisation (DMO). Version 1. computer hardware.2 (CMMI-DEV.

Mark Bofinger (Software Verification Research Centre) Prof. and a consolidated list of over 300 review comments received worldwide. +SAFE is provided in a form that can be used standalone by experienced CMMI users with minimal support from safety domain experts.2. V1. this technical note contains editorial changes made to the Australian Department of Defence +SAFE.2 as an SEI technical note was a response to the Software Engineering Institute’s 2006 release of CMMI-DEV.Matt Ashford (Defence Materiel Organisation) Dr.1 was based on experience gained from the trial use of version 1.2.2 PURPOSE AND SCOPE The purpose of +SAFE is to extend CMMI to provide an explicit.1 that aligns it with CMMI-DEV. DoD) Adrian Pitman (Defence Materiel Organisation) Pascal Rabbath (Defence Materiel Organisation) Neil Robinson (Software Verification Research Centre) Mick Spiers (Defence Materiel Organisation) 1.0. 2 | CMU/SEI-2006-TN-038 . V1.2 The development of +SAFE version 1.1.1.) Bradley Doohan (Defence Materiel Organisation) Jennifer Murray (Defence Materiel Organisation) 1. Peter Lindsay (Software Verification Research Centre) Lisa Ming (Defense Contract Management Agency.1: Matt Ashford (Defence Materiel Organisation) Graham Bower-White (Ball Solutions Group) Geoff Bowker (Bonket Pty. U. V1. DMO acknowledges the following individuals for their contribution to releasing version 1.3 Version 1. SEI acknowledges the copyrighted work by DMO and the DMO’s full support of publishing +SAFE as an SEI technical note.1 The development of +SAFE version 1. Ltd. The SEI and DMO acknowledge the following individuals for their contribution to releasing this technical note version: Mike Phillips (Software Engineering Institute) Sandy Shrum (Software Engineering Institute) Mike Konrad (Software Engineering Institute) Bradley Doohan (Defence Materiel Organisation) 1.S. Principally. specific framework for functional safety with respect to developing complex safety-critical products.2 Version 1.

so it adopts the same assumptions.4.5. safety standards. The +SAFE extension to CMMI does not solely consist of the addition of new process areas.• +SAFE is an extension of CMMI. conventions. Figure 1: Context of +SAFE SOFTWARE ENGINEERING INSTITUTE | 3 . These overlaps are explained in section 1. Relationships with safety standards are discussed further in section 1.4. and is affected by the general process-area and capability-level interactions inherent in CMMI. These relationships with CMMI are discussed further in section 1. techniques. to existing process area categories. This document also contains additional informative components and some overlaps with CMMI. • • The context of +SAFE and its relationships with components. methods. and standards that define safety principles. work products. and product assessments may be used to satisfy the goals of the framework as appropriate. The +SAFE framework is not specific to any safety standard. described in the standard CMMI manner. model structure. and assessment and appraisal methods is shown in Figure 1. and terminology as CMMI.

The generic CMMI conventions where elements are “required” (specific and generic goals)..”. sustaining. +SAFE may be used by trained and qualified CMMI appraisers with no specific safety expertise to perform safety capability appraisals using SCAMPI or another suitable appraisal method [SEI 2001]. and managing safety-critical products. and references to external standards explicitly delineate “informative” content from “required” or “expected” content. Terms such as “e. discipline amplifications. is 4 | CMU/SEI-2006-TN-038 . since some CMMI process areas could address safety as a nonfunctional attribute of a product and there is overlap or redundancy with practices in these process areas. 1.1. If the standalone requirement for +SAFE is removed. • A +SAFE appraisal or improvement program may be integrated with a CMMI appraisal or improvement program.g. “sample”. +SAFE may be used in appraisals or improvement programs just as any other process area in a CMMI model when a continuous representation is used. “indicators may include”. so that the reliance on subject matter expertise is reduced. generic practice elaborations. The level of cross-referencing to other process areas is above the level typical in a CMMI process area.g. “expected” (specific and generic practices) and “informative” (everything else) are reinforced in +SAFE to ensure that the informative content is not used prescriptively. • • In addition.4 +SAFE RELATIONSHIPS WITH CMMI-DEV +SAFE is positioned as a set of additional process areas for CMMI. maintaining. notes. examples in practice descriptions. which elaborates on the relationships between certain process area goals and certain capability level goals. +SAFE may be used by organizations with CMMI and IDEALSM (or equivalent) expertise to improve their safety capability [McFeeley 1996]. subpractices. typical work products. As a framework for improving an organization’s capability in developing. +SAFE contains material that supplements the explanatory sections of CMMI: • The Framework Interactions sub-section.3 USES OF +SAFE +SAFE is used in the same applications as CMMI: • As a framework for appraising the capability of a supplier or potential supplier of safety-critical products. +SAFE’s process areas integrate seamlessly into the Project Management and Engineering process area categories of CMMI. except for the following: • The level of detail and amount of informative material (e. and references) is above the level typical in a CMMI process area.

extended to describe the broad relationships between +SAFE process areas and CMMI process areas (refer to section 1. Issues 2 and 3.g. The informative components of the extension are indicators of how goals may be achieved.K. and identification of the requirements for users intending to apply the model (refer to section 3). but these components are not prescriptive and an organization can select the approaches it wishes to adopt to achieve the goals. The ProSOFTWARE ENGINEERING INSTITUTE | 5 . The Using CMMI Models section is extended to include tailoring guidance for the +SAFE process areas. discipline amplifications. Electronic and Programmable Electronic Control Systems. • The Terminology section is extended to include safety domain-specific terms (refer to section 1. • +SAFE also contains material that is fully redundant with CMMI to support its standalone use: • Section 1. and references) that may be redundant with CMMI. As an extension to CMMI. subpractices.. and domain-specific safety standards wherever feasible) [ADoD 1998. and is intended to be consistent with the principles of other contemporary safety standards (e.5 +SAFE RELATIONSHIPS WITH SAFETY STANDARDS +SAFE does not require the use of any specific safety standard..9). Safety Management Requirements for Defence Systems.6 STRUCTURE OF THE SAFETY EXTENSION The structure of the safety extension is shown in Table 2 and was developed from the structure of the safety model presented in Australian defence standard. 1. +SAFE contains informative content (e..8 provides material on CMMI concepts for safety practitioners who may not be familiar with CMMI and who are required to assist in the application of +SAFE. Defence Standard.S. System Safety Program Requirements. UKMoD 1997. • 1.g. +SAFE is intended to be consistent with the Australian Defence Standard. an appraisal based on this extension is not analogous to a functional safety assessment as defined in IEC’s Safety of Machinery—Functional Safety of Safety-Related Electrical. +SAFE is not intended to be used as part of a product assessment (i. including the selection of specific standards.2). military standard. Safety Engineering in the Procurement of Defence Systems. notes. Electronic and Programmable Electronic Control Systems). CEI/IEC 2005. the U. generic practice elaborations.8. USDoD 1993].e. U. IEC’s Safety of Machinery—Functional Safety of Safety-Related Electrical. Part 1. typical work products. UKMoD 2004. +SAFE is an extension used for defining goals and for increasing levels of performance capability.

7 INTENDED AUDIENCES As discussed in section 1. This group may not have any CMMI expertise.curement of Computer-Based Safety-Critical Systems.1 Appraisers (Internal or Acquirers) +SAFE was originally developed to satisfy the need for appraisers acting for an acquirer to undertake an appraisal of a supplier’s or potential supplier’s safety process capability. and have attended a short training session on +SAFE. Organizations with CMMI and (systematic) process improvement expertise In addition. a secondary audience for +SAFE are safety specialists who may be involved as subject matter experts in both appraisals and improvement programs. and Sources of Hazards SG2 Analyze Hazards and Perform Risk Assessments SG3 Define and Maintain Safety Requirements SG4 Design for Safety SG5 Support Safety Acceptance Table 2 Structure of the Safety Extension 1. +SAFE was developed in the style of CMMI. 1.3. Accidents. and use this information to assist the acquirer in managing risks associated with an acquisition. so that appraisers and other users are familiar with the structure and style. Such appraisals could be undertaken either as part of larger CMMI appraisals or as a standalone safety appraisal. 6 | CMU/SEI-2006-TN-038 . and the structure of CMMI [ADoD 2000]. there are two primary audiences for +SAFE: 1. The purpose of these appraisals is to identify strengths and weaknesses in safety processes. CMMI appraisers who may not have specific safety expertise and the organizations they appraise 2. The appraisers using this safety extension are trained CMMI appraisers.7. CMMI PA Category Project Management Safety Process Area Safety Management Specific Goals SG1 Develop Safety Plans SG2 Monitor Safety Incidents SG3 Manage Safety-Related Suppliers Engineering Safety Engineering SG1 Identify Hazards.

In an appraisal. In an improvement program. and providing advice on their implementation.3 Organizations Undertaking Process Improvement +SAFE provides guidance to organizations on how to improve their safety processes. ConSOFTWARE ENGINEERING INSTITUTE | 7 . It does. and conventions. and by elaborating on the means for implementing the generic practices. and the use of relevant safety standards.7. the organization must satisfy the intent of the goals of the safety process areas. however. Several portions of CMMI can be used to provide a context for +SAFE.7.8 CMMI PREREQUISITES FOR THE USE OF +SAFE +SAFE is intended for standalone use and in general does not depend on the process areas documented in CMMI. 1.1. like other subject matter experts in other areas. The organization may also use terminology different from that used in +SAFE. depend on the capability level descriptions.2 Organizations to Be Appraised The organization’s safety processes may not be structured the same way as the safety processes presented in +SAFE. It also assumes that users are familiar with the CMMI Framework. to assist the appraisal team in evaluating indicators such as alternative practices and work products. 1. The text in CMMI Part 1 sections 1-5 and Part 3. by describing specific practices that may be performed to achieve the goals of each process area. This assistance may include undertaking improvements to reduce risks identified by customers in their appraisal of the organization. is applicable and should be consulted for further guidance on using and understanding the safety extension. however. 1.7. including Process and Product Quality Assurance. Effective safety management and engineering depend on certain support processes being in place. and the general framework interactions inherent in CMMI. which support achievement of the generic goals for each capability level.4 Safety Specialists Safety specialists may be used in the application of +SAFE for both process appraisals and process improvement. The organization may have alternative practices that meet the intent of the specific practices in +SAFE. and apply a systematic approach to process improvement using an improvement process such as SEI’s IDEAL model [McFeeley 1996]. terminology. the organization must implement processes from the CMMI Process Management process area category. safety specialists may be used. and are able to reference relevant sections of CMMI when required. and developing appropriate improvement recommendations. safety specialists may be used in developing appropriate improvements to safety processes. The Appendices and Glossary. To use this guidance effectively.

. everything else). “expected” (i. and Decision Analysis and Resolution. may be used to appraise organization processes. The +SAFE extension contains similarly classified content. including terms specific to CMMI models. and other words that have a special meaning in CMMI models.. as 8 | CMU/SEI-2006-TN-038 . or safety principles. Organizations may meet specific and generic goals without performing expected specific and generic practices (i. The interactions are described in more detail in CMMI Framework Interactions on page 9. including those described in the +SAFE safety extension.e. These terms are defined in Parts 1 and 3 of CMMI-DEV. and in designing improvements. and organizations may chose whether or not to adopt +SAFE expected practices or to make use of +SAFE informative material. Of particular interest to users of +SAFE is the abbreviation SP for “specific practice”. the process areas of a CMMI model do not typically map one-to-one with the processes used in an organization. safety procedure. by performing “alternative practices”). or “informative” (i.8. Process Areas and Capability Levels The CMMI continuous representation supports the independent appraisal and improvement of each of the process areas described in a CMMI model.e. Process Areas Versus Process Descriptions CMMI is a model that provides guidance for developing processes. safety practice.. specific and generic practices). identify strengths and weaknesses. Organizations may draw on alternative bodies of knowledge instead of those used for the informative sections of the model.e. and Informative Content Content in CMMI models is classified as either “required” (i. Abbreviations. Etc. Any process area. commencing with level 1 and working upward.) CMMI defines a range of terminology. (these CMMI process areas are not covered in detail in this document). +SAFE does not use this abbreviation for safety plan. including application domain(s) and organization structure and size. Conventions (Numbering Systems. The actual processes used by an organization depend on many factors. 1.1 Key CMMI Concepts This section lists some key CMMI concepts important to understand before using +SAFE.. It is not a set of process descriptions that can be directly applied in an organization. Thus. Required. and improve these processes through the achievement of specific and generic goals in the capability levels.figuration Management. Expected. The +SAFE extension provides guidance in specific practices and elaborated generic practices in each of its process areas to assist users in identifying strengths and weaknesses. An organization focusing on appraising and/or improving its processes related to a process area endeavors to satisfy the goals of each capability level. specific and generic goals).e.

The relationships between Safety Engineering and the Engineering process area category of CMMI is more complex. is not based on any specific reference standard and is not country specific. The interactions of the process areas remain as described in Figure 4.4 of CMMI-DEV).long as the processes they implement meet the required specific and generic goals of the safety process areas. Each goal of Safety Engineering is associated with one or more of the Engineering process areas and must be achieved concurrently with the goals of these other process areas. Safety Management influences the performance of the Project Planning. +SAFE was designed to recognize these relationships. and Supplier Agreement Management process areas in a similar manner to Risk Management.9 ACRONYMS AND DEFINITIONS The acronyms and definitions in Table 3 are used in this document. The safety extension also creates some new relationships. +SAFE terminology. Unless a reference is cited. unless specifically noted. and the Support process areas of CMMI are generic and the interactions described in CMMI-DEV are applicable to the +SAFE process areas. or work products are subsumed by generic practices.5 of CMMI-DEV. +SAFE process areas are assigned to process area categories in CMMI in recognition of some of these relationships. Safety Engineering is intended to influence the performance of all Engineering process areas. Few of the +SAFE specific practices. and between process areas and capability levels. but it also influences the Risk Management process itself. by treating safety risks as a special case. Further. • • • 1. The relationships among Safety Management. SOFTWARE ENGINEERING INSTITUTE | 9 . sub-practices. The interactions between Safety Management or Safety Engineering and CMM-DEV generic practices are also generic and the interactions described in CMMI-DEV are applicable to the +SAFE process areas. terms have the meaning defined in this section or their dictionary meaning. Safety Engineering.2 CMMI Framework Interactions Part 1 of a CMMI-DEV model identifies a number of interactions and interdependencies among process areas in process area categories. and it is unlikely that duplicate observations would result from an appraisal using +SAFE specific practices and CMMI generic practices. 1.8. but Safety Engineering overlays each process area. Project Monitoring and Control. which are a by-product of the design decision to structure the extension as a set of separate process areas rather than as an embedded extension of CMMI: • The relationship between Safety Management and the basic Project Management process areas of CMMI is similar to the relationship between the Risk Management process area and the basic Project Management process areas (refer to Figure 4.

of CMMI-DEV for definitions of all other CMMI terms. A situation with the potential to lead to an accident. damage to property or the environment..” which is. The Appendices and Glossary.” The maximum level of risk of a particular technical process or condition that is regarded as acceptable in the circumstances in question. or economic loss. Capability Maturity Model Integration Capability Maturity Model Integration for Development CMMI with the safety extension. There is currently little quantitative evidence that the methods and techniques recommended are actually effective in achieving the associated safety targets. fatalities and serious and/or minor injuries). An event or sequence of events that leads to harm. Acronym or Glossary Term +SAFE accident Meaning The safety extension to CMMI. Hence +SAFE avoids the word “effective. damage to or loss of data. Defence Materiel Organisation. Unless +SAFE has extended a CMMI term and the extended definition is included below. refer to Part 3. loss of product capability. also known as a “mishap” or “hazardous event. “appropriate” is intended to mean that there is consensus that the method or technique is suitable for the relevant safety target. The consequence when a safety risk matures.g. used in CMMI. however. Some standards such as Def (Aust) 5679 and IEC 61508 recommend appropriate methods and techniques. Types of harm include harm to people (e. acceptably safe appropriate CMMI CMMI-DEV CMMI +SAFE DMO harm hazard 10 | CMU/SEI-2006-TN-038 .Standard CMMI abbreviations and numbering systems are used. Australian Department of Defence. When applied to a method or technique used in safetyrelated engineering.

or developed from analysis or development policy. level of trust. The statement is usually structured as an argument and its supporting evidence. safety case argument safety criteria See safety argument. SOFTWARE ENGINEERING INSTITUTE | 11 safety critical safety function . and tested sufficiently to justify it being safe. Also known as “safety case argument. military off the shelf off the shelf An acceptable level of risk. A functional requirement that is needed to ensure the safety of the product. The limits of acceptable risk associated with a hazard. A measure of the level of confidence or trust that one wishes to have that the product meets a given product safety requirement. we define safety in terms of the level of risk that is deemed acceptable.. based on a safety assessment. Also known as safety functional requirement. Also known as a system safety assessment (SSA) and assurance case. the safety case is either: (1) the complete body of evidence that proves an item was designed and integrated correctly to approved standards by competent people in accordance with approved procedures with sufficient mitigation. zero risk) is not generally achievable. Therefore. Absolute safety (i.e. and a risk analysis (with recommendations) of the differences. or (2) a well-reasoned summary document detailing what the original safety program aims were versus what was actually achieved. has safety requirements that must be satisfied for the product or product component to be accepted for service. These limits may be defined (externally) as imposed safety targets.high-level safety argument LOT A safety argument for a major function or component of a safety-critical product. A product or product component that.” MOTS OTS safety safety argument safety case Depending on the domain. The statement of why a particular characteristic of a product or product component meets safety requirements and safety targets.

product. These requirements include safety functional requirements and their associated safety targets. The project or product lifecycle in which safety processes are performed. When applied to a situation. (2) raises the requirement for a modification or change to procedures or products as a result of the event.2 aligns with CMMI-DEV. the (safety) risk presented is a combination of the likelihood and consequence (i. An event in which injury or damage could have occurred and either: (1) raises concern about the safety of any person. mission. or (3) highlights a lesson to be learned from the event. Products. The following changes are forecast to +SAFE: • Development of +SAFE to span and cross reference other CMMI constellations Development of additional training and case studies for applying the model for both appraisal and improvement. or processes used to implement a function or component of safety. Any requirement that is needed to ensure the safety of the product. A safety target is intended to express how safe an implementation of the safety requirement must be. Management and engineering principles for developing and operating systems and product components so that they are most likely to meet safety requirements. • 12 | CMU/SEI-2006-TN-038 . or procedure.safety functional requirement safety incident See safety function.e. safety lifecycle safety related safety risk safety principles safety requirement SCAMPI SEI (safety) target Table 3: Acronyms and Definitions 1.2. Version 1. A qualitative or quantitative target associated with a safety requirement.. items. severity of any resulting harm). Standard CMMI Appraisal Method for Process Improvement.10 CHANGES FORECAST +SAFE Version 1. Software Engineering Institute.

• Provision of guidance on target capability profiles and the recommended scope of appraisals. SOFTWARE ENGINEERING INSTITUTE | 13 .

14 | CMU/SEI-2006-TN-038 .2 +SAFE This section consists of the two +SAFE process areas that specifically address safety: • • Safety Management Safety Engineering These process areas are presented in the same format and style as other CMMI process areas.

14 | CMU/SEI-2006-TN-038 .

The integration of safety management with other planning viewpoints (e. and managing them in accordance with the plans Developing and implementing agreements with suppliers for the acquisition of safety-related products and services The Safety Management process area addresses the need for the project to effectively consider safety requirements and how they may be satisfied by both management activities and technical methods.g. and targets to establish plans for safety activities that satisfy safety requirements Implementing the plans. and that adopts these management principles: • • Safety issues should be addressed early in the project lifecycle. the performance and results of safety activities are monitored against the plan. monitoring. SOFTWARE ENGINEERING INSTITUTE | 15 . Introductory Notes The Safety Management process area involves the following: • • • Using safety principles. components. and schedule) ensures that safety activities are given the planning. supplier agreement management. safety management ensures that relevant requirements are incorporated into supplier agreements and that these agreements are satisfied. risk. Safety assurance requires independent visibility of both the product and the process. monitoring safety incidents.. and control focus commensurate with their importance. and services. and deviations from plans are corrected. Safety management is a continuous process that spans the lifecycle of the project. cost. and should be tracked throughout. criteria.SAFETY MANAGEMENT A Project Management Process Area Purpose The purpose of Safety Management is to ensure that safety activities (including those relating to suppliers) are planned. quality. When suppliers external to the project are used to provide products.

Refer to the Risk Management process area for more information about risk identification. and preparation of the safety case. safety verification and validation. and mitigation. 16 | CMU/SEI-2006-TN-038 . Refer to the Supplier Agreement Management process area for more information about managing supplier agreements. technical solutions. Refer to the Safety Engineering process area for more information about hazard identification and analysis. and evolutionary process must be used. which could be useful for developing a safety strategy. (Technical aspects of safety risk management are dealt with in the Safety Engineering process area. continuous. An iterative. development of safety requirements. analysis. Refer to the Project Monitoring and Control process area for more information about monitoring project activities.• • Related Process Areas Safety assurance must be transferable to parties outside the project (including suppliers). risk assessment.) Refer to the Project Planning process area for more information about developing project plans and integrating different planning viewpoints. Refer to the Decision Analysis and Resolution process area for more information about using a formal evaluation process to evaluate alternatives.

SG 2 Monitor Safety Incidents Safety incidents are monitored. Generic Goals GG 1 Achieve Specific Goals The safety management process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.1 Monitor and Resolve Safety Incidents Manage Safety-Related Suppliers SP 3. Practice to Goal Relationship Table SG 1 Develop Safety Plans SP 1. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process.1 Establish Supplier Agreements That Include Safety Requirements SP 3. and Standards SP 1. SG 3 Manage Safety-Related Suppliers The acquisition of safety-related products and services from suppliers external to the project is managed by means of a formal agreement that includes safety requirements. and resolved. safety criteria. GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. reported. GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GG 2 Institutionalize a Managed Process The process is institutionalized as a managed process. analyzed.2 Satisfy Supplier Agreements That Include Safety Requirements SG 2 SG 3 SOFTWARE ENGINEERING INSTITUTE | 17 .4 Establish a Safety Plan Monitor Safety Incidents SP 2.1 Determine Regulatory Requirements.3 Establish a Safety Organization Structure for the Project SP 1. and safety management principles are established and maintained as a basis for managing safety throughout the project lifecycle. Legal Requirements.Specific Goals SG 1 Develop Safety Plans Safety plans based on safety requirements.2 Establish Safety Criteria SP 1.

18 | CMU/SEI-2006-TN-038 .2 Plan the Process GP 2.8 Monitor and Control the Process GP 2. and safety management principles are established and maintained as a basis for managing safety throughout the project lifecycle. analyzing.1 Perform Specific Practices Institutionalize a Managed Process GP 2. are identified and documented. Legal Requirements. Applicable specific regulatory requirements.7 Identify and Involve Relevant Stakeholders GP 2. documenting.2 Collect Improvement Information Institutionalize a Quantitatively Managed Process GP 4. or requirements for compliance with standards for processes or work products.1 Establish an Organizational Policy GP 2. legal requirements. Where such requirements are directly applicable to the domain. they should be integrated with requirements that are developed as a result of hazard and risk assessment on the project.4 Assign Responsibility GP 2.2 Correct Root Causes of Problems GG 3 GG 4 GG 5 Specific Practices by Goal SG 1 Develop Safety Plans Safety plans based on safety requirements.9 Objectively Evaluate Adherence GP 2.. SP 1.3 Provide Resources GP 2.1 Establish Quantitative Objectives for the Process GP 4.10 Review Status with Higher Level Management Institutionalize a Defined Process GP 3.g. Refer to the Requirements Development process area for more information about eliciting. Such requirements may either be directly applicable to the domain (e. and Standards Identify and document regulatory requirements. and applicable standards. safety criteria.6 Manage Configurations GP 2.1 Establish a Defined Process GP 3.GG 1 GG 2 Achieve Specific Goals GP 1. legal requirements. avionics) or should be tailored to the domain. and validating requirements.2 Stabilize Subprocess Performance Institutionalize an Optimizing Process GP 5.5 Train People GP 2.1 Determine Regulatory Requirements.1 Ensure Continuous Process Improvement GP 5.

Requirements source lists Requirements categories list Safety requirements specification Product requirements specification (with safety annotations) Safety requirements trace Subpractices 1. In general. An example in which multiple safety standards may be applicable is the production of a missile. consider the compatibility of the standards and the resolution of conflicts. legal. and regulatory product and work performance standards. 4. The intention of +SAFE is to allow for the approaches described in most modern safety standards. under Australian common law. or common law sources. Safety requirements may arise from contractual. If multiple safety standards are used. Safety standards differ in their approach to safety. 3. 2. Some countries place a legal obligation on suppliers of safety-related equipment or services irrespective of contractual requirements (or lack thereof). which can involve separate standards for the following: • Ordnance • Electromagnetic interference • Avionics Typical Work Products 1. an organization owes a duty of care to its employees and to members of the public who may be inadvertently harmed by that organization’s activities. Determine requirements sources. Safety requirements are elicited from the sources identified and collected into related groups or categories where they are organized and documented. This process assists in the subsequent development of safety strategies and plans. Refer to the Risk Management process area for more information about the identification and analysis of project risks. categorize. 5. it is preferable to use the framework of a single safety standard if this approach is sufficient to cover the scope of the project’s requirements. For example. Identify. SOFTWARE ENGINEERING INSTITUTE | 19 . safety standards must be applied consistently within a project. however. and document safety requirements. 2.Refer to the Safety Engineering process area for more information about establishing safety requirements based on analysis of project safety risks.

The types of harm that may be considered include the following: • Harm to people (fatalities and serious or minor injuries) • Damage to property or the environment • Loss of product capability • Damage to or loss of data • Economic loss Refer to the Requirements Development process area for more information about eliciting needs. Safety requirements should be traceable to their sources. SP 1.The following factors may be considered when determining safety requirement categories: • The phases of the project’s lifecycle model • The types of processes used • The types of products used • The risk management taxonomy or framework used by the project Safety requirements may be documented in a safety requirements specification or included with other product requirements. or the organization itself. regulatory bodies. Refer to the Requirements Management process area for more information about traceability of requirements to source requirements. In this light. defining the likelihood and consequence of each risk. customers. which may include safety targets. The acceptable level of risk may be defined qualitatively or quantitatively. 20 | CMU/SEI-2006-TN-038 . the concept of “acceptably safe” is applied through the definition of what is considered to be an acceptable level of risk. The parameters for scaling likelihood and consequence are normally aligned with the parameters used for rating other types of risk. Safety criteria may include targets (or failure probability objectives) for various types of harm. using safety criteria.2 Establish Safety Criteria Establish and maintain safety criteria that reflect the level of acceptable safety. and acceptable levels within these dimensions. Safety criteria may also include risk assessments. Safety targets are usually derived from policies set by government. It is a generally accepted concept that absolute safety is unachievable.

3. The applicability of the targets and the scope of the risk assessment should be recorded to ensure that hazard identification and risk assessment activities are complete and provide a record of the justifications for any exclusions from the assessment scope. Safety targets are defined for each of the safety requirements or situations where a target is required. showing acceptable levels of risk c.g. These methods may be selected on the basis of other safety requirements (e. regulatory requirements that include safety targets) or on aligning them with the broader risk management approach of the project. Risk indices 2. Targets and their applicability b.Refer to the Risk Management process area for more information about the analysis and categorization of project risks and risk mitigation strategies. Acceptable levels of risk are defined for each of the safety requirements. 2. Criteria may be based on the harm attributable to the following: • • • • • All products Each product Each product component Each accident Each hazard Typical Work Products 1. Hazard/risk likelihood/impact matrix. The safety requirements or situations in which acceptably safe criteria must be defined are identified and methods for defining acceptably safe levels of risk are selected. Safety criteria (usually contained in the safety plan) expressed as one or more of the following: a.. Determine safety targets and/or acceptable levels of risk. Document safety criteria for required harm types and scopes. SOFTWARE ENGINEERING INSTITUTE | 21 . Identify requirements for safety criteria. Safety strategy (usually contained in the safety plan) Subpractices 1. The scope of safety targets and the scope of acceptable levels of risk may be apportioned in various ways.

It should also provide for the resolution of disputes relating to safety. Any exclusions from the analysis are identified and justified.g. Associated with acceptable levels of risk are thresholds for triggering action to mitigate against exceeding acceptable levels.. or assessment consider designs from a fresh perspective and reveal problems that might not be identified by those who are closer to the design. and ensuring adequate levels of managerial and technical independence. including specifying roles and duties of personnel and groups. their applicability. The line of appeal should be to a person in the organization with authority higher than the project manager. Example elements of a safety organization structure for a project include the following: • • • • Safety roles and responsibilities in the project The duties for each safety role in the project Reporting lines and communication channels between safety roles and from safety roles to other roles in the project The level of authority for each safety role in the project structure (e.3 Establish a Safety Organization Structure for the Project Establish and maintain a safety organization structure for the project. and their scope. then that person should be given a line of appeal outside the project. Staff members who are responsible for independent verification. and for the independent audit of safety processes and safety cases. If a person other than the project manager is given responsibility for safety management within the project. validation. providing reporting channels. A safety organization structure for a project should include the need for managerial and technical independence in the conduct of safety-related activities. acceptable levels of risk. SP 1.Safety criteria are specified as targets. Independence is important for ensuring the following: • • Staff members in a safety role are not put under unreasonable pressure to acquiesce on safety issues. ability to initiate work or financial authority) 22 | CMU/SEI-2006-TN-038 .

2.4 A project manager who supervises both a technical manager and a safety manager A safety manager who can report to both the project manager and to another manager who is independent of project pressures Safety personnel who report to both the technical manager and the safety manager Safety representatives from suppliers reporting to a safety manager Establish a Safety Plan Establish and maintain a safety plan. The methods and techniques may vary according to the complexity and/or safety targets SOFTWARE ENGINEERING INSTITUTE | 23 . Typical Work Products 1. such as audits and evaluations. an organization chart may include the following: • • • • SP 1. validation. The safety plan is established using safety management principles and references applicable regulatory requirements and standards. The planning should also cover safety engineering and support processes for safety verification. Project organization chart and responsibility allocation matrix Project safety plan For example. which may include safetyrelated training. and independent safety assessment activities. and use of appropriately trained and knowledgeable personnel.Example roles to be documented in the structure of a project safety organization include the following: • • • • • • • • Acceptance body Certification body Safety management group System safety working group Safety manager Safety engineers Safety authority Quality assurance Refer to the Organizational Training process area for more information about establishing strategic training needs. the project safety lifecycle. Many standards specify particular methods and techniques that are considered to be appropriate for safety-related work.

The safety plan is reviewed and accepted by both project management and the independent line of reporting for safety issues. Verification techniques Schedules for safety evaluation activities and event entry and exit criteria Project safety organization. A safety plan typically addresses or references the following: • • • • • • • • • • • Product description Program safety requirements. integrating. 4. and targets Integration of the safety engineering lifecycle and processes with product development and the project lifecycle model Identification of key safety milestones Integration of safety engineering with support processes such as configuration management and change management. 2. criteria.of the products being developed. including mitigation. 24 | CMU/SEI-2006-TN-038 Document the project safety lifecycle and its processes. and the tracking of dependencies Risk assessment procedures and hazard analysis techniques Hazard tracking and resolution procedures. and gaining commitment to plans. . 5. These issues should be considered in safety planning. 8. Safety plan Certification plan Safety verification plan Safety validation plan Independent safety assessment plan Safety acceptance plan Safety staff skills and experience matrix Safety training plan 7. Subpractices 1. 6. and acceptance procedures A detailed description of the process of deriving safety requirements and the rules and techniques for each level of trust or safety integrity levels. and plans for ensuring project staff have the required level of safety skills and knowledge Typical Work Products 1. Refer to the Project Planning process area for more information about establishing. review. 3. roles and responsibilities.

) Establish training requirements. report.Document a safety lifecycle for the project and product. Attitudinal characteristics of safety-related staff are significant selection criteria. reported. and resolved. it may be possible to train people to meet the required competency. Safety must be ensured throughout each lifecycle. (Where there are shortfalls against the competency requirements and it is not possible to train existing staff to the required competency. 3. skills. projects should aim to obtain staged acceptance as the project progresses.) Establish recruitment requirements. Safety acceptance of the project plans and the product should be sought at key points in the project lifecycle. Planning should document the key stages of the acceptance. 2. and resolve safety incidents and maintain safety analyses. etc. from initial concept through to disposal. Plan for safety acceptance. Processes are in place and a culture has been promoted to ensure that safety-related incidents that arise during the project lifecycle are SOFTWARE ENGINEERING INSTITUTE | 25 . it is particularly important that staff have adequate experience. For safety-related activities. SP 2. The project safety lifecycle should be integrated into the overall project lifecycle. (Competency requirements are documented in terms of expected qualifications. and who provides acceptance at each stage. and skills.1 Monitor and Resolve Safety Incidents Monitor. years of experience. The product safety lifecycle should cover all product lifecycle phases. issues relating to safety should be addressed as early as possible. analyze. analyzed. In particular. selection criteria can also include licensing schemes that ensure staff members are licensed before they undertake unsupervised safety-critical work: • Establish competency requirements. these processes should be identified and integrated with other project processes. Planning for safety acceptance may be contained in a project verification and validation plan instead of the safety plan.) • • SG 2 Monitor Safety Incidents Safety incidents are monitored. training. To reduce the risk of major acceptance problems late in the project is reduced. (Where there are shortfalls against the competency requirements. Plan for needed knowledge and skills in the performance of safetyrelated activities. what is delivered for assessment. Where specific processes must be performed to satisfy the safety strategy. In certain domains. then it may be necessary to engage specialists.

reported. Reported incidents are resolved by reviewing the existing hazard analysis and risk assessment in the project safety plan, and updating the analysis as necessary. The resolution of such incidents may result in the need for corrective or preventative action, including the update of both safety-related and non-safety-related project artifacts. Refer to the Measurement and Analysis process area for more information about data collection and reporting. Refer to the Project Monitoring and Control process area for more information about monitoring activities, which can include monitoring safety incidents and can form the basis for initiating review actions. Refer to the Causal Analysis and Resolution process area for more information about identifying root causes, which when applies to safety incidents, can enable initiating preventative action.
Typical Work Products

1. 2. 3. 4. 5. 6. 7.

Minutes of meetings (e.g., of the safety management group) Updated project safety plan Updated hazard analysis Updated safety case Updated hazard log Incident reports Change requests

Subpractices

1.

Monitor and analyze safety incidents. The status of safety activities and their results are monitored on a periodic and event-driven basis. Any incidents are reported and logged, and the safety plan is reviewed to ensure that the incidents are effectively managed to closure, or change requests are generated to revise the safety plan. The collection of incident reports is analyzed for trends that may require revisions to the safety plan.

2.

Resolve safety incidents. Incidents either are managed to closure using the existing safety plan, or the plan (including hazard log, hazard analysis, and safety cases) is revised to manage the incident and to include any required preventative actions.

26 | CMU/SEI-2006-TN-038

SG 3

Manage Safety-Related Suppliers

The acquisition of safety-related products and services from suppliers external to the project is managed by means of a formal agreement that includes safety requirements.
SP 3.1 Establish Supplier Agreements That Include Safety Requirements

Analyze the project’s needs to acquire safety-related products and services, select suppliers, and include appropriate safety requirements in supplier agreements.
Where a need to acquire a safety-related product or service is identified, select an appropriate supplier and establish an agreement that includes relevant safety requirements. When procuring safety-related products and services, supplier agreements should allow for necessary monitoring activities and should require the delivery of safety assurance (e.g., a safety case) with any delivered product. The acquirer retains responsibility for the impact that the acquired product components or services has on the safety of the product. Give particular consideration to the acquisition of off-the-shelf (OTS) products, which may be acquired from commercial suppliers (commercial off-the-shelf or COTS), government (government off-theshelf or GOTS), or outside the project in the acquirer organization itself (e.g., military off-the-shelf or “MOTS”). The advantages of OTS products could be offset by the unknowns in their safety characteristics, which may not be determined economically from the product itself. Appropriate evaluation activities should be undertaken and the results of these activities used as input to supplier agreement development.
For Software Engineering Selection of COTS software to use in a product may involve comprehensive review of field-use data with the software vendor, and a design approach that allows for the product to detect failures and operate in a functionally degraded but acceptably safe mode in the event of COTS software failure. Depending on the criticality of the COTS software component, the integrator or product developer may wish to appraise the development or production processes used by the software supplier as part of the development of the supplier agreement.

Refer to the Decision Analysis and Resolution process area for more information about evaluating and selecting among alternatives, which may include externally-supplied products, services, and suppliers. Refer to the Supplier Agreement Management process area for more information about developing and managing supplier agreements, including the handling of OTS products.

SOFTWARE ENGINEERING INSTITUTE | 27

Refer to the Technical Solution process area for more information about incorporating the results of formal evaluations of OTS products into the design of the solution.
Typical Work Products

1. 2. 3.

Supplier agreements that include safety requirements Supplier management plan (or relevant section of the project management plan) Subcontractor management plan (or relevant section of the project management plan)

Subpractices

1.

Ensure that all products and services to be acquired are assessed to establish whether or not they are safety-related. In general, the project should assume that all products and services to be acquired are safety-related unless proven otherwise.

2. 3.

Establish safety requirements for each safety-related product and service. Include consideration of safety risk when selecting suppliers. Suppliers should be assessed to ensure they have appropriate processes, skills, and experience for supplying safety-related products and services.

4.

Include safety requirements in the supplier agreements. The supplier agreement should include safety requirements for the product or service. It should cover the following:
• How the supplier interacts with the project on safety matters (e.g., lines of communication for safety matters that link into the project safety organization structure) • The commitment of both the project and the supplier to participate in ongoing safety activities (e.g., through participation in a safety working group) • The need to deliver a safety case as part of the safety-related product or service • The commitment of the supplier to report all project-related safety incidents to the project in a timely manner

5.

Create an appropriate level of involvement between the organization and its supplier. The supplier agreement should include the responsibility of the organization and the supplier to provide support for each other’s activities. This support may involve the presence of personnel on the product safety working groups and other groups set up by the other organization.

28 | CMU/SEI-2006-TN-038

SP 3.2

Satisfy Supplier Agreements That Include Safety Requirements

Execute supplier agreements that include safety requirements and ensure that safety assurance is delivered with the product or service.
Supplier agreements are executed and monitored. Procedures should be in place to monitor progress and performance of safety-related suppliers (e.g., through regular progress reviews and/or audits examining safety-related activities). Special provisions for the acquisition of “off the shelf” (OTS) products may require specific monitoring and review. The project should ensure that suitable safety assurance is delivered with any product delivered as part of the agreement (e.g., in the form of a safety case). Refer to the Supplier Agreement Management process area for more information about establishing and managing supplier agreements, including the handling of OTS products. Refer to the Verification process area for more information about ensuring that products and services meet their requirements. Refer to the Requirements Management process area for more information about managing the traceability of requirements, including safety requirements.
Typical Work Products

1. 2. 3.
4. 5. 6.

Safety requirements specifications Product requirements specifications (with safety annotations) Review minutes Audit records Supplier assessment records and recommendations Product or service verification records

Subpractices

1.

Establish traceability of safety issues between the organization and the supplier. In general, the majority of safety requirements flow from the organization to the supplier. Assumptions made by either party must be propagated throughout the system to check their validity. Safety analysis of the supplier may need to be constructed and used in the context of a wider safety analysis of the organization.

SOFTWARE ENGINEERING INSTITUTE | 29

1 Establish and Maintain an Organizational Policy Establish and maintain an organizational policy for planning and performing the safety management process. Considerations that are important when acquiring OTS products include the following: • Transferring existing safety assurance of the OTS product into a suitable form for the project • Securing the operational history of the OTS product • Ensuring compatibility of the organization’s environment with the original environment of an OTS product when transferring assurance or using operational histories • Accurately identifying the configuration or version of OTS products • Ensuring any transferred assurance or operational history applies to the version of the OTS product supplied • Identifying and analyzing unspecified functionality of OTS products • Securing ongoing support of the OTS product Generic Practices by Goal GG 1 Achieve Specific Goals The safety management process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. Supporting the supplier may involve the inclusion of the organization in meetings of groups within the supplier such as the system safety working group. and other support practices. competencies. 2. 30 | CMU/SEI-2006-TN-038 .Other issues requiring traceability include schedules.1 Perform Specific Practices Perform the specific practices of the safety management process to develop work products and provide services to achieve the specific goals of the process area. GG 2 Institutionalize a Managed Process The process is institutionalized as a managed process. Periodic meetings and reviews may be part of monitoring. GP 1. Monitor and support the technical performance of the supplier. GP 2.

such as safety assurance. SOFTWARE ENGINEERING INSTITUTE | 31 . or contract management. Elaboration: Typically. which can be applied to planning the safety management process. the certification authority liaison. The project and subordinate plans address the specific needs and objectives for the project.Elaboration: Policies for the safety processes of the organization are established.2 Plan the Process Establish and maintain the plan for performing the safety management process. and standards that are applicable to most of the organization’s projects are identified and documented. and providing the services of the process. However. elements of the plan for performing the safety management process are part of the project plan (as described in the Project Planning process area). some parts of the plan may reside outside the project with one or more independent groups. These parts of the plan address both project and organizational viewpoints. Refer to the Project Planning process area for more information about planning. legal requirements.3 Provide Resources Provide adequate resources for performing the safety management process. The policies should be appropriate for projects to develop safety processes. GP 2. developing the work products. tailor these requirements for their specific needs. Regulatory requirements. Projects determine the applicability of these requirements and standards and. GP 2. if necessary.

g. 32 | CMU/SEI-2006-TN-038 . independence considerations can be dealt with in the organization (i. Example elements of a safety organization structure at the organization level include the following: • • • • Safety roles and responsibilities in the organization The duties for each safety role in the organization How the safety roles in the organization as a whole interact with individual projects Reporting lines and communication channels between safety roles and from safety roles to other roles in the organization GP 2.3 for management independence in the conduct of safety-related activities. systems. developing the work products.5 Train people Train the people performing or supporting the safety management process as needed.4 Project-independent oversight and escalation of safety issues Specialists that provide technical advice (e.. Typically. and provision for the resolution of disputes relating to safety apply to the assignment of responsibility for performing the safety management process. and providing the services of the safety management process. quality]) Specialist supplier and contract management staff Preferred supplier lists Requirements trace and incident tracking programs Hazard log tracking tools (containing analysis arguments or references) Failure mode and effects analysis tools Assign Responsibility Assign responsibility and authority for performing the process. Elaboration: The concerns described in SP 1.e. software. Safety staff within projects can then be provided with lines of appeal to independent safety staff within the organization as a whole.Elaboration: Examples of resources provided include the following: • • • • • • • GP 2.. distinct from the project) structure by providing safety staff that are not attached to specific projects. user requirements representatives and specialist engineers [human factors.

Examples of training topics include the following: • • • • • • • • Safety awareness programs Product safety Safety planning Safety incident reporting Hazard identification and analysis Causal analysis Application domain-specific training (e. Traceability of safety requirements to agents such as external suppliers or certifiers also generates configuration management requirements for both work products and inputs of the safety management process. Project Monitoring and Control. SOFTWARE ENGINEERING INSTITUTE | 33 . flight systems) Related process areas: Project Planning. GP 2. Risk Management.g. and a culture that ensures safety planning and management is appropriately prioritized with other planning and management viewpoints.Elaboration: Effective performance of the safety management process requires people with a combination of safety discipline and application domain skills.6 Manage Configurations Place designated work products of the safety management process under appropriate levels of control. and experience.. Elaboration: The level of configuration management deemed appropriate may depend on the safety requirements for the product in question. Process and Product Quality Assurance. knowledge. and Configuration Management Refer to the Organizational Training process area for more information about identifying and meeting training needs.

location) Safety checklists Incident reports Refer to the Configuration Management process area for more information about the management of configuration items.Example work products to be placed under configuration management include the following: • • • • • • • Safety plans Hazard log Hazard analysis Safety analysis Designations of safety-critical items (identity. not only to involve them in the project and to keep them informed of outcomes. The identification of such stakeholders is important. Example stakeholder groups include the following: • • • • • • Customer requirement representatives Engineering discipline experts Regulatory authorities Test and evaluation centers Stores clearance specialists Explosive safety boards 34 | CMU/SEI-2006-TN-038 . but to ensure that independence is not compromised by a conflict of interest. Elaboration: Stakeholders may have a safety-related interest in the outcome of the project. Some standards require the establishment of a safety working group to aid in involving stakeholders in managing and performing safety activities. GP 2.7 Identify and Involve Relevant Stakeholders Identify and involve the relevant stakeholders of the safety management process as planned.

g.9 Objectively Evaluate Adherence Objectively evaluate adherence of the safety management process against its process description. and address noncompliance.8 Safety plans Safety requirements User safety constraints Customer-related safety instructions Monitor and Control the Process Monitor and control the safety management process against the plan for performing the process and take appropriate corrective action. and procedures. typically by a team (e. procedures. requirements. standards. and objectives. Refer to the Project Monitoring and Control process area for more information about monitoring activities and managing corrective action. the safety working group or a milestone review team). Elaboration: The project is monitored against the project safety plan. Corrective action may include updates to the safety plan. Elaboration: Perform safety product and process audits periodically as a means of confirming that the safety process is implemented as planned and that it satisfies applicable safety policies. Refer to the Process and Product Quality Assurance process area for more information about objective evaluations. Residual risk levels can be monitored expecting that there will be gradual rectification. standards. GP 2.Example work products requiring stakeholder involvement in their development or approval include the following: • • • • GP 2. A hazard log provides one mechanism for checking the progress of safety activities. Audits are carried out throughout the project lifecycle by independent auditors with dual lines of reporting. SOFTWARE ENGINEERING INSTITUTE | 35 . Corrective action is taken when the project deviates significantly from the project safety plan.

Examples of safety work products include the following: • • • • • • • GP 2. and results of the safety management process with higher level management and resolve issues. including independent reporting lines.Examples of safety activities reviewed include the following: • • Safety planning Safety verification Safety audits do not cover the scope of a functional safety assessment or independent safety assessment. Typically. 36 | CMU/SEI-2006-TN-038 . these reviews include a summary of progress against safety criteria. and any safety issues that require escalation. to provide visibility into project safety risk exposure and appropriate corrective action. Refer to the Project Monitoring and Control process area for more information about progress and milestone reviews. GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process.1 Establish a Defined Process Establish and maintain the description of a defined safety management process. the status of risk mitigation efforts. Refer to the Safety Engineering process area for more information about independent safety evaluations. Elaboration: Reviews of the project safety status are held on a periodic and eventdriven basis with appropriate levels of management. status.10 Audit reports Defect reports Updated safety plan Safety requirements specification Hazard analysis and hazard log Risk assessment reports Review and walkthrough checklists Review Status with Higher Level Management Review the activities. GP 3.

measures. GP 4.GP 3. GP 5. GP 4.2 Correct Root Causes of Problems Identify and correct the root causes of defects and other problems in the safety management process.2 Collect Improvement Information Collect work products. and improvement information derived from planning and performing the safety management process to support the future use and improvement of the organization’s processes and process assets.2 Stabilize Subprocess Performance Stabilize the performance of one or more subprocesses to determine the ability of the safety management process to achieve the established quantitative quality and process performance objectives. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. measurement results.1 Ensure Continuous Process Improvement Ensure continuous improvement of the safety management process in fulfilling the relevant business objectives of the organization.1 Establish Quantitative Objectives for the Process Establish and maintain quantitative objectives for the safety management process that address quality and process performance based on customer needs and business objectives. SOFTWARE ENGINEERING INSTITUTE | 37 . and improvement information include the following: • • • • GG 4 Results of safety management reviews Results from analysis of safety incidents Supplier performance reports Independent evaluations of supplier safety work products Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GP 5. measurement results. measures. Elaboration: Examples of works products.

38 | CMU/SEI-2006-TN-038 .

The integration of safety engineering with other engineering processes (involving requirements. plans. SOFTWARE ENGINEERING INSTITUTE | 39 . formal mathematical proof of correctness may be appropriate. and evolutionary development process is required. and plan implementation The Safety Engineering process area addresses the technical analysis and engineering of safety requirements and the application of safety engineering principles in the development of a technical solution. and verification) ensures that safety aspects of the requirements and technical solution are engineered at appropriate points in the project lifecycle. that critical functions should be as simple as possible. and that for the most critical cases. and isolated from the rest of the product. integration. and sources of hazards. technical solution. accidents. and analysis of those identified to assess safety-related risk Development of safety requirements that address safety-related risks Application of safety principles throughout the project lifecycle to ensure that safety requirements are satisfied Development of an audit trail that can support safety acceptance and provide the information needed to validate safety strategies. and that their priority relative to other requirements or characteristics of the solution is explicitly addressed. The specific practices in Safety Engineering employ the technical safety principles that safety is best achieved by using tried and trusted techniques. that an iterative. Introductory Notes The Safety Engineering process area involves the following: • • • • Identification of hazards.SAFETY ENGINEERING An Engineering Process Area Purpose The purpose of Safety Engineering is to ensure that safety is adequately addressed throughout all stages of the engineering process. continuous.

Refer to the Verification process area for more information about verifying that work products satisfy their requirements. Refer to the Product Integration process area for more information about the iterative. Refer to the Validation process area for more information about acceptance criteria. Refer to the Process and Product Quality Assurance process area for more information about activities that verify that process descriptions. Refer to the Technical Solution process area for more information about developing a technical solution that meets requirements. procedures. and supplier management. planning.Related Process Areas Refer to the Safety Management process area for more information about safety criteria. and validation of requirements. analysis. incremental assembly of the product. 40 | CMU/SEI-2006-TN-038 . and standards are adhered to during the development process. Refer to the Requirements Development process area for more information about elicitation. monitoring and control.

GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. and Sources of Hazards SP 1. Accidents.Specific Goals SG 1 Identify Hazards. accidents. Accidents. SG 5 Support Safety Acceptance The process of safety acceptance is supported by establishing and maintaining a hazard log and safety case. SG 3 Define and Maintain Safety Requirements Safety requirements are developed and maintained to address the hazards. Generic Goals GG 1 Achieve Specific Goals The safety engineering process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. and through validation of the assumptions of safety activities.2 Identify Possible Hazards Analyze Hazards and Perform Risk Assessments SP 2.1 Analyze Hazards and Assess Risk SOFTWARE ENGINEERING INSTITUTE | 41 SG 2 . SG 2 Analyze Hazards and Perform Risk Assessments Analyze hazards and perform risk assessments. through independent safety assessments. and sources of hazards are identified.1 Identify Possible Accidents and Sources of Hazards SP 1. Practice to Goal Relationship Table SG 1 Identify Hazards. and Sources of Hazards Hazards. SG 4 Design for Safety Safety principles are applied throughout the project lifecycle and safety requirements are satisfied. GG 2 Institutionalize a Managed Process The process is institutionalized as a managed process. GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process.

2 Determine a Safety Target for Each Safety Requirement SP 3.2 Correct Root Causes of Problems SG 4 SG 5 GG 1 GG 2 GG 3 GG 4 GG 5 Specific Practices by Goal SG 1 Identify Hazards.1 Ensure Continuous Process Improvement GP 5.7 Identify and Involve Relevant Stakeholders GP 2. 42 | CMU/SEI-2006-TN-038 .4 Assign Responsibility GP 2. SP 1.5 Train People GP 2.8 Monitor and Control the Process GP 2.1 Perform Specific Practices Institutionalize a Managed Process GP 2.1 Establish a Hazard Log SP 5.1 Determine Safety Requirements SP 3.1 Apply Safety Principles SP 4.SG 3 Define and Maintain Safety Requirements SP 3.1 Identify Possible Accidents and Sources of Hazards Identify possible accidents and sources of hazards. and sources of hazards are identified. accidents.2 Collect Improvement Information Institutionalize a Quantitatively Managed Process GP 4. and risk assessment are steps in an iterative process that may be revisited multiple times during the project lifecycle.3 Provide Resources GP 2.4 Perform Independent Evaluations Achieve Specific Goals GP 1.3 Allocate Safety Requirements to Components Design for Safety SP 4.1 Establish an Organizational Policy GP 2.2 Stabilize Subprocess Performance Institutionalize an Optimizing Process GP 5. Accidents.1 Establish Quantitative Objectives for the Process GP 4.10 Review Status with Higher Level Management Institutionalize a Defined Process GP 3. and Sources of Hazards Hazards. hazard analysis.9 Objectively Evaluate Adherence GP 2.6 Manage Configurations GP 2.2 Collect Safety Assurance Evidence SP 4.1 Establish a Defined Process GP 3. Hazard identification.3 Validate Product Safety for the Intended Operating Role SP 5.2 Develop a Safety Case Argument SP 5.2 Plan the Process GP 2.3 Perform Safety Impact Analysis on Changes Support Safety Acceptance SP 5.

Acronyms and Definitions. for examples of alternate terms. 2. typically in a hazard log.9. The following are examples of potential sources of hazards: • • Separation of turbine blades in an aircraft engine while under load Containment failure and leakage of toxic materials in a processing plant For Software Engineering An example of a potential source of hazard is dead (unused) code. 3. 5.2 Hazard checklist Hazard log Accident list Hazard source lists (external and internal) Hazard category lists Identify Possible Hazards Identify and document possible hazards using an appropriate model of the product as a basis. the easier and more cost-effective it is to deal with them.The identification of potential accidents is a useful first step in the hazard identification process. Typical Work Products 1. 4. Different standards use different terminology to describe accidents. The following are examples of potential accidents: • • A mid-air collision of aircraft An explosion in a processing plant Identifying sources of hazards helps to provide a structure to hazard identification. Refer to section 1. Methods for identifying sources of hazards include referencing standard safety practices appropriate to the product and referencing regulatory requirements. It is important that hazard identification is as complete as possible. For Software Engineering An example of a standard safety practice for software that uses data from field (physical) sources is range checking of all input data. SOFTWARE ENGINEERING INSTITUTE | 43 . The earlier hazards are identified in the project lifecycle. Information about hazards is logged. SP 1.

5. Refer to the Technical Solution process area for more information about designing the product. Documenting the scope and interfaces of the product to be delivered enables identification of hazards on that boundary. Refer to the Requirements Development process area for more information about establishing operational concepts and scenarios and defining required functionality. 6. Use a systematic approach that includes consideration of all phases of the project lifecycle. 3. 3. Product environment and boundary definition Hazard analysis scope definition Functional model of the product Hazard and operability analysis (HAZOP) tables Functional failure analysis (FFA) tables Hazard log Subpractices 1. Document the scope and interfaces of the product to be delivered.The success of hazard identification and analysis depends largely on the model of the product used. A functional model of the product can provide an effective basis for hazard identification and analysis. Refer to the Requirements Development process area for more information about identifying interfaces and documenting requirements. which will help you in documenting system boundaries. A graphical representation of the product can help the hazard identification and analysis team understand the product. 2. which provide the basis for creating a functional model of the product. This model should genuinely reflect the current system concept and design and should provide sufficient detail on the intended functionality of the product to allow a systematic hazard analysis. 44 | CMU/SEI-2006-TN-038 . Systematic approaches include hazard and operability analysis (HAZOP) and functional failure analysis (FFA). Use the model of the product as the basis for hazard identification and hazard analysis. 4. Typical Work Products 1. 2. 4. Define the functionality of the product.

g. Apply a structured.1 Analyze Hazards and Assess Risk For each hazard. and preconditions for each hazard. which may include personnel with the following experience: • Relevant domain experience • Knowledge of all parts of the project lifecycle (e. and maintenance) • Experience with hazard identification Historical data should be used. and assess the severity of the risk presented by that hazard. and checklists specific to the domain. SP 2. but use other alternate measures to analyze and classify risks. An example of an alternative measure that is applied in analyzing risk is the use of assigned “levels of trust. operation. Document all hazards identified. 5. and consequence. with consideration given to the effectiveness of those teams. likelihood. Refer to the Safety Management process area for more information about the consideration of all lifecycle phases. Refer to the Risk Management process area for more information about identifying and analyzing risks. Cross reference each hazard to all of the following: • Related analysis • Related safety requirements • Related verification requirements and records SG 2 Analyze Hazards and Perform Risk Assessments Hazards are analyzed and risk assessments performed.” which are based on the level of control that the product has over the initiation or prevention of the hazard. SOFTWARE ENGINEERING INSTITUTE | 45 .Teams of personnel should be formed to perform the hazard analysis. likelihood. Some standards do not require the development of risk indices as a combination of likelihood and consequence. commissioning. analyze possible causes. including information on past incidents and accidents. Combine these elements to determine the potential risk posed by the hazard. Appropriate personnel should be involved. and compare the potential risk with criteria for risk mitigation and management strategies. systematic method or methods to determine potential consequences.

effects. of each hazard related to the product.. 3. Failure modes and effects analysis reports Failure modes. A quantitative measure of the likelihood of a potential accident is based on the analysis of the hazards for which that accident is a possible consequence. The likelihood of each individual event in the event sequence that results in an accident may be drawn from sources such as the following: • Manufacturer’s specifications of involved equipment • Historical data from previous accidents When systematic failures are seen as contributing to the likelihood of an accident (e.g. Assess the likelihood of potential accidents. 1 occurrence every 10. or extremely rare) or quantitatively (e. Subpractices 1. or 1 occurrence every 100 missions). the process is often reversed to set safety targets for system failure rates. 2. 10 fatalities. Approaches to systematic consequence analysis include failure modes and effects analysis.. Systematic causal analysis approaches include fault tree analysis and event tree analysis. where software failures may cause the accident). or 1 severe injury). 6. Likelihood may be assessed qualitatively (e. and criticality analysis reports Event tree analysis reports Fault tree analysis reports Risk assessment reports Hazard logs 5. major. Assess and determine potential consequences of hazards. frequent. Determine all potential consequences.. Determine sequences of events leading to hazards..g.000 operations. The likelihood of the hazard leading to accidents is assessed. 1 fatality. Determine the conditions and events that lead to hazards. Instead.. quantitative analysis is generally seen as inappropriate. 4. Combine consequence and likelihood to obtain the estimate of risk presented by each hazard. or minor) or quantitatively (e. including accidents. rare. 1 occurrence in 10 years.g. 46 | CMU/SEI-2006-TN-038 .g. 3. 4.Typical Work Products 1. Consequences may be assessed qualitatively (e. catastrophic.g. 2.

2 Determine a Safety Target for Each Safety Requirement Determine an applicable safety target for each safety requirement. and standards sources of safety requirements and targets. A target may apply to one or more requirements. Typical Work Products 1.1 Determine Safety Requirements Determine the safety requirements based on the outcome of the hazard identification. risks. hazard analysis. these hazards shall be addressed by safety requirements. Quantitative targets may be expressed as a frequency of hazardous failure. and safety criteria. 5. and specify the required safety target for each safety function. and risk assessment. Where a risk exceeds criteria. SG 3 Define and Maintain Safety Requirements Safety requirements are developed and maintained to address the hazards. Where the hazard analysis and risk assessment identify hazards that are either unacceptable or must be reduced. Refer to the Requirements Development process area for more information about the development of requirements. These requirements are maintained throughout the project lifecycle. SP 3.Refer to the Risk Management process area for more information about defining risk parameters. Safety requirements are developed that specify the safety functions addressing the hazards. a risk management strategy is invoked to mitigate against the maturing of the risk. 2. SP 3. Typically. Safety targets may be specified qualitatively or quantitatively. Safety requirements specification Product requirements specification (with safety annotations) Refer to the Safety Management process area for more information about the regulatory. Compare the risk presented by each hazard with the criteria for acceptability. SOFTWARE ENGINEERING INSTITUTE | 47 . legal. the requirements specify the means of mitigating or detecting and reducing the exposure time of the hazard.

A qualitative target may be expressed as requirements for processes used in the development or testing of components to meet safety requirements. the requirements for the processes do not replace the target for the safety function. Refer to the Safety Management process area for more information about the regulatory. This determination can be achieved through derivation of the acceptable risk that was set for each hazard during hazard analysis and risk assessment. Compare the assessed risk against the acceptable risk. and should ensure the estimates of assessed risk used in the hazard analysis and risk assessment are carried forward into product design. Hazards may be eliminated during the development of a technical solution. legal. The safety target should ensure the level of risk presented by the product is less than or equal to the acceptable risk. software products). 48 | CMU/SEI-2006-TN-038 . 2. 2. Determine any hazards associated with each safety requirement. achievement of the qualitative target is intended to satisfy (but generally does not guarantee satisfaction of) the quantitative target. 4. However. Safety requirements specification Product requirements specification (with safety–related requirements annotated) Records of traceability between requirements and targets 3. This determination can be achieved through derivation from the risk assessment of each hazard. 3. Where products suffer from systematic failures (e. Where qualitative targets have been derived from quantitative targets. and standards sources of safety requirements and targets. Typical Work Products 1. Compare the assessed risk for each safety requirement with the acceptable risk for each safety requirement.. The required reliability of a safety function may be translated to requirements for the processes used to develop and test that safety function. Subpractices 1. quantitative targets are often replaced by qualitative targets. Set a safety target for each safety requirement. Determine the acceptability of the hazards associated with each safety requirement.g. Satisfying qualitative process targets does not necessarily satisfy quantitative targets. and on selection of product safety standards.

Safety requirements are allocated to components in a manner consistent with the capabilities of the components.3 Allocate Safety Requirements to Components Safety requirements are allocated to product components and safety-related products. In cases where combinations of components are responsible for satisfying the requirement. Refer to the Decision Analysis and Resolution process area for more information about identifying.It may be infeasible to determine if a safety target has been met (e. 2. Allocate requirements to components of the solution. Safety requirements may be allocated to product components or combinations of components. where failures are systematic in nature or where failure rates are sufficiently low to make testing prohibitively time consuming). However. Refer to the Requirements Development and Technical Solution process areas for more information about allocating product component requirements. Note that this allocation may create a need for new solution components. In such cases. 2. 3. evaluating. SOFTWARE ENGINEERING INSTITUTE | 49 . Technical data package that addresses safety Requirement allocation sheets Records of traceability for requirements and safety targets Subpractices 1. SP 3. Use of appropriate qualitative methods does not ensure that safety targets have been satisfied. safety targets may be used in determining how the product is to be developed. Typical Work Products 1.. This specific practice provides information for defining the allocation of safety requirements but must interact with the specific practices in the Technical Solution process area to establish solutions to which the requirements are allocated.g. and selecting alternatives. such translations from quantitative targets to qualitative methods are generally not applicable in reverse. Allocate requirements and design constraints to functions. 3. Document relationships among allocated requirements and traceability of targets. the performance should be partitioned for unique allocation to each product component as a derived requirement.

1 Apply Safety Principles Select solutions based on safety principles. However. Select Product Component Solutions. and Perform Make. SG 4 Design for Safety Safety principles are applied throughout the project lifecycle and safety requirements are satisfied. These principles may affect the solution development process. The specific practices of this goal provide information on how safety requirements may be satisfied but must interact with the specific practices in the Technical Solution process area to deliver solutions that satisfy all requirements. 50 | CMU/SEI-2006-TN-038 . The chosen solution should be appropriate to meet the safety requirements. and the resources used in the process. Refer to the Technical Solution process area for more information about how a technical solution is developed and selected. SP 4. such as Develop Alternative Solutions and Selection Criteria.The allocation of safety requirements also allocates safety targets to solution components. its methods and tools. Refer to the Verification process area for more information about how verify that requirements are met. Many of the specific practices of the Technical Solution process area may be affected by the application of safety principles. based on the available knowledge at the time when the decision is made. Safety principles are applied at appropriate points in the project lifecycle and in the performance of all processes to ensure that safety requirements are satisfied. safety principles have broader application than to the safety requirements for the solution and its components. Buy or Reuse Analysis. Refer to the Technical Solution process area for more information about solution design and development.

ALARP is the principle of applying mitigations until the costs of applying such mitigations outweigh the benefit gained. Refer to the Decision Analysis and Resolution process area for further information on how to evaluate identified alternatives using a formal evaluation process. 3. Alternative solutions incorporating safety principles Solution selection criteria addressing safety Safety-related decisions and rationales as applied in productcomponent selection Subpractices 1. ALARP may result in reduction beyond that level. 2. SOFTWARE ENGINEERING INSTITUTE | 51 . Where a level of acceptability has been set. An example order of precedence might be to apply the following (from highest precedence to lowest precedence): • • • • • Redesign to eliminate the risk due to the hazard Redesign to reduce the risk due to the hazard Incorporate safety devices Incorporate warning devices Develop training and operational procedures The extent to which solutions are developed to address safety may also be determined according to safety principles.Examples of alternative solutions that may be applied to a particular problem include the following: • • • • • • Redundancy in architecture Diversity in architecture Isolation of critical components Alarms and warnings Protective clothing Emergency procedures and responses The selection of alternative solutions may be applied according to an order of precedence. alternatives are not mutually exclusive. Typical Work Products 1. Establish selection criteria for safety principles at relevant points in the development lifecycle. The principles applied may include “as low as reasonably practicable” (ALARP) and the precedence in which to apply mitigations.

Refer to the Requirements Management. recovering from faults. 4. Use selected safety principles to contribute to the development of alternate solutions. and limiting the effects of damage resulting from faults. and Process and Product Quality Assurance process areas for more information about some of the activities that may be called on for supporting evidence. Use selected safety principles to contribute to the selection of the product component solution that best satisfies the criteria established. Validation. Use appropriate implementation methods to develop the safetyrelated product. Ensure that supporting evidence is collected that will make the safety case valid. Technical Solution. SP 4. including setting safety targets for safety requirements. 5. Ensure simplicity in the design of the safety-related product. Consider means of detecting faults. Refer to the Safety Management process area for more information about safety assurance in purchased components and services. Configuration Management.2. Typical Work Products 1. 3. Verification. The actual evidence is determined by the activities planned for and the outcomes of safety activities. 6. Analysis reports Review minutes and comments Test records Implemented design Validation test reports Audit reports Subpractices 1. 3. 52 | CMU/SEI-2006-TN-038 .2 Collect Safety Assurance Evidence Ensure that evidence to validate the safety case is developed and collected in all the processes involved in the production of the product throughout the project lifecycle. Requirements Development. 2. Evidence may also be influenced by the safety standard chosen and the practices recommended or not recommended under various circumstances.

The implementation techniques used should be appropriate to the safety requirements and safety targets. Use appropriate verification techniques. implementation methods may include techniques such as the following: • Use of a safe subset of a high level programming language • Use of multiple redundancy. data. For Software Engineering Selection of COTS software for use in a product may involve appraisal of the development and production processes used by the software supplier and collection of assurance data from the appraisal. Evidence that off-the-shelf products were verified by the product supplier may not be available to the acquirer. SOFTWARE ENGINEERING INSTITUTE | 53 . However. Some standards suggest techniques to use at different levels of risk. the attributes of the implementation techniques used by the supplier. multiple language implementations. or path coverage. Verification techniques used should be appropriate to the safety requirements and safety targets. 2. the acquirer has little or no control over the selection of implementation techniques by the supplier. and voting systems • Use of trusted kernels and services Where use of an off-the-shelf product has been selected as the preferred method of implementation. Alternate techniques for verification may need to be adopted. For Software Engineering For critical software components. and their effect on the safety characteristics of the product must be evaluated. Example analysis and design techniques include the following: • The use of formal (mathematical) proofs in high-assurance cases • Verification of components and the product using simulation For Software Engineering Review and inspection techniques may include the use of structured reviews such as the software technique called a Fagan inspection. Refer to the Technical Solution process area for more information about solution implementation. Testing techniques may require testing to a particular level of structural.

3. Document the results of safety verification. Refer to the Validation process area for more information about documenting validation procedures and results. Trace validation activities to safety requirements and targets. 7. Corrective action may be required as a result of verification activities.Example verification techniques include the following: • Use of field-use data. Document the results of safety validation. Use appropriate safety validation techniques. confirming a validation may include the use of statistical testing techniques to demonstrate a quantitative requirement has been satisfied. Refer to the Requirements Management process area for more information about traceability between requirements and work products. Refer to the Verification process area for more information about establishing verification procedures and criteria as well as analyzing verification results. If validation is carried out using simulation. 6. 8. Trace verification activities to safety requirements and targets. For example. including reference sites and service histories • Accelerated service-life testing Refer to the Verification process area for more information about work product verification. All verification evidence should be collected and documented to demonstrate that the safety requirements and targets have been satisfied. Refer to the Requirements Management process area for more information about the traceability between requirements and work products. Refer to the Validation process area for more information about establishing validation procedures and criteria. which can include validation plans and results. 4. which can include verification plans and results. 54 | CMU/SEI-2006-TN-038 . The validation techniques used should be appropriate to the safety requirements and targets. Analyze the results of verification. 5. then the validity of the simulation should be confirmed.

Safety acceptance is often dependent on external factors and agencies (e. 2. an impact analysis is carried out to assess the impact on safety. Refer to the Validation process area for more information about acceptance testing. SOFTWARE ENGINEERING INSTITUTE | 55 . The specific practices of this goal provide information on how safety acceptance may be supported. 4. Where a change affects a hazard and risk assessment carried out in earlier parts of the project lifecycle.SP4.g. SP 5. Typical Work Products 1. or use different mechanisms to achieve the same result. changes should not violate any of the assumptions in the hazard and risk assessment. it may be necessary to repeat the analysis. Some safety standards identify alternate practices to the specific practices covered under this specific goal. 3. Hazard information is kept up to date with changes as they occur. In particular.1 Establish a Hazard Log Establish and maintain a method of logging and tracking hazard status. Changes are approved before they are made and all changes are documented. It is important that proposed changes are assessed in terms of their impact on safety. SG 5 Change proposals Change records Impact analysis Updated hazard analysis and hazard log Support Safety Acceptance The process of safety acceptance is supported by establishing and maintaining a hazard log and safety case (or equivalents) through independent safety assessments and through validation of the assumptions of safety activities. but must interact with the specific practices in the Validation process area to gain acceptance of all requirements.. regulatory bodies) and each may impose its own requirements for acceptance evidence.3 Perform Safety Impact Analysis on Changes When changes are proposed to the requirements or the design.

Typical Work Products 1. 56 | CMU/SEI-2006-TN-038 . In such cases. the status of each hazard must be monitored regularly. 3.2 Develop a Safety Case Argument An argument is developed to outline how it will be shown that the product is acceptably safe.. other documents may be used to achieve the same goal (e. A coherent argument for the safety of the product 2. Hazard log Hazard status summaries Action requests Example hazard information to be logged includes the following: • • • • • • • • • • • • A complete description of the hazard Who identified the hazard and when The consequences of the hazard and the severity of any resulting accidents What could cause the hazard Risk assessment of the hazard How the hazard is detected. A safety case presents an argument for the safety of the product being developed by the project. SP 5. A safety case should consist of two parts: 1. 2.Once a hazard has been identified and documented. controlled. To effectively track a hazard to closure. safety assessment report).g. its status should be tracked to closure. or mitigated The subsequent impact of risk management actions on risk likelihood and consequences Safety requirements that are derived from the hazard Where the safety requirements are addressed in the design Verification requirements that are derived from the safety requirements Verification records Cross references to other documents (that may document the above hazard information). The status of hazards provides a good basis for monitoring and controlling project progress against safety matters. The supporting evidence for the argument Not all safety standards require the development of a safety case.

it is helpful to produce multiple documents that make up the overall safety case. supporting evidence is cross-referenced from the main body of the argument. For some products. To ensure the argument is readable. comprehensible (to all stakeholders). including the results of safety assessments SP 5. complete. It includes plans. and defensible. High-level safety argument Cross references to supporting evidence Supporting evidence Typically. Examples of safety case content include the following: • • • • • • A high-level summary of the safety argument Relevant standards and regulatory requirements The configuration baseline All identified hazards and the residual risk of each All operational and support assumptions All safety-related design decisions and features and the rationale for each Typical Work Products 1. either through validating on site or through simulation. verification reports. specifications.3 Validate Product Safety for the Intended Operating Role Validate that the safety requirements and safety targets for the product’s intended use are satisfied in the product’s intended environment. 2. An example stage-based safety case release is the use of developmental phase and aircraft kit-proof (first article) phase safety cases in aircraft development. analysis reports. in these instances the structure of the documents should be clear. 3. the supporting evidence is the safety documentation developed throughout the project safety lifecycle.It can be advantageous to release the safety case in incremental stages throughout the project to gain early acceptance of the project safety approach and to support project lifecycles in which incremental safety acceptance is a requirement. SOFTWARE ENGINEERING INSTITUTE | 57 . consistent. and should cover all stages of the project lifecycle. Supporting evidence for a safety case includes the following: • • • evidence of hazard identification and risk assessment activities evidence of system hazard analysis activities evidence of all safety assurance activities. and validation reports. The safety argument should be clear.

The recommendations of the evaluator are used as part of the final decision of the acceptance body. 3. safety processes. the evaluator presents findings and recommendations to the person responsible for safety acceptance. Validation plan and procedures Validation environment Validation results Subpractices 1. Evaluators consider the design from a fresh perspective and reveal problems that might not be identified by those who are closer to the design. Typically.Refer to the Validation process area for more information about the validation of products. An independent evaluation is carried out by investigating the project and the products developed by the project. Some standards specify levels of independence to achieve sufficient objectivity. 2. It is important to confirm that product performance in operation meets its specified performance and that assumptions made in the safety analysis are validated in operation. and the safety case. SP 5. Validate the assumptions that are used in the safety case. Typical Work Products 1. Continue to validate the product when in operation.4 Perform Independent Evaluations Perform independent evaluations of the product. Independence is important for ensuring the following: • • Evaluators are not put under unreasonable pressure to acquiesce on safety issues. 58 | CMU/SEI-2006-TN-038 . 2. The evaluation includes the following: • • • Familiarization with the product Familiarization with the hazards of the product Review and analysis of project deliverables The evaluation may also include reworking parts of the safety work carried out by the project.

if necessary. services. GP 2. The policies should be appropriate for projects to develop safety processes. and processes. and standards that are applicable to most of the organization’s projects are identified and documented. GG 2 Institutionalize a Managed Process The process is institutionalized as a managed process. legal requirements. GP 2. Regulatory requirements.1 Perform Specific Practices Perform the specific practices of the safety engineering process to develop work products and provide services to achieve the specific goals of the process area. Safety evaluation report Independent safety assessment report Generic Practices by Goal GG 1 Achieve Specific Goals The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. Typical Work Products 1.2 Plan the Process Establish and maintain the plan for performing the safety engineering process. GP 1. Elaboration: Policies for the safety processes of the organization are established.Refer to the Safety Management process area for further information on the independence of evaluators. tailor these requirements for their specific needs. Refer to the Process and Product Quality Assurance process area for more information about independent evaluation of work products.1 Establish an Organizational Policy Establish and maintain an organizational policy for planning and performing the safety engineering process. 2. SOFTWARE ENGINEERING INSTITUTE | 59 . Projects determine the applicability of these requirements and standards and.

such as safety assurance. 60 | CMU/SEI-2006-TN-038 .g. developing the work products. developing the work products..4 Specialist technical staff (e. the certification authority liaison. software. and providing the services of the process.Elaboration: Typically. These parts of the plan address both project and organizational viewpoints. systems. some parts of the plan may reside outside the project with one or more independent groups. However. The plan for safety engineering may take on various formats according to the requirements of regulatory agencies. quality]) Hazard log tracking tools (containing analysis arguments or references) Failure mode or effects analysis tools Assign Responsibility Assign responsibility and authority for performing the process. Elaboration: Examples of resources provided include the following: • • • GP 2. user requirements representatives and specialist engineers [human factors.3 Provide Resources Provide adequate resources for performing the safety engineering process. or contract management. GP 2. although these elements may be contained in the project plan (as described in the Project Planning process area). and providing the services of the safety engineering process. elements of the plan for performing the safety engineering process are part of the safety plan. Examples of safety engineering process plans include the following: • • • • • System safety plan System safety program plan Plan for software aspects of certification Safety management plan Verification and validation plan Refer to the Project Planning process area for more information about planning activities.

such as external suppliers or certifiers. flight systems) Refer to the Organizational Training process area for more information about training for activities. Elaboration: Effectively performing the safety engineering process requires people with a combination of safety discipline. and experience. Elaboration: The level of configuration management deemed appropriate may depend on the safety requirements for the product in question. knowledge.. the application domain skills. GP 2.g. SOFTWARE ENGINEERING INSTITUTE | 61 . also generates configuration management requirements for work products and inputs of the Safety Engineering process. and requirements for independence determine who is assigned responsibility and authority for safety engineering practices. Examples of training topics include the following: • • • • • • Safety awareness System safety Safety incident reporting Hazard identification and analysis Causal analysis Application domain-specific topics (e. statutory and regulatory requirements. engineering discipline. GP 2.5 Train People Train the people performing the safety engineering process as needed.Elaboration: The safety plan or project plan.6 Manage Configurations Place designated work products of the safety engineering process under appropriate levels of control. Traceability of safety requirements to agents. the organization’s safety policies. and a culture that ensures that safety engineering is appropriately prioritized relative to other engineering viewpoints.

For example.7 Identify and Involve Relevant Stakeholders Identify and involve the relevant stakeholders of the safety engineering process as planned. GP 2.Example work products to be placed under configuration management include the following: • • • • • Hazard log Hazard analysis Safety analysis Safety checklists Incident reports Refer to the Configuration Management process area for more information about managing configuration items. Elaboration: Stakeholders may have a safety-related interest in the engineering activities of the project. then the suppliers of those products may be concerned about electro-magnetic interference from the new product and should be included as stakeholders. the safety working group.g. or product experience required to perform those activities. if the project is developing a product that resides in the vicinity of other safety-related products. typically by a team (e. Relevant stakeholders of many of the engineering activities are those with the domain. Elaboration: The project is monitored against the project safety plan. For example.. The corrective action may include updates to the safety plan. technology. 62 | CMU/SEI-2006-TN-038 . Corrective action is taken when the project deviates significantly from the project safety plan. design review group). a hazard analysis should be performed by a diverse range of personnel to ensure that the analysis addresses the wide range of aspects that may affect safety.8 Monitor and Control the Process Monitor and control the safety engineering process against the plan for performing the process and take appropriate corrective action. GP 2.

and procedures. Refer to the Project Monitoring and Control process area for more information about monitoring and controlling activities. Residual risk levels can be monitored expecting that there will be gradual rectification. Elaboration: Perform safety product and process audits periodically as a means of confirming that the safety engineering process is implemented as planned and satisfies safety policies.9 Objectively Evaluate Adherence Objectively evaluate adherence of the safety engineering process against its process description. Audit the work products of safety processes to ensure they comply with requirements and applicable process descriptions. and results of the safety engineering process with higher level management and resolve issues. standards. and address noncompliance. standards.A hazard log provides one mechanism for checking the progress of safety activities. and procedures. GP 2.10 Review Status with Higher Level Management Review the activities. standards. Examples of safety activities that are audited include the following: • • • Analysis of hazards Selection of product components Derivation and allocation of safety requirements Examples of safety work products that are audited include the following: • • Safety cases Hazard logs Refer to the Process and Product Quality Assurance process area for more information about evaluating work products. requirements. status. Audit safety processes against safety planning documentation and applicable procedures. GP 2. and objectives. SOFTWARE ENGINEERING INSTITUTE | 63 . Audits are performed throughout the project lifecycle.

to provide visibility into project safety risk exposure and appropriate corrective action. GP 3.2 Collect Improvement Information Collect work products. GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. 64 | CMU/SEI-2006-TN-038 . and improvement information derived from planning and performing the safety engineering process to support the future use and improvement of the organization’s processes and process assets. GP 3. and any safety issues that require escalation. including independent reporting lines. these reviews include a summary of progress against safety criteria. GP 4.1 Establish Quantitative Objectives for the Process Establish and maintain quantitative objectives for the safety engineering process that address quality and process performance based on customer needs and business objectives.2 Stabilize Subprocess Performance Stabilize the performance of one or more subprocesses to determine the ability of the safety engineering process to achieve the established quantitative quality and process performance objectives.Elaboration: Reviews of project safety status are held on a periodic and event-driven basis with appropriate levels of management. the status of risk mitigation efforts. Typically. GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. Refer to the Project Monitoring and Control process area for more information about the review of project status and conducting progress reviews. measurement results. GP 4. measures.1 Establish a Defined Process Establish and maintain the description of a defined safety engineering process.

1 Ensure Continuous Process Improvement Ensure continuous improvement of the safety engineering process in fulfilling the relevant business objectives of the organization. SOFTWARE ENGINEERING INSTITUTE | 65 . GP 5.GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. GP 5.2 Correct Root Causes of Problems Identify and correct the root causes of defects and other problems in the safety engineering process.

66 | CMU/SEI-2006-TN-038 .

or independently. CMMI Framework Interactions on page 9 should be referenced to identify the implications for the appraisal and its results. Table 4 summarizes the cross references (by +SAFE specific goal) to CMMI process areas. The related process areas and cross references to CMMI process areas identified in each +SAFE process area highlight the benefits that may be gained if a +SAFE appraisal is performed as part of.2 process model. the appraisal team must evaluate the level of expertise it has available and supplement its subject matter expertise if required. CMMI process area Safety Management SG1 Causal Analysis and Resolution Configuration Management Decision Analysis and Resolution Measurement and Analysis Organizational Training Process and Product Quality Assurance Project Monitoring and Control Project Planning Requirements Development √ √ √ √ √ √ √ √ √ √ √ √ SG2 √ √ √ SG3 Safety Engineering SG1 SG2 SG3 SG4 SG5 SOFTWARE ENGINEERING INSTITUTE | 67 . 3. Although +SAFE process extension presents the safety-related processes separate from CMMI-DEV. a broader CMMI appraisal. but. +SAFE process areas may be appraised as part of a broader CMMI–based appraisal. and the additional training module for +SAFE (available from DMO). The safety extension has been written assuming appraisers have undertaken normal CMMI appraiser training. 3. as with other CMMI process areas.1 Using +SAFE with CMMI Where +SAFE process areas are appraised independently. in the same way as other CMMI process areas.1. or in addition to. this approach is intended only to encourage a focus on safety during an appraisal. +SAFE does not assume that appraisers will have a high level of knowledge in safety. as with the appraisal of any CMMI process area.3 Usage Guidelines This section describes guidelines for the use of +SAFE for appraisals and process improvement.1 PROCESS APPRAISAL CONSIDERATIONS +SAFE may be used with any of the appraisal methods applicable to CMMI. V1.

2. This mapping may also identify parts of the +SAFE process areas that may be tailored for a specific appraisal. since both safety critical and nonsafety-critical projects influence the way an organization performs safety activities. To simplify and shorten the appraisal. The product is not safety-critical and safety activities are not attempted. The determination of safety criticality is not a task that should be left to a +SAFE appraisal team on the basis of a brief understanding of the nature of a product. The product is safety-critical and safety activities are attempted. Ideally. For example. the results of an appraisal that tailors out specific practices relating to management of external suppliers will have limited use for internal process improvement and for acquisition risk management. and are not reusable in other contexts. The three basic alternatives regarding safety that are generally seen in projects are as follows: 1. However. 68 | CMU/SEI-2006-TN-038 . an organization’s process descriptions and the organization of these descriptions reflect the processes used in its operations rather than the generic processes described in +SAFE. the +SAFE appraisal team should determine whether to appraise one or more projects that do not attempt any safety activities on the basis of the influence that the inclusion of these project will have on the overall appraisal of an organization to perform safety activities.1. 3. The product is safety-critical or its safety characteristics are unknown and safety activities are not attempted.2 Tailoring for an Appraisal Tailored appraisal results have a specific purpose. Some tailoring must be performed during the appraisal. 3. a mapping should be created prior to the appraisal that illustrates the relationships between the organization’s safety processes and terminology.Requirements Management Risk Management Supplier Agreement Management Technical Solution Validation Verification Table 4: √ √ √ √ √ √ √ √ √ √ √ √ √ Summary of Cross References to CMMI Version 1.2 √ As with the standard components of CMMI. The decision to include a particular project as a sample in a +SAFE appraisal thus relies on a safety appraisal (by suitably qualified appraisers) of whether the project is safety critical. if the appraised organization uses external suppliers. and the processes and terminology used in this extension. a +SAFE appraisal should include samples of each alternative. The following guidelines should be applied in determining which parts of the extension are applied to each project under appraisal.

it should be appraised against the specific goals of the Safety Management process area. it should be appraised against SG3 Define and Maintain Safety Requirements and SG4 Design for Safety of the Safety Engineering process area. If a project achieves SG2 of the Safety Engineering process area. which are the “required” parts How the organization might achieve these goals.2 PROCESS IMPROVEMENT CONSIDERATIONS The +SAFE extension provides guidance on how an organization may achieve capabilities in safety activities. Accidents. the specific and generic goals of the process areas. including components such as specific practices. 3. generic practice elaborations. in other words. and Sources of Hazards and SG5 Support Safety Acceptance of the Safety Engineering process area. and thus determines that the project is safety-related. in other words. and subpractices The structure of the process areas using capability levels. discipline amplifications. it should be appraised against SG2 Analyze Hazards and Perform Risk Assessments of the Safety Engineering process area. • • Table 5 illustrates the process areas and goals that can be selected. and against SG1 Identify Hazards. and thus determines that there are safety requirements. effective use of +SAFE as a guide for improvement of safety process capability relies on the SOFTWARE ENGINEERING INSTITUTE | 69 . If a project achieves SG1 and SG5 of the Safety Engineering process area. As with other CMMI process areas. including their classification as safety-critical or non-safety-critical.• If a project may be safety related. the guidance on improvement priorities and dependencies • • Besides the general guidance on systematic improvement found in the Process Management process area category. the “expected” and “informative” parts. is not part of an appraisal against the +SAFE extension. Project Safety Management SG1 Project is not safety-rated Project may be safety-rated but hazard identification indicates that it is not Project is safety-related but all hazards are acceptable Project is safety-related and some hazards are not acceptable Table 5: Safety Engineering SG1 SG2 SG3 SG4 SG5 SG2 SG3 √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ Sample Selection of Process Areas The evaluation of the correctness of project decisions. in other words. the guidance consists of the following: • What the organization must achieve in performing its safety activities.

Although the +SAFE extension presents safety-related processes separate from the main CMMI process model. If an organization has selected specific standards.same prerequisites as improvement in other process areas. +SAFE makes frequent reference to the need for integrated use of +SAFE and other CMMI process areas. and the need for independent lines of reporting for safety management and practitioners. To a lesser extent. and Decision Analysis and Resolution. or if these standards are imposed by contract. V1. this presentation is not intended to discourage organizations from integrating safety processes with other processes. Safety processes are highly dependent on the Support process areas. including. Safety processes place a significant emphasis on the independence of verification and validation resources. Effective implementation of these process areas is important for sustainable improvement in safety capability. alternative practices for the +SAFE specific and generic practices. Specific guidelines for using the safety process areas are as follows: • +SAFE does not require the use of specific safety standards. the +SAFE framework is intended to accommodate the methods and techniques of the standard.2 and the IDEAL model [McFeeley 1996]. • • 70 | CMU/SEI-2006-TN-038 . Process and Product Quality Assurance. where applicable. and these prerequisites are described in CMMI for Development. particularly for issue escalation. Organizational independence may also be a factor in fostering functional expertise among safety practitioners. safety processes are dependent on Measurement and Analysis and Causal Analysis and Resolution process areas. particularly Configuration Management.

inquiries. and requests for further information to DMO Head of Engineering Electronic and Weapons Systems Division Russell Offices Department of Defence CANBERRA ACT 2600 Approving Authority Chief Executive Officer Defence Materiel Organisation Russell Offices R2-5-C131 CANBERRA ACT 2600 SOFTWARE ENGINEERING INSTITUTE | 71 . Defence Materiel Organisation maintains configuration of +SAFE. Please address comments.Appendix Contact for Further Information Australian Department of Defence.

.

72 | CMU/SEI-2006-TN-038 .

2 (CMU/SEI-2006-TR008. Pittsburgh. Safety of machinery—Functional Safety of SafetyRelated Electrical. Carnegie Mellon University. South Australia.sei. December 2001. Canberra.1. +SAFE – A Safety Extension to CMMI v1.edu/publications/documents/02. SOFTWARE ENGINEERING INSTITUTE | 73 .pdf. PA: Software Engineering Institute. Version 1. Pittsburgh.mod.1 Continuous Representation (CMU/SEI-2002-TR-003.reports/02tr003. Carnegie Mellon University. Defence Standardization.001.sei.dstan. 2005.html. http://www. PA: Software Engineering Institute. 1996.sei. http://www. [McFeeley 1996] McFeeley.0 (CA38809-364).edu/publications/documents/06. Version 1. Version 1. 2004. IDEAL: A User’s Guide for Software Process Improvement (CMU/SEI-96-HB001). December 14. Electronic and Programmable Electronic Control Systems (CEI IEC 62061).edu/publications/documents/06.html. CMMI for Development. Geneva.References/Bibliography [ADoD 1998] Australian Department of Defence. December.edu/publications/documents/96. [ADoD 2001] Australian Department of Defence. [ADoD 2000] Australian Department of Defence. Defence Materiel Organisation. http://www. December 19. [SEI 2002] CMMI Product Development Team. Carnegie Mellon University.uk/data/00/056/01000300. 2000. Safety Management Requirements for Defence Systems. ESC-TR-2002-003). August 2006.K. Carnegie Mellon University. UK: Defence Procurement Agency. Part 1. [SEI 2006] CMMI Product Development Team. [UKMoD 2004] United Kingdom Ministry of Defence. 2001. PA: Software Engineering Institute. [SEI 2001] CMMI Product Development Team. [CEI/IEC 2005] International Electrotechnical Commission. http://www.cmu. http://www.reports/96. Issue 3 (Def Stan 00-56).html. 2001. CMMI for Systems Engineering/Software Engineering. Scotland. PA: Software Engineering Institute. Glasgow. Canberra. Defence Science and Technology Organisation. Bob. August. Safety Process Model Version 0.cmu.7 (CA38809-362).html. ESC-TR-2006-08).hb.cmu. September 1. 1998. Pittsburgh.reports/06hb002. SCAMPI v1. The Procurement of Computer-Based Safety Critical Systems (DEF [AUST] 5679).1: Method Definition Document (CMU/SEI-2001-HB-001). Standard CMMI Appraisal Method for Process Improvement. Defence Materiel Organisation.reports/06tr008.sei. U.cmu. Pittsburgh. Switzerland: International Electrotechnical Commission.

S.pdf. U. UK: Defence Procurement Agency.pdf.[UKMoD 1997] United Kingdom Ministry of Defence. 74 | CMU/SEI-2006-TN-038 . Washington. Safety Management Requirements for Defence Systems. Scotland. DC: United Stated Department of Defense. http://www.uk/data/00/055/01000200. Department of Defense. Issue 2 (Def Stan 00-56). Part 1. 1997.K.weibull. 1993. Glasgow.com/mil_std/mil_std_882c. August 1. Defence Standardization.dstan. [USDoD 1993] U. January 19. http://www.mod. System Safety Program Requirements (MIL-STD-882C).

Arlington. Washington. PA 15213 9. 1. and managing safetycritical products. safety 16. TITLE AND SUBTITLE March 2007 5. +SAFE supplements CMMI-DEV with two additional process areas that provide a basis for appraising or improving an organization’s processes for providing safety-critical products. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) PERFORMING ORGANIZATION REPORT NUMBER CMU/SEI-2007-TN-006 10. 0704-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response. However. it adopts the same assumptions. Send comments regarding this burden estimate or any other aspect of this collection of information. conventions. DC 20503. 6. to Washington Headquarters Services. safety engineering. This extension was developed for standalone use.2: A Safety Extension to CMMI Version 1. AGENCY USE ONLY 2. MA 01731-2116 11. SPONSORING/MONITORING AGENCY REPORT NUMBER HQ ESC/XPK 5 Eglin Street Hanscom AFB. Developing such products requires specialized processes. and to the Office of Management and Budget. including the time for reviewing instructions. Paperwork Reduction Project (0704-0188). 1215 Jefferson Davis Highway. DTIC. (Leave Blank) 4. LIMITATION OF ABSTRACT Unclassified NSN 7540-01-280-5500 Unclassified Unclassified UL Standard Form 298 (Rev.2 AUTHOR(S) FA8721-05-C-0003 Defence Materiel Organisation. sustaining. and completing and reviewing the collection of information. SECURITY CLASSIFICATION OF REPORT 66 18. gathering and maintaining the data needed. This technical report describes the +SAFE extension and how to use it to appraise an organization’s capability in developing. Suite 1204. REPORT DATE 3. SECURITY CLASSIFICATION OF THIS PAGE 19. 7. Software Engineering Institute Carnegie Mellon University Pittsburgh. there are intentional overlaps with CMMI model content and some safety standards. REPORT TYPE AND DATES COVERED Final FUNDING NUMBERS +SAFE. searching existing data sources. NUMBER OF PAGES safety management. It is not intended to be embedded in a CMMI model document. nor does it rely on any specific safety standards. SUBJECT TERMS 15. NTIS 13. and experience. CMMI. maintaining. and terminology as CMMI and is affected by the general process-area and capability-level interactions inherent in CMMI. SUPPLEMENTARY NOTES 12A DISTRIBUTION/AVAILABILITY STATEMENT CMU/SEI-2007-TN-006 12B DISTRIBUTION CODE Unclassified/Unlimited. Directorate for information Operations and Reports.REPORT DOCUMENTATION PAGE Form Approved OMB No. PRICE CODE 17. 2-89) Prescribed by ANSI Std. +SAFE is designed to identify safety strengths and weaknesses and to address identified weaknesses early in the acquisition process. model structure. Since +SAFE is an extension of CMMI. V1. VA 22202-4302. Australian Department of Defence PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. Z3918 298-102 SOFTWARE ENGINEERING INSTITUTE | 75 . 14. ABSTRACT (MAXIMUM 200 WORDS) +SAFE is an extension to CMMI® for Development (CMMI-DEV) that covers safety management and safety engineering. including suggestions for reducing this burden. SECURITY CLASSIFICATION OF ABSTRACT 20. skills. +SAFE was designed to reduce the dependence of CMMI appraisers on safety domain expertise.

76 | CMU/SEI-2006-TN-038 .

Sign up to vote on this title
UsefulNot useful