Archivos de la categoría: Requerimientos de software

  1. Inicio  > 
  2. Archivo por categoría "Requerimientos de software"
7, Jul 2025
“Fase de proyecto” un marco teórico descrito en el “Anexo 11” para la validación de sistemas

En la industria regulada, la implementación de un sistema computarizado dentro de nuestra área de trabajo es una decisión que no se debe tomar a la ligera. Ante una decisión de gran importancia es indispensable conocer prerrequisitos y requisitos a cumplir para garantizar la correcta implementación y conclusión del proceso de calificación. El “Anexo 11” de la comisión europea (Eudralex) establece los requerimientos a tomar en cuenta en procesos de implementación, haciendo énfasis en la seguridad del paciente, la integridad de datos y la calidad del producto.

El avance tecnológico y el desarrollo de herramientas avanzadas por proveedores emergentes para el control de datos y registros, implica que la industria regulada tenga mayor control y certeza de la calidad de los servicios obtenidos.

El control y cumplimiento de proveedores a los requerimientos de validación establecidos por el cliente “In-House” y a guías relevantes como son el Anexo 11 ayuda a que la “Fase de proyecto” sea transparente y efectiva.

Fase de proyecto

Validación

Cuando se define la implementación de un sistema computarizado dentro del área de trabajo, es importante considerar que la migración de un sistema manual a uno digital no debe disminuir la calidad del proceso que va en marcha. Para esto es indispensable que los sistemas computarizados cuentan con documentos y reportes de soporte emitidos por el fabricante (desarrollador) que incluyan pasos relevantes del ciclo de vida. Dicha documentación debe incluir registros de riesgos, control de cambios, especificiaciones y reportes de validación que muestren los resultados de pruebas derivados de soportes, fallas, Bugs y actualizaciones, según aplique.

No olvidemos que el control documental establece un alto compromiso del desarrollador con la integridad de datos hacia los procesos del cliente que se verán potenciados por la implementación de un sistema electrónico y/o digital. Con este hecho, el desarrollador debe tener la disposición y la capacidad documental de poder justificar sus políticas, protocolos, criterios de aceptación, procedimientos y registros basándose en evaluaciones de riesgo, según apliquen.

En el caso de sistemas críticos se deberá disponer de una descripción actualizada del sistema, en la que se detallen las disposiciones físicas y lógicas de los flujos de datos y las interfaces con otros sistemas o procesos, los requisitos previos de hardware y software de y las medidas de seguridad considerando lo siguiente:

  • Las especificaciones de requisitos de usuario deben describir las funciones necesarias del sistema informatizado y basarse en una evaluación de riesgos documentada el cual demuestra el impacto de las prácticas correctas de fabricación. Los requisitos del usuario deben ser trazables a lo largo de todo el ciclo de vida.
  • El usuario debe tomar las medidas razonables para garantizar que el sistema se ha desarrollado de acuerdo con un sistema de gestión de la calidad lo que ayuda a que el proveedor sea evaluado adecuadamente.
  • Para la validación de sistemas informatizados a medida o personalizados debe existir un proceso que garantice la evaluación formal y la notificación de las medidas de calidad y rendimiento para todas las fases del ciclo de vida del sistema.
  • Deben demostrarse los métodos de prueba y los escenarios de prueba adecuados. En particular, deberán tenerse en cuenta los límites de los parámetros del sistema (proceso), los límites de los datos y la gestión de errores (Las herramientas de prueba automatizadas y los entornos de prueba deben contar con evaluaciones documentadas de su idoneidad).
  • Si los datos se transfieren a otro formato o sistema de datos, la validación deberá incluir comprobaciones de que los datos no sufren alteraciones en su valor y/o significado durante este proceso de migración.

Después de abordar los requerimientos generales descritos en el Anexo 11 para fases de proyecto logramos conocer la importancia de los factores externos e internos y como estos nos brindan soporte al momento de implementar un sistema computarizado.

Recuera que, Deappharma, es un proveedor de soluciones informáticas en cumplimiento con la normatividad local NOM-059 BPF e internacional. Te invitamos a conocer nuestras soluciones, las cuales cumplen con los requerimientos CFR21 y Anexo 11 de la comisión europea. Nuestras soluciones satisfacen las regulaciones más exigentes de nuestro sector farmacéutico. Conoce como transformamos el control de Libros de Excel con eDocuSeed y la gestión de datos analíticos con eADMxL.

