En repetidas ocasiones que he estado en pláticas o conferencias relativas al método de medición de tamaño funcional (FSM) COSMIC, se ha preguntado si aplica para el método PROBE de PSP o que porqué no usar PSP en lugar de COSMIC. Tratando de atender estas preguntas se escribe este artículo.
Surgimiento y Concepto de PSP
Después de la II Guerra mundial (1945), el enfoque en calidad de las organizaciones (incluidas las de desarrollo de software) estaba fundamentado en las pruebas. Fue hasta los 70’s y los 80’s que E. Deming y J.M. Juran convencieron a la industria de USA de enfocarse en la forma en que las personas realizan su trabajo. Sin embargo, la industria de software siguió fundamentando la calidad de las piezas de software en las pruebas.
El primer gran paso hacia el enfoque propuesto por Deming y Juran en el área de software se dio con las inspecciones de software propuestas por Michael Fangan (1976), otro gran paso se dio en 1987 con la introducción de Capability Maturity Model (CMM).
Es fundamental entender que el enfoque principal del CMM y hoy Capability Maturity Model Integration (CMMI) for Development es el sistema de administración, soporte y asistencia que se proporciona a los ingenieros de desarrollo de software [1], en otras palabras su enfoque es en mejorar la calidad de los desarrollos de software, a través de mejorar el desempeño de los procesos de una organización relacionados con la construcción de software. El SEI ha documentado efectos sustancialmente positivos por el uso de de CMM y CMMI.
En 1995 surge el Personal Software Process (PSP), que fue generado por Watts Humphrey y busca extender los beneficios de la mejora de procesos organizacionales a las personas que realizan el trabajo, el PSP se enfoca en las prácticas de trabajo individuales de los ingenieros de desarrollo de software (proceso personal), la estructura básica conceptual del PSP se muestra en la Figura 1.
Se inicia con un establecimiento de los requerimientos, después se realiza una planeación, posteriormente el diseño, la codificación, etc. ¿Qué es lo que lo hace diferente? Que durante todo el ciclo se generan “scripts de procesos” los cuales define los pasos para cada fase, también los “logs” y las formas de registro y almacenamiento de información, así como los estándares que deben de seguir los desarrolladores, es decir, son guías de lo que se debe de hacer en cada fase del ciclo definido (checklist).
Pero quizá lo más relevante de todo lo que se ha mencionado, y la fortaleza del PSP es el registro y almacenamiento de información ya que es lo que permite la mejora la productividad de las personas, mejora en los hábitos de programación, así como una detección temprana de defectos y riesgos.
Visto de otra manera lo que establece PSP es un “proceso de medición”, un proceso de medición es como lo que hace un área contable, cada día van identificando las facturas que se pagan, los pagos que se cobran, las pólizas, etc.
Si esto se hace cada mes, lo que algunas veces sucede, se acumulará más trabajo y la visibilidad de lo sucedido será con corte cada mes, por lo que si existiera algún riesgo durante el periodo, no se identificaría, hasta que se contabilizara todo.
Si esto lo extendemos a un año se acumula más trabajo y la posibilidad de poder tener visibilidad de lo sucedido cuando ya no se pueda hacer nada. Lo mismo sucede en el desarrollo de proyectos de software.
Estimación de Tamaño y Recursos con PSP (Método PROBE)
Dentro de la fase de planeación (Figura 2) se establece la estimación de tiempo y recursos, el método que propone PSP para realizar la estimación tanto de tamaño como de esfuerzo es el método PROBE (PROxy Based Estimating), el cual se basa en la utilización de objetos base -denominados proxys- para estimar el tamaño más probable de un producto.
Figura 1. Estructura Conceptual PSP
Como muchos mecanismos que utilizan elementos cuantitativos, establece que la precisión de los estimados depende del detalle de conocimiento sobre los requerimientos del trabajo a realizar, por eso incluye una etapa de diseño conceptual que se toma como base para estimar tanto el tamaño del producto como los recursos, considerando la siguiente suposición: “La correlación entre el tamaño del programa y el tiempo de desarrollo es ligeramente moderada entre equipos de ingenieros/desarrolladores y organizaciones. Sin embargo, de forma individual es generalmente alta”. [1]
Para realizar la estimación de tiempo, un desarrollador determina los tipos de objeto requeridos para desarrollar una pieza de software, con base en datos históricos de objetos similares – el método PROBE establece que se requieren datos de al menos tres proyectos- se determina el tamaño (LOC) más probable del tipo de objeto de acuerdo a distintos rangos, con los tamaños estimados de los objetos a desarrollar y utilizando una regresión lineal, se determina la cantidad de código que se planea desarrollar.
Reflexión: Hasta aquí todo suena bien, sin embargo, en la documentación PSP [1] se menciona una suposición que si bien cuando se creó PSP pudo hacer sentido, hoy podemos considerarla errónea: “como el tamaño de un objeto es función del estilo de programación, el método PROBE enseña a los ingenieros cómo utilizar los datos generados por ellos mismos para generar rangos de uso personal”.
Porqué se considera errónea, la suposición se basa en el supuesto de que se estima el tamaño del software a producir con base a líneas de código (LOC), sin embargo después de mucho avance de la disciplina Ingeniería de Software, se reconoce que esta no es una medida adecuada del tamaño de una sistema, en virtud de que no es estándar y depende de la tecnología, por lo que no puede ser utilizada como parámetro de comparación.
Aunado a lo anterior, hoy sabemos que solamente existe un estándar cuantitativo para determinar el tamaño de la funcionalidad del software, se denomina tamaño funcional (ISO/IEC 14143) y se determina a través de distintos métodos estándares, entre los que se encuentra COSMIC como el único método de segunda generación (referencia blog).
En lo que se refiere a la estimación de recursos, el método PROBE recomienda utilizar una regresión lineal considerando el tamaño (la cantidad de código) estimado y el esfuerzo real (en alguna unidad de tiempo como meses, días u horas-persona) de acuerdo a los datos históricos personales, también recomienda al menos tres proyectos siempre y cuando se demuestre una correlación razonable entre los datos.
Una vez estimado el tiempo total del proyecto, se establece con base en los datos históricos el esfuerzo por fases, y se detalla por mes, semana o día, para proyectos grandes PSP introduce también el uso del método de Earn Value.
Aquí cabe mencionar que uno de los problemas más grandes para la realización de estimados es el contar con datos históricos, Morgenshtern [2] menciona que los modelos algorítmicos necesitan datos históricos, y muchas organizaciones no cuentan con esta información. Adicionalmente, recolectar estos datos implica un costo muy alto en dinero y tiempo.
Figura 2. Fase DE planeación en PSP
Mejorando PSP
Si bien la técnica PSP utiliza las LOC como unidad principal de medida, también indica que “cualquier unidad de medida puede ser utilizada, siempre y cuando proporcione una correlación razonable entre el tiempo y el tamaño del producto” [1].
«Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.» – Bill Gates.
P. Bourque [3] menciona que los requerimientos definen el alcance o tamaño del producto, el tamaño determina el esfuerzo y éste influye en la duración; también menciona que la relación entre esfuerzo y tiempo no es lineal.
Aunado a lo anterior resulta lógico pensar que es mejor utilizar un estándar generalmente aceptado para determinar una unidad de medida y poder realizar comparaciones.
Por estas razones, se considera que los resultados que se obtienen con PSP pueden ser visiblemente mejorados si se utiliza un mecanismo estandarizado de dimensionamiento de tamaño de software, que para este caso se puede recomendar el único estándar de segunda generación de tamaño funcional; método COSMIC (ISO/IEC 19761), como se muestra a continuación.
Figura 3. Método PROBE utilizando COSMIC
Conclusión
PSP en un proceso que se enfoca en mejorar las prácticas de trabajo individuales, a través de la definición y utilización de un “proceso de medición” basado en LOC.
Sin embargo, existen estudios que demuestran que la correlación entre LOC y esfuerzo no es muy adecuada, en virtud de que las LOC son dependientes de las distintas tecnologías, así como de la experiencia de programación de los desarrolladores, además de no ser un estándar.
Por lo anterior, se considera que los resultados de PSP pueden ser mejorados si se utiliza un mecanismo estándar de medición como el método COSMIC, en virtud de ser un método que determina unidades de tamaño estándares generalmente aceptados, y en particular COSMIC por ser el único estándar para medición de tamaño funcional de segunda generación, el cual presenta algunas ventajas sobre los métodos de la primera generación.
En relación a las preguntas planteadas originalmente respecto si el método COSMIC se puede utilizar con el método PROBE de PSP, la respuesta es SI, de hecho se complementan.
Respecto de la pregunta de ¿porqué no usar PSP en lugar de COSMIC?, la respuesta es porque no son excluyentes, PSP es un proceso y COSMIC es estándar de medición de tamaño de la funcionalidad del software.
Referencias
[1] Watts S. Humphrey (2000), “The Personal Software Process SM (PSPSM), Technical report CMU/SEI-2000-TR-022, ESC-TR-2000-022, November 2000.
[2] Morgenshtern, O., T. Raz, and D Dovir (2007), “Factors affecting duration and effort estimation errors in software development projects,” Information and Software Technology, vol. 49, no. 8, August 2007, pp. 827-837.
[3] Bourque, Pierre, S. Oligny, A. Abran, B. Fourrnier. 2007. « Developing Project Duration Models in Software Engineering ». Journal of Computer Science and Technology, vol. 22, p. 348-357.