Verificación y validación con TestStand

Antes de analizar las prácticas recomendadas para la verificación y validación, conviene comprender primero la diferencia entre estos conceptos y cómo se aplican a un sistema de pruebas.

Validación

Al desarrollar cualquier sistema de pruebas, el primer paso es comprender y documentar los requisitos de la prueba. Para definir estos requisitos, se parte de las especificaciones de la unidad bajo prueba (UUT) y se desarrollan los requisitos de prueba para garantizar que se detecten las deficiencias en la UUT. En este punto del desarrollo, es fundamental asegurarse de que los requisitos definan completamente todas las condiciones de falla del UUT. El proceso de garantizar que el sistema de pruebas cumpla con la intención original se conoce como validación.

La validación es el proceso de evaluar si un sistema cumple realmente su propósito o intención.

La validación debe llevarse a cabo durante todo el proceso de desarrollo de la prueba, pero debe comenzar en la fase de recopilación de requisitos, ya que las posibles deficiencias son mucho más fáciles de abordar al principio del ciclo de vida del proyecto. La validación puede incluir un procedimiento de prueba formal de aprobación o no aprobación, o puede ser una forma subjetiva de estudiar la usabilidad con clientes, usuarios o pacientes. La validación a menudo implica algunos requisitos subjetivos, como “rechaza productos defectuosos” o “tiene una interfaz fácil de usar”. Siempre que sea posible, debe definir requisitos de nivel inferior más detallados para respaldar estas declaraciones subjetivas, a fin de garantizar que todas las partes involucradas estén de acuerdo con lo que se desea obtener.

Verificación

Una vez que se desarrollan los requisitos de pruebas detallados, los desarrolladores de pruebas pueden diseñar e implementar un sistema de pruebas que cubra los requisitos. Al terminar, los ingenieros deben asegurarse de que el sistema de pruebas cubra todos los requisitos definidos. El proceso de garantizar que el sistema de pruebas aborde correctamente los requisitos especificados se conoce como verificación.

La verificación es el proceso de determinar si un sistema de pruebas se ha elaborado según las especificaciones de un diseño, dibujo, declaración de trabajo u otra directriz similar.

Las pruebas de verificación deben realizarse en varios puntos del desarrollo de un producto. La verificación se puede realizar en todo el sistema como un todo o en componentes más pequeños del sistema de pruebas.

Para ilustrar la diferencia entre verificación y validación, supongamos que un departamento de pruebas construye un dispositivo de prueba simple para medir el consumo de corriente eléctrica de una unidad bajo prueba (UUT). El sistema de pruebas debe comparar la medición de corriente para los pines de alimentación de la UUT con los límites de prueba que requieren que la UUT consuma menos de 500 mA. Para abordar esto, los desarrolladores de pruebas definen el requisito de que “la corriente UUT no debe exceder los 500 mA a máxima potencia”. A continuación, los desarrolladores diseñan e implementan un dispositivo de prueba con el hardware requerido para tomar esta medida y crean un caso de prueba para verificar la corriente de la UUT después de suministrar toda la potencia.

Para realizar la verificación del sistema de pruebas, los desarrolladores verifican que el sistema lleva a cabo la medición correctamente con una repetibilidad aceptable y produce una falla si la potencia excede los 500 mA. Si el comportamiento del sistema de pruebas coincide con los requisitos, la verificación es satisfactoria.

Sin embargo, existe un modo de falla en la fabricación: un diodo instalado en dirección inversa puede hacer que algunas partes del circuito no se activen, lo que lleva a un consumo de corriente excesivamente bajo de 150 mA. Los sistemas de pruebas no informan de este problema como una falla, ya que solo se prueba un valor límite máximo y se pueden enviar unidades con fallas. Aunque el sistema de pruebas se haya construido correctamente de acuerdo con las especificaciones, el sistema no cumple el propósito que se le encomendó cumplir y, por lo tanto, falla la validación. La especificación y el sistema de pruebas deben modificarse para incorporar un límite de medición superior e inferior, como 400-500 mA.