No olvides recomendar y compartir nuestras publicaciones para que nuestra comunidad farmacéutica siga creciendo.

27, Feb 2025
Diferencias entre acceso controlado y firma electrónica en software

Comprendiendo dos conceptos esenciales en la seguridad y autenticidad del software

En el mundo del software, especialmente en el ámbito de la seguridad y la autenticación, los términos «acceso controlado» y «firma electrónica» son fundamentales, pero se refieren a conceptos distintos. A continuación, explicamos en detalle la diferencia entre ambos.

Acceso controlado

El acceso controlado es un mecanismo que regula quién o qué puede ver o usar recursos en un entorno de computación. A través de diferentes métodos, se asegura que solo las personas autorizadas puedan acceder a información o sistemas específicos. Los métodos más comunes de acceso controlado incluyen:

  • Contraseñas: Un método básico de autenticación que requiere que los usuarios introduzcan una clave secreta para acceder al sistema.
  • Sistemas de autenticación de dos factores: Añaden una capa extra de seguridad al requerir una segunda forma de identificación además de la contraseña, como un código enviado a un dispositivo móvil.
  • Biometría: Utiliza características físicas o conductuales, como huellas dactilares o reconocimiento facial, para verificar la identidad del usuario.
  • Listas de control de acceso: Definen los permisos que los usuarios tienen sobre ciertos recursos o datos dentro del sistema.

El acceso controlado es vital para proteger información sensible, prevenir accesos no autorizados y garantizar que los datos solo sean utilizados por aquellos con los permisos adecuados.

Firma electrónica

La firma electrónica es un método utilizado para autenticar la identidad del firmante de un documento digital y para garantizar que el contenido del documento no haya sido alterado desde que fue firmado. Existen varios tipos de firma electrónica, cada una con diferentes niveles de seguridad y verificabilidad:

  • Firma electrónica simple: Incluye cualquier tipo de firma digitalizada, como una imagen de una firma manuscrita. Aunque es fácil de usar, ofrece poca seguridad.
  • Firma electrónica avanzada: Está vinculada de manera única al firmante, se crea utilizando medios que el firmante puede mantener bajo su control exclusivo y es capaz de identificar al firmante de manera fiable. Además, cualquier cambio en los datos firmados es detectable.
  • Firma electrónica cualificada: Es una firma electrónica avanzada que se crea mediante un dispositivo cualificado de creación de firmas y que se basa en un certificado cualificado de firma electrónica. Proporciona el nivel más alto de seguridad y tiene el mismo valor legal que una firma manuscrita en muchos países.

Las firmas electrónicas son esenciales para la legalidad y la integridad de los documentos digitales, ofreciendo una manera de verificar la autenticidad e integridad de estos.

Comparación

Aunque tanto el acceso controlado como la firma electrónica tienen que ver con la seguridad y autenticación, se aplican en contextos diferentes y sirven propósitos distintos:

  • Propósito: El acceso controlado regula quién puede acceder a qué recursos en un sistema, mientras que la firma electrónica autentica la identidad del firmante y asegura la integridad de un documento.
  • Método: El acceso controlado puede involucrar contraseñas, autenticación de dos factores, biometría, etc. La firma electrónica utiliza certificados digitales, encriptación HASH y/o dispositivos de creación de firmas.
  • Aplicación: El acceso controlado es utilizado en sistemas y bases de datos para proteger información sensible. La firma electrónica se utiliza en documentos digitales para garantizar su autenticidad y legalidad.

En resumen, ambos conceptos son cruciales para la seguridad de la información en el entorno digital, pero se aplican de manera diferente y tienen objetivos distintos.

En Deappharma hemos desarrollado los aplicativos eDocuSeed y eADMxL, diseñados para elevar la integridad de datos en: documentos, hojas de cálculo de Excel y datos analíticos. Nuestras soluciones, establecen controles avanzados de acceso y firma electrónica. De esta manera, contribuyen sustancialmente a elevar la integridad de datos.

Te invitamos a que te comuniques con nosotros en contacto para que puedas conocer todos los beneficios de nuestras soluciones.

Igualmente, te invitamos a que leas nuestros artículos en nuestro Blog, sobre:

30, Sep 2024
Entregables documentales para la calificación de sistemas computarizados.

