arrow_back_ios

Main Menu

arrow_back_ios

Main Menu

arrow_back_ios

Main Menu

arrow_back_ios

Main Menu

arrow_back_ios

Main Menu

arrow_back_ios

Main Menu

arrow_back_ios

Main Menu

Declaración: Prácticas de Validación y Control de Calidad del Software Estándar de ReliaSoft

 

ReliaSoft a menudo recibe preguntas/solicitudes de clientes/terceros sobre la validación del software (generalmente relacionadas con los requisitos de la FDA). Este documento se ha creado para abordar tales solicitudes.


 

Declaración General

Todos los productos de envoltura retráctil de ReliaSoft son rigurosamente probados y completamente validados antes de su lanzamiento comercial. Nuestro estricto proceso de validación, junto con nuestra extensa documentación sobre el uso del software y las matemáticas subyacentes, asegura (con una probabilidad muy alta) que todos los resultados proporcionados por las aplicaciones de ReliaSoft son válidos y correctos.

 

Los procedimientos de validación y aseguramiento de calidad (QA) de ReliaSoft fueron desarrollados independientemente de los requisitos de validación de la Administración de Alimentos y Medicamentos (FDA). Aunque creemos que las pruebas de validación de ReliaSoft son de una naturaleza mucho más amplia y mucho más intensivas que los requisitos de la FDA, es, por supuesto, responsabilidad de cada organización determinar si el uso del software de ReliaSoft cumplirá con cualquier directriz regulatoria a la que puedan estar sujetas. Esperamos que este documento proporcione la mayoría de la información sobre los procedimientos de ReliaSoft que se requerirá para que realices tu evaluación.

 

Validación Independiente del Usuario Final

Con todos los productos estándar de envoltura retráctil, ReliaSoft proporciona una extensa documentación en forma de guías del usuario, archivos de ayuda y libros de texto teóricos. El propósito de la documentación es presentar las metodologías utilizadas (ecuaciones y formulaciones), proporcionar ejemplos y familiarizar al usuario final con la teoría subyacente.

 

Un usuario final puede hacer lo siguiente:

 

  • Confirmar de manera independiente que la aplicación se comporta como se describe en estas guías.
  • Utilice los libros de texto proporcionados para realizar una validación independiente adicional de los resultados del software, ya sea utilizando las formulaciones dadas o utilizando los muchos ejemplos y soluciones proporcionados dentro de estos libros de texto (muchos de los cuales son de artículos publicados).

Además, se proporcionan comparaciones entre los resultados numéricos de ReliaSoft y los resultados publicados (por otros autores) con la documentación impresa.

 

Algunos de estos libros de texto están publicados en el wiki público de ReliaSoft. Específicamente, las siguientes referencias están disponibles:

 

Las siguientes secciones presentan una visión general de los requisitos para el desarrollo de software en ReliaSoft.

 


Formulación Teórica y Desarrollo de Teoría

Toda teoría y formulaciones creadas o implementadas por ReliaSoft deben ser teóricamente sólidas y correctas, aceptadas por académicos y expertos de la industria, y también deben ser validadas exhaustivamente antes de convertirse en parte de un producto de software estándar (SSP).

 

Las teorías y formulaciones que no son creadas por ReliaSoft deben cumplir con los siguientes estándares:

 

  • Deben haber sido publicadas en revistas académicas o libros de texto de renombre y deben haber tenido tiempo suficiente para la revisión por pares.
  • Deben haber sido re-derivadas y validadas por científicos de ReliaSoft para asegurar la corrección del trabajo original.
  • Todas las suposiciones realizadas durante la formulación deben ser escrutadas, bien documentadas y entendidas.
  • Deben ser revisadas y aprobadas por la junta de revisión teórica de ReliaSoft y por al menos un experto académico independiente en el tema.

Las teorías y formulaciones que son desarrolladas por un científico de ReliaSoft deben cumplir con los siguientes estándares:

 

  • Deben documentar todas las suposiciones realizadas durante la formulación.
  • Deben ser revisadas y aprobadas por la junta de revisión teórica de ReliaSoft y al menos dos expertos académicos independientes en el tema.
  • Si la publicación de la formulación no se considera una ventaja competitiva, entonces debe ser publicada en revistas académicas de renombre para revisión por pares. Si existe una ventaja competitiva, entonces debe ser publicada después del lanzamiento del producto, ya sea en revistas o en libros de texto de ReliaSoft.

Desarrollo de Código

Todos los productos y componentes de producto desarrollados por ReliaSoft deben adherirse a los estándares aceptados en la industria para el desarrollo de aplicaciones orientadas a objetos basadas en Windows, incluidos los estándares de la industria para interfaces gráficas de usuario (GUIs). Múltiples autores, incluidos Microsoft y publicaciones de Microsoft Press, ofrecen una amplia gama de artículos y libros que detallan las prácticas aceptadas. Además, dicho desarrollo de código debe adherirse a las pautas para el desarrollo de software según el documento interno de ReliaSoft "Prácticas y Procedimientos de Codificación para Software SSP", y a las prácticas, métodos y documentos actuales publicados en la sección de Desarrollo de la intranet de ReliaSoft.

