SOFTWARE QUALITY ASSURANCE PLAN TEMPLATE

(BASED ON ANSI/IEEE STD 730.1-1989)

1.0 1.1 1.2 1.3 1.4 2.0 3.0

..................................................................................................... ................................................................ INTRODUCTION ..................................................................................................... 1 PURPOSE ............................................................................................................... 1 SCOPE ................................................................................................................... 1 SOFTWARE ITEMS.................................................................................................... 1 SOFTWARE LIFE CYCLE ............................................................................................ 2 DOCUMENTS ................................................................ ..................................................... REFERENCE DOCUMENTS ..................................................................................... 2 ....................................................................................................... ................................................................ MANAGEMENT ....................................................................................................... 5

3.1 ORGANIZATION ....................................................................................................... 5 3.1.1 Organizational Structure ................................................................................. 5 3.1.2 Organizational Description .............................................................................. 5 3.1.3 Organizational Independence.......................................................................... 6 3.2 TASKS ................................................................................................................... 6 3.2.1 Software Life Cycle ......................................................................................... 6 3.2.2 SQA Activities.................................................................................................. 8 3.2.3 Milestones...................................................................................................... 10 3.3 RESPONSIBILITIES ................................................................................................. 12 3.3.1 Software Activities ........................................................................................ 12 3.3.2 Software Work Products................................................................................ 12 3.3.3 Walkthroughs Software Work Products ........................................................ 13 3.3.4 Inspections of Software Work Products........................................................ 13 4.0 ................................................................ ............................................................... DOCUMENTATION ............................................................................................... 14

4.1 PURPOSE ............................................................................................................. 14 4.2 MINIMUM DOCUMENTATION REQUIREMENTS ............................................................. 14 4.2.1 Software Requirements Document (SRD) ..................................................... 14 4.2.2 Software Architecture Description (SAD) ..................................................... 16 4.2.3 Software Verification and Validation Plan (SVVP)........................................ 16 4.2.4 Software Verification and Validation Report (SVVR).................................... 18 4.2.5 User Documentation Description (UDD)........................................................ 19 4.2.6 Software Configuration Management Plan (SCMP)....................................... 21 4.3 OTHER ................................................................................................................ 22 4.3.1 Software Project Plan (SPP) .......................................................................... 22 4.3.2 System Requirements Specification (SRS) ................................................... 24 4.3.3 System Architecture and Requirements Allocation Description (SARAD) ... 25 4.3.4 Database Design Description (DDD) .............................................................. 25 4.3.5 Software Interface Design Description (SIDD).............................................. 26 4.3.6 Test or Validation Plan (TVPL) ...................................................................... 26 4.3.7 Software Design Description (SDD)............................................................... 27 4.3.8 Test or Validation Procedures (TVPR) .......................................................... 27 4.3.9 Test or Validation Results Report (TVRR)..................................................... 28 4.3.10 Software Integration Plan (SOIP) ............................................................... 29 4.3.11 Software Integration Audit Report (SIAR).................................................. 29

- ii -

4.3.12 Software Installation Plan (SIP) ................................................................. 30 5.0 PRACTICES, STANDARDS, PRACTICES, CONVENTIONS, AND METRICS ................................ 31 AND

5.1 PURPOSE ............................................................................................................. 31 5.2 CONTENT ............................................................................................................. 31 5.2.1 Documentation Standards ............................................................................. 32 5.2.2 Logic Structure Standards ............................................................................ 32 5.2.3 Coding and Commentary Standards .............................................................. 35 5.2.4 Testing Standards and Practices .................................................................. 37 5.2.5 Software Process and Product Metrics......................................................... 39 6.0 REVIEWS AND AUDITS ........................................................................................ 40 AUDITS ........................................................................................ ................................

6.1 PURPOSE ............................................................................................................. 40 6.1.1 Technical and Managerial Reviews and Audits ............................................ 40 6.1.2 Accomplishing Reviews and Audits .............................................................. 41 6.1.3 Implementing and Verifying Reviews and Audits ......................................... 42 6.2 MINIMUM REQUIREMENTS ...................................................................................... 42 6.2.1 Software Requirements Review (SRR) .......................................................... 43 6.2.2 Software Preliminary Design Review (SPDR)................................................ 43 6.2.3 Software Critical Design Review (SCDR) ...................................................... 43 6.2.4 Software Verification and Validation Plan Review (SVVPR) ........................ 44 6.2.5 Functional Configuration Audit (FCA) ........................................................... 44 6.2.6 Physical Configuration Audit (PCA) ............................................................... 45 6.2.7 In-Process Audit ............................................................................................ 45 6.2.8 Managerial Review ........................................................................................ 46 6.2.9 Software Configuration Management Plan Review (SCMPR) ....................... 47 6.2.10 Post Mortem Review................................................................................... 47 6.3 OTHER ................................................................................................................ 48 6.3.1 System/Subsystem Requirements Review (SSRR)........................................ 48 6.3.2 System/Subsystem Design Review (SSDR) ................................................... 48 6.3.3 Software Test Readiness Review (SOTRR)................................................... 49 6.3.4 Software Test Results Review (SOTRER) ..................................................... 49 6.3.5 System Test Readiness Review (SYTRR)...................................................... 50 6.3.6 System Test Results Review (SYTRER) ........................................................ 50 6.3.7 Software Usability Review (SUR) .................................................................. 50 6.3.8 Software Maintenance Review (SMR) ........................................................... 51 7.0 8.0 9.0 TEST..................................................................................................................... TEST..................................................................................................................... 51 ................................................................................................ REPORTING ACTION............................................ ION................................ PROBLEM REPORTING AND CORRECTIVE ACTION............................................ 52 TECHNIQUES, METHODOLOGIES................................ ................................................... TOOLS, TECHNIQUES, AND METHODOLOGIES................................................... 52

................................................................................................... 10.0 CODE CONTROL................................................................................................... 54 CONTROL ................................................................................................ ................................................................................................. ................................................................ 11.0 MEDIA CONTROL ................................................................................................. 54

- iii -

....................................................... ... 15.................................. 14................................................................ 55 COLLECTION... AND RETENTION ............................CONTROL ........iv - ......................................... ....0 SUPPLIER CONTROL ............ ......................................................................................................................... 56 .............................0 TRAINING ...................................... AND 13........................................................................................... 12.......................................................................................................................0 TRAINING.................... 56 ......0 RECORDS COLLECTION................................... MAINTENANCE..................................0 RISK MANAGEMENT ................................... 56 14....

the data acquisition CSCI. tasks. 1. The scope of the SQAP also includes identification of software tests not included in the SVVP. Specifically. In addition. and data processing CSCI. 1. and postprocessing of real-time telemetry data from specialized data measurement equipment. • Operating System CSCI: The operating system CSCI provides the integrating framework for the other three CSCIs. and data processing CSCI of the command and control system. Finally. 1. The operating system CSCI provides key integrating functions such as the human-computer user interface. and identification of reviews and audits. and identification of tools. status messaging and logging. maintenance. The command and control system enables the high-speed collection. techniques. practices. It shall list the name(s) of the software items covered by the SQAP and the intended use of the software. supplier control. media control.0 INTRODUCTION This section shall delineate the specific purpose and scope of the particular SQAP. identification of standards. the scope of the SQAP includes identification of SQA training requirements and the risk management methods and procedures to be used by the software project manager. and responsibilities. and methodologies for SQA. caution and warning. data management CSCI. identification of practices and procedures for problem reporting and corrective action. and records collection.3 Software Items The software items covered by the SQAP include the operating system CSCI. It shall state the portion of the software life cycle covered by the SQAP for each software item specified. and retention policies and procedures from software configuration management. storage.1 Purpose The purpose of the SQAP is to define a planned and systematic pattern of all actions necessary to provide adequate confidence that a software work product conforms to established technical requirements. and metrics for software developers and how SQA verifies them. conventions. the scope of the SQAP includes identification of the code control.1. data management CSCI.2 Scope The scope of the SQAP includes definition of the SQA organization. -1- . identification of minimum documentation requirements for software developers and how SQA verifies them. data acquisition CSCI. the SQAP defines a set of activities designed to evaluate the software processes by which software work products are developed and/or maintained.

software integration.0 REFERENCE DOCUMENTS This section shall provide a complete list of documents referenced elsewhere in the text of the SQAP. standards. and automated interfaces to the data processing CSCI and operating system CSCI. shutdown. media control. system architectural design. • Data Processing CSCI: The data processing CSCI provides key functions such as real-time and non-real-time data processing. tools. shutdown. data-rate detection. initialization. software detailed design. and retrieval. documentation. initialization. system initialization. and methodologies. and retention. built-in-test. The management. automatic data-size detection. 1. • Data Acquisition CSCI: The data acquisition CSCI provides key functions such as a real-time interface to the specialized data measurement equipment. high-speed data reduction and analysis. the software life cycle is a collection of interrelated activities or software processes for managing and developing software-based products and services. built-in-test. practices. software coding and testing. data-size configuration. built-in-test. datarate configuration. reviews and audits. More specifically.4 Software Life Cycle The software life cycle to which the SQAP applies for all CSCIs is defined by IEEE 12207. The software life cycle phases to which the SQAP applies include system requirements analysis. automatic data-size detection. archiving. The SQAP in its entirety applies to the command and control system and its four CSCIs. high-speed data collection. high-speed data storage. special test scenario execution. training. automatic data-rate detection. supplier control. test. • Data Management CSCI: The data management CSCI provides key functions such as a realtime interface to the data acquisition CSCI. and an automated command interface to the data management CSCI and operating system CSCI.automatic command and control system execution. initialization. system integration. and software acceptance support. techniques. manual control. problem reporting and corrective action. code control. and automated interfaces to the data management CSCI and operating system CSCI. software qualification testing. and metrics. conventions. 2. -2- . The software life cycle is the period of time that begins when a software product is conceived and ends when the software is no longer available for use. software installation. system qualification testing. maintenance. shutdown. system startup and shutdown. software architectural design. records collection. and risk management requirements of the SQAP apply to the command and control system software. and system debugging. software requirements analysis.

software technical reviews. which serve as controlling documents for managing software projects.1-1987 (IEEE Standard for Software Project Management Plans): The purpose of this standard is to prescribe the format and content of software project management plans. • IEEE/EIA 12207. • ANSI/IEEE STD 1012-1986 (IEEE Standard for Software Verification and Validation Plans): This purpose of this standard is to provide uniform and minimum requirements for the format and content of SVVPs. • OMG Version 1. such as instructions for a particular position or task. programming -3- . and the IEEE Standard for Software Life Cycle Processes. the review. program structure. a group of related CSCIs.00. and suggest optional V&V tasks.0-1996 (IEEE Standard for Software Life Cycle Processes): The purpose of this standard is to provide uniform. the tracking and reporting of such changes. the IEEE Standard for Reviews and Audits. • ANSI/IEEE STD 1058. the IEEE Standard for Software Quality Assurance Plans.1-1989 (IEEE Standard for Software Quality Assurance Plans): The purpose of this standard is to provide uniform. define minimum V&V tasks. and the control of interface documenation and project supplier SCM. minimum acceptable requirements for preparation and content of Software Quality Assurance Plans (SQAPs).The reference documents which the SQAP is principally based upon consist of three documents. and control of changes. • SPC-94093-CMC Version 01. and software joint reviews. or a software system or subsystem. software products. the audits and reviews of the evolving software product. • ANSI/IEEE STD 1028-1988 (IEEE Standard for Software Reviews and Audits): The purpose of this standard is to provide definitions and uniform requirements for review and audit processes. readability. including requirements for source code presentation. • ANSI/IEEE STD 828-1990 (IEEE Standard for Software Configuration Management Plans): The purpose of this standard is to establish the minimum required contents of SCM plans and activities which include the identification and establishment of baselines. • ANSI/IEEE STD 730.10-October 1995 (Ada 95 Quality and Style: Guidelines for Professional Programmers): The purpose of this document is to provide software source code style and coding guidelines for the Ada 95 computer programming language.3-June 1999 (OMG Unified Modeling Language Specification): The purpose of this standard is to serve as a precise and self-consistent definition of UML semantics and notation. UML is a graphically and visually oriented diagramming standard for representing analytical models of software requirements and software designs. minimum acceptable requirements for software activities. software records. • DI-IPSC-81433-941205 (MIL-STD-498 Software User Manual Data Item Description): The purpose of this DID is to tell a hands-on software user how to install and use a CSCI. It may also cover a particular aspect of software operation. approval.

