Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

CATEGORII DOCUMENTE




BulgaraCeha slovacaCroataEnglezaEstonaFinlandezaFranceza
GermanaItalianaLetonaLituanianaMaghiaraOlandezaPoloneza
SarbaSlovenaSpaniolaSuedezaTurcaUcraineana

AdministrationAnimalsArtBiologyBooksBotanicsBusinessCars
ChemistryComputersComunicationsConstructionEcologyEconomyEducationElectronics
EngineeringEntertainmentFinancialFishingGamesGeographyGrammarHealth
HistoryHuman-resourcesLegislationLiteratureManagementsManualsMarketingMathematic
MedicinesMovieMusicNutritionPersonalitiesPhysicPoliticalPsychology
RecipesSociologySoftwareSportsTechnicalTourismVarious

Master Validation Plan - PharmaReady 4.1 Release

managements

+ Font mai mare | - Font mai mic






DOCUMENTE SIMILARE

Trimite pe Messenger
STRATEGIC MANAGEMENT PROCESS
Payment methods
Budget Development and Cost Calculation
ASPECTS OF MARKETING MANAGEMENT
The Statement of Work and the Project Announcement
DISSERTATION - HEDGING OPPORTUNITIES, STRATEGY AND NEED
Human Resource Management - Bristol Compressors case study
Project Closure
International business issues
Perspectives inManagement

Master Validation Plan


PharmaReady 4.1 Release

DMS, TRMS, eCTD, & SPL Modules

1. Introduction

The PharmaReady product suite encompasses four modules; a document management module (DMS), training record management module (TRMS), electronic common technical document submission module (eCTD), and structured product label authoring module (SPL). PharmaReady is targeted for use within business areas regulated by FDA and other federal laws, and is technically compliant with the regulations of 21 CFR Part 11 and the predicate rules which govern the use of computerized systems for managing data related to clinical trials.

This Master Validation Plan outlines the activities and deliverables required to develop, test, and deploy the PharmaReady application.

2. Scope

2.1     Overview

The master validation plan covers all activities for the PharmaReady 4.1 release, which encompasses additional features and maintenance to all modules.

Specifically, the plan is intended to ensure:

·         All requirements found in the PharmaReady 4.1 Business Requirements documents are incorporated into the application.

·         All specifications found in the PharmaReady 4.1 Functional Specifications documents are incorporated into the application.

·         All specifications found in the PharmaReady 4.1 Functional Specifications documents are tested and passed.

·         All 4.1 bugs are fixed and unit tested.

·         All 4.1 bug fixes are tested and passed.

·         During the testing phase, all high-level defects detected are resolved.

·         All defects other than high-level are resolved or deferred to a later release.

Only the PharmaReady Life Sciences teams in the Raleigh, NC and Chennai India facilities fall within the scope of this project:

3. Organizational Structure

This section describes the roles and responsibilities of the project team members.

3.1     Project Manager

Phillip Mosely (US) and Sampathraj Mathurperumal (India):

·         Project planning

·         Control of project activities and resources

·         Monitor progress of teams

·         Ensure issues are correctly addressed and resolved

·         Enforce project objectives

·         Work with Quality Assurance to ensure compliance

3.2     Technical Lead, Sr. Developer, Developer

Ken Stamper, Todd Andrews, Jim Beck (US) and Kamal Menon, Ganesan Durairaj, Jegan Raman, Selvabharathi Raman, Rajnish Kumar, Elangovan Parasuraman, Gyaneshwar Kumar (India):

·         Ensure software is coded according to functional specifications document

·         Create unit test cases

·         Execute unit test cases

·         Create, review and approve validation documents

·         Work with Quality Assurance to ensure compliance

3.3     Quality Assurance

Dawn Staniewicz, Jon Schweitzer (US) and Lakshmi Ramasamy, Sharon Anita, Vamsi Krishna Reddy (India):

·         Write functional and bug test cases

·         Execute all test cases

·         Ensure software is tested according to functional specifications document

·         Ensure all assigned bugs are tested and passed

·         Create, review and approve validation documents

·         Ensure software compliance

3.4     Business Analyst

Jay Johnson (US):

·         Ensure software is current with industry standards and regulations

·         Create Business Requirements, Functional Specifications, and Traceability Matrixes for all modules

·         Assist Quality Assurance in testing

·         Create, review and approve validation documents

·         Ensure software compliance

·         Work with Quality Assurance to ensure compliance

3.5     Technical Writer

Ellen Lofton (US):

·         Create user documentation (user guides, training workbooks)

·         Work with Quality Assurance to ensure compliance

3.6     Implementation and Support

Tricia Miller (US) and Vijay Srinivasin (India):

