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

Costos de detección y reparación de defectos de un proyecto

En la elaboración de un proyecto se pueden dar "X" cantidad de errores. Pero el problema no es que existan errores, ya que en la gran mayoría de los proyectos se va a dar, sino más bien es en que etapa se está dando este error. Se tienen algunas etapas en la que estos errores pueden aparecer, como lo son las que se muestran en el video presentado: Inicio del proyecto, organización y preparación, realización del trabajo, mantenimiento.  


Ahora bien, según en donde ese error sea ubicado en alguna de las etapas comentadas, va a variar a el costo en que este error será reparado. Como se muestra en el video, se observa que mientras ese error se muestra más al inicio será un costo menor a que se repare o modifique algo en el proyecto en las fases de fiscalización.
Es por esto que realizar una buena verificación de los requerimientos o requisitos con los que se va a implementar el proyecto para que lo principal en la historia de todo proyecto se dé (el costo) sea relativamente menor.


Se mencionado en el video un aproximado de $50 la modificación de una línea de código antes de la liberación del proyecto. Por lo contrario de la reparación o modificación del defecto encontrado después de la liberación, ya que con esto puede costar aprox. $4,000, costando 80 a 100 veces más. Con este dato nos podemos dar una idea más clara de lo perjudicial que puede resultar la reparación de un defecto encontrado en una etapa de fiscalización del proyecto.



Bibliografía
[liderdeproyecto].(2015, setiembre 30).Dirección de proyectos: ¿Cuánto cuesta repara un error?[Archivo de video]. Recuperado de https://www.youtube.com/watch?v=7i5Ugy7ys50

IEEE 1044 (2009)

El acrónimo IEEE cuyo significado es Instituto de Ingeniería Eléctrica y Electrónica es una asociación que se dedica a la estandarización de distintas áreas de tecnología, esta tiene muchos éxitos en el mercado debido a lo eficaz que resultan sus normas .

Los éxitos del IEEE incluyen:
• Resultados financieros excepcionales, con superávit neto de US $ 71,1
Millones con un superávit operativo de 21,4 millones de dólares EE.UU.
Y ganancias netas de inversión de US $ 50,2 millones.
• Un aumento del 7,6% en las ventas de productos,
Entre los suscriptores académicos de la
América del Norte y un notable crecimiento de IEEE / IET
Biblioteca electrónica en Brasil, China, India y el Sur
África, entre otras naciones.
• Un récord histórico de 397.001 miembros
En la mayoría de los grados de membresía y en IEEE
Miembros de la sociedad.
• Un récord de 1.077 conferencias técnicas
Patrocinado o copatrocinado por IEEE.(Reid & James, 2009)

El IEEE cuenta con treinta y ocho sociedades que están orientadas a trabajo distinto.  Las sociedades realizan publicaciones especializadas, redes de negocio entre otros muchos servicios más.
Además, cuenta con una serie de normas o estándares diseñadas para un tipo de trabajo específico.
Ahora hablaremos de IEEE 1044, esta norma proporciona el conjunto básico de atributos para la clasificación de fallas y defectos.(IEEE, 2009)

Esta norma puede ser utilizada por cualquier tipo de software, a esto también se le incluye la posibilidad de ser utilizado en sistemas operativos, aplicaciones, firmware y sistemas de gestión.

Esta norma busca definir un vocabulario común en el cual diferentes personas u organizaciones puedan tener una comunicación productiva acerca de algunas anomalías que se pueden dar en el software que al que se le esté atendiendo y establecer técnicas de la industria para analizar defectos del software mismo y algunos datos de fallas.

IEEE 1044 cuenta con un proceso de clasificación en la que la organización definirá su proceso de clasificación de la siguiente manera:
A) La meta o objetivos a alcanzar mediante la clasificación de los defectos y fallos.
B) La norma de referencia (por ejemplo, como se describe en una especificación, contrato o plan) utilizada para determinar qué comportamientos de sistema / software constituyen un fallo.
C) Cómo se resolverán los desacuerdos o conflictos relacionados con las decisiones de clasificación.
D) Cuando la clasificación debe comenzar y terminar dentro del ciclo de vida del proyecto o del producto.
E) Los valores específicos del proyecto, del producto o de la organización que son elegibles para la asignación a atributos de clasificación (véanse ejemplos en la Tabla A.1 y Tabla A.2).
F) Quién asignará valores a los atributos de clasificación enumerados en la Tabla 3 y Tabla 4 para cada defecto y fracaso descubierto, respectivamente.
G) Dónde y cómo se deben mantener los datos de clasificación.(Reid & James, 2009)

Además, se cuenta con una clasificación estructurada de defectos. En la tabla se registran los valores de todos los atributos de defectos. Los valores son de forma informativa. Es de forma más efectiva o común que los valores de los atributos sean registrados a medida que se encarguen del defecto. El estado de este defecto puede ser uno de los siguientes tres estados: Insertado, Detectado o Removido.

