Debra Weber Master Plan

VALIDATION MASTER PLAN (VMP)
FOR <COMPANY>
<DATE>
Author(s)
The signature by the individual(s) below indicates that he/she (they) has(ve) authored this document
and agree to its correctness and accuracy.
Printed Name Printed Title Signature Date
Reviewer(s)
The signature by the primary <company> representative(s) below indicates that the individual(s) have
reviewed the scope of the effort as described in this document and agree to its correctness and
accuracy as being representative of the <company>.
Printed Name Printed Title Signature Date
Doc Type Document Number Status Last Modified Page
VMP <company document ID> DRAFT April 25, 2013 1 of 16

This document is the property of <company> All rights reserved
Table of Contents
1. Purpose .............................................................................................................................................. 3
2. Scope .................................................................................................................................................. 3
3. Definitions .......................................................................................................................................... 3
4. Roles and Responsibilities ............................................................................................................... 3
5. Background ....................................................................................................................................... 5
5.1 Computerized System ..................................................................................................................... 5
5.2 Software Categories ....................................................................................................................... 5
6. Procedure ........................................................................................................................................... 6
6.1 The Validation Master Plan ............................................................................................................. 6
6.2 Initiation Phase ............................................................................................................................... 6
6.3 Requirements Phase ...................................................................................................................... 7
6.4 Design Phase .................................................................................................................................. 7
6.5 Development Phase ........................................................................................................................ 7
6.6 Test Phase ...................................................................................................................................... 8
6.7 Production Phase ............................................................................................................................ 9
6.8 Retirement Phase ........................................................................................................................... 9
6.9 Requirements Traceability through Testing .................................................................................... 9
6.10 Periodic Review of Validated Computer Systems ...................................................................... 9
6.11 Retrospective Evaluation for Existing Computer Systems.......................................................... 9
7. Terms, Acronyms and Definitions ................................................................................................. 10
8. Validation Requirements for Deliverables .................................................................................... 13
9. Revision History Summary ............................................................................................................. 16
Table of Figures
Figure 5-1 Components of a Computerized System ................................................................................. 5
Table of Tables
Table 4-1 Roles and Responsibilities ........................................................................................................ 4
Table 9-1 Validation Deliverables ........................................................................................................... 13

1. Purpose
This document describes the Validation Master Plan employed at <company>, including the mechanism
used to manage validation activities and the documentation prepared to support the validation effort.
This SOP defines the System Development Life Cycle (SDLC) methodology to be utilized during the
validation of a computer system, including the development, use, maintenance, and retirement of the
system for Food and Drug Administration (FDA) regulated business activities at <company>. The SDLC
adopted at <company> will be referred to in this document as the methodology used for the Validation
Master Plan.
2. Scope
This corporate Standard Operating Procedure (SOP) applies to <company>. This SOP does not
supersede any procedures supporting similar computer validation initiatives at the site or local level.
This SOP applies to all vendor-purchased, in-house developed, local, and enterprise computer systems
applicable under FDA regulations, that are used to create, modify, maintain, archive, retrieve, or transmit
electronic records governed by the requirements set forth by the FDA. Such computer systems are
required to be validated to ensure accuracy, reliability, consistent intended performance, and the ability to
discern invalid or altered records.
Validation documentation produced from the SDLC is required to be part of FDA regulated, IS projects.
However, the details associated with each deliverable will be dependent upon individual department or
site SOPs and the complexity of the computer system being evaluated. This SOP identifies the minimum
requirements for each validation deliverable described for validated systems. Refer to Section 8 for the
typical deliverables in each phase of the SDLC.
3. Definitions
Refer to Section 7 for the terms, acronyms, and definitions referred to under the Validation Master Plan.
4. Roles and Responsibilities

The project team for a computer validation effort consists of personnel from different functions and/or
technical resources. Members of the project team may be drawn from functional, technical, infrastructure,
or user (for the related business functions) departments. The project team may include external
resources, such as suppliers or consultants. When external providers are utilized for services required of
the project team, a formal agreement will be established describing their competencies, roles and
responsibilities.
The representation for a project team should include, at a minimum, the following functional roles:
Information Services (IS) Owner
System Owner (SO)
IS Quality Representative
Quality Assurance (QA) Representative
Additional roles, such as developers, testers, or system engineers may be enlisted for support on a
project based on need. Multi-site projects (for centralized or duplicated systems) may be managed as one
central project, and the necessary resources are determined by the IS Owner and/or Project Manager.
However, a site QA Representative will be designated to represent site quality function for the project
activities at the site. The responsibilities listed below are not necessarily all-inclusive.