La calificación de un sistema computarizado es un proceso documental que requiere enfoque, orden y consistencia lógica para llevar a buen puerto el proceso deseado. En ocasiones pensamos que los entregables documentales para validación de sistemas computarizados difieren según sea el caso de sistemas a validar. Lo más factible es que los procesos de validación sean estructurados y sistemáticos. De esta manera podremos establecer procesos o procedimientos replicables para estas actividades. ¿Pero que entregables documentales son los que se deben generan y mostrar ante una inspección regulatoria?

En este articulo te compartimos los documentos y su alcance dentro del proceso de calificación de sistemas computarizados para los sectores farmacéutico, almacenes y de dispositivos médicos.

El siguiente proceso lógico documental te servirá para procesos y proyectos de calificación de sistemas computarizados, tales cuales son: ERP, SAP, software personalizado, Software comercial, CRM, Plataformas Web y Hojas de cálculo.

ACUERDO DE NIVEL DE SERVICIO (SLA)

Un acuerdo de nivel de servicio es un documento de base legal y calidad. En este documento se establecen los alcances del proyecto. Así como, los entregables documentales, tiempo y responsabilidades entre el cliente-proveedor. Es importante, que este documento considere mencionar y acordar la estructuración de los procesos de actualización y la obtención de documentos de soporte como controles de cambio hacia el cliente para favorecer el mantenimiento del estado validado del servicio obtenido.

ANÁLISIS DE RIESGO

Un análisis de riesgo es un documento que establece como base la detección de eventos que pudiesen suceder durante el proceso de validación. Es decir, este documento establece eventos críticos y/o relevantes del sistema que deben ser cumplidos por el sistema. Y según aplique, el detalle de acciones a considerar si el sistema “per-se” manifiesta la falta de requerimientos normativos y de cumplimiento en integridad de datos. Se recomienda, que en este documento también se incluya la categorización del software a calificar-validar. Conoce acerca de las categorías de software aquí>>https://deappharma.com/gamp-5-y-la-categorizacion-de-software/

PLAN DE VALIDACIÓN

El plan de validación es un documento que establece como su nombre lo indica un plan de validación. Este plan establece de manera detallada las siguientes tareas:

  • Definir la estrategia de la calificación-validación que se aplicara.
  • Determinar los entregables que se generaran en cada actividad.
  • Identificar el equipo de calificación-validación y pruebas junto con su responsabilidad para la finalización de cada actividad.
  • Definir el procedimiento para las pruebas de calificación-validación.

ESPECIFICACIONES

Las especificaciones son la base documental para la estructuración de pruebas y evidencias. Dentro del proceso de calificación deben existir tres principales actores:

  • Especificación de requerimientos de usuario de software: este documento establece y define de manera puntual cada requerimiento de usuario solicitado y cada requerimiento regulatorio que deberá ser evaluado con la determinación de su entregable. Este documento del sistema detalla: ambiente, propósito y manejo de datos, funciones de entrada, función de proceso, funciones de salida, funcione generales, características de usuarios, restricciones, suposiciones dependencias, requerimientos futuros, requerimientos de rendimiento requerimientos específicos, copias de seguridad, archivo y restauración y requisitos de conservación.
  • Especificación de diseño: este documento establecer y define de manera puntual los detalles de infraestructura y técnicos que se requieren para que el sistema funcione y se instale correctamente. Este documento detalla: plataforma y entorno, interfaces, ajuste de configuración, nombre, versión, modelo, código, recuperación y requisitos.
  • Especificación funcional: este documento establece y muestra barra de funciones, así como el alcance de cada una de ellas en un entorno productivo.

PROTOCOLOS DE CALIFICACIÓN