La verificación del sistema puede ser relativamente fácil en función de una especificación bien escrita, un dibujo o una declaración de trabajo, y los métodos de prueba pueden ser muy sencillos para que los defectos sean fáciles de encontrar, pero la validación puede ser más difícil, como se muestra en el ejemplo anterior.

Análisis de impacto

Una vez que se haya completado la validación y verificación de un sistema de pruebas y se haya puesto en uso, es probable que deba realizar cambios o actualizaciones en el sistema. Estas actualizaciones pueden deberse a mantenimiento, reparación o al intento de mejorar o corregir el rendimiento del sistema, como reemplazar un instrumento defectuoso o modificar un algoritmo o configuración. Al hacer cambios en un sistema, es importante comprender qué partes del sistema de pruebas deben revalidarse para garantizar que los cambios no introduzcan fallos; esto se conoce como análisis de impacto. 

El Análisis de impacto es el proceso de determinar qué componentes de un sistema de pruebas se ven afectados por un conjunto de cambios realizados.

Es importante llevar a cabo un análisis de impacto detallado, ya que un cambio puede hacer que el sistema deje de funcionar correctamente de repente, lo que podría provocar la retirada de productos, paradas de producción u otras interferencias con el negocio. Un cambio también puede hacer que el sistema funcione correctamente, pero puede afectar el resultado o los resultados de la prueba y causar decisiones incorrectas sobre los productos probados. El coste de un cambio omitido o una validación incorrecta puede ser muy alto. En algunas industrias, los envíos de productos defectuosos pueden dar lugar a la retirada de productos. La FDA se reserva el derecho de tomar medidas regulatorias. 

Para mitigar el impacto de los cambios en un sistema, es importante diseñar el sistema de pruebas de forma modular, de modo que los cambios en un componente no afecten a los demás. Para ello, es importante asegurarse de que cada componente esté completamente desacoplado de los demás y tener procedimientos independientes para la validación. Por ejemplo, puede introducir una capa de abstracción de hardware (HAL), que proporciona un conjunto estándar de funciones para interactuar con el hardware. Las funciones definidas por la HAL se pueden validar de forma independiente del resto del sistema de pruebas. Si realiza un cambio de hardware, el impacto se producirá solo en la capa HAL, ya que puede verificar que las funciones de HAL tengan el mismo comportamiento después de realizar el cambio.

Estándares de la Industria de validación y verificación

Los principios que rigen la V&V están bien definidos para muchas industrias y están delineados por disciplinas como las Buenas Prácticas de Manufactura (GMP) o por regulaciones como ISO-9000, 21 CFR de la FDA o Estándares IEEE. Cada sistema de V&V es similar, pero utiliza una terminología ligeramente diferente para explicar los requisitos genéricos de ambos procesos. Por lo general, no se definen los requisitos específicos. Este documento explora los procesos de V&V para sistemas de pruebas automatizados.

Los requisitos de validación que se relacionan específicamente con dispositivos médicos en el 21 CFR de la FDA son imprecisos, e incluyen frases que especifican que un dispositivo médico debe ser validado para cumplir con las necesidades del usuario y los usos previstos, por lo que el administrador del sistema de calidad debe definir las necesidades y supervisar las pruebas de validación. Para los sistemas de pruebas, un método para definir una prueba de validación podría ser tan simple como realizar un seguimiento de los modos de falla conocidos y tener muestras de productos buenas y malas disponibles para ayudar a garantizar que el sistema detecte defectos conocidos. Otro método podría usar un procedimiento de prueba manual fiable o incluir otro sistema automatizado para validar los resultados del nuevo sistema de pruebas. 