Table 4-1 Roles and Responsibilities
Functional Role Responsibilities

Responsible for technical and functional support to the user, by participating in
the implementation and validation of the system and providing ongoing
support to the user department.
Responsible for the technical quality of the solution.
Information Services (IS) Owner Assure that, during system development, operation, support and maintenance,
and/or Project Manager (PM) all steps of the methodology are followed and that requirements, testing, and
other required documentation or deliverables are available in accordance with
the methodology.
Responsible for the overall project team budget and administration.
Responsible for releasing the validated system to the user community.
Responsible for ensuring that appropriate computer system compliance
activities are performed and to assure proper communication to the user
community.
Responsible for identifying the predicate rules in the User Requirements
Specification.
System Owner (SO) Controls the business aspects of the project and is responsible for
representing the user community.
Responsible for authorizing the initiation of a computer system to support that
departments business responsibilities.
Responsible for the functional quality of the solution.
Responsible for releasing the validated system for production use.
Responsible for determining the scope of validation and/or qualification
activities for new system implementation and/or system changes to existing
systems.
Responsible for the quality of the solution from a regulatory perspective.
Ensure the validation projects adherence to US Quality & Compliance
processes by monitoring compliance with established Quality & Compliance
procedures, standards, and/or requirements.
Quality Assurance (QA)
Representative Assure that system(s) are independently reviewed and/or approved for use in
production and that qualification/validation evidence is managed and
controlled.
Represent the site quality function for the activities that are common for the
participating site in a multi-site validation effort.
Provide general support during the validation process to ensure that FDA
regulations and guidelines are met, and that US Quality & Compliance
standards are followed.
Responsible for the technical quality of the solution from a system functionality
perspective.
Ensure the validation projects adherence to IS processes by monitoring
compliance with established IS procedures, standards and/or technology
requirements.
IS Quality Representative Assure that system(s) are reviewed and/or approved for use in production and
that qualification/validation evidence is managed and controlled.
Represent the site IS quality function for the activities that are common for the
participating site in a multi-site validation effort.
Provide general support during the validation process to ensure that IS
standards and practices are followed.

5. Background
<company> uses computer systems to support activities and documentation required by FDA regulations,
and recognizes the importance of ensuring that automated systems maintaining records are validated.
5.1 Computerized System
Computer System Validation involves the control of a computer system in its operating environment. The
term computerized system is used to define the computer system in the user setting. It consists of the
controlling system and the controlled process. The controlling system is composed of the computer
hardware and software. The operating environment, where the controlling system resides, includes
equipment, users, procedures, documentation, the physical environment, as well as infrastructure. Both
the controlling system and its operating environment will need to be considered when validating a
computer system for use.
The following figure shows the components of a computerized system that will be considered when
validating a computer system for use.
Figure 5-1 Components of a Computerized System
The infrastructure components (servers and databases) supporting FDA regulated computerized systems
must be appropriately qualified in compliance with applicable regulatory requirements.
5.2 Software Categories
Complex systems may incorporate multiple layers of different types of software. These types of software
may be categorized into the following:
Established, commercially available operating systems and databases.
Firmware or standard instruments that are non-user programmable.
Standard software packages that are Commercial-off-the-Shelf (COTS).
Configurable software packages where the typical feature allows the user to configure and/or
amend predefined software modules, as well as developing new application software modules.
Custom built software that is exclusively built and tailored to the user.
A computer system could exhibit one, several, or all software categories. Appropriate qualifications and
controls for each software component or layer, commensurate with the compliance risks and the
complexity of the system, will define the basis for determining the scope and extent of validation or
qualification activities.

