Tarea 5

La intención de este tipo de análisis es proveer una oportunidad explícita de aprender de una experiencia de desarrollo e identificar posibles estrategias, tácticas y cambios para hacerlo mejor en el futuro. Este tipo de análisis se realiza independientemente de cuán exitoso haya sido el producto desarrollado, ya que se enmarca dentro de una cultura de mejoramiento contínuo. Se enfoca más a a los procesos de desarrollo que al producto propiamente dicho.

Para ello debe:

1. Leer el capítulo 10  The Postmortem del libro de Watts Humphrey Introduction to the Team Software Process^SM(Addison-Wesley, 2000).

En el texto va a encontrar algunos acrónimos y referencias a formularios que puede ignorar.
• PSP  (Personal Software Process) y TSP(Team Software Process), se refieren a procesos de desarrollo orientados al desarrollador individual y al equipo de desarrollo respectivamente.
• PIP (Process Improvement  Proposal): Es un formulario que permite anotar propuestas para mejorar algún aspecto del desarrollo. Su formato es trivial ("Descripción del problema", "Mejora propuesta"), de modo que puede ignorarla.
• SUMP, SUMQ: Son formularios preparados  para reportar la productividad (SUMP) y la calidad (SUMQ) estimada y efectiva del desarrollo. Son demasiado detallados para nosotros. Aplique el guión con lo que tenemos.
• PEER: Puede ignorar las actividades relacionadas con el formulario PEER; esta encuesta la aplicaremos en clase en la semana 12.

 
2. Aplicar el modelo que presentó el Prof. Nagib Callaos para estimar cuál era la estimación del modelo en cuanto a tiempo, esfuerzo y número óptimo de desarrolladores para Delta Pensum 2.2. Incorpore los multiplicadores que considere pertinentes y reporte tanto la estimación ideal (sin multiplicadores) como la estimación factible (con multiplicadores).

En realidad este paso debió haberse hecho al inicio del desarrollo de DP 2.2, pero cómo no lo hicimos, remendaremos la falta ahora. Recuerde que para estimar:
1. Partimos del número de pantallas y reportes que se desarrollarán/modificarán,
2. Determinamos el tamaño estimado del producto en líneas de código y,
3. Calculamos el esfuerzo en horas-persona, tamaño óptimo del equipo y tiempo calendario necesario para el desarrollo, con los multiplicadores de ajuste que sean pertinentes.


El Prof. Callaos expuso y combinó dos modelos: el modelo de puntos de función y el modelo COCOMO intermedio aplicado a desarrollos orgánicos. El modelo COCOMO fue creado por B. Boehm (Software Engineering Economics, Prentice-Hall, 1981) y se basa en las siguientes fórmulas:

1. esfuerzo (medido en meses-persona) = 2.4 *(KLOC)^1.05   // recuerdo que KLOC es el tamaño del sistema en miles de líneas de código fuente.
2. tiempo_calendario (medido en meses) = 2.5 * esfuerzo^0.35
3. tamaño_óptimo_equipo (medido en personas) = esfuerzo / tiempo_calendario


La fórmula del esfuerzo se ajusta de acuerdo a las circunstancias del proyecto, multiplicándola por factores de ajuste (tambien llamados multiplicadores). Al revisar los apuntes de la clase del Prof. Callaos, me he dado cuenta que no incluyó los multiplicadores. Ellos pueden encontrarse en el  libro de B. Boehm .  En la nomenclatura de Boehm, ustedes han desarrollado un proyecto orgánico. De los 15 multiplicadores del modelo COCOMO intermedio, pueden resultarnos relevantes:

• CPLX, ajusta por la complejidad del sistema. Según los parámetros establecidos por Boehm, Delta Pensum es de complejidad alta y por ende el valor del multiplicador es 1.15.
• STOR: ajusta por restricciones al espacio de memoria ocupado por el sistema y sus datos. Me parece un poco exagerado argumentar que DP 2.2 tiene restricciones altas en este sentido (En DP 2.3, esto puede cambiar), pero si fuera el caso el valor del multiplicador no pasaría de 1.05.
• ACAP: ajusta por la calidad del análisis realizada por el equipo. Los posibles valores para este multiplicador son 1.46 (muy bajo), 1.19 (bajo). La falta de calidad se refleja en problemas/restricciones de comunicación con los usuarios y entre los analistas y los programadores, un elevado número de defectos atribuibles a fallas en el análisis de requerimientos o a falta de correspondencia entre análisis, diseño y codificación.
• AEXP: ajusta por falta de experiencia de los miembros del equipo en el desarrollo de aplicaciones del tipo a desarrollar. En el caso de DP, el dominio es sistemas de apoyo de decisión en ambiente universitario.  Si la experiencia es de menos de cuatro meses de experiencia se considera que la experiencia es muy baja y el valor del multiplicador es de 1.29.
• PCAP: ajusta por la habilidad y nivel de experticia de los programadores del equipo. Los posibles valores son: 1.42 (muy bajo), bajo (1.17), normal (1.00), alto (0.86).
• VEXP: ajusta por la experiencia previa del equipo en la máquina virtual  del desarrollo(es decir, hardware, sistema de operación y base de datos).  En el caso de que la experiencia promedia sea menos de un mes, el valor del multiplicador es 1.21, en caso de hasta 4 meses de experiencia en promedio, 1.10 , y si el promedio es de más de año 0.90.
• LEXP: ajusta por la experiencia en el lenguaje de programación (Java), 1.14 (menos de un mes de experiencia promedio), 1.07 (hasta cuatro meses), 0.95 (más de un año).
• MODP: ajusta por el  uso y dominio de las técnicas de desarrollo, como uso de control de configuración, modelo de uso, modelo conceptual, modelo de interacción. Los valores pueden ser 1.24 (ningún uso de estas técnicas), 1.10 (uso experimental, de novato).
• TOOL: ajusta por el uso de herramientas, 1.24 (sólo se usan herramientas básicas como editor de texto, compilador y debugger),  1.10 (herramientas básicas + librerías).
• SCED: ajusta por compresión en el calendario de desarrollo. Si se estima (por el modelo) que un proyecto se puede desarrollar en 4 meses y se exige hacerlo en 3 meses, hay una compresión al 75% [por cierto este es la compresión máxima considerado factible). Los valores son: 1.23 (compresión al 75%), 1.08 (compresión al 85%), 1.04 (si se alarga el tiempo en un 30% --luce paradójico, pero recuerden lo que significa apartarse del valor nominal), 1.10 (alargar el tiempo en más del  60%).


Una explicación introductoria a COCOMO, el modelo de Boehm también se encuentra en R. Pressman: Ingeniería de Software: Un Enfoque Práctico (Cuarta edición, McGraw-Hill, 1997, p. 81-83).

Los dos libros citados se encuentran en la biblioteca de la universidad.
 
 

 
3. Aplique el modelo que presentó el Prof. Nagib Callaos para medir la productividad de su empresa en el desarrollo de Delta Pensum 2.2:

En este caso:
1. Medimos el tamaño del producto logrado, distinguiendo entre el número de líneas de código agregadas, eliminadas y modificadas. En lel modelo más simple el tamaño del producto logrado se obtiene sumando esos tres números.
2. Utilizando los datos reales de horas-persona y número de personas involucradas en el desarrollo, obtenemos las medidas de productividad.

 
4. Compare tanto la estimación del modelo del Prof. Callaos, como su propia estimación inicial de tiempo y esfuerzo contra el tiempo y esfuerzo invertido. ¿Qué puede concluir a partir de estas comparaciones?

 
5. Revisen sus bitácoras y reporten el número de defectos que encontraron o corrigieron por requerimiento implementado, distinguiendo entre los defectos que existían previos a su desarrollo y los inyectados durante el desarrollo. Reporte adicionalmente el porcentaje de defectos corregidos contra el número de defectos encontrados o corregidos. Si tiene información suficiente para hacerlo, grafique dos curvas, la curva de defectos encontrados y la curva de defectos corregidos, ambas contra el tiempo de desarrollo. A partir de estas mediciones, ¿qué puede concluir? A  partir de su experiencia y el número de defectos encontrados que subsisten por cada mil líneas de código (KLOC) qué puede concluir sobre la calidad de su proceso de desarrollo? ¿Cuáles requerimientos fueron más complejos de desarrollar, juzgando por el número de defectos asociados a ellos? ¿Corresponden a los que se llevaron más esfuerzo? ¿Por qué fue así? ¿Hay clases asociadas con más defectos?

 
6. Revise la lista de riesgos contenidas en el índice del libro de Capers Jones (Assessment and Control of Software Risks) previamente repartidas a cada empresa y los contenidos en el índice del libro de C. Clarr Team Leader's Problem Solver y determine cuáles fueron los riesgos más pertinentes que vivió y qué tan exitosa fue la empresa en mitigar los riesgos. ¿Se conserva esta lista de riesgos para Delta Pensum 2.3?

 
7. Aplique el guión PM1 del capítulo 10 del libro citado de Watts Humphrey.

Si lo desea o si lo considera pertinente, puede consultar la descripción de los requerimientos de Delta Pensum 2.3, el cuál será el único incremento a desarrollar el próximo trimestre.

---

Esta página fue creada por el Prof. Alejandro Teruel el 15 de noviembre de 2000.

Ultima actualización: 16 de noviembre de 2000.

Por favor dirija sus comentarios al Prof. Alejandro Teruel.