Algunas instancias de validación deben ser extraordinariamente exhaustivas, como las que afectan a las industrias aeronáutica, farmacéutica y de dispositivos médicos, porque los procesos de validación implican casos extremos de seguridad, calidad o coste. Una validación exhaustiva del sistema puede tardar semanas o meses en definirse y llevarse a cabo. Por ejemplo, si un sistema de pruebas usa una matriz de conmutación en una configuración de 16x32, el ingeniero de pruebas puede probar todas las combinaciones posibles de conexiones mediante un probador de continuidad y asegurarse de que no se realicen nunca conexiones restringidas. Otro ejemplo podría consistir en validar un sistema de comunicación en el que se deba probar y validar cada comando y secuencia de comandos posibles. Aunque tales procesos de validación pueden parecer extremos, es imperativo que no se produzcan daños, lesiones o resultados incorrectos bajo ninguna circunstancia.

Los procesos de V&V se centran en especificaciones bien definidas. La validación también puede estar sujeta a algunos problemas objetivos, como las necesidades poco definidas del mercado o del usuario final. El primer paso más importante para cualquier sistema de pruebas es investigar y documentar una buena especificación de trabajo y requisitos de V&V. Puede ser difícil garantizar que el sistema de pruebas sea exhaustivo si las especificaciones no son específicas o dejan margen para la interpretación o las ambigüedades. Las pruebas se pueden detener si el auditor u observador encuentra una configuración no documentada o implementada incorrectamente. Una especificación bien escrita implementada con cuidado y atención puede ayudar a garantizar un proceso de V&V sin mayores dificultades.

La verificación requiere uno o más documentos de diseño o dibujos para determinar lo que el sistema debe lograr.  Los documentos y dibujos pueden cubrir un componente, un ensamblaje o todo un sistema. La especificación y la metodología de prueba para la verificación deben formar parte de un documento completamente detallado, con toda la información necesaria para crear un sistema de pruebas correcto.

Asegúrese de registrar cualquier cambio que se produzca en las especificaciones, ya sea ideado por un cliente, por ingenieros o como resultado del aprendizaje y el descubrimiento. Emplee un proceso de orden de cambio para registrar el cambio y el motivo, y para que el cambio sea oficial. La verificación solo se aprueba si hace coincidir las instrucciones, la configuración y los límites de prueba con el documento correcto. 

El diseño de una prueba de validación suele ser subjetivo y puede parecer más un arte que una ciencia, y aunque la sabiduría y la experiencia pueden parecer las únicas herramientas para el diseño de validación, recuerde que recopilar los requisitos puede ser revelador y útil. Las técnicas incluyen revisar el rendimiento anterior de otros dispositivos o productos de prueba, entrevistar a los operadores y sus supervisores y estudiar datos de mediciones anteriores. Una compañía que habitualmente subcontrata para probar integradores de sistemas realiza una revisión detallada de cada proyecto para encontrar formas de mejorar el siguiente proyecto y coloca esas ideas en una lista de verificación para el próximo proyecto.

TestStand se basa en una arquitectura modular, con muchos componentes desacoplados, incluido el motor TestStand, los modelos de proceso, el código de prueba y la interfaz de usuario. Esta arquitectura ayuda en las tareas de V&V, ya que cada componente puede analizarse con facilidad de forma independiente. Además, los cambios en los sistemas de pruebas existentes requieren menos revalidación, ya que el impacto se puede limitar a un solo componente.

La arquitectura modular de TestStand permite que cada componente se verifique y valide de forma independiente y reduce el impacto de los cambios en el sistema de pruebas en su conjunto.

Al diseñar un sistema de pruebas, es importante tener en cuenta la verificación y validación, y cómo puede diseñar el sistema para facilitar estos esfuerzos. Las siguientes secciones proporcionan las prácticas recomendadas para diseñar componentes de su sistema de pruebas teniendo en cuenta la V&V.

Diseñar archivos de secuencia

Al desarrollar secuencias de prueba, recuerde los siguientes objetivos:

• Integrar la funcionalidad mediante subsecuencias para bloques lógicos de funcionalidad.
• Reducir la interacción entre los pasos, lo que permite que los cambios en pasos individuales tengan un impacto menor en el sistema de pruebas.

Centrarse en estos objetivos le permitirá hacer un mejor seguimiento de cómo se cubren los requisitos en el código de prueba y reducir el impacto de los cambios que haga en los pasos individuales.  