In the context of this document, a distinction is made between the commonly interchangeable terms,
qualification and validation. Qualification demonstrates that a component or equipment works, or that
an application functions as it was designed. Qualification is the result of direct measurements and
observations that prove a computer system was installed correctly in compliance with the requirements of
the manufacturer, or that it functions in conformance to design parameters. Qualification supports
validation through the presentation of direct measurements or evidence.
Validation focuses on the requirements of the users. Validation is a System Development Life Cycle
(SDLC) exercise that is used to show a process that is consistently applied and under control, will reliably
produce a consistent and predicable output. Validation ensures that quality is built into a computer system
via verification activities throughout the SDLC. Validation shows that a system functions according to its
intended use and that the system meets the requirements of the users and their business processes.
For new system implementation and/or changes to existing systems, the scope of validation and/or
qualification activities will be determined by the Quality Assurance Representative.
6. Procedure
6.1 The Validation Master Plan
The Validation Master Plan at <company> typically follows the SDLC to demonstrate that the computer
system has been built using a quality process.
Formal documentation generated from the SDLC methodology leads to improved and confirmed
compliance to the Validation Master Plan. Systems that are well defined are easier to support and
maintain, resulting in less operational downtime.
An approved inventory of all computerized systems must be maintained for system identification.
All new, FDA regulated systems should be prospectively validated utilizing the SDLC methodology. Below
are typical phases of the standard SDLC methodology:
Initiation Phase
Requirements Phase
Design Phase
Development Phase
Test Phase
Production Phase
Retirement Phase
The phases are described in the following:
6.2 Initiation Phase
The Initiation Phase is the phase during which drivers for a new computer system are identified. The need
to purchase or develop a new computer system, or upgrade an existing system, is identified. If the
proposed system requires validation, then a multi-disciplinary project team is established.
A Validation Plan (VP) for the project is typically prepared and approved to provide overall strategy on
how the system will be validated. The VP defines the overall validation strategy, procedures and
approaches that apply to the project.
The following items must be included in the VP:
Validation strategy and activities expected as part of the project.
Roles and responsibilities of organizations and personnel involved in the project.
Deliverables to ensure that the system will be built, verified, and tested according to the
requirements.
Validation documentation to be securely stored and readily available for review and inspection.
The VP may be prepared in conjunction with the User Requirements Specification (URS) or the User and
Functional Requirements Specification (UFRS), as described in the next phase.

During this phase, a compliance risk assessment is performed to identify, assess, and mitigate the level
of compliance risks associated with the computerized system and to determine the scope of the validation
effort. Based on this assessment, the level of verification and testing that is commensurate with the risks
to the system will be determined.
6.3 Requirements Phase
In the Requirements Phase, the features of what the users or the business community expects from the
proposed system are determined. These business features and functions are identified in the User
Requirements Specification (URS) and Functional Requirements Specification (FRS). The requirements
of the URS and the FRS may be combined into a single User and Functional Requirements Specification
(UFRS).
The URS or UFRS may be sent to the computer product suppliers as part of a vendor selection process.
Requirements for the URS or UFRS should be uniquely identified, described from an end-user
perspective. The URS or UFRS will take in consideration electronic records and electronic signature
requirements for the system, as appropriate.
All requirements should be verifiable, testable, and consistent so that a Requirements Traceability Matrix
(RTM) may be developed to trace the requirements through to testing.
For a purchased system, a vendor audit is generally performed to assess the vendors ability to provide
products and services that meet business needs and satisfy applicable regulatory requirements.
6.4 Design Phase
The Design Phase defines how the user and functional requirements will be developed into the blueprint
for a system. The requirements found in the Requirements Phase are transformed into a detailed design
for each component of the system. The System Design Specification (SDS) should be created to define
how the system would meet the requirements found in the Requirements Phase.
The SDS should cover the following specifications (list is not exhaustive):
Hardware/equipment
Infrastructure or architecture
Software or application
Software module/ unit
Ancillary equipment or embedded systems
Network
Interface
Design (for equipment Mechanical drawings, electrical drawings, process & instrumentation
drawings, etc.)
Data flow of the system
The SDS may be broken down into multiple design documents, where the number and hierarchy of
design documents will depend on the size and complexity of the system.
For vendor-purchased systems, vendor design specifications may be a proprietary intellectual asset that
cannot be attained. In such cases, elements of the design specifications may be verified through testing,
if applicable.
6.5 Development Phase
The Development Phase begins by building the system in accordance with IS standard practices. The
system is developed and integrated so that the built product is traceable to the design specifications
found in the previous phase.
Iterative build cycles may be used, such as prototyping where an early approximation of a final system is
built, tested, and then reworked as necessary until an acceptable build is finally achieved from which the
complete system can be developed. This agile model works best in scenarios where not all of the user
and functional requirements are known in detail ahead of time. It is an iterative, trial-and-error process
that takes place between developers and the users.

