Configuration Management Practices



Similar documents
CHAPTER 7 Software Configuration Management

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK

The Configuration Management process area involves the following:

Certified Professional in Configuration Management Glossary of Terms

Requirements Management Best Practices

CHAPTER 7 SOFTWARE CONFIGURATION MANAGEMENT

Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements

Configuration & Build Management

Software and Hardware Configuration Management

CMS Policy for Configuration Management

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Software Configuration Management

Eastern Illinois University EISE Configuration Management Plan

Project QA and Collaboration Plan for <project name>

Configuration Management

How To Integrate Software And Systems

Independent Verification and Validation of SAPHIRE 8 Software Configuration Management Plan

Theme 1 Software Processes. Software Configuration Management

HOW TO CREATE USEFUL SOFTWARE PROCESS DOCUMENTATION ABSTRACT

ISO 9001: 2008 Construction Quality Management System Sample - Selected pages (not a complete plan)

Software Quality Assurance: VI Standards

Department of Administration Portfolio Management System 1.3 June 30, 2010

TL 9000 and TS16949 Comparison

CONFIGURATION MANAGEMENT PLAN

THE PROJECT MANAGEMENT KNOWLEDGE AREAS

Software Configuration Management. Addendum zu Kapitel 13

Page 1. Outline of the Lecture. What is Software Configuration Management? Why Software Configuration Management?

Configuration Management - The Big Picture

<name of project> Software Project Management Plan

Reaching CMM Levels 2 and 3 with the Rational Unified Process

CONFIGURATION MANAGEMENT PLAN GUIDELINES

AIRLIE LITTLE BOOK OF CONFIGURATION MANAGEMENT

U. S. Department of Energy. Document Online Coordination System (DOCS) Systems Configuration Management Plan (SCMP)

Configuration Management ISO 10007

The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision of resources to support service requirements.

ISO 9001:2000 AUDIT CHECKLIST

Configuration Management Fundamentals

From Chaos to Clarity: Embedding Security into the SDLC

Quality management systems

Software Configuration Management Plan

Configuration Management Plan (CMP) Template

EXHIBIT L. Application Development Processes

ISO 9001:2000 Gap Analysis Checklist

Eagle Machining, Inc. Quality Management System

Configuration Management in Software Development Life Cycle

D R A F T. Resource Ordering and Status System (ROSS) Software Configuration Management Guidelines

ISO 9001:2008 Audit Checklist

Draft Copy. Change Management. Release Date: March 18, Prepared by: Thomas Bronack

Project Management Guidelines

System Development Life Cycle Guide

PM Planning Configuration Management

Quality Management System-A Revision 7 (NRC-approved Version)

<Project Name> Configuration Management Plan

Software Process Training

ITS Projects Systems Engineering Process Compliance Checklist

STAR JPSS Algorithms Integration Team Configuration Management Plan Version 1.2

Software Process Training

Release Management. ProPath. Office of Information and Technology

U.S. Department of Education Federal Student Aid

Fundamentals of Measurements

What Is Software Configuration Management?

JSP 886 DEFENCE LOGISTIC SUPPORT CHAIN MANUAL VOLUME 7 INTEGRATED LOGISTIC SUPPORT PART 8.12 CONFIGURATION MANAGEMENT

Systems Development Life Cycle (SDLC)

3SL. Requirements Definition and Management Using Cradle

ISO 9001:2000 Its Impact on Software

Baseline Change Control Procedure

Project Management Best Practices

Appendix 2-A. Application and System Development Requirements

Software Project Audit Process

SOFTWARE ASSURANCE STANDARD

How To Write A Contract For Software Quality Assurance

CORPORATE QUALITY MANUAL

What Are Software Developers Facing?

Life Cycle Support Information System. Training Guide

Overview of the System Engineering Process. Prepared by

TREASURY INSPECTOR GENERAL FOR TAX ADMINISTRATION

Configuration Management Self Assessment Checklist

An Introduction to the ECSS Software Standards

Intland s Medical Template

Process and Procedure Definition: A Primer

Software Configuration Management. Software Engineering: A Practitionerʼs Approach, 7/e by Roger S. Pressman

CONTENTS. Preface. Acknowledgements. 1. Introduction and Overview 1 Introduction 1 Whatis the CMMI"? 2 What the CMMI* is Not 3 What are Standards?

ALS Configuration Management Plan. Nuclear Safety Related

VAIL-Plant Asset Integrity Management System. Software Development Process

Technical Baseline Management

Configuration, Change, and Release Management Policies and Procedures Guide

