¿Qué es la validación de software?
La validez de
la información de la medición es de interés para todos aquellos que la utilizan
o son afectados por ésta. Las mediciones, particularmente las realizadas en el
ensayo y la calibración, a menudo involucran procesos complejos, utilizan una
gran variedad de software, hardware, personas y formatos de datos.
El uso de
software apropiado le facilita a la organización disminuir los errores y bajar los
costos, compartir los datos, utilizar conjuntamente diferentes componentes, guías
y prácticas para proveer procesos eficaces y eficientes. El principio de mejora
continua debe ser aplicado también al software.
Las pruebas
de validación en la ingeniería de software son el proceso
de revisión que el sistema de software producido
cumple con las especificaciones y que cumple su cometido. Es normalmente una
parte del proceso de pruebas de software de un proyecto, que
también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales.
La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente
quería.
¿Para qué sirve?
La validación
del software es necesaria ya que proporciona un alto grado de confianza y seguridad
en el software y en los resultados que se obtienen al aplicarlo.
Comprobar que
se satisfacen los requisitos:
·
Se
usan la mismas técnicas, pero con otro objetivo.
·
No
hay programas de prueba, sino sólo el código final
de la aplicación.
·
Se
prueba el programa completo.
·
Uno
o varios casos de prueba por cada requisito o caso de uso especificado.
·
Se
prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos).
·
Pruebas alfa (desarrolladores)
y beta (usuarios).
¿Cómo se valida?
Para los
laboratorios de ensayo y calibración que se encuentran acreditados o en proceso
de acreditación, según los requisitos establecidos en la Norma ISO/ IEC 17025 (NVC
2534: 2000) “Requisitos generales para la competencia de los laboratorios de ensayo
y calibración”, la validación del software desarrollado por el usuario es un requisito
técnico que debe ser cumplido con el mismo rigor que el resto de los
requisitos. La calificación de “adecuado para el uso”, aplicada a un software
relacionado con los procesos de ensayo o calibración, es una garantía de que la
influencia del software sobre el resultado de la medición está bajo control, al
realizar el análisis del proceso de medición como sistema, único enfoque que evalúa
integralmente el proceso de medición.
Ciclo de vida de una validación
No es recomendable
el uso de un modelo específico del ciclo de vida del software.
Los
diseñadores del software deben establecer un modelo del ciclo de vida del software
que sea apropiado a su producto y organización. El modelo del ciclo de vida que
se seleccione debe cubrir desde la creación del software hasta el retiro del
uso (desinstalación) del mismo.
· Planificación de la calidad.
· Definición de los requisitos del sistema.
· Especificación detallada de los requisitos del software.
· Especificación del diseño del software.
· Implementación (construcción o codificación) .
· Prueba.
· Instalación.
· Operación y apoyo.
· Mantenimiento.
· Desinstalación.
Empresa que realiza este tipo de validación
Software Quality Sistem S.A.
Los servicios
de Validación y Verificación independiente de SQS permiten incorporar a lo
largo de sus procesos de desarrollo actividades de calidad de software. Esto
permitirá mejorar y asegurar la calidad del desarrollo durante todo el proceso.
Las ventajas son claras, un mayor control sobre el proceso, una identificación
temprana de errores y problemas y una reducción drástica de los costes para
subsanar estos errores. Una parte importante de los proyectos de Validación y
Verificación que lleva a cabo SQS, se deben a la necesidad en el cumplimiento
de normativas específicas de sectores como el ferrocarril, la industria
farmacéutica o la aeronáutica entre otros.
Que pruebas y test realiza la empresa
Como parte de
estrategia completa de Validación y Verificación, es necesario identificar las
actividades que se incorporarán a lo largo del proceso de desarrollo. El equipo
de consultoría de SQS es experto en las siguientes actividades:
· Diseño
e Implantación de Entornos de Pruebas.
· Coordinación
de procesos de prueba. Definición de las tareas de test.
· Revisiones
Formales de Documentación.
· Revisiones
de Código.
· Pruebas
Unitarias y de Integración.
· Pruebas
Funcionales y de Aceptación.
· Métodos
Estáticos y Dinámicos.
· Implementación
de Estándares de Calidad y Seguridad.
· Formación
del personal cliente.
Los
principios de actuación de SQS en los procesos de Verificación y Validación
son:
· Independencia entre
equipos de desarrollo/ ingeniería y pruebas.
· Enfoque
formal del proceso de test.
· Automatización del
proceso de test (Hardware y Software). Repetitividad de los ciclos de prueba.
· Certificación
de operación acorde con requerimientos del sistema y de su entorno.
· Compromiso
con Resultados. Establecimiento de Principio y Fin medibles
Problemas de software de la historia
Error de división de Intel Pentium
El 30 de octubre de 1994 el profesor Thomas Nicely de la Universidad de
Lynchburg descubrió
un error en
la unidad de coma
flotante del Intel Pentium. Nicely observó que algunas operaciones de
división devolvían siempre un valor erróneo por exceso. Otras personas
confirmaron rápidamente estos errores en las divisiones. Este fallo de diseño
se hizo notorio muy rápidamente y se le dio el nombre de error FDIV del Pentium (FDIV es la instrucción de división en coma flotante de
los microprocesadores x86).
Intel negó inicialmente la existencia del
problema. Más tarde, Intel remarcó la insignificancia de los defectos de sus
microprocesadores, queriendo tranquilizar a los usuarios. Intel se negó a
sustituir sistemáticamente los microprocesadores defectuosos; sin embargo, si
una persona podía demostrar que había sido afectada por el error, entonces
Intel procedería a cambiar su procesador. Aunque evaluaciones efectuadas por
organismos independientes mostraron la poca importancia de las consecuencias de
error y que el efecto era desdeñable en la mayoría de las ocasiones, se provocó
una situación en la que los usuarios de Intel Pentium demandaban el reemplazo
de los procesadores defectuosos. Empresas como IBM se unieron a la denuncia. Al final,
Intel se vio forzada a aceptar sustituir todos los microprocesadores defectuosos,
lo que le representó un coste enorme.
El fallo
estaba presente tan sólo en algunos modelos del procesador Pentium. Todos los
modelos de procesador de familia Pentium que funcionan a una frecuencia de reloj de por lo menos 120 MHz tienen
el error corregido.
Realizando
esta operación en la calculadora de Windows se podía comprobar el error.
§ 4195835.0/3145727.0 = 1.333 820 449 136 241 002
(Resultado correcto)
§ 4195835.0/3145727.0 = 1.333 739 068 902 037 589
(Pentium con error)
Problema de frenos Toyota
A finales
del 2009 y todo el 2010 se presentaron muchas quejas de automovilistas por el
auto Prius de 3era generación.
Los países
que presentaron quejas en estos modelos fueron EEUU y Japón.
Al
principio se creía que todo era problema de unas alfombrillas entrometidas que
estaban estorbando al momento del frenado, esto provoco más investigación por
parte de las organizaciones correspondientes.
Tiempo despues se determino que todo era problema del software que se habia instalado para el control de los frenos de ese marca, Toyota admitio su error y comenzo a hacer una actualizacion con un parche en el software para los modelos posteriores, pero a los que ya estaban en circulación tuvo que convocar a los clientes a que llevaron su auto a revision para despues instalarles la actualización en los autos hibridos.
Toyota explico que el error solo era cuando el auto estaba acelerando poco y despues intentaba frenar, surgia el error. A altas velocidades el software funcionaba todo bien.
Todo esto le costo a la empresa millones de dolares y perdida de muchos clientes y demandas por los clientes que se habian visto afectados por este imperfecto de software.
Bibliografía.