For systems that are configured or customized by the supplier, a Certificate of Quality for acceptance at
the supplier site is generally required and should be available at the time the system is delivered to the
user. Other certifications, such as a passing Factory Acceptance Test (FAT), a test summary report, or a
quality statement from the supplier, are suitable representation of a Certificate of Quality.
6.6 Test Phase
Once a successful build is completed and a documentation baseline is established from previous phases,
qualification testing occurs in the validation test environment. The validation test environment is staged to
be similar or equivalent to the production environment. The systems installation is qualified through an
Installation Qualification (IQ) to assure that the hardware and software components of the system are
installed according to specifications.
Normal, expected functional testing, including stress conditions, is performed during an Operational
Qualification (OQ). The user community usually participates in the OQ testing effort. The user
community also performs a Process Qualification (PQ) on the system to ensure that the supported
process is verified under production or simulated production conditions. As part of the PQ, the existing,
manual, business process should be run in parallel with the automated system, if appropriate.
All qualifications must focus on the FDA regulated functions/components of the system. Successful
qualification allows for system use in the production environment.
Formal testing during qualification requires well-defined, pre-approved test cases and the creation of
individual test records, including the appropriate evidence to prove successful test runs. Change control
and anomaly handling should be managed during formal testing. A qualification report will be created at
the conclusion of testing to summarize the test results.
Appropriate procedures should be in place for the users to operate and maintain the system in the
production environment. Functional and/or system-specific procedures should be identified in the
following areas:
System documentation management
System back-up and restore
Archival and retrieval, as appropriate
Problem management
Physical and logical security access and controls
System operation and maintenance
User training
Change control
Incident management
Other procedures determined as necessary
For certain vendor-developed systems, it is possible to use the qualification documentation supplied by
the vendor. However, a justification must be captured. It is also mandatory to formally check the test
scope against the approved URS or UFRS.
At the conclusion of the project, a Validation Summary Report (VSR) is written to summarize the project
and explain any discrepancies, if any, to the VP.
The VSR should indicate the following:
The state and summary of validation activities and results
The procedures that will be followed to maintain the system in a validated state
How the related documentation will be securely stored and readily available for review, audit or
inspection
Any outstanding deviations from the Validation Plan or anomalies from qualification testing, with the
appropriate justification and remediation.

6.7 Production Phase
Once a system has been validated, it is essential to ensure that the validated status is maintained during
its use in the production environment. System operation and maintenance must be performed according
to approved procedures to ensure the validated state of the computerized system is maintained.
Modifications to the validated system must be made according to Change Control procedures.
6.8 Retirement Phase
When a computerized system is retired or decommissioned, the computer system will no longer be in
production use. A business decision will be made to either archive the data currently residing on the
system, or to migrate the data to a new system.
Steps shall be documented to decommission the system and archive the data and associated
documentation. If the data is to be migrated to a new system, the validation activities related to the
migration shall be documented.
6.9 Requirements Traceability through Testing
User requirements may be built into the computer system or leveraged through procedural controls. Test
cases or scripts should be traceable to requirements in order to facilitate testing. This is achieved by
creating a Requirements Traceability Matrix (RTM) that links the requirements to the test items and/or to
procedural controls.
Figure 2 maps the relationship between key requirements and qualification elements as the system is
specified, designed, built, and tested:
Figure 2: Basic Framework for Traceability of Requirements and Qualification
User Requirements Specification Process Qualification

Verifies
(URS) (PQ)
Functional Requirements
Verifies Operational Qualification
Specification
(OQ)
(FRS)
ifies
Ve r
Baseline of System Design
Installation Qualification
Specification
Verifies (IQ)
(SDS)
SYSTEM BUILD
6.10 Periodic Review of Validated Computer Systems