Se siguen las pautas de Microsoft para el desarrollo de aplicaciones de Windows (como se detalla en varios documentos, como "Especificación de Aplicaciones para Microsoft® Windows® 2000"). Cualquier desviación de estas pautas debe ser aprobada por la junta de revisión técnica de ReliaSoft y las razones de la desviación deben ser documentadas.

Se realizan revisiones de diseño periódicas con miembros del equipo de desarrollo de código, redactores técnicos y aseguramiento de calidad. Además, se llevan a cabo juntas de revisión teórica y técnica.


Gestión del Código Fuente

Las pautas implementadas por ReliaSoft para la gestión de código fuente son las siguientes:

  • Todo el código fuente, incluidas las modificaciones al código, se rastrea y controla mediante el uso de software de control de código fuente de terceros.  Bajo ninguna circunstancia se puede introducir código no rastreado a través del control de código fuente en la aplicación.
  • Todas las compilaciones de productos están versionadas utilizando un esquema de numeración estándar Mayor.Menor.Revisión (por ejemplo, 3.1.2).
  • Todo el código compilado (componentes) utilizado en las aplicaciones de ReliaSoft se controla a través de los procesos de configuración y control de versiones de ReliaSoft. Todos los componentes son capaces (a través de un evento o propiedad) de identificar su versión y compilación a una aplicación anfitriona.

 

Visión General de Control de Calidad y Procedimientos de Ensayos

ReliaSoft siempre ha cumplido con los más altos estándares de calidad y fiabilidad para todos sus productos y servicios de software. Los procedimientos de aseguramiento de calidad (QA) y pruebas para todos los productos de ReliaSoft, incluido el software personalizado, se basan en un marco ágil escalado que se facilita utilizando CA Agile Central. El proceso ágil escalado implica esfuerzos de prueba detallados y exhaustivos por múltiples individuos y equipos a lo largo de iteraciones específicas en el tiempo; documentación exhaustiva de todos los problemas identificados durante cada iteración; y validación independiente de todos los métodos, teorías y resultados calculados.

Pruebas Unitarias

Estas pruebas incluyen pruebas de bajo nivel en los niveles de 'unidad' e 'integración'. Generalmente prueban bibliotecas, etc., y por lo tanto son realizadas por desarrolladores. Su propósito es asegurar que el software produzca los resultados correctos (por ejemplo, 2+2 = 4). Deben completarse antes de que se puedan concluir las Pruebas del Sistema. Esta prueba unitaria asegura que los componentes y modelos funcionen como se pretende y también garantiza robustez. Esta prueba es responsabilidad de los desarrolladores individuales e implica un proceso de prueba-análisis-arreglo (TAAF).

Pruebas de Integración

Las pruebas de integración implican que los evaluadores busquen errores dentro de las relaciones e interfaces entre un par de componentes o un grupo de componentes. (Un ejemplo es cómo Weibull++ está integrado con ALTA.) No se requieren pruebas de integración si la aplicación está compuesta por utilidades individuales que no comparten datos ni se invocan entre sí. Sin embargo, si el software utiliza API, comparte datos o pasa el control de un componente a otro, entonces las pruebas de integración se convierten en un método importante para verificar que los componentes están funcionando juntos correctamente. Las pruebas de integración requieren que el evaluador tenga un firme entendimiento de cómo se supone que los componentes deben trabajar juntos.

Pruebas del Sistema

Una vez que todos los módulos/componentes han sido probados, compilados y vinculados sin errores ni advertencias, se implementan pruebas más amplias en la aplicación o sistema completo. Se mantienen registros formales de las actividades de pruebas del sistema en nuestro sistema de Registro y Seguimiento de Errores - CA Agile Central. En general, cualquier problema encontrado se corrige a medida que se identifica y las pruebas se reanudan inmediatamente con la versión corregida para asegurar que la solución no haya creado problemas de regresión. Se pone especial énfasis en el componente o problema que se ha corregido. Esto se repite a lo largo de cada iteración de la fase de desarrollo.

Pruebas de Instalación y de Entorno

La última fase de las pruebas es la instalación y prueba de configuración. Esto se realiza internamente en múltiples sistemas de prueba, incluyendo la mayoría de las versiones de Windows® (por ejemplo, Windows 7 y 8.1, Windows 10). Cuando es apropiado, también se recaban opiniones de evaluadores externos. En el caso de software que alcanzará mercados extranjeros, también se realizan pruebas de sistemas operativos extranjeros (por ejemplo, Windows chino, Windows coreano).

Pruebas de Validación de Resultados

En paralelo con las pruebas de funcionalidad del software, múltiples ingenieros, científicos y estadísticos que trabajan de manera independiente realizan pruebas y validación de todos los resultados calculados. Los resultados validados están documentados a fondo y muchos de los ejemplos se ilustran en libros de texto que se publican con el software. Cualquier problema encontrado se corrige, se vuelve a probar y se revalida utilizando múltiples escenarios de datos.

Decisión de lanzamiento