·         Manage customer implementations

·         Provide customer support

·         Create, review and approve validation documents

·         Work with Quality Assurance to ensure compliance

3.7     Information Technology

Edwin Rodriguez (US):

·         Install software

·         Provide customer support

·         Create, review and approve validation documents

4. Risk Assessment

The PharmaReady 4.1 maintenance release has changes which affect all four modules.  The majority of the functional changes are within the DMS, eCTD, and SPL modules.  The level of testing will include updating applicable developer unit test cases, updating applicable functional test cases with new changes, testing all bugs fixed in the release, updating all Installation Qualification and Operational Qualification documents, and updating regression test cases.  The application will need to be revalidated to qualify the installation and basic operations.

5. Validation Strategy

PharmaReady 4.1 maintenance release has changes which affect the majority of the functionality.

5.1     Lifecycle

The V model will be used for lifecycle.

·         Business Requirements – High-level design - contains business needs of software.

·         Functional Requirements – Detail-level design - contains functional design of application.

·         Development - Coding by the developers as per the functional specification.  Code Review is performed to ensure that code is created as per the coding standards.

·         Unit Testing – Performed in the Development Server by the developer to ensure that program works per the functional requirements. 

·         Application Testing / Integration Testing - This is to ensure that programs work along with other components that might get affected.  The test cases are created separately.  

·         Product Testing / Load Testing - Performed with large datasets to check if the system / product can handle production scenarios in terms of memory and performance.

·         Final Implementation in Production – Create installation disc and assemble validation package for customer installations.

·         Support - Any further defects will be recorded as a bug fix or enhancement and will be carried out as a part of a future release.


5.2     Plan Responsibilities

Overall responsibility of developing and executing the Validation Plan deliverable documents will be that of the following groups.

ROLES / RESPONSIBILITIES

C=Create, A=Approve

PM

Tech L

S.DEV

DEV

QA

BA

TW

SUP

MISC

Master Validation Plan (VP)

C, A

A

PharmaReady Validation Plan (PRVP)

C, A

A

Project Team list

C

A

Business Requirements Document (BRD)

A

C

A

Functional Specifications Document (FSD)

A

C

A

Traceability Matrix

A

C

A



Company Org Chart

A

C

Installation Qualification Protocol (IQ)

C, A

C, A

C, A

A

Operation Qualification Protocol (OQ)

C, A

A

Performance Qualification Protocol (PQ)

A

C

A

A

PQ Execution and Summary

A

C

A

A

Developer Unit Test Cases

C, A

C

C

A

Problem Tracker Summary

C

A

A

Production Release Form

C

A

Release Notes

A

A

C

Test Execution Summary

C,A

Training Manuals

A

A

C

A

Training Session Descriptions

A

A

C

A

System Admin User Guides

A

A

C

A

DMS Doc Management Guide

A

A

C

A

eCTD User Guide

A

A

C

A

SPL User Guide

A

A

C

A

Technical Manuals




C, A

A

A

C, A

PharmaReady Validation Summary Report

C, A

A

List of documents

C, A

Master Validation Summary Report (VSR)

C, A


5.3     Project Timeline

The timeline for the project is:

5.4     Traceability

The Traceability Matrix demonstrates that the system meets the defined Business and Functional Requirements.  All requirements will be traceable to successfully executed test cases.

Manual testing or successful execution of automated test scripts will demonstrate that all requirements have been met.

5.5     Testing Tools

All test cases are written and executed manually.  When all manual test cases pass, if time permits, the test case will be recorded for reuse using Quick Test Pro by the India QA Team.

5.6     Validation Approach

The general approach to validating the system will be to integrate the validation activities with the development and quality activities.

6. Validation Deliverable Documentation

The validation documentation will be created during the development, testing, and deployment phases.  All electronic validation document deliverables will be uploaded into OSPRey, the TAKE Solutions Document Management System.  The OSPRey DMS application has Edit, Review, Approve, Publish and Distribute workflow functions to maintain strict version control of documents and protect against accidental destruction.

Hardcopies of executed validation documents (such as test cases) will be retained in the PharmaReady filing cabinet in the Raleigh, NC office.

6.1     Business Requirements

The business requirements documents (BRD) capture the high-level functions desired by the user community (customer) to be implemented in the system.  The PharmaReady business requirements are created separately for each of the four modules.  Each BRD must be sufficient to establish requirements that are verifiable or testable.

6.2     Hardware, Software and Infrastructure Requirements

The hardware, software, and infrastructure requirement document (HSIR) is produced to specify the required system hardware, software, and infrastructure components necessary to install and run the PharmaReady servers. 

