IEEE 730-2002 pdf download IEEE Standard for Software Quality Assurance Plans
4.3.3 Roles and responsibilities
This section shall identify the specific organizational element that is responsible for performing each task
4.3.4 Quality assurance estimated resources
This section shall provide the estimate of resources and the costs to be expended on quality assurance andquality control tasks.
4.4 Documentation (section 4 of the SQAP)
4.4.1 Purpose
This section shall perform the following functions:
2Identify the documentation governing the development, verification and validation, use, and maintenance of the software.
6)List which documents are to be reviewed or audited for adequacy. For each document listed, identifthe reviews or audits to be conducted and the criteria by which adequacy is to be confirmed, with reference to section 6 of the SOAP
4.4.2 Minimum documentation requirements
To ensure that the implementation of the software satisfies the technical requirements, the followingdocumentation is required as a minimum.
NOTE-Names of various artifacts listed below use the terminology contained in IEEE/EIA 12207.1-1997 B18). Thecontent of these documents may be included in other documents as long as traceability to the required information ismaintained; e.g., a reference in that section of the document or a traceability table.
4.4.2.1 Software requirements description (SRD)
The SRD should specify requirements for a particular software product, program, or set of programs thatperform certain functions in a specific environment. The SRD may be written by the supplier (internal olexternal), the customer, or by both. The SRD should address the basic issues of functionality, externalinterfaces. performance, attributes, and design constraints imposed on implementation. Each requirementshould be uniquely identifed and defined such that its achievement is capable of being objectively verifiedand validated (see IEEE Std 830″-1998 B5]).
4.4.2.2 Software design description (SDD)
The SDD should depict how the software will be structured to satisfy the requirements in the SRD. The SDDshould describe the components and subcomponents of the software design, including databases and internal interfaces. The SDD may be prepared first as the architecture design (also sometimes referred to as the top-level SDD) and should be subsequently expanded to produce the detailed SDD (see IEEE Std 1016″-1998B11).
4.4.2.3 Verification and validation plans
Verification and validation processes are used to determine if developed software products conform to theirrequirements, and whether the software products fulfill the intended use and user expectations. This includesanalysis, evaluation, review, inspection, assessment, and testing of the software products and the processesthat produced the products. Also, the software testing, validation, and verification processes apply whenintegrating purchased or customer-supplied software products into the developed product.
The verification plan should document the verification tasks and the validation plan should document thevalidation tasks. If desired, the verification plan and validation plan may be packaged together in a singledocument. Each plan defines the verification and validation tasks and required inputs and outputs needed tomaintain the appropriate software integrity level. lt also provides a means of verifying the implementation ofthe requirements of the SRD in the design as expressed in the SDD and in the testing as expressed in theproject’s test documentation (see IEEE Std 829″-1998 B4], EEE Std 1008″-1987 B8,and EEE Std1012”-1998[B91.and EEE Std 1012a”-1998B101)
4.4.2.4 Verification results report and validation results report
The verification results report should describe the results of the software verification activities conductedaccording to the verification plan. The validation results report should describe the results of the software
test or validation carried out according to the validation plan.
4.4.2.5 User documentation
User documentation guides the users in installing, operating, managing, and maintaining (does not applywhen modifying software source code) software products.
The user documentation should describe the data control inputs, input sequences, options, programimitations, and all other essential information for the software product. All error messages should beidentified and described. All corrective actions to correct the errors causing the error messages shall bedescribed. The documentation is applicable to any portion of the embedded software with which the userinteracts directly.(see IEEE Std 10631987 B141)
IEEE 730-2002 pdf download
PS:Thank you for your support!
