Revisiones Estáticas

 Beneficios de las Revisiones:

Es necesario buscar irregularidades tempranos en productos ya que estos se traducen como defectos en el producto final.

"Veamos una analogía con la arquitectura de edificios. Si en un plano el color de una línea indica su significado, una confusión en el color se traducirá en un error en el edificio. Por ejemplo, si el azul indica tuberías de agua y el amarillo cables eléctricos y el arquitecto comete un error usando el azul en una conducción eléctrica, los electricistas que usen el plano como guía para su trabajo no colocarán cables eléctricos mientras que los fontaneros colocarán tuberías de agua donde no debían ir." [1]

 El plano de un edificio es el artefacto equivalente al diseño de un producto software. Si un diseño tiene irregularidades, seguramente estas irregularidades se trasmitirán al código cuando los programadores usen ese diseño como guía para su trabajo.


Es por esto que la detección temprana de errores conlleva grandes beneficios. Si las revisiones únicamente se aplican al código mejoran la calidad y producen ahorros en los costos del proyecto. Pero más ahorros habrán si se da una revisión temprana del desarrollo.

"Estudiando los resultados publicados sobre ahorros con las revisiones, puede afirmarse que la utilización de inspecciones de código produce un ahorro del 39% sobre el coste de detectar y corregir defectos, frente a únicamente utilizar la evaluación dinámica. Sin embargo, el ahorro es del 44% si se inspecciona también el diseño."[1]

 Las revisiones también proporcionan beneficios más generales. Entre éstos se pueden citar los siguientes: evaluación del progreso del proyecto, potencia las capacidades de los participantes, mejoran la comunicación entre el equipo de desarrollo, aumentando su motivación, pues los productos paran a ser documentos públicos, proporciona aprendizaje, retroalimentación y prevención, forma y educa a los participantes.

 Objetivos de la Evaluación Estática
La evaluación estática de los productos que se vayan generar en el desarrollo de software como lo pueden ser: especificación de requisitos, modelos conceptuales, diseño, código, entre otros. Lo que pretende es comprobar su calidad. 

Los defectos que se buscan al evaluar estáticamente los productos de software son los siguientes: 

"• Para los requisitos: 
              o Corrección. Los requisitos especifican correctamente lo que el sistema debe hacer. Es                          decir, un requisito incorrecto es un requisito que no cumple bien su función. Puesto que la                    función de un requisito es indicar qué debe hacer el sistema, un requisito incorrecto será                      aquel que, o bien pide que el sistema haga algo que no es lo que debe hacer, o pide que                        haga algo que no deba hacer.               o Compleción. Especificación completamente el problema. Está especificado todo lo que                         tiene que hacer el sistema y no incluye nada que el sistema no deba hacer. En dos                                 palabras: no falta nada; no sobra nada Consistencia. No hay requisitos contradictorios.                     o Ambigüedad. Los requisitos no pueden estar sujetos a interpretación. Si fuese así, un                             mismo requisito puede ser interpretado de modo distinto por dos personas diferentes y, por                   tanto, crear dos sistemas distintos. Si esto es así, los requisitos pierden su valor pues dejan                  de cumplir su función (indicar qué debe hacer el sistema). Las ambigüedades provocan                        interpretación por parte de la persona que use o lea los requisitos. Por tanto, una                                    especificación debe carecer de ambigüedades.                                                                                      o Claridad. Se entiende claramente lo que está especificado. • Para el diseño:              o Corrección. El diseño no debe contener errores. Los errores de corrección se pueden referir                 a dos aspectos. Defectos de “escritura”, es decir, defectos en el uso de la notación de diseño                 empleada (el diseño contiene detalles prohibidos por la notación). Defectos con respecto a                   los requisitos: el diseño no realiza lo que el requisito establece. Hablando apropiadamente,                   los primeros son los puros defectos de corrección, mientras que los segundos son defectos                   de validez.              o Compleción. El diseño debe estar completo. Ya sea que diseña todo el sistema marcado por                 los requisitos; ya sea no diseñando ninguna parte no indicada en los requisitos. De nuevo,                   nada falta, nada sobra.              o Consistencia. Al igual que en los requisitos, el diseño debe ser consistente entre todas sus                     partes. No puede indicarse algo en una parte del diseño, y lo contrario en otra.              o Factibilidad. El diseño debe ser realizable. Debe poderse implementar.              o Trazabilidad. Se debe poder navegar desde un requisito hasta el fragmento de diseño donde                 éste se encuentra representado. • Código Fuente:              o Corrección. El código no debe contener errores. Los errores de corrección se pueden referir                 a dos aspectos. Defectos de “escritura”, es decir, lo que habitualmente se conoce por                             “programa que no funciona”. Por ejemplo, bucles infinitos, variable definida de un tipo                       pero utilizada de otro, contador que se sale de las dimensiones de un array, etc. Defectos                       con respecto al diseño: el diseño no realiza lo que el diseño establece." [1]

 Técnicas de Evaluación Estática

Las técnicas de Evaluación estática de artefactos del desarrollo se las conoce de modo genérico por Revisiones.  Las revisiones pretenden detectar manualmente defectos en cualquier producto del desarrollo. Por manualmente queremos decir que el producto en cuestión (sea requisito, diseño, código, etc.) está impreso en papel y los revisores están analizando ese producto mediante la lectura del mismo, sin ejecutarlo.

Algunas de esas Revisiones son: 

"• Revisiones informales, también llamadas inadecuadamente sólo Revisiones (lo cual genera confusión con el nombre genérico de todas estas técnicas). Las Revisiones Informales no dejan de ser un intercambio de opiniones entre los participantes.
 • Revisiones formales o Inspecciones. En las Revisiones Formales, los participantes son responsables de la fiabilidad de la evaluación, y generan un informe que refleja el acto de la revisión. Por tanto, sólo consideramos aquí como técnica de evaluación las revisiones formales, puesto que las informales podemos considerarlas un antepasado poco evolucionado de esta misma técnica.
• Walkthrough. Es una revisión que consiste en simular la ejecución de casos de prueba para el programa que se está evaluando. No existe traducción exacta en español y a menudo se usa el término en ingles. Quizás la mejor traducción porque ilustra muy bien la idea es Recorrido. De hecho, con los walkthrough se recorre el programa imitando lo que haría la computadora.
• Auditorias. Las auditorias contrastan los artefactos generados durante el desarrollo con estándares, generales o de la organización. Típicamente pretenden comprobar formatos de documentos, inclusión de toda la información necsaria, etc. Es decir, no se tratan de comprobaciones técnicas, sino de gestión o administración del proyecto."[1]

 Blibliografía:

[1] Obtenido de: http://webcache.googleusercontent.com/search?q=cache:nwRR7iLakiEJ:www.lsi.us.es/docencia/get.php%3Fid%3D360+&cd=4&hl=es&ct=clnk