What SQA Resource are you searching for?

SQA TASK PROFILES

• Posted by author on December 31st, 2008 filed in SQA - Advice Center
• Comment now »

SQA Definition: A planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical REQUIREMENTS. (ANSI/IEEE Std 730-1984)

The SQA task definition leads to three possible task profiles: 1 – Minimal Conformance Profile top SQA task is limited to verifying the conformance of deliverable items to software engineering standards stated in the project contract (usually military standards or ANSI/IEEE standards) or conformance to corporate standards (usually patterned after military standards or ANSI/IEEE standards and modified to corporate or project environment). The additional conformance tasks relate to traceability checks. Thus, SQA traces design to requirements, test cases to requirements and checks conformance to interface control document. The SQA conformance profile ensures that deliverable items including documentation is according to standards” detects mechanic interface errors, supports traceability of life-cycle phases to requirements,’ checks that configuration management, problem reporting and corrective actions are handled properly. Interface and traceability checks can be automated depending on project software engineering environment. The SQA conformance profile is characterized by the mechanical nature of its tasks. In this profile SQA personnel qualifications are those of librarians or technicians. The SQA conformance profile satisfies neither ANSI/IEEE Std 730-1984 nor MIL-S-52779A.

The SQA definition of providing adequate confidence that the product conforms to REQUIREMENTS cannot be achieved by mechanical checks that documents have paragraph titles as listed in standards. The means for providing the required confidence must be provided by SQA software engineering. The minimal SQA conformance profile is attractive to many companies, since it requires a minimal budget allocation to SQA, usually less than five percent of the software development budget. Also, SQA work (of this kind) is not attractive to senior software engineers, so that even if budgets are available this is the only task profile which the available SQA manpower is capable of providing. The image of SQA in the seventies was a librarian checking the labels of magnetic tapes. Unfortunately, this image has not been completely erased despite extensive educational efforts by the military and professional organizations. Most DOD-STD-2168* assessments are covered by the minimal profile.

NB> DOD-STD-2168* cancelled on 20 March 1995 and merged into Mil-STD-498, which superseded DOD-STD-2167A, DOD-STD-7935A, and DOD-STD-1703. MIL-STD-498 in turn was cancelled in June 1998 when IEEE/EIA 12207 was released.

2 – Audit Profile top

SQA must have senior Systems and software engineers capable of auditing the CONTENTS of deliverable documentation. The qualifications of SQA manpower for this profile are most demanding. SQA engineers must have prior experience and proven capability in defining and implementing projects audited. For instance, auditing of an avionics operating flight program O.F.P project would require a team consisting of pilots, systems engineers and senior software engineers that have specified previous or similar projects. Surely, a junior programmer or librarian is useless in this profile. Furthermore, it is emphasized that an SQA team in the auditing profile must have an interdisciplinary capability and it must be understood that junior people cannot grow to such tasks at the expense of projects. The excuse of hiring junior programmers for SQA, because nobody else is available, is not acceptable. In such circumstances it is preferable to refrain from SQA auditing and not to audit punctuation in documents.

It is the responsibility of both the customer, corporate management, project office and, of course, the SQA manager to evaluate the capability of the SQA team to fulfill the required auditing profile. The auditing profile itself is not resource intensive. Usually around ten per cent of budgets is sufficient. The real problem is that top quality manpower is required. Both ANSI/IEEE Std 730-1984 and MIL-S-52779A require SQA auditing profile. SQA auditing is a major issue in configuration management. DOD-STD-2168* auditing profile is limited and most of this DoD standard relates to issues covered by the minimal conformance profile. The DoD standard nevertheless requires an independent assessment role.
3 – Verification, Validation and Testing Profile top

Neither ANSI/IEEE Std 730-1984 nor MIL-S-52779A explicitly state that SQA shall conduct verification, validation and testing. The definition that SQA shall provide adequate confidence that the product conforms to established REQUIREMENTS is usually interpreted that SQA plan shall reference or document procedures to assure the accomplishment of VV&T objectives. Thus, MIL-S-52779A requires SQA assurances for the following objectives:

a. Analysis of software requirements to determine testability (a major challenge for the SQA auditing profile).

b. Review of test requirements and criteria for adequacy, feasibility, traceability and satisfaction of requirements (requirements for the SQA auditing profile).

c. Review of test plans, procedures, and specifications for compliance with contractor and contractual requirements, to assure that all authorized and only authorized changes are implemented (SQA auditing profile with interface to configuration management).

d. Verification that tests are conducted in accordance with approved test plans and procedures (requirement for SQA at least to participate in testing).

e. Certification that test results are the actual findings of the tests (requirement for SQA to participate in testing and to monitor testing).

f. Review and certification of test reports (as above).

g. Assurance that test related media and documentation are maintained to allow repeatability of tests (SQA assurance of auto regression testing requires involvement both in testing and configuration management).

h. Assurance that support software and computer hardware to be used to develop and test software and hardware under the contract are acceptable.

MIL-S-52779A does not explicitly require SQA to perform tasks a-h, but SQA is held responsible for the accomplishment of a-h. It is the task of both customer, corporate management, project offices and, of course, SQA management to evaluate as to whether SQA is capable of undertaking the above responsibility.

ANSI ‘ /IEEE Std 983-1986 Guide for SQA Plans states software verification and validation plan and report as compulsory deliverable items, states the required contents, and explicitly states that SQA is responsible for the reviews of these deliverable items. Again, SQA role for VV&T shall include auditing but need not be restricted to auditing according to both military and ANSI/IEEE standards.

The VV&T profile of SQA should in the author’s opinion be entrusted to an independent organization external to the supplier company. The IVV&T shall be directly subordinated to customer. Basically, full scale IVV&T for critical projects requires management of a parallel project with a complete life-cycle. The resources required for IVV&T may even exceed those allocated to supplier software development.

Extensive IEEE/ANSI standardization efforts for verification and validation plans and guide for implementing such plans are under way.