Periodic review of the computerized system should be performed after the initial validation completion
date. Periodic Review should focus on system reliability, repeatability, performance data, and the
accuracy and use of current procedures. This review is to determine if there is a need for action (such as
an update to a procedure) and/or re-validation of the system.
6.11 Retrospective Evaluation for Existing Computer Systems
Existing FDA regulated computer systems, which are currently used in the production environment but
have not previously been qualified or validated, should be retrospectively evaluated.
The following items should be taken into account during an evaluation of an existing system; the findings
and conclusions must be formally documented.
Change history
Currently available documents supporting the system. For example: requirements, hardware or
software manuals, documented installation or commissioning tests, other formal testing
protocols

Available procedures
Historical data (used as evidence to support the performance of the system)
Problem and maintenance logs
Documentation may need to be updated or generated to reflect the computer system that is currently in
production. As a result of a retrospective evaluation of computer systems, a qualification/validation effort
may be necessary. The retrospective evaluation will determine the actions required to achieve a validated
system.
7. Terms, Acronyms and Definitions

The following table is a list of terms, acronyms, and definitions that are utilized in conjunction with the
<company> Validation Master Plan.
Term/Acronym Definition
The criteria that a product must meet successfully during a testing phase of the
Acceptance Criteria
System Development Life Cycle to achieve the requirements.
Anything observed in the documentation or operation of software that deviates
Anomaly
from expectations.
An independent examination of a work product or services to assess compliance
Audit
with specifications, standards, contractual agreements, or other criteria.
A specification or product that has been formally reviewed and agreed upon, that
Baseline serves as the basis for further development, and that can be changed through
formal means.
For systems that are developed by a supplier, a Certificate of Quality representing
an acceptance at the supplier site is typically required. Other certifications, such
Certificate of Quality
as a passing Factory Acceptance Test (FAT), a test summary report, or a quality
statement from the supplier, are suitable representation of a Certificate of Quality.
An established quality process used for all changes that are made to the
Change Control
computer system and/or to the systems data.
Commercial-off-the-Shelf
Standard, non-customized software that is sold for general usage.
(COTS)
A functional unit, consisting of one or more computers and associated peripheral
input and output devices, and associated software, that uses common storage for
Computer System all or part of a program and also for all or part of the data necessary for the
execution of the program. A computer system may be a stand-alone unit or may
consist of several interconnected units.
The computer system and any subsystems it controls. The system includes
Computerized System hardware, software, peripheral devices, personnel, and documentation; e.g.
manuals and procedures.
Establishing documented evidence that provides a high degree of assurance that
Computer System Validation
a specific computer system attains its predetermined specifications and quality
(CSV)
attributes.
Current Good Manufacturing,
Current FDA regulations and guidance governing Good Manufacturing, Clinical
Clinical, Laboratory Practices
and Laboratory Practices.
(cGxP)
The individual(s) who is technically responsible for the implementation of the
Developer
design for the computer system.
Specifications (i.e. User Requirement Specification, Functional Requirement
Documentation Baseline Specification, and System Design Specification) that have been formally reviewed
and agreed upon, that serves as the basis for further development, and that can