Cuando ReliaSoft lanza un producto, ha sido probado exhaustivamente y ReliaSoft tiene una alta confianza en su calidad y fiabilidad. Después de que todos los problemas han sido resueltos y validados, se toma una decisión de lanzamiento. Esta decisión se basa en el número y la frecuencia de los problemas encontrados. Antes de que se pueda iniciar el lanzamiento del software, el Gerente de Lanzamiento debe asegurarse de que toda la documentación de pruebas haya sido aprobada (y se haya dado la aprobación para el lanzamiento) por el Gerente de Pruebas.

Comentarios Finales

En el caso de sistemas personalizados, esperamos que el cliente pruebe el producto para asegurar que el sistema funcione como se pretende en el entorno del cliente. Para los sistemas que incorporan una base de datos no ReliaSoft para soportar la funcionalidad y los cálculos, el cliente es responsable de tomar medidas para mantener la integridad de los datos almacenados en la base de datos. Una visión general de los procedimientos de prueba empleados por ReliaSoft se presenta en la siguiente tabla.


Tabla Resumen de Pruebas de Software (QA)

 

Fase de Pruebas Tipo de Pruebas Responsabilidad Detalles de las Pruebas

Fase de Desarrollo

Pruebas Unitarias

Pruebas de Integración

Desarrollo

Control de Calidad (QA)

Fase teórica

Realizar pruebas unitarias continuas durante el desarrollo. Esto implicará probar componentes individuales a medida que se desarrollen. En esta etapa, se probarán los componentes individuales para verificar la corrección de los cálculos, así como la interacción con otros componentes.

Fase de Pruebas General

Pruebas de Proceso

Pruebas de Integración

Sistema de Pruebas

Control de Calidad (QA)

Desarrollo

Fase teórica

Documentación

Validar los resultados del proceso para verificar su corrección. Rastrear la ocurrencia y resolución de todos los problemas anómalos. Probar el rendimiento de los componentes cuando estén completamente integrados.

Fase de Pruebas de Instalación

Pruebas de Instalación y de Entorno

Control de Calidad (QA)

Desarrollo

Probar el sistema interna/externamente en varios entornos de instalación. Para sistemas personalizados, trabaje con el cliente para probar el sistema en el lugar de implementación.

Fase de Validación de Cálculos

Validación de Cálculos

Fase teórica

Valide una muestra representativa de los cálculos del sistema realizando cálculos idénticos de forma independiente y comparando los resultados.

Fase de Lanzamiento

Pruebas Finales

Control de Calidad (QA)

Desarrollo

Fase teórica

Documentación

Pruebas de unidad, proceso, integración y funcionalidad, usabilidad y despliegue.

Las pruebas en cada fase son cíclicas utilizando un proceso de prueba-análisis-arreglo (TAAF). Todos los problemas después de la fase de desarrollo inicial se comunican, documentan y resuelven utilizando CA Agile Central.


Proceso de Seguimiento y Resolución de Problemas

CA Agile Central rastrea todos los problemas encontrados para cada producto desde la fase de desarrollo y a lo largo de su ciclo de vida. Este sistema integrado forma la base de nuestros procedimientos de aseguramiento de calidad. Todos los problemas se registran en CA Agile Central como incidentes y se rastrean desde su creación hasta su resolución. Cada defecto se registra para que el equipo correspondiente lo aborde. Los defectos pueden incluir sugerencias de clientes, empleados, errores encontrados durante las pruebas, etc. Una vez que el defecto ha sido abordado por el desarrollo, debe ser probado por el grupo de aseguramiento de calidad para asegurar que la solución empleada aborda correctamente el problema y no introduce ningún problema de regresión adicional. CA Agile Central facilita el trabajo en equipo entre desarrolladores, expertos teóricos, redactores técnicos, aseguramiento de calidad y gestión para crear una aplicación confiable y robusta.

La siguiente figura muestra una de las interfaces de reporte de defectos dentro de CA Agile Central.

Interfaz de Comunicación de Defectos dentro de CA Agile Central


Despliegue de Software

Una aplicación de software no se considera lista para su implementación hasta que el candidato de lanzamiento ha sido aceptado por el grupo de control de calidad de ReliaSoft. El grupo de control de calidad debe estar satisfecho con el estado actual de la aplicación basado en los resultados de las pruebas.

Una vez que un producto está listo para su implementación:

  • Se construye un máster para la duplicación posterior.
  • El sistema de control de versiones se actualiza para incluir la configuración final del producto y el código fuente para la construcción y luego se congela.
  • Se realizan copias de seguridad del código fuente, componentes de construcción y configuración de la máquina utilizados para la construcción de lanzamiento, y se documentan las versiones de los componentes (incluidos los componentes no de ReliaSoft). El almacenamiento y la ubicación de copias de seguridad redundantes se realizan de acuerdo con los Protocolos de Recuperación ante Desastres de ReliaSoft.
  • La máquina utilizada para la construcción se aísla y congela, y no puede ser utilizada para ningún propósito que no sea la construcción (revisiones) posterior de la misma versión de la aplicación.