Availability of Software and Reference Documentation

Another important aspect to take into consideration is access to proprietary source code and associated documentation. All custom (bespoke) appfication-specific software and reference doc- 

Regulators now expeet formal access agreements to be established (e.g., escrow accounts) where access to application software and associated reference documentation is restricted. It is generally accepted that formal access agreements for operating systems, compilers, and system software are urmecessary since the ubiquity of such systems provides adequate implied evidence of their fitness for purpose. Access agreements should be kept up to date current and historical software versions should be covered by their respective documents and revisions. 

Validation approaches for both the hardware and software of computer systems need to be considered  

The fitness for purpose of a proposed solution should be assessed and any history of usage in similar applications considered when determining the validation strategy. A holistic perspective should be taken with computer systems comprising components found in multiple categories of software and hardware. 

---

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. 

Prosite is perhaps the best known of the domain databases (Hofmann et al., 1999). The Prosite database is a good source of high quality annotation for protein domain families. Prosite documentation includes a section on the functional meaning of a match to the entry and a list of example members of the family. Prosite documentation also includes literature references and cross links to other databases such as the PDB collection of protein structures (Bernstein et al., 1977). For each Prosite document, there is a Prosite pattern, profile, or both to detect the domain family. The profiles are the most sensitive detection method in Prosite. The Prosite profiles provide Zscores for matches allowing statistical evaluation of the match to a new protein. Profiles are now available for many of the common protein domains. Prosite profiles use the generalized profile software (Bucher et al., 1996). 

There are no detailed specihcation documents for any of the computerized process control systems that contain sufficient information on how these systems/software were represented and developed. The only specification documents made available and referred to as the design document were the system specifications however, these documents only provide a high-level explanation of what the systems do. They lack sufficient detailed description of specihc and complete data structure, data control flow, design bases, procedural design, development standards, and so on to serve as the model for writing code and to support future changes to the code. [FDA 483, 2000]... 

Acceptance testing of software must be conducted and documented. Written documentation of change control procedures must exist to provide a reference and guidance for management ofthe ongoing software change and maintenance process. All steps in this process should be explained or clarified, and the procedures should be available to all system users. 

National consensus standards that pertain specifically to computer software are available for reference, such as ANSI/IEEE Standard 730-2002 (IEEE, 2002). The user of equipment driven by software should refer to such documents to understand how the software will react under given conditions. When a user is unfamiliar with the intricacies of a software program, the results and their presentation are open to question. 

Process Model It is possible that misunderstandings (an incorrect model) about the thoroughness of the development process led to a failure to provide requirements and processes for performing software checks at the launch site. Complacency may also have been involved A common assumption is that software does not fail and that software testing is exhaustive, and therefore additional software checking was not needed. However, this is speculation, as the report does not explain why management did not provide documented requirements and procedures to review the launch data nor ensure the availability of references for comparison so that discrepancies could be discovered. 

The idea of having available rapid methods to respond to requests for product sensory information is, as already noted, essential. However, such a resource means having subjects who have the necessary sensory skill and experience to provide information that can be relied on. This also means that one should not select subjects at random or use software for analysis that is not understood. While some legacy methods require many weeks of training, some do not. The sensory staff has to decide what is the best approach to take in developing capabilities so that best use is made of available resources. The choices are documented here along with reference to where more details can be found. 

We found various resources and tools that were available to organize and maintain information, which were generally easy to use. We used the following software available on the Internet to manage this project. Refer to Figure 1, Planning Your Document and Figure 2, Basic Coordination of Literature and Media . 

PLCs are poorly supported by software tools when compared to other software approaches. In particular, tool support for testing is weak e.g. test harnesses and test coverage tools are not available. Tools are available to aid documentation and principally to cross reference use of variables. The most recent developments have occurred in the areas of simulation and emulation with a view to improving testing. 

To install ID WIN-NMR, 2D WIN-NMR and GETFILE, stored on your CD-ROM, you must first have installed the MS-DOS operating system version 3.3 or higher and MS-WINDOWS version 3.1 or higher, e.g. WINDOWS 98 or WINDOWS NT on your PC. Please refer to the documentation that came with these products for how to do this. Note The installation and the starting of the software tools (2.3.2 - 2.3.5), the copy of the NMR data (2.5.5) and the description of a few useful WINDOWS options (2.5.6) is demonstrated for a PC under a MS-WINDOWS 98 environment. However the corresponding operations and options are also available with MS-WINDOWS 3.1 (3.11), MS-WINDOWS 95 or MS-WINDOWS NT. 

Software Preliminary Hazard Analysis This type of analysis is used to identify software program routines that are considered to be safety-critical, and thus is conducted prior to software program coding. To perform the analysis, the analyst should make reference to any available system specifications, interface documentation, functional flow diagrams, software flowcharts, storage and file allocation specifications, and any other program descriptive information. 

---