IEEEsqap

Software Quality Assurance Plan
Software Quality Assurance Plan (SQAP) Template
Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. The document in this file is an annotated outline for a Software Quality Assurance Plan, following loosely the IEEE Standard for Software Quality Assurance Plans (Std 730-1989). Tailor this to your needs. Where you decide to omit a section, you might keep the header, but insert a comment saying why you omit the element.
P:\IRM\Private\QA\QAPLAN\SQAPLAN.doc
Page 1 of 30
02/07/03 8:18 AM
Agency Project Software Quality Assurance Plan
Version: (n)
Date: (mm/dd/yyyy)
Page 2 of 30
02/07/03 8:18 AM
TABLE OF CONTENTS
1. PURPOSE 1
2. REFERENCE DOCUMENTS, DEFINITIONS, AND ACRONYMS 2.1 Reference Documents 2.2 Glossary of Terms 2.3 Abbreviations and Acronyms
1 1 1 1
3. PROJECT MANAGEMENT 3.1 Project Organization 3.2 Methodology 3.3 Activities and Tasks 3.4 Roles and Responsibilities
2 2 2 2 2
4. DOCUMENTATION 4.1 Project Notebook 4.2 Functional Specifications Document 4.3 Architecture Design Document 4.4 Software Verification and Validation Plan 4.5 Software Verification and Validation Report 4.6 Configuration Management Plan 4.7 User and Operations Documentation
3 3 3 4 4 5 5 6
5. STANDARDS 5.1 Coding Standards 5.2 Data Naming Standards 5.3 User Interface Standards 5.4 Static Report Format Standards 5.5 Development Tool Standards 5.6 Documentation Standards 5.7 Metrics 5.8 IEEE Standards 5.9 IRMC Policies, Standards, Checklists
6 6 6 6 6 6 6 6 6 6
6. REVIEWS AND AUDITS 6.1 Deliverable Reviews 6.2 Management Reviews 6.3 Product Reviews
P:\IRM\Private\QA\QAPLAN\SQAPLAN.doc Page 3 of 30 02/07/03 8:18 AM
7 7 8 8
TABLE OF CONTENTS (CONTINUED)

7. TEST 7.1 Unit Test 7.2 Integration Test 7.3 System Test 7.4 User Acceptance Test 9 9 9 10 10
8. Problem Reporting and Corrective Action
11
9. Tools, Techniques, and Methodology 9.1 Tools 9.2 Techniques 9.3 Methodologies 9.4 Code Control 9.5 Media Control 9.6 Security 9.7 Disaster Recovery 9.8 Supplier Controls 9.9 Records Collection, Maintenance, and Retention
11 11 11 11 11 11 11 11 11 11
10. TRAINING 10.1 User Training 10.2 Development Team Training 10.3 Transition to State Team Training
12 12 12 12
11. RISK MANAGEMENT 11.1 Project Self Assessment 11.2 Project Risk Assessment and Management Plan 11.3 Risk Review and Management Process 11.4 Tools
14 14 14 14
12. Lessons Learned
18
13. Document Approvals
18
Page 4 of 30
02/07/03 8:18 AM
Software Quality Assurance Plan APPENDIX A - GLOSSARY APPENDIX B - STANDARDS APPENDIX C - SUPPORTING DOCUMENTATION 19 29 30
Page 5 of 30
02/07/03 8:18 AM
1. PURPOSE
THE SOFTWARE QUALITY ASSURANCE PLAN (SQAP) DEFINES THE ACTIVITIES PERFORMED TO PROVIDE ASSURANCE THAT THE SOFTWARE-RELATED ITEMS DELIVERED TO THE CUSTOMER CONFORM TO THE ESTABLISHED AND CONTRACTED TECHNICAL REQUIREMENTS. THE SQAP ALSO DESCRIBES HOW THE PROJECT WILL BE AUDITED TO ENSURE THAT THE POLICIES, STANDARDS, PRACTICES, PROCEDURES, AND PROCESSES APPLICABLE TO THE PROJECT ARE FOLLOWED.
Describes the purpose and scope of the project Software Quality Assurance Plan (SQAP). Contains a list of all software items covered by the SQAP and the intended use of the software. It also states the portion of the system software life cycle covered by the SQAP for each software item specified. The following questions should be answered in this section: What is the intended use of the software (business use, criticality, and interfaces)? What is the scope of this SQAP? How will this plan contribute to the success of the project? Name the software development life cycle (SDLC) that applies to the project? What, if any, are the deviations from the software development life cycle? (Refer to IEEE Standard 730 for more information about the Software Quality Assurance Plan.)
2. REFERENCE DOCUMENTS, DEFINITIONS, AND ACRONYMS

