Validation and regulatory compliance of free/open source software - Open Source Software in Life Science Research - page 489

good software development practices and an understanding of software
validation in the life sciences industry. Experience is that the development
and validation of regulatory signifi cant applications is best accomplished
by real subject matter experts.
Where business process owners wish to contribute to the development
of open source solutions, this is perhaps best achieved by defi ning clear
requirements and executing user acceptance testing. In many cases the
setup and use of the software may follow a 'trial and error' process - this
may often be the case where documentation is poor or out of date. It is
acceptable to follow such a prototyping process, but all requirements and
specifi cations should be fi nalised and approved before moving into
formal testing of the software.
Prior to formal testing, the software and associated documentation
should be placed under change control, document and confi guration
management. It is unlikely that open source community controls will be
adequate to provide the level of control required in the regulated life
sciences industry (see below) and the regulated company will usually
need to take responsibility for this.
It is worth noting that there are a small number of open source software
tools on the market providing basic change control, confi guration
management, document management and test management functionality
(e.g. Open Technology Real Services [24], and Project Open OSS [25] IT
Service Management suites). Although these do not require formal
validation, they should be assessed for suitability to ensure that they
function as required, are secure and will be supported by the development
community for the foreseeable future. Important areas to consider here
are described in Figure 21.5.
Depending on the outcome of the risk assessment and the nature of the
software, testing may consist of:

￿ ￿ ￿ ￿ ￿

■ unit and integration testing of any custom developed functions. This
may take several forms including:
￿ white box testing (suitable where the custom function has been
developed by the regulated company and the structure of the
software is known),
￿ black box testing (where the custom function has been
developed in the open source community and the structure of the
software is not known - only input conditions and outputs can be
tested),
￿ positive case testing, and where indicated as applicable by risk-
assessment, negative case, challenge or stress testing;