Utilizar pasos separados frente a la configuración de pasos

Al definir una condición para un paso, analice si la condición podría aplicarse a varios pasos. El uso de los pasos If/Else o Case para implementar la lógica son más visibles en el entorno TestStand, son expandibles y pueden modificarse para ejecutar diferentes opciones e incluir más de un paso por condición. Sin embargo, introducen relaciones entre los pasos de prueba y el control de flujo. En cuanto a la lógica que siempre se aplicará a un solo paso, el uso de una condición previa le permite contener la lógica y el paso en un solo componente.
Use un enfoque similar al implementar el cambio en su código de prueba. En cuanto a las rutas que se aplican a una sola prueba, el uso de la configuración de conmutación de un paso le permite integrar la funcionalidad de conmutación con el código de prueba. En el caso de la conmutación que afecta a varios pasos, el uso de pasos de conmutación es más visible en una secuencia y hace que la secuencia se autodocumente más.

Modularizar mediante subsecuencias

Para combinar los beneficios de la descomposición en componentes de la configuración de pasos incorporados con la extensibilidad del uso de pasos independientes, puede crear subsecuencias para encapsular conjuntos de pasos relacionados. Al contener conjuntos de tales secuencias en un archivo de secuencia independiente, puede crear de manera eficaz un archivo de secuencia que es una biblioteca de funciones, que se puede validar y compartir de forma independiente entre múltiples aplicaciones de prueba.
Además, la secuencia de prueba debe estar compuesta casi en su totalidad por pasos de llamada de secuencia, que implementan agrupaciones lógicas de pruebas. La organización de subsecuencias debe corresponderse con las especificaciones de prueba, donde los requisitos de alto nivel, como “el sistema probará las capacidades de audio del dispositivo”, deben corresponderse con una secuencia en la prueba, mientras que los requisitos de soporte de nivel inferior, como “el volumen de sonido máximo no debe exceder los 80 dB”, deben corresponderse con los pasos de la secuencia.

Reducir dependencias entre múltiples pasos

También puede introducir dependencias entre pasos, como ocurre cuando un paso requiere los datos obtenidos en el paso anterior. Evite usar la propiedad PreviousStep para acceder directamente a los datos de otro paso y, en su lugar, use una variable local para almacenar los datos del primer paso y, a continuación, acceda a la variable en el paso posterior.

También debe asegurarse de que cada paso establezca o verifique de manera independiente que las condiciones requeridas se establezcan antes de ejecutar la prueba. Por ejemplo, si un paso de prueba del volumen de audio incluye una prueba de volumen a volumen bajo, medio y alto, y un paso posterior realiza una prueba de calidad de audio que debe hacerse a volumen medio, debe asegurarse de que el volumen se establezca a medio antes de realizar la prueba. Esto garantiza que ambas pruebas sean independientes: los cambios en la prueba de volumen de audio no afectarán a la prueba de calidad de audio.

Documentar las secuencias de prueba

Una documentación clara de sus archivos de secuencia es una importante para garantizar que todos los requisitos de la especificación estén suficientemente cubiertos. Sin embargo, debe evitar repetir información en la documentación, como valores límite o parámetros de prueba. 

Puede usar el nombre y la descripción de un paso para documentar el propósito del mismo. El nombre del paso debe describir lo que hace y por qué realiza una acción, pero no debe contener valores de parámetros definidos en el paso. Por ejemplo, en lugar de nombrar un paso “Esperar”, nómbrelo “Esperar a que el sistema arranque”. Si el nombre requiere más información, utilice la propiedad de descripción del paso para añadir más detalles.

También puede usar la integración de TestStand con NI Requirements Gateway para rastrear de manera eficaz dónde se cubren los requisitos en el código de prueba real. NI Requirements Gateway le permite ver rápidamente qué requisitos se cubren e ir al paso que cubre el requisito, lo que acelera el proceso de verificación.

NI Requirements Gateway le permite crear enlaces entre los documentos de requisitos, secuencias de prueba e informes de prueba para garantizar que se cumplan todos los requisitos.

