Validación de Sistemas
Computadorizado y Análisis De
Riesgo
POR NELSON ESTEVES
ECS - Esteves Consulting Services,
Inc.
I. PLANEACIÓN ESTRATEGICA EN VALIDACIÓN DE SISTEMAS COMPUTARIZADOS.
• CSV definición y ventajas - Se definira el concepto de "Computer System
Validaction" y porque su importancia y en que nos ayuda.
• SDLC definición y clasificación de sistemas- Se definira el ciclo de vida de un
sistema computadorizado, sus partes y la clasificación de sistema y cada
requisitos necesario de acuerdo a la clasificación del sistema por cada etapa del ciclo de vida.
• Preparación efectiva de Requerimientos y Diseño - Definir requisitos de
sistemas es ecencial el el desarrollo de un sistema computadorizado, quienes, que y como definir los requerimientos para crear un diseño adecuado que ayuda a la planiación de la validación.
• Plan de Validación de Sistemas Computadorizados - Definir los componenetes
de un plan, definir responsabilidades por area, y como ejecutarla durante todo el ciclo de vida del sistema.
• Analisis de Riesgo como instrumentos a definir la estrategia de
validaciones-Introducción a cuales aspectos consideramos para definir un analisis de riesgo, como generar un analisis efectivo que mitigue el riesgo y nos ayude a reducir las pruebas en la validación.
• Planeación de la estrategia durante el SDLC- Que se va a validar, como y como
subdividir el sistema de acuerdo a su clasificacion. Integrar el análisis de riesgo y la sub-división del sistema clasificado para definir la estrategia de validación.
Metodología:
La evaluación sistemática del sistema se comienza en el ciclo de vida del sistema (SDLC) mientras se desarrollan todas sus etapas. Las fases del ciclo de vida del sistema (SDLC) son:
¾ Concepto
¾ Planificación del Proyecto ¾ Definición de requerimiento ¾ Especificación de diseño ¾ Código/Construcción ¾ Pruebas ¾ Implementación ¾ Mantenimiento
Es importante que se clasifique el sistema para determinar que fases del ciclo de vida que le aplican.
La clasificación del sistema esta categorizada por el software y se sugiere la siguiente clasificación.
Categoría Descripción
Categoria 1.
Sistemas Operativos (OS)
Establece sistemas operativos (SO) de redes o locales. Por ejemplo; DOS, UNIX,
VAX/VMS, Novell and Windows 95/98/NT Categoria 2.
Instrumentos, Microcontroladores Instrumentos programados.
Firmware, dispositivos electrónicos, pre-programados. Ejemplos, ASIC, ROM.
Categoria 3.
Paquetes Pre-programados
(COTS) Software comerciales
pre-programados,. Ejemplos hojas de cálculos (Excel).
Categoria 4.
Paquetes Configurables
Paquetes de software que son configurables para unas especificaciones ejemplo
SCADA,LAS, MRP,HMI Categoria 5
Sistemas programables desarollados
Software desarrollados por programación o por paquetes pre-programados con una aplicación determinada y requerida.
Categorias de clasificación de
Software
Tareas en el Ciclo de Vida del sistema
(SDLC) por fase
En la próxima tabla y diagramas se
presentan las fases del ciclo de vida de un
sistema (SDLC) y las tareas que se deben
realizar en cada categoría donde en cada
una de ella se consideran los requisitos de
Parte 11 una vez evaluado el sistema.
Categoria
Fase del SDLC Tareas del SDLC
1 2 3 4 5
Solicitud de Cambio aaa a a
Concepto
Análisis de Riesgo y Justificación a a
Plan Maestro aaa a a
Auditoría al Vendedor a a
Plan de Validación aaa a a
Planificación del proyecto e
Iniciación
Solicitud de Justificación aaa a a Requerimientos de Usuario a a a Requerimientos Funcionales aaa a a Definición de
Requerimiento
Matriz de Rastreo a a
Especificaciones de diseño
Especificación de diseño del sistema a a Configuración y Línea de Código a a a Construcción y
codificación Unidad de Integración al Plan de Pruebas,
Conjunto de Datos y Tipos de Pruebas. a
Tareas sugeridas en el Ciclo de Vida del sistema
C a t e g o r ia F a se d e l S D L C T a r e a s d e l S D L C 1 2 3 4 5 P r u e b a s P r u e b a s a c c e p t a b le s d e l sist e m a d e u su a r io , C a so s d e p r u e b a s, C o n ju n t o d e d a t o s, y R e p o r t e a C a lific a c ió n d e I n st a la c ió n y r e p o r t e s ( I Q &
R e p o r t ) a a a a a
C a lific a c ió n O p e r a c io n a l y r e p o r t e s ( O Q &
R e p o r t ) a a a a a
C a lific a c ió n d e P r o c e so y r e p o r t e s ( P Q & R e p o r t ) a a a a a R e p o r t e d e V a lid a c ió n a a a a a I m p la n t a c ió n N o t ific a c ió n d e R e le v o a a a a a R e p o r t e d e M a n t e n im ie n t o a a a a a C o n t r o l d e C a m b io s a a a a a
A d m in ist r a c ió n d e l S ist e m a a a a a a
P r o c e d im ie n t o s d e S e g u r id a d a a a a a R e sg u a r d o /R e c u p e r a c ió n a a a a a P la n d e r e c u p e r a c ió n d e d e sa st r e a a a a a L o g s d e M a n t e n im ie n t o a a a a a M a n t e n im ie n t o R e v isio n e s P e r ió d ic a s a a a a a
Requisitos Funcionales
Plan de Validación Parte 11 y Plan Maestro
Diseño y Construcción del Sistema Computadorizado
Selección del Vendedor
Especificaciones del Sistema Computadorizado Funciones Controladas Hardware y Software Evaluación Continua 2 Definición 3 Selección 4 Especificación 5 Desarrollo 6 Integración y Calificación Hardware y Software Equipo Calificación de Desempeño Funciones Controladas Hardware y Software IQ del Equipo
OQ del Equipo OQ Sistema Computadorizado IQ Sistema Computadorizado
Hardware Software
Fase 1 Definición del concepto del sistema Fase 2 Planificación del Proyecto
Fase 3 Requerimientos del Sistema
Fase 4 Especificaciones de diseño del Sistema
Fase 5 Construcción y Codificación del Sistema
Fase 6 Definición de Pruebas
Fase 7 Implantación y Calificación
Fase 8 Definición de Mantenimiento del Sistema
Fase 9 Definición del Retiro del sistema
Fases:
PLAN DE
VALIDACIÓN
• El Documento debe incluir:
– Descripción del Sistema Computadorizado
– Responsabilidades
– Guías Corporativas
– Procedimientos Estándares de Operación
– Itinerario de Actividades
– Filosofías y métodos a utilizarse
– Criterios de Aceptación
Responsabilidades
usuario/proveedor
• Responsabilidades del usuario
– Validación de los sistemas.
– Remediaciones procedurales para el
cumplimiento de ERES.
• Responsabilidades del proveedor
– Proveer remediaciones técnicas a los usuarios o
software para el cumplimiento de ERES.
¿Quiénes conforman el comité de
validación?
• Control de Calidad y cumplimiento
• Ingenieria
• Servicio Técnico
• Validación
• IS/IT, “Automation”
• Manufactura
• Compra
Plan Maestro de Validación
Enfoque y estrategias
• El Plan Maestro define el concepto general del
proyecto y los controles y estrategias a utilizarse
durante el proceso de validar los sistemas y sus
componentes
• El Plan Maestro general (VMP) se puede
descomponer por areas o por sistemas
• Es necesario documentar como proceder en cada
evento y como administrar cada etapa del ciclo de
validación
Aspectos a Considerar para
desarrollar el Plan Maestro (VP)
• Inventario del sistema
• Análisis de Riesgo (Categorización, Impacto,
Criticalidad, Prioridad)
• Estrategia de Validación
• Recursos a utilizarse
• Objetivos especificos de alcance
• Calendario (Schedules)
Plan Maestro
• Establecer el plan de acción
para las actividades de validacion y los resultados
• Definir recursos y calendario
de actividades.
• Comprometer a todos los
componentes del grupo de validaciones
• Proveer quías de diseño
• Establecer el paso regulatorio • Establecer las estrategias de
validaciones
• Definir los grupos y sus
Validación efectiva en costo
• Garantizar cumplimiento de requerimientos de
producto
• Prevenir observaciones de las agencias
regulatorias y posibles rechazos de productos.
• El esfuerzo de validación debe asistir en in
assessing product quality; facilitate the transfer
of processes and/or technology to operations
and identify areas where improved process
controls are desirable to assure process
Ventajas de Validar
– Reduce inspecciones
– Reduce pruebas
– Reduce duplicidad de trabajo
– Reduce “trouble-shooting”
– Reduce scrap
– Reduce dificultades en el producto
– Reduce costo asociados con rechazo de lotes
– Timepo cort de “start-up”
– Procesos robustos
– Mejor entendimiento del proceso
– Los supervisores y gerentes de area adquieren
mejor conocimiento y control de los procesos.
REQUISITOS
FUNCIONALES
Requisitos Funcionales Especificaciones y Diseño Calificación 1 2 3 4 Las Especificaciones y el Diseño suplen la CalificaciónCada elemento de prueba en la Calificación es rastreable a uno o más elementos de las Especificaciones y del Diseño Cada elemento de las Especificaciones y
del Diseño es rastreable a uno o más elementos de los Requisitos Funcionales
Los Requisitos Funcionales suplen a las Especificaciones
REQUISITOS
FUNCIONALES
Re
qui
sito
s
Re
qui
sito
s
Fu
nci
ona
les
Fu
nci
ona
les
Aseguramiento
Aseguramiento
de Calidad
de Calidad
Ingenier
Ingenierí
ía
a
Cliente /
Cliente /
Usuario
Usuario
Validaci
Validaci
ó
ó
n
n
REQUISITOS
FUNCIONALES
• Requisitos y Características
Distintivas
– Descripción del Sistema Computadorizado – Equipos a Controlar
– Secuencia de Operación – Datos de Entrada
– Procesamiento de Datos – Datos de Salidas
– Interfaces con el Operador – Requisitos de Reportes – Restricciones
¿
¿QuQuéé es lo que el sistema debe hacer?es lo que el sistema debe hacer?
¿
REQUISITOS
FUNCIONALES
Procesamiento
Procesamiento
Entrada
Entrada
Salida
Salida
•
• VerificaciVerificacióón de datos de entradan de datos de entrada
•
• Respuestas a condiciones anormalesRespuestas a condiciones anormales
•
• DesbordamientoDesbordamiento
•
• Falla de comunicaciFalla de comunicacióónn
•
• Manejo de erroresManejo de errores
•
• ParParáámetros afectados por la operacimetros afectados por la operacióónn
•
• MMéétodos (ecuaciones, etc..)todos (ecuaciones, etc..)
• • FuentesFuentes • • CantidadesCantidades • • UnidadesUnidades • • RangosRangos • • ExactitudExactitud • • ToleranciaTolerancia • • DestinoDestino • • CantidadesCantidades • • UnidadesUnidades • • RangosRangos • • ExactitudExactitud • • ToleranciaTolerancia • • MensajesMensajes • • ReportesReportes
Desarrollo de especificaciones de
usuarios, funcionales y de diseño
• Las especificaciones de un sistemas se definen por
el proceso en
– Requerimientos de usuarios
– Requerimientos funcionales
– Especificaciones de Diseno
• Deben de ser:
– Leíbles
– Claras
– Identificables
– Rastreables
ESPECIFICACIONES
DEL SISTEMA
COMPUTADORIZADO
• Diagramas
– Flujogramas del Proceso – Flujogramas de Datos – Secuencia de operación
• Interacción con el Usuario
• Interacción con otros equipos
• Interacción con el Medio
Ambiente Operacional
• Equipos a Controlar
Documento o colecci
Documento o coleccióón de documentos, que describen de forman de documentos, que describen de forma clara y completa como es que el Sistema Computadorizado va
clara y completa como es que el Sistema Computadorizado va
a operar y como satisface los Requisitos Funcionales.
a operar y como satisface los Requisitos Funcionales.
¿
ESPECIFICACIONES
DEL SISTEMA
COMPUTADORIZADO
(cont.)
• Operación del Sistema Computadorizado
– Modos de operación – Condiciones irregulares – Parámetros operacionales
• Entrada, Salida, Límites • Rango
• Alarmas e “Interlocks” – Detalles sobre pantallas – Detalles sobre reportes
AUDITORÍA AL
VENDEDOR
– Técnicamente competente y comercialmente calificado para suplir y dar apoyo al sistema – Conocimiento sobre los Requisitos de la
Calificación
– Proveer un Sistema para aplicaciones GMP – Aseguramiento de Calidad de “Software”
• Estándares de Programación de “Software” • Especificaciones sobre Diseño de “Software” • Plan para probar el “Software”
• Plan de auditoría de “Software” • Adiestramiento interno al personal – Procedimientos de Control de Cambios – Procedimientos de Documentación
AUDITORÍA AL
VENDEDOR (cont.)
• Auditoría al Producto
– “Software”
• Programas de Aplicación
– Sistema de Aseguramiento de Calidad
• Programas de Sistema Operacional o
Configurable
– Historial de satisfacción
– Análisis retrospectivo del reporte de problemas y el procedimiento de corrección
– Cantidad y tipos de aplicaciones utilizando el programa – Tiempo de la versión en el mercado
AUDITORÍA AL
VENDEDOR (cont.)
– “Hardware”
• Reglamentaciones de ingeniería y calidad • Historial de uso
• Durabilidad • Contabilidad
• Exactitud operacional durante condiciones definidas del medio ambiente operacional del sistema
ESPECIFICACIONES DEL
SISTEMA
COMPUTADORIZADO
• Diagramas
– Flujogramas del Proceso – Flujogramas de Datos – Secuencia de operación
• Interacción con el Usuario
• Interacción con otros equipos
• Interacción con el Medio
Ambiente Operacional
• Equipos a Controlar
Documento o colecci
Documento o coleccióón de documentos, que describen de forman de documentos, que describen de forma clara y completa como es que el Sistema Computadorizado va
clara y completa como es que el Sistema Computadorizado va
a operar y como satisface los Requisitos Funcionales.
a operar y como satisface los Requisitos Funcionales.
¿
ESPECIFICACIONES
DEL SISTEMA
COMPUTADORIZADO
(cont.)
• Operación del Sistema Computadorizado
– Modos de operación – Condiciones irregulares – Parámetros operacionales
• Entrada, Salida, Límites • Rango
• Alarmas e “Interlocks” – Detalles sobre pantallas – Detalles sobre reportes
Tipos de Software
• Programas del Sistema: provee las instrucciones de operación básica de la computadora y control de operaciones
• Programa Configurable: el usuario no puede cambiar el código del programa pero le permite definir una serie de condiciones tales como:
– parámetros operacionales – parámetros de reportes – condiciones de alarmas
• Programa de Aplicación: código que es escrito o modificado para una función específica. Cuando un programa configurable es utilizado, los parámetros y
operaciones que son especificados por medio de éste, son tratados como programas de aplicación.
PROGRAMAS DEL
SISTEMA
• Sistemas operativos, compiladores, interpretadores,
“firmware”, programas de diagnósticos y programas de los periferales no están sujetos a validación. Se recomienda documentación histórica de uso satisfactorio, versión utilizada, fecha de introducción al mercado, órdenes de compra y documentación del vendedor (certificaciones y auditorías).
DISEÑO Y
CONSTRUCCIÓN DEL
SISTEMA
COMPUTADORIZADO
• Dibujos de Ingeniería – “P&IDs”– Instalación del Alambrado de Control – Distribución Eléctrica y Alambrado de
Tierra
• Especificaciones
– Instrumentos de Campo – “Hardware”
– “Software”
• Asignación de Entrada y Salida de Datos (I/O
DISEÑO Y
CONSTRUCCIÓN DEL
SISTEMA
COMPUTADORIZADO
(cont.)
• Codificación• Verificación del “Software”
– Estructural – Funcional
• Manuales del Usuario
• Adiestramiento
DOCUMENTOS DE
CALIFICACIÓN
Calificaci Calificacióónn Operacional (OQ) Operacional (OQ) Calificaci Calificacióónn de Instalac i de Instalac ióón (IQ)n (IQ)CALIFICACIÓN DE
INSTALACIÓN (IQ)
Definición:
Verificación documentada de los aspectos relevantes de la
instalación del “Hardware” y el “Software” y su cumplimiento con las especificaciones del sistema.
CALIFICACIÓN DE
INSTALACIÓN (IQ)
• Partes del documento
– Título – Hoja de aprobaciones – Tabla de contenido – Objetivo – Alcance – Responsabilidades
– Descripción del sistema
– Procedimientos generales y documentación – Verificación de instalación • Título de la prueba • Objetivo • Procedimiento o metodología • Criterios de aceptación • Anejo
CALIFICACIÓN DE
INSTALACIÓN (IQ)
• Verificación de instalación
– Verificar que la información requerida esté al día y debidamente aprobada (“Hardware” y “Software”). – Verificación estructural del código fuente para
certificar que esté libre de errores, código muerto
(“dead code”) e instrucciones redundantes (“Programa de aplicación”).
CALIFICACIÓN DE
INSTALACIÓN (IQ)
• Verificación de instalación (cont.)
– Verificar que las condiciones ambientales
(humedad, temperatura,electromagnetismo y
radio frecuencia) no afecten los componentes
e instrumentos.
– Verificar que el “Software”
haya sido debidamente
instalado basado en el
procedimiento de
CALIFICACIÓN DE
INSTALACIÓN (IQ)
• Verificación de instalación(cont.)
– Verificar los cables y conexiones según diagramas y especificaciones.
– Realizar pruebas diagnósticas a los
componentes que lo requieran.
– Verificar las especificaciones de
seguridad física y lógica
CALIFICACIÓN DE
INSTALACIÓN (IQ)
• Verificación de instalación (cont.)
– Verificar los procedimientos de: • Operación
• Seguridad
• Calibración y mantenimiento
• Copias de resguardo y recuperación de desastres • Control de cambio
• Alarmas y manejo de errores • Retención de documentos
CALIFICACIÓN DE
INSTALACIÓN (IQ)
• Verificación de instalación (cont.)
– Verificar que los componentes e instrumentos contengan los servicios especificados
– Verificar que los instrumentos sean calibrados y haya procedimientos para ello.
CALIFICACIÓN DE
INSTALACIÓN (IQ)
• “Hardware”
– Información Requerida
• Listado de componentes con sus especificaciones • Diagramas – Proceso e instrumentación – Conexión • Utilidades o servicios – Electricidad – Aire comprimido
CALIFICACIÓN DE
INSTALACIÓN (IQ)
• “Hardware”
– Información Requerida (cont.) • Manuales
– Instalación y configuración – Operación y mantenimiento • Órdenes de compra
• Documentación del vendedor – Certificaciones
Pruebas de Instalación (IQ)
• Pruebas de instalación de sofware o funciones que generan el
‘Audit Trail’, controles de seguridad automatizados para firma
electrónicas, adquisición de datos, sincronización de fecha y
hora, anti-virus u otro software instalados para remediar
aspectos de requisitos tecnológicos.
• Verificación de que los procedimientos asociados al sistema
estén aprobados por el Departamento de Control de Calidad y
que existen en un mecánismo controlado.
• Verificación de la evidencia de educación de los usuarios del
sistema, capacitaciones, y/o experiencia.
• Verificación de toda la documentación de validación de
computadora previa a la cualificación.
• Verificación de los archivos de desarrollo y configuración del
sistema si los sistemas son categoria 4 ó 5.
PROGRAMA
CONFIGURABLE
• Información Requerida
– Documentación histórica de uso satisfactorio.
– Análisis retrospectivo de los reportes de problemas con el programa.
– Procedimientos usados por el vendedor para informar y corregir problemas con el programa.
– Fecha de introducción al mercado de la versión utilizada del programa.
PROGRAMA
CONFIGURABLE
• Información Requerida (cont.)
– Número aproximado de usuarios de dicha versión.
– Disponibilidad del código fuente (“source code”) para ser revisado en cualquier momento
– Órdenes de compra
– Documentación del vendedor • Certificaciones
PROGRAMA DE
APLICACIÓN
• Código fuente (“source code”) en disco y papel, lenguaje
utilizado y versión del compilador o interpretador
• Flujogramas
• Descripción de módulos y listado de subprogramas,
PROGRAMA DE
APLICACIÓN (cont.)
• Estándares y procedimientos utilizados para el
desarrollo, pruebas y mantenimiento del programa
• Descripción de detección de errores y recuperación
PROGRAMA DE
APLICACIÓN (cont.)
• Definición de todas las variables y constantes
• Especificación de todas las entradas (“inputs”),
procesamiento y salidas (“outputs”)
• Resultados de pruebas realizadas durante la fase de
CALIFICACIÓN
OPERACIONAL (OQ)
• Definición:
Verificación documentada de que el sistema opera en conformidad con las especificaciones del sistema.
CALIFICACIÓN
OPERACIONAL (OQ)
• Partes del documento
– Título – Hoja de aprobaciones – Tabla de contenido – Objetivo – Alcance – Responsabilidades
– Descripción del sistema
– Procedimientos generales y documentación – Pruebas funcionales • Título de la prueba • Objetivo • Procedimiento o metodología • Criterios de aceptación • Anejo
CALIFICACIÓN
OPERACIONAL (OQ)
• Pruebas funcionales
– Verificación de comunicación
• El objetivo de esta prueba es verificar y documentar que el sistema tiene la habilidad de reconocer la pérdida de comunicación entre los componentes
críticos y que posee la lógica apropiada para manejar esta situación hasta que la comunicación sea
establecida nuevamente. – Verificación de alarmas
• El objetivo de esta prueba es verificar y documentar que el sistema tiene la habilidad de alertar al operador de que una condición anormal que pone en peligro la seguridad del personal o compromete la calidad del producto está ocurriendo.
CALIFICACIÓN
OPERACIONAL (OQ)
• Pruebas funcionales (cont.)
– Verificación de interfaces con el usuario (operador)
• El objetivo de esta prueba es verificar y documentar que:
– los campos definidos para cada parámetro de operación son los correctos
– los datos de entrada cumplen con los rangos de operación
– cada menú u opción sigue la secuencia especificada – cada mensaje o reporte sigue el formato especificado
– Verificación de los valores límites o fronteras
• El objetivo de esta prueba es verificar y documentar el comportamiento del sistema cuando son recibidos
valores justamente sobre o justamente debajo del rango de operación.
CALIFICACIÓN
OPERACIONAL (OQ)
• Pruebas funcionales (cont.)
– Verificación bajo condiciones extremas (“Worst Case”)
• El objetivo de esta prueba es verificar y documentar el comportamiento del sistema cuando:
– todos los componentes del sistema o equipos relacionados están trabajando al mismo
tiempo
– todos los componentes del sistema o equipos relacionados están trabajando un tiempo mayor que el normal
– están corriendo dos o más aplicaciones al mismo tiempo
CALIFICACIÓN
OPERACIONAL (OQ)
• Pruebas funcionales (cont.)
– Verificación de control de operación
• El objetivo de esta prueba es verificar y documentar el comportamiento del sistema cuando otros sistemas o mecanismos ejercen control sobre la misma operación.
– Verificación durante falla eléctrica
• El objetivo de esta prueba es verificar y documentar que el sistema puede recuperarse efectivamente de una falla
eléctrica mediante la retención de los valores de producción y la secuencia del proceso seleccionado o cualquier tarea o información que estaba en progreso cuando ocurrió la falla eléctrica.
– Verificación de operación del sistema
• El objetivo de esta prueba es verificar y documentar que el sistema trabaja adecuadamente y de forma integrada.
Pruebas Funcionales y
Operacionales en (OQ)
• Pruebas de Control de los Archivos, verificar:
– Imprimir archivos
– El contenido se ve en pantalla
– La entrada (input) al archivo
– Se transfiere en formatos comunes
– Acceso al archivo
– Retención de los archivos
– Niveles de acceso
– Secuencia de pasos
– Data de equipos verificable automaticamente
– Resguardo y Recuperación
– Metadata
• Pruebas al ‘Audit Trail’, verificar:
– Data generada que tenga fecha, hora, nombre de
usuario, tipo de cambio
– Que la data sea solo para leer (Read Only) y pueda ser
impresa
– Es automatico para cada entrada
– Sincronización de fecha y hora
– Valores previos
– Transferencia a formato de texto u otro formato que se
pueda ver en otro sistema
– Protección de acceso
– No manejable
Pruebas Funcionales y
Operacionales en (OQ)
• Seguridad física y lógica, verificar:
– Controles mecánicos de acceso a cuartos protegidos
– ID ‘username’
– Contraseña ‘Password’
– Privilegios específicos por responsabilidad
– Eventos de terminar connecciones
– Eventos de bloqueo temporero de acceso
– Eventos de protecciones por tiempo de inactividad
– Eventos de control de mensajes por contraseñas de
acceso no correctas o falsas
Pruebas Funcionales y
Operacionales en (OQ)
• Procedimientos operacionales se verifica:
– Control de Cambios
– Resguardo y Recuperación
– Manejo y operaciones en el sistema
• Pantallas
• Sequencias
• Entrada de datos
• Imprimir
• Alarmas
– Administración del sistema
Pruebas Funcionales y
Operacionales en (OQ)
• Firmas electrónicas se verifica:
– Nombre del usuario a firmar
– Combinaciones de ID/Contraseña
– Fecha y Hora
– Propósito y significado de la firma
– Referencia al archivo electrónico firmado
– Autenticidad de la firma
– Concordancia de eventos y la firma
– Archivos se imprimen con la firma electrónica necesaria
– Firma única y comprobable
Pruebas Funcionales y
Operacionales en (OQ)
EVALUACIÓN CONTINUA
Sistema Computadorizado Calificado Procedimientos Estándares de Operación Procedimientos de Control de Cambios Procedimientos de Mantenimiento Adiestramiento Medidas de Seguridad Re-evaluación Periódica de Desempeño Plan de Contingencia / Recuperación de un DesastreSistema de Cambios
• El sistema de cambio se da por las siguientes
razones:
– Evaluación del sistema
– Cambios en versiones del Software
– Cambios de Hardware
– Cambios en subsistemas o sistemas alternos
– Cambios en sequencias operacionales
– Cambios en recetas o el proceso
– Reubicación del sistema
Sistema de Cambios
• Se evalua el cambio junto al grupo de trabajo y se
genera un hoja de cambio.
• Se evalua el impacto del cambio y se analisa el riesgo
e impacto en la criticalidad del sistema y el contacto
del sistema al producto.
• El cambio es aprobado por los diferentes componentes
del grupo con representaciones de los departamento de
ingenieria, ambiental, control de calidad y
manufactura.
• Se evalua el efecto del cambio, si impacta la
validación actual, los documentos del SDLC y los
procedimientos operacionales (SOPs)
– En cambios de software y hardware impacta todo el SDLC y
require validarse el sistema
– Todos los cambios asociados a Sistemas Computadorizados
en su mayoria afectan el sistema validado y sus documentos
del SLDC
Análisis de Riesgo (AR)
• Se descompone el sistema en subsistemas para ser
evaluado.
• Se evalua la criticalidad del sistema dada por la
calidad del producto
– Impacto directo
– Impacto no-directo
• Se evalua el sistema por aspectos de seguridad
– Ambiental
– Lógica
– Física
• Se genera un documento donde se registre todo el
proceso de investigación.
• El AR debe ser periodico, por cambios y por
evaluación del sistema.
Ingenieria-Mantenimiento
• Comisionamiento (Comissioning)
– Se realiza en etapas de instalaciones del sistema y
equipos.
• FAT – La verificación del sistema (software y
controles) en las instalaciones del provedor
• SAT- La verificación de la integración del sistema
en las instalaciones de la planta de manufactura.
Mantenimiento
• Es necesario e imprecindible para la operación
contiua del sistema.
• Deben existir procedimientos que definan los
pasos a sequir y consideraciones técnicas para
llevar a cabo el mantenimiento y establecer en que
periodos de tiempos se realize.
• El mantenimiento asegura la calidad del proceso
de manufactura y el cumplimiento regulatorio del
producto.
R&D Conceptual
Design Basic Engineering
Detailed Engineering Construction Start-up/ Validation Operation Validation Input Project Planning Maintenance Strategy
GMP and Design Audits
Engineering Design Review FDA Meetings Protocol Development Procurement FAT IQ OQ PQ Reporting FDA Review Commissioning Plan/Sequence
Set up Data Mgt. System
Pop. MEL Equip Info
Populate CMMS w. PMs, SOPs, Part IDs Vendor Manuals CMMS Upload Complete Maintainability Review Criticality Analysis
Develop Craft Training FMEA Main ten a nce Valid atio n Spine PM/PdM Development
Dev. Maint. Schedule KPI’s / Metrics
Go Forward
Deliver Craft Training Maint. Process SU
Construction Review
Val. CMMS Master Plan Develop.
Calidad y Desarrollo
• La calidad se debe inicar desde el comienzo del
proyecto desde el concepto hasta el proceso de
retiro
• El ciclo de vida de validacion debe ser evaluado
continuamente observando la calidad de los
controles establecidos para las distintas etapas.
• Los grupos de control de calidad deben tener
participación activa en la toma de deciciones y no
solamente en la revisión de documentación
Producción y Materiales
• Recursos Humanos
• Procedimientos
• Manuales
• Especificaciones
• Dibujos
• Formulaciones o recetas
• Control de seguridad
• Control de documentos
• Control de Cambios
• Control de Fallas
RECORDEMOS...
Definir bien el sistema a ser evaluado
Lo que no se documentó,
no fue realizado
II Guias de GAMP y Analisis de
Riesgo Efectivo
• GAMP conceptos y definiciones - Que es GAMP, Como nos
ayuda y cuando utilizarlo.
• Guías y sus usos en el GAMP - Definir las distintas guías
sugeridas por el GAMP y conocer sus propósito e implementación.
• Propósito del Análiss de riesgo - Porque es necesario el análisis
de riesgo, cuando y como se usa durante el SDLC.
• Aplicación de Análisis de Riesgo - Cuando aplicar el Análisis de
Riesgo para una estrategia adecuadas de validación y en que tipos de sitemas es adecuado y beneficioso.
• Implementación al Análisis de Riesgo - Como implementar el
análisis de riesgo en un sistema validado o por validar para mitigar funcionalidades de alto riesgo que afecten
adversamente el proceso de manufactura donde se use el sistema computadorizado.
Estandar GAMP enfocados en
los Sistemas de Control de
Proceso
• Tipos de Equipos y Sistemas.
• Desarrollo de especificaciones de usuarios, funcionales y
de diseño.
• Evaluación del impacto.
• Componentes críticos del proceso.
• Programa de actividades.
• Evaluación crítica de software.
• Elementos de validación especificos de los sistemas de
control de proceso.
Estandar GAMP enfocados en
los Sistemas de Laboratorios
• Nueva categorización aplicable a los sistemas de
laboratorio.
• Desarrollo vs. Implementación del ciclo de vida.
• Especificaciones y rastreabilidad.
• Codificación y Construcción.
• Elementos de validación específicos de los sistemas de
laboratorio.
Estandar GAMP enfocados en el
control y cumplimiento de la
infraestructura de IT
• Plataformas.
• Proceso y personal.
• Sistemas de administración de calidad.
• Calificación de plataformas.
• Procuramiento e instalación.
• Aplicación del análisis de riesgo.
• Reportes y entregas.
Estandar GAMP enfocados en el
control y cumplimiento de los
Sistemas de Informacion Global
• Consideraciones en la administración del proyecto.
• Planeación de la administración de datos.
• Arquitectura del sistema.
• Validación y establecimiento.
• Administración de la rastreabilidad.
• Seguridad del sistema.
• Respaldos y recuperaciones.
Estandar GAMP basados en el
manejo del riesgo de registros y
firmas electronicas
• Conceptos claves.
• Riesgos en registros electronicos.
• Evaluación del sistema.
• Peligros.
• Rigor de los controles.
• Registros hibridos.
Tipos de Equipo y Sistemas
• Sistemas de Manejo de Edificio (BMS
• Equipos configurables
• Sistemas Distribuidos de Control (DCS)
• Sistemas Embedded
• Controles Logicos Programables (PLC)
• Control Supervisados y Adquisicion de
datos (SCADA)
BMS
• Son sistemas que se utilizan para controlar las
condiciones ambientales (ambiente) de un edificio
utilizado para la preparación de un producto
regulado.
• En sus siglas en Ingles “Building Management
Systems”
• Contienen Sistemas computadorizados
– Software (categoría 2,3,4), Hardware
– Controles
Equipos Configurables
• Son instrumentación que contienen
parámetros que se configuran para el
funcionamiento del equipo que realizar la
función definida.
• Ejemplos; PID, HPLC, Analizadores,
Lectores Código de barras, Balanzas.
• Estos equipos contienen software internos
previamente programados, categoria 2.
DCS
• Son sistemas de controles integrados bajo
parámetros de control o monitoreo en un
solo y único sistema con definiciones
especificas únicas y no multiples.
• Los Software de estos sistemas se
consideran Categoría 4, si no son
‘customizados’
• Son sistemas de controles para operaciones
complejas de integración.
Embbeded
• Son sistemas con aspectos programables y
configurables.
• Contienen PLCs, software configurables, e
instrumentación.
• Por ejemplo sistemas de empaque.
PLC
• Sistemas programables de control de
procesos. Controlan entradas y salidas para
realizar una función según definida en un
orden lógico y secuencial (Algorítmico).
• Contienen tarjetas análogas o digitales para
proveer control/monitoreo a la
instrumentación del proceso.
SCADA
• Contienen uno o mas PLCs.
• Tienen la capacidad de monitorear,
controlar y evaluar decisiones.
• La adquisición de data es imprescindible
para evaluaciones del proceso y control del
mismo.
• El Manejo de eventos es determinante en
estos sistema para la estructura del mismo.
Standalone
• Son sistemas independientes que se
proporcionan capacidades de proceso en
sistemas antes mencionados como DCS,
SCADA.
• Tienen sus propias funcionalidades
utilizadas por sistemas que se alimentan de
ellos para completar el proceso.
Evaluación del impacto
• Se inicia con la planificación del proyecto al
definir los URS.
• Se Define el plan a realizar para definir el
proceso de evaluación del sistema y sus
implicaciones a través de un documento
• Se Aprueba el documento de Plan por el
equipo de aprobación del proyecto
• Se comienza a ejecutar el plan
Análisis de Riesgo (AR)
• Ejecución del Plan escrito o por un procedimiento:
– Se descompone el sistema en subsistemas para ser
evaluado.
– Se evalúa lo critico de cada sistema identificado del
PCS.
• Impacto directo a la calidad del producto • Impacto no-directo a la calidad del producto
– Se evalúa el sistema por aspectos de seguridad
• Ambiental • Lógica • Física
Análisis de Riesgo (AR)
– Se genera un documento donde se registre todo
el proceso de investigación.
– El AR debe ser periodico, por cambios y por
evaluación del sistema.
Componentes críticos del proceso
• Se identifican cada componente/funcional
del sistema
• Los componentes del sistema ya
identificados se evalúan por critico o no
critico.
• Se identifican cada uno en base a el impacto
a la calidad del producto. En contacto físico
o implicaciones de datos que identifican la
calidad del producto.
Programa de actividades
• Se define un programa como antes
mencionamos por procedimiento o por plan,
este debe contar con un calendario definido
de actividades para el análisis de riesgo a
ejecutarse.
• Se define quienes serán los responsables de
ejecutar y en que periodo de tiempo.
Evaluación crítica de software
• La evaluación critica de software se realiza al
principio del proyecto al definir las
especificaciones del sistema y se evalúa lo
siguiente:
– GxP
– GAMP software categoría
– Seguridad y ambiental
– Parámetros críticos de PCS
• El propósito es para definir al funcionalidad del
software y como afecta los parámetros de la
Elementos de validación especificos
de los sistemas de control de proceso
• Desarrollo de Software GAMP categoría 5
• Ciclo de vida del desarrollo del Software
(Aplicación del sistema)
– Requerimientos
– Diseño
– Pruebas Internas del desarrollo
• Pruebas estaticas
• Pruebas Dinamicas
Calibracion
• Desarrollar inventario de instrumentación y
equipo del PCS que necesitan calibración
• Usar los procedimientos internos de
calibración o mantenimientos para
instrumentación/equipo ya en la planta.
Crearlo para los nuevos.
• Plan de mantenimiento actualizado y
periódicos
Procesos
• Los siguientes son procesos típicos en IT:
– Manejo de Cambio
– Manejo de configuración
– Manejo de seguridad
– Manejo de problemas
– Ayuda técnica
– Resguardo y Recuperación
– Recuperación en caso de desastre (DRP)
– Monitoreo de Operaciones
– Manejo de suplidores
– Revisiones periódicas
Proceso y Personal
• El personal debe tener definidos claramente sus
roles y responsabilidades y estar documentados, y
aprobados por la gerencia de la empresa.
• La necesidad del personal se cuantifica por la
cantidad de procesos a mantener, las areas de
servicios dentro de IT, la candidad de servidores y
redes, entre otros.
• No se limita a contar con personal para:
– gerencia administrativas por sistemas
– Calidad y cumplimiento
– Infraestructura física
Sistemas de administración de
calidad (QMS)
• Garantiza el estado de control y cumplimiento de IT.
• Los siguientes elementos se necesitan para cumplir las
metas del QMS.
– Manual de Calidad
– Definir Roles y Responsabilidades – Manejo de archivo y data
– Manejo de documentación – Documentación de pruebas – Procedimientos operacionales – Capacitación
– Periodos de evaluación y revisión del QMS – Auditorias por QA
Aplicación del análisis de riesgo
• El manejo de riesgo considera los siguientes pasos
para el control de riesgo: (ver apéndice #2)
– Análisis – Definir los limites de la infraestructura al
impacto en el negocio y sus factores, para asignar
prioridad a los riesgos.
– Evaluación – Determinar cuales de los riesgo analizado
serán aceptado y sus consecuencias.
– Control – Determinar el plan de reducción del riesgo y
como eliminar o minimizar el riesgo.
– Revisión y evaluación continua – Determinar con que
frecuencia se evaluara el riesgo a los sistemas
Calificación de plataformas
• Se crea un plan de proyecto
para el sistema de IT a calificar
• Se define una estrategia en este
plan donde establezca las distintas actividades de
considerar durante las fases de un ciclo de vida regular.
• Si la plataforma es única de una
aplicación se valida como parte de la aplicación.
• Se define si la plataforma es
GxP.
• Se define las categorías de sus
elementos.
• Se definen los componentes
críticos para someterlos a análisis de riesgo.
Consideraciones de diseño
• Certificaciones de Cables de la red
• Calificación de los Servidores y certificaciones
• Calificación de los Clientes (PC)
• Verificación de Comunicación
• Monitoreo de la Comunicación
• Dibujos de la Red
• Topología de la red GxP vs, Non GxP
• Protocolos de comunicación
• Sistemas de Almacenamientos de datos
• Procedimientos
Procuramiento e instalación
• Los componentes de las plataforma y sus servicios son
identificados como de calidad por los suplidores.
• El suplidor es quien conoce y puede demostrar el nivel de
calidad, el servicio efectivo y los riesgos asociados en caso
de falla de la plataforma.
• Realizar un FAT de la plataforma y sus componentes antes
de llevar al lugar final.
• Una vez la plataforma se recibe se debe:
– Verificar la orden de compra y sus elementos
– Almacenar en un lugar apropiado de acuerdo a las especificaciones del equipo.
Evaluación del Suplidor
• La compañía debe utilizar el programa de
evaluación del suplidor.
• El suplidor debe ser evaluado antes de ser
seleccionado para determinar:
– Aprobado
– Aprobado condicionalmente
– No Aprobado
• Si la plataforma es GxP, QA debe intervenir desde
el principio de la evaluación al suplidor y
Documentación necesaria
• Especificaciones de diseño
• Descripción de hardware y software
• Manuales de operación
• Manuales técnicos
• SOPs
• Topología de la red
• Diagramas lógicos de la red
• Sistema de etiquetaje
• Lista de cables
• Lista de direcciones lógicas
• Documentación del suplidor incluyendo la evaluación y
sus programas de calidad
Condiciones ambientales
• Se verifican las condiciones ambientales
para garantizar que la plataforma pueda
trabajar adecuadamente según las
especificaciones ambientales sugeridas por
el suplidor.
– Temperatura y humedad
– Eléctricas
Servidores
• Se verifica la configuración de los componentes de software y hardware del servidor de acuerdo a las especificaciones de diseño aprobadas.
• Se prepara un CIL (lista de configuraciones requeridas para los servidores), para así ser usada cuando se instale otro servidor nuevo.
• Hardware CIL
– Modelo y marca
– Tipo y cantidad de memoria – Números de CPUs y discos – Controles de discos
– Información para reconstruir el servidor
• Software CIL
– Sistema Operativo (OS) – Programas de comunicación
– Programas de remediación de otros software (“patches, services packs”) – Controles de acceso (seguridad)
Redes
• Red física; Verificación:
– De cables y sus certificaciones
– Factores ambientales
– Estándares de conexión
– Configuración de los componentes de comunicación y
conexión
• Red lógica; Verificación:
– De la configuración del sistema de manejo de la red
– Protocolos de comunicación (SNMP para TCP/IP)
– Cumplimiento de las especificaciones de la red
Reportes y entregas
• Reporte se documentan los resultados de cada
actividad del IQ y el OQ.
• Puede ser uno o mas reporte de acuerdo a la
estrategia utilizada de validación.
• Aprobar el reporte
• La entrega de la plataforma debe realizarse cuando
su Calificación este completada en reporte, al
igual que los reporte de la validación de otras
aplicaciones de la plataforma.
Entrega para Red en vivo
• Se debe realizar una ejecución en paralelo
antes de cortar la plataforma vigente por la
nueva cualificada.
• Este proceso debe llevarse a cabo por un
plan, donde se establezca el periodo la data
a usarse y la migración de la data ya
validada.
• Esta etapa de entrega es la mas critica y la
de mayor tiempo.
Sistemas Globales
• Definir un sistema global
– Sistema de información que su requerimientos,
procesos y estándares son definidos en la
compañía para uso global (mas de un lugar)
bajo las misma especificaciones y/o
especificaciones locales. Son definidos y
estructurados como centralizados y/o
Consideraciones en la
administración del proyecto
• Organización de proyecto global
– Jerarquía de proyecto global con representates por localidades.
• Efectividad del manejo de proyecto.
– Gerente de proyecto global
• Gerentes locales
– Elemento de manejo globales y estándares – Elementos de manejo locales y estándares – Diversidad cultural
– Aspectos regulatorios globales y locales – Planificación del manejo de data
– Arquitectura del sistema – Procedimientos
Planeación de la administración de
datos
• Crear estadandares de manejo de dato globales
• Establecer y conocer los aspectos regulatorios globales y locales que
afecten el manejo de dato.
• Aplicar a nivel local regulaciones globales del manejo de datos (Ex.
Parte 11).
• Definir Roles y responsabilidades.
• Definir objetivos.
• Definir estrategias y metodologías.
• Definir la necesidad de la data por regiones y localidades.
• Definir requisitos de la administración de la data y las herramientas a
utilizarse desde el concepto de las aplicaciones de manejo y administración hasta el almacenamiento.
• Definir el modelo de dato y la base de datos.
Requisitos especificos de usuarios
(URS) para el ciclo de vida de la
data
• Estos requisitos de el ciclo de vida de la data deben definirse en el URS.
– Creación y/o migración – Definiciones de meta data – Validación y/o verificación
– Políticas para creación y eliminación o modificación de dato. – Obtener y usar la data
– Autoridad de la data – Dueño de data
– Técnicas de acceso de datos – Manejo de copia de dato – Control de versión de dato – Almacenaje y/o migración
– Arquitectura de dato central o distribuida – Definición de data critica
– Definir todos los elementos de datos y enlaces en sus elementos – Auditoria de datos
Políticas, estándares, guías
• Definir el uso de la data y su calidad
requerida.
• Crear políticas, guías o estándares
específicos combinados con los existentes
por agencias y/o instituciones.
• Crear capacitación para la aplicación de
estas políticas, guías y estándares
Base de Datos y Modelo de dato
• Administrador de datos debe:
– Control de calidad del modelo de data global o
local.
– Mantener consistencia de administración y sus
herramientas a nivel global o local.
– Mantener estabilidad, seguridad, coherencia en
la data a nivel global y local.
– Manejo de copia de datos
– Infraestructura controlada
Arquitectura del Sistema
• Definir la aplicación de la data a nivel
global y/o local
• Definir la centralizacion y/o distribucin de
la data.
• Definir sistemas centralizados y/o
distribuidos.
Ventajas y Desventajas de Sistemas
Centralizados
• Ventajas:
– Fácil manejo de
cambio
– Fácil aplicación de
estándares
– Fácil análisis de
sistema
– Fácil implementación
de seguridad.
• Desventajas:
– Difícil determinar
fallas o errores de
datos.
– Potencial impacto de
cambio
Ventajas y desventajas de sistemas
distribuidos
• Ventajas:
– Incrementas el mantener las aplicaciones con sus
últimos cambios al día. – Acceso a compartir
recursos.
– Mayor reproducibilidad de la data.
– Fácil de implementar aspectos locales de leyes sobre datos, aspectos regulatorio.
• Desventajas:
– Difícil de probar y manejar fallas.
– Difícil de incorporar mejoras y controlar cambios.
– Aspectos de seguridad mas complejos.
– Sincronización de tiempo. – Incompatibilidad de
infraestructura de redes y sistemas.
Administración
• Administrar ayuda de Infraestructura:
– Definir y considerar “Help Desk” local.
– Definir y considerar “Help Desk” global.
• Administrar planes de recuperación en casos de
desastres para la continuidad del negocio.
– El plan se debe de retar (hacer pruebas) una vez
terminado y aprobado.
– Capacitación sobre los que implementaran el plan
– Tomar en cuenta consideraciones globales y locales a la
hora de desarrollar el plan.
Ambiente
• El desarrollo, pruebas, y ambiente de producción y
su sincronización y relación es mas complejo
cuando se tiene disponible para sistemas globales.
Por esta razón consideramos lo siguiente:
– El nivel de programación de localidad especifica del
software.
– Manejar el ambiente de producción y sus similitudes.
– Coordinar y manejar el ambiente de prueba en el
ambiente de producción.
– Establecer procesos de control que ayudan a resolver
problemas potenciales de comunicación entre el
software global y el local en la interacción de los
mismos en momentos de pruebas en paralelos.
Plan de desempeño y capacidad
• Los requisitos de desempeño debe
establecer el tiempo de respuesta adecuado
del sistema global en la localidad donde se
efectúa el proceso. Esto se debe de retar
(probar).
• Definir, especificar cada aspecto de mejora
del sistema global su infraestructura sus
aplicaciones y como afecta al proceso local.
• Definir requisitos de licencias.
Validación y establecimiento
• Aspectos a tomar en consideración a la validación
e implementación de sistemas globales de
información;
– Propietario del sistema
– Plan de validación
– URS
– Manejo de riesgo
– SDS, revisión del diseño y manejo de rastreo
– Pruebas
Propietario del sistema
• Definir el dueño del Sistema
– Sistemas globales centralizados
– Sistemas locales
• Definir el grupo dueño del sistema
– Sistemas globales distribuidos
• Definir roles y responsabilidades en ambos
casos
• Responsables de mantener el sistema
validado, y en cumplimiento de ley.
Plan de validación
• Definir calendario de actividades
• Definir roles y responsabilidades
• Definir estrategias de validación basadas en categorías y
definiciones de sistemas o su complejidad.
• Revisar los aspectos de:
– Cultura
– Regulatorios locales
– Arquitectura de sistemas y bases de datos – Procedimientos
• Definir su administracion
– Local – Global