file organization. Revision 6. make. and database standards. declarations. using white space. Files include file naming conventions. compound statements.P. inline images. statements. including requirements for declaration standards. special considerations. portability. and interaction with C. types. H. to include broad classes of software measures..0. T... lint. 2000 (Visual Basic Style Guide): The purpose of this document is to provide software source code style and coding guidelines for the Visual Basic computer programming language. portability. • Patrick. declarations. naming conventions. Spencer. control and user interface standards. header file content. reusability object-oriented features. and Brader. and programming practices.. K. Wittington. Mitze. E. Miller..H. identifier naming conventions. J. 20-APR-99 (Sun Code Conventions for the Java Programming Language): The purpose of this document is to provide software source code style and coding guidelines for the Java computer programming language.A. guidelines for application. L.O. • Sun Microsystems.. character formatting. tables. Inc. statements. variables. • Cannon. 25-June-1990 (Indian Hill C Style and Coding Standards): The purpose of this document is to provide software source code style and coding guidelines for the C computer programming language. M. operators. white space.. Kirchhoff. including requirements for file organization. comments. ANSI C. including requirements for files. and fill-out forms. preprocessor. D. Inc. miscellaneous. Elliot. R.practices. macros. function declarations. Keppel.. naming conventions. Equipments. constants. and -4- . equipments. and practical examples.0b-October 2000 (PSM Practical Software and Systems Measurement: A Foundation for Objective Project Management): The purpose of this document is to introduce software process and product measurement guidelines for managing system and software projects. and improving performance.W. whitespace. linking. keyword reference. Prentice Hall. • Gabryelski. J. T..W. concurrency.. 1998 (W3C Style Guide for Online Hypertext): The purpose of this document is to provide software source code style and coding guidelines for the HTML computer programming language.W.M. L. and source file content. R. debugging. simple statements. file organization. indentation. W3C.. conditional compilation. 1997 (Wildfire C++ Programming Style: With Rationale): The purpose of this document is to provide software source code style and coding guidelines for the C++ computer programming language. functions. • BL. • MIL-STD-1521B-4 June 1985 (Military Standard for Technical Reviews and Audits for Systems. and project-dependent standards. Milner. including requirements for markup tags. Schan. including requirements for file names. N. • DoD and US Army Version 4.. Wildfire Communications. comments. and Computer Software): The purpose of this standard is to prescribe the requirements for the conduct of technical reviews and audits on systems.

such as the software quality assurance group.1 Organizational Structure The organizational structure to which the SQAP applies consists of software engineering. tasks. software test procedures. software testing. executing. and SQA which is responsible for evaluating the software engineering. and the software engineering process group. Organizational dependence or independence of the elements responsible for SQA from those responsible for software development and use shall be clearly described or depicted.1. and. • Software Engineering: Software engineering is the collection of individuals (both managers and technical staff) who have responsibility for software development and maintenance activities (i. 3. more specifically. 3. and has been designed to take advantage of current technological advancement and management procedures in conducting reviews and audits. 3. by the application of software test plans. -5- . and test) for a project.e. are not included in the software engineering group. This shall include a description of each major element of the organization together with the delegated responsibilities.0 MANAGEMENT This section shall describe organization. and evaluating CSCIs to ensure that they meets their software requirements. SCM which is responsible for controlling software baselines. exercising. and SCM processes. SCM. software testing which is responsible for evaluating the software.1 Organization This paragraph shall depict the organizational structure that influences and controls the quality of the software. requirements analysis..2 Organizational Description The organizational description to which the SQAP applies consists of software engineering which is responsible for software development. 3.computer software. Groups performing software-related work. code. design. the software configuration management group.1. software testing. • Software Testing: Software testing is a process of dynamically operating. and responsibilities. and test reports. SQA itself. software test designs. software test cases.