Section 2 will provide a complete list of documents referenced elsewhere in the text of the SQAP. By definition, these documents originate outside the project. Refer to Appendix C for a list of external Standards and Procedures. Also included in this section are a glossary of project specific terms and their definitions and l list of project-specific abbreviations and acronyms and their meaning. .
2.1 Reference Documents

Lists all project-related documents referred to in the text of the SQAP. Refer to Appendix B for a list of common referenced documents, policies, procedures, and standards.
2.2 Glossary of Terms

Lists and defines all terms that establish meaning within the context of the SQAP. Refer to Appendix A for a detail list of common terms
Page 6 of 30
02/07/03 8:18 AM
2.3 Abbreviations and Acronyms

Lists all alphabetical contractions and their definition that appear within the text of the SQAP.
3. PROJECT MANAGEMENT
This section describes the project organization, tasks and activities, and responsibilities. Describes the project management approach to be employed on the project. Because much of this information is provided in the Statement of Work and project plan, this section may briefly summarize the approach and refer the reader to referenced documents for more detailed information.
3.1 Project Organization

This section depicts the organizational structure that influences and controls the quality of the software. Outlines the organizational structure of the project, including the role of user representatives, technology experts, IS support staff, and other project logistical items (such as workspace, workstations, LAN support, telephones, development and testing environments, etc.).Organizational dependencies or independence of the elements responsible for SQA from those responsible for software development and use should be clearly described or depicted.
3.2 Methodology
Describes the methodology to be followed during the design and development phases of the project. This section will explain how the Agency system development life cycle approach (SDLC) has been applied.
3.3 Activities and Tasks

Provides a summary of the project plan, including a list of activities and tasks to be performed by team members. The sequence of tasks and activities should be detailed. Describe: The portion of the system development life cycle covered by the SQAP; and The relationship between activities and tasks and the planned major checkpoints or milestones.
3.4 Roles and Responsibilities

This section should identify the specific organizational elements responsible for each task or activity. Briefly describes the roles and responsibilities of project team members.
4. DOCUMENTATION
Describes the documentation that will be created during the project to support management, design, development, and testing activities. This section shall perform the following functions: Identify the documentation governing the development, verification and validation, use, and maintenance of the software, and State how the documents are to be checked for adequacy.
IEEE Standard 730 requires the following documentation as a minimum: Software Requirements Specification (SRS) Software Design Description (SDD) Software Verification and Validation Plan (SVVP) Software Verification and Validation Report (SVVR) User Documentation Software Configuration Management Plan (SCMP)
4.1 Project Notebook

Explains the purpose, content, and location of the materials included in the project notebook. 4.1.1 Statement of Work 4.1.2 Project Plan 4.1.3 Project Progress Reports 4.1.4 Individual Progress Reports 4.1.5 Issues Log 4.1.6 Project Change Requests 4.1.7 Deliverable Acceptance Reports
Page 8 of 30
02/07/03 8:18 AM
4.2 Functional Specifications Document

Explains the purpose and content of the functional specification document. The Software Requirements Specification shall clearly and precisely describe each of the essential requirements (functions, performances, design constraints, and attributes) of the software and external interfaces. Each requirement shall be defined such that achievement is capable of being verified and validated by a prescribed methods. (For more information about business functional requirements refer to IEEE Standard 830.) 4.2.1 Purpose 4.2.2 Contents
4.3 Architecture Design Document

Explains the purpose and content of the architecture design document including technical, application, communication and deployment. The software design description (SDD) depicts how the software will be structured to satisfy the business functional requirements. The architectural design document will describe the components and subcomponents of the software design including databases and internal interfaces. (Refer to IEEE Standard 1016 for more information about the Software Design Document.) 4.3.1 Purpose 4.3.2 Contents
4.4 Software Verification and Validation Plan

Describes the overall plan for the verification and validation of the software. Identifies and describes the methods (e.g., inspection, analysis, demonstration, or test) to be used to: Verify that requirements in the business functional requirements document have been approved by the appropriate authority, Verify that the requirements are implemented in the design, Verify that the design is implemented in the code, and Verify that the code, when executed, complies with the requirements defined in the Business Functional Requirements.
(Refer to IEEE Standard 1012 for more information about the Verification and Validation plans.) 4.4.1 Purpose 4.4.2 Contents
4.5 Software Verification and Validation Report

