Software Quality Assurance SOPs for Healthcare Manufacturers, Second Edition

Software Quality Assurance SOPs for Healthcare Manufacturers Second Edition Steven R. Mallory Interpharm /CRC Boca Rat...

Author: Steven R. Mallory

29 downloads 787 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Software Quality Assurance SOPs for Healthcare Manufacturers Second Edition

Steven R. Mallory

Interpharm /CRC Boca Raton London New York Washington, D.C.

Software Quality Assurance SOPs for Healthcare Manufacturers Second Edition

Steven R. Mallory

Interpharm /CRC Boca Raton London New York Washington, D.C.

Library of Congress Cataloging-in-Publication Data Mallory, Steven R. Software quality assurance SOPs for healthcare manufacturers / Steven R. Mallory.—2nd ed. p. ; cm. Companion v. to: Software development and quality assurance for the healthcare manufacturing industries. Includes index. ISBN 1-57491-135-X 1. Medical instruments and apparatus—Data processing—Quality control. 2. Pharmaceutical industry— Data processing—Quality control. 3. Computer software—Quality control. [DNLM: 1. Software—standards. 2. Quality Control. 3. Software Design. 4. Software Validation. W 26.55.S6 M255sa 2002] I. Mallory, Steven R. Software development and quality assurance for the healthcare manufacturing industries. II. Title. R856.6 .M35 2002 681¢.761¢0285—dc21 2002004293

This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the authors and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. Neither this book nor any part may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, microfilming, and recording, or by any information storage or retrieval system, without prior permission in writing from the publisher. The consent of CRC Press LLC does not extend to copying for general distribution, for promotion, for creating new works, or for resale. Specific permission must be obtained in writing from CRC Press LLC for such copying. Direct all inquiries to CRC Press LLC, 2000 N.W. Corporate Blvd., Boca Raton, Florida 33431. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation, without intent to infringe.

Visit the CRC Press Web site at www.crcpress.com © 2002 by CRC Press LLC Interpharm is an imprint of CRC Press LLC No claim to original U.S. Government works International Standard Book Number 1-57491-135-X Library of Congress Card Number 2002004293 Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 Printed on acid-free paper

CONTENTS

Dedication

vii

Preface

ix

Preface to the First Edition

xi

Introduction

xiii

Introduction to the First Edition

xv

The Software Quality Assurance Program: Methodology and Process Documents SE-CMG

Software Engineering Configuration Management Guidelines

1

SE-CMP

Software Engineering Configuration Management Policies

23

SE-DCP

Software Engineering Design Control Policies

53

SE-SDG

Software Engineering Software Development Guidelines

61

SE-SDP

Software Engineering Software Development Policies

103

SE-SMG

Software Engineering Software Metrics Guidelines

155

SE-PCMP

Software Engineering Project Control and Management Policies

169

SE-PDP

Software Engineering Project Directory Policies

189

SE-VVG

Software Engineering Verification and Validation Guidelines

201

SE-VVP

Software Engineering Verification and Validation Policies

245

The Software Quality Assurance Program: Software Project Planning Documents SCMP

Software Configuration Management Plan

293

SDP

Software Development Plan (without SCMP and SQAP)

317

Software Development Plan (with SCMP and SQAP)

353

Software Development Test Plan

397

SDTP

iii

iv

Contents

SEAP

Software End-product Acceptance Plan

423

SQAP

Software Quality Assurance Plan

435

SVTP

Software Validation Test Plan

451

SVVP

Software Verification and Validation Plan

483

The Software Quality Assurance Program: Software Requirements and Design Documents IDS

Interface Design Specification

523

RTM

Requirements Traceability Matrix

537

SADS

Software Architecture Design Specification

539

SDDS

Software Detailed Design Specification

551

SRS

Software Requirements Specification (without RTM)

571

Software Requirements Specification (with RTM)

593

The Software Quality Assurance Program: Software Hazards and Safety Documents SFMEA

Software Failure Modes and Effects Analysis

615

SFMECA

Software Failure Modes Effects Criticality Analysis

617

The Software Quality Assurance Program: Software Testing and Verification and Validation Documents SAR

Software Anomaly Report

626

DTIS

Development Test Information Sheet

629

VTIS

Validation Test Information Sheet

630

SVTL

Software Validation Test Log

631

SVTPR

Software Validation Test Procedures

633

SVVR

Software Verification and Validation Report

647

The Software Quality Assurance Program: Software Configuration Management Documents CRA

Change Request/Approval (CRA) Form

651

SCAR

Software Configuration Audit Report

653

SCSR

Software Configuration Status Report

655

The Software Quality Assurance Program: Software Process Improvement Document STRC

[Project/Product Name] Software Team Report Card

657

v

DEDICATION

This book is dedicated to all of the healthcare industry software engineers, companies, and corporations and to the software professional societies that helped to provide the inspiration that an integrated whole could be created.

vii

PREFACE

I am very grateful for and flattered by the favorable reception of this work. In this second edition, I have made a large number of refinements and have included new material. A casual reader will notice little difference between this edition and the previous except for the organization of the material. Most of the document templates are fundamentally the same as in the previous edition, but they have been updated and brought in line with the Software Development and Quality Assurance for the Healthcare Manufacturing Industries text. In addition, at the request of some readers, several new templates have been included. I thank all of you who told me that the information could be better organized and could provide a more centralized approach for reference. I hope that this new organization satisfies your requirements. Steven R. Mallory December, 2001

ix

PREFACE TO THE FIRST EDITION

The difficulty with a project that encompasses a predefined and integrated approach to software engineering policies, Standard Operating Procedures (SOPs), guidelines, and project documentation is that you tend to think that it is not really needed. I have continually struggled with the notion that nearly every company already has formats in place for their software engineering policies, SOPs, and project documents; that nearly every company already has acceptable software project documentation in place; and that nearly every company already has software engineering policies, SOPs, and documents. However, since writing Software Development and Quality Assurance for the Healthcare Manufacturing Industries I have found that this is not usually the case. The intent of Software Development and Quality Assurance for the Healthcare Manufacturing Industries was to present a logical, organized, and coordinated effort at defining a software quality assurance program for healthcare manufacturers. The approach was to discuss and build a general and generic framework in basic and fundamental terms that would allow the users and readers to construct their own software quality assurance programs and outfit it with details tailored to the culture of their company. Since publication of that book, however, many individuals and client organizations have suggested that a more concrete approach to a healthcare software quality assurance program should be created, namely, the generation of a suite of example software engineering policies, SOPs, and project documents. Their recommendation was to provide a set of interrelated and interdependent policies that could be used verbatim or modified to some degree in order to reflect the particular software engineering environment within their company. In addition, they argued, examples of the software project documents based on those policies and SOPs would be valuable because the formats, content, and layouts could be used to compare and contrast with those that were already in use within their companies or used as templates by those organizations that do not have document standards. The logical conclusion of their arguments and the logical extension of my first book is, then, this book, Software Quality Assurance SOPs for Healthcare Manufacturers. It presents the concrete formalization of the software engineering policies, SOPs, and project documents of the first book in a form that is useful to software engineers and managers, regulatory affairs personnel, and anyone interested in establishing a software quality assurance program from the grassroots level. This volume presents information based on the information in Software Development and Quality Assurance for the Healthcare Manufacturing Industries and, in fact, can be considered a companion volume to that work. Steven R. Mallory March, 1997

xi

INTRODUCTION

This work represents an updated companion volume to my book Software Development and Quality Assurance for the Healthcare Manufacturing Industries and presents examples of software engineering policies, Standard Operating Procedures (SOPs), and project documents discussed in broad terms in that book. The reader is cautioned against interpreting the word “examples” too narrowly; the software policies, SOPs, and project documents presented here are usable as software quality assurance documentation. For example, my book provided guidance on the form, content, and intent of software development policies and left the details to the reader; this book presents a usable software development policy document. In addition, it presents usable documentation examples that directly support the specifics of the software development policy. The emphasis of this work is on the same concrete, formal, useful, and practical approach to software quality assurance policies, SOPs, and project documentation presented in Software Development and Quality Assurance for the Healthcare Manufacturing Industries. The intent is to provide users with “fill-in-the-blank” or “search-and-replace” templates for software engineering policies, SOPs, and project documents. This work can provide not only guidance for generating documents and the content of those documents but also templates that can be used to establish the documentation for a software quality assurance program for healthcare manufacturers. Readers can use the policies and guidelines as presented, modify them for use within their organizations, or use them to compare and contrast with any existing software engineering policies and SOPs within their organizations. They can also use the project documentation examples as presented or, again, modify them for use within their organizations. The content of the software project documentation as presented here satisfies the software policies and SOPs that are also presented within this volume. For the interpretation of how to convert specific information within the square brackets of these examples, please see the Introduction to the first edition, below.

xiii

INTRODUCTION TO THE FIRST EDITION

This work represents a companion volume to my book Software Development and Quality Assurance for the Healthcare Manufacturing Industries and presents examples of software engineering policies, SOPs, and project documents discussed in broad terms in that book. The reader is cautioned against interpreting the word “examples” too narrowly; the software policies, SOPs, and project documents presented here are usable as software quality assurance documentation. For example, my earlier book provided guidance on the form, content, and intent of software development policies and left the details to the reader; this book presents a usable software development policy document. In addition, it presents usable documentation examples that directly support the specifics of the software development policy. The emphasis is on the same concrete, formal, useful, and practical approach to software quality assurance policies, SOPs, and project documentation presented in Software Development and Quality Assurance for the Healthcare Manufacturing Industries. The intent, then, is to provide users with “fill-in-the-blank” or “search-and-replace” templates for software engineering policies, SOPs, and project documents. The hope is that the reader will understand that this work can provide not only guidance but templates that can be used to establish the documentation for a software quality assurance program for healthcare manufacturers. Readers can use the policies and guidelines as presented, modify them for use within their organizations, or use them to compare and contrast with any existing software engineering policies and SOPs within their organizations. Furthermore, they can also use the project documentation examples as presented or, again, modify them for use within their organizations. I stress that the content of the software project documentation as presented here satisfies the software policies and SOPs that are also presented in this volume. A few words about the general formats of the information found here are in order. Each document in this work should be viewed as if it could stand alone as a complete, signed-off, and released document. Consequently, document cover pages contain the rudimentary details required to make the entire document usable within any document control system. For example, each document requires signatures from the document’s writer, reviewer, and approver, as well as inclusion of their printed names and titles or positions. This information is indicated within the square brackets, (i.e., [Name/Title/Position]). For the policy documents found here, a second approval signature is shown as required, and this is the location where the appropriate officer would sign for approval if necessary. Below the signature area is the document configuration identification area where the document identification, revision, and pagination counts are found. Users may want to edit this so that it appears at the foot of every page in the document. Below the document identification area is the revision history of the document; users may want to edit this information so that it appears as the second, stand-alone page of the document.

xv

xvi

Introduction to the First Edition

In general, information appearing within square brackets on any page of the enclosed documentation is expected to be provided by users or to be tailored in order to comply with any existing documentation formats within their organizations. As a further example, suppose that the software project document templates shown here are to be used on the “New Generation Model” project. A global search and replace of the character string “[project/product name]” with “New Generation Model” will convert these documents from generic templates into specific project-related documents. In some instances, specific character strings may require more thought in order to convert them into their real-life equivalents. For example, the string “[project title/position]” appears in project-related documents and might refer to a project leader, software development leader, or software verification and validation leader, depending on the context of the discussion in which the string appears. The strings “[title/position]” or “[corporate title/position]” might refer to a software manager, a software quality assurance manager, or an appropriate vice president within the organization, depending on their context. Some discretion is required when the generic square brackets and their contents are replaced with the correct substitutions. On the technical side, the same ground rules apply. For example, a software project document may indicate where additional task description sections are required. Users can then include the additional information in the outline provided within the document. However, if no additional information is required, users may delete any unused or unnecessary sections. In fact, if a document contains information that is not applicable to the project or product, it is reasonable to expect that users would eliminate unnecessary sections or information. Furthermore, it would be expected that the user would include any necessary, pertinent, and additional information that is not readily apparent in the included document templates, either in an existing section or by creating entirely new headings and sections. The contents of this book are meant to form the basis of a software quality assurance program. The software policies and SOPs were written in such a way as to be meaningful in a regulatory environment and to convey the activities, tasks, responsibilities, and deliverables of good software engineering practices. The software documents here were written in such a way as to fully support and comply with the software policies and SOPs presented here. The software quality assurance documents can be used verbatim as fill-in-the-blank templates or as modifiable and customized templates, where no such software quality assurance documentation exists, or as a set of standards that can be used to compare and contrast existing software quality assurance documentation.

SE-CMG SOFTWARE ENGINEERING CONFIGURATION MANAGEMENT GUIDELINES

Written by:

[Name/Title/Position]

Date

Reviewed by:


Date

Approved by:


Date