Utilice el campo Requisitos [Requirements], que está disponible para pasos, secuencias y archivos de secuencia, a fin de proporcionar información sobre los requisitos que cubren. Puede usar estos campos con NI Requirements Gateway para crear una asignación entre el documento de requisitos y el código de prueba para ver rápidamente dónde se cubren los requisitos. 

Utilice el campo de requisitos para asignar pasos, secuencias o archivos de secuencia a requisitos específicos en los documentos de especificaciones.

Para obtener más información sobre el uso de NI Requirements Gateway con TestStand para rastrear los requisitos, consulte el tutorial Acoplar NI Requirements Gateway con NI TestStand.

Desarrollar módulos de código independientes

TestStand inicia los módulos de código de llamada para comunicarse con el hardware de automatización e instrumentación. Los módulos de código se pueden implementar en varios lenguajes, incluidos LabVIEW, C++ o C#. Puesto que TestStand proporciona un límite natural entre los pasos y los módulos de código, es conveniente escribir módulos de código que se puedan probar y validar independientemente de la secuencia de TestStand. 
Para garantizar que los módulos de código se puedan probar fuera de la secuencia de prueba, evite usar SequenceContext u otras referencias de TestStand para acceder a los datos directamente y, en su lugar, pase los datos al módulo de códigos a través de parámetros. Para los casos en los que es necesario usar SequenceContext, como para implementar un monitor de terminación, diseñe el módulo de código para que pueda funcionar sin el código específico de TestStand. En un módulo de código de LabVIEW, puede usar la función “no es una referencia” para verificar si SequenceContext es válido antes de usarlo.

Con módulos de código que se pueden ejecutar de forma independiente, puede diseñar dispositivos de prueba que se repiten en el módulo de código y pasar todas las permutaciones de los parámetros de entrada. El dispositivo de prueba puede comparar los resultados con los resultados correctos conocidos para validar que los módulos de código se comporten según lo previsto.

Realizar cambios en los modelos de proceso mediante plug-ins

Los modelos de proceso de TestStand controlan la funcionalidad de prueba que no es específica de una unidad bajo prueba, incluido el rastreo de UUT, la generación de informes, el registro de la base de datos y las pruebas por lotes o en paralelo. Los modelos de proceso que se envían con TestStand son complejos, por lo que realizar cambios en estos modelos requiere una considerable labor de validación. 

Los modelos de proceso utilizan una arquitectura de plug-in que implementa las capacidades de generación de informes y de registro de la base de datos predeterminadas. Puede utilizar esta arquitectura para ampliar la funcionalidad de los modelos de proceso existentes sin hacer cambios en los archivos de secuencia del modelo de proceso. Para hacerlo, cree un plug-in personalizado, que se implementa en un archivo de secuencia de plug-in separado. Puede validar el comportamiento de este plug-in de forma independiente.

Los plug-ins de los modelos de proceso son componentes separados de los archivos de modelo de proceso, que pueden validarse individualmente.

Si necesita hacer cambios en la funcionalidad directamente en los modelos de proceso, como hacer cambios en la forma en la que el modelo recopila el número de serie de UUT, plantéese la posibilidad de deshabilitar los pasos en el modelo de proceso que implementan la funcionalidad existente y, a continuación, cree un plug-in aparte para la nueva funcionalidad. Con este método, los cambios futuros que haga en el comportamiento personalizado pueden limitarse solo al plug-in, que será más fácil de revalidar. 

Para obtener más información sobre cómo personalizar los modelos de proceso y plug-ins, consulte el documento Prácticas recomendadas para el desarrollo y personalización del modelo de proceso de NI TestStand.

Administrar configuración y ajustes de prueba