Configuration Management

QUALITY MANUAL 3 KENDRICK ROAD WAREHAM, MA FAX

FAA WILLIAM J. HUGHES TECHNICAL CENTER ATLANTIC CITY INTERNATIONAL AIRPORT, NEW JERSEY 08405

Group18-CUCE2012. Mr. Mobile Project. Software Testing Plan (STP) Version: 4.0. CM Identifier: G18_SE004

1. Introduction. Annex 7 Software Project Audit Process

5 FAH-5 H-510 CONFIGURATION MANAGEMENT

Service Support Kasse Initiatives, LLC. ITIL Configuration Management - 1. version 2.0

Independent Verification and Validation of SAPHIRE 8 Software Project Plan

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction

Requirements-driven Verification Methodology for Standards Compliance

CM00 Change Management High Level

SUPPLIER QUALITY MANAGEMENT SYSTEM QUESTIONNAIRE

Time Monitoring Tool Software Development Plan. Version <1.1>

Transcription:

Safety Critical Software Management Practices Linda Westfall Westfall Team, Inc. International Conference on Software Quality ICSQ 2011 Copyright 1999-2010 Westfall Team, Inc. All Rights Reserved. Management Defined A discipline applying technical & administrative direction & surveillance to: Identify & document the functional & physical characteristics of a configuration item Control changes to those characteristics Record & report change processing & implementation status Verify compliance with specified requirements [ISO/IEC 24765]

SCM Maintains a Balance Flexibility Stability Software configuration management is necessary to enable large teams to work together in a stable environment, yet still have the flexibility that s needed to do creative work. [SPNM-98] The Good News It s Not All or Nothing Work Product Creation Review Development Test Independent Test Release Various Levels of Control Rigor Complete Flexibility Complete Stability

SCM Activities Software Development Software Identification Software Control Software Status Accounting Software Auditing Product Release & Distribution SCM Planning Management of the SCM Functions Software Management Standards AS9100C: 7.1.3 Management The organization shall establish, implement and maintain a configuration management process that includes, as appropriate to the product a) configuration management planning SCM Identification Activities Identification is the SCM function that includes: Identifying software configuration items to be controlled Assigning unique identifiers to each product & its components, & associated documents Defining important characteristics of each configuration item & identifying the owner Identifying component, data & product acquisition points & criteria i Establishing & controlling baselines AS9100C: 7.1.3 Management The organization shall establish, implement and maintain a configuration management process that includes, as appropriate to the product b) configuration identification

What Are Items? item: A work product placed under configuration management & treated as a single entity A collection of hardware or software elements treated as a unit for the purpose of configuration control [NQA-1a] Selecting Items The following items should be placed under configuration management: Externally delivered software products & data Designated internal software work products & data Designated support tools used to create or support the software product Supplier/vendor supplied software Customer supplied equipment/software NQA-1a: Subpart 2.7 Quality Assurance Requirements for Computer Software for Nuclear Facility Applications 203 Software Management: items to be controlled shall include, as appropriate: 1. documentation (e.g., software design requirements, instructions for computer program use, test plans, and results); 2. computer programs (e.g., source, object, back-up files); and 3. support software.

Baseline Defined 1. A specification or product that has been formally reviewed & agreed upon, that thereafter serves as the basis for further development, & that can be changed only through formal change control processes [NQA-1a] 2. A document or set of such documents formally designated & fixed at a specific time during the life cycle of a configuration item Baselines identify how software entities: Are related to each other Are related to software life cycle milestones [ISO/IEC 24765] Functional Baseline System Requirements Software Requirements Types of Baselines Allocated Baselines Design Implement Developmental Baselines NQA-1a: Requirements 3 - Design Control 802.1 Identification: A software baseline shall be established at the completion of each activity of the software design process. Approved changes created subsequent to a baseline shall be added to the baseline. A baseline shall define the most recently approved software configuration. Development Test System Test Product Baseline Operations

Baselines Baselines should be defined for specific control points in the life cycle. For each baseline, this definition includes: Event that creates the baseline Items controlled Procedures for establishing & changing the baseline Authority required to approve changes to the baseline Acquisition One critical aspect for control of work products is the proper timing for when they enter into configuration management. [SPMN-98] Creation or Update of a Work Product Developer controls changes to work product Quality Gate Acquisition: Work Product Placed Under CM Formal change authority controls changes to work product

