Source Code Reviews

Laboratories utilizing automated data collection systems must provide such control of those systems that current and future system performance can be assured and that data integrity can be maintained. Consistent, accurate, and reliable system performance depends on the control of laboratory facilities and equipment requirements, as well as software requirements. Functional testing, a requirement for both equipment and software, and source code review of software are also required to provide control of system performance. 

Consistent and proper operation of any software system is dependent upon the decision and action formulae or algorithms included in the code. With a poorly designed algorithm, interim problems may not be obvious in testing, but may cause significant difficulties over time. Similarly, improper formulae may work properly with some data sets, but may malfunction with unusual or outlier data points. Examination and confirmation of appropriate formulae is a critical part of any source code review. 

A Source Code Review must be performed on application software unless there is evidence from the Supplier Audit that the source code has been, or will be, developed in a quality assured manner and subjected to review as part of its development life cycle. The decision and justification not to perform a review must be documented within the Validation Plan. 

The Source Code Review aims to provide confidence in the operability of the system and, as such, has hve basic objectives ... 

Recommend testing from Source Code Review... 

Study) Source Code Review X X Design Qualification) Configuration only for Category 4 software... 

Source Code Review for bespoke code/macros. 

URS Reference Functional Specification Reference Design Specification Reference DQ Reference Source Code Review Reference... 

Source Code Reviews have four basic objectives ... 

The Source Code Review must systematically cover all aspects of the software, with particular attention to GMP elements of functionality. The risk assessment process presented in Chapter 8 can be used to select which software will be subjected to the most detailed inspection (a threshold risk score will need to be set to determine when a detailed review is required). All configurations should be checked against specification. 

Supplier Audits should always include the review of a sample of code to ensure compliance with quality system standards, though such a review will never pretend to assume the rigor of a formal Source Code Review. Where suppliers withhold software listings, access agreements should be established and refer to the availability of software and reference documentation in Chapter 11. 

The outcome of the Source Code Review will be a report providing an overview of the review, together with a list of all observations noted and all actions that must be completed. Specific statements on software structure, programming practice, GMP-related functionality, information transfer with other portions of the system or other systems, error handling, redundant code, version control, and change control should be made before an overall conclusion on the suitability and maintainability of the software is drawn. A copy of annotated software listings should be retained with the report. 

Generally, widely distributed Off-The-Shelf (OTS) software is not considered to need Source Code Review if a reputable developer has produced it under an effective system of quality assurance and the product requires no more than an application parameter configuration. In most computer systems, therefore, Source Code Reviews are limited to custom (bespoke) software and configuration within OTS software products. 

The effectiveness of Source Code Review is often questioned. Programmers alone should not inspect their own code because it is difficult to be objectively critical of one s own work. The objectivity of others and a willingness to accept criticism are key to any review process. Left to themselves, programmers error detection rates on their own codes can be as low as 5%. Where a reviewer conducts the inspection in partnership with the software author, error detection rates can rise to 30% or more so long as it is not treated as a superficial, cursory activity. The time saved in taking corrective action on exposed errors, particularly the structural ones, in advance of testing usually more than justifies the involvement of a colleague. 

Examples of real problems identified in Source Code Reviews include ... 

For a PLC or the configuration of a small Distributed Control System (DCS), the Source Code Reviews will typically require about 4 days effort, split between an independent reviewer and the software programmer. The reward of identifying and correcting defects prior to Development Testing or User Qualification has proved time after time to more than compensate for the time and effort required to carry out the Review. It really is the most cost-effective way of building quality into software. 

It is vital that the QA environment is maintained nnder strict configuration management. There should be no software development in the QA environment. Software should be prepared in the development environment and then, when completed, transported to the QA environment. Source Code Reviews should be conducted in the QA enviromnent. If this approach is taken, strict configuration management and change control within the development enviromnent is not required, and it should facilitate faster software development. 

Summary of key hndings and correchve actions from the Source Code Review. 

The general approach to retrospective validation is the same as for prospective validation (see Chapter 6 to Chapter 11). However, it may not be possible to condnct some prospective activities such as Supplier Audits if the supplier is no longer trading. Source Code Reviews if there is no access to source code and relevant design documentation, and Development Testing if detailed design information is not available. Historical records demonstrating reliable operation may be available to aid validation. 

A Design Review should be conducted before testing begins. This will normally involve developing a Requirements Traceability Matrix (RTM). If no detailed design information is available then cross-references should be made between the newly prepared System Specification, available operator manuals, and user procedures. Source Code Reviews will be expected for custom (bespoke) software under the control of the pharmaceutical or healthcare company, and redundant code identified should be removed. 

The combination of effective design reviews and source code reviews should reduce overall project costs by about 10% compared to projects not implementing these reviews. (This saving is achieved by detecting errors before testing.)... 

Source Code Reviews are used to ensure that controlled development and a consistent programming style have been used. It also checks GMP critical features. Source Code Reviews need a standard against which to check, and programming practices for all programs should be documented. An audit of the supplier s compliance with its own quality management procedures should have been carried out to ensure that appropriate quality is being built into the system. 

The risk assessment would identify the need for a configuration or source code review against critical code modules. 

Computer Room Environment Configuration and source code review... 

Good Programming Practice and Source Code Reviews (SCR).719... 

---