El protocolo de calificación es un documento que establece las instrucciones para llevar a cabo cada etapa del proceso. Este documento está estrechamente vinculado a las especificaciones y su entregables. Este documento puede ser uno solo o, segmentado a cuatro protocolos de calificación. Es importante mencionar, que, aunque la normativa no define que necesariamente deben ser protocolos. Se debe tener en cuenta que no se puede avanzar de etapa de calificación hasta haber concluido la previa en la cual no se determinen eventos críticos que detenga en proceso.  De cualquier forma, el o los protocolos deben mostrar las instrucciones de verificación del diseño, instalación, operación y desempeño del sistema a dictaminar.

  • Protocolo de diseño: es el documento que establece las instrucciones de trabajo con base en las especificaciones de diseño previamente autorizadas.
  • Protocolo de instalación: es el documento que establece las instrucciones con base en la documentación del sistema y el sistema de gestión de la calidad del negocio. Así como, consideraciones del fabricante para llevar a cabo la instalación. Importante mencionar que esta etapa de instalación debe incluir como parte de su evaluación las operaciones de configuración del sistema.
  • Protocolo de operación: es el documento que establece las instrucciones. Con base base, en la especificación de requerimientos de usuario de software. Esta etapa, define la evaluación de operaciones de entrada y proceso del sistema.
  • Protocolo de desempeño: es el documento que establece las instrucciones de pruebas que se establecen con base en las especificaciones de funcionalidad sobre un proceso real de trabajo. Esta etapa define pruebas de transacciones generales estructuradas bajo eventos reales de trabajo.

REPORTE DE CALIFICACIÓN

El reporte de calificación es un documento que establece los resultados finales cada etapa del proceso. Este documento está estrechamente vinculado al o los protocolos de calificación. Este documento puede ser uno solo o, segmentado a cuatro reportes de calificación. Es importante mencionar, que, aunque la normativa no define que necesariamente deben ser reportes. Se debe tener en cuenta que no se puede avanzar de etapa de calificación hasta haber concluido el reporte previo en la cual no se hallan determinado eventos críticos que detenga en proceso.  De cualquier forma, el o los reportes deben mostrar los resultados, hallazgos y acciones determinada en cada etapa que ha sido verificada par el: diseño, instalación, operación y desempeño.

MATRIZ DE TRAZABILIDAD

La matriz de trazabilidad es un documento en formato de tabla preferentemente que relaciona uno de los requerimientos con los entregables que se hayan solicitado. Este cuadro es de doble sentido ya que permite identificar que se resultado se alcanza a través de cada requisito y a la vez, que requisitos son los que permite obtener un entregable como resultado reportable.

CONCLUSIÓN

Un proceso de calificación ordenado, conciso y detallado tiene como principal beneficio el cumplimiento regulatorio.

Te invitamos a recibir nuestro apoyo en proyectos de calificación de sistemas computarizados. Nuestra esencia como empresa en el desarrollo de software y nuestro enfoque en el sector regulado te brinda el ¿Qué? y ¿Cómo? llevar a buen puerto tu proyecto.

¡Recuerda!  que en deappharma tienes un aliado para realizar la validación de sistemas computarizados. ¡Con nuestro método obtendrás el cumplimiento requerido!

Nuestro servicio te da acceso a un beneficio totalmente gratis por un año. Este beneficio consiste en implementar eDocuSeed  un software que centraliza todos tus libros de Excel y documentos en un solo punto. De esta manera les brindamos los atributos de integridad de datos, trazabilidad y mantenimiento necesarios para dar cumplimiento a las regulaciones más exigentes. Nuestra solución ya impacta de manera positiva a empresas del sector farmacéutico en México y Sudamérica. Solicita tu demostración totalmente gratuita. ¡Estamos listos para ayudarte!

Contáctanos y solicita una demostración y asesoría gratuita ¡Quiero un asesoría y demostración!

¡Gracias por leernos!

26, Abr 2024
Revisión del diseño y trazabilidad en sistemas computarizados

Revisión de diseño

La revisión del diseño evalúa los entregables a través de requerimientos estándar, identificando eventos, y proponer las medidas correctivas necesarias. Esta revisión es sistemática y planeada, de tal manera que pueda ser desarrollada en todos los puntos del ciclo de vida del sistema. Esto es una de las partes importantes de la verificación del proceso.

La revisión del diseño deberá ser realizada por un equipo de especialistas apropiado. La revisión de desempeño individual deberá estar identificada. En algunos casos el uso de herramientas podría simplificar aspectos para la revisión de diseño; por ejemplo, análisis de código y herramientas de trazabilidad pueden proporcionar un enfoque eficiente de confianza.

El rigor de la revisión del proceso de diseño y la extensión de la documentación deben estar basadas en el riesgo, complejidad y novedad del sistema a evaluar.