Assigning Unique Identifiers SCM provides a way to uniquely identify each: Revision, version & release Document Software component (source code module, data) Baseline NQA-1a: Requirements 3 - Design Control 802.1 Identification (cont.): A labeling system for configuration items shall be implemented that: a) uniquely identifies each configuration item; b) identifies changes to configuration items by revision; and c) provides the ability to uniquely identify each configuration of the revised software available for use. ISO 13485-2003: 7.5.3.1 Identification The organization shall identify the product by suitable means throughout product realization and shall establish documented procedures for such product identification. Control Requirements NQA-1a: Requirements 3 - Design Control 802.2 Control: Changes to software shall be formally documented. The documentation shall include: a) a description of the change; b) the rationale for the change; and c) the identification of affected software baselines. The change shall be formally evaluated and approved by the organization responsible for the original design, unless an alternate organization has been given the authority to approve the changes. Only authorized changes shall be made to software baselines. Appropriate verification activities shall be performed for the change. The change shall be appropriately reflected in documentation and traceability of the change to the software design requirement shall be maintained. Appropriate acceptance testing shall be performed for the change. NQA-1a: Subpart 2.7 Quality Assurance Requirements for Computer Software for Nuclear Facility Applications 203 Software Management (cont.): The software configuration change control control process shall include: 1. initiation, evaluation, and disposition of a change request 2. control and approval of changes prior to implementation; and 3. requirements for retesting and acceptance of the test results

Control Requirements ISO 13485-2003: 7.3.7 Control of design and development changes Design and development changes shall be identified and records maintained. The changes shall be reviewed, verified, and validated, as appropriate, and approved before implementation. The review of design and development changes shall include evaluation of the effect of the changes on constituent parts and product already delivered. AS9100C: 7.1.3 Management The organization shall establish, implement and maintain a configuration management process that includes, as appropriate to the product c) change control AS9100C: 7.3.7 Control of Design and Development Changes Design and development changes shall be controlled in accordance with the configuration management process. AS9100C: 7.6 Control of Monitoring and Measuring Equipment NOTE: Confirmation of the ability of computer software to satisfy the intended application would typically include its verification and configuration management to maintain its suitability for use. What is Control? The systematic process that ensures that changes to a baseline are: Properly identified Documented Evaluated for impact Approved by an appropriate level of authority Incorporated Verified

Control The configuration control process must answer these questions: When is control initiated? By what means is an entity placed under control? What is the control process? Levels of control each work product passes through Change authority at each levell Procedure for obtaining authorization for changes Procedure for implementing & verifying change Controlled Software Artifacts Uncontrolled Software Artifacts Controlled Software Artifacts Items Quality Records Change Control Document Control Control of Quality Records Control

Control Procedures control procedures include: Mechanisms for requesting & documenting changes to controlled work products Requirements for performing impact analysis for each requested change Mechanisms for informing affected stakeholders of the change request & soliciting their input to impact analysis An authority exists for making decisions on accepting or rejecting change request Control Procedures (cont.) Mechanisms for informing affected stakeholders of the decision to accept or reject the change & for obtaining their commitment to the change if it is accepted Mechanisms for tracking requested changes from submission through final disposition (rejection or completion of the change) Mechanism for verifying the change

Assign Author Change Control Process Communicate Reasons for Disapproval Create/ Change Item Fix/ Change No Problem/ Enhancement Identified? Yes Approve Change Disapprove Change CCB Decision? Defer Wait Verification Private Defects Internal Use Issue Change Request No Acquisition: Baselined for internal use Problem/ Enhancement Identified? Yes Release: Baselined for external use Operations Document Control Process Initial Development of Item Rework Verify Item Acquisition: Baselined for use No Problem/ Enhancement Identified? Yes Rework Create Updated Draft Item Verify Updated Draft Item Rework Delete Draft & Communicate Reasons for Disapproval Disapproved Private Changes Release: Baselined for external use Internal Use No Private Changes Approved CCB Decision? Defer Wait Being Used? Internally In Operations Problem/ Enhancement Identified? Operations Yes Baseline updated configuration items Remove Prior Version of Item from Use or Mark Obsolete

Control Board (CCB) A Control Board (CCB) is beneficial because it: Provides authority Ensures change authorization before implementation Provides visibility in change control process Provides a vehicle for impact analysis Facilitates t resource allocation Plays an integral role in keeping the software development process under control Multiple Levels of CCBs - Examples Different levels of CCBs can be used to balance between the need for control & the need to streamline the change process. Examples include: System/product level CCB controls changes to the functional baseline & product baseline Subsystem level CCBs control changes to the allocated baselines Software development level CCBs control changes to the developmental baselines