Al desarrollar un sistema de pruebas, es importante asegurarse de que todas las configuraciones de TestStand sean las mismas en todas las estaciones que ejecutan la prueba y que no se modifiquen nunca sin la validación adecuada del cambio. Sin embargo, dado que muchos componentes de TestStand tienen configuraciones individuales, puede resultar difícil garantizar que no haya cambios. Además de la configuración de TestStand, también debe asegurarse de que la configuración del instrumento sea coherente en todos los sistemas de pruebas. La configuración del instrumento puede incluir la configuración de NI-DAQmx realizada en NI Measurement & Automation Explorer (MAX) o las configuraciones de GPIB y COM para un dispositivo. Dichas configuraciones pueden ser numerosas, y las pruebas de validación pueden ser difíciles de diseñar.

Una forma de garantizar que las configuraciones sean correctas es establecerlas mediante programación en la secuencia de prueba y después consultar cada configuración para asegurarse de que el instrumento o programa haya aceptado la configuración. Si no se puede consultar la configuración, busque dónde está almacenada y léala desde un archivo de texto, INI o XML. El sistema puede verificar y registrar el estado de los elementos externos a TestStand y mantenerlos bajo control.

Administrar archivos mediante herramientas de control de código fuente

Otro método para administrar la configuración consiste en controlar de forma estricta los archivos que contienen la configuración. Los archivos de configuración que almacenan todas las configuraciones de TestStand se almacenan en el directorio <TestStand Application Data>\Cfg. En cuanto a otras configuraciones, consulte la documentación específica del producto para obtener información sobre la ubicación de los archivos de configuración.
El método aceptado por la industria para monitorear, controlar y almacenar archivos del sistema de prueba son los programas de control de código fuente (SCC) como Subversion, Perforce y Microsoft Visual SourceSafe. Muchos de estos programas están diseñados para ajustarse a la interfaz de SCC de Microsoft y se pueden usar en TestStand o LabVIEW. En algunos casos, no se puede modificar un archivo sin tomar la propiedad temporal del mismo y documentar los cambios para guardarlos. A menudo, estos programas pueden decirle qué archivos han cambiado, así como analizar los archivos antiguos y nuevos para resaltar los cambios y ayudar a simplificar la verificación.

También puede usar sumas de verificación de archivos para asegurarse de que los archivos de configuración no hayan cambiado desde el estado validado. Para utilizar este enfoque, puede agregar pasos que comparen la suma de verificación con una suma de verificación que calcule para el valor de archivo validado y generar una falla de prueba si no coinciden.   

Además del sistema de pruebas, es importante asegurarse de que todo el hardware y software que respalden la prueba se encuentre en un estado conocido y validado. En esta sección se ofrecen técnicas para mantener el estado del sistema y la forma de aplicar los cambios cuando sea necesario.

Administrar la configuración de hardware

Debe seleccionar, instalar, programar y configurar adecuadamente los instrumentos no solo para el sistema sino también para cada prueba independiente. Por ejemplo, un multímetro digital (DMM) u osciloscopio cuenta con varias opciones para configurar una comunicación y adquisición de señal adecuadas que deben verificarse y validarse al finalizar un sistema de pruebas y para cambios en el hardware en el futuro.

La creación de una capa de abstracción de hardware (HAL) para administrar las interacciones de hardware puede ayudar a reducir la revalidación requerida al realizar cambios en el hardware en el sistema de prueba. En lugar de emplear módulos de código específicos de un dispositivo en una secuencia de prueba, una HAL le brinda la habilidad de separar tipos de mediciones y controladores específicos del instrumento de la secuencia de prueba. Debido a que los procedimientos de prueba normalmente se definen usando tipos de instrumentos (como fuentes de alimentación, multímetros digitales [DMM], salidas analógicas y relés) en lugar de instrumentos específicos, el empleo de capas de abstracción da, como resultado, una secuencia de prueba que es más adaptable a los nuevos instrumentos y requerimientos. Una HAL puede validar el nuevo hardware asegurándose de que las funciones de HAL produzcan el mismo resultado que el hardware anterior en un conjunto de casos de prueba, sin la necesidad de probar todo el sistema de pruebas. Para obtener información más detallada sobre el uso de HAL, consulte Fundamentos de la construcción de un sistema de pruebas: Capas de abstracción de hardware y mediciones.