be changed through formal means.
A system that is developed centrally and implemented locally at each participating
Duplicated System
site.
Any combination of text, graphics, data, audio, pictorial, or any other information
Electronic Record (ER) representing in digital form that is created, maintained, modified, archived,
retrieved, or distributed by a computer system.
A computer data compilation of any symbol or series of symbols that is executed,
Electronic Signature (ES) adopted, or authorized by an individual to be a legally binding equivalent of the
individuals handwritten signature.
Regulations that consider electronic records, electronic signatures, and
Electronic Records and handwritten signatures executed to electronic records to be trustworthy, reliable,
Electronic Signatures and generally equivalent to paper records and handwritten signatures executed
Compliance on paper. The FDA regulation is Chapter 21 of the United States Code of Federal
Regulations, Section 11.
Everything that supports the system or the performance of a function. The
Environment
conditions that affect the performance of a system or function.
For systems that are developed by a supplier, a Factory Acceptance Test (FAT)
for acceptance at the supplier site is generally required. The FAT should be
Factory Acceptance Test
available at the time the system is delivered to the user. For COTS, the FAT
(FAT)
should be available upon request during the vendor assessment. Also see
Certificate of Quality.
Food and Drug An administration of the United States government that regulates all food, drugs,
Administration (FDA) and medical devices.
Physical equipment, as opposed to programs, procedures, rules, and associated
Hardware documentation. The examples include personal computers, servers, external
equipment.
Incident A service disruption that can be restored within Service Level Agreement limits.
Equipment, processes, and support required to implement, maintain, and use
computer systems and their communications. It includes, but not limited to,
Infrastructure server, desktop, peripheral hardware, database engines, performance monitoring
tools, utilities, and the communication and data storage required to support cGxP
computer systems.
Documented verification that all key aspects of software and hardware installation
Installation Qualification (IQ) adhere to appropriate codes and approved design intentions and that the
recommendations of the manufacturer have been suitably considered.
The individual who manages the day-to-day aspects of a project from conception
IS Owner and/or Project to completion. A representative from the Information Systems group or the
Manager (PM) operational area of <company> may fulfill this position. The role and
responsibilities of the IS Owner/PM are discussed in the projects Validation Plan.
Operational Qualification Documented verification that the system or subsystem performs as intended
(OQ) throughout representative or anticipated operating ranges.
Documented verification that the process and/or the total process-related system
Process Qualification (PQ) perform as intended throughout all anticipated operating ranges in the actual
production environment or simulated production environment.
For all validated systems, a documented, periodic assessment is conducted. This
Periodic Review includes a review of all changes that were implemented since the last review or
since the last validation effort.
The underlining requirements set forth in the Federal Food, Drug, and Cosmetic
Act (the Act), the Public Health Service Act (PHS Act), current Good
Predicate Rules
Manufacturing, Clinical, and Laboratory Practices, and the Prescription Drug
Marketing Act.

Problem The root cause of one or more incidents.
A multi-disciplinary group of individuals that holds the responsibility to carry out
Project Team the tasks associated with a project per the direction of the Project Manager and/or
IS Owner.
Establishing confidence that process equipment and ancillary systems are
compliant with appropriate codes and approved design intentions, that the system
Qualification
consistently operates within established limits and tolerances, or that the finished
product produce a specific process that meets all requirements.
The planned systematic activities necessary to ensure that a component, module,
Quality Assurance (QA)
or system conforms to established technical requirements.
Requirement Any need or expectation for a system or for its software.
An organized method of keeping track of the relationships between the
Requirements Traceability
requirements and the design features of the computer system to testing
Matrix (RTM)
procedures or scenarios.
Existing computer systems, which are installed and in production environment use
and have not previously been qualified/validated, are retrospectively evaluated.
Retrospective Evaluation
The retrospective evaluation will determine the actions required to achieve a
validated system.
Determination of the uncertainty of events or conditions the risk causes and the
Risk Assessment definition of the mitigation actions to reduce the risk and the vulnerability of the
system. Risk assessment is a component of a Risk Management initiative.
A document that states the requirements and it indicates the criteria whereby the
Specification conformity of the requirement can be checked. It may refer to or include drawings,
patterns, or other relevant documents.
Standard Operating A procedure specifying how certain activities of the business process is to be
Procedure (SOP) followed or accomplished.
An approach to computer system development that begins with identification of
System Development Life the users requirements, continues through design, integration, qualification, user
Cycle (SDLC) validation, control and maintenance, and ends when commercial use of the
system is discontinued.
A technical document that defines how the system would meet the
requirements. The SDS includes the architecture of the software, hardware, and
System Design Specification
the data flow of the system. The SDS may be broken down into multiple design
(SDS)
documents, where the number and hierarchy of design documents will depend on
the size and complexity of the system.
The owner of the system where its business operations resides. The individual is
System Owner (SO) responsible for the overall validation of the system and maintaining the system in
a validated state until the service retirement of the system.
Functional testing usually conducted at the user site to evaluate the compliance of
User Acceptance Testing
a system with specified performance requirements. User Acceptance testing is
(UAT)
typically a component of Operational and Process Qualification.
User The individual(s) who interacts with the computer system.
Establishing documented evidence, which provides a high degree of assurance
Validation that a specific process will consistently produce a product meeting its pre-
determined specifications and quality attributes.
Evidence compiled during the validation effort completed for an application that is
Validation Documentation assembled at the conclusion of a systems validation effort. This documentation
is stored in a secured location.
A preliminary review of potential vendors for the determination of the vendors
Vendor Assessment
capability for meeting the user requirements associated for a given project.