6.3     Functional Specifications

The functional specification documents (FSD) capture the high-level design functions in the system.  The PharmaReady functional specifications are created separately for each of the four modules.  Each FSD must provide a page-by-page representation of the module, detailing the user interface, fields and columns, active elements, access rules, and field validation.  Each FSD item must be verifiable or testable.

6.4     Traceability Matrix

The traceability matrix document demonstrates that the system meets the defined Business and Functional Requirements. All requirements will be traceable to successfully executed test cases.  The PharmaReady traceability matrixes are created separately for each of the four modules.

6.5     Project Team Lists

The project team list is a listing of all members on the PharmaReady development, quality assurance, and support teams in both the United States and Chennai, India offices.


6.6     Installation Qualification Validation Protocols

The IQ validation protocol is used to install the software and all components associated with the PharmaReady application.  The IQ protocol is written by the development and information technology teams.  The IQ New install, Upgrade, and Client Workstation documents must be approved prior to the release of the software as well as prior to execution at a customer’s site.  An acceptance criterion is listed in the IQ document, which must be met to demonstrate the system’s readiness for the next phase of validation.  Approval of the IQ protocols by the Development Manager, Information Technology, and Quality Assurance shall constitute approval for initiation of the Operational Qualification phase.

6.7     Operational Qualification Validation Protocols

The OQ validation protocol is used to demonstrate the effectiveness and reproducibility of the system as a fully integrated system and all major functional areas of the system.

The OQ protocols are written by the quality assurance team. 

New Installation

For new installs, each module has a separate OQ protocol which consists of two documents, an admin and a workflow document. 

Upgrades

For upgrade installs, each module has a separate OQ protocol which consists of two documents, an admin upgrade and a workflow upgrade document. 

Standalone Modules – New Installation

Two modules, eCTD and SPL, are available in a standalone version.  Each new install for the standalone modules has a separate OQ protocol which consists of two documents, an admin and a workflow document. 

Standalone Modules – Upgrade

Each new upgrade install for the standalone modules have a separate OQ protocol which consists of two documents, an admin and a workflow document. Each OQ document must be approved prior to the release of the software as well as prior to execution at a customer’s site.  An acceptance criterion is listed in the OQ document, which must be met to demonstrate the system’s readiness for the next phase of validation.  Approval of the OQ protocols by the Development Manager, Business Analyst, and Quality Assurance shall constitute approval for the Operational Qualification phase.

6.8     Performance Qualification Validation Protocols

The PQ validation protocol is used to demonstrate load on the system for a specified number of concurrent users and total number of documents in the system.  The PQ protocol is written by the development and information technology teams.  The PQ execution will be performed on the final release of the software.  An acceptance criterion is listed in the PQ document, which must be met to demonstrate the systems meet the specified performance benchmarks.  Approval of the PQ protocols by the Development Manager and Quality Assurance Manager shall constitute approval.


6.9     Testing Documents

Testing is the process of checking the system to verify it satisfies all requirements and operates as expected.  Testing documentation includes:

Test Plan – A plan which outlines the testing timeline.

Functional Test Cases – Step-by-step instructions to verify all specifications in the system are included and work properly.

Bug Test Cases – Step-by-step instructions to test a specific defect or issue in the system.

Functional Test Case Execution Summary – Report listing each functional test case, when it was tested, and a result of pass or fail.  If a test case fails, it needs to be re-executed in a subsequent build until it passes.

Bug Test Case Execution Summary – Report listing each bug test case, when it was tested, and a result of pass or fail.  If a test case fails, it needs to be re-executed in a subsequent build until it passes.

6.10                 Release Notes

The Release Notes document includes a description of new functionality included in the new release, each bug that is fixed in the new release, and any known issues.

6.11                 Training Workbooks and User Guides

The Training workbooks and User Guides provide information on how to use the system.  The training workbooks are designed to teach specific objectives within multiple lessons and are tailored on a module basis.  The user guides are designed to give information on a page or functional level on a module basis.

6.12                 Validation Summary Report

At the end of the validation activities, a Validation Summary Report will be written describing the results of the executed testing and any deficiencies that were observed and their appropriate resolution.  The validation report will include the status of all testing activities, any deviations from the planned validation activities, and validation status. The report also includes any outstanding issues, a list of documentation, and the location of all project deliverables.


7. Validation Environment

7.1     Validation Environment

The Validation/Testing Environment describes the environments in which the unit cases, functional test cases, bug test cases, OQ protocols, use cases, and regression test cases were executed.

·         The development code was produced in a development environment.

·         The current development/build version of the PharmaReady application was deployed on one of two QA testing environments (PR41A and PR41B) using the Installation Qualification.

