Software quality

Arthus LJ. Measuring Programmer Productivity and Software Quality. New York Wiley, 1985. 

Ince D, ed. Software Quality and Reliability. London Chapman and Hall, 1991. 

GMP risk assessment Qualified/trained resource System life-cycle validation System environment Current specifications Software quality assurance Formal testing/acceptance Data entry authorization Data plausibility checks Communication diagnostics Access security Batch release authority Formal procedures/contracts Change control Electronic data hardcopy Secure data storage Contingency/recovery plans Maintenance plans/records... 

System design and development teslmg under Supplier s Software Quality Ass ura nee Progra m... 

The computer system supplier s detailed project and quality plan incorporating the procedures for software quality assurance should be one of the first contracted deliverables, if not already submitted as part of the quotation or requested during precontract discussions. 

The software design specification is written by the system supplier and must identify how the supplier intends to provide system software under a software quality assurance plan. The design specification must describe the subsystem software that will make up the computer system software and subsystem interfaces to implement the aims set out in the FDS. Each subsystem should be traceable back to statements in the FDS. 

A decision not to perform the review (e.g., evidence that code is developed under a quality system and formal reviews have already been conducted and reported) should be documented in the project validation plan, complete with the rationale. It is recognized that under its software quality assurance program the supplier may conduct similar examination of the software using only internal resource. Considering GMP implications, the pharmaceutical manufacturer would normally require that the software designer or programmer does not carry out any software review in isolation. 

In many instances operating system software has already been developed and is offered as a fundamental part of the computer system ready for application software to be developed or configured. In such cases it is prudent to establish the existence of the respective software quality assurance plans and procedures and the design, development, and testing records. Identification and examination of this documentation can be conducted and recorded as part of the supplier audit. (See Sec. VI.)... 

Supplier prequalification response Supplier audit report Project and quality plans Software quality assurance plan Commercial and purchasing specs. 

Project Quality Plan Software Quality Assurance Program Functional Design Specification Hardware Design Specification Software Design Specification Software Module Design Specification Software Review Software Module Test Records Hardware Test Records Integration Test Records Instrument Spccs/Data Sheets Instrument Calibration Records Material Certificates... 

The TickIT Guide—Using ISO 9001 2000 for Software Quality Management System Construction Certification and Continual Improvement. British Standards Institution (January 2001, issue 5.0). 

The integrity of the information managed by a computer system is protected by procedural controls, rather than the technology used to apply the controls. Procedural controls comprise any measures taken to provide appropriate instructions for each aspect of system development, operations, calibration, and validation. For computer systems, procedural controls address all aspects of software engineering, software quality assurance, and operation. In a regulated environment, these controls are fundamental to the operation of the computer system. 

Validation plan A multidisciplinary strategy from which each phase of a validation process is planned, implemented, and documented to ensure that a facility, process, equipment, or system does what it is designed to do. May also be known as a system or software Quality Plan. 

Computer system operating environment System description Software quality assurance Built-in entry and processing checks Testing... 

The definition of supplier validation activities and documentation should be embedded in contractual agreements. In addition, suppfiers should agree to potential inspection by GxP regulatory agencies and Supplier Audit by pharmaceutical and healthcare companies. Supplier Audits can be conducted by the pharmaceutical or healthcare company s own personnel or, if this would compromise the supplier s commercial interests, by an independent software quality assurance auditor, consultant, or validation expert employed by the pharmaceutical or healthcare company. Auditors must be suitably qualified, for example by independent certification by examination to the quafity system standards such as ISO 9001 2000. Suppfier Audits are discussed in detail in Chapter 7. 

Howard Garston-Smith, formerly of Pfizer, has published a book on software quality assurance. It provides a postal audit checklist reproduced in Appendix 7C. If the supplier has already prepared an internal ISO 9000 mapping or an internal audit report on how it aligns to industry standards such as the GAMP Guide, this can be offered as an alternative to the auditor s postal checklist. A reduced postal checklist may be agreed upon, at the very least. Wherever possible, photocopies of actual example documents and test records should be inspected for documentary evidence of validation. Remember that the pharmaceutical and healthcare companies are themselves being inspected for documentary evidence of validation. 

Garston-Smith, H. (1997), Software Quality Assurance — A Guide for Developers and Auditors, ISBN 1-57491-049-3, Interpharm Press, Buffalo Grove, IL. 

The adoption of good practices such as those defined by GxP validation should improve software quality. Original document sets need to be reviewed after a number of changes have been implemented to see if a new baseline set of documents needs to be generated. 

Upgrade Versions Caution is needed when implementing new versions or bug fixes to standardized apphcations. Release documentation should coufirm coutiuued quality of software. If serious doubts exist over software quality, commouseuse should prevail aud the software should be treated as customized or eutirely bespoke, aud heuce require full validation. 

Maxwell, K.D. (2002), Applied Statistics for Software Managers, Software Quality Institute Series, Prentice Hall, Upper Saddle River, NJ. 

Are software quality assurance issues not resolved by the project addressed by senior management ... 

Audits should be conducted by suitably trained/qualihed personnel against the applicable ISO 900Cb series standard, with special reference being made to software quality guidelines (e.g., ISO 9000-3, TicklT ) for instrument systems involving software. The software audit may cover the development of both application software and core (operating system level) software, depending on the type of system to be supplied. Follow-up audits should be considered. 

ANSI (1989), IEEE Standard for Software Quality Assurance Plans, ANSI/IEEE Std. No. 730.1-1989, The Institute of Electrical and Electronic Engineers, New York. 

TickIT Guide (2000), A guide to Software Quality Management System Construction and Certification using IS09001 2000, Issue 5.0, DISC/BSI TickIT Office, London. 

The majority of analytical processes in regulated environments rely on computer control for automation and for data capture and evaluation. It is therefore important that not only is the instrument validated but also the computer and operational software. Validation of software is more complex than hardware validation, especially since source codes for many analytical processes can run to several hundred thousand lines. In this case the responsibility for validation still remains with the user, who should have the assurance that the computer system has been validated during and at the end of the DQ phase. The vendor should provide documentation with a declaration that the software has been validated to these or similar guidelines to ensure software quality standards. Further, the vendor should provide access to the source codes if required by the user. 

The TickIT guide to software quality management system construction and certification using EN 29001, Issue 2, February 1992. Available from the DISC TickIT Office London... 

---