software architectural design. Primarily. The sequence of the tasks shall be indicated.1 Software Life Cycle The software life cycle phases to which the SQAP applies include system requirements analysis. and authority from software engineering in order to maintain independence. and integrity of SQA activities. schedule.1. for later use by system architectural design. system qualification testing. and especially SQA. (2) A set of activities designed to evaluate the process by which software work products are developed and/or maintained. 3. or the software engineering functional manager. software coding and testing. objectivity. SQA is not functionally subordinate to software engineering. for computer software configuration items (CSCI) of a system or segment of a system. responsibility.• SCM: SCM is a discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item.2. -6- . and thus maintains independent power. software engineering reports to a software project lead and the software engineering functional manager. the software project lead. functional organization. and verify compliance with specified requirements. 3.2 Tasks This paragraph shall describe (a) that portion of the software life cycle covered by the SQAP. software testing. • System Requirements Analysis Phase: System requirements analysis is the process of developing system-level requirements. software qualification testing. status. and reporting channels between software engineering. and software acceptance support. and (c) the relationships between these tasks and the planned major check-points. system integration. software requirements analysis. (b) the tasks to be performed with special emphasis on software quality assurance activities. 3. Furthermore. software integration. SCM. SQA does not report to the system project or program manager in order to further propagate the integrity of SQA independence and protect SQA software process evaluation activities and results from the cost. software installation. • SQA: SQA is defined as a (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that a software work product conforms to established technical requirements. control changes to those characteristics. quality.3 Organizational Independence The organizational independence of SQA consists of a mutually exclusive chain of authority. and delivery pressures of software projects. record and report change processing and implementation status. system architectural design. software detailed design.

(u)—updated • System Architectural Design Phase: System architectural design is the process of transforming the system-level requirements into an architectural design. for a system or segment of a system. including its operational and support environments. for a CSCI of a system or segment of a system.Software Activity System System Software Software Requirements Architectural Requirements Architectural Analysis Design Analysis Design Software Detailed Design Software Coding and Testing Software Integration Software Qualification Testing System Integration System Qualification Testing Software Installation Software Acceptance Support Software Product • SRS • SARAD SRD • UDD • DDD (p) SAD • SIDD (p) • TVPL • UDD (u) • • DDD (d) SDD • SIDD (d) • TVPL (u) • UDD (u) • • DDD (u) TVPL (u) • TVPR • UDD (u) • TVRR • • SOIP TVPR (u) • UDD (u) • TVRR • • UDD (u) SIAR • TVRR • • • • TVPR (u) TVRR • TVRR • SIP • TVRR Technical Review • Walkthru • Inspection • Walkthru • Inspection • Walkthru • Inspection • Walkthru • Inspection • Walkthru • Inspection • Walkthru • Inspection • Walkthru • Inspection • Walkthru • Inspection • Walkthru • Inspection • Walkthru • Inspection Software Record • SYRER • SYAER • SORER • SOAER • DDER EOCR SCTRER • SCR • • • SIER • • DER SCR • SQTER SCR SER • SQTARR • • • SIRR • SCR Joint Review System/ Subsystem Requirements Review System/ Subsystem Design Review Software Requirements Review Software Preliminary Design Review Software Critical Design Review Software Test Readiness Review Software Test Results Review System Test Readiness Review System Test Results Review Software Usability Review Software Maintenance Review PLAN (3) SIP SOIP TVPL Software Installation Plan Software Integration Plan Test or Validation Plan SPECIFICATION (1) SRS System Requirements Specification DESCRIPTION (7) DDD SAD SARAD SDD SIDD SRD UDD Database Design Description Software Architecture Description System Architecture and Requirements Allocation Description Software Design Description Software Interface Design Description Software Requirements Description User Documentation Description PROCEDURE (1) TVPR Test or Validation Procedures SIAR TVRR REPORT (2) Software Integration Audit Report Test or Validation Results Report RECORD (14) DDER DER EOCR SCR SCTRER SER SIER SIRR SOAER SORER SQTARR SQTER SYAER SYRER Detailed Design Evaluation Record Documentation Evaluation Record Executable Object Code Record Source Code Record Software Code and Test Results Evaluation Record System Evaluation Record Software Integration Evaluation Record Software Installation Results Record Software Architecture Evaluation Record Software Requirements Evaluation Record System Qualification Test Audit Results Record System Qualification Test Evaluation Record System Architecture Evaluation Record System Requirements Evaluation Record (p)—preliminary. for later use by software architectural design. (d)—detailed. • Software Architectural Design Phase: Software architectural design is the process of transforming software requirements into a top-level software design consisting of computer software components (CSC). • Software Requirements Analysis Phase: Software requirements analysis is the process of developing software requirements. -7- . for later use by software detailed design. for later use by software requirements analysis. for a CSCI of a system or segment of a system.

• Software Installation Phase: Software installation is the process of transporting and installing software associated with a system or a segment of a system from the development environment to the target environment. • Software Qualification Testing Phase: Software qualification testing is the process of dynamically evaluating computer software using test cases and test procedures based on CSCI-level software requirements. for later use by software integration. software detailed design. for a CSCI of a system or segment of a system. for later use by system qualification testing. using installation policies. including system requirements analysis. for a CSCI of a system or segment of a system. and test procedures. system architectural design. software requirements analysis. in order to determine to whether or not to accept the system from the developer. software -8- . for later use by system integration. for later use by software installation. using acceptance test plans. for later use by software acceptance support. • Software Integration Phase: Software integration is the process of combining and evaluating the CSUs that have been implemented and unit tested. • System Qualification Testing Phase: System qualification testing is the process of dynamically evaluating integrated CSCIs and HWCIs of a system or segment of a system. plans. • Software Acceptance Support Phase: Software acceptance support is the process of assisting customers and end-users dynamically evaluate a system or segment of a system. 3. for a CSCI of a system or segment of a system. software architectural design. There are SQA activities for each of the twelve software life cycle phases. for later use by software coding and unit testing. • System Integration Phase: System integration is the process of combining and evaluating CSCIs and HWCIs of a system or segment of a system. that have undergone individual software and hardware qualification testing. using test cases and test procedures based on system-level requirements.2 SQA Activities The SQA activities principally consist of auditing the software activities. and software records of the software life cycle phases for conformance to software process and software product standards. for later use by software qualification testing. and work instructions. • Software Coding and Testing Phase: Software coding and testing is the process of transforming the software detailed design—CSUs—into computer software. procedures. software products. test cases.2. for CSCIs of a system or segment of a system. technical reviews.• Software Detailed Design Phase: Software detailed design is the process of decomposing the software architectural design into an increasingly detailed hierarchy of computer software units (CSU).

UDD. SRD. walkthrough standard. TVPL. and UDD (u) for conformance to the software detailed design activity standard. SAD. walkthrough standard. SDD. and TVRR for conformance to the software coding and testing activity standard. walkthrough standard. SIDD (d). software installation. DDD (d). and UDD (u) document standards. TVPR. • Software Detailed Design Phase: The SQA activities for the software detailed design phase include auditing the software detailed design activities. SIDD (d). system integration. SDD. and inspections of the DDD (u). TVPR (u). TVPR. and inspection standard. UDD (u). and inspection standard. TVPL (u). SID (p). TVPL (u). UDD (u). and inspection standard. and inspection standard. DDD (p). SIDD (d). TVPL (u). software integration. SAD. • Software Coding and Testing Phase: The SQA activities for the software coding and testing phase include auditing the software coding and testing activities. TVPR. SAD. UDD (u). walkthroughs of the DDD (p). TVPL (u). SID (p). SIDD (d). TVPL. DDD (u). SID (p). UDD (u). and TVRR. UDD (u). SARAD document standard. SRD and UDD document standards. TVPL. walkthroughs of the SOIP. and TVRR document standards. SRS. TVPL (u). software qualification testing. and UDD (u) for conformance to the software architectural design activity standard. • Software Architectural Design Phase: The SQA activities for the software architectural design phase include auditing the software architectural design activities. SOIP. TVPR (u). and UDD (u) document standards. walkthroughs of the DDD (d). TVPL (u). and UDD (u). walkthroughs of the SARAD. • System Architectural Design Phase: The SQA activities for the system architectural design phase include auditing the system architectural design activities. and inspections of the DDD (p). walkthrough standard. SAD. DDD (p). and inspection standard. TVPL (u). walkthroughs of the DDD (u). walkthrough standard. TVPL (u). and inspection standard. walkthrough standard. SARAD. • Software Requirements Analysis Phase: The SQA activities for the software requirements analysis phase include auditing the software requirements analysis activities. and TVRR. -9- . SDD. and inspections of the SARAD for conformance to the system architectural design activity standard. SDD. DDD (d). and inspections of the SOIP. • Software Integration Phase: The SQA activities for the software integration phase include auditing the software integration activities. and inspections of the SRD and UDD for conformance to the software requirements analysis activity standard. and UDD (u). TVPR. system qualification testing. • System Requirements Analysis Phase: The SQA activities for the system requirements analysis phase include auditing the system requirements analysis activities. DDD (u). and UDD (u).coding and testing. and inspections of the SRS for conformance to the system requirements analysis activity standard. and inspections of the DDD (d). and software acceptance support. UDD (u). TVPL. and TVRR. and TVRR. walkthroughs of the SRS. SRS document standard. SID (p). and UDD (u). walkthroughs of the SRD and UDD.

and inspection standard. SRS walkthroughs. walkthrough standard. • Software Installation Phase: The SQA activities for the software installation phase include auditing the software installation activities. TVPR (u). software critical design review. walkthrough standard. UDD (u). system test readiness review. TVRR. which immediately follows the system requirements analysis phase. SIAR. • Software Qualification Testing Phase: The SQA activities for the software qualification testing phase include auditing the software qualification testing activities. software preliminary design review.TVPR (u). and inspection standard. SIAR. and the software maintenance review. software usability review. . 3. • Software Acceptance Support Phase: The SQA activities for the software acceptance support phase include auditing the software acceptance support activities. software test results review. SIAR. TVPR (u) and TVRR. and SRS inspections shall occur before SSRR commences. • System/Subsystem Requirements Review (SSRR): External review techniques include a system/subsystem requirements review (SSRR). walkthroughs of the TVPR (u) and TVRR. and inspections of the TVRR for conformance to the system integration activity standard. UDD (u). TVRR document standard. and inspections of the UDD (u). SIP. the SRS. TVRR document standard. and TVRR document standards. walkthrough standard. SOIP. walkthroughs of the UDD (u).10 - . UDD (u). and inspection standard. walkthroughs of the TVRR. walkthrough standard. and inspection standard. system test results review. SQA audits of system requirements analysis activities. SIAR. UDD (u). TVRR. walkthrough standard. and inspections of the TVPR (u) and TVRR for conformance to the system integration activity standard. and inspections of the TVRR for conformance to the system integration activity standard. software requirements review. • System Integration Phase: The SQA activities for the system integration phase include auditing the system integration activities. and TVRR. and inspection standard. and inspections of the SIP for conformance to the system integration activity standard. and inspection standard. system/subsystem design review. and TVRR document standards. • System Qualification Testing Phase: The SQA activities for the system qualification testing phase include auditing the system qualification testing activities. SIP document standard. walkthrough standard. TVPR (u) and TVRR document standards.3 Milestones The milestones which follow the SQA activities include the system/subsystem requirements review. and TVRR for conformance to the software qualification testing activity standard. walkthroughs of the SIP. walkthroughs of the TVRR.2. and TVRR. software test readiness review. and TVRR for conformance to the software integration activity standard.

UDD (u). SQA audits of software requirements analysis activities. SIAR. which immediately follows the software requirements analysis phase.• System/Subsystem Design Review (SSDR): External review techniques include a system/subsystem design review (SSDR). SQA audits of software detailed design activities.11 - . SID (p). SQA audits of software coding and testing activities and software integration activities. SAD. SQA audits of software qualification testing activities. which immediately follows the software architectural design phase. SRD and UDD walkthroughs. and UDD (u). SQA audits of system architectural design activities. and UDD (u) inspections shall occur before SPDR commences. TVPL (u). SID (p). SIAR. which is necessary to successfully conclude the system architectural design phase. SAD. UDD (u). and UDD (u). TVPL. and UDD (u) walkthroughs. and SRD and UDD inspections shall occur before SRR commences. TVRR. the DDD (d). TVPR (u) and TVRR walkthroughs. the SRD and UDD. and DDD (u). and DDD (p). • Software Requirements Review (SRR): External review techniques include a software requirements review (SRR). and TVRR walkthroughs. SAD. and SARAD inspections shall occur before SSDR commences. TVPL (u). TVPR. TVRR. and TVRR. TVRR. DDD (p). which immediately follows the system integration phase. SDD. SARAD walkthroughs. SDD. which immediately follows the software detailed design phase. DDD (u). the UDD (u). SOIP. SOIP. SIAR. TVPL. • Software Test Readiness Review (SOTRR): External review techniques include a software test readiness review (SOTRR). and UDD (u). the TVPR (u) and TVRR. • System Test Readiness Review (SYTRR): External review techniques include a SYTRR. TVPR. UDD (u). which immediately follows the software qualification testing phase. and TVPR (u) walkthroughs. • Software Critical Design Review (SCDR): External review techniques include a software critical design review (SCDR). SIDD (d). UDD (u). the DDD (p). • Software Preliminary Design Review (SPDR): External review techniques include a software preliminary design review (SPDR). and TVPR (u) inspections shall occur before SOTRR commences. SID (p). and TVPR (u) and TVRR inspections shall occur before SYTRR. SQA audits of software architectural design activities. TVPL (u). TVPL. DDD (d). SIDD (d). • Software Test Results Review (SOTRER): External review techniques include a software test results review (SOTRER). and DDD (d). and UDD (u) inspections shall occur before SCDR commences. SQA audits of system integration activities. TVPL (u). which immediately follows the software integration phase. SOIP. TVPL (u). SIDD (d). the DDD (u). . and UDD (u) walkthroughs. TVPL (u). and TVPR (u). SDD. and TVRR inspections shall occur before SOTRER. TVPR. the SARAD.

1 Software Activities The responsibilities of SQA shall include auditing the software activities for each of the twelve software life cycle phases for conformance to software activity standards. software integration. SQA shall audit the SRS resulting from the system requirements analysis activity. SQA audits of the software installation activities. SQA shall audit the software products.3 Responsibilities This paragraph shall identify the specific organizational elements responsible for each task. SQA audits of the system qualification testing activities. and TVRR inspections shall occur before SMR. system integration. The responsibilities of SQA shall include auditing the software processes and software products of the software life cycle for conformance to software process and software product standards. system qualification testing. TVRR walkthroughs. and SIP inspections shall occur before SUR. which include the software activities themselves. the SIP. software qualification testing. SQA audits of the software acceptance support activities. • Software Maintenance Review (SMR): External review techniques include a software usability review (SUR). 3.3.2 Software Work Products The responsibilities of SQA shall include auditing the software work products for each of the twelve software life cycle phases for conformance to software work product standards. SQA shall audit the software processes.3.12 - . which immediately follows the software installation phase. walkthroughs of the software work products. which immediately follows the software installation phase. software installation. the TVRR. which immediately follows the system qualification testing phase. TVRR walkthroughs. 3. SIP walkthroughs.• System Test Results Review (SYTRER): External review techniques include a system test results review (SYTRER). software requirements analysis. walkthrough standards. 3. and inspections of the software work products for conformance to software activity standards. system architectural design. and TVRR inspections shall occur before SYTRR. SQA shall audit the . which include each of the 31 software work products resulting from each of the twelve software activities for conformance to software work product standards. software coding and testing. • Software Usability Review (SUR): External review techniques include a software usability review (SUR). software architectural design. and software acceptance support activities. and inspection standards. the TVRR. software detailed design. SQA shall audit the system requirements analysis.

TVPL (u). SQA shall audit inspections of the DDD (d). and TVRR resulting from the software integration activity. and UDD (u) resulting from the software architectural design activity. SQA shall audit walkthroughs of the SARAD resulting from the system architectural design activity. SQA shall audit the DDD (p). SQA shall audit the SIP of the software installation activity. and UDD (u) resulting from the software architectural design activity. SQA shall audit walkthroughs of the DDD (d). And. TVPL. SQA shall audit inspections of the DDD (p).3 Walkthroughs Software Work Products The responsibilities of SQA shall include auditing walkthroughs of software work products for each of the twelve software life cycle phases for conformance to walkthrough standards.13 - . and TVRR resulting from the software integration activity. SIDD (d). UDD (u). And. TVPL. 3.3. SQA shall audit walkthroughs of the DDD (u). SQA shall audit the SOIP. SQA shall audit inspections of the SRS resulting from the system requirements analysis activity. SQA shall audit the DDD (d). SQA shall audit walkthroughs of the TVPR (u) and TVRR of the system integration activity. and UDD (u) resulting from the software architectural design activity. TVPL. SQA shall audit the TVRR of the software acceptance support activity. and UDD (u) resulting from the software detailed design activity. SQA shall audit walkthroughs of the SIP of the software installation activity. TVPR (u). UDD (u). SQA shall audit the SRD and UDD resulting from the software requirements analysis activity. TVPL (u). SQA shall audit the UDD (u). TVPL (u). SIDD (p). SAD. TVPR. SQA shall audit inspections of the SRD and UDD resulting from the software requirements analysis activity. SAD. TVPR (u). SIAR. SIDD (d). SQA shall audit walkthroughs of the UDD (u). SQA shall audit walkthroughs of the TVRR of the system qualification testing activity. SQA shall audit the DDD (u). TVPR. SQA shall audit inspections of the DDD (u). TVPL (u). TVPL (u). UDD (u). SQA shall audit inspections of the SARAD resulting from the system architectural design activity. SIAR. SQA shall audit the TVRR of the system qualification testing activity. UDD (u). and TVRR resulting . and TVRR resulting from the software coding and testing activity. SAD. TVPL (u). and UDD (u) resulting from the software detailed design activity. and TVRR resulting from the software qualification testing activity. UDD (u).4 Inspections of Software Work Products The responsibilities of SQA shall include auditing inspections of software work products for each of the twelve software life cycle phases for conformance to inspection standards. SQA shall audit walkthroughs of the SRD and UDD resulting from the software requirements analysis activity. TVPR. SDD. and TVRR resulting from the software qualification testing activity. SIDD (p). SDD.3. SDD. 3. SQA shall audit the TVRR of the software acceptance support activity. and TVRR resulting from the software coding and testing activity.SARAD resulting from the system architectural design activity. SQA shall audit walkthroughs of the DDD (p). SQA shall audit walkthroughs of the SRS resulting from the system requirements analysis activity. and UDD (u) resulting from the software detailed design activity. SIDD (p). SQA shall audit the TVPR (u) and TVRR of the system integration activity. SQA shall audit walkthroughs of the SOIP. SIDD (d).

(2) State how the documents are to be checked for adequacy. and TVRR resulting from the software qualification testing activity. analysis. for example.1 Software Requirements Document (SRD) The SRD shall clearly and precisely describe each of the essential requirements (functions. use. TVPR (u). the following documentation is required as a minimum: 4. verification and validation. 4. and maintenance of the software. SQA shall conduct an audit of the SRD to verify the following properties: . 4. SQA shall audit inspections of the UDD (u).2. inspection. SQA shall audit the TVRR of the software acceptance support activity. UDD (u). SQA shall audit inspections of the TVPR (u) and TVRR of the system integration activity. performances. The software requirements description is used as the basis for design and qualification testing of a software item. or test. And. and TVRR resulting from the software integration activity. This shall include the criteria and the identification of the review or audit by which the adequacy of each document shall be confirmed. SIAR. design constraints. with reference to Section 6 of the SQAP.2 Minimum Documentation Requirements To ensure that the implementation of the software satisfies requirements. and attributes) of the software and the external interfaces.1 DOCUMENTATION Purpose This section shall perform the following functions: (1) Identify the documentation governing the development. SQA shall audit inspections of the TVRR of the system qualification testing activity.from the software coding and testing activity. SQA shall audit inspections of the SIP of the software installation activity. The purpose of the software requirements description is to specify the requirements for a software item and the methods to be used to ensure that each requirement has been met.0 4.14 - . SQA shall audit inspections of the SOIP. demonstration. Each requirement shall be defined such that its achievement is capable of being objectively verified and validated by a prescribed method.

• Human-equipment interactions. • Environmental conditions. • Software quality characteristics. • Areas that need concentrated human attention and are sensitive to human errors and training. • Constraints on personnel.• Generic description information. • User operation and execution requirements. • Functionality of the software item. • Design and implementation constraints. including those related to compromise of sensitive information. • Safety specifications. • User documentation requirements. • Performance requirements. • Installation and acceptance requirements of the delivered software product at the maintenance site(s).15 - . • Manual operations. and personnel injury. including those related to methods of operation and maintenance. • Human-factors engineering (ergonomics) requirements. • System identification and overview. • Installation and acceptance requirements of the delivered software product at the operation site(s). . • Requirements for interfaces external to software item. • Data definition and database requirements. • Qualification requirements. including installation-dependent data for adaptation needs. • Physical characteristics. environmental influences. • User maintenance requirements. • Security and privacy specifications.

• Rationale.2. SQA shall conduct an audit of the SAD to verify the following properties: • Generic description information. inspection. The purpose of the software architecture description is to describe the software item-wide design decisions and the software item architectural design. • Packaging requirements. .• Computer resource requirements. • Software component concept of execution. • Software architecture general description. • Rationale for software architecture and component definition decisions. • Software component definition. including database and user interface design. including data bases and internal interfaces. The SAD shall be prepared first as the Preliminary SAD (also referred to as the Top-Level SAD) and shall be subsequently expanded to produce the Detailed SDD.2. 4.16 - . analysis. 4. • Software item architectural design. • System overview and identification. The SAD shall describe the components and subcomponents of the software design. • Precedence and criticality of requirements.2 Software Architecture Description (SAD) The SAD shall depict how the software will be structured to satisfy the requirements in the SRD. • Resource limitations and the strategy for managing each resource and its limitation. • Requirements traceability. • Identification of software requirements allocated to each software component.3 Software Verification and Validation Plan (SVVP) The SVVP shall identify and describe the methods (for example.

complies with the requirements expressed in the SRS. The purpose of the software verification and validation plan is to provide. and (c) the design expressed in the SDD is implemented in the code. • Referenced documents. or test) to be used: (1) To verify that (a) the requirements in the SRS have been approved by an appropriate authority. • Implementation phase V&V. uniform and minimum requirements for the format and content of SVVPs. • Test phase V&V. (b) the requirements in the SRS are implemented in the design expressed in the SDD. • Organization. • Requirements phase V&V. • Design phase V&V. specific minimum V&V tasks and their required inputs and outputs that shall be included in SVVPs. for both critical and non-critical software. techniques. . and suggest optional V&V tasks to be used to tailor SVVPs as appropriate for the particular V&V effort. • Concept phase V&V. define. • Responsibilities. • Tools.17 - . SQA shall conduct an audit of the SVVP to verify the following properties: • Purpose. • Resources summary. • Verification and validation overview. • Definitions. (2) To validate that the code.demonstration. • Life-cycle verification and validation. when executed. • Master schedule. • Management of V&V. for critical software. and methodologies.

• Summary of anomalies and resolution.• Installation and checkout phase V&V. • Anomaly reporting and resolution. • Summary of task results. and software acceptance support. software installation. . • Optional reports. system qualification testing. software detailed design. • Task iteration policy. 4.4 Software Verification and Validation Report (SVVR) The SVVR shall describe the results of the execution of the SVVP. practices. software integration. • Control procedures. system architectural design. • Required reports. system requirements analysis. software architectural design. • V&V phase summary report. SQA shall conduct an audit of the SVVR to verify the following properties: • Task reporting. • Standards.18 - . • Description of V&V tasks performed. • Interim results and status. system integration. • Verification and validation administrative procedures. • Operation and maintenance phase V&V. • Deviation policy. • Software verification and validation reporting. software qualification testing. software requirements analysis. software coding and testing. The purpose of the software verification and validation report is to summarize the results of V&V tasks performed in each of the software life cycle phases. and conventions.2.

guide. and other activities or items necessary for successful execution of the software. 4. program limitations.2. • Purpose and objectives.g. • Recommendations.5 User Documentation Description (UDD) User documentation (e. • Cause. • Criticality. • Summary of task results. • Impact. • Assessment of overall software quality. input sequences. • Software testing results.• Assessment of software quality. manual. • Approach.19 - . • Recomendations. • Software configuration management results. All error messages shall be identified and . • Software quality assurance results. • Special studies report. • Anomaly report. etc. • Description and location.. • Summary of all life-cycle V&V tasks. • Summary of anomalies and resolutions. • Summary. • Recommendations. • V&V final report. • Other reports. options.) shall specify and describe the required data and control inputs.

• Software organization and overview of operation. • Access control. • Equipment familiarization.20 - . • Software environment. • Document overview. A method of describing user-identified errors or problems to the developer or the owner of the software shall be described. • Contingencies and alternate states and modes of operation. • System overview. • Assistance and problem reporting. • Identification. • Initiating a session. • Software summary. • Referenced documents. • First-time user of the software. • Security and privacy. • Software inventory. (Embedded software that has no direct user interaction has no need for user documentation and is therefore exempted from this requirement. • Software application. SQA shall conduct an audit of the UDD to verify the following properties: • Scope. .) The purpose of the user documentation description is to record the planning and engineering information created during the development process that is of use to the users of the software product or service. • Access to the software.corrective actions described. • Installation and setup.

• Identifying configuration items. malfunctions. 4.2.6 Software Configuration Management Plan (SCMP) The SCMP shall document methods to be used for identifying software items. • (Aspect of software use). releases. support the software development and maintenance methodology that fits the software requirements. • Processing reference guide. and recording and reporting change implementation status. • Processing procedures. • Capabilities. SQA shall conduct an audit of the SCMP to verify the following properties: • Introduction. • Recovery from errors. • Messages. • Data backup.• Stopping and suspending work. • Configuration identification. policies. • Quick-reference guide. tests. • Appendices. The purpose of the software configuration management plan is to provide a structure for identifying and controlling software documentation. software source code. • Conventions. . and support production of management and product information concerning the status of software baselines. change control. and emergencies. controlling and implementing changes. • Notes. standards. and databases to support all software life cycle phases.21 - . and audits. • Related processing. • SCM management. organization and management philosophy. software interfaces.

1 Software Project Plan (SPP) The purpose of the software project plan is to serve as a controlling document for managing a software project. • Acquiring configuration items. 4. SQA shall conduct an audit of the SPP to verify the following properties: . • Implementing changes. • Configuration status accounting.22 - . 4. • Evaluating changes. • Configuration control.• Naming configuration items. • Interface control. A software project plan defines the technical and managerial project functions. • SCM schedules. • Configuration audits and reviews.3. • Requesting changes. • Approving or disapproving changes. and tasks necessary to satisfy the requirements of a software project. • SCM resources. • Subcontractor/vendor control.3 Other Other documentation may include the following: (1) Software Development Plan (2) Standards and Procedures Manual (3) Software Project Management Plan (4) Software Maintenance Manual. activities. as defined in the project agreement. • SCM plan maintenance.

• User involvement (i. reporting. budgets. software size. access to facilities). • Approval required by such means as regulations. requirements setting exercises. including test environment. tracking.e. library. acceptance. prototype demonstrations and evaluations). usage. privacy. cost.e. if any. and reporting. • Work breakdown structure of the life cycle processes and activities. joint reviews. the rules for need-to-know and access-to-information at each project organizational level). • Software life cycle model. including external organizations. • Training of personnel. • Management of safety. procedures. • Security policy (i. implementation. informal meetings. software services and non-deliverable items to be performed.. including the approach for interfacing with the verification and validation agent. • Verification and validation.. operation or maintenance. staffing. • Quality assurance. and schedule risks). equipment. physical resources. including the software products. required certifications. • Engineering environment (for development. audits. if specified. • Acquirer involvement (i. and schedules associated with the tasks.. and tools. approval.. ownership. • Project organizational structure showing authority and responsibility of each organizational unit. security. • Risk management (i. • Configuration management (separate plans for configuration management may be developed). and other critical requirements of the software products or services (separate plans for safety and security may be developed). as applicable). • Subcontractor management. • Management of the quality characteristics of the software products or services (separate plans for quality may be developed).• Generic plan information for managing the project. modification and change.23 - . standards. including subcontractor selection and involvement between the subcontractor and the acquirer. . facilities. proprietary. warranty and licensing rights.e. the management of the areas of the project that involve technical. • Means for scheduling.e.

2 System Requirements Specification (SRS) The purpose of the system requirements specification is to specify the requirements for a system or subsystem and the methods to be used to ensure that each requirement has been met. • System environmental requirements. • Business. • Personnel. • Computer communications requirements. • Computer resource requirements. and logistics requirements. • Operations and maintenance requirements. • System quality characteristics. including utilization requirements. • Safety. • Requirements for the functions and performance of the system. security. The system requirements specification is used as the basis for design and qualification testing of a system or subsystem. • Physical requirements. and user requirements. SQA shall conduct an audit of the SRS to verify the following properties: • Generic specification information. and privacy protection requirements. • System identification and overview. • Computer software requirements. • Installation-dependent data requirements. • Human-factors engineering (ergonomics) requirements.4. • Internal data requirements. organizational. training. • Required states and modes. • Computer hardware requirements.3. • System external interface requirements. • Design constraints and qualification requirements.24 - . . • Computer hardware resource requirements.

3. • Database overview and identification. SQA shall conduct an audit of the SARAD to verify the following properties: • Generic description information. • Precedence and criticality of requirements. • Hardware item identification. a collection of related data stored in one or more computerized files in a manner that can be accessed by users or computer programs via a database management system.3 System Architecture and Requirements Allocation Description (SARAD) The purpose of the system architecture and requirements allocation description is to describe the architectural design of a system or subsystem. conceptual. • Manual operations identification.g.• Packaging requirements. • Rationale for allocation of hardware items. 4. physical). • Reference to design description of software used for database access or manipulation.. 4.25 - . SQA shall conduct an audit of the DDD to verify the following properties: • Generic description information. that is. • Concept of execution. logical. • Rationale. including descriptions of applicable design levels (e. The database design description is used as the basis for implementing the database and related software units. internal.3. software items. • System overview and identification. and manual operations. .4 Database Design Description (DDD) The purpose of the database design description is to describe the design of a database. • Software item identification. • Design of the database. The database design description may also describe the software units used to access or manipulate the data.

and analysis. diagrams). hardware item. source language. or other system component. 4.26 - . • Data recording.3. software item. manual operation. reduction.. source language. • External-software item interface definition (e.5 Software Interface Design Description (SIDD) The purpose of the software interface design description is to describe the interface characteristics of one or more system. • Software unit identification. • Software component identification. subsystem. SQA shall conduct an audit of the SIDD to verify the following properties: • Generic description information.3. 4.g. . The software interface design description may describe any number of interfaces. The test or validation plan describes the software test environment to be used for the testing.6 Test or Validation Plan (TVPL) The purpose of the test or validation plan is to describe plans for qualification testing of software items and software systems.• Rationale for database design. diagrams).. • External interface identification.g. • Test classes. • Software item-software item interface definition (e. • Test progression. • Software component-software component interface definition (e. SQA shall conduct an audit of the TVPL to verify the following properties: • Generic plan information. • General test conditions. and provide schedules for test activities. identify the tests to be performed. source language. diagrams).. • Test levels.g.

3. including algorithms and data structures. • Requirements traceability. 4. • Qualification testing environment.27 - . • Software unit-level requirements traceability. The test or validation procedures enable the acquirer to assess the adequacy of the qualification testing to be performed. The software design description and the software architecture provide the detailed design needed to implement the software. and participating organizations. • Reuse element identification. including items and their identifiers. test cases. personnel.8 Test or Validation Procedures (TVPR) The purpose of the test or validation procedures is to describe the test preparations. SQA shall conduct an audit of the SDD to verify the following properties: • Generic description information. including data flow and control flow. and test procedures to be used to perform qualification testing of a software item or a software system or subsystem. • Rationale for software item design. • Planned tests.• Test coverage (breadth and depth) or other methods for assuring sufficiency of testing. • Requirements traceability. • Concept of execution. • Software component-level requirements traceability. 4. . • Static relationships of software units. • Software item input/output description. site.7 Software Design Description (SDD) The purpose of the software design description is to describe the design of a software item. • Description of how the software item satisfies the software requirements.3. • Test schedules. The software design description may be supplemented by software item interface design and database design.

requirements. other) for each test.3. The test or validation results report enables the acquirer to assess the testing and its results. or other software-related item. . • Prerequisite conditions. software. 4.9 Test or Validation Results Report (TVRR) The purpose of the test or validation results report is to provide a record of the qualification testing performed on a software item. a software system or subsystem. • Test objectives. • Test preparations (hardware.SQA shall conduct an audit of the TVPR to verify the following properties: • Test or Validation Procedures. and rationale. • Generic procedure information. • Overview of test results.28 - . • Test identifier. SQA shall conduct an audit of the TVRR to verify the following properties: • Generic report information. • Requirements traceability. • Rationale for decisions. • System identification and overview. • Identification of test author. • Instructions for conducting procedure. • Criteria for evaluating results. • Overall assessment of the software tested. • Expected test results. • Requirements addressed. • Test input. • Identification of test configuration. • Test descriptions.

4. • Test schedule. • Scope. • Test requirements. • Test data. 4.• Impact of test environment.3. • Test identifier. • Detailed test results. SQA shall conduct an audit of the SIAR to verify the following properties: • Date of issue and status. • Problems encountered. • Issuing organization. • Test responsibilities. • Test procedures. SQA shall conduct an audit of the SOIP to verify the following properties: • Generic plan information.11 Software Integration Audit Report (SIAR) The purpose of the software integration audit report is to describe the results of an independent audit of software qualification testing activities and work products. • Deviations from test cases/procedures. • Rationale for decisions. • Test summary. • Test log.3.29 - .10 Software Integration Plan (SOIP) The purpose of the software integration plan is to define the activities necessary to integrate the software units and software components into the software item. .

• Installation overview. SQA shall conduct an audit of the SIP to verify the following properties: • Scope. set initial parameters. • Summary. • Document overview. • Change history. • Message. • Context. • Identification. • Referenced documents. • Description. • Relationship to other plans. • Glossary. • Contact point.• References.12 Software Installation Plan (SIP) The purpose of the software installation plan is to describe the information necessary to install a system or component. 4. • Bibliography. • Introduction. • Conclusions and recommendations. . • Body. • System overview. • Contributors.3. and prepare the system or component for operational use.30 - . • Support materials.

• Installation procedures. • (Site name). CONVENTIONS. design. 5. • Schedule.2 Content The subjects covered shall include the basic technical. • Data update procedures. • Schedule. • Installation team. • Data update procedures. • Site-specific information for software center operations staff. • (Site name). • Tasks. and programming activities .1 STANDARDS. • Personnel. practices.0 5. • Security and privacy protection. • Facilities.• Training. conventions and metrics to be applied. • Installation procedures. • Site-specific information for software users. • Software inventory. 5.31 - . PRACTICES. AND METRICS Purpose This section shall: (1) Identify the standards. (2) State how compliance with these items is to be monitored and assured.

Perhaps a better name would be “static structural diagram” but “class diagram” is shorter and well established.2. TVRR. The individual class diagrams do not represent divisions in the underlying model. SDD. such as documentation. and testing. SIDD. Class diagrams may be organized into packages . SARAD. SRD. and even instances. SOIP. the SRS. collaboration diagram. component diagram. such as classes. the following information shall be provided: (1) Documentation standards (2) Logic structure standards (3) Coding standards (4) Commentary standards (5) Testing standards and practices (6) Selected software quality assurance product and process metrics such as: (a) Branch metric (b) Decision point metric (c) Domain metric (d) Error message metric (e) Requirements demonstration metric 5. IEEE Standard for Software Verification and Validation Plans. As a minimum. sequence diagram. Note that a “class” diagram may also contain interfaces.2. Only the following documentation standards from the IEEE Standard for Software Life Cycle Processes shall be enforced by the SQAP. relationships. packages. such as objects and links. and deployment diagram. The following nine UML logic structure diagrams shall be enforced by the SQAP. SAD. object diagram. variable and module naming. MIL-STD-498 Software User Manual Data Item Description.32 - . activity diagram. DDD. SIAR. A class diagram is a graphic view of the static structural model. A class diagram is a collection of (static) declarative model elements. connected as a graph to each other and to their contents. inspection. IEEE Standard for Software Configuration Management Plans. and their relationships. UDD. TVPL. and SIP.2 Logic Structure Standards The logic structure standard that shall be enforced by the SQAP is the OMG Unified Modeling Language. class diagram. TVPR. statechart diagram.1 Documentation Standards The documentation standards that shall be enforced by the SQAP are the IEEE Standard for Software Life Cycle Processes. interfaces. programming. and the IEEE Standard for Software Project Management Plans. use case diagram. 5. • Class Diagram: A class diagram is a graph of classifier elements connected by their various static relationships.involved.

(See subsequent sections for details of the contents of a sequence diagram.” The phrase is useful. Tools need not support a separate format for object diagrams.) • Collaboration Diagram: A collaboration diagram presents a collaboration. Classes have data structure and behavior and relationships to other elements. to characterize a particular usage achievable in various ways. which is a set of messages between classifier roles within a collaboration to effect a desired operation or result. A sequence diagram has two dimensions: 1) the vertical dimension represents time and 2) the horizontal dimension represents different objects. A use case is a kind of classifier representing a coherent unit of functionality provide by a system. • Sequence Diagram: A sequence diagram presents an interaction. so a class diagram with objects and no classes is an “object diagram. as well as their required relationships given in a particular context. the bottom list compartment holds a list of operations. Objects can be grouped into “swimlanes” on a diagram. a use case may also have compartments displaying attributes and operations. • Use Case Diagram: A use case diagram shows the relationship among actors and use cases within a system. if desired. and includes among the use cases. A static object diagram is an instance of a class diagram. The top name compartment holds a list of attributes. An optional stereotype keyword may be placed above the name and a list of properties included below the name. extends. it shows a snapshot of the detailed state of a system at a point in time. The use of object diagrams is fairly limited. which contains a set or roles to played by objects. however. The relationships are associations between the actors and the use cases. a set of use cases. The diagram may also present an interaction.) Usually only time sequences are important. As a classifier. Mainly to show examples of data structures. A use case is show as an ellipse containing the name of the use case. a subsystem. The use cases represent functionality of a system or a classifier. The use cases may optionally be enclosed by a rectangle that represents the boundary of the containing system or classifier. which defines a set of messages . The name of a class has scope within the package in which it is declared and the name must be unique (among class names) within its package. or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system. Normally time proceeds down the page. A class is drawn as a solid-outline rectangle with three compartments separated by horizontal lines. like a subsystems or a class. Class diagrams can contain objects. generalizations between the actors. but in real-time applications the time axis could be an actual metric.33 - . There is no significance to the horizontal ordering of the objects. • Object Diagram: An object diagram is a graph of instances. (The dimensions may be reversed. as manifested to external interactors with the system or the classifier. A class represents a concept within the system being modeled. an the relationships between these elements. possibly some interfaces. Use case diagrams show actors and use cases together with their relationships. and generalizations. including objects and data values. A use case diagram is a graph of actors.either with their underlying models or as separate packages that build upon the underlying model packages.

Use ordinary state diagrams in situations where asynchronous events occur. A collaboration diagram can be given in two different forms: at instance level or at specification level. or methods. actors. or show classifier roles. The entire activity diagram is attached (through the model) to a class. • Component Diagram: A component diagram shows the dependencies among software components. it is used for describing the behavior of classes. A collaboration which describes a classifier. and executable components. it may also include the communication stated by an interaction. and messages. States and various other types of vertices (pseudostates) in the state machine graph are rendered by appropriate state and pseudostate symbols. Use activity diagrams in situations where all or most of the events represent fhe completion of internally-generated actions (that is. but statecharts may also describe the behavior of other model entities such as use cases. States may also contain sub-diagrams by physical containment or tiling. and stimuli. Typically. A statechart diagram is a graph that represents a state machine. subsystems. A collaboration diagram shows a graph of either objects linked to each other. or to the implementation of an operation. as well as ordinary associations attached to the classifier owning the operation. including source code components. Specifically. For a business. or classifier roles and association roles. references classifiers and associations in general. operations invocations). some exist at link time. The purpose of this diagram is to focus on flows driven by internal processing (as opposed to external events). while a collaboration describing an operation includes the arguments and local variables of the operation. “software” components are taken in the broad sense to include business procedures and documents. procedural flow of control). it may either show instances. operations.. links.34 - . such as a use case. while transitions are generally rendered by directed arcs that interconnect them. It represents a state machine of a procedure itself. it describes possible sequences of states and actions through which the element can proceed during its lifetime as a result of reacting to discrete events (e. The graphical rendering of this top state is optional.specifying the interaction between the objects playing the roles within a collaboration to achieve the desired result. Some components exist at compile time. • Statechart Diagram: A statechart diagram can be used to describe the behavior of a model element such as an objet or an interaction. signals. association roles.g. Statechart diagrams represent the behavior of entities capable of dynamic behavior by specifying its response to the receipt of event instances. some exist at run . or to a package. An activity diagram is a special case of a state diagram in which all (or at least most) of the states are action or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or subactivities in the source states. binary code components. like a use case. A software module may be represented as a component stereotype. Note that every state machine has a top state which contains all the other elements of the entire state machine. A collaboration is used for describing the realization of an operation or a classifier. • Activity Diagram: An activity graph is a variation of a sate machine in which the states represent the performance of actions or subactivities and the transitions are triggered by the completion of the actions or subactivities.

time, and some exist at more than one time. A compile-only component is one that is only meaningful at compile time. The run-time component in this case would be an executable program. A component diagram has only a type form, not an instance form. To show component instances, use a deployment diagram (possibly a degenerate one without nodes). A component diagram is a graph of components connected by dependency relationships. Components may also be connected to components by physical containment representing composition relationships. A diagram containing component types and node types may be used to show static dependencies, such as compiler dependencies between programs, which are show as dashed arrows (dependencies) from a client component to a supplier component that it depends on in some way. The kinds of dependencies are implementation-specific and may be shown as stereotypes of the dependencies. As a classifier, a component may have operations and may realize interfaces. The diagram may show these interfaces and calling dependencies among components, using dashed arrows from components to interfaces on other components. • Deployment Diagram: Deployment diagrams show the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units. Components that do not exist as run-time entities (because they have been compiled away) do not appear on these diagrams, they should be show on component diagrams. For business modeling, the run-time processing elements include workers and organizational units, and the software components include procedures and documents used by the workers and organizational units. A deployment diagram is a graph of nodes connected by communication associations. Nodes may contain component instances. This indicates that the component lives or runs on the node. Components may contain objects, this indicates that the object resides on the component. Components are connected to other components by dashed-arrow dependencies (possible through interfaces). This indicates that one component uses the services of another component. A stereotype may be used to indicate the precise dependency, if needed. The deployment type diagram may also be used to show which components may reside on which nodes, by using dashed arrows with the stereotype support from the component symbol to the node symbol or by graphically nesting the component symbol within the node symbol. 5.2.3 Coding and Commentary Standards

The coding standards that shall be enforced by the SQAP include the SPC Ada 95 Quality and Style, Indian Hill C Style and Coding Standards, Wildfire C++ Programming Style, Visual Basic Style Guide, W3C Style Guide for Online Hypertext, and the Sun Code Conventions for the Java Programming Language. • SPC Ada 95 Quality and Style: The SPC Ada 95 Quality and Style includes requirements for source code presentation, readability, program structure, programming practices, concurrency, portability, reusability object-oriented features, and improving performance. Source code presentation includes code formatting. Readability includes spelling, naming conventions,

- 35 -

comments, and using types. Program structure includes high-level structure, visibility, and exceptions. Programming practices include optional parts of the syntax, parameter lists, types, data structures, expressions, statements, visibility, using exceptions, and erroneous execution and bounded errors. Concurrency includes concurrency options, communication, and termination. Portability includes fundamentals, numeric types and expressions, storage control, tasking, exceptions, representation clauses and implementation-dependent features, and input/output. Reusability includes understanding and clarity, robustness, adaptability, and independence. Object-oriented features include object-oriented design, tagged type hierarchies, tagged type operations, managing visibility, and multiple inheritance. Improving performance includes performance issues, performance measurement, program structure, data structures, algorithms, types, and pragmas. • Indian Hill C Style and Coding Standards: The Indian Hill C Style and Coding Standards include requirements for file organization, comments, declarations, function declarations, whitespace, simple statements, compound statements, operators, naming conventions, constants, macros, conditional compilation, debugging, portability, ANSI C, special considerations, lint, make, and project-dependent standards. • Wildfire C++ Programming Style: The Wildfire C++ Programming Style includes requirements for files, preprocessor, identifier naming conventions, using white space, types, variables, functions, statements, miscellaneous, and interaction with C. Files include file naming conventions, file organization, header file content, and source file content. Preprocessor includes macros and conditional compilation. Identifier naming conventions include general rules, identifier style, namespace clashes, and reserved namespaces. Using white space includes indentation, long lines, comments, block comments, single-line comments, and trailing comments. Types include constants, use of const, struct and union declarations, enum declarations, classes, class declarations, class constructors and destructors, automatically-provided member functions, function overloading, operator overloading, protected items, friends, friend classes, friend methods, and templates. Variables include placement of declarations, extern declaration, indentation of variables, number of variables per line, definitions hiding other definitions, and initialized variables. Functions include function declarations and function definitions. Statements include compound statements, if/else statements, for statements, do statements, while statements, infinite loops, empty loops, switch statements, goto statements, return statements, and try/catch statements. Miscellaneous includes general comments and rules, limits on numeric precision, comparing against zero, boolean, character, integral, floating point, pointer, use and misuse of inline, references versus pointers, and portability. Interaction with C includes ANSI-C/C++ include files, including C++ header files in C programs, including C header files in C++, and C code calling C++ libraries. • Visual Basic Style Guide: The Visual Basic Style Guide includes requirements for declaration standards, keyword reference, control and user interface standards, and database standards. Declaration standards include nomenclature standards, nomenclature for variables, nomenclature for constants, nomenclature for user-defined types, nomenclature for

- 36 -

enumerated data types, nomenclature for line labels, nomenclature for procedures, nomenclature for declares, nomenclature for user interface elements, nomenclature exceptions, instantiation standards, instantiation of variables, instantiation of constants, instantiation of user-defined types, instantiation of enumerated data types, instantiation of line lables, instantiation of procedures, instantiation of declares, declaration modifiers, global options, compiler directives, Visual Basic limitation on declaration, and data typing of literals. Keyword reference includes compiler directives, conversion functions, date and time features, declaration features, error handling and debugging features, file system features, financial features, flow control features, math features, miscellaneous features, operators, and string features. Control and user interface standards includes general considerations, communication, control interaction, documentation, and specific control information. Database standards include database design, nomenclature, normalization, database documentation, database usage, spreadsheet presentation, bound filed presentation, and form object presentation. • W3C Style Guide for Online Hypertext: The W3C Style Guide for Online Hypertext includes requirements for markup tags, character formatting, linking, inline images, tables, and fill-out forms. Markup tags include html, head, title, body, headings, paragraphs, lists, preformatted text, extended quotations, addresses, forced line breaks/postal addresses, and horizontal rules. Character formatting includes logical versus physical styles and escape sequences. Linking includes relative pathnames versus absolute pathnames, URLs, links to specific sections, and mailto. Inline images include image size attributes, aligning images, alternate text for images, background graphics, background color, and external images, sounds, and animations. Tables include table tags, general table format, and tables for nontabular information. • Sun Code Conventions for the Java Programming Language: The Sun Code Conventions for the Java Programming Language includes requirements for file names, file organization, indentation, comments, declarations, statements, white space, naming conventions, and programming practices. File names include file suffixes and common file names. File organization includes Java source files, beginning comments, package and import statements, and class and interface declarations. Indentation includes line length and wrapping lines. Comments include implementation comment formats, block comments, single-line comments, trailing comments, end-of-line comments, and documentation comments. Declarations include number per line, initialization, placement, and class and interface declarations. Statements include simple statements, compound statements, return statements, if, if-else, if else-if else statements, for statements, while statements, do-while statements, switch statements, and trycatch statements. White space includes blank lines and blank spaces. Programming practices include providing access to instance and class variables, referring to class variables and methods, constants, variable assignments, miscellaneous practices, parentheses, returning values, expressions before ‘?’ in the conditional operator, and special comments. 5.2.4 Testing Standards and Practices

- 37 -

identify the tests to be performed.The testing standards and practices that shall be enforced by the SQAP are from the IEEE Standard for Software Life Cycle Processes. and test procedures. • System Qualification Testing Phase: System qualification testing is the process of dynamically evaluating integrated CSCIs and HWCIs of a system or segment of a system. software integration. The test or . using acceptance test plans. the TVPL. using test cases and test procedures based on system-level requirements. for later use by system qualification testing. system qualification testing. software qualification testing. and provide schedules for test activities. • Software Acceptance Support Phase: Software acceptance support is the process of assisting customers and end-users dynamically evaluate a system or segment of a system. for CSCIs of a system or segment of a system. The following software activity standards from the IEEE Standard for Software Life Cycle Processes shall be enforced by the SQAP. for later use by system integration. The following documentation standards from the IEEE Standard for Software Life Cycle Processes shall be enforced by the SQAP. The test or validation plan describes the software test environment to be used for the testing. that have undergone individual software and hardware qualification testing. and test procedures to be used to perform qualification testing of a software item or a software system or subsystem. software coding and testing. • System Integration Phase: System integration is the process of combining and evaluating CSCIs and HWCIs of a system or segment of a system. test cases.38 - . system integration. and the TVRR. TVPR. for later use by software installation. and software acceptance support. • Software Qualification Testing Phase: Software qualification testing is the process of dynamically evaluating computer software using test cases and test procedures based on CSCI-level software requirements. • Test or Validation Procedures (TVPR): The purpose of the test or validation procedures is to describe the test preparations. for later use by software integration. for a CSCI of a system or segment of a system. • Software Integration Phase: Software integration is the process of combining and evaluating the CSUs that have been implemented and unit tested. for a CSCI of a system or segment of a system. • Test or Validation Plan (TVPL): The purpose of the test or validation plan is to describe plans for qualification testing of software items and software systems. for later use by software qualification testing. test cases. • Software Coding and Testing Phase: Software coding and testing is the process of transforming the software detailed design—CSUs—into computer software. in order to determine to whether or not to accept the system from the developer.

• Software Cost (process): The cost measure counts budgeted and expended costs. compared to budgets. Cycle time . Size is a critical factor for estimating development schedules and costs. easily understood measure. The test or validation results report enables the acquirer to assess the testing and its results. modified. software effort (process). and process performance. code. These measures also provide information on the amount and frequency of change to products.validation procedures enable the acquirer to assess the adequacy of the qualification testing to be performed. schedule. software cycle time (process). which is especially critical late in product development. This measure usually correlates directly with cost. • Software Cycle Time (process): Cycle time or duration is defined as the elapsed time in hours or months during which development effort proceeds without interruption. measured in person-months. and shall include software size (process). The productivity measure compares the amount of product completed to the amount of effort expended. • Software Effort (process): Effort refers to develop effort—the effort required to design. but can also address other common issue areas including schedule and progress. • Software Size (process): Physical size and stability measures quantify the physical size of a system or product. and possible additional work. • Software Productivity (process): Productivity is the number of lines of source code produced per programmer-month (person-month) of effort.39 - . This measure is a basic input to project planning and can evaluate whether performance levels are sufficient to meet cost and schedule estimates. unit test. Productivity is also useful early in the project for estimate and baseline comparisons before actual productivity data is available.5 Software Process and Product Metrics The software process and product metrics that shall be enforced by the SQAP are defined by the PSM Practical Software and Systems Measurement guide. The measure provides information about the amount of money spent on a project or a product. required effort. a software system or subsystem. Changes in the number of lines of code indicate development risk due to product size volatility. and productivity. software productivity (process). The lines of code measure counts the total amount of source code and the amount that has been added. It can be categorized by activity as well as by product. Only six software process and product metrics have been selected from the PSM Practical Software and Systems Measurement Guide.2. or deleted. and software quality (product). 5. Lines of code is a well-understood software measure that helps in estimating project cost. and system test. software cost (process). • Test or Validation Results Report (TVRR): The purpose of the test or validation results report is to provide a record of the qualification testing performed on a software item. This is a straightforward. The effort measure counts the number of labor hours or number of personnel applied to all tasks. or other software-related item.

0 6.1 Technical and Managerial Reviews and Audits The first ten technical and managerial reviews and audits are from the IEEE Standard for Software Quality Assurance Plans and the IEEE Standard for Software Reviews and Audits.1 REVIEWS AND AUDITS Purpose This section shall: (1) Define the technical and managerial reviews and audits to be conducted. a key objective in process improvement is to reduce overall cycle time. • Software Quality (product): Quality or defect density is the number of software defects committ4ed per thousand lines of software source code. software preliminary design review. They include the software requirements review.1. and can be used to predict test completion. Arrival rates can indicate product maturity (a decrease should occur as testing is completed). and has a direct impact on quality. software critical design review. and priority of defects reported. software. The accumulation of all processes determines the total schedule to complete a project. The next eight reviews are from the IEEE Standard for Software Life Cycle Processes and Military Standard for Technical Reviews and . Usually. and post mortem review. Closure rates are an indication of progress. Military Standard for Technical Reviews and Audits for Systems. physical configuration audit.40 - . Equipments. 6. IEEE 12207. and the IEEE Standard for Software Reviews and Audits. managerial reviews. The number of defects indicates the amount of rework. status.measures the length of time that it takes a process to complete all associate activities. (3) State what further actions are required and how they are to be implemented and verified. The defects measure quantifies the number. It provides useful information on the ability of a supplier to find and fix defects in hardware. A defect density measure—an expression of the number of defects in a quantity of product—can be derived from this measure. software configuration management plan review. Eighteen technical and managerial reviews and audits shall be enforced by the SQAP as defined by the IEEE Standard for Software Quality Assurance Plans. (2) State how the reviews and audits are to be accomplished. or whether rework is being deferred. and Computer Software. Tracking the length of time that defects have remained open can be use to determine whether progress is being made in fixing defects. The purpose of this section is to identify and define the technical and managerial reviews and audits that shall be enforced by the SQAP. in-process audits. software verification and validation plan review. Defect density can identify components with the highest concentration of defects. or documentation. functional configuration audit. 6.

software configuration management personnel. system test readiness review. • Software Requirements Review (SRR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SRR. the audit process itself. Software configuration management is responsible for executing the policies and procedures associated with functional configuration audits and physical configuration audits. 6. software verification and validation personnel. Software project managers are responsible for executing the policies and procedures associated with joint reviews. • Physical Configuration Audit (PCA): Software configuration management personnel are responsible for executing the policies and procedures of the PCA.Audits for Systems. Software project personnel. • Functional Configuration Audit (FCA): Software configuration management personnel are responsible for executing the policies and procedures of the FCA. system/subsystem design review. They include the system/subsystem requirements review. software usability review. • Software Verification and Validation Plan Review (SVVPR): Software project managers. Software project personnel. walkthroughs and inspections. Software quality assurance is directly responsible for executing the policies and procedures of only one of the three types of in-process audits.2 Accomplishing Reviews and Audits The reviews and audits will be accomplished by the application of individual policies and procedures for each of the reviews and audits by software project managers. . software project personnel. and software configuration management are responsible for executing the policies and procedures of the SVVPR. software quality assurance. software test results review. namely software engineers. software project personnel. • Software Critical Design Review (SCDR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SCDR. are responsible for executing the policies and procedures of walkthroughs and inspections. • Managerial Review: Software project managers and software project personnel are responsible for executing the policies and procedures of managerial reviews.41 - . • Software Preliminary Design Review (SPDR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SPDR. are responsible for executing the policies and procedures for two of the three types of in-process audits. Equipments. system test results review.1. and software maintenance review. and Computer Software. software test readiness review. namely software engineers. • In-Process Audit: Software quality assurance personnel are responsible for executing the policies and the procedures of the audit process. and software quality assurance personnel.

software project personnel. software quality assurance. software quality assurance. • System/Subsystem Requirements Review (SSRR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SCDR. Verification of the audit process. software project personnel.3 Implementing and Verifying Reviews and Audits Implementation and verification of the eighteen major types of reviews and audits shall be accomplished by audits performed by software quality assurance personnel. • Software Usability Review (SUR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SUR. shall be independently evaluated (other than by software quality assurance personnel). • System Test Results Review (SYTRER): Software project managers and software project personnel are responsible for executing the policies and procedures of the SYTRER. and software configuration management are responsible for executing the policies and procedures of the SCMPR.1. software verification and validation personnel. • Software Test Results Review (SOTRER): Software project managers and software project personnel are responsible for executing the policies and procedures of the SOTRER. • System/Subsystem Design Review (SSDR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SSDR. and software configuration management are responsible for executing the policies and procedures of post mortem reviews.2 Minimum Requirements As a minimum. • System Test Readiness Review (SYTRR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SYTRR.42 - . as well as audit process effectiveness. • Software Maintenance Review (SMR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SMR. • Software Test Readiness Review (SOTRR): Software project managers and software project personnel are responsible for executing the policies and procedures of the SOTRR. SQA shall audit each of the eighteen types of reviews and audits using the audit process itself (with the exception of the audit process). the following reviews and audits shall be conducted: . • Post Mortem Review: Software project managers. 6. 6.• Software Configuration Management Plan Review (SCMPR): Software project managers.

and technical adequacy of the selected top-level design and test approach. and UDD form a satisfactory basis for proceeding into software architectural design. which immediately follows software requirements analysis. For configuration items.2. compatibility between software requirements and preliminary design. technical adequacy. A successful SRR is predicated upon the contracting agency's determination that the COD. The SRR is conducted when CSCI requirements have been sufficiently defined to evaluate the contractor's responsiveness to and interpretation of the system.2 Software Preliminary Design Review (SPDR) The SPDR (also known as top-level design review) is held to evaluate the technical adequacy of the preliminary design (also known as top-level design) of the software as depicted in the preliminary software design description. which immediately follows software architectural design. 6. subsystem. and risk resolution (on a technical. External review techniques include a software critical design review (SCDR). Finally this review establishes the existence and compatibility of the physical and functional interfaces among the configuration items and other items of equipment.43 - . or prime item level requirements. External review techniques include a software requirements review (SRR). and schedule basis) of the selected design approach. The SRR is a review of the finalized CSCI requirements and operational concept. and evaluates the degree of definition and assesses the technical risk associated with the selected manufacturing methods/processes. This review is conducted for each configuration item or aggregate of configuration items to evaluate the progress. and on the preliminary version of the operation and support documents. facilities. which immediately follows software detailed design. this review determines their compatibility with performance and engineering specialty requirements of the HWCI development specification. consistency. This review is conducted for each configuration . cost.3 Software Critical Design Review (SCDR) The SCDR (also known as detailed design review) is held to determine the acceptability of the detailed software designs as depicted in the detailed software design description in satisfying the requirements of the SRD. SRD. 6.6.2. computer software. this review focuses on the evaluation of the progress. External review techniques include a software preliminary design review (SPDR).1 Software Requirements Review (SRR) The SRR is held to ensure the adequacy of the requirements stated in the SRS. and personnel. For CSCIs.2.

and audits. The purpose of this review is to determine that the detailed design of the configuration item under review satisfies the performance and engineering specialty requirements of the HWCI development specifications. inspections. and inspections of the SVVP to ensure that it meets the requirements as stated in software project plans and software requirements documents.44 - . compliance levels of software V&V activities. Test data shall be reviewed to verify that the hardware or computer software performs as required by its functional/ allocated . walkthroughs. measure compliance with the SVVP.2. determine the effectiveness of software V&V. Verifying the SVVP conforms to software V&V standards consists of conducting audits of the SVVP to ensure that it meets the requirements of the SVVP standard. actions. the purpose of this review is to review the preliminary hardware product specifications.2.item when detail design is essentially complete. monitoring. and assesses the results of the producibility analyses conducted on system hardware. this review focuses on the determination of the acceptability of the detailed design. This review also establishes the detailed design compatibility among the configuration items and other items of equipment. the SVVP meets the needs of the software project. 6. Measuring compliance with the SVVP consists of conducting audits of software V&V activities to determine their compliance with policies and procedures. The objective of the Software Verification and Validation Plan Review (SVVR) shall be to verify the SVVP conforms to software V&V standards. and test characteristics of the design solution. For CSCIs. and schedule basis). and non-conformances arising from managerial reviews. and ensuring their rapid resolution and closure. assesses configuration item risk areas (on a technical. The objective of the Functional Configuration Audit (FCA) shall be to verify that the configuration item's actual performance complies with its hardware Development or Software Requirements and Interface Requirements Specifications. Verifying the SVVR meets the needs of the software project consists of conducting managerial reviews. and software quality and reliability levels of the software work products themselves.5 Functional Configuration Audit (FCA) This audit is held prior to the software delivery to verify that all requirements specified in the SRS have been met. cost. Resolving software V&V non-conformances consists of identifying. walkthroughs. performance. 6. and resolve software V&V non-conformances. computer software and personnel.4 Software Verification and Validation Plan Review (SVVPR) The SVVPR is held to evaluate the adequacy and completeness of the verification and validation methods defined in the SVVP. Finally. and on the adequacy of the operation and support documents. Determining the effectiveness of software V&V consists of analyzing completion of SVVP tasks. facilities. and tracking the issues.

Inspections are expertly facilitated evaluations of software products by domain experts.2. all subsequent changes are processed by engineering change action. For software. walkthroughs. Software User's Manual (SUM).2. The Physical Configuration Audit (PCA) shall be the formal examination of the as-built version of a configuration item against its design documentation in order to establish the product baseline. namely software . Walkthroughs are informal design review meetings held principally by software project managers to elicit comments and feedback on their design solutions. The PCA also determines that the acceptance testing requirements prescribed by the documentation is adequate for acceptance of production units of a configuration item by quality assurance activities.6 Physical Configuration Audit (PCA) This audit is held to verify that the software and its documentation are internally consistent and are ready for delivery. After successful completion of the audit. technical data and tests utilized in production of HWCIs and a detailed audit of design documentation. Computer System Operator's Manual (CSOM). The review shall include an audit of the released engineering documentation and quality control records to make sure the as-build or as-coded configuration is reflected by this documentation. 6. and as appropriate. Software audits are independent evaluations of software activities and software work products by software quality assurance. For software. the Computer System Diagnostic Manual (CSDM). and manuals for CSCIs.configuration identification. software audits. and inspections. an FCA shall be a prerequisite to acceptance of the configuration item. the Software Product Specification and Software Version Description shall be a part of the PCA review.45 - . in or order to verify conformance to software process and product standards. For configuration items developed at Government expense.7 In-Process Audit In-process audits of a sample of the design are held to verify consistency of the design. including: (1) Code versus design documentation (2) Interface specifications (hardware and software) (3) Design implementations versus functional requirements (4) Functional requirements versus test descriptions There are three types of in-process audits. The PCA includes a detailed audit of engineering drawings. listings. a technical understanding shall be reached on the validity and the degree of completeness of the Software Test Reports. specifications. 6.

Audits are performed in accordance with documented plans and procedures. The audit plan establishes a procedure to conduct the audit and for follow-up action on the audit findings. solicit a critique of the approach. a detailed design. in order to identify defects. The results of the audit are documented and are submitted to the management of the audited organization. non-conformances to numerical tolerances. or procedures. a technical architecture. functional flow. or solicit design alternatives). Software project manager walkthroughs are open forums for evaluating software designs. The three types of in-process audits are each unique. without any defense from the author or creator of the product. In performing the audit. • Walkthrough: A walkthrough is an informal design review meeting in which the manager. and/or rationale and justification for selecting technologies. recommendations are reported in addition to the audit results. SQA audits verify conformance to software process and product standards.2. or any subjective improvements to the product’s design by the examiners (in order identify defects for later mandatory correction and enable early validation of the product using internal technical experts before it is delivered). and without any consideration of design alternatives. or technical lead that’s directly responsible for creating or designing a product. not suggest design alternatives or subjective improvements to the product). supervisor. and procedures. inspections are for technical experts to identify defects that must be corrected (but. and standards. while very complementary. nonconformances to standards. • Software Audit: The objective of software auditing is to provide an objective compliance confirmation of products and processes to certify adherence to standards. or a specific solution to satisfy the product’s requirements or specifications. 6. to the entity initiating the audit. design critiques. and software engineering inspections are expert forums for directly improving software quality. audit personnel evaluate software elements and the processes for producing them against objective audit criteria. guidelines. and to any external organizations identified in the audit plan. When stipulated by the audit plan. or technical leads. to evaluate their conformance to requirements and identify software defects for mandatory correction. with other managers. supervisors. requirements. operational and functional failures. such as contracts. In short. walkthroughs are intended for managers to solicit design alternatives (without any mandatory action on behalf of the manager or product author).8 Managerial Review . specifications. non-conformances to requirements and specifications. plans. • Inspection: An inspection is a highly structured and facilitated meeting in which independent technical experts analyze and examine each of the individual product characteristics one-byone. engineers. The report includes a list of the items in noncompliance or other issues for subsequent review and action. In short. and/or safety hazards.engineers. and technical specialists (in order to defend the design concept. without the presence of managers. guidelines. specifications.46 - . verbalizes the intended operational flow.

(3) Maintaining global control of the project through adequate allocation of resources. The objective of the management review is to provide recommendations for the following: (1) Making activities progress according to plan. The objective of the Software Configuration Management Plan Review (SCMPR) shall be to verify the SCMP conforms to SCM standards. 6. This review may require additional changes in the SQAP itself. inspections. walkthroughs. determine the effectiveness of SCM. Each problem areas identified by the review team is recorded.2. measure compliance with the SCMP.Managerial reviews are held periodically to assess the execution of all of the actions and the items identified in the SQAP. During the review meeting the entire review team examines plans or progress against applicable plans. then an additional meeting shall be scheduled to complete the management review process.10 Post Mortem Review The review is held at the conclusion of the project to assess the development activities . walkthroughs. and SCM integrity levels of the software work products themselves. monitoring. and audits.47 - . compliance levels of SCM activities. Measuring compliance with the SCMP consists of conducting audits of SCM activities to determine their compliance with policies and procedures. These reviews shall be held by an organizational element independent of the unit being reviewed. A management review is a formal evaluation of a project level plan or project status relative to that plan by a designated review team. the SCMP meets the needs of the software project. Verifying the SCMP meets the needs of the software project consists of conducting managerial reviews. and tracking the issues. and ensuring their rapid resolution and closure. or by a qualified third party. and inspections of the SCMP to ensure that it meets the requirements as stated in software project plans and software requirements documents. (2) Changing project direction nor to identify the need for alternative planning. and resolve SCM non-conformances. When critical data and information cannot be supplied. based on an evaluation of product develop status. and guidelines. or both. Resolving SCM non-conformances consists of identifying. standards. Determining the effectiveness of SCM consists of analyzing completion of SCMP tasks. 6. actions.2. The management review process can be applied to new development or to maintenance activities. Verifying the SCMP conforms to SCM standards consists of conducting audits of the SCMP to ensure that it meets the requirements of the SCMP standard.9 Software Configuration Management Plan Review (SCMPR) The SCMPR is held to evaluate the adequacy and completeness of the configuration management methods defined in the SCMP. and non-conformances arising from managerial reviews.

SSRRs are inprocess reviews normally conducted during the system conceptual or validation phase. 6. human resources.48 - . Evaluating the effectiveness of the software project also includes evaluating the effectiveness of any necessary replanning and corrective actions. computers and software engineering tools). This review will not be conducted by S&IS if a system specification is not required or. effort.g. size. and most importantly the ability of the organization effectively organize and execute similar projects in the future (if at all). and consistently evaluate the effectiveness of the software project upon its completion. cost. This review is held to evaluate the adequacy (e.g. schedule accuracy.. teams. intergroup coordination.3.3.1 System/Subsystem Requirements Review (SSRR) External review techniques include a system/subsystem requirements review (SSRR). deliverables. correctness. activities. appropriateness of processes. 6.implemented on that project and to provide recommendations for appropriate actions. The objective of the project postmortem review is to formally.g. objectively. how well software project objectives were met. purchasing. is provided by the government. the technical and interpersonal strengths and weaknesses of individuals. Such reviews may be conducted at any time but normally will be conducted after accomplishment of functional analysis and preliminary requirements allocation. and process quality. the appropriate identification and mitigation of software risks. and usability) of user documentation. It is conducted when a significant portion of the system functional requirements has been established. Evaluating the effectiveness of the software project includes evaluating the effectiveness of the software project plan. corporate infrastructure support (e. and critical computer resources). 6. in a highly structured. information systems. repeatable. and product quality. and facilities management).. cooperation. SSRRs are to determine initial direction and progress of the systems engineering management effort and the convergence upon an optimum and complete configuration.3 Other Other reviews and audits may include the user documentation review (UDR). which immediately follows system requirements analysis.. appropriateness of work products.. the initial accuracy of quantitative estimates (e. The objective of the SSRR is to ascertain the adequacy of the contractor’s efforts in defining system requirements. clarity.g. and the allocation of personnel and facility resources (e. software project management and coordination. communication. and teamwork. if required. and measurable fashion (in order to ensure that future projects proactively improve their performance).2 System/Subsystem Design Review (SSDR) . completeness. and groups.

software requirements and interface requirements specifications. the contracting agency also reviews the results of informal software testing and any updates to the operation and support documents. 6. and contractor progress in successfully verifying the requirements of the configuration items. which is necessary to successfully conclude the system architectural design. Basic manufacturing considerations are reviewed and planning for production engineering in subsequent phases is addressed. SOTRERs are held to resolve open issues regarding the results of software qualification testing. For noncombined functional configuration audit/SOTRERs. and completeness of the SOTRER shall be maintained with the functional configuration audit and duplication of effort avoided. . and to identify the test report(s)/data which document results of qualification tests of the configuration items. This review is conducted when the system definition effort has proceeded to the point where system characteristics are defined and the configuration items are identified. which produced the allocated technical requirements and of the engineering planning for the next phase of effort. If sufficient test results are not available at the functional configuration audit to insure the configuration items will perform in their system environment.3 Software Test Readiness Review (SOTRR) External review techniques include a software test readiness review (SOTRR).4 Software Test Results Review (SOTRER) External review techniques include a software test results review (SOTRER). the SOTRER shall be conducted (post physical configuration audit) during system testing whenever the necessary tests have been successfully completed to enable certification of configuration items.49 - . traceability. This review is conducted for each CSCI to determine whether the software test procedures are complete and to assure that the contractor is prepared for formal CSCI testing. At SOTRR. which immediately follows software integration. correlation. 6. prior to the physical configuration audit.3. which immediately follows software qualification testing. and risks associated with the allocated technical requirements. risk aspects of the particular hardware and software. Software test procedures are evaluated for compliance with software test plans and descriptions. correlation.3. This review is conducted to evaluate the optimization. The point of government certification will be determined by the contracting agency and will depend upon the nature of the program. the SOTRER shall be combined with the functional configuration audit at the end of configuration item/subsystem testing. completeness. A successful SOTRR is predicated on the contracting agency's determination that the software test procedures and informal test results form a satisfactory basis for proceeding into software qualification testing. and for adequacy in accomplishing test requirements.External review techniques include a system/subsystem design review (SSDR). When feasible. The objective of the SOTRER shall be to verify that the actual performance of the configuration items of the system as determined through test comply with the hardware development specification. Also included is a summary review of the system engineering process.

7 Software Usability Review (SUR) External review techniques include a software usability review (SUR). the contracting agency also reviews the results of informal system testing and any updates to the operation and support documents. including “training software products. If sufficient test results are not available at the functional configuration audit to insure the configuration items will perform in their system environment. When feasible. For noncombined functional configuration audit/SYTRERs. and the status of installation preparations and activities.3. and completeness of the SYTRER shall be maintained with the functional configuration audit and duplication of effort avoided. System test procedures are evaluated for compliance with system test plans and descriptions. which immediately follows system qualification testing.50 - . which immediately follows software installation.6 System Test Results Review (SYTRER) External review techniques include a system test results review (SYTRER). and contractor progress in successfully verifying the requirements of the configuration items. the SYTRER shall be conducted (post physical configuration audit) during system testing whenever the necessary tests have been successfully completed to enable certification of configuration items. and for adequacy in accomplishing test requirements. prior to the physical configuration audit. SYTRERs are held to resolve open issues regarding the results of system qualification testing. SURs are held to resolve open issues regarding the readiness of the software for installation at user sites. and then using these problems to make recommendations for fixing the problems and improving the usability of .” if applicable. and to identify the test report(s)/data which document results of qualification tests of the configuration items. risk aspects of the particular hardware and software. traceability. status of training. 6. The point of government certification will be determined by the contracting agency and will depend upon the nature of the program. the software version descriptions. which are aimed at finding usability problems in an existing user interface design. the user and operator manuals. 6. the SYTRER shall be combined with the functional configuration audit at the end of configuration item/subsystem testing.3. SURs optionally involve conducting usability inspections.5 System Test Readiness Review (SYTRR) External review techniques include a system test readiness review (SYTRR). At SYTRR.6. The objective of the SYTRER shall be to verify that the actual performance of the configuration items of the system as determined through test comply with the hardware development specification. A successful SYTRR is predicated on the contracting agency's determination that the system test procedures and informal test results form a satisfactory basis for proceeding into system qualification testing. correlation. This review is conducted for each system to determine whether the system test procedures are complete and to assure that the contractor is prepared for formal system testing.3. which immediately follows system integration. system requirements and interface requirements specifications.

the software maintenance manuals. current written maintenance methods at the systems and program level. any existing performance statistics. 6. and new technologies that need to be incorporated. including expected external or regulatory changes to the system. quantify the software maintenance effort. pluralistic walkthroughs (meetings where users. consistency inspections (evaluating user interface consistency across a family of products by designers from multiple projects). and feature inspections (used to verify that individual user interface functions conform to system requirements). SMRs are held to resolve open issues regarding the readiness of the software for transition to the maintenance organization. expected internal changes to support new requirements. the software version descriptions. and the status of transition preparations and activities. quality and timeliness of documentation. if applicable. and develop the software maintenance plan.3. their job descriptions. and tools used to support the maintenance process and how they are used.0 TEST This section shall identify all the tests not included in the SVVP for the software covered by the SQAP and shall state the methods to be used.the design. standards inspections (increasing the degree to which a given user interface is similar to the user interfaces of competing products in the marketplace). which immediately follows software acceptance support. the software product specifications. cognitive walkthroughs (checking to see if the user interface enables intuitive. and human factors people step through a scenario. correct. the experience level of the maintenance staff. Usability inspections consist of heuristic evaluation (having usability specialists judge whether each dialogue element conforms to established usability principles). Finally. and repeatable user operations). new lines of business that need to be supported. wish-lists of new functions and features. including age since being placed in production. SMRs are used to determine the software maintenance requirements. adaptability. both industry-wide and for the particular application. including transition of the software engineering environment. formal usability inspections (a software inspection process used to identify defects in user interfaces). consistent. number of maintainers. discussing usability issues associated with dialogue elements involved in the scenario steps).8 Software Maintenance Review (SMR) External review techniques include a software maintenance review (SMR). SMRs are used to determine necessary software maintenance effort. number and type of changes during life. SMRs are also used to determine the necessary software maintenance process. actual methods used by programming staff. developers. types and number of requests received for changes. guideline reviews (checking the user interface for conformance with a comprehensive list of usability guidelines). the rate of turnover and possible reasons for leaving. expected upgrades for performance. 7. and their actual jobs. . and connectivity.51 - . usefulness of the system.

that shall be enforced by the SQAP. software quality assurance reviews and audits activities and work products of software projects. software quality assurance participates in creation of software development plans.Software test methods that shall be enforced by the SQAP.52 - . identify the tests to be performed. is not the principal test plan. test cases. The test or validation procedures enable the acquirer to assess the adequacy of the qualification testing to be performed. and provide schedules for test activities. The practices and procedures to be followed for reporting.0 TOOLS. and documentation support. TECHNIQUES. tracking. • Test or Validation Plan (TVPL): The purpose of the test or validation plan is to describe plans for qualification testing of software items and software systems. 9. and procedures by software projects. and test procedures to be used to perform qualification testing of a software item or a software system or subsystem. plans. which are not covered by the SVVP. identification and definition of software testing methods shall be defined in the test or validation plan. The SVVP. shall be identified and defined by the test or validation plan and the test or validation procedures. and resolving problems identified in both software items and the software development and maintenance process. • Software Quality Assurance Policy and Procedure: This procedure establishes the guidelines by which software quality assurance prepares software quality assurance plans for software projects. and software quality assurance handles deviations and non-compliances to software standards. per se. and resolving problems identified in both software items and the software development and maintenance process.0 PROBLEM REPORTING AND CORRECTIVE ACTION This section shall: (1) Describe the practices and procedures to be followed for reporting. as well as the test or validation procedures. (2) State the specific organizational responsibilities concerned with their implementation. This procedure shall begin with project system managers ensuring that software quality assurance is present on all software projects and end with independent experts reviewing the methods and frequency that software quality assurance will use to provide feedback to software engineering. shall be identified and defined by the software quality assurance policy and procedure. The test or validation plan describes the software test environment to be used for the testing. • Test or Validation Procedures (TVPR): The purpose of the test or validation procedures is to describe the test preparations. AND METHODOLOGIES . 8. software configuration management. So. tracking.

The results of the audit are documented and are submitted to the management of the audited organization. and technical specialists (in order to defend the design concept. guidelines. specifications. • Software Audit: The objective of software auditing is to provide an objective compliance confirmation of products and processes to certify adherence to standards. recommendations are reported in addition to the audit results. techniques. non-conformances to numerical tolerances. or technical leads. with other managers. or a specific solution to satisfy the product’s requirements or specifications. in order to identify defects. requirements. without any defense from the author or creator of the product. Audits are performed in accordance with documented plans and procedures. and procedures. walkthroughs. without the presence of managers. operational and functional failures. and without any consideration of design alternatives. solicit a critique of the approach. techniques. and/or safety hazards. that shall be enforced by the SQAP. non-conformances to requirements and specifications. In short. and describe their use. design critiques. and methodologies that support SQA. a detailed design. The audit plan establishes a procedure to conduct the audit and for follow-up action on the audit findings. defect typing and classification. and standards. a technical architecture. and/or rationale and justification for selecting technologies. or technical lead that’s directly responsible for creating or designing a product. and to any external organizations identified in the audit plan. supervisor. guidelines. shall include audits. audit personnel evaluate software elements and the processes for producing them against objective audit criteria. nonconformances to standards. and methodologies that support SQA. state their purposes. specifications. and software quality modeling. functional flow. verbalizes the intended operational flow. In short. walkthroughs are intended for managers to solicit design alternatives (without any mandatory action on behalf of the manager or product author). plans. • Walkthrough: A walkthrough is an informal design review meeting in which the manager. In performing the audit. supervisors. not suggest design alternatives or subjective improvements to the product). or procedures. When stipulated by the audit plan. inspections are for technical experts to identify defects that must be corrected (but. inspections.This section shall identify the special software tools. engineers. or any subjective improvements to the product’s design by the examiners (in order identify defects for later mandatory correction and enable early validation of the product using internal technical experts before it is delivered). such as contracts. The special software tools.53 - . . or solicit design alternatives). to the entity initiating the audit. The report includes a list of the items in noncompliance or other issues for subsequent review and action. • Inspection: An inspection is a highly structured and facilitated meeting in which independent technical experts analyze and examine each of the individual product characteristics one-byone.

an appropriate reference shall be made thereto. If so. releases. The methods and facilities used to maintain. organization and management philosophy. Arrival rates can indicate product maturity (a decrease should occur as testing is completed).54 - . 10.0 MEDIA CONTROL . or documentation. store. support the software development and maintenance methodology that fits the software requirements. This may be implemented in conjunction with a computer program library. or whether rework is being deferred. Defect density can identify components with the highest concentration of defects. 11. This may be provided as part of the SCMP. standards. More detailed classifications are provided for those projects that require more rigor. Tracking the length of time that defects have remained open can be use to determine whether progress is being made in fixing defects.0 CODE CONTROL This section shall define the methods and facilities used to maintain. and priority of defects reported. A defect density measure—an expression of the number of defects in a quantity of product—can be derived from this measure. store. tests. software source code. secure and document controlled versions of the identified software during all phases of the software life cycle. and can be used to predict test completion. status. change control. The defects measure quantifies the number. and has a direct impact on quality. software interfaces. It provides useful information on the ability of a supplier to find and fix defects in hardware.• Software Defect Typing and Classification: Software defect typing and classification provides a uniform approach to the classification of anomalies found in software and its documentation. The minimum set of classifications deemed necessary for a complete data-set are indicated as mandatory. The number of defects indicates the amount of rework. policies. and support production of management and product information concerning the status of software baselines. and it provides comprehensive lists of software anomaly classifications and related data items that are helpful to identify and track anomalies. Closure rates are an indication of progress. that shall be enforced by the SQAP. secure and document controlled versions of the identified software during all phases of the software life cycle. and databases to support all software life cycle phases. It describes the processing of anomalies discovered during any software life cycle phase. • Software Quality Modeling: Software quality or defect density is the number of software defects committ4ed per thousand lines of software source code. • Software Configuration Management Plan (SCMP): The purpose of the software configuration management plan is to provide a structure for identifying and controlling software documentation. software. shall be identified and defined by the software configuration management plan. and audits.

If so. and support production of management and product information concerning the status of software baselines. that shall be enforced by the SQAP. change control. software interfaces. In addition.55 - . standards. This may be provided as a part of the SCMP. the supplier shall be required to prepare and implement a SQAP in accordance with this standard.0 SUPPLIER CONTROL This section shall state the provisions for assuring that software provided by suppliers meets established requirements. and audits. including the copy and restore process. this section shall state the methods to be used to assure the suitability of the product for use with the software items covered by the SQAP. The methods and facilities to be used to identify the media for each computer product and the documentation required to store the media. For software that is to be developed. shall be identified and defined by the software configuration management plan. subcontract software managers track software subcontractors. 12. The provisions for assuring that software provided by suppliers meets established requirements. • Software Configuration Management Plan (SCMP): The purpose of the software configuration management plan is to provide a structure for identifying and controlling software documentation. and databases to support all software life cycle phases. tests. For previouslydeveloped software. support the software development and maintenance methodology that fits the software requirements. subcontract software managers select software subcontractors. this section shall state the methods that will be used to assure that the software supplier receives adequate and complete requirements. organization and management philosophy. an appropriate reference shall be made thereto. This section shall also state the methods to be employed to assure that the developers comply with the requirements of this standard. subcontract software managers create software subcontract agreements. releases. and subcontract software managers make changes to software subcontract agreements. and (b) protect computer program physical media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle. policies. software source code. that shall be enforced by the SQAP. and protect computer program physical media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle.This section shall state the methods and facilities to be used to (a) identify the media for each computer product and the documentation required to store the media. including the copy and restore process. This procedures shall begin with project system managers ensuring that documented standards and procedures are used for selecting software subcontractors and . • Software Subcontract Management Policy and Procedure: This procedure establishes the guidelines by which subcontract software managers define software work to be subcontracted. shall be identified and defined by the software subcontract management policy and procedure.

assess. . shall be identified and defined by the training program policy and procedure.56 - .0 RISK MANAGEMENT This section shall specify the methods and procedures employed to identify. shall state the methods and facilities to be used to assemble. software source code. and maintain the SQA documentation to be retained. training groups perform training for the organization and software projects. change control.managing software subcontracts and end with software quality assurance reviewing and/or auditing acceptance processes for products of software subcontractors. tests. 15. • Software Configuration Management Plan (SCMP): The purpose of the software configuration management plan is to provide a structure for identifying and controlling software documentation. shall be identified and defined by the software configuration management plan. organization and management philosophy. that shall be enforced by the SQAP. and training groups maintain records of training for the organization and software projects.0 RECORDS COLLECTION. training groups develop and maintain training courses. 13. AND RETENTION This section shall identify the SQA documentation to be retained. and databases to support all software life cycle phases. releases. The training activities necessary to meet the needs of the SQAP. software interfaces. MAINTENANCE.0 TRAINING This section shall identify the training activities necessary to meet the needs of the SQAP. • Training Management Policy and Procedure: This procedure establishes the guidelines by which project software managers develop and maintain a training plan for each software project. that shall be enforced by the SQAP. and support production of management and product information concerning the status of software baselines. support the software development and maintenance methodology that fits the software requirements. training groups develop and revise the organization training plan. 14. and audits. This procedure shall begin with senior management ensuring that skills and knowledge for software management and technical roles are identified and end with independent experts verifying that training groups follow the organization training plan. policies. standards. safeguard. and maintain this documentation and shall designate the retention period. monitor. The methods and facilities to be used to assemble. safeguard.

shall be identified and defined by the software project plan. assess.and control areas of risk arising during the portion of the software life cycle covered by the SQAP. The methods and procedures employed to identify. that shall be enforced by the SQAP. as defined in the project agreement.57 - . A software project plan defines the technical and managerial project functions. activities. and control areas of risk arising during the portion of the software life cycle. . and tasks necessary to satisfy the requirements of a software project. monitor. • Software Project Plan (SPP): The purpose of the software project plan is to serve as a controlling document for managing a software project.

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.