An independent examination of the vendor to conduct a review of system records
Vendor Audit and activities in order to verify the adequacy and effectiveness of procedures, to
ensure compliance with established policies and operational procedures.
The demonstration of consistency, completeness, and correctness of the software
Verification
at each stage and between each stage of the system life cycle.
8. Validation Requirements for Deliverables

The following matrix lists the typical deliverables for a prospective computer validation using the SDLC
methodology. An assessment of the applicable deliverables for a particular computer validation effort is
determined at the commencement of the project. The size and complexity of a system should be taken
into account. Fewer or combined deliverables may be considered for smaller, less complex systems.
Systems that are COTS or stand-alones require a lesser validation effort, and therefore, fewer documents
need to be prepared. As an example, a combined IQ/OQ Plan and a combined IQ/OQ Report may be
written to detail the IQ and OQ effort.
A specific list of validation deliverables, including the identification of the responsible individuals for the
development, review, and approval of the deliverables, should be made available for a project effort.
Table 8-1 Validation Deliverables
Validation
Responsible Minimum
SDLC Phase Deliverable Description of Deliverable
Party* Approval By**
Name
The document addresses the project
scope, the roles and responsibilities of all IS Owner and/or
team members, the deliverables required PM
for validation, among others. It contains System Owner
Validation the scope and approach of the validation IS Owner
Plan (VP) effort, details the activities to be and/or PM IS Quality
completed by each group participating in Representative
the validation, and includes the QA
Initiation acceptance criteria defined for the Representative
Phase project.
The form used to assess cGxP
cGxP compliance risks associated with the System Owner
Compliance operation of a computerized system in IS Owner and/or
System
Risk order to minimize their impact on PM
Owner
Management compliance, while providing the QA
Matrix necessary justification for the system Representative
validation scope.
The URS describes requirements solely
IS Owner and/or
in business or user language and only
PM
addresses what the system must
User System Owner
perform such as user roles and tasks,
Requirements Requirements System
user interface requirements, security, IS Quality
Phase Specification Owner
specific regulatory compliance, and 21 Representative
(URS)
CFR Part 11 requirements. The URS
QA
may be combined with the FRS into a Representative
UFRS.

Validation
Responsible Minimum
Name
The FRS is a technically detailed
document defining the functional and IS Owner and/or
structural requirements of the system. PM
Functional For larger systems, the Functional System Owner
Requirements Requirements Specification may be IS Owner
Specification broken into several separate documents. and/or PM IS Quality
(FRS) In addition, suitable supplier Representative
documentation may be referenced where QA
possible. The FRS may be combined Representative
with the URS into a UFRS.
Test cases or scripts in the Testing
IS Owner and/or
Phase must be traceable to the
PM
requirements. Traceability can be
Requirements achieved by creating tables that link the System Owner
IS Owner
Traceability requirements, specifications and the test IS Quality
and/or PM
Matrix (RTM) items. This deliverable will be drafted in Representative
this phase, populated during the course QA
of the project, and finalized when the Representative
testing is complete.
Document describing the details of how
the goals and requirements specified in
the User and Functional Requirements
Specification will be met. The document
details the hardware specifications,
software requirements, system
System operation, data definitions, and system IS Owner and/or
Design limitations and expandability. IS Owner PM
Design Phase and/or PM
Specification The SDS may be broken into several IS Quality
(SDS) separate documents or sub-documents Representative
for larger, complex systems.
For COTS, a SDS may not be available.
However, COTS systems that are further
configured or customized require a
specification detailing the additional
configuration or customization.
Development As defined by
Development Development Phase deliverables are IS Owner
Phase Information
Phase defined by Information Services. and/or PM
Deliverables Services.
Installation IS Owner and/or
Qualification Plan describing how the system will be PM
IS Owner
Plan (IQP), installed and/or verification of the
and/or PM IS Quality
including test installed configuration items.
cases Representative
The IQ execution/results refer to the