Aspectos que deben ser considerados cuando se planea una revisión de diseño incluyen:

  • El alcance y objetivo de la revisión.
  • Que método y/o proceso deberá ser seguido.
  • Quienes estarán involucrados, con roles y responsabilidades específicas.
  • Cuáles serán los resultados.

Para productos estándar (GAMP categoría 3) la revisión de diseño en compañías reguladas típicamente no es requerida. Sin embargo, esto debe estar descrito en el riesgo definido.

Para sistemas basados en configuraciones de producto, gran parte de la revisión de diseño deberá ser realizada por el proveedor durante el desarrollo del producto. Esto deberá ser una parte de evaluación del proveedor. Las actividades de revisión de diseño deberán estar enfocadas en la configuración y las actividades de implementación.

Par aplicaciones personalizadas, las revisiones de diseño típicamente son conducidas a cada nivel del detalle de la especificación de diseño y alcance del producto.

Trazabilidad (Matriz de trazabilidad)

La trazabilidad establece relaciones entre dos o más productos en el proceso de desarrollo.

La trazabilidad asegura que:

  • Los requerimientos han sido realizados y estos pueden ser trazados como parte de los elementos de diseño.
  • Los requerimientos han sido verificados y que estos pueden ser trazados por medio de las actividades de prueba y verificación descritas en los requerimientos.

La exactitud en la trazabilidad puede proveer beneficios como:

  • Permitir una mayor eficacia en la administración de riesgos.
  • Juzgar impactos potenciales a cambios propuestos.
  • Facilitación para la estructuración del análisis de riesgos por cambios propuestos.
  • Identificar alcance de evaluación de cambios.
  • Permitir mayor exactitud y rapidez durante una inspección de auditoría.

¡Recuerda!  que en deappharma tienes un aliado para realizar la validación de sistemas computarizados. ¡Con nuestro método obtendrás el cumplimiento requerido!

Con nuestro servicio obtendrás un beneficio totalmente gratis por un año. Este beneficio consiste en implementar eDocuSeed un software que centraliza todos tus libros de Excel en un solo punto. Para brindarles los atributos de integridad de datos, trazabilidad y mantenimiento necesarios para dar cumplimiento a las regulaciones más exigentes. Nuestra solución ya impacta de manera positiva a empresas del sector farmacéutico, dispositivos médicos y distribuidoras de medicamentos. Solicita tu demostración totalmente gratuita. ¡Estamos listos para ayudarte!

Contáctanos y solicita una demostración y asesoría gratuita ¡Quiero un asesoría y demostración!

¡Gracias por leernos!

12, Abr 2023
Definiendo los requerimientos de usuario

Una clave muy importante para la validación del software y libros de Excel es una especificación documentada de los requisitos que defina:

– el «uso previsto» del software, libro de Excel o equipo automatizado; y

– la medida en que el fabricante del producto depende de ese software, libro de Excel o equipo para la producción de un producto sanitario de calidad.

El fabricante del producto (usuario) tiene que definir el entorno operativo previsto, incluyendo cualquier configuración de hardware y software necesarias, versiones de software, utilidades, etc. El usuario también debe:

– documentar los requisitos de rendimiento del sistema, calidad, gestión de errores, puesta en marcha, apagado, seguridad, etc;

– identificar cualquier función o característica relacionada con la seguridad, como sensores, alarmas, enclavamientos, pasos lógicos de procesamiento o secuencias de comandos; y

– definir criterios objetivos para determinar el rendimiento aceptable.

La validación debe realizarse de acuerdo con un protocolo documentado, y los resultados de la validación también deben documentarse. Deben documentarse los casos de prueba que pongan a prueba el rendimiento del sistema con respecto a los criterios predeterminados, especialmente para sus parámetros más críticos.

Los casos de prueba deben abordar las condiciones de error y alarma, el arranque, el apagado, todas las funciones de usuario y controles de operador aplicables, posibles errores de operador de valores permitidos y las condiciones de estrés aplicables al uso previsto del equipo. Los casos de prueba deben ejecutarse y los resultados deben registrarse y evaluarse para determinar si los resultados permiten concluir que el programa informático está validado para el uso previsto.

Un fabricante de productos puede llevar a cabo una validación utilizando su propio personal o puede depender de un tercero, como el fabricante del equipo/software tercero, o un consultor. En cualquier caso, el fabricante del producto conserva la responsabilidad última de garantizar que el software del sistema de producción y calidad:

– se valide de acuerdo con un procedimiento escrito para el uso concreto previsto; y

– funcionará según lo previsto en la aplicación elegida.

El fabricante del producto debe disponer de documentación que incluya

– los requisitos de usuario definidos

– el protocolo de validación utilizado

– los criterios de aceptación

– casos de prueba y resultados; y

– un resumen de validación que confirme objetivamente que el software y/o Libros de Excel está validado para el uso previsto.

¿Existen herramientas en el mercado que mejoren los procesos administrativos y de laboratorio?

Como bien sabemos el desafío más grande al que se a puesto a prueba el sector farmacéutico es el relacionado con la integridad de datos. ¡Pero! ¿Por qué es tan complejo este tema? La respuesta se deriva por la gran cantidad de datos y documentos que se emiten día con día en el que se ven impactados documentos y libros de Excel. 

Recordemos que la validación de software y libros de Excel es el primer paso. No obstante, muchos libros de Excel utilizados en el sector farmacéutico no cuentan con evidencia de validación lo cual es un riesgo que podrá derivar en un hallazgo critico ante una inspección regulatoria.

El segundo paso y el más complejo es adherir las configuraciones necesarias que eleven la integridad de datos y favorezcan el mantenimiento tanto de software como de Libros de Excel.

Te invitamos a mitigar el riesgo por el uso de sistemas computarizados no validados y con pobres atributos de integridad de datos. Nuestros desarrollos están estructurados bajo un sistema de gestión de calidad trazable y auditable. Tales cuales cuentan con el soporte de validación-calificación documental con base en Gamp 5 y CFR21 parte 11.

Conoce eADMxL el cual es un software que desarrollamos para mitigar el uso de hojas de cálculo para procesos de validación de métodos analíticos. Conoce sus beneficios y alcance general aquí:  ¡Da clic aquí!

eDocuSeed es más que un software de gestión documental ya que este es capaz de controlar y mantener libros de Excel por medio de adición de controles necesarios para: acceso, edición, trazabilidad y su mantenimiento. Conoce sus beneficios y alcance general aquí: ¡Da clic aquí!

“No vivas con el riesgo ¡Mitígalo!” para eso nosotros de ayudamos.

Visita nuestro sitio www.deappharma.com y solicita una demostración y asesoría gratuita.

¡Contáctanos! y conoce de que manera te vamos a ayudar.

¡Únete a nuestra comunidad en redes!

5, Sep 2022
¿Qué debo saber para abordar la Validación de hojas de cálculo?

Las hojas de cálculo también llamadas planillas, templetes, plantillas de cálculo, son herramientas rutinariamente utilizadas para realizar actividades GxP de carácter normativo. Es por esto que el control y el uso de estas debe ser regulado  derivado de que pueden tener impacto sobre la exactitud, fiabilidad, integridad, disponibilidad, autenticidad de los registros y firmas requeridas, según aplique.

Para poder comprender la criticidad e importancia de la emisión de datos con estas herramientas, podríamos partir respondiendo a las siguientes preguntas; ¿Cuál es el objetivo de validar una hoja de cálculo? ¿Qué hace tan viable el uso de las hojas de cálculo como una herramienta en entornos GxP? ¿Qué debo saber antes de comenzar una validación de hoja de cálculo? ¿Cómo definir el alcance de validación de una hoja de cálculo? O más aún ¿Podría auto inspeccionar mi hoja de cálculo? Las respuestas a las preguntas antes mencionadas nos brindan un panorama general de conocimiento.

¿Cuál es el objetivo de validar una hoja de cálculo?

El objetivo de validación de una hoja de cálculo nos encanta definirlo de la siguiente manera: “Buscar la verdad de algo”. Para lo cual debemos revisar, auditar y documentar que una hoja de cálculo emite resultados fidedignos respecto a la especificación de requisitos establecida.

¿Qué hace tan viable el uso de las hojas de cálculo como una herramienta en entornos GxP?

En entornos Gxp se genera una gran cantidad de data que va desde lo simple, lo que podemos denominar texto o escritura hasta data compleja, tendencias, inferencias, decisiones etc. es aquí donde las hojas de cálculo adquieren relevancia ya que estas otorgan al usuario versatilidad, dinamismo y poder de personalización que va desde la vinculación de celdas configurables, hasta la creación de código VBA o MACROS personalizados.