Describes the results of the execution of the Software Verification and Validation Plan including: Summary of all life cycle verification and validation tasks, Summary of task results, Summary of anomalies and resolutions, and Assessment of overall software quality,
(Refer to IEEE Standard 1012 for more information about the Verification and Validation plans.) 4.5.1 Purpose 4.5.2 Contents
4.6 Configuration Management Plan

Explains the purpose and content of the Configuration Management Plan (i.e., the methodical storage and recording of all software components and deliverables during development). The Software Configuration Management Plan documents methods to be used for the identification of software items, control and implementation of change, and recording and reporting change implementation status. The plan should describe methods used for: Identification of software configuration items, Control and implementation of change, Recording and reporting change and problem report implementation status, Conducting configuration audits, Review and approval cycles as well as approval authority, and Identification of personnel responsible for configuration management.
(Refer to IEEE Standard 828 for more information about the Configuration Management plans.) 4.6.1 Purpose 4.6.2 Contents
4.7 User and Operations Documentation

Explains the purpose and content of the user and operations documentation to be provided for the system, including user manuals, installation and operations manuals, on-line help, and training materials. User documentation (e.g., manual, guide, etc.) must specify and describe the required data and control inputs, input sequences, options, program limitations, and other activities necessary for successful execution of the software.
(Refer to IEEE Standard 1063 for more information about Software User Documentation.) 4.7.1 Purpose 4.7.2 Contents
5. STANDARDS
Describes the purpose of the standards to be applied in the design and development of the system. Specific standards for coding, data naming, user interfaces, report formats, and development tools will be itemized.
5.1 Coding Standards 5.2 Data Naming Standards 5.3 User Interface Standards 5.4 Static Report Format Standards 5.5 Development Tool Standards 5.6 Documentation Standards 5.7 Metrics 5.8 IEEE Standards (Refer to Appendix B) 5.9 IRMC Policies, Standards, Checklists
Page 11 of 30
02/07/03 8:18 AM
6. REVIEWS AND AUDITS

Describes how deliverable reviews, project management audits, and third party independent reviews will be employed to improve the quality of the system.
6.1 Deliverable Reviews

This section will describe the review process to be applied to project deliverables. The role of team members and tools experts will be explained as well as the process for reporting, tracking, and correcting errors found in the deliverables.
6.1.1 Software Requirements Review

The Software Requirements Review is held to ensure the adequacy of the requirements stated in the business functional requirements. 6.1.2 System Architecture Review The System Architecture Review is conducted to ensure application compliance to the State Technical Architecture. 6.1.3 Technical Design Review The Technical Design review is held to evaluate the technical adequacy of the software design and the acceptability of the design to satisfy business functional requirements. 6.1.4 Software Verification and Validation Plan Review The SVVPR is held to evaluate the adequacy and completeness of the verification and validation methods defined in the Software Verification and Validation Plan. 6.1.5 Software Configuration Management Plan Review The SCMPR is held to evaluate the adequacy and completeness of the configuration management methods defined in the Software Configuration Management Plan. 6.1.6 Implementation Plan Review This functional or in-process audit is held to verify that the software and the documentation are consistent. In-process audits may include: Code versus design documentation, Interface specifications, Design implementation versus functional requirements, Functional requirements versus test specifications.
Page 12 of 30 02/07/03 8:18 AM
Software Quality Assurance Plan 6.1.7 Post-implementation Maintenance Plan Review This review is held at the conclusion of the project to assess the development activities implemented and to provide recommendations for appropriate action.
6.2 Management Reviews

This section will explain the role of the independent auditor (third party independent QA reviewer) in the review of project management practices and process artifacts. It will describe the schedule and focus of the audits and specify the format of the audit reports. It will also include a focus on measuring tracking and progress towards this quality assurance plan.
6.2.1 Schedule 6.2.2 Third Party Independent Review Reporting Describes the format and process, and identifies who will receive the reports.
6.3 Product Reviews

This section will explain the role of the projects quality assurance specialist in the review of design and development processes. It will describe the schedule and focus of audits and specify the format of the audit reports. Product reviews would include: Peer Reviews Inspections Walk-throughs Prototype reviews JARs / JADS 6.3.1 Schedule 6.3.2 Review Reporting Describes the format and process, and identifies who will receive the reports.
7. TEST
This section will describe the verification and validation approach to be used by the project team to ensure that the system meets user requirements, functions as designed, and is free of defects. This section shall identify the tests to be performed (e.g., unit, system, integration, string, interface, regression, user acceptance) and the approach used to
Software Quality Assurance Plan accomplish the test. Describes the purpose and content of the test plan, which will detail the unit, integration, system, and user acceptance testing activities and identify the specific test cases to be performed at each stage of the verification and validation process.
7.1 Unit Test

