Vvvvvvvvv

¡Hey! Cuánto tiempo sin escribir y vernos por aquí, ya sabemos que no nos extrañabas pero de cualquier modo estamos de regreso y sólo por poco tiempo, porque ya vienen vacaciones de nuevo y nos iremos de nuevo así que hoy te hablaremos de un tema mega divertido: verificación y validación, eso que muchas personas lo dejan hasta el final como la escritura de todas estas entradas pero como veremos hoy, es un proceso continuo que se tiene que hacer durante todo el proceso de software y no únicamente antes de que se vaya a liberar, ¿qué? ¿No te habías enterado? Bueno, precisamente para eso son estas entradas, sin más que decir, adentrémonos en este mundo de locura de la validación y la verificación.

V&V


No, no se trata de esa marca de chocolates que tienen comerciales muy cool, estamos hablando de V&V y no de M&M's, V&V se trata de las siglas de Verificación y Validación que incluyen a todos los procesos de comprobación y análisis que llevan a asegurarnos que el software que estamos desarrollando harán a nuestro cliente más que feliz. Como ya te adelantamos un poco arriba, la validación y la verificación no son una etapa que se hace hasta el final del proyecto o cuando ya se va a liberar la primera versión el público en general sino que tiene que estar en cada etapa del desarrollo.

Estas etapas de las que estamos hablando inician con la verificación de todos nuestros requerimientos tanto funcionales como no funcionales, es decir, asegurar que nuestro software haga lo que nuestro cliente y nuestras propias indagaciones nos indiquen. Después tenemos la etapa de validación, esta etapa es esencial ya que este software a pesar de que pueda pasar la verificación no va a indicar necesariamente que nuestro cliente esté satisfecho con el producto, la validación entre otras cosas nos indicará si nuestro desarrollo actual cumple las expectativas del cliente o no. Es decir, si lo hace feliz o no.


Como ya lo viste, validación y verificación fácilmente se pueden confundir pero para que no lo hagas más, te diremos dos preguntas que te tienes que hacer para tener una diferencia clara sobre lo que van cada uno de ellos:
  • Verificación: ¿Estamos construyendo el producto correctamente?
  • Validación: ¿Estamos construyendo el producto concreto?
Tenemos que ser formales


Cuando estamos tratando con software crítico, es decir, software del que de su desempeño dependen funciones críticas de un sistema más grande entonces tenemos que asegurarnos que cumplan las funciones al pie de la letra. Para solucionar este tipo de problemas se crearon los casos de prueba, estos casos validan que los requerimientos del usuario se cumplan al pie de la letra y que nuestro software sea uno de calidad entonces requeriremos de casos de prueba de calidad así que para esto hablaremos de un estándar más que conocido en la industria y que fue hecho por la NASA: IV&V.

IV&V significa Independent Verification and Validation y está dirigido a sistemas de software críticos no, un software crítico no es ese que administrará el cibercafé de tu colonia. su función principal es reducir los riesgos y costos a lo largo de la vida operativa del software y para lograrlo se sirve de cinco fases principales:
  •  Planificación IV&V
  • Verificación de requisitos
  • Verificación de diseño
  • Código de verificación
  • Validación
Un muy buen resumen acerca de lo que va cada etapa lo puedes encontrar aquí, en su correspondiente entrada en Wikipedia, el escribirlo yo aquí a modo de resumen sería un abuso y estoy seguro que me saltaría detalles importantes así que antes de seguir leyendo, te recomiendo que vayas y le des una leída.

Procesos que de comunes no tienen nada


Hasta ahora todo bien, ya hemos hablado acerca de la verificación, de la validación y hasta de un estándar pero... ¿qué hacemos cuando encontramos un error en una de las inspecciones antes dichas? Bueno, sigue la depuración. La depuración es el proceso que localiza el origen y corrige los defectos que se pueden encontrar en el software y consta de los siguientes pasos:

  1. Localizar el error: una vez que tenemos como resultado un error, lo que sigue es localizarlo en nuestro código y ver de una buena vez qué es lo que lo está provocando. Recuerda que este error no necesariamente estará cerca de dónde lo encontramos.
  2. Diseñar reparación de errores: sí, esto también lo tenemos que diseñar. Toma una hoja de papel antes de siquiera modificar una línea de código, recuerda que tienes que tener un plan siempre.
  3. Reparación de errores: ¿ya tienes tu plan? Ahora sí, manos a la obra.
  4. Probar de nuevo: Ya que todo está bien, entonces prueba que el error se haya ido de una vez por todas.
  5. Vuelve a la verificación principal.
 Esta es la manera más coloquial de detectar errores pero hay otras formas más formales tales como las pruebas de defectos y las pruebas estadísticas pero por efectos del curso, en esta entrada solo mencionaremos las pruebas de defectos. Las pruebas estadísticas pretenden encontrar las inconsistencias entre un programa y su especificación, inconsistencias que se deben principalmente a defectos en el código del programa y los pasos a seguir en las pruebas de defectos son las siguientes:


En la imagen de arriba te mostramos el proceso de las pruebas de defectos y lo que se espera cuando se cumple un ciclo de estos. Más allá de las pruebas de defectos también existen otras pruebas funcionales como la de caja negra y caja blanca que se concentran en seleccionar casos de prueba particulares para cada componente o programa en conjunto, en el caso de la caja negra las pruebas se seleccionan en función de la especificación y no de la estructura interna así como pruebas que se seleccionan en función del conocimiento que se tiene de la implementación del módulo. 

Conclusiones

Como ya viste, la verificación y la validación no tienen que ser un proyecto tan dramático y mientras más rápido te acostumbres a que forme parte del ciclo de vida de tu software y no unicamente al final entonces más de tus proyectos llegarán a buen puerto. Este tema en particular es muy denso, por lo que no estaría de más que revisaras algo más sobre el tema, recuerda, en esta entrada sólo rascamos la superficie de todo el mundo de validación y verificación, queda un mundo por delante que no estaría nada mal que descubrieras. Sin más que decir, yo me despido... ¡Nos vemos a la vuelta!

Comentarios

Entradas populares de este blog

Hagamos un breve repaso

El QQQ que no es malo

Casos de la vida real (en el diseño orientado a objetos)