·         Each subsequent QA build was deployed to the other QA server in a rotating fashion.

·         An additional QA environment was added in July for testing the software in an upgraded state.

7.2     Pre-Execution Validation Process

The following steps outline the pre-execution process.

·         The development environment must be in place and available for developing code.

·         Visual Source Safe must be in place for source code control.

·         Testers will print all test case documents.

·         Testers will complete all necessary validation documents in blue or black ink.

7.3     Validation Execution Process

The following steps outline the validation execution phase.

·         Development team must execute all unit and IQ test cases.

·         Quality Assurance team must execute all functional, bug, use case, and OQ test cases.

·         Document observed results on the validation document pages while testing.

·         Indicate the result of the Test Step/case is Pass, Pass with Error, or Fail.

·         A test step will Pass if no defect or software irregularity is encountered.

·         A test step/case will Pass with Errors if only minor, cosmetic defects or software irregularities are encountered.

·         A test case will Fail if major defects or software irregularities are encountered.

·         During the Validation Execution phase, all errors are documented in ProblemTracker.

7.4     Validation Execution Process

During the Validation Execution phase, the error resolution process is:

·         While executing the unit cases, functional test cases, bug test cases, OQ protocols, use cases, and regression test cases, all defects or irregularities will be logged into the ProblemTracker application for tracking and assignment to a subsequent build for deployment.

·         All defects or irregularities will be logged on the respective test case.

·         All issues will be assigned a severity level of High, Medium, or Low.

·         All High-level defects will be corrected. 

·         Medium and Low-level defects can be deferred to a later release.



·         If applicable, the Software Configuration Manager will push a new version of the application to the validation environment

·         Tester will re-execute failed documents.

·         The Error Resolution cycle will continue until all test cases pass.

7.5     Post-Execution Validation Process

The following steps outline the process after the validation documents are executed.

·         All electronic versions of validation documents are retained in TAKE Solutions internal PharmaReady application, OSPRey.

·         All hardcopies of executed validation documents will be retained in the PharmaReady filing cabinet.

·         Unit test case

·         Functional test cases

·         Bug test cases

·         For customer implementation, customer retains original documents while TAKE Solutions retains copies of the documents.

·         Prepare a Validation Summary Report summarizing the results. 

7.6     Acceptance Criteria of Validation

The Validation will be deemed complete when all of the following are satisfied:

·         All coding is completed.

·         All unit test cases are created, executed, and passed.

·         All QA functional and bug test cases are created, executed, and passed.

·         All IQ and OQ documents are created, executed, and passed.

·         All issues determined to be High Level are corrected.

·         All issues determined to be Medium or Low Level are either resolved or deferred for future releases.

·         Validation Summary Report is completed.

8. Training

The PharmaReady Training Records Management module is used to facilitate employee training records tracking.  All Standard Operating Procedures (SOPs) and Work Instructions (WIs) are distributed to Life Science employees and read via PharmaReady. Each employee is responsible for reading SOPs and WIs based on their job title. A Training Matrix is maintained listing all required training by job title.


9. Glossary

The following abbreviations or terns were used throughout this document.

Term or Abbreviation

Description

DMS

Document Management System

TRMS

Training Records Management System

eCTD

Electronic Common Technical Document

SPL

Structured Product Labeling

FDA

Food and Drug Administration

IQ

Installation Qualification

OQ

Operational Qualification

PQ

Performance Qualification

Validation

Establishing documented evidence, which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specification

SOP

Standard Operating Procedure

WI

Work Instructions

Training Matrix

Excel grid which shows employee job titles and the corresponding SOPs and WIs each job title is required to read


10. Document Control

10.1                 Approval

Filename: 4.1 Release Master Validation Plan

Date: 28 May 2008

Authored by:

Reviewed by:

Approved by:

Jon Schweitzer,
Quality Analyst Lead

Date

28/May/08

Jay Johnson,
Business Analyst

Date

28/May/08

Dawn Staniewicz,
Quality Assurance Manager

Date

28/May/08

10.2          Change History

The following table describes significant content changes made to Master Validation Plan 4.1 Release document.  The version number denotes where changes were introduced.

Version

Effective Date

Description of Change

By

V1.0

28 May 2008

Initial creation of document

J. Schweitzer

10.3          Related Documents

The following documents are related to this Master Validation Plan 4.1 Release document:

·         Installation Qualification

·         Operational Qualification Admin (for each installed module)

·         Operational Qualification Workflow (for each installed module)

·         Validation Summary Report









Politica de confidentialitate

DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 1023
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2019 . All rights reserved

Distribuie URL

Adauga cod HTML in site