Chapter 15
Downloaded by UNIV OF CALIFORNIA SAN DIEGO on December 22, 2015 | http://pubs.acs.org Publication Date: August 1, 2002 | doi: 10.1021/bk-2002-0824.ch015
Documentation Requirements for the Design of Good Laboratory Practice Software Robert D. Walla Astrix Software Technology,Inc.,Suite 302, 175 May Street, Edison, NJ 08837
Validation of computerized systems is required by many regulations, quality programs, and company standards. The process of designing software systems that are subjected to validation must be conducted under strict procedures with adequate documentation. The process of designing the system must be well documented and strict controls should be in place to insure the system will ultimately pass validation. The system developer plays a key role in insuring that the system being designed meets minimum documentation standards necessary to satisfy the needs of the validation team. This paper will describe the "best practices" that a software developer should follow to adequately document the design phase of a system that will ultimately be used as a GLP system.
Overview The term validation has been defined in the literature by many different authors and sources. The most commonly accepted definition of validation can
© 2002 American Chemical Society
In Capturing and Reporting Electronic Data; Garner, Willa, et al.; ACS Symposium Series; American Chemical Society: Washington, DC, 2002.
109
110
Downloaded by UNIV OF CALIFORNIA SAN DIEGO on December 22, 2015 | http://pubs.acs.org Publication Date: August 1, 2002 | doi: 10.1021/bk-2002-0824.ch015
be found in the guideline General Principles of Validation. "Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes." The approaches that different companies take to satisfy this requirement are varied. This paper will discuss the steps that a software vendor should follow to adequately document a system that will be subjected to validation testing.
Project Assessment and Development The Product Development Cycle for software that is subject to validation testing is composed of discrete steps that are characterized by rigorous quality control, continuous user feedback, and thorough documentation. The process begins with an assessment of the business needs (Figure 1). The requirements of the system are identified by meeting with the target users. Once the system requirements are known and use cases are designed a technical architecture is proposed. The architecture must employ technology that has a proven and dependable track record. A Project Assessment document is generated, that details the use, benefit, and preliminary budget for the system. Once the project team has completed the assessment phase, the planning phase will begin. The project team will assemble the following documents: Project plan, quality assurance plan and system test strategy. The complete design of the system will be detailed in the system specification. Once the design is complete and approved the system will transition into production.
Requirements Definition Phase The developer must meet with the users and content experts to understand the user's needs. A core team of client content and business and information technology leads must be organized to interact with the business assessment team. Typically, a series of meetings will be scheduled to allow the developer to gather the necessary information to complete the clients' needs and objectives. The requirements will be separated into logical groupings: Functional, technical, reporting, etc. The requirements will also be ranked according to their priority. The developer should utilize a requirements database to manage the user requirements gathered during this phase. A printout of the requirements should be available upon request.
In Capturing and Reporting Electronic Data; Garner, Willa, et al.; ACS Symposium Series; American Chemical Society: Washington, DC, 2002.
In Capturing and Reporting Electronic Data; Garner, Willa, et al.; ACS Symposium Series; American Chemical Society: Washington, DC, 2002.
Business Case Development
Assessment
Planning
Project
Production
Detail Design
Figure L Assessment and Development.
Architecture Design
Business Assessment
Development
Downloaded by UNIV OF CALIFORNIA SAN DIEGO on December 22, 2015 | http://pubs.acs.org Publication Date: August 1, 2002 | doi: 10.1021/bk-2002-0824.ch015
Implementation
112 A technical architecture will be proposed after the requirements definition phase is completed.
Downloaded by UNIV OF CALIFORNIA SAN DIEGO on December 22, 2015 | http://pubs.acs.org Publication Date: August 1, 2002 | doi: 10.1021/bk-2002-0824.ch015
Technical Architecture Phase The architecting process incorporates a technical process and an organizational process. The technical process includes steps and heuristics for creating a good architecture. However, a technically good architecture is not sufficient to ensure the successful use of the architecture, and the organizational process is oriented toward ensuring support for, and adoption of, the architecture. The architecture should be documented using adequate tools that show the relationships of the various architectural components and their interaction.
Logical Data Design After the requirements are gathered and the technical architecture is finalized the database will be designed to accommodate the business needs. A conceptual entity-relationship model shows how the business world views information. It suppresses non-critical details in order to emphasize business rules and user objects. It typically includes only significant entities that have business meaning, along with their relationships. A conceptual model may include a few significant attributes to augment the definition and visualization of entities. A logical entity-relationship model, the blueprint for building an application, is a normalized diagram of data that is used by the business. A logical data model requires a complete scheme of identifiers or candidate keys for unique identification of each occurrence in every entity. Since there are choices of identifiers for many entities, the logical model indicates the current selection of identity. Propagation of identifiers as foreign keys may be explicit or implied. The conversionfromthe logical to physical data architecture is a nonlinear process and will require additional planning and coordination between the developer and the users. Several volumetric parameters must be evaluated including: • •
User population data access characteristics Table usage
In Capturing and Reporting Electronic Data; Garner, Willa, et al.; ACS Symposium Series; American Chemical Society: Washington, DC, 2002.
113
• •
Table growth Table row populations
Downloaded by UNIV OF CALIFORNIA SAN DIEGO on December 22, 2015 | http://pubs.acs.org Publication Date: August 1, 2002 | doi: 10.1021/bk-2002-0824.ch015
These items will allow the proper sizing of hardware, and, more importantly, to understand the activity of the data. Once the volumetrics are in place the next component of the architecture are the schémas and interfaces. The schémas will be createdfromthree major components: • • •
The logical view of the data Use of the data De-normalization to adjust performance
De-normalization mapping will outline each of the de-normalization steps taken to improve performance. The developer will construct the physical data model. The physical data model will provide more detail about the actual datafieldsthan the logical data model. The documentation requirement is to have a complete data model designed using a database design tool. The database design tool should allow a person to evaluate the design using a variety of views and report formats.
Detailed System Design Specification Documentation The developer will provide a complete set of product specifications for the system. The specifications will detail all aspects of the project and will be used by the development team to code the system. The specifications should contain at a minimum the following topics: Functional Decomposition The objective of the Functional Decomposition is to decompose the system step by step, beginning with the mainfonctionof the system and continuing with the interim levels down to the level of elementary functions. On each level abstractions are madefromeach corresponding lower level. All the subfunctions together form the completely decomposed function (functional hierarchy).
In Capturing and Reporting Electronic Data; Garner, Willa, et al.; ACS Symposium Series; American Chemical Society: Washington, DC, 2002.
114 Logical Application Design
Definition of modules and functional requirements of each module.
Downloaded by UNIV OF CALIFORNIA SAN DIEGO on December 22, 2015 | http://pubs.acs.org Publication Date: August 1, 2002 | doi: 10.1021/bk-2002-0824.ch015
Program Interface Architecture
Form mock-ups will be designed for each of the entry screens. Each form will be accompanied by user form interaction, business rules, and input tables.
Global Features and Integration
A complete discussion of the global features that will be included in the system. These features include items such as the use of Wizards, Printing, Online Help, etc.
System Security Model
The complete system security model is defined.
Standards, Methods, Tools and Errors
Coding standards will be discussed in detail. The methods of development including version control, change control and defect tracking systems will be identified. Tools including development and reporting tools will be identified. Error checking will serve to check completeness and formatting. Error handling will serve to report internal errors to the user. Error checking will be included in the data entry and datafileselection actions.
System Administration
The administration component of the system will be described including: System Administration, Site Administration and User Administration.
In Capturing and Reporting Electronic Data; Garner, Willa, et al.; ACS Symposium Series; American Chemical Society: Washington, DC, 2002.
115 Calculations, Reports and Graphs The output of the system including the reports, alerts, etc., will be described in detail.
Downloaded by UNIV OF CALIFORNIA SAN DIEGO on December 22, 2015 | http://pubs.acs.org Publication Date: August 1, 2002 | doi: 10.1021/bk-2002-0824.ch015
Project Plan, QA Plan and System Test Plan Documentation Project Plan The project plan is a detailed proposal describing each of the objectives of the project. The project plan includes deliverable requirements and the necessary timeframefor each component of the system. The Project Plan will contain a timeline for each phase of the project that identifies specific milestones including project meetings, status report submissions, and project deliverables.
Quality Assurance Plan The purpose of this Software Quality Assurance Plan (QAP) is to define the techniques, procedures and methodologies that will be used by the developer to assure timely delivery of the software that meets specified requirements within project resources.
System Test Plan The Test Team assigned to the project will be responsible for developing a Test Plan for each phase of the project. The contents of the Test Plan should be based on IEEE Std. 1012-1986, IEEE Std. 829-1983, and IEEE Std. 10081987. The Test Plan identifies the hardware, software, test personnel, location and strategy employed to test the system.
Summary The design of a system to support processes that are governed by the GLPs must be well documented. The documentation of the system design forms the foundation of the development phase of the system. Only a well-designed system will provide the users with a high degree of assurance that the system
In Capturing and Reporting Electronic Data; Garner, Willa, et al.; ACS Symposium Series; American Chemical Society: Washington, DC, 2002.
116
Downloaded by UNIV OF CALIFORNIA SAN DIEGO on December 22, 2015 | http://pubs.acs.org Publication Date: August 1, 2002 | doi: 10.1021/bk-2002-0824.ch015
will consistently function according to the written documentation. Therefore, when purchasing or evaluating a GLP based system, it is important to meet with the developer and understand the steps used in designing the system. The specifications are the primary document that defines the functionality of the system. All validation testing should be designed to insure the system operates as stated in the design documentation.
In Capturing and Reporting Electronic Data; Garner, Willa, et al.; ACS Symposium Series; American Chemical Society: Washington, DC, 2002.