Bibliografía

IEEE. (2009). IEEE STANDART classification FOR SOFTWARE ANOMALIES. New York, NY 10016-5997, USA.

Reid, J., & James, E. (2009). CELEBRATIN 125 YEARS OF ENGINEERING THE FUTURE. IEEE Corporate Strategy, 3.

El caso del Aeropuerto de Denver

En la época de los 80 a 90 se dio la construcción del aeropuerto internacional de Denver, Colorado en Estados Unidos. Exactamente este aeropuerto se encuentra a 25 kilómetros del centro de Denver. Queriéndose dar, en este aeropuerto, la implementación de un sistema que se encargaría del equipaje automatizado más grande del mundo. El aeropuerto tendría una capacidad de 50 millones de pasajeros al año.

Como se esperaba tanta cantidad de personas anualmente, claramente debían resolver un problema, el cual sería ¿cómo lidiar con tantos equipajes?, por lo que este sistema lo resolvería realizando eficientemente la entrega del equipaje automatizado entre el check-in para recoger al momento de llegar.

El aeropuerto tenía un estimado de costo alrededor de los $5 millones. pero sucedió algo, antes del final de 1994, el Aeropuerto de Denver encontró con una deuda en bonos de más de $3.8 mil millones debido al problema que fue encontrado en la ejecución del sistema de equipajes. Dando como resultado una suma de $500 millones. En la fecha prevista, todo estaba listo menos un sistema software llamado Sistema Automático de Gestión de Equipajes (Automatic Baggage Handling System -ABHS). Un artículo en Scientific American achacaba el retraso al proceso software, y proponía como solución aumentar el nivel CMM (pero un proceso software mejorado no elimina las incertidumbres). (DeMarco & Lister, 2013)

Un análisis en profundidad habría descubierto razones de otro tipo. Imaginemos el siguiente interrogatorio ficticio al comité de dirección del proyecto:

·                     Pregunta: ¿Por qué no pudo abrir el aeropuerto sin el ABHS?

·                     Respuesta: El software estaba en el camino crítico. Sin este software, no se podía atender a los pasajeros ni un solo día.

·                     Pregunta: ¿Por qué ABHS estaba en el camino crítico?  Porque no se podía mover el equipaje sin el sistema: Tele-carritos, lectores de código de barras, dispositivos de escaneo, descargadores automáticos.

·                     Pregunta: ¿No hay más alternativas para mover el equipaje? Sí. Mozos empujando carritos y el método tradicional en los aeropuertos de cintas transportadoras y camiones pequeños.

·                     Pregunta: Si ABHS no estaba listo a tiempo ¿por qué no se usaron los métodos alternativos? Los túneles de los tele-carritos eran muy bajos.

·                     Pregunta: ¿No se podían rediseñar los túneles? Sí, pero no había tiempo. Cuando se descubrió que ABHS se retrasaba ya estaban construidos, y el tiempo de rehabilitación se estimó mayor que el necesario para perfeccionar el software.

·                     Pregunta: ¿Se sabía de alguna experiencia previa similar? 

·                     Respuesta: El aeropuerto de Munich había instalado un piloto de ABHS parecido.

·                     Pregunta: ¿El equipo visitó el proyecto de Munich? Si es así, ¿qué aprendió? 

·                     Respuesta: Sí. El equipo de Munich asignó 2 años de pruebas y convivencia con el sistema antiguo durante 6 meses para afinar el sistema nuevo. Aconsejaron hacer lo mismo.

·                     Pregunta: ¿La dirección del proyecto siguió este consejo? 

·                     Respuesta: No había tiempo.

·                     Pregunta: ¿El equipo avisó suficientemente del retraso inminente? 

·                     Respuesta: Ya los licitantes advirtieron del riesgo en sus propuestas. Se contrató a BAE Automated Systems porque ofrecían menor plazo. Durante la ejecución, el proveedor advirtió repetidas veces del potencial retraso, al introducirse cada mes nuevos cambios. Todas las partes eran conscientes de que se trataba de hacer un proyecto de 4 años en 2. Todas estas advertencias fueron ignoradas. (Barato, 2012)

En conclusión, este fracaso se dio ya que la gestión de riesgos no se planeó de la mejor forma, en la parte de prueba y pensar que todo funcionaría a la perfección si prueba anterior. Si esto se hubiera previsto a tiempo se pudo retrasar la entrega, pero no se darían tanto gasto como la suma exagerada que se terminó dando por esta falla.

Bibliografía

Barato, J. (15 de 3 de 2012). El caso del Aeropuerto de Denver: Los Hábitos de un Director de Proyectos Eficaz. Obtenido de http://jose-barato.blogspot.com/2012/04/el-caso-del-aeropuerto-de-denver.html

DeMarco, T., & Lister, T. (2013). Waltzing whit Bears: Managing risk on software projects. Addison-Wesley.