Document Number [aaa]-SECMG-[#.#]

Revision

Page

[#.#]

1 of [#]

REVISION HISTORY Revision

Description

Date

[##.##]

[Revision description]

[mm/dd/yy]

Copyright © 2002 Interpharm Press

Page 1 of 22 SE-CMG

2

Software Quality Assurance SOPs for Healthcare Manufacturers

CONTENTS

1.0

INTRODUCTION

3

2.0

SOFTWARE REPORTING PRACTICES

4

3.0

PROJECT DIRECTORY DEFINITION

6

4.0

CONFIGURATION MANAGEMENT RESPONSIBILITIES

7

APPENDIX A-1


16

APPENDIX A-2

Instructions for Completing Software Anomaly Report

17

Software Configuration Management Process Record of Deviation or Waiver Approval

18

APPENDIX C

Project Directory Structure

19

APPENDIX D

Matrix for Configuration Management Script Execution

20

APPENDIX B

GLOSSARY

Page 2 of 22 SE-CMG

21



3

1.0 INTRODUCTION

1.1 Purpose This document has been developed to define consistent methods, standards, conventions, practices, and styles for software configuration management.

1.2 Scope The guidelines in this document are to be used to promote consistency in the configuration management of all software. The identified software configuration manager will use this guide to establish common practices for software configuration management.

1.3 Overview This document covers the creation of project directories, standard configuration management scripts, and the reporting of discrepancies from documented processes.

1.4 References •

Product Development Safety Design Guidelines, Revision [#.#], dated [date]

•

Product Development User Interface Design Guidelines, Revision [#.#], dated [date]

•

Software Engineering Development Guidelines, Revision [#.#], dated [date]

•

Software Engineering Configuration Management Policies, Revision [#.#], dated [date]

•

Software Engineering Software Development Policies, Revision [#.#], dated [date]

•

Software Engineering Verification and Validation Guidelines, Revision [#.#], dated [date]

•

Software Engineering Verification and Validation Policies, Revision [#.#], dated [date]


Page 3 of 22 SE-CMG

4


2.0 SOFTWARE REPORTING PRACTICES

2.1 Bug, Error, and Anomaly Reporting The reporting and documenting of software configuration discrepancies is accomplished through the use of the Software Anomaly Report.

2.1.1


Problem reporting is initiated by the project configuration manager with a Software Anomaly Report, which identifies problems detected during software development activities. The specific information required on an anomaly report identifies how, when, and where the problem occurred and the impact of the problem on the system capability and on the continued conduct of verification and validation (V&V) phase activities. Appendix A shows an example of the anomaly report and instructions for completing the report.

2.1.2

Anomaly Reporting and Resolution

The software configuration manager is responsible for ensuring the proper documentation and reporting of Software Anomaly Reports, and all anomalies are reported regardless of the perceived impact on software development or severity level with respect to the system operation. Unreported and unresolved problems can have a significant adverse impact in the later stages of the software development cycle, which may include little time for resolution. The projected impact of an anomaly is determined by evaluating the severity of its effect on the operation of the system. The severity of an anomaly report is defined as one of the following: •

High. The change is required to correct a condition that prevents or seriously degrades a system objective and no alternative exists, or to correct a safety-related problem.

•

Medium. The change is required to correct a condition that degrades a system objective, to provide for performance improvement, or to confirm that the user and system requirements can be met.

•

Low. The change is desirable to maintain the system, correct operator inconvenience, or other.

Resolution of the critical anomaly indicated as a severity of “high” is required before the development effort proceeds to the next software development phase.

Page 4 of 22 SE-CMG



5

Software Anomaly Reports are reviewed by the software lead engineer of the project for anomaly validity, type, and severity, and the software lead engineer can direct additional investigation, if required, to assess the validity of the anomaly or the proposed solution. When an anomaly solution is approved and the personnel responsible for performing the corrective action are indicated, the software lead engineer will authorize implementation of the corrective action. The software V&V lead engineer is responsible for anomaly report closure, which includes documenting that corrective action has been taken and verifying the incorporation of authorized changes as described in the anomaly report. If the anomaly requires a change to a baselined configuration item, a Change Request/Approval (CRA) is prepared by a member of the software development team for the item(s) to be changed. A reference to applicable anomaly reports will be documented in the issued CRA.

2.2 Configuration Management Deviation or Waiver Circumstances may require deviation(s) or waiver(s) from policy. A written request for a deviation is generated by the project configuration manager in advance of a future activity, event, or product in order that software engineering (SE) management be made aware of the project personnel’s intention to employ a higher risk development approach. A written request for a waiver is generated by the project configuration manager in those cases where the activity, event, or product has already been initiated. The deviations or waivers are submitted to the cognizant [project title/position] for review, and a recommendation will be made to the [title/position] and/or [title/position] for approval or disapproval of the proposed deviation or waiver. A proposed deviation or waiver must be approved by the [title/position] and/or [title/position] before commencing the software development tasks affected by that deviation or waiver. A copy of each approved deviation or waiver shall be forwarded to the secretary of the Software Configuration Management Policy Change Control Board (CCB). A copy shall also be placed in the product history file. A permanent record of deviation and waiver approvals shall be maintained for each project using the form depicted in Appendix B. Each request for a deviation or waiver identifies the following: •

Each specific policy or policy requirement for which it applies

•

Alternative policy approach to be taken by the project

•

Impact on project schedule, performance, and/or risk

This record shall be initiated during development of the product objectives documentation and shall serve as a record of all subject approvals for the duration of the project.


Page 5 of 22 SE-CMG

6


3.0 PROJECT DIRECTORY DEFINITION All projects are controlled electronically, and a standard directory structure is defined for uniformity and consistency.When a new project is begun, the directory structure and environment are defined using configuration management (CM) scripts. Appendix C defines the project and software repository library directory structures.

3.1 Project Directory Scripts The software CM scripts are stored in the configuration management directory at [enter directory path here]. Each member of the new <project_name> group must have the path to these scripts in [enter file names that must define the CM directory path names]. It is the responsibility of each <project_name> member to ensure that they modify their files to accomplish this.

3.2 Project Directory Source Repository The repository where the project’s source data and information products are stored is under a directory called <project_name>, and ownership is given to login_name pdcm. The availability of disk space and the location of the project directory structure is determined by the system administrator and the configuration manager. The project name should be no more than six characters in length. It is the responsibility of the configuration manager to ensure that this task is done.

3.3 Project User and Group Identification Access to the stored source information, data, and code for a project is limited to the users of a specific group. Files are stored and accessed by means of standard operating system user and group IDs.Write access will be denied to any user not in the specific group.The system administrator will set up <project> and <project>_vnv as project groups for any project adding login_name pdcm to any group. In addition to the above two project groups, the global groups, integ and vnv, reside in the group file. All software integrators on each active project are members of the integ group. The scripts to be run by the project integrator are group owned by integ in order to make execution of the scripts possible by all integrators.

Page 6 of 22 SE-CMG



7

All members of the project’s <project>_vnv group are placed in the vnv group. The scripts to be run by members of any <project>_vnv group are group owned by V&V personnel in order to make execution of the scripts possible by all project V&V members. It is the responsibility of the configuration manager to ensure that these groups are set up.

4.0 CONFIGURATION MANAGEMENT RESPONSIBILITIES

4.1 Integrator Responsibilities The CM scripts depend upon the project integrator performing the following tasks for the duration of the project. •

<project>/se/project_utilities/data/directory_list.def contains an entry for each physically executable software task added under the / . . . /se/project_code directory.

•

The correct directory structure is created and maintained under the <project>/se/project_utilities directory. Because this directory contains only directories, it is just one level deep. The contents of the project_utilities/data directory must be put under software configuration control and contains all files associated with the MAKE process. Software configuration control is optional for all other directories under project_utilities.

•

After the new project directory structure has been created, the MAKE files must be added from the project_utilities/data directory to the source directory of each task under the project_code directory. These files must also be checked in under the software configuration control directory in the project_code/task/source directory.

•

Initially, check files under the <project>/se/project_include directory into a software configuration control directory.

•

Before a baseline is requested, the project_code, project_include, and project_ utilities/data directories must be placed under software configuration control and have been checked in by the integrator through the script “integ_in.”


Page 7 of 22 SE-CMG

8


4.2 Configuration Management Scripts The following sections describe the CM scripts in terms of their function, the phase of the project that they apply to, the area of the project directories that is affected, who should run the script, and the tasks that the script accomplishes.

4.2.1

Script “new_project”

Script “new_project” is the first of the CM scripts to be run. This script, run only one time per project by login_name pdcm, accomplishes the following tasks: •

Creates an empty project directory structure

•

Builds the user_tool_info directories

•

Copies the data directory from the software library to the project data directory and places them under software configuration control

•

Copies the necessary tool files from the software library to the project tool directories

•

Creates any MAKESYS for the project

•

Sets ownership of the project directory

4.2.2

Script “new_frame”

Script “new_frame” runs within the development directories only, is initiated by the project integrator, and must be run from the destination location in /se. The purpose of this script is to initially check in an existing file to the local software configuration control directory. It accomplishes the following tasks: •

Checks the corresponding directory in /build for a file of the same name

•

If the duplicate exists, informs the user and exits

•

If a duplicate file does not exist in /build, the script then checks the file into the local software configuration control directory and sets the user table to allow access by all members of the project group

Page 8 of 22 SE-CMG



4.2.3

9

Script “integ_out”

Script “integ_out” is run within the development directories only, is initiated by the project integrator, and must be run from the destination location in /se. The purpose of this script is to check a file out of software configuration control with the default of a file tagged with the user ID. The option for an untagged file is -t, and the option to change the tag from the user ID is -n. This script accomplishes the following tasks: •

Checks the current directory in /se for the presence of the requested file

•

If it exists in /se and is not checked out, then checks it out as tagged or untagged, as requested

•

If the requested file does not exist in /se, then examines the corresponding directory in /build, informs the user that the file does not exist in /build, and exits or copies the file from /build to /se

•

Checks the file copied from /build into the /se local software configuration control directory

•

Clears the software configuration control user table

•

Sets the contents of the user table to the project group

•

Software configuration control edits a tagged or an untagged file from the local /se software configuration control directory as requested

4.2.4

Script “integ_in”

Script “integ_in” is run within the development area only by the project integrator and must be run from the destination location in /se. The purpose of this script is to check a file into the software configuration control, clearing the user table, and then opening access of the file to the entire project group. The read only copy of the file resides at the software configuration control directory level and reflects the file checked in by “integ_in.” Script “integ_in” should be the last script run on an /se source file before a baseline is requested.

4.2.5

Script “check_out”

Script “check_out” is run within the development area only by members of the project group and must be run from the destination location in /se. The purpose of this script is to check out a tagged file to the requestor, and it accomplishes the following tasks:


Page 9 of 22 SE-CMG

10


•

Checks the current directory for the presence of the requested file, and if it exists but is not checked out, then checks it out as tagged, or reports that the file is checked in but inaccessible. This would be true if the file had been checked in by a developer and was now locked to that developer and/or the integrator. In either case, exits. If the file exists but is checked out, the script reports this and exits.

•

If the requested file does not exist in /se, goes to the same location in /build. If the file does not exist in /build, then reports this and exits. If the file does exist in /build, then copies the file from /build to /se, checks the file into the local /se software configuration control directory with a user table containing the entire project group, and software configuration control edits a tagged file from the local software configuration control directory.

4.2.6

Script “check_in”

Script “check_in” is run within the development area only by any member of the project group and must be run from the destination location in /se. The purpose of this script is to allow developers to check in a file yet retain exclusive access to the file until it is released to the integrator. The read-only copy of the file resides at the software configuration control directory level and does not reflect the file checked in by “check_in.”The user table is then set to include the individual developer and the integrator group.

4.2.7

Script “prebase_check”

Script “prebase_check” is run by login_name pdcm before each baseline requested by the project and checks that each file under /project_utilities, /project_include, and /project_code is checked in to its software configuration control directory. The output of this script is directed to /pdcm/check.file. Any file shown to be checked out by this script must be resolved with the project integrator before the next script is run.

4.2.8

Script “prebase_diff”

Script “prebase_diff” is run by login_name pdcm after script “prebase_check” has been resolved, and it determines software configuration control differences on each file under /project_utilities, /project_include and /project_code. A difference between the source file and the software configuration control file other than expected variances indicates that the file has not been integrated. The output of this script is directed to /pdcm/diff.file and any differences reported by the script must be resolved with the project integrator before the next script is run.

Page 10 of 22 SE-CMG



4.2.9

11

Script “prebase_get”

Script “prebase_get” is run by login_name pdcm after script “prebase_diff” has been resolved. This script performs a software configuration control get -k on each file under /project_utilities, /project_include and /project_code to ensure that the source files being copied to /baseline contain appropriate software configuration control information.

4.2.10 Script “se_2_baseline” Script “se_2_baseline” is run by login_name pdcm for each baseline required by the project. This script assumes that the three prebaseline scripts above have been run successfully. Script “se_2_baseline” accomplishes the following tasks: •

Copies /project_code, /project_include, and /project_utilities from <project>/se to <project>/baseline, makes a directory named /project_libraries, and makes a directory named project_list

•

Uses directory_list.def in directory <project>/baseline/project_utilities/data, deletes each software configuration control directory under <project>/baseline/ project_code//source and <project>/baseline/project_code/ /include

•

Removes the contents of /baseline/project_code//object and generates a log list

•

Deletes the software configuration control directory under <project>/baseline/ project_include

•

Deletes the software configuration control directory under each <project>/baseline/project_utilities directory

•

Invokes script “s_se_2_baseline.chper1” and “s_se_2_baseline.chper2” to change group ownership of the /baseline directory from <project> to <project>_vnv

4.2.11 Script “ids_build” Script “ids_build” is run by login_name pdcm at the request of the project leader and copies the Interface Design Specification (IDS) document from /se/project_documents/specifications/ design/ids to directory /build/project_documents/specifications/design/ids.



12


4.2.12 Script “srs_build” Script “srs_build” is run by login_name pdcm at the request of the project leader and accomplishes the following tasks: •

Copies /se/analysis to /build/analysis

•

Copies /se/stp_configuration to /build/stp_configuration, and modifies “projdir” path in /build/ToolInfo.project from /se to /build

•

Copies the project SRS from /se/project_documents/specifications/design/srs to /build/project_documents/specifications/design/srs

4.2.13 Script “ads_build” Script “ads_build” is run by login_name pdcm at the request of the project leader and accomplishes the following tasks: •

Copies /se/analysis to /build/analysis

•

Copies /se/stp_configuration to /build/stp_configuration and modifies “projdir” path in /build/ToolInfo.project from /se to /build

•

Copies the Software Architecture Design Specification (SADS) from /se/project_ documents/specifications/design/sads to /build/project_documents/ specifications/design/sads

4.2.14 Script “dds_build” Script “dds_build” is run by login_name pdcm at the request of the project leader and accomplishes the following tasks: •

Copies /se/detail_design to /build/detail_design

•

Copies /se/stp_configuration to /build/stp_configuration and modifies “projdir” path in /build/ToolInfo.project from /se to /build

•

Copies the Software Detailed Design Specification (SDDS) from /se/project_documents/ specifications/design/dds to /build/project_documents/specifications/design/dds




13

4.2.15 Script “code_build” Script “code_build” is run by login_name pdcm at the request of the project leader and accomplishes the following tasks: •

Removes contents of /build/project_libraries and /build/project_list if they exist, or makes these directories if they do not

•

Copies /project_utilities from /baseline to /build, adds a software configuration control directory for data under /project_utilities if this is the first code build, and places the contents of /build/project_utilities/data under software configuration control

•

Adds /project_code tasks added since previous build using new directory_list.def in /build/project_utilities/data or all tasks listed in directory_list.def, if this is the first code build

•

Copies /baseline/project_include to /build/project_include, and places /build/project_include under software configuration control

•

Copies /baseline/project_code//source and /include to /build, then places the contents of /build/project_code//source and /include under software configuration control, removes /build/project_code//object, and generates a log listing

•

Deletes /se/project_code

•

Deletes /se/project_include

•

Deletes /se/project_libraries

•

Deletes /se/project_list

•

Reconstructs the /se project_code directory structure

•

Checks out a copy of all source and include files in /build as project leader

•

Checks out a copy of all files in /build/project_utilities/data as project leader

4.2.16 Script “final_build” Script “final_build” is run by login_name pdcm at the request of the project leader. This is the last script to be run for a project and should be run only once prior to final V&V and transfer of the build to document control. This script accomplishes the following tasks:



14


•

Removes contents of /build/project_libraries and /build/project_list if they exist, or make these directories if they do not

•

Copies /project_utilities from /baseline to /build, adds a software configuration control directory for data under /project_utilities if this is the first code build, and places the contents of /build/project_utilities/data under software configuration control

•

Adds /project_code tasks added since previous build using directory_list.def in /build/ project_utilities/data or all tasks listed in directory_list.def if this is the first code build

•

Copies /baseline/project_include to /build/project_include and places /build/project_include under software configuration control

•

Copies /baseline/project_code//source and /include to /build, places contents of /build/project_code//source and /include under software configuration control, removes /build/project_code//object, and generates a log listing

•

Copies /se/project_database to /build

•

Copies /se/project_documents to /build

•

Copies /se/project_purchased_code to /build

•

Copies /se/stp_configuration to /build

•

Copies /se/analysis to /build

•

Copies /se/detail_design to /build

•

Deletes /se/project_code

•

Deletes /se/project_include

•

Deletes /se/project_libraries

•

Deletes /se/project_list

4.2.17 Script “vnv_out” Script “vnv_out” is run within the /build area by members of the <project>_vnv group and must be run from the destination location in /build.The purpose of this script is to allow mem-




15

bers of the <project>_vnv group to make a writable tagged copy of a source file in the /build area. The tagged copy is the result of a copy command and not an actual software configuration control edit. Any number of uniquely tagged source files can be created, and the tag used will be the requester’s user ID.

4.2.18 Script “vnv_del” Script “vnv_del” is run within the /build area by members of the <project>_vnv group and must be run from the destination location in /build. The purpose of this script is to delete a tagged version of a source file copied by script “vnv_out.”

4.2.19 Script “update_usertable” Script “update_usertable” is run within the /se area by the project integrator. The purpose of this script is to update the software configuration control user table of all /project_include and /project_code/source and /include files with the user ID of any new project members not in the original group file. If the source file is not checked out and is either a new frame or has been integrated, its software configuration control user table will be updated.

4.2.20 Script “report” Script “report” is run by login_name pdcm after running any build script, and it sends a file to /build/project_documents/reports. This file contains a list of all /project_include, /project_code, and /project_utilities source files that make up the build, the changes of the files, and a list of configuration items in the build not under software configuration control.

4.2.21 Script “delete_baseline” Script “delete_baseline” is run by login_name pdcm after running script “first_build” or “next_build” and before running script “se_2_baseline.” This script deletes the contents of /baseline.

4.3 Script Execution Matrix Appendix D describes execute permissions for the CM scripts, and execution may be either an individual login_name or a group. The workstation that executes the scripts as login_name pdcm needs root access to the disk containing the project.



16


APPENDIX A-1

SOFTWARE ANOMALY REPORT SOFTWARE ANOMALY REPORT

1. Date:

2. Severity: HML

3. Anomaly Report

4. Title (briefly describe the problem):

5. System: 8. Originator:

6. Component: 9. Organization

12. Verification and Validation Task: 14.

System Configuration:

15.

Anomaly Description:

16.

Problem Duplication: During run Y N After restart Y N After reload Y N

10. Telephone

N/A N/A N/A

Investigation Time

19.

Proposed Solution:

20.

Corrective Action Taken: Date:

21.

Closure Sign-off:

11. Approval:

13. Reference Document(s):

17.

18.


7. Version

❑ ❑ ❑ ❑ ❑

Source of Anomaly: PHASE Requirements Architecture Design Detailed Design Implementation Undetermined

❑ ❑ ❑ ❑ ❑ ❑

TYPE Documentation Software Process Methodology Other Undetermined

Software Lead Engineer

Date

V&V Lead Engineer

Date



APPENDIX A-2

17

INSTRUCTIONS FOR COMPLETING SOFTWARE ANOMALY REPORT

1. Date: Form preparation date. 2. Severity: Circle the appropriate code. High: The change is required to correct a condition that prevents or seriously degrades a system objective (where no alternative exists) or to correct a safety-related problem. Medium: The change is required to correct a condition that degrades a system objective, to provide for performance improvement, or to confirm that the user and system requirements can be met. Low: The change is required to maintain the system, correct operator inconvenience, or other. 3. Anomaly report number: Number assigned for control purposes. 4. Title: Brief phrase or sentence describing the problem. 5. System: Name of the system or product against which the anomaly report is written. 6. Component: Component or document name against which the anomaly report is written. 7. Version: Version of the document or code against which the anomaly report is written. 8. Originator: Printed name of individual originating the anomaly report. 9. Organization: Organization of originator of anomaly report. 10. Telephone: Office phone number of the individual originating the anomaly report. 11. Approval: Software management individual or designatee approval for anomaly report distribution. 12. V&V task name: Name of the V&V task being performed when the anomaly was detected. 13. Reference document: Designation of the documents that provide the basis for determining that an anomaly exists. 14. System configuration: Configuration loaded when anomaly occurred; not applicable for documentation or logic errors. 15. Anomaly description: Description defining the anomaly and a word picture of events leading up to and coincident with the problem. Cite equipment being used, unusual configurations, environment parameters, and so forth, that will enable the programmer to duplicate the situation. If continuation sheets are required, fill in Page _ of _ at the top of the form. 16. Problem duplication: Duplication attempts, successes or failures for software errors; not applicable for documentation or logic errors. 17. Source of anomaly: On investigation completion, source of the anomaly in terms of phase origination and type. 18. Investigation time: Time, to the nearest half hour, required to determine the cause of the anomaly but not the time to determine a potential solution or time to implement the corrective action. 19. Proposed solution: Description defining in detail a solution to the detected anomaly, including documents, components and code. 20. Corrective action taken: Disposition of the anomaly report, including a description of any changes initiated as a direct result of this report and the date incorporated. 21. Closure sign-off: Signature of the software lead engineer authorizing implementation of the corrective action. Signature of the V&V lead engineer verifying incorporation of the authorized changes as described in this report. Only signature of software lead engineer is required when no corrective action is approved.



18


APPENDIX B

SOFTWARE CONFIGURATION MANAGEMENT PROCESS RECORD OF DEVIATION OR WAIVER APPROVAL

SOFTWARE CONFIGURATION MANAGEMENT PROCESS RECORD OF DEVIATION OR WAIVER APPROVAL PROJECT:

TYPE: Deviation or Waiver

PHASE: SOP Requirement Paragraph(s):

Initiated by:

________________________________ Signature

Reviewed by:

________________________________ Signature

Approved by:

________________________

Date:

________________________

Date:

________________________

Title/Position

________________________________ Signature

Date:

Title/Position

Title/Position

Reason/Rationale/Explanation:

Project schedule and performance impact:

Project risk:

Alternative approach to be used:




APPENDIX C

19

PROJECT DIRECTORY STRUCTURE



20


APPENDIX D

Script Name new_proj

MATRIX FOR CONFIGURATION MANAGEMENT SCRIPT EXECUTION Configuration Manager

V&V Personnel

Project Integrator

Project Personnel

X

new_frame

X

integ_out

X

integ_in

X

check_out

X

check_in

X

prebase_check

X

prebase_diff

X

prebase_get

X

se_2_baseline

X

ids_build

X

srs_build

X

ads_build

X

dds_build

X

code_build

X

final_build

X

vnv_out

X

vnv_del

X

update_usertable

X

X

reportX delete_baseline


X



21

GLOSSARY Anomaly: Anything observed in the documentation or operation of software that deviates from expectations based on previously verified software products or reference documents. Baseline: Specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Change control: Process by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked. Change Request/Approval (CRA): Form used to document changes to a baseline. Configuration control: Process of evaluating, approving or disapproving, and coordinating changes to configuration items after formal establishment of their configuration identification. Configuration identification: Process of designating the configuration items in a system and recording their characteristics. Configuration item: Aggregation of hardware, software, or any of its discrete parts that satisfies an end-use function. Configuration management (CM): Process of identifying and defining the configuration items in a system, controlling the release and change of these items throughout the product life cycle, recording and reporting the status of configuration items and change requests, and verifying the completeness and correctness of configuration items. Deviation: Authorization for a future activity, event, or product to depart from standard procedures. Documentation: Manuals, written procedures or policies, records, or reports that provide information concerning uses, maintenance, or validation of software. Integrity: Accuracy in an item’s compliance with its requirements. Software configuration management (SCM): Discipline of identifying the configuration of a software system at discrete points in time for the purpose of systematically controlling changes to this configuration and maintaining the integrity and traceability of this configuration throughout the development process.



22


Software development library: Software library containing computer-readable and humanreadable information relevant to a software development effort. Software library: Controlled collection of software and related documentation designed to aid in software development, use, or maintenance. Software project: Planned and authorized undertaking of specified scope and duration that results in the expenditure of resources toward the development of a product that is primarily one or more computer programs. Source code: Original software expressed in human-readable form (programming language) that must be translated into machine-readable form before it can be executed by the computer. Waiver: Authorization to depart from SE policy for an activity, event, or product that has already been initiated.



SE-CMP SOFTWARE ENGINEERING CONFIGURATION MANAGEMENT POLICIES

Written by:


Date

Reviewed by:


Date

Approved by:


Date

Approved by:


Date

Document Number [aaa]-SECMP-[#.#]

Revision

Page

[#.#]

1 of [#]


Description

Date

[##.##]


[mm/dd/yy]


Page 1 of 30 SE-CMP

24


CONTENTS

PREAMBLE

SE Software Configuration Management Policies

3

POLICY 1

Software Configuration Management Organization

7

POLICY 2

Software Configuration Identification

9

POLICY 3

Software Configuration Management of Subcontractor and Vendor Products

10

POLICY 4

Software Configuration Management Plan

12

POLICY 5

Software Configuration Change Processing

14

POLICY 6

Change Request/Approval Form

16

POLICY 7

Software Change Review Board

17

POLICY 8

Software Configuration Status Accounting

19

POLICY 9

Software Configuration Status Report

20

POLICY 10

Software Configuration Audits and Reviews

21

POLICY 11


23

GLOSSARY

Page 2 of 30 SE-CMP

26



PREAMBLE

25

SE SOFTWARE CONFIGURATION MANAGEMENT POLICIES

Policy Software engineering (SE) software projects shall comply with a set of Software Configuration Management (SCM) Policies, which are established, maintained, and used to achieve quality in all phases of the software life cycle. Justified and necessary departures from these policies may be authorized in response to a written request. A permanent board shall be established to control and maintain the SE SCM Policies.

Requirements 1. The SE SCM Policies shall be applied to all SE software projects. Projects in which effort will be expended in order to modify or enhance existing software also are subject to this requirement. 2. The SE SCM Policies shall be maintained by the Software Configuration Management Policy Change Control Board (CCB). The CCB chairman shall be appointed by the SE [title/position] with the approval of the [title/position], and board members shall be appointed in writing by the SE [title/position]. The SE [title/position] shall serve as the secretary to the CCB and shall be responsible for scheduling board meetings and maintaining minutes of meetings and permanent files of CCB actions. Proposed changes to SE SCM Policies must be submitted in writing to the board. At least once each year, the CCB shall convene to review all of the policies for relevancy and currency.Where appropriate, they shall propose revisions to the policies subject to the review and approval of the [title/position]. After approval by the SE [title/position], the policies shall be approved by the [title/position] and [title/position]. 3. Circumstances may require deviation(s) or waiver(s) from policy. A written request for a deviation shall be submitted by the project configuration manager in advance of a future activity, event, or product in order that SE management be made aware of the project’s intention to employ a higher risk approach to SCM. A written request for a waiver shall be submitted by the project configuration manager in those cases where the activity, event, or product has already been initiated. Deviations and waivers shall be reviewed by the [project title/position] and submitted to the SE [title/position] for review. The SE [title/position] will make a recommendation to the [title/position] and/or [title/position] for approval or disapproval of the proposed deviation or waiver. A proposed deviation or


Page 3 of 30 SE-CMP

26


waiver must be approved by the [title/position] and/or [title/position] before commencing the SCM tasks affected by that deviation or waiver. 4. Each request for a deviation or waiver shall identify: a. Each specific policy or policy requirement for which it applies b. The alternative policy approach to be taken by the project c. The impact on project schedule, performance, and/or risk 5. A copy of each approved deviation or waiver shall be forwarded to the secretary of the Software Configuration Management Policy CCB. A copy shall also be placed in the product history file. 6. These policies refer to and govern a set of SE SCM procedures. The procedures are intended to provide detailed guidance within the framework and requirements provided by these policies (see Figures 1 and 2). It is the responsibility of the project configuration manager to apply the existing relevant SE SCM procedures. New SE SCM procedures are to be submitted to the SE [title/position] prior to their use, in order that they can be reviewed and approved (see Figure 3).

Figure 1

SE Software Configuration Management Policies Policy Category

Configuration Identification Project Management

Product Management and Acceptance Configuration Change Control

Configuration Status Accounting

Page 4 of 30 SE-CMP

Policy Topic Title Software Configuration Identification Software Configuration Management Organization Software Configuration Management of Subcontractor and Vendor Products Software Configuration Management Plan (SCMP) Software Configuration Change Processing Software Change Request/Approval Form (CRA) Software Change Review Board (SCRB) Anomaly Reporting and Resolution (SAR) Software Configuration Status Accounting Software Configuration Status Report (SCSR) Software Configuration Audits and Reviews

Policy Number 2 1 3 4 5 6 7 11 8 9 10



27

7. A permanent record of deviation and waiver approvals shall be maintained for each project using the form depicted in the SE configuration management procedures. This record shall be initiated during development of the Product Objectives Document and shall serve as a record of all subject approvals for the duration of the project.

Figure 2

SE Software Configuration Management Policies Throughout the Software Development Life Cycle

Requirements

Architecture Design

Detailed Design

Code and Test

Integrate and Test

Software Configuration Management Organization

E

E

ED

E

E

E

E

Software Configuration Identification

S

Software Configuration Management of Subcontractor and Vendor Products

S

S

S

S

S

S

S

S

Software Configuration Management Plan (SCMP)

S

S

ED

E

E

E

E

E

Software Configuration Change Processing

S

S

S

S

S

S

S

Software Change Request/Approval (CRA) Form

S

S

S

S

S

S

ED

Software Change Review Board (SCRB)

S

S

S

S

S

S

S

Software Configuration Status Accounting

E

E

E

E

E

E

E

E

ED

ED

Software Configuration Status Report (SCSR)

ED ED ED ED

ED ED ED ED

ED ED

Software Validation

Interface Design

Software Life Cycle Phase

Project Start-up

Policy Topic Title

ED

Software Configuration Audits and Reviews

E

E

E

E

E

E

E

Anomaly Reporting and Resolution (SAR)

S

S

S

S

S

S

ED

Notes: 1. D indicates that a deliverable or activity is required at that time. 2. E indicates that the procedure requirements are in effect for the entire phase. 3. S indicates that the procedure requirements can start at any time.


Page 5 of 30 SE-CMP

28


Figure 3

Matrix of Responsibilities for Software Configuration Management Policy Documents Document Title

Software configuration management procedures Software configuration management deviation Software configuration management waiver Software Configuration Management Plan (SCMP) Software Change Request (SCR) Form (Class I and II) Software Change Request (SCR) Form (Class III) Configuration status accounting Software Configuration Status Report (SCSR) Software Trouble Report (STR) Form (low) Software Trouble Report (STR) Form (medium) Software Trouble Report (STR) Form (high) Notes

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

PCM1 SLE2 V&VLE3

Director, Program SE Manager SCRB4

G

R/D

G G

R/D R/D

G

R

R

A

R

V

A R/D E/M/A

R R

R/D R/D

V

G G

R/D

R

R/D

G

R

R

R/D

G

R

R

R/D

Assigned project configuration manager. Project software lead engineer assigned to the project. Project V&V lead engineer assigned to the project. Software Configuration Review Board. G means generate. A means assigns ID number. E/M/A means establish, maintain, and archive. R means review. R/D means review and disposition. V means verify disposition.

Responsibilities The project configuration manager is responsible for the following: 1. Generating changes to SE SCM Policies 2. Generating written deviations and waivers 3. Generating changes to SCM procedures 4. Applying relevant SCM procedures to the project

Page 6 of 30 SE-CMP



29

The SE [title/position] is responsible for the following: 1. Review and approval or disapproval of SE SCM Policies 2. Review and recommendation of deviations and waivers from SE SCM Policies 3. Review and approval or disapproval of SCM procedures The [title/position] and/or [title/position] are responsible for the following: 1. Approval or disapproval of SE SCM Policies 2. Approval or disapproval of deviations and waivers from SE SCM Policies The [project title/position] is responsible for the review and submittal of deviations and waivers from SE SCM Policies. The managers of organizations supporting and sponsoring the project should share the commitment to implementing these policies.

POLICY 1 SOFTWARE CONFIGURATION MANAGEMENT ORGANIZATION

Policy SE software projects shall assign a project configuration manager to be responsible for the software configuration management (SCM) of the software end products developed on the project. The project configuration manager shall perform the configuration management activities described in the Software Configuration Management Plan (SCMP). In order to achieve the successful configuration management of a software project, the project configuration manager shall establish a product development library to be the depository for software end products placed under configuration control.


Page 7 of 30 SE-CMP

30


Requirements 1. Management of the functions and tasks of SCM for each SE software project shall be the responsibility of the project configuration manager. The project configuration manager shall be responsible for making decisions regarding the performance of SCM, assigning priorities to SCM tasks, estimating the level of effort for an SCM task, tracking the progress of work, and assuring adherence to SE standards in all configuration management efforts. The authority for resolving issues raised by SCM tasks shall reside with the SE [title/position]. A non-project-related person shall be assigned the responsibility for the SCM tasks with the mutual approval of the software lead engineer and the SE [title/position]. This person shall report operationally to the software lead engineer and shall receive functional direction from the SE [title/position]. 2. The project shall prepare and maintain an SCMP in compliance with the SE Software Development Policies. The SCMP shall describe the SCM requirements for the project. The project’s SCMP shall be provided to the project configuration manager by the software lead engineer prior to the Software Requirements Review (SRR). The project configuration manager shall review the SCMP and establish the appropriate configuration management organization for implementing the prescribed configuration management activities. 3. A product software development library shall be established by the project configuration manager to be the depository for software end products placed under configuration control. The product development library shall provide storage of and controlled access to software and documentation in both human-readable and machine-readable form. 4. The project configuration manager shall be responsible for the following activities on the project: a. Providing support and guidance to the software lead engineer on all matters relating to SCM b. Preparing and issuing SCM procedures for SCM activities unique to the project c. Coordinating with the project’s technical team and other technical organizations on matters pertaining to SCM

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the following responsibilities are prescribed by this policy: 1. The project configuration manager shall be responsible for the following: a. Managing the functions and tasks of SCM for an SE software project

Page 8 of 30 SE-CMP



31

b. Reviewing the project’s SCMP and establishing a configuration management organization to implement the prescribed configuration management activities c. Establishing a product software development library to be the depository for software end products placed under configuration control d. Providing support and guidance to the software lead engineer on all matters relating to SCM e. Preparing and issuing SCM procedures for configuration management activities unique to the project f. Coordinating with the project’s technical team and other technical organizations on matters pertaining to SCM 2. The software lead engineer shall be responsible for providing the project configuration manager with the SCMP prior to the Software Requirements Review (SRR) 3. The SE [title/position] shall be responsible for the following: a. Providing functional review and guidance to project personnel performing SCM tasks b. Resolving issues raised by SCM tasks

POLICY 2 SOFTWARE CONFIGURATION IDENTIFICATION

Policy SE software projects shall provide configuration identification of software end products developed on the project. The configuration of each software end product shall be identified by its technical documentation. Configuration baselines shall be established at specific points during software development to further define the configuration of the items as they are developed. The project configuration manager shall be responsible for defining the configuration of the software items at each baseline and assigning configuration identification numbers to each item baselined.

Requirements 1. Interface Design, Requirements, Architecture Design, Detailed Design, Implementation, and Software Validation baselines shall be established for the software


Page 9 of 30 SE-CMP

32


project at the appropriate software development phases. These baselines shall define a formal departure point for control of future changes to the performance and/or design of the software end products. 2. The project configuration manager shall be responsible for defining the technical documentation, which identifies and establishes the configuration of the software end products at each configuration baseline. 3. The items identified for configuration management at each configuration baseline, referred to as configuration items, shall be uniquely identified by a configuration identifier that is easily recognized and understood by the software project personnel. The project configuration manager shall be responsible for composing and assigning all configuration identification numbers to configuration items.

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the project configuration manager shall be responsible for defining the configuration of the software items at each baseline and assigning configuration identification numbers to each configuration item.

POLICY 3 SOFTWARE CONFIGURATION MANAGEMENT OF SUBCONTRACTOR AND VENDOR PRODUCTS

Policy Subcontractors and vendors who design and/or produce software that is delivered as a component of an SE software project shall comply with the same software configuration management (SCM) requirements imposed on the project, insofar as they are applicable. These requirements are imposed on subcontractors and vendors through a procurement package. After source selection and negotiation, the procurement package becomes the contract. SE reserves the right to review the subcontractor’s or vendor’s configuration management system prior to contract award and to periodically audit that system subsequent to contract award to assure that adequate methods are implemented for identifying and controlling each product produced for SE.

Page 10 of 30 SE-CMP



33

Requirements 1. The SE system of controlling subcontractors and vendors with respect to SCM shall include the following: a. A proven source selection process that recognizes and implements SCM requirements b. Contractually required compliance with these SE SCM Policies and SCM procedures c. Continuing liaison, monitoring, and audits to ensure that SCM requirements are met 2. SE’s subcontractors and vendors shall be required to meet the SCM requirements specified in the procurement package. Computer programs developed by subcontractors and vendors can range in complexity from previously developed standard “off-the-shelf” parts to highly sophisticated system elements developed for an SE software project. Therefore, the SCM requirements of the procurement package may vary with each subcontractor or vendor product, depending on the magnitude and complexity of the item being procured. The procurement package shall indicate those parts of the SE SCM Policies and SCM procedures applicable to each subcontractor and vendor and product. 3. The demonstrated capabilities of a subcontractor or vendor to support an SCM program shall be confirmed by SE during the subcontract or vendor selection process. The project configuration manager shall be responsible for reviewing and evaluating the subcontractor’s or vendor’s capabilities as they relate to configuration identification, change control, and configuration status records. 4. Baseline material and changes to baseline material on an SE software project that are submitted by subcontractors and vendors shall be reviewed and approved by SE prior to their submission for project approval. This processing shall include systematic checking for compliance with all SCM requirements. 5. The project configuration manager shall monitor the subcontractor’s or vendor’s configuration management procedures to ensure that adequate methods are being implemented for identifying and controlling each product produced for SE.

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the project configuration manager shall be responsible for the following: 1. Reviewing and evaluating the subcontractor’s or vendor’s capabilities as they relate to configuration identification, change control, and configuration status records



34


2. Monitoring the subcontractor’s configuration management procedures to ensure that adequate methods are being implemented for identifying and controlling each product produced for SE

POLICY 4 SOFTWARE CONFIGURATION MANAGEMENT PLAN

Policy SE software projects shall perform software configuration management functions that establish a series of baselines and methods for controlling changes to these baselines. The degree of formality and control employed and manpower used should be contingent upon the size and complexity of the project, the significance of the product, and the investment risks. The project’s software configuration management activities shall follow a Software Configuration Management Plan (SCMP) to be prepared and approved prior to the Software Requirements Review (SRR).

Requirements 1. An SCMP that addresses the requirements of this policy and any unique requirements shall be prepared by the project’s software configuration manager and approved by the SE [title/position] prior to the SRR. Depending upon the scope of the project, the SCMP may be a separate document or a section of the Software Development Plan (SDP). The plan shall be in the form prescribed by the relevant software development procedures and shall specify the following: a. Baselines to be used by the project and that are established after formal review and project approval b. Configuration identification requirements, including the types of products to be controlled and the rules for naming, marking, or otherwise identifying these products c. Configuration identification requirements, based on the relevant software development procedures d. Configuration control mechanisms, including the definition of the change and approval or disapproval processes for controlled products and the handling of waivers and deviations




35

e. Problem reporting system, including definition of the forms to be used and their relationship to the change control process f. Configuration status accounting system, including the records and reports required to provide traceability of changes to controlled products and to provide a basis for communications of configuration information within the project g. Configuration verification approach to be used in order to assure that products are developed and maintained according to the requirements above 2. The project shall accomplish the issuance, retention, change control, packaging, and delivery of the physical computer program products in conformance with approved configuration control procedures and marking requirements. 3. The project shall establish and operate a product software development library in which the master representation of each software product is maintained and controlled.

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the following responsibilities are prescribed by this policy: 1. The project’s software configuration manager shall be responsible for generating and obtaining the approval of the SCMP. 2. The project’s software lead engineer shall be responsible for the following: a. Reviewing the SCMP and obtaining approval of it b. Ensuring that the software project adheres to the provisions of the SCMP 3. The SE [title/position] shall support and audit each software project’s configuration management program by: a. Reviewing and approving the project SCMP b. Providing functional review and guidance to project personnel performing configuration management duties c. Furnishing part- or full-time specialists to the project when such support is requested by the software lead engineer d. Providing, at project request, interpretive project documentation, standards, and procedures for the guidance of ongoing configuration management activities e. Providing the means for physical media control of baselines to the extent defined by the approved project SCMP f. Reviewing the effectiveness of the project software configuration management program as an element of periodic assurance audits



36


POLICY 5 SOFTWARE CONFIGURATION CHANGE PROCESSING

Policy SE software projects shall provide for the systematic evaluation, coordination, approval or disapproval, and implementation of all changes to the configuration of a software item after establishment of its configuration identification. The project configuration manager shall be responsible for establishing a system to support the configuration change processing described in the project’s Software Configuration Management Plan (SCMP). The implementation and verification of approved changes to baselined material shall conform to the project’s SCMP and Software Verification and Validation Plan (SVVP).

Requirements 1. The project configuration manager shall select and/or generate the SCM procedures required to establish a system to support the change control processing described in the project’s SCMP. 2. The project configuration manager shall be responsible for configuration control of the software end products developed on the project. 3. The software items that compose each configuration baseline shall be provided to the project configuration manager upon approval and/or verification and validation (V&V). The project configuration manager shall be the custodian of the “to-be-established” configuration baseline, previously baselined material and all changes to baselined material, during the completion of the software development phase associated with the configuration baseline. 4. The project configuration manager shall enter baseline material in the product software development library for version and access control. Version control shall ensure the rapid, comprehensive, and accurate treatment of approved changes to items under configuration control. Access control shall ensure restricted access to configuration items undergoing change. 5. Changes to baselined material shall be documented on a Change Request/Approval (CRA) form and uniquely identified by a number that combines the name of the software project and the responsible engineer’s initials, providing valuable historical information as to who requested the change. The project configuration manager shall be




37

responsible for assigning identification numbers to CRAs in accordance with the relevant SCM procedures. 6. CRAs shall be classified as one of the following: a. Class I—changes that affect the performance, function, or technical requirements b. Class II—changes that require a change to other baselined material but that do not meet the criteria defined for Class I changes c. Class III—changes that do not require a change to any other baselined material 7. All CRAs shall be reviewed by the project’s software lead engineer. Approval or disapproval of Class III changes shall be the responsibility of the project’s software lead engineer. Class I and Class II proposed changes shall be submitted by the project’s software lead engineer to the project’s Software Change Review Board (SCRB) with a change status recommendation. 8. The project’s software lead engineer is responsible for the distribution, implementation, and status update of approved CRAs in accordance with the project’s SCMP. 9. The project’s V&V project leader shall be responsible for the verification of revised baselined material in accordance with the project’s SCMP and SVVP.

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the following responsibilities are prescribed by this policy: 1. The project configuration manager shall be responsible for the following: a. Selecting and/or generating the SCM procedures required to establish a system to support the change control processing described in the project’s SCMP b. Maintaining the “to-be-established” configuration baseline, previously baselined material, and all changes to baselined material c. Entering baseline material in the product software development library for version and access control d. Assigning identification numbers to CRAs 2. The project software lead engineer shall be responsible for the following: a. Reviewing all proposed changes to baselined material b. Approving or disapproving Class III CRAs c. Reviewing and recommending Class I and Class II CRAs



38


d. Distributing, implementing, and status updating approved CRAs in accordance with the project’s SCMP 3. The project V&V leader shall be responsible for the verification of revised baselined material in accordance with the project’s SCMP and SVVP.

POLICY 6 CHANGE REQUEST/APPROVAL FORM

Policy Changes to baselined material shall be documented on a Change Request/Approval (CRA) form. The CRA shall document the affected SE software project name, a description of the proposed change(s), its effect on configuration baselines, and the status of the change(s). Changes to baselined material may be initiated by anyone through the generation of a CRA.

Requirements 1. A CRA shall be used to identify proposed changes to baselined material. The form of the CRA shall be as defined in the relevant SE SCM procedures. 2. The CRA shall be submitted by the initiator to the project software lead engineer. 3. Each CRA shall identify the following: a. b. c. d. e. f. g. h.

Affected SE software project name CRA number Application level of the proposed change Initiator Configuration baseline(s) affected Change classification Documents affected Proposed change and estimated impact on other systems, software, or equipment

4. The disposition of the proposed change(s) shall be documented on the CRA, including the date of disposition and signature of appropriate dispositioner.




39

5. The results of change verification shall be documented on the CRA. At the completion of change verification, the conductor of the verification and validation (V&V) activities shall sign and date the CRA. 6. The status of a CRA shall be determined to be closed upon successful change implementation and verification or upon change disapproval. The project software lead engineer is responsible for determining when a CRA shall be considered closed. Upon closure of the CRA, the project software lead engineer shall date and sign the CRA.

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the software lead engineer shall be responsible for the following: 1. Determining when a CRA shall be considered closed 2. Dating and signing closed CRAs

POLICY 7 SOFTWARE CHANGE REVIEW BOARD

Policy SE software projects shall establish a Software Change Review Board (SCRB) to coordinate, review, and decide the disposition of Class I and Class II changes to baselined material. Change Request/Authorization (CRA) forms classified as Class I or Class II shall be submitted to the SCRB. The SE [title/position] shall chair the project’s SCRB, and the project configuration manager shall serve as the SCRB secretary.

Requirements 1. An SCRB shall be established for each project to evaluate and determine disposition of changes to baselined material, which are classified as Class I or Class II changes.



40


2. The SE [title/position] shall be responsible for chairing the project’s SCRB and for proposed change disposition.The members of the project’s SCRB shall be appointed by the SE [title/position] and shall include SE personnel involved in the development of the baselined material to be changed and in the verification and validation (V&V) of the software project. 3. The project configuration manager shall serve as the SCRB secretary and shall be responsible for scheduling SCRB meetings and maintaining minutes of meetings and permanent files of SCRB actions. 4. The SCRB shall analyze and identify the impact of the proposed change and ensure that one or more of the following criteria are met: a. b. c. d.

Effects substantial life-cycle cost savings Significantly increases system effectiveness Corrects deficiencies Prevents slippage of the approved development schedule

5. The SCRB shall direct the proposed change disposition to be one of the following: a. b. c. d.

Additional problem analysis A change different from that proposed in the change document Approval of the change as proposed Disapproval of any change

6. The SCRB secretary shall distribute approved CRAs to the project software lead engineer for implementation. A copy of all CRAs shall be provided to the project configuration manager for configuration accounting purposes.

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the following responsibilities are prescribed by this policy: 1. The project configuration manager shall be responsible for the following: a. b. c. d. e.

Serving as the SCRB secretary Scheduling SCRB meetings Maintaining minutes of meetings Maintaining permanent files of SCRB actions Distributing approved CRAs to the software lead engineer

2. The SE [title/position] shall be responsible for the following:




41

a. Chairing the project’s SCRB b. Appointing the members to the SCRB c. Proposed change disposition

POLICY 8 SOFTWARE CONFIGURATION STATUS ACCOUNTING

Policy SE software projects shall establish and maintain configuration status accounting records for the software end products developed on the project. Configuration status accounting shall provide identification of the project’s configuration baselines, traceability from the baselines resulting from approved changes, and a management tool for monitoring the accomplishment of all related tasks resulting from approved changes. The results of this configuration management activity shall be documented in the project’s Software Configuration Status Report (SCSR).

Requirements 1. Configuration status accounting shall provide for the identification of the project’s configuration baselines and traceability from the baselines resulting from approved changes. Configuration status accounting shall also be used as a management tool for monitoring the accomplishment of related tasks resulting from each approved change to the project’s configuration baselines. The results of this configuration management activity are reported in an SCSR. 2. Configuration status accounting records shall be established and maintained for the software project by the project configuration manager. These records shall provide a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes. The types and formats of the configuration status accounting records shall be in accordance with the project’s Software Configuration Management Plan (SCMP). 3. Configuration status accounting records shall be maintained until all software end products developed on the project have been approved in accordance with the SE Software Development Policies and the project’s SCMP. Upon end product acceptance, all configuration status accounting records shall be archived by the project configuration manager



42


in accordance with the project’s SCMP to provide project history for use in future software development planning.

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the project configuration manager shall be responsible for the following: 1. Establishing and maintaining configuration status accounting records for the software project 2. Archiving all configuration status accounting records upon end-product acceptance

POLICY 9 SOFTWARE CONFIGURATION STATUS REPORT

Policy SE software projects shall document the results of configuration status accounting in a Software Configuration Status Report (SCSR). The SCSR shall be generated at the conclusion of the software development phase associated with each configuration baseline. The SCSR shall be distributed to the project software lead engineer and the SE [title/position]. The project configuration manager shall be responsible for the generation and distribution of the SCSR.

Requirements 1. The SCSR shall document the status of the configuration items being developed on the project, and the form of the SCSR shall be as defined in the relevant SE SCM procedures. 2. The results of configuration status accounting for each configuration baseline shall be reported in the SCSR. The SCSR shall list the following information: a. Baseline identification b. A list of all baselined material, indicating the current revision and referenced CRAs c. A list of all CRAs, including current disposition or date of closure




43

3. The SCSR shall be generated and distributed at the conclusion of the software development phase associated with each configuration baseline and upon request of the project software lead engineer. The project configuration manager shall be responsible for the generation and distribution of the SCSR to the project software lead engineer and the SE [title/position].

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the following responsibilities are prescribed by this policy: 1. The project configuration manager shall be responsible for generating and distributing the SCSR. 2. The project software lead engineer shall be responsible for reviewing the SCSR. 3. The SE [title/position] shall be responsible for reviewing the SCSR.

POLICY 10

SOFTWARE CONFIGURATION AUDITS AND REVIEWS

Policy SE software projects shall conduct technical reviews and configuration audits as described in the SE Software Development Policies and SE Software Verification and Validation Policies. Additionally, SE software projects shall ensure the integrity, completeness, and traceability of “to-be-established” and “established” configuration baselines. The project configuration manager shall be responsible for providing configuration management support during the project’s technical reviews and configuration audits. The project configuration manager is responsible for performing configuration audits of pre- and post-baselined material.

Requirements 1. The project configuration manager shall be responsible for supporting the project software lead engineer in the preparation and conduct of the project’s technical reviews.



44


2. The project configuration manager shall be responsible for supporting the project V&V leader in the preparation and conduct of the project’s software configuration audit of the validated software. 3. The project configuration manager shall be responsible for the following during the project’s technical reviews and configuration audits: a. Providing an update of the project’s Software Configuration Status Report (SCSR) b. Obtaining copies of baselined material for use during the review or audit c. Providing a copy of all Change Request/Approval (CRA) forms generated since the last review or audit 4. The project configuration manager shall be responsible for conducting configuration audits of the project’s “to-be-established” and “established” configuration baselines. These audits shall be conducted to ensure the following: a. Technical and administrative integrity of pre- and/or post-baselined material b. Each element maps directly or through parents when traced through preceding baselines c. System and software requirements are fulfilled by the software configuration specified in the “to-be-established” and “established” baseline d. Changes made to baselined material are implemented as intended

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the project configuration manager shall be responsible for the following: 1. Supporting the project software lead engineer in the preparation and conduct of the project’s technical reviews 2. Supporting the project V&V leader in the preparation and conduct of the project’s software configuration audit of the validated software 3. Providing an update of the project’s SCSR to the review or audit team 4. Obtaining copies of baselined material for use during the review or audit 5. Providing a copy of all CRAs generated since the last review or audit 6. Conducting configuration audits of the project’s “to-be-established” and “established” configuration baselines




POLICY 11

45

ANOMALY REPORTING AND RESOLUTION

Policy The project configuration manager shall be responsible for the proper documentation and reporting of software configuration management anomalies on a Software Anomaly Report. All anomalies shall be reported regardless of the perceived impact on software development or the severity of the anomaly with respect to system operation. Software Anomaly Reports shall be reviewed by the project software lead engineer for anomaly solution determination and implementation authorization.The project software V&V lead engineer shall be responsible for anomaly report closure.The SE [title/position] shall be responsible for the approval or disapproval of the distribution of Software Anomaly Reports.

Requirements 1. A Software Anomaly Report shall be used to identify problems detected during software configuration management activities. The specific information required includes the following: a. b. c. d. e.

Description and location of the anomaly Severity of the anomaly Cause and method of identifying the anomalous behavior Recommended action and actions taken to correct the anomalous behavior Impact of the problem on the system capability of the product and on the continued conduct of V&V phase activities

2. The form of the Software Anomaly Report shall be as defined in the relevant SE software configuration management procedures. The configuration identification, tracking, and status reporting of Software Anomaly Reports shall be in accordance with the project’s Software Configuration Management Plan (SCMP). 3. The projected impact of an anomaly shall be determined by evaluating the severity of its effect on the operation of the system. The severity of a Software Anomaly Report shall be defined as one of the following: •

High. The change is required to correct a condition that prevents or seriously degrades a system objective where no alternative exists, or to correct a safety-related problem.

•

Medium. The change is required to correct a condition that degrades a system objective, to provide for performance improvement, or to confirm that the user or system requirements can be met.



46


•

Low. The change is desirable to maintain the system, correct operator inconvenience, or any other.

4. The project software V&V lead engineer shall be responsible for ensuring the proper documentation and reporting of software anomalies. All anomalies shall be reported regardless of the perceived impact on software development or the severity of the anomaly with respect to the system operation. 5. Software Anomaly Reports shall be reviewed by the project software lead engineer for anomaly validity, type, and severity. The project software lead engineer can direct additional investigation if required to assess the validity of the anomaly or the proposed solution. An anomaly solution that does not require a change to a baselined software configuration item may be approved by the project software lead engineer. If the anomaly requires a change to a baselined software configuration item, then the anomaly solution shall be approved in accordance with the project’s SCMP. 6. When an anomaly solution is approved and the personnel responsible for performing the corrective action are indicated, the project software lead engineer shall authorize implementation of the corrective action. 7. The project software V&V lead engineer shall be responsible for anomaly report closure, which includes the following: a. Documenting the corrective action(s) taken b. Verifying the incorporation of authorized changes as described in the anomaly report c. Reporting the status of the Software Anomaly Report to the software lead engineer and the SE [title/position] 8. The SE [title/position] shall be responsible for the approval or disapproval of the distribution of Software Anomaly Reports that are reported closed. When distribution is approved, the project software V&V lead engineer shall distribute closed Software Anomaly Reports to the software project Quality Assurance representative(s). 9. The SE [title/position] shall ensure the resolution of anomalies that are indicated on the Software Anomaly Report with a severity of “high” before the software project proceeds to the next software development phase.

Responsibilities In addition to the responsibilities identified in the preamble to these policies, the following responsibilities are prescribed by this policy: 1. The project software V&V lead engineer shall be responsible for the following:




47

a. Proper documentation and reporting of software anomalies b. Anomaly report closure c. Distribution of closed Software Anomaly Reports to the software project Quality Assurance representative(s) 2. The software lead engineer shall be responsible for the following: a. Review of Software Anomaly Reports for anomaly validity, type, and severity b. Direction of additional investigation if required to assess the validity of the anomaly or the proposed solution c. Approval or disapproval of an anomaly solution that does not require a change to a baselined software configuration item d. Authorization of corrective action implementation 3. The SE [title/position] shall be responsible for the following: a. Approval or disapproval of the distribution of closed Software Anomaly Reports b. Ensuring the resolution of anomalies that are indicated on the Software Anomaly Report with a severity of “high” before the software project proceeds to the next software development phase



48


GLOSSARY Accuracy: Quantitative assessment of freedom from error. Archive: Provisions made for storing and retrieving records over a long period of time. Audit: Independent review for the purpose of assessing compliance with software requirements, specifications, baselines, standards, procedures, instructions, and coding requirements. Baseline: Specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Change control: Process by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked. Change Request/Approval (CRA): Form used to document changes to a baseline. Code: Loosely, one or more computer programs or part of a computer program. Completeness: Those attributes of the software or documentation that provide full implementation of the functions required. Component: Unit of code that performs a specific task or a group of logically related code units that perform a specific task or set of tasks. Computer program: Sequence of instructions suitable for processing by a computer. Processing may include the use of an assembler, a compiler, an interpreter, or a translator to prepare the program for execution as well as to execute it. Configuration audit: Process of verifying that all required configuration items have been produced, that the current version agrees with specified requirements, that the technical documentation completely and accurately describes the configuration items, and that all change requests have been resolved. Configuration control: Process of evaluating, approving or disapproving, and coordinating changes to configuration items after their configuration identification has been formally established. Configuration identification: Process of designating the configuration items in a system and recording their characteristics.




49

Configuration item: Aggregation of hardware, software, or any of its discrete parts, that satisfies an end-use function. Configuration management (CM): Process of identifying and defining the configuration items in a system, controlling the release and change of these items throughout the product life cycle, recording and reporting the status of configuration items and change requests, and verifying the completeness and correctness of configuration items. Configuration status accounting: Recording and reporting of the information that is needed to manage a configuration effectively, including a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes. Correctness: Extent to which software is free of design defects, coding defects, and faults; meets its specified requirements; and meets user expectations. Delivery: Transfer of responsibility for an item from one activity to another, as in the delivery of the validated software product to quality assurance personnel for certification. Design phase: Period in the software development cycle during which the designs for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements. Deviation: Authorization for a future activity, event, or product to depart from standard procedures. Documentation: Manuals, written procedures or policies, records, or reports that provide information concerning uses, maintenance, or validation of software. Error: Discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. Evaluation: Process of determining whether an item or activity meets specified criteria. Failure: Inability of a system or system component to perform its required function (see fault). Fault: Defect of a system or system component, caused by a defective, missing, or extraneous instruction or set of related instructions in the definition, specification, design, or implementation of a system that may lead to a failure.



50


Implementation phase: Period in the software development cycle during which a software product is created from design documentation and debugged. Integrity: Accuracy in an item’s compliance with its requirements. Procurement package: All specifications, documents, state of work, and data required to describe a complete task for submittal to prospective subcontractors and vendors. Product history file: Compilation of records containing the complete development history of a finished product. Quality assurance (QA): Planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical requirements. Requirements phase: Period in the software development cycle during which the requirements, such as functional and performance capabilities for a software product, are defined and documented. Software: Computer programs, procedures, rules, and associated documentation and data pertaining to the operation of a computer system. Software Change Review Board (SCRB): Forum for the evaluation, approval, monitoring, and control of changes to software baselines. Software configuration management (SCM): Discipline of identifying the configuration of a software system at discrete points in time for the purpose of systematically controlling changes to this configuration and maintaining the integrity and traceability of this configuration throughout the development process. Software Configuration Management Plan (SCMP): Project-specific plan that specifies the methods and planning employed to implement SCM activities. Software Configuration Management Policy Change Control Board (SCMPCCB): Members appointed to establish and maintain a set of Software Configuration Management Policies in order to achieve quality in all phases of the software development life cycle. Software Configuration Status Report (SCSR): Document that reports the results of configuration status accounting performed on a software project. Software development library: Software library containing computer-readable and humanreadable information relevant to a software development effort.




51

Software development life cycle: Period that starts with the development of a software product and ends when the product is validated and delivered for QA certification. This life cycle includes a requirements phase, design phase, implementation phase, and software validation phase. Software Development Plan (SDP): Project-specific plan that identifies and describes the procedures used to implement the management activities that coordinate schedules, control resources, initiate actions, and monitor progress of the software development effort. Software end products: Computer programs, software documentation, and databases produced by a software development project. Software library: Controlled collection of software and related documentation designed to aid in software development, use, or maintenance. Software project: Planned and authorized undertaking of specified scope and duration that results in the expenditure of resources toward the development of a product that is primarily one or more computer programs. Software Requirements Review (SRR): Software review conducted to review the provisions of the Software Requirements Specification, which, once approved, will serve as the basis of acceptance of the software end product. Software Requirements Specification (SRS): Project-specific document that provides a controlled statement of the functional, performance, and external interface requirements for the software end products. Software Validation Phase: Period in the software development life cycle in which the components of a software product are evaluated and integrated and the entire software product is evaluated to determine whether requirements have been satisfied. Software Verification and Validation Plan (SVVP): Project-specific plan that describes the project’s unique verification and validation organization, activities, schedule, inputs and outputs, and any deviations from the software policies required for effective management of verification and validation tasks. Technical reviews: Meetings at which the software end products of a phase of software development are presented for the purpose of end-product review, issue resolution, and obtaining commitment to proceed into the next software development phase. Validation: Process of evaluating software at the end of the software development process to ensure compliance with software requirements.



52


Verification: Process of determining whether the products of a given phase of the software development cycle fulfill the requirements established during the previous phase. Waiver: Authorization to depart from SE policy for an activity, event, or product that has already been initiated.



SE-DCP SOFTWARE ENGINEERING DESIGN CONTROL POLICIES

Written by:


Date

Reviewed by:


Date

Approved by:


Date

Approved by:


Date

Document Number [aaa]-SEDCP-[#.#]

Revision

Page

[#.#]

1 of [#]


Description

Date

[##.##]


[mm/dd/yy]


Page 1 of 8 SE-DCP

54


CONTENTS

1.0

PURPOSE

3

2.0

SCOPE

3

3.0

RESPONSIBILITY

3

4.0

PROCEDURE

4

APPENDIX A

Page 2 of 8 SE-DCP

Process Record of Deviation or Waiver Approval

8



55

1.0 PURPOSE

The purpose of this document is to describe the general, high-level software design control philosophy and methodology used for [company name] software.

2.0 SCOPE

This procedure applies to the design control of the following [company name] software: (1) product, engineering, embedded systems or application software; and (2) quality system(s) software applications used to trace, track, or generate reports containing quality-related data, such as defect tracking, field problem reporting, and so forth.The allocation of this procedure is to [company name] internal software development, vendor-supplied software, and contractor-supplied software.

3.0 RESPONSIBILITY

This document applies to the design control of all software developed by or for [company name] engineering, [insert any other company organizations, such as administration, Information Systems (IS), or Information Technology (IT), that will be using this design control policy to govern software development].

3.1 Software Development Responsibilities An engineer or team will be designated by engineering [list other company organizations such as administration, IS, or IT] to undertake a planned and authorized project of specified scope and duration which results in the expenditure of resources toward the development and/or implementation of a software end product.


Page 3 of 8 SE-DCP

56


3.2 Software Verification and Validation Responsibilities A software verification and validation (V&V) engineer will be designated by engineering [list other company organizations such as administration, IS, or IT] to perform and coordinate software V&V activities, including assessment, evaluation, analysis, review, testing, and the generation of associated documentation.

3.3 Software Design Control Responsibilities The Quality Systems (QS) group will define and maintain this procedure and audit compliance with this procedure. The QS group will make all decisions regarding the [company name] software packages, applications, or systems that are governed by this procedure.

4.0 PROCEDURE

A software project is a planned and authorized undertaking of specified scope and duration which results in the expenditure of resources toward the development of a product that is primarily one or more computer programs. Each software project requires that V&V activities be performed to ensure an independent assessment and measurement of the correctness, accuracy, consistency, completeness, robustness, and testability of the software requirements, design, and implementation. All software developed by or for [company name] by employees or consultants will be subjected to appropriate V&V activities as generically specified in the following sections.

4.1 [company name] Developed Software for Products or Processes 4.1.1

The specifics of software V&V and software development activities, comprising the software life-cycle methodology, procedures, and practices, shall be detailed in writing, external to the software project, in separate software engineering process documents.

4.1.2

The end result of V&V is written affirmation stating that the software was developed in accordance with documented software engineering procedures, that good quality

Page 4 of 8 SE-DCP



57

assurance procedures were adhered to, and that test results demonstrate that system and software specifications and/or functional requirements were met. 4.1.3

The results of the software development and related V&V activities are to be kept on file in [enter location where documents are kept such as Document Control] as part of the [enter formal name of document repository such as Product History File]. This repository will hold the appropriate software development documents, V&V documents, and vendor V&V supporting documents.

4.1.4

Software project documentation will consist of specifications and documents detailing functional units or modules and their operations; traceability to higher requirements, safety, and hazards; and specification of the software project development activities and quality assurance procedures.

4.1.5

Software project documentation will provide specifications of the V&V activities; test plans for all functional units or modules and test completion criteria; software functional test plan; traceability among requirements, safety, hazards, and testing; and a software V&V test report and summary with results of testing at all levels.

4.2 [company name] Developed Software for [enter other company organizations such as administration, IS, or IT not using this design control policy] 4.2.1

The specifics of V&V and software development activities shall be documented in separate business system or information system software engineering process documents that describe software activities related to [company name] business system, quality system, or information system software development projects. This can be satisfied with either [company name] [enter other company organizations such as administration, IS, or IT] software engineering procedures or product development software engineering procedures.

4.2.2

The end result of V&V is written affirmation stating that the software was developed in accordance with documented software engineering procedures, that good quality assurance procedures were adhered to, and that test results demonstrate that system specifications and/or functional requirements were met.

4.2.3

The results of the software development and related V&V activities are to be kept on file in the [enter location where documents are kept such as Document Control, IS or IT] area. The [enter location where documents are kept such as Document Control, IS or IT] area will also hold vendor V&V supporting documents.


Page 5 of 8 SE-DCP

58


4.3 Vendor-Supplied (“off the shelf”) Software 4.3.1

All off the shelf software shall be validated for intended use with both correct and incorrect inputs. The software package shall produce intended and correct outputs for each of the types of input.

4.3.2

Software purchased from a supplier does not require V&V when the supplier can provide evidence of at least one of the following: (1) a product V&V certification; (2) an error or bug tracking and reporting capability; (3) has software maintenance, revision, and upgrade capabilities; or (4) a software quality assurance program.This type of software has software-industry-accepted V&V based on validation through common usage and wide distribution.

4.4 Vendor-Supplied Commercial Equipment With Software Commercial equipment with incorporated software purchased from a supplier and proven through use does not require V&V when the supplier can provide evidence of at least one of the following: (1) a product V&V certification; (2) an error or bug tracking and reporting capability; (3) software maintenance, revision, and upgrade capabilities; (4) a software quality assurance program; or (5) test programs that may be used to assure that the equipment will appropriately and accurately perform all intended functions before it is used for routine production. 4.4.1

Automated production and test equipment that is controlled by software can be validated through the use of a “golden unit,” which should exercise all functions and decisions in normal and worst-case situations that may be expected during normal production use.

4.4.2

Conducting a first and last piece inspection of representative product lots can validate automated machine tools that are controlled by software. The record of this activity may be noted on the routine quality control or production records for the machine.

4.5 Contractor-Supplied Software Departments that contract for the purchase of software from subcontractors or vendors who design and/or produce software shall establish a procurement package for assuring that the subcontractor or vendor will produce quality software.The subcontractor or vendor shall com-

Page 6 of 8 SE-DCP



59

ply with the same requirements imposed in this document. The contracting department shall reserve the right to review the subcontractor’s or vendor’s configuration management system prior to contract award and to periodically audit that system subsequent to contract award to assure that adequate methods are implemented for identifying and controlling each end product produced. 4.5.1

The procurement package will provide assurance that the requirements for the software are clearly defined, communicated, and completely understood by the subcontractor or vendor. This may require written procedures for the preparation of requirements and purchase orders, subcontractor or vendor conferences prior to contract release, and other appropriate methods.

4.5.2

Acceptance procedures for contractor- or vendor-supplied software may include thirdparty certification. [company name] shall have the primary responsibility for assuring that the software is adequate for its intended use.When third-party certification is used, the certification package shall include adequate documented evidence that the software complies with specified requirements. Examples of such evidence include criteria listed in the above sections.


Page 7 of 8 SE-DCP

60


APPENDIX A

SOFTWARE ENGINEERING PROCESS RECORD OF DEVIATION OR WAIVER APPROVAL

SOFTWARE ENGINEERING PROCESS RECORD OF DEVIATION OR WAIVER APPROVAL PROJECT:

TYPE: Deviation or Waiver

PHASE: SOP Requirement Paragraph(s):

Initiated by:

________________________________ Signature

Reviewed by:

________________________________ Signature

Approved by:

________________________

Date:

________________________

Date:

________________________

Title/Position

________________________________ Signature

Date:

Title/Position

Title/Position

Reason/Rationale/Explanation:

Project schedule and performance impact:

Project risk:

Alternative approach to be used:

Page 8 of 8 SE-DCP


SE-SDG SOFTWARE ENGINEERING SOFTWARE DEVELOPMENT GUIDELINES

Written by:


Date

Reviewed by:


Date

Approved by:


Date

Document Number [aaa]-SESDG-[#.#]

Revision

Page

[#.#]

1 of [#]


Description

Date

[##.##]


[mm/dd/yy]


Page 1 of 41 SE-SDG

62


CONTENTS

1.0

INTRODUCTION

3

2.0

PROGRAM ORGANIZATION AND STYLE

5

3.0

INTERNAL SOURCE CODE DOCUMENTATION

10

4.0

NAMING CONVENTIONS

12

5.0

CONSTRUCTS

15

6.0

CODING PRACTICES

16

7.0

HARDWARE INTERFACE

22

8.0

SOFTWARE REPORTING PRACTICES

24

APPENDIX A

Assembly Language Programming Guidelines

27

APPENDIX B

C Programming Guidelines

32

APPENDIX C-1


38

APPENDIX C-2

Instructions for Completing Software Anomaly Report

39

Software Development Record of Deviation or Waiver Approval

40

APPENDIX D

GLOSSARY

Page 2 of 41 SE-SDG

41



63

1.0 INTRODUCTION

1.1 Purpose This document has been developed to define consistent methods, standards, conventions, practices, and styles for software development and resultant source code.

1.2 Scope The guidelines in this document are to be used to promote consistency in developing all software. The software development teams will use this guide to establish common practices for software development and code generation. This guide will be used as a general template for any software language.

1.3 Overview This document covers the following: •

Organization of files and internal documentation

•

Coding style and recommended limits on function and file sizes

•

Conventions used for naming program items

•

Recommended program and logical constructs

•

Optimization rationale and generic methods

1.4 References 1.4.1

Industry Standards

Unless otherwise specified, the latest revision of the following documents shall be used:


Page 3 of 41 SE-SDG

64


•

ANSI X3.159-1989

C Language Specification

•

ANSI X3.53-1976

PL/1 Language Specification

•

ANSI X3.9-1978

FORTRAN Language Specification

•

ANSI/MIL-STD-1915A

ADA Language Specification

•

ANSI X3.4-1977

Information Exchange Specification

•

ANSI/IEEE 1016-1986

Software Design Description

•

ANSI/IEEE 729-1983

Glossary of Software Engineering Terminology

•

DOD-STD-2167

Defense Systems Software Standards

•

DOD-STD-7935

Automated Data Systems Documentation

•

MIL-STD-490

Specification Practices

1.4.2

Corporate Documents

•

Product Development Safety Design Guidelines, Revision [#.#], dated [date]

•

Product Development User Interface Design Guidelines, Revision [#.#], dated [date]

•

Software Engineering Configuration Management Guidelines, Revision [#.#], dated [date]

•

Software Engineering Software Configuration Management Policies, Revision [#.#], dated [date]

•

Software Engineering Software Development Policies, Revision [#.#], dated [date]

•

Software Engineering Verification and Validation Guidelines, Revision [#.#], dated [date]

•

1.4.3 •

Software Engineering Verification and Validation Policies, Revision [#.#], dated [date]

Other Documents C Programming Guidelines. T. Plum. Prentice-Hall, 1984.

Page 4 of 41 SE-SDG



•

The C Programming Language, Second Edition. B.W. Kernighan and D.M. Ritchie. Prentice-Hall, 1988.

•

Software Engineering Economics. B.W. Boehm. Prentice-Hall, 1981.

65

2.0 PROGRAM ORGANIZATION AND STYLE

All software should be written in a manner that enhances readability. Each individual module, file, function, procedure, and subroutine within the program should follow the same general format and be logically ordered. The following guidelines should be used when making style decisions.

2.1 Cohesion There are seven levels of cohesion listed here from the least desirable to the most desirable: 1. Coincidental cohesion.Tasks performed by a module are grouped purely by coincidence. 2. Logical cohesion. Tasks performed by a module are independent but logically similar. 3. Temporal cohesion. Tasks performed by a module are related by time. 4. Procedural cohesion. Tasks performed by a module are related by the order in which program control flow must occur. 5. Communicational cohesion.Tasks performed by a module are related through a requirement to access common data. 6. Sequential cohesion.Tasks performed by a module are related by the order in which program data flow must occur such that the output of one task is the input to the next task. 7. Functional cohesion. Module performs a single task. A program module should be communicatively, sequentially, or functionally cohesive, and functionally cohesive is preferred. If the purpose of a module can be summarized in a single sentence of the form “specific verb + specific object(s),” that module is functionally cohesive.


Page 5 of 41 SE-SDG

66


2.2 Coupling There are five types of coupling listed here from the least desirable to the most desirable: 1. Content coupling. Modules are content coupled if a module alters a statement in another module, a module refers to or changes data contained within another module, or a module branches to another module. 2. Common coupling. Modules are common coupled if they share common data. 3. Control coupling. Modules that pass control parameters are control coupled. 4. Stamp coupling. Modules are stamp coupled if they communicate using a data structure. 5. Data coupling. Modules that communicate by passing ordinary data in a call or return statement are data coupled. Data coupling is the preferred method of coupling, but data that are passed through several modules before they reach the module in which they are operated on should be avoided. Control coupling, if required, should be implemented only to pass data from a higher to a lower level module in the hierarchy. Module coupling is considered optimum when a new module can replace any particular module without affecting any other software component in the system.

2.3 Declarations and Definitions 2.3.1

Function and Variable Definitions

All functions and variables should be defined at the beginning of the source code file before they are used. Explicit data types, return types, and return values should be used instead of default values or types, because the latter can lead to incorrect code and their type is less obvious. Explicit exit types and values should be used for the same reason.

2.3.2

Definition Locations

Definitions of literals, constants, macros, structures, and function prototypes should be grouped into header files that are separate from the source code files. These header files may be combined with source code files to create the file that is then compiled or assembled. The use of header files simplifies generation of source files that use the same definitions.

Page 6 of 41 SE-SDG



2.3.3

67

Data Definition Locations

Data should not be defined in header files, because they may be included in more than one source file, which causes multiple definitions of the same data. Global data definitions should be grouped into source files that have no executable instructions. This will make global data easier to find and will simplify maintenance. Grouping of data that are common to a set of programs that make up a task will also facilitate understanding of the task and simplify maintenance.

2.4 Libraries Groups of object modules should be combined into libraries, which can then be thought of as a single module in terms of usage, configuration control, documentation, and verification and validation (V&V). The advantage of using libraries is that the library will be more stable than a large number of individual files. The use of libraries to group similar modules also encourages reusability of previously debugged and verified code.

2.5 Directives The directives or any means of performing special and/or unique operations by a tool should be used. The use of directives allows for special non-code-related tool functions and support and makes the human interaction easier. All directives for a given file should be at the beginning of the file unless their functions prohibit this; directives include the following: •

Compiler

•

Assembler

•

Linker

•

Loader

•

Locator

•

Library manager

•

MAKE program


Page 7 of 41 SE-SDG

68


•

Debug switches

•

Environment variables

Prior to beginning any coding, a thorough review of the tool directives should be made in order to determine the correct assignments.

2.6 File Organization 2.6.1

File Directories

Directory structures should be uniform throughout all software projects, and they should be organized logically to aid in clarity and maintainability. Source and generated files should reside in different directories.

2.6.2

Code File Contents

If only one function resides in each file, only a function prologue is necessary. However, if multiple functions are grouped together within a file, a designation for the group should precede any functions and explain, at a minimum, what the functions have in common and why they are grouped together. Each file should be organized so that text substitutions appear first, data declarations and initialization next, and then the code.

2.6.3

Number of Functions Per File

In general, files should be limited to one function.

2.7 Function Size Functions should consist of 100 or fewer source lines and be no longer than a screen length. This guideline does not require artificial splitting of cohesive code into smaller pieces.

Page 8 of 41 SE-SDG



69

2.8 Layout 2.8.1

Tabs Versus Spaces

The use of tabs within the documentation of a project can cause document output by different tools to be inconsistent in appearance. If all of the tools used on the project can be configured to produce the same output when using tabs, then tabs may be used. If tabs are used, tab stops should be the equivalent of four spaces. If one or more tools used on a project cannot be configured to the same number of tabs as all of the other tools, spaces should be used for indentation.

2.8.2

White Space and Blank Lines

White space should be used to enhance program readability. Succeeding logical levels should be indented four spaces. Secondary and following lines of a multiple line statement should be indented to show logical constructs but not less that two spaces. Blank lines should also be used wherever they promote readability. A blank line should be left between the logical sections of a program. If more that one function resides in a single file, two or more blank lines should be left between them.

2.8.3

Page Width

The maximum page width of source files should be limited to the editor screen width. This allows ease of viewing and editing. An additional limitation should be that the page width must be sized so that it is compatible with the printer used. This allows ease of viewing hard copy material.

2.8.4

Columns

Structure definitions, table initializations, and other similar constructs should be organized in neat columns for easy reading. The enclosing braces of a table should be in the same column.

2.8.5

Code

Multiple statements per line should be avoided.


Page 9 of 41 SE-SDG

70


3.0 INTERNAL SOURCE CODE DOCUMENTATION

The purpose of using source-code-embedded documentation is to provide an internal guide to understanding the source code for debugging, modification, testing, communicating with other readers, and maintaining the program. The basic elements of internal source code documentation should include function prologues, block comments, in-line comments, and documentation available in ROM.

3.1 Include Files Include files are files that are included in other source files prior to processing by a compiler or an assembler, and they are used to declare the standard library and other project-related library functions. These files are also used to contain the template for data organization, definitions, macros, function prototypes, and text substitutions that are shared among multiple files. However, include files should not be used for declaration or initialization of source code data. They should be functionally organized so that declarations for separate subsystems should be in separate include files. If a set of declarations is likely to change when code is sent from one machine to another, those declarations should be in a separate include file. Nested include files should be avoided. The purpose of each include file should be explicitly described as a comment block at the beginning of the file, and all items in the include files should be clearly documented. Unique file extensions may be used to categorize the files by content. Include files should be listed at the top of the code module in which they are to be used.

3.2 Function Prologues Function prologue comments should appear immediately following the routine header statement and parameter declarations. The basic format for such comments should include the following: •

Description of what the function or subroutine does

•

Calling argument descriptions: – Input. Arguments that are used or can be accessed – Output. Arguments that are modified – I/O. Arguments that are used, can be accessed, and are modified – Returned value(s)

Page 10 of 41 SE-SDG



•

Data structures, global data, and parameter descriptions by name: – Input parameter descriptions – Output parameter descriptions

•

Module name. Name of the task or module in which the function or subroutine is incorporated

•

Function or subroutine development history such as copyright notice, original author, date of creation, and revision number

71

3.3 Source Code Comments 3.3.1

Block Comments

Sections of explanatory text should be used to describe blocks of code rather than commenting on every line. Block comments should be separated from code by using blank lines or indentation and may contain pseudocode for complicated data structures or algorithms. Use comments to explain processing, side effects, or unusual operations.

3.3.2

In-line Comments

Functions or subroutines should be documented with one-line comments placed liberally throughout the source code. The comments should appear immediately above the code it describes and should be tabbed over a uniform distance. Short comments may appear on the same line as the code it describes provided that the comment does not require a second line and does not violate any other guidelines for page width or columns.

3.4 Documentation in ROM Internal source code documentation that ends up in the ROM should include the following in at least one location of every subsystem: •

Copyright notice

•

Subsystem name

•

Software version and revision number



72


In addition, in one location of every system the following information should be included: •

Copyright notice

•

Device type or model identification

•

Device serial number

•

Compatible electrical engineering (EE) revision number(s)

•

Compatible mechanical engineering (ME) revision number(s)

•

Compatible software engineering (SE) revision number(s)

4.0 NAMING CONVENTIONS

4.1 General Names of files, functions, variables, structures, and macros should be selected to impart the contents and understanding of the named unit to programmers, users, and maintainers of the software. The naming format to be used on a project should be selected before coding has started, documented in the Software Detailed Design Specification (SDDS), and maintained for the duration of the life of the product. Names should be selected so that they cannot be confused with the other groupings of names. The filename should coordinate with the task it is representing. Characters selected for names must be compatible with the character set allowed for names in the language selected. If multiple languages are used, only the characters common to the languages should be used for names within that project. Names should not be assumed to be case sensitive. The length selected for names must also be compatible with the language selected. Names must be unique within the length allowed by the language. If multiple languages are used, the names must be unique within the shorter of the lengths allowed by all languages used within that project. Names of more than four characters should differ by at least two characters.




73

4.2 Scope The scope of a variable should be obvious from its name. A part of the name may be used to allow the user to determine the scope of the variable without the need to look up the definition. Each project should develop a naming scheme for macros, variables, functions, and pointers that would identify these entities as belonging to a particular module, task, or function operation. In addition, global variables that serve as identifiers of specific operating system task entities, such as mailboxes or task control blocks, should be marked appropriately.

4.2.1

Variables

Variables may have global, physical task, file, or local scope and should not be all uppercase characters.

4.2.2

Data Structures

Data structures may have global, physical task, file, or local scope and should not be all uppercase characters. Data structures should follow conventions associated with their form and use. All data structures should be documented to indicate type and purpose.

4.2.3

Macros

Macro names should be completely separate and unique from all other names and should be defined with names that are all uppercase.

4.2.4

Functions

Function names should be as descriptive as possible of the operational functions that they perform. Functions should also be grouped using one or more characters of the name that allow users to understand which functions make up a task or logically grouped set of functions.

4.3 Mnemonic After the letters that indicate the scope or grouping of a file, function, variable, or structure, the remaining characters of the name should be used to convey the function of the entity. Descriptive and meaningful names should be used to assist the user in understanding the basic purpose of an entity without the need to look up the definition.



74


4.4 File Names File names must conform to the conventions of the hardware platform that will hold the source files of the project. If more than one platform is used on a project, the file names must be constructed to be compatible with all systems used. Some system conventions of concern are number of characters allowed in file names, characters allowed in file names, use of file extensions, use of version extensions, and size of extensions. Characters that are unique to the selected system should be avoided.

4.4.1

Source Code Files

The files that make up a task or logical set of functions should be grouped by using file names that are identical in one or more characters. A file name should use the name of the function that it contains or as much of the name as allowed by the file system. If more than one function is contained in the file, the name of the file should indicate the functionality of the set of functions in the file.

4.4.2

Source Files

Files that are related in their function, content, or use should be grouped by using file names that are identical in one or more characters.

4.4.3

Object and Executable Generated Files

The source code object modules and their executable files should have the same name as the source code file name and the same name as the file used to produce them.

4.4.4

Library Files

The library name should indicate the function performed by the library.

4.4.5

Generated Files

Files that are related by their generation or content should be grouped by using file names that are identical in one or more characters.




75

4.5 Abbreviations If abbreviations are used, only one abbreviation version should be used for any object. For example, either “ptr” or “pt” may be used as the abbreviation for “pointer” but only one should be used on a given project. Standard abbreviations should be used if possible.

5.0 CONSTRUCTS

Constructs should be used in a disciplined and structured manner, and they should help eliminate obscurity, not cause it.

5.1 Control Constructs The three types of control structures are sequencing, selection, and repetition. Sequencing is used to indicate that the execution of one statement immediately follows the execution of another statement. It is possible to group together statements of a sequence to form a unique compound statement. Selection control constructs allow a selection to be made among a number of possible alternative statements. This is usually expressed as an “if,” “if-then,” “if-then-else” construct, as a “case” statement, or as a select statement with multiple selection. Repetition constructs allow the looping through a certain set of instructions repeatedly for a finite number of times. These instructions are expressed as “for,” “while,” “repeat,” or “do” loops.

5.2 Use of Constructs Multiple selection is favored over sequential instances of single selection if there are three or more choices involved. “GOTO” commands should be avoided and structured constructs used.

5.3 Exit and End Statements Exit, end, or process terminating statements and similar commands should be used only for error exits. Copyright © 2002 Interpharm Press


76


5.4 Nesting Nesting of constructs should be used wherever it enhances program clarity and readability and should be reinforced through the use of indentation. Nesting should not exceed seven levels.

6.0 CODING PRACTICES

The coding practices defined here are to be used as a guide for developing code in areas of the system that require innovative approaches to achieve the required levels of performance. Simple and direct coding should be used in all cases, unless it can be shown that more complex code is mandatory to reach the required level of performance.

6.1 Parentheses and Grouping Use of implied operator precedence should be avoided in both logical and arithmetic expressions. Parentheses should be used to explicitly demonstrate execution order.

6.2 Assembly Versus High-Level Language High-level languages are preferred to low-level languages in all cases. A change from high to assembly language is generally undesirable but may be needed in order to meet performance requirements. If the performance issue is a lack of execution speed, then the change to assembly language should be considered only after the high-level language code has been examined for possible performance improvements.

6.3 Transforming State Machines to Code State transition diagrams can be converted to executable code through the use of tables, “case” statements, and several other methods. Although one method may be more efficient than




77

another for any particular application, once the best method for the project application has been selected, that method should be standardized and used throughout the project. The use of one method will enhance readability of the program and provide a consistent correlation between the code and the design.

6.4 Function Calls and Macros The trade-off between the use of macros and functions is usually the same as the trade-off between speed and code size. Macros can execute faster since the call and return overhead of a function are not present, but each macro call essentially places a copy of the code in-line, which increases the size of the code. Macros also may be used to enhance the readability of the source code if used properly. Macro names should give an obvious clue to the function that the macro performs, and it should not be so complicated that it has functionality that goes beyond what is suggested by its name. Macros cannot be nested.

6.5 Variables The range, data type, and precision of all variables should be established as a part of the detailed design process. Variables should be checked when used to verify that they are within range, and data tests that show that the value is outside the allowed domain of the variable should cause an error condition to be established. The data may be reconstructed, if possible, or a system error triggered. Data checking is especially critical for safety-related variables.

6.5.1

Scope

Functions and variables should use the lowest scope required by the desired operation. A lower scope level results in a more restrictive access to the functions and variables by other system functions and reduced module coupling.

6.5.2

Global Data Versus Passed Arguments

Variables should be passed as argument parameters, unless the calling overhead becomes burdensome because of large amounts of data or multiple levels of function calls.



78


6.5.3

Magic Numbers, Literals, and Constants

The use of “magic numbers” within the executable source code is not recommended. Any constant or literal that is required should be defined with the mechanism of the compiler or assembler and placed in a standard area of the source file or in a header file, and the name is then used in the source code. The compiler or assembler may then use the name to interpret and replace it with the correct definition. The origin and intended usage of this type of definition should be well documented.

6.5.4

Initialized Versus Uninitialized Variables

It is recommended that all variables be initialized by the run-time code, because this is the safest method of insuring that the initial values are set correctly. Uninitialized variables may be used so long as the program start-up code has the ability to copy the correct initial values into all uninitialized variables. Initialization of variables is not allowed in any include files, because the file may be included in more than one executable source code file. Default initializations should not be used.

6.5.5

User-Defined Types

User-defined types should be used only to simplify high-level language source code. Defined types should not be used to create new data types that are simple redefinitions of intrinsic data types, unless the new type makes the source code easier to read and understand. User-defined types can be used to simplify complex declarations if the created type name is selected to suggest the properties of the object being declared.

6.6 Calling Conventions All functions should be written so that the interface to other functions in the system is as simple as possible, because the other functions could be written for an assembler or a high-level language compiler. A calling convention or interface definition should be established at the beginning of the project and maintained throughout the life of the product. Function input parameters may be obtained by reading global values, from CPU registers, or from the program stack. Depending on the language used, the names of these areas may be different or undefined. Methods of returning values should be consistent for all functions in the system, and the return value with the lowest possible scope should be used.




79

6.7 Side Effects Side effects are defined as processing or activities performed or results obtained that are secondary to the primary function of a program, subprogram, or operation. All functions have side effects, and care should be taken that all side effects are known and desired when writing a function. Undesired side effects could be caused by a register that was not preserved or a global variable that was changed unintentionally. Desired side effects are the reason for writing the function and may include changes to input parameters, global variables, or changes in hardware register contents. The possibility of undesired side effects may be reduced by using functions and variables with the smallest possible scope, by using functions to access variables, and by implementing other data-hiding techniques.

6.8 Defensive Programming 6.8.1

Selection Control Constructs

Selection control statements must provide processing for the unspecified default case.

6.8.2

Data Structures

Data structures should be checked to ensure that they are uncorrupted and being referenced correctly. In particular: 1. Arrays. Check array bounds. 2. First in/first out (FIFO) queues, last in/first out (LIFO) queues, and stacks. Check for overflow and underflow conditions. 3. Linked lists. Check that links are intact. 4. Records. Use and check for identifiers where appropriate.

6.8.3

Parameters

Function argument parameters should be checked to ensure that they are within limits on entry.



80


6.8.4

Entry and Exits

Each routine, function, or procedure should be limited to one entry point and one exit point.

6.8.5

Self-Modifying Code

Code that modifies itself or executes the stack is prohibited at all times.

6.8.6

Error Handling

It is preferable to write routines that return status and error codes, and when they are provided, the codes should be checked.

6.8.7

Logical Expressions

Logical expressions should be explicitly defined. For example, instead of using the construct “if (expression)”, use “if (expression = true).”

6.8.8

Conditional Assembly and Compilation

Conditional assembly and compilation may be used to turn code sections on and off. These sections should be clearly delineated, and the purpose for the conditional assembly or compilation should be documented.

6.8.9

Recursion

Recursive code should be used only if the language facilitates it, and it should not be simulated by the coder.

6.9 Portability When portability is an issue, macros should be used sparingly, since their evaluation and parameter conventions are not standard or portable. Macros and other non-portable code should be kept in a separate file and clearly documented.




81

6.10 Optimization Optimization is the application of techniques to improve system performance or to reduce the use of limited system resources. Optimization is a time-consuming process and, if improperly done, may occur at the expense of good design practice and portability.

6.10.1 Scope Optimization should only be done to meet system performance requirements or resource constraints, and it should be considered only after the system design is complete. Optimization to meet performance requirements should be delayed until measurements are made to identify performance issues.

6.10.2 Side Effects Optimization has varying levels of impact on maintainability and portability. The techniques with the lowest impact should be implemented first and followed, if necessary, by techniques with greater impact.

6.10.3 Low-Impact Optimization Techniques Techniques that have little or no impact on portability and maintainability include the following: •

Using compiler optimization options

•

Removing invariants from loops

•

Changing a control flow statement to an alternate form

•

Changing data types

•

Eliminating variables that hold only intermediate values

•

Moving code from interrupt service routines to program code

6.10.4 Moderate-Impact Optimization Techniques Techniques that have some impact on portability and maintainability include the following:



82


•

Converting high-level language to assembler

•

Converting subroutine calls to macros

•

Converting subroutine calls to in-line code

•

Combining two or more modules into a single module, even though it reduces cohesion and increases the size of the module beyond the recommended limit

6.10.5 Significant Impact Optimization Techniques Techniques that have significant impact on portability and maintainability include the following: •

Modifying code to use “GOTO” commands

•

Adding multiple returns to subroutines

•

Employing techniques that increase module coupling

6.11 Linking There are link options that can be set in order to make the task of debugging easier. For example, explicitly request a map file that includes a list of global symbols; create a cross-reference listing between source lines and addresses; and turn on the option for symbolic debug.

7.0 HARDWARE INTERFACE

This section provides a general guide for implementing the interface between the software and the hardware platform on which it will operate.The hardware interfaces should be defined during the requirements analysis and design phases and should be documented in the Interface Design Specification (IDS).




83

7.1 Input/Output (I/O) Interfacing Some other considerations need to be taken into account when interfacing to an I/O device.

7.1.1

I/O Classifications

I/O interfaces may be classified as human oriented, computer oriented, and external environment oriented. Human-oriented interfaces provide interfacing for external devices, such as switches, keyboards, lights, LEDs, alphanumeric displays, and LCD displays. Computeroriented interfaces provide interfacing for external devices, such as cassettes, cartridges, floppy disks, modems, remote communications, and printers. External-environment-oriented interfaces provide interfacing for devices such as analog-to-digital converters (ADC), digitalto-analog converters (DAC), relays, sensors, and stepping motors.

7.1.2

I/O Interface Timing

Resolve any differences that may exist regarding the timing between the processor and the peripheral device. In the case where some peripheral device demands immediate attention, the interface may need to produce interrupt signals to force the processor to react quickly.

7.1.3

Data Conversions

Convert the format of the data produced by the processor to the format necessary for the peripheral immediately before the peripheral interface. Convert the format of the data produced by the peripheral to the format necessary for the processor immediately after the peripheral interface.

7.1.4

Buffered I/O

All I/O should be buffered to reduce communication overhead, maintain a consistent response time, and provide appropriate I/O error checking and error recovery.

7.1.5

I/O Port Names

All I/O ports should be addressed with descriptive names.



84


7.2 Interrupts Interrupt handling routines should save the state of the interrupted program, service the interrupt, restore the state of the interrupted program, and return.

7.3 Initialization Hardware should be explicitly set to the initial state or verified to be in the correct initial state.

8.0 SOFTWARE REPORTING PRACTICES

8.1 Bug, Error, and Anomaly Reporting The reporting and documenting of coding bugs and errors is accomplished through the use of the Software Anomaly Report.

8.1.1


Problem reporting is initiated by the software engineer(s) with a Software Anomaly Report, which identifies problems detected during software development activities. The specific information required on an anomaly report identifies how, when, and where the problem occurred and the impact of the problem on the system capability and on the continued conduct of V&V phase activities. Appendix C shows an example of the anomaly report and the instructions for completing the report.

8.1.2


The software V&V lead engineer is responsible for ensuring the proper documentation and reporting of Software Anomaly Reports, and all anomalies are reported regardless of the perceived impact on software development or severity level with respect to the system operation. Unreported and unresolved problems can have a significant adverse impact in the later stages of the software development cycle, which may include little time for resolution.




85

The projected impact of an anomaly is determined by evaluating the severity of its effect on the operation of the system. The severity of an anomaly report is defined as one of the following: •

High. The change is required to correct a condition that prevents or seriously degrades a system objective and no alternative exists or to correct a safety-related problem.

•

Medium. The change is required to correct a condition that degrades a system objective, to provide for performance improvement, or to confirm that the user and system requirements can be met.

•

Low. The change is desirable to maintain the system, correct operator inconvenience, or other.

Resolution of the critical anomaly indicated as a severity of “high” is required before the development effort proceeds to the next software development phase. Software Anomaly Reports are reviewed by the software lead engineer for anomaly validity, type, and severity, and the software lead engineer can direct additional investigation if required to assess the validity of the anomaly or the proposed solution. When an anomaly solution is approved and the personnel responsible for performing the corrective action are indicated, the software lead engineer will authorize implementation of the corrective action. The software V&V lead engineer is responsible for anomaly report closure, which includes documenting that the corrective action(s) have been taken and verifying the incorporation of authorized changes as described in the anomaly report. If the anomaly requires a change to a baselined configuration item, a Change Request/Approval (CRA) is prepared by a member of the software development team for the item(s) to be changed. A reference to applicable anomaly reports will be documented in the issued CRA.

8.2 Software Deviation or Waiver Circumstances may require deviation(s) or waiver(s) from policy. A written request for a deviation is generated by the software lead engineer in advance of a future activity, event, or product in order that SE management be made aware of the project’s intention to employ a higher risk development approach. A written request for a waiver is generated by the software lead engineer in those cases where the activity, event, or product has already been initiated. The deviations or waivers are submitted to the [project title/position] for review, and a recommendation is made to the [title/position] and/or [title/position] for approval or disapproval of the proposed deviation or waiver.



86


A proposed deviation or waiver must be approved by the [title/position] and/or [title/position] before commencing on the software development tasks affected by that deviation or waiver. A copy of each approved deviation or waiver shall be forwarded to the secretary of the Software Development Policy CCB. A copy shall also be placed in the product history file. A permanent record of deviation and waiver approvals shall be maintained for each project in the form depicted in Appendix D. Each request for a deviation or waiver identifies the following: •

Each specific policy or policy requirement for which it applies

•

The alternative policy approach to be taken by the project

•

The impact on project schedule, performance, and/or risk

This record shall be initiated during development of the Product Objectives Document and shall serve as a record of all subject approvals for the duration of the project.




APPENDIX A:

87

ASSEMBLY LANGUAGE PROGRAMMING GUIDELINES

A.1 Introduction This appendix covers those topics not discussed above that are specific to the assembly language programming.

A.2 Commenting Conventions A.2.1 Looping Constructs The do-while construct is bracketed by comment lines “DO WHILE” and “END WHILE.” The do-until construct is bracketed by comment lines “DO” and “END DO.” Within the dountil construct, the “UNTIL” condition comment line is placed above the conditional check. The executable code within the loop should be indented to aid in readability.

A.2.2 Case Constructs The if-else and if-then-else constructs are bracketed by comment lines “IF” and “END IF.” Place the “THEN” condition comment line after the conditional check. If there is an else part, place the “ELSE” condition comment line after the body of the if part. All executable code within the construct should be indented.

A.2.3 Multiple Case Constructs This construct is bracketed by comment lines “CASE” and “END CASE.” Place the “IF” condition comment line above the first check point and “ELSE IF” condition comment line above each remaining check point. Place the “THEN” condition comment line below each check point. All executable code within the construct should be indented.



88


A.3 Directives The following suggestions should be followed concerning the use of directives: •

Don’t make the assembly process of the program dependent upon unique directives.

•

If string definitions and substitutions are allowed, then ASSIGNing string substitutions allows easy redefinition if assemblers are changed.

•

Reduce the number of embedded directives and list the general directives, collected as a block.

•

Use, as an include or file, this list of general directives as they apply across all program modules.

•

All directives should have the same invocation from within the same program.

A.4 Operations A.4.1 Registers Use register operands when needed for speed; the instruction cycle time is reduced since a memory fetch for the operand is not required. Certain registers in the microprocessor may have a unique feature such as accumulator, memory addressing, counting, indexing, and status control.

A.4.2 Constants A constant may be explicitly defined in memory and referenced by its label. A certain data area should be set aside for constants so as to prevent inadvertent destruction. If the microprocessor supports immediate addressing, the constant may become part of the instruction. When using this method, the constant should be associated with a descriptive symbolic label via an assembler directive.




89

A.4.3 Expressions An assembler may allow the use of constant expressions as operands. The level of expression evaluation will be assembler specific but may allow use of nested parentheses and/or arithmetic, logical, relational, and memory operators.

A.5 Instruction Set Care should be exercised when using the instruction set of a specific assembler. Consistent programming techniques can enhance readability and maintainability of assembler code. Use arithmetic opcodes for arithmetic operations and logical opcodes for logical operations. Use the same register each time a loop counter is required, and be consistent with methods of loop control. In addition to performance improvement, the programmer should use hardware math functions if available and shift operations for powers of 2 multiplication and division. The use of the smallest form of call or jump will enhance both size and speed, but be certain that the use is consistent with the rest of the modules in the program. Avoid creating macros that look like assembler mnemonics. Use the most common mnemonics and avoid vendor-specific mnemonics.

A.6 Interfacing with High-Level Languages A calling convention or interface definition should be established at the beginning of the project and maintained throughout the life of the product. It will usually be strongly influenced by the high-level language being used. The following sections contain information that should be defined as part of the calling convention.

A.6.1 Parameter Passing Function input parameters may be obtained by reading global values, from CPU registers or from the program stack. Depending on the high-level language used, the names of these areas may be different or undefined.

A.6.2 Global Variables Reading global variables is straightforward as long as the calling and called functions are consistent in the way the variable is used and the way in which it is stored. The calling function



90


must set the global variables and then do a call to the desired sub-function. The called subfunction will then simply read the global data and process it, possibly placing results in another global data area or overwriting the input data area.

A.6.3 Usage, Storage, and Variable Naming Some high-level languages add a prefix or change the variable name in some way, and the names must be arranged so that they will match after the high-level language compiler and the low level language assembler have processed their respective source code. The responsibility for conforming to the name format is usually placed on the low-level language, so the low-level language names will probably need to be adjusted to conform to the high-level language format. When a low-level language function is called from another low-level language function or a high-level language function is called by a low-level language function, the same requirements of consistent usage, storage, and variable naming must also be followed.

A.6.4 Register Variables Reading register variables is easy to do, but high-level languages may not be able to load the registers easily. High-level languages that do have the ability to load registers may be less efficient than they are when using other methods of parameter passing. Care should be exercised when choosing this method of parameter passing, since high-level language compilers usually have restrictions on which registers may be changed. Passing parameters in registers can be very easy and very fast when a low-level language function is called from another low-level language function. However, if the low-level language function is also called from a high-level language or the low-level language function calls a high-level language function, the use of register-passed parameters will cause the lowered efficiency described above. It may not be possible to directly call a high-level language function with register-passed parameters because that method may not be supported by the high-level language compiler.

A.6.5 Stack Variables For high-level languages that support a program stack, variables may be passed on the stack. Some high-level languages manipulate the stack and variables placed on the stack. Low-level language functions that receive parameters on the stack must reference these variables by using the stack pointer or its equivalent and an offset to the correct position on the stack. The offset will be the same for any variable on the stack for any call that uses an identical calling sequence. Each high-level language call to the low-level language assembler function must have the same number, order, and size variables, since these factors affect the offset of every variable on the stack. Also affecting the offset is the size of the return address.When a low-level




91

language function is called from another low-level language function or a high-level language function is called from a low-level language function, the same requirements of consistent usage, storage, and variable naming must be followed. The calling function must place the parameters on the stack and then call the desired sub-function, which will reference and process the input data from the stack.

A.6.6 Preserving Registers Some high-level languages have restrictions on which registers may be changed or which registers must be preserved. All registers that are changed should be saved and restored by the called function unless one of the following conditions applies: •

The high-level language defines a register as a return value storage location.

•

The high-level language does not require the register to be saved, and a time constraint is in effect for the assembler function. This may be the case for an interrupt service routine but requires careful consideration.

•

A low-level language is calling a high-level language that does not require all registers to be preserved. The low-level language interface must be aware of which registers may be changed by the high-level language and preserve appropriate registers before calling the high-level language.

A.6.7 Returning Values Methods of returning values should be consistent for all functions in the system. Any high-level languages in use will affect the location of the return value. Return values can be passed back to the calling program as a changed global variable, memory location, or register. If a global is used as an input parameter, it may be changed and used as an output parameter. Some highlevel languages use a fixed set of registers as the return value storage area. Any low-level language functions should follow this convention if the function is to be called from the high-level language and should expect return values in those registers if high-level language functions are called from low-level language functions. The return value with the lowest possible scope should be used.



92


APPENDIX B

C PROGRAMMING GUIDELINES

B.1 Introduction This appendix covers those topics not discussed above and that are specific to the C programming language.

B.2 Scope A source file is the principal administrative unit of code written in the C language, and it is a key element in the C language scoping rules, allowing data and function “hiding.” Since a file may be made up of one or more related C functions, it is important that there be a file prologue distinct from each function prologue. If an operating system task main function is defined within a file, then certain additional elements are required in the prologue.

B.3 Braces In C language control structures, each opening and closing brace should appear on a line of its own and should be indented to the same tab position as the code enclosed in the braces. Braces should be used around the body of all for, if, while, switch, and do-while conditional statements to prevent errors when code is modified. In data structures, left and right braces should be vertically aligned.

B.4 Naming Conventions The ANSI standard for naming conventions should be followed.

B.5 Constants All manifest and enumeration constants should be defined with uppercase names either in the file where used or in a header file when used in more than one file. A set of useful manifest constants, such as YES and NO, should be provided in a project header file or taken directly




93

from standard header files. Multicharacter constants, such as \r\f, should be avoided because of the non-portability of machine byte order and probable maintenance difficulties. If enumeration constants are utilized as array indices, then this usage should be thoroughly commented where the enumeration constants are defined.

B.6 Variables Variables should be defined with all lowercase names and be distinct within the first 31 characters. Only one variable should be declared per source line, and a comment should be provided to explain the purpose of the variable.

B.7 Data Conversion Pointers should be explicitly declared with the correct pointer type. Pointer conversions should be limited to the following: •

Assignment of the NULL pointer

•

Assignment of an allocation function

•

Conversion of a general pointer to a pointer to void, or pointer to character and back again

B.8 TypeDefs TypeDefs should be used in the tag definitions of structures, unions, and enumerations. This provides cleaner and shorter declarations and, in some cases, may produce better diagnostics in the case of syntax errors. TypeDefs should be consistently uppercase or lowercase throughout the project. Tag definitions should be separated from variable declarations. Unions should not be used to transfer data from one type to another because of portability considerations.

B.9 Defined Types The basic data types of char, short, and others should be used instead of artificially defined types, but this does not prevent the use of enumerated types, such as BOOL. The exception



94


might be in cases where portability is an issue, as with an operating system or communications library. If metatypes are necessary, they should all be defined in a header file. Preprocessor conditionals should be used in conjunction with the header definitions to minimize portability problems.

B.10 Defensive Programming B.10.1 Spaces Around Operators Readability of the code is enhanced by a uniform layout of the operators. Spaces are related to precedence, because spaces imply a looser binding than the absence of spaces. An improper or non-uniform use of spaces may convey a different meaning to an expression than was intended. Operators are categorized into the following groups: •

High Precedence. These operators include the primary operators of [], (), ., and -> and unary operators of -, ++, —, !, ~, *, &, (type), and sizeof.

•

Medium Precedence. These operators include the arithmetic operators +, -, / and *, bitwise operators , &, ^, and |, logical operators && and ||, and relational operators =.

•

Low Precedence. These operators include the conditional operators ? and :, assignment operators =, +=, -=, /=, *=, &=, ^=, |=, =, and %= and the comma operator.

The high-precedence operators should never have space around them. The low-precedence operators should always have space around them, and the medium-precedence operators should usually have space around them. An exception to the rule for the primary operator () is the keywords if, while, for, switch, and return, which should be followed by a space.

B.10.2 Evaluation Order Code that depends on the order of evaluation may perform differently with different tools, so programs should not depend upon the order of evaluation of expressions.




95

B.10.3 Bitwise Operators and Parentheses The bitwise operators &, |, ~, ^, >>, and

Software Quality Assurance SOPs for Healthcare Manufacturers, Second Edition

Agile Software Development Quality Assurance

Handbook of Software Quality Assurance

Agile Software Development Quality Assurance

Quality Assurance in Dialysis, Second Edition

Software Development and Quality Assurance for the Healthcare Manufacturing Industries, Third edition

Quality Assurance

Model-Driven Software Development: Integrating Quality Assurance

Handbook of Software Quality Assurance, 4th ed

Handbook of Software Quality Assurance, 4th ed

Computational Intelligence in Software Quality Assurance

Quality Assurance for Environmental Analysis

Quality Assurance for Environmental Analysis

Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement

Testing and quality assurance for component-based software

Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement

Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement

Quality Assurance in Analytical Chemistry: Training and Teaching - Second edition

Power Transformers Quality Assurance

Healthcare Strategic Planning, Second Edition

Handbook of SOPs for Good Clinical Practice, Second Edition

Total quality assurance for the food industries 3rd Edition

Process Quality Assurance for UML-Based Projects

Total quality assurance for the food industries 3rd Edition

Model-Driven Software Development: Integrating Quality Assurance (Premier Reference Source)

Model-Driven Software Development: Integrating Quality Assurance (Premier Reference Source)

Mastering Software Quality Assurance: Best Practices, Tools and Technique for Software Developers

Model-Driven Software Development: Integrating Quality Assurance (Premier Reference Source)

Software Testing and Quality Assurance: Theory and Practice

Software Testing and Quality Assurance Theory and Practice

Dairy Processing and Quality Assurance

Software Quality Assurance SOPs for Healthcare Manufacturers, Second Edition

Agile Software Development Quality Assurance

Handbook of Software Quality Assurance

Agile Software Development Quality Assurance

Quality Assurance in Dialysis, Second Edition

Software Development and Quality Assurance for the Healthcare Manufacturing Industries, Third edition

Quality Assurance

Model-Driven Software Development: Integrating Quality Assurance

Handbook of Software Quality Assurance, 4th ed

Handbook of Software Quality Assurance, 4th ed

Computational Intelligence in Software Quality Assurance

Quality Assurance for Environmental Analysis

Quality Assurance for Environmental Analysis

Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement

Testing and quality assurance for component-based software

Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement

Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement

Quality Assurance in Analytical Chemistry: Training and Teaching - Second edition

Power Transformers Quality Assurance

Healthcare Strategic Planning, Second Edition

Handbook of SOPs for Good Clinical Practice, Second Edition

Total quality assurance for the food industries 3rd Edition

Process Quality Assurance for UML-Based Projects

Total quality assurance for the food industries 3rd Edition

Model-Driven Software Development: Integrating Quality Assurance (Premier Reference Source)

Model-Driven Software Development: Integrating Quality Assurance (Premier Reference Source)

Mastering Software Quality Assurance: Best Practices, Tools and Technique for Software Developers

Model-Driven Software Development: Integrating Quality Assurance (Premier Reference Source)

Software Testing and Quality Assurance: Theory and Practice

Software Testing and Quality Assurance Theory and Practice

Dairy Processing and Quality Assurance

Recommend Documents