¿Qué debo saber antes de comenzar una validación de hoja de cálculo?

Antes de comenzar una validación de hoja de cálculo es necesario evaluar de manera documentada la hoja de cálculo, es decir definir el riesgo y la expectativa de validación. Una excelente manera para definir es aquella que se relaciona a la complejidad. En función de la complejidad de la hoja de cálculo los resultados requeridos son escalables. Aquí un ejemplo para definir complejidad dentro de este rubro:

  • Simple: la hoja de cálculo se considera simple cuando utiliza funciones estándar de Excel. Se pueden utilizar cálculos y otras funciones de Excel (formulas) sencillas siempre que los requisitos estén documentados con suficiente detalle para permitir la realización de pruebas GxP. Si un cálculo o una fórmula no se expresa o no puede expresarse suficientemente en los requisitos, la hoja de cálculo debe considerarse compleja y debe generarse una especificación de diseño.
  • Compleja: la hoja de cálculo se considera compleja cuando utiliza funciones no estándar de Excel, como objetos personalizados, macros o Visual Basic. Una hoja también se considera compleja si un cálculo o una fórmula utilizada no se expresa o no pueden expresarse suficientemente en los requisitos indicados anteriormente. Si la hoja de cálculo contiene una amplia codificación personalizada, no debe validarse siguiendo estándares de validación de hojas de cálculo. Es grado de personalización deberá trabajarse como una validación de software utilizado criterios y parámetros de validación diferentes.

¿Cómo definir el alcance de validación de una hoja de cálculo?

El alcance de validación se define con base en la complejidad. Y con base en esta complejidad se define el entregable, un alcance típico es el siguiente:

¿Podría auto inspeccionar mi hoja de cálculo?

La regulación no establece limitantes para que puedas ser tu mismo quien valide tu hoja de cálculo. Sin embargo, se sugiere que la validación sea llevada por un ente ajeno a tu proceso. De esta manera la validación y auditoria de la hoja de cálculo podrá ser realizada de manera objetiva.

Expertos en Validación de Hojas de Cálculo de Microsoft Excel

No olvides que en caso de ser necesario, puedes contactarnos para mejorar el proceso de laboratorio y/o administrativo de tu organización a través software 100% confiable y seguro.

Recuerda que en deappharma contamos  con un software que te ayudara a administrar y controlar tu proceso de libros y hojas de Excel. Somos expertos en la materia, por lo que procesos complejos no representa un reto para nosotros, debido a que tenemos en mente los aspectos relevantes de cumplimiento.

Te invitamos a adquirir nuestro servicio de  validación, auditoria o diseño de hojas de cálculo y no te pierdas del beneficio extra que tenemos para ti.  Conoce este beneficio ¡da clic aquí!

Contáctanos en: info@deappharma.com

¡Únete a nuestra comunidad en redes!

2, May 2022
Características de un buen SRS (Software Requirements Specification) especificación de requerimientos de software

La especificación de requisitos de software (SRS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.

Las características de un buen SRS son:

  • Sin ambigüedades
  • Completa
  • Verificable
  • Coherente
  • Modificable
  • Trazable
  • Utilizable durante la fase explotación y mantenimiento

Cada característica se aborda con mayor detalle a continuación:

Sin ambigüedad. Una SRS es inequívoca si- y solo si- cada requisito en ella tiene una única interpretación.

  • Como mínimo, esto requiere que cada característica del producto final se describa utilizando un único termino.
  • En los casos en los que un término utilizado en un contexto particular pueda tener múltiples significados, el termino debe incluirse en un glosario donde se especifique su significado.

Completa. Un SRS es completo si posee las siguientes cualidades:

  • Inclusión de todos los requisitos significativo, ya sean relativos a la funcionalidad, el rendimiento, las limitaciones de diseño, los atributos o las interrelaciones externas.
  • Definición de las respuestas de software a todas las clases realizables de datos de entrada en todas las clases realizables de situaciones. Obsérvese que es importante especificar la respuesta a los valores de entrada válidos y no validados.
  • Conformidad con cualquier norma del SRS que le sea aplicable. Si una sección particular de la norma no es aplicable, el SRS debe incluir el número de sección y una explicación de porque no es aplicable.

Verificable. Un SRS es verificable si, y solo si, todos los requisitos establecidos en el son verificables. Un requisito es verificable si y solo si existe algún proceso finito y rentable con el que una persona o máquina pueda comprobar que el producto de software cumple con el requisito.

  • Ejemplos de requisitos no verificables, estas son declaraciones como: a)El producto debe funcionar bien, o el producto debe tener una buena interfaz humana. Estos requisitos no pueden verificarse porque es imposible definir los términos bueno o bien. b)El programa nunca debe entrar en un bucle infinito. Este requisito no es verificable porque la comprobación de esta cualidad es teóricamente imposible.