Multiple Levels of CCBs Code Example Change Authority Product Level CCB Release product that includes code Project Level CCB Promote code to system test Software Development Level CCB Promote code to integration test Team Level CCB Acquire code for baseline Developer Create code or make authorized changes Multiple Levels of CCBs SRS Example Software Requirements Specification (SRS) example: Change Authority Product Level CCB Release product that includes software defined by that SRS Project Level CCB Acquire SRS for baseline Software Analysis Create SRS or make authorized changes

CCB Membership - Examples Customers/users Systems engineering Hardware development manager Documentation / technical publications Software development manager SQA SCM V&V Software analysts Software architecture/designer Software engineers Software level CCB Team level CCB Product level CCB Project level CCB Impact Analysis Checklist Items to consider include: Size & complexity of the change Severity of the change Schedule impacts Cost impacts Effort impacts Technical impacts Relationships to other changes Testing requirements Benefits of the change

Backward Traceability & Impact Analysis Requirements Requirement R1302 Design Design Element A Source Code Unit ABC ISO 13485-2003: 7.5.3.2 Traceability (7.5.3.2.1 General) The organization shall establish documented procedures for traceability. Such procedures shall define the extent of product traceability and the records required. Where traceability is a requirement, the organization shall control and record the unique identification of the product. NOTE management is a means by which identification and traceability can be maintained. AS9100C: 7.5.3 Identification and Traceability NOTE In some industry sectors, configuration management is a means by which identification and traceability are maintained Forward Traceability & Impact Analysis Requirements Design Source Code Unit Test Cases Design Element A Unit ABC Unit DEF Unit TC A1 Unit TC B1 Design Element X Unit GHI Unit TC D1 Requirement R1302 Design Element Y Unit Y01 Unit Y02 Training Materials Training Doc 1 System Test Cases Sys TC 392 Sys TC 393 Training Doc 2 User Documentation User Doc 1

Status Accounting Requirements NQA-1a: Requirements 3 - Design Control 802.3 Status Control: The status of configuration items resulting from software design shall be maintained current. item changes shall be controlled until they are incorporated into the approved product baseline. The controls shall include a process for maintaining the status of changes that are proposed and approved, but not implemented. The controls shall also provide for notification of this information to affected organizations. ISO 13485-2003: 7.3.7 Control of design and development changes Records of the results of the review of changes and any necessary actions shall be maintained. AS9100C: 7.1.3 Management The organization shall establish, implement and maintain a configuration management process that includes, as appropriate to the product d) configuration status accounting Status Accounting The configuration status tracking system should keep track of: Product description records Status of each controlled software component Contents & status of each build/release Contents of each baseline verification records Change status records (defects & enhancements) Installation status of all configuration items at all locations [SPMN-98]

Item Dependencies Test Cases, Procedures & Scripts Tested With Items, Components & Units Target Platforms & Environments Described By Built Into Runs On Specifications Built Using Software Builds Supported By Tools, Macros, Libraries & Platform User Documentation Functional Audits Audits conducted to verify that: The development of a configuration item has been completed satisfactorily The item has achieved the performance & functional characteristics specified Its operational & support documents are complete & satisfactory AS9100C: 7.1.3 Management The organization shall establish, implement and maintain a configuration management process that includes, as appropriate to the product e) configuration audit [ISO/IEC 24765]

Conducting a Functional Audit The functional configuration audit includes: An audit of the formal test documentation against test data An audit of the verification & validation reports A review of all approved changes A review of updates to previously delivered documents A sampling of design review outputs A comparison of code with documented requirements A review to ensure all testing was accomplished The FCA may include additional sample testing. [Kasse-00] Physical Audits Audits conducted to verify that: A configuration item, as built, conforms to the technical documentation that defines it All items identified as being part of the configuration are present in the product baseline The correct version & revision of each part are included in the product baseline They correspond to information contained in the They correspond to information contained in the baseline s configuration status report

Conducting a Physical Audit The physical configuration audit includes: An audit of the system specification for completeness An audit of the FCA report for discrepancies & actions taken A comparison of the architectural design with the detailed design components for consistency A review of the module listing for compliance with approved coding standards d An audit of the manuals for format completeness & conformance to systems & functional descriptions [Kasse-00] Questions?

Contact Information Linda Westfall 3000 Custer Road Suite 270, PMB 101 Plano, TX 75075-4499 phone: (972) 867-1172 fax: (972) 943-1484 email: lwestfall@westfallteam.com www.westfallteam.com