Installation
actual recorded results and all output as
Test Phase Qualification IS Owner As defined in the
well as all incident/deviation report forms,
Execution and/or PM IQ Plan
resolution documentation, and retest
and Results
documentation.
IS Owner and/or
Installation PM
The report summarizes the Installation IS Owner
Qualification
Qualification effort. and/or PM IS Quality
Report (IQR)
Representative

Validation
Responsible Minimum
Name
IS Owner and/or
PM
Operational
Qualification System Owner
Plan describing the OQ testing strategy IS Owner
Plan (OQP), IS Quality
inclusive of how the system will operate. and/or PM
including test Representative
cases
QA
Representative
The OQ execution/results refer to the
Operational
actual recorded results and all output as
Qualification IS Owner As defined in the
well as all anomaly report forms,
Execution and/or PM OQ Plan
resolution documentation, and retest
and Results
documentation.
IS Owner and/or
PM
Operational System Owner
The report summarizes the results of the IS Owner
Qualification IS Quality
Operational Qualification effort. and/or PM
Report (OQR) Representative
QA
Representative
This plan outlines the PQ testing strategy
IS Owner and/or
and demonstrates how the computer
PM
Process system will produce acceptable output in IS Owner
Qualification the user environment through the use of System Owner
and/or PM
Plan (PQP), actual computer parameters and IS Quality
including test procedures. This may include the System
Representative
cases simulation of conditions that are Owner
QA
encountered in actual production use of Representative
the system.
The execution/results refers to the actual IS Owner
Process
recorded results and all output as well as and/or PM
Qualification As defined in the
all anomaly report forms, resolution
Execution System PQ Plan
documentation, and retest
and Results Owner
documentation.
IS Owner and/or
PM
The report summarizes the Process IS Owner
Process System Owner
Qualification effort. This document also and/or PM
Qualification IS Quality
authorizes the release and finalization of System
Report (PQR) Representative
qualification testing. Owner
QA
Representative
This document summarizes the IS Owner and/or
validation effort as compared to the PM
approach described in the Validation System Owner
Validation
Plan. It includes the results, conclusions, IS Owner
Summary IS Quality
and recommendations regarding use of and/or PM
Report (VSR) Representative
the system in production, and the
documentation supporting the validation QA
effort. Representative
Production Refer to <company> functional and
Production Not
Phase system-specific procedures for more Not Applicable
Phase Applicable
Procedures information.

Validation
Responsible Minimum
Name
Retirement
Retirement Refer to <company> retirement Not
Phase Not Applicable
Phase procedure for more information. Applicable
Deliverables
* This is the group that is responsible for the deliverable indicated regardless of whether the Responsible
Party creates the deliverable or obtains alternate resources to perform the task.
** The approvers for a deliverable represent the minimum required signatures. Additional signatories may
be added per agreement of the Project Team. However, no signatories may be removed from the table.
9. Revision History Summary

Version # Date Section # Description of the Change Author(s)
Entire
1 11-NOV-10 New document. Deb Weber
Document


Debra Weber Master Plan

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Debra Weber Master Plan

Hochgeladen von

Copyright:

Verfügbare Formate

VALIDATION MASTER PLAN (VMP)

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 1 of 16

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 2 of 16

4. Roles and Responsibilities

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 3 of 16

Functional Role Responsibilities

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 4 of 16

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 5 of 16

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 6 of 16

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 7 of 16

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 8 of 16

User Requirements Specification Process Qualification

6.10 Periodic Review of Validated Computer Systems

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 9 of 16

7. Terms, Acronyms and Definitions

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 10 of 16

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 11 of 16

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 12 of 16

8. Validation Requirements for Deliverables

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 13 of 16

The IQ execution/results refer to the

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 14 of 16

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 15 of 16

9. Revision History Summary

Doc Type Document Number Status Last Modified Page

VMP <company document ID> DRAFT April 25, 2013 16 of 16

Das könnte Ihnen auch gefallen