Coherente. Un buen SRS es consistente si y solo si ningún conjunto de requisitos individuales descritos en ella entra en conflicto. Hay tres tipos de conflictos principales en un SRS:

  • Dos o más requisitos pueden describir el mismo objeto del mundo real, pero utilizar termino diferentes para ese objeto. Por ejemplo, la solicitud de una entrada de usuarios por parte de un programa puede denominarse “prompt” en un requisito y “cue” en otro.
  • Las características especificadas de los objetos del mundo real pueden entrar en conflicto. Por ejemplo: 1)El formato de un informe de salida puede describirse en un requisito como «tabular” pero en otro como “textual” 2) Un requisito puede establecer que todas las luces deben ser verdes mientras que otro establece que todas las luces deben ser azules. 3) Puede haber un conflicto lógico o temporal entre dos acciones específicas. Por ejemplo; a) Un requisito podría especificar que el programa sumará dos entradas y otro especificar que el programa las multiplicará. b) Un requisito puede establecer que A debe seguir a B, mientras que otros requieren que A y B ocurran simultáneamente.

Modificable. Un SRS es modificable si su estructura y estilo son tales que cualquier cambio necesario en el requisito puede realizarse de forma fácil, completa y coherente. Los cambios en un SRS generalmente requieren:

  • Tener una organización coherente y fácil de usar, con un índice y referencias cruzada explicitas.
  • No ser redundante; es decir, el mismo requisito no debe aparecer en otras partes en el SRS.

Trazable. Una SRS es trazable si el origen de cada uno de sus requisitos es claro y se facilita la referencia de cada requisito de la futura documentación de desarrollo o mejora. Se recomiendan dos tipos de trazabilidad:

  • La trazabilidad hacia atrás (es decir, hacia etapas anteriores de desarrollo) depende de que cada requisito haga referencia explícita a su fuente en documentos anteriores.
  • La trazabilidad hacia adelante (es decir, hacia todos los documentos generados por el SRS) depende que cada requisito del SRS tenga un nombre o número de referencia único.

Utilizable durante la fase de operación y mantenimiento. El SRS debe atender las necesidades de la fase de operación y mantenimiento, incluyendo la eventual sustitución del software.

  • El mantenimiento suele ser realizado por personal no relacionado con el desarrollo original. Los cambios locales (correcciones) pueden aplicarse mediante un código. Si embargo, para los cambios de mayor alcance, la documentación sobre el diseño y los requisitos es esencial. Esto implica dos acciones:
  • El SRS debe ser modificable
  • El SRS debe contener un registro de todas las disposiciones especiales que aplican a los componentes individuales, tales como:
  • Su criticidad
  • Su relación con las necesidades sólo temporales.
  • Su origen
  • Este tipo de conocimiento se da por sentado en la organización de desarrollo, pero a menudo falta en la organización de mantenimiento. Si no se entiende la razón o el origen de una función, a menudo es imposible realizar un mantenimiento adecuado del software.

No olvides que todas nuestras soluciones son liberadas bajo un sistema de calidad robusto. En caso de ser necesario, puedes contactarnos para mejorar el proceso de laboratorio y administrativo de tu organización a través software 100% confiable y seguro. Recuerda que en deappharma contamos  con una suite de herramientas que te ayudaran a mejorar tus procesos con un enfoque en integridad de datos. Somos expertos en la materia, por lo que procesos complejos no representa un reto para nosotros, debido a que tenemos en mente los aspectos relevantes de cumplimiento.

Referencias

  • FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

  • GAMP 5 Guide: Compliant GxP Computerized Systems

  • Guía del IEEE sobre especificaciones de requisitos de software ANSI/IEEE std 1984.

¡Contáctanos! y conoce de que manera te vamos a ayudar.

¡Únete a nuestra comunidad en redes!