Otra buena idea es validar el hardware en tiempo de ejecución. Al leer y almacenar configuraciones u otros factores en tiempo de ejecución, puede asegurarse de que los elementos que deben validarse junto con el software están configurados y funcionan según lo previsto. Por ejemplo, los pasos de TestStand pueden consultar las fechas de calibración de un instrumento para garantizar que la calibración esté actualizada y pueden verificar el número de modelo y el número de serie del instrumento conectado a un puerto COM para garantizar que no se haya reemplazado el instrumento. Los procesos de V&V se pueden simplificar mediante el diseño de la secuencia de pruebas e incluso con la compra de instrumentos para tal fin.

Si cree que debe cambiar de hardware, debe considerar la posibilidad del cambio en un proceso de V&V. Si un instrumento falla y se inserta otro de la misma marca y modelo, analice lo que tiene que hacer para verificar que funciona adecuadamente y diseñe una prueba para asegurarse de que el cambio se ha realizado correctamente. El uso de controladores e interfaces de Interchangeable Virtual Instrument (IVI) para la configuración de instrumentos puede ayudar a simplificar la transición entre dos instrumentos de la misma marca o modelo, o entre dos instrumentos de marcas o modelos diferentes.

Administrar la configuración de software

Al tener un sistema de pruebas, deberá considerar la posibilidad de actualizar LabVIEW, TestStand o cualquier otro programa para aprovechar las nuevas funciones a medida que estén disponibles. Hacer una actualización de software de este tipo siempre es un desencadenante para una nueva validación y una nueva verificación. Trate una potencial actualización como un ejercicio de retorno de inversión (ROI). Por ejemplo, para obtener una interfaz de desarrollo simplificada, es posible que desee actualizar durante el desarrollo, pero no después de que se implemente el sistema. Sin embargo, como es el caso con las actualizaciones recientes de TestStand, la velocidad de ejecución mejorada puede dar como resultado un tiempo de prueba más corto, mayor rendimiento y mayores ingresos. En ambos casos, el coste de la revalidación es el factor decisivo, pero el coste también puede proporcionar un ROI positivo y, por lo tanto, vale la pena el gasto y el esfuerzo. Por lo general, se deben llevar a cabo varias actualizaciones de software a la vez para minimizar la cantidad de veces que el software necesita ser validado.

Para mantener un conjunto de software coherente en un sistema de pruebas, puede crear una imagen base a partir de un sistema validado y usar esta imagen al configurar nuevas estaciones de prueba. Sin embargo, incluso cuando se utiliza una imagen, debe asegurarse de que no se realicen actualizaciones de software. En cuanto al software de NI, asegúrese de que el servicio de actualización de NI esté configurado para que nunca se instalen actualizaciones automáticamente. En la mayoría de los ordenadores, las actualizaciones de Microsoft se instalan automáticamente. Otras compañías, como Sun, Apple y Adobe, también utilizan actualizaciones automáticas basadas en la web. Debe deshabilitar los cambios y actualizaciones automáticos en todos los sistemas sujetos a los procesos de V&V. No se puede predecir los cambios que introducen las actualizaciones automáticas, y pueden tener efectos desconocidos en el funcionamiento y la configuración. 

El departamento de TI puede tener la política general de que controlan los ordenadores de la empresa, incluido el uso de software de detección de virus, el establecimiento de políticas de seguridad, como protectores de pantalla, y la instalación de parches y actualizaciones según sea necesario. El departamento de fabricación debe trabajar con el departamento de IT para ayudar a gestionar los sistemas TestStand dejándolos intactos. Debe decidir qué elementos afectan específicamente a sus ordenadores, pero sus necesidades pueden contrastar con la política de TI, como la eliminación de los escáneres de virus, la desactivación de los protectores de pantalla y la exención de actualizaciones o parches para toda la empresa.

Haga clic para ver otros documentos dentro de la Serie de Arquitectura Avanzada de TestStand que cubren temas de interés para los desarrolladores avanzados de NI TestStand.