This section will summarize the unit test approach to be employed by developers as they verify the functionality and performance of individual software modules. This test covers technical aspects of the software unit and is based upon the low-level design document. The section will describe any testing tools to be used and define the problem reporting, tracking, and correction process to be followed as unit tests are performed. 7.1.1 Approach 7.1.2 Responsible Party 7.1.3 Tools 7.1.4 Problem Reporting, Tracking, and Correction
7.2 Integration Test

This section will summarize the integration test approach to be employed by developers and quality assurance specialists as they verify that the software functions properly when individual software modules are linked together to form sub-system, which perform specific business functions prescribed in the user requirements document. This test covers functional aspects of the software unit and is based upon the high-level design document. The section will describe any testing tools to be used and define the problem reporting, tracking, and correction process to be followed as integration tests are performed. 7.2.1 Approach 7.2.2 Responsible Party 7.2.3 Tools 7.2.4 Problem Reporting, Tracking, and Correction
7.3 System Test

This section will summarize the system test approach to be employed by quality assurance specialists and users as they verify that the sub-systems function properly when they are linked together to form the Agency system. This test is based upon the functional specification document. The section will describe any testing tools to be used, describe the security interface to other systems, define the performance and regression testing procedures, and define the problem reporting, tracking, and correction processes to be followed as system tests are performed.
Software Quality Assurance Plan 7.3.1 Approach 7.3.2 Responsible Party 7.3.3 Tools 7.3.4 System Function Testing 7.3.5 Performance Testing 7.3.6 Regression Testing 7.3.7 Problem Reporting, Tracking, and Correction
7.4 User Acceptance Test

This section will summarize the user acceptance test approach to be employed by users as they verify that the (SYSTEM) meets their business needs. The section will describe any testing tools to be used and define the problem reporting, tracking, and correction process to be followed as acceptance tests are performed.
7.4.1 Approach 7.4.2 Responsible Party 7.4.3 Tools 7.4.4 Problem Reporting, Tracking, and Correction
Page 15 of 30
02/07/03 8:18 AM
8. Problem Reporting and Corrective Action

Defines the process for tracking and correcting problems identified within the audits. This section shall: Describe the practices and procedures to be followed for reporting, tracking, and resolving problems identified in both software items and the software development and maintenance process. State the specific organizational responsibilities concerned with problem resolution.
The purposes of problem reporting and corrective action systems are to: Assure that problems are documented, corrected, and used for process improvement, Assure that problem reports are assessed for their validity, Assume reported problems and their associated corrective actions are implemented in accordance with customer approved solutions, Provide feedback to the developer and the user of problem status, and Provide data for measuring and predicting software quality and reliability.
(For more information about software problems, refer to IEEE Standard 1044, Standard Classification of Software Anomalies.)
9. Tools Techniques, and Methodology

This section shall identify the special software tools, techniques, and methodologies that support software quality assurance activities, state their purpose, and describe their use. 9.1 Tools 9.2 Techniques 9.3 Methodologies 9.4 Code Control 9.5 Media Control 9.6 Security 9.7 Disaster Recovery 9.8 Supplier Controls 9.9 Records Collection, Maintenance, and Retention
Page 16 of 30
02/07/03 8:18 AM
10. TRAINING
This section will identify and provide a summary of the training activities to be provided for during system implementation. Details about training are to be provided in the Implementation Plan, another deliverable in this phase. This section will cover the responsible party, audience for the class, format for the class (e.g. classroom, one-on-one, CBTs), types of materials \ tools (e.g. workbooks, handouts, overheads), and the problem reporting, tracking and correction procedures. This section must also identify the training activities necessary to meet the needs of the SQAP.
10.1 User Training 10.2 Development Team Training 10.3 Transition to State Team Training
11. RISK MANAGEMENT

This section will describe the overall risk management approach to be employed for the project.
11.1 Project Self Assessment

Describes how a high-level project risk self assessment survey will be used to solicit input regarding potential risks and mitigation options from various team members.
11.2 Project Risk Assessment and Management Plan

Describes how project risk assessment and management methodology will be employed to identify risks and develop a risk mitigation plan.
11.3 Risk Review and Management Process

This section will describe the process that will be employed to ensure that risk factors are reviewed periodically and corrective actions are taken in a timely manner when problems arise.
11.4 Tools
This section will describe the tool(s) used to manage project risks.
Page 17 of 30
02/07/03 8:18 AM
12. LESSONS LEARNED

This section will identify the plan for closeout activities to review and document the overall lessons learned from the project and recommendations for improvement. Also, lessons learned activities include a plan for review of actual to plan performance and a summary of performance to quality goals and project metrics.
13. Document Approvals

This section is used to identify the appropriate parties and stakeholders needed to approve the Software Quality Assurance Plan. The approver's names, signature, and date of approval should be specified.
Page 18 of 30
02/07/03 8:18 AM
APPENDIX A - GLOSSARY OF TERMS

This appendix lists definitions for terms used in the project.
A Acceptance Criteria The list of requirements that must be satisfied prior to the customer accepting delivery of the product. Acceptance Test Formal user performed testing performed prior to accepting the system (sometimes called client acceptance test or user acceptance test). Acquisition Generic term for hardware, software, or services acquired from an outside vendor or contractor. Action Plan - A plan that describes what needs to be done and when it needs to be completed. Project plans are action plans. Activity - A specific project task, or group of tasks, that require resources and time to complete. Adaptive System Describes software that has flexibility as the primary design point. Application Generic term for a program, or system, that handles a specific business function. Application Software A complete, self-contained program that can perform work for a user. This is in contrast to system software such as an operating system, server processes, and libraries that exist in support of application software. Approval Cycle Process of gaining funding and management approval prior to project initiation. Architecture Imposes order and makes interconnections possible. Generally defined as an intermediate step between initial requirements and business functional specifications during which the entire complex of hardware, software, and design considerations are viewed as a whole. Refers to a blueprint for evolving a technical infrastructure. Assessment A general term for the formal management review of a process. Audit - A formal and detailed examination of the progress, costs, operations, results, or some other aspect of a project or system performed by an independent party. Availability The portion of time that a system that is scheduled to operate actually can be used as expected. B Baseline Plan - The initial approved plan to which deviations will be compared as the project proceeds.
Page 19 of 30
02/07/03 8:18 AM
Software Quality Assurance Plan Glossary of Terms* (continued)

Batch A term describing a method of operating computers. This method takes groups of transactions, executes them, and returns the results, all without human intervention. Backbone A high-speed computer network designed to interconnect lower-speed networks or clusters of dispersed user devices. Baseline A specification, or product, that has been formally agreed upon which serves as the starting point against which progress will be judged. Bench Mark A standard figure of merit which measurements or comparisons may be made. Bridge Devices that connect two separate networks. Once bridging is accomplished, the bridge makes interconnected networks look like a single network. Budget A planned sequence of expenditures over time with costs assigned to specific tasks and activities. C CASE Computer Aided Software Engineering - Systems that attempt to automate some or all of the tasks involved in managing, designing, developing, and maintaining software systems. Change Management The formal process of recording, analyzing, estimating, tracking and reporting of changes to the project baseline business functional requirements. Checkpoint A point in the development process at which project state, status, and results are checked, recorded, and measured. Client/Server System Primarily a relationship between processes running on separate machines. A client initiates the dialog by sending requests to the server asking for information or action. Confidence Level - A level of confidence, stated as a percentage, for a budget or schedule estimate. The higher the confidence levels the lower the risk. Configuration Management Methodical storage and recording of all software components and deliverables during development. Connectivity Refers to the ability to send and receive information between locations, devices, and business services. Contingency Plan - An alternative for action if the project does not proceed according to plan or if the expected results are not achieved. Control - A process for assuring that reality, or actual performance, meets expectations or plans. Cooperative Processing Computing that requires two or more distinct processors to complete a single transaction.

Cost / Benefit Analysis A formal study in which the development, execution, and maintenance costs for a project are matched against the anticipated value of the product. Critical Activity - A task, activity, or event that, if delayed, will delay another important event probably the completion of the project or a major milestone in the project. Critical Path Derived from the PERT method, this term implies the set of activities that must be completed in sequence and on time if the entire project is to be completed on time. A missed task on the critical path will cause a product delivery delay. This is the longest time for the project from beginning to end. Critical Path Method (CPM) - One of the two most common forms of networking systems. CPM uses a one-time estimate for creating a project schedule. D Data Describes the numbers, text, graphics, images, and voice stored in a form that can be used by a computer. Data Warehouse Where you consolidate and store data from many sources. Deliverable A tangible, physical object that is the output of a software development task. Dependency Diagram - Another name for a network or precedence diagram that shows the dependencies among tasks. Design The tasks associated with specifying and sketching the features and functions of a new application prior to coding. Development Project The sum of all tasks and activities necessary to build a software product. Document of Understanding A formal agreement between two parties. A contract which is sometimes referred to as a Statement of Work (SOW). Documentation The printed and displayed materials which explain an application to a user. Duration - The period of time over which a task takes place. Duration establishes the schedule for a project. E Effectiveness - A measure of the quality of attainment in meeting objectives. Efficiency - A measure of the volume of output received for the input used. Effort - The amount of work or labor (in hours or workdays) required to complete a task. Environment The set of tools and physical surroundings in which software is developed.

Estimate A predicted total of expenditures required to complete a task, activity, or project. Exit Criteria The set of conditions that must be met prior to completing a project phase or application. F Feasibility Project A project designed to prove, or disprove, the appropriateness of the technology solution under existing constraints (sometimes called proof-of-concept project). Float - The amount of time for a task to be freely scheduled without affecting other tasks in the project. G Gantt Chart A method of displaying overlapped and partially concurrent activities by using horizontal lines to reflect the time required by each activity. The chart, named for Henry Lawrence Gantt, consists of a table of project task information and a bar chart that graphically displays the project schedule to be used in planning and tracking. Gateway Hardware or software that translates between two dissimilar protocols. Granular Describes the art of writing small modules of code and / or objects. Graphical User Interface (GUI) A manner of presentation that makes use of windows, icons, menus, pointers, and scroll bards.
H Hardcode An informal term that describes a programming technique where data or procedures are specifically written into the program instructions. Hardware Physical equipment used to process, store, or transmit computer program data.
I Independent Review A formal examination of a project conducted by an organization other than the development organization. Information The meaningful interpretation of data. IRMC Information Resource Management Commission. Integration Describes the work, or device, required to connect two different systems that were not originally designed to work together.
Page 22 of 30
02/07/03 8:18 AM

Integration Test Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. Interface A connection between two devices or systems. Interoperability The ability to have applications and computers from different vendors work together on a network. Intranet An Internet network behind a firewall. Issue A problem to be solved or a decision that has not been made. J K L Lag - The amount of time after one task is started or finished before the next task may be started or finished. Lead - The amount of time that precedes the start of work on another task. Local Area Network (LAN) A communications system confined to a limited area, typically a building, occasionally a group, and linking computers together via cable. M Maintenance Refers to the ongoing activity that keeps software functioning in a technical and business environment (production). Methodology A set of formal protocols followed when performing a task. Middleware Software that hides the complexity of the networked computing environment from the users and application programmers. Milestone A major checkpoint in the activities involved in a project. A clearly defined point in a project that summarized the completion of a related set of tasks. Model - A way of looking at reality, usually for the purpose of abstracting and simplifying it to make it understandable in a particular context. Modular Programming Programming that has as its fundamental assumption that a large piece of software should be separated into its constituent parts or modules thereby making for easier and faster development and maintainability. Modules were traditionally called subroutines or functions and now are often called objects. N Network Describes the physical hardware and software connections between computers allowing information to be shared and electronic communications to take place.
Page 23 of 30
02/07/03 8:18 AM

Network Diagram - The logical representation of tasks that defines the sequence of work in a project. N-tier Architecture Describes a method for dividing an application into a series of distinct layers to provide for ease of maintenance and flexibility. O Operating System System software that controls data storage, input and output to and from the keyboard, and the execution of applications written for it. It performs base services: prioritizing work, scheduling, memory management, etc. P Padding - A standard project management tactic used to add extra time or money to estimates to cover for the uncertainty and risk of predicting future project activities. Package Acquisition The purchase, or lease, of software from an outside source. Path - A sequence of lines and nodes in a project network. PERT Project Evaluation and Review Technique - The PERT method uses the concepts of milestones, activities, and slack time to calculate the critical path. The chart, which resembles a flow chart, depicts a box to represent each project task and a line connecting two boxes to represent the relationship between tasks. Phases The divisions of a software development life cycle into discrete stages (e.g., requirements, design, code, test, etc.). Planning Project A project intended to gather, or predict, the sequence of activities and resources needed to complete a work effort. Platform The hardware and support software with which a program is intended to operate. Precedence - When one task must be completed before another task can be started, the first task is said to have precedence over the other. Process The step by step sequence of activities (systematic approach) that must be carried out to complete a project. Programming The art of writing, in a computer understandable language, a set of instructions that produces software. Project The combined resources (people, machines, materials), processes, and activities that are dedicated to building and delivering a product to a customer. Project Duration - The time it takes to complete the entire project. Project Management - The combination of systems, techniques, and people required to successfully complete a project on time and within budget.

Project Manager The senior person responsible for the entire project. Project Plan A formal document that describes the technical and management approach to be followed for a project. Project Sponsor The department customer who will authorize project initiation, and who will receive, accept, and use the software product or service. Protocol A set of rules and specifications that describes how a piece of software will behave and how other pieces of software must behave in order to work with the first piece of software. Q Quality (Product) - Conformance to business functional requirements with defect-free products. Quality reflects both the completeness of software or system features and functions, and errorfree operation. Quality (Process) Verification and validation to established policies, standards, procedures and guidelines for software development. Quality Assurance Within the State of North Carolina, the process tracking and oversight function for monitoring project performance, adherence to commitments, and budget requirements. Performed under the control of the Office of Information Technology Services (ITS), Enterprise Technology Strategies (ETS) staff. R Regression Test Selective re-testing to detect errors or faults introduced during modification of a system. Relational Database A collection of data that is organized into tables so that relationships between and among data can be established. Resource Leveling - The process of shifting resources to even out the workload of team members. RFP - Request for Proposal - Formal statement by a department that they are soliciting enterprises to bid on a contract for a program, system or service. Requirements The statement of needs by a user that triggers the development of a program, system, or project. May be called business functional requirements or requirement specifications. Research and Development Project A definition of a project type essentially exploring options for developing new systems or work products. Risk The probability that a project will experience undesirable events, which may create, cost overruns, schedule delays, or project cancellation. The identification, mitigation, tracking, and management of those elements creating the risk situation.

Risk Analysis - An evaluation of the feasibility or probability that the outcome of a project will be the desired outcome.
S Scalable A term describing an architecture or software that can handle expansion in the use as the need arises without adversely impacting systems management and operations. Scope - The magnitude of the effort required to complete a project. Server A computer on a network that makes applications, print services, data, and communications available. Slack - see float. Software Computer programs, systems, and the associated documentation that describes them. SDLC - Software Development Life Cycle The period of time that begins with the decision to develop a software product and ends when the software is delivered. Software Development Process The process by which user needs are translated into a software product. Specifications General term for the wide variety of paper-based descriptions of a program or system. Stakeholders - People who have a personal or agency interest in the end results of a project. Standalone Describes a computer workstation where the computer is not connected to any other computer on a network. Statement of Work (SOW) - An integrated set of task descriptions, goal descriptions, risks, and assumptions that accompany the evolving master project plan during development. Strategic Plan The long range plan where the horizon is usually three to five years time span. Subcontract - Delegating tasks or sub-projects to contractors or other organizations. System A linked collection of programs, or components, that perform a generic business or technical function. System Test The final stage of testing on a completed project (prior to client acceptance test) when all hardware and software components are put together and tested as a whole.
Glossary of Terms* (continued)


SDLC - System Development Life Cycle - The complex of tasks and deliverables that are organized toward developing software systems.
T Tactical Plan Specific improvements, or changes, that will be carried out in a fairly short time span (usually twelve (12) months). Task - A cohesive unit of work on a project (usually 40 to 80 hours of effort). Task Description - A description that defines all the work required to complete a project task or activity including input, output, expected results, and quality specifications. Test Plan A document that describes the scope, approach, resources, and schedule of intended test activities. Testing The set of defect removal tasks that include execution of all, or part, of an application on a computer. Topology The map or plan of a network.
U Unit Test - The testing carried out personally by individual programmers on their own code.
V W
Wide Area Network (WAN) A network where the computers are separated by significant distances and telecommunications links are implemented. Work Breakdown Structure (WBS) A formal analysis of the activities, tasks, and sub-tasks that must be accomplished to build a software project. A product or activity oriented hierarchy tree depicting the elements of work that need to be accomplished in order to deliver a product. Workstation Any machine with all of its installed storage, processing, and communications that can be either standalone or networked. X Y Z
Page 27 of 30
02/07/03 8:18 AM
* Definitions were extracted from Assessment and Control of Software Risks by Capers Jones (1994); Managing Software Development Projects (Second edition) by Neal Whitten (1995); IEEE Standards Collection: Software Engineering (1997 Edition); Best Practices in IT Architecture Planning and Implementation by Larry DeBoever; Essential Client/Server Survival Guide by Robert Orfali; and The Complete Idiot's Guide to Project Management by Sunny and Kim Baker.
Page 28 of 30
02/07/03 8:18 AM
APPENDIX B - STANDARDS
This appendix gives the complete text of the standards developed for this project.
IEEE Standards IRMC Project Proposal Checklist ETS Project Status Report State of North Carolina SDLC Model (Method/1) IEEE 730, Standard for Software Quality Assurance Plans IEEE 828, Standard for Software Configuration Management Plans IEEE 829, Standard for Software Test Documentation IEEE 830, Recommended Practice for Software Requirement Specification IEEE 1008, Standard for Software Unit Testing IEEE 1012, Standard for Software Verification and Validation Plans IEEE 1016, Guide to Software Design Description IEEE 1028, Standard for Software Review and Audit IEEE 1042, Guide to Software Configuration Management Plans IEEE 1044, Standard Classification for Software Anomalies IEEE 1045, Standard for Software Productivity Metrics IEEE 1058.1, Standard for Software Project Management Plans IEEE 1059, Guide for Software Verification and Validation Plans IEEE 1061, Standard for a Software Quality Metrics Methodology IEEE 1063, Standard for Software User Documentation IEEE 1074, Standard for Developing SDLC Processes IEEE 1219, Standard for Software Maintenance IEEE 1233, Guide to Developing System Requirement Specifications
* *
* *
* Compliance to these IEEE Standards is required for all projects.
Agency Standards Department SDLC Processes

. .
Page 29 of 30
02/07/03 8:18 AM
APPENDIX C - SUPPORTING DOCUMENTATION

This appendix provides an opportunity to attach related supporting documentation, which has been referenced in the Software Quality Assurance Plan. Supporting documentation may include: Software Development Plan Standards and Procedures Manual Software Project Management Plan (IEEE Standard 1058.1) Software Maintenance Schedule User Requirements Statement (IEEE Standard 1233 Guide for Developing System Software Requirements) External Interface Specifications Internal Interface Specifications Operations Manual Installation Manual Training Plan Training Manual Software Metrics Plan (IEEE 1061 Standards for Software Quality Metrics) Software Security Plan Software Capacity Plan
Page 30 of 30
02/07/03 8:18 AM

IEEEsqap

Uploaded by

Copyright:

Available Formats

IEEEsqap

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IEEEsqap

Uploaded by

Copyright:

Available Formats

Software Quality Assurance Plan

Software Quality Assurance Plan (SQAP) Template

Software Quality Assurance Plan

Agency Project Software Quality Assurance Plan

Software Quality Assurance Plan

Software Quality Assurance Plan

TABLE OF CONTENTS (CONTINUED)

8. Problem Reporting and Corrective Action

12. Lessons Learned

13. Document Approvals

Software Quality Assurance Plan

2. REFERENCE DOCUMENTS, DEFINITIONS, AND ACRONYMS

2.1 Reference Documents

2.2 Glossary of Terms

Software Quality Assurance Plan

2.3 Abbreviations and Acronyms

3.1 Project Organization

3.3 Activities and Tasks

3.4 Roles and Responsibilities

Software Quality Assurance Plan

4.1 Project Notebook

Software Quality Assurance Plan

4.2 Functional Specifications Document

4.3 Architecture Design Document

4.4 Software Verification and Validation Plan

Software Quality Assurance Plan

4.5 Software Verification and Validation Report

4.6 Configuration Management Plan

Software Quality Assurance Plan

4.7 User and Operations Documentation

Software Quality Assurance Plan

6. REVIEWS AND AUDITS

6.1 Deliverable Reviews

6.1.1 Software Requirements Review

6.2 Management Reviews

6.3 Product Reviews

7.1 Unit Test

7.2 Integration Test

7.3 System Test

7.4 User Acceptance Test

Software Quality Assurance Plan

8. Problem Reporting and Corrective Action

9. Tools Techniques, and Methodology

Software Quality Assurance Plan

11. RISK MANAGEMENT

11.1 Project Self Assessment

11.2 Project Risk Assessment and Management Plan

11.3 Risk Review and Management Process

Software Quality Assurance Plan

12. LESSONS LEARNED

13. Document Approvals

Software Quality Assurance Plan

APPENDIX A - GLOSSARY OF TERMS

Software Quality Assurance Plan Glossary of Terms* (continued)

Software Quality Assurance Plan Glossary of Terms* (continued)

Software Quality Assurance Plan Glossary of Terms* (continued)

Software Quality Assurance Plan Glossary of Terms* (continued)

Software Quality Assurance Plan Glossary of Terms* (continued)

Software Quality Assurance Plan Glossary of Terms* (continued)

Software Quality Assurance Plan Glossary of Terms* (continued)