Articulo Sa Pfa Cocomo

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

Calculador de puntos de función y COCOMO Generalidades del proyecto Carlos Valdez Jorge Yass Gustavo Ayapan Adie Juárez

200217159 200413054 200412831 200412978

08/01/2009

This article shows the general on the planning, development and launch of an application able to calculate and estimate costs, resources and time of software projects. The main idea is to automate manual processes and calculations that involve some risk of not being accurate. Thus, the program becomes a useful tool for systems analyst, and the general professional to make estimates.

1. Introducción En la actualidad, se hace de imprescindible importancia la estimación del tiempo de desarrollo de un proyecto, porque una mala planificación de este tiempo, puede conllevar a presentarle fechas apresuradas a los clientes y por tanto a entregar un software que no tendría la calidad deseada ni mínima a cumplir. En el ámbito de desarrollo de software, existen métodos para estimar dicho tiempo y recursos, algunos empíricos, además de algunos métodos más objetivos. La técnica más utilizada actualmente es la de Puntos de Función (es un método empírico), esta consiste en utilizar registros de proyectos anteriores, para tratar de hacer una proyección del proyecto actual en cuestión de tiempo y gastos. Sin embargo el cálculo por esta técnica es muy tediosa sobre todo cuando se tienen grandes registros o estos son demasiados. Nuestro proyecto titulado PFCalculator, pretende reducir ampliamente el tiempo invertido en esto, simplificando en gran manera el proceso, resumiendo a ingresar algunos de los parámetros utilizados en el cálculo de puntos de función. Sin embargo, los puntos de función, por si solos, no nos dan mayor información. Es necesario utilizarlos en combinación con otros métodos de estimación, como COCOMO, el cual nos permite estimar el esfuerzo, tiempo y personal necesario para realizar un proyecto, basándose en los puntos de función. Es por ello que nuestro programa también puede hacer estimaciones utilizando COCOMO, lo que le da un matiz de herramienta indispensable al analista de sistemas.

2. Descripción de la aplicación Este es un software que estima los puntos de función para los módulos de un proyecto, que puede almacenar dichos módulos por proyecto, y que puede almacenar los puntos de función de cada módulo. Además, permite que se guarde información adicional y futura sobre los módulos, como por ejemplo, el tiempo de desarrollo, de corrección de fallas, etc. También, permite en base a los puntos de función, estimar mediante el modelo constructivo de costos (COCOMO) el esfuerzo requerido en meses/hombre, el tiempo de desarrollo en meses, y el tamaño del equipo que se necesitaría para realizar el proyecto.

3. Estimaciones de recursos y costos Utilizando el método de puntos de función, se realizo un cálculo (someramente temprano) sobre la estimación de puntos de función ajustados que nos llevaría el proyecto, para luego, estimar el esfuerzo, tiempo y tamaño del equipo para desarrollarlo. Dicha estimación nos dio un resultado de 335 puntos de función . A continuación, se uso el modelo orgánico y la versión básica de COCOMO para estimar el esfuerzo requerido (se eligieron porque el proyecto es pequeño, y no tiene una complejidad alta) y nos dio un resultado (en meses) de 9 aproximadamente. Este dato fue tomado como erróneo por un margen muy alto, ya que elegimos utilizar TIMEBOXES de una semana, y la entrega del proyecto se acordó en 3 semanas (2 originalmente) por lo que el desarrollo no iba a tomar ni siquiera un mes. Luego, se estimo el tamaño del equipo, aquí el método nos dio un resultado de 3.22, el dato fue tomado como 4, lo que estuvo bastante bien, dado que en el equipo de desarrollo habíamos 4 personas. En resumen, sabíamos que por los TIMEBOXES teníamos que entregar el proyecto en 3 semanas, pero se hicieron las estimaciones correspondientes para tenerlas como referencia. Sin duda, la elección de la versión Detallada de COCOMO nos hubiera presentado un tiempo más ajustado a la realidad.

4. Estimación de Riesgos Elemento de Control Análisis

Riesgo

del 45% de

2

Desarrollo

Incumplimiento de 40% los tiempos de entregas establecidas.

Trabajo atrasado 2 durante el desarrollo de la iteración.

Desarrollo

Mal diseño de la 25% base de datos

Almacenamiento o consulta de datos con cierto grado de dificultad.

Desarrollo

Mala integración de 20% los módulos con la base de datos

3

Cualquier fase

Mala comunicación 50% entre el equipo de desarrollo

El proceso de 2 codificación puede no tener mayor avance.

Análisis

Mal entendimiento 60% de los requerimientos

No se obtiene las 2 salidas esperadas

Mal diseño cronograma actividades

Probabilidad Indicadores

Categoría PSGR Realizar un buen estudio de las historia de usuario y capacidades del equipo de desarrollo. Mediante las reuniones diarias se determina el estado de la iteración, y de algún modo acelerar el ritmo de trabajo sin comprometer la calidad del producto. Evaluar las posibles consultas que se realizaran en la aplicación. Se realizaran pruebas para verificar la conexión y el manejo de los datos antes de pasar a producción. Incentivar al equipo de desarrollo para que exponga sus dudas. Permitir una comunicación mayor y fluida entre el equipo y el cliente.

5. Requerimientos

El siguiente es el diagrama entidad relación utilizado en la base de datos:

Los requerimientos en base a la metodología que utilizamos que fue XP, los obtuvimos por medio de las historias de usuario, entre los requerimientos de más peso tenemos: La aplicación debe trabajar en base a resultados de SAPF y CP y debe de ser capaz de calcular puntos de función ajustados (PFA). Se requiere almacenamiento de los resultados obtenidos. Se requiere almacenamiento de datos adicionales a las PFA, tales como horas de desarrollo, numero de fallas, etc. Se requiere que la aplicación pueda realizar estimaciones en base a COCOMO. Se requiere que la aplicación sea intuitiva, sencilla de utilizar, y lo más importante, exacta en los cálculos que realice. Requerimientos como los FURPS son deseables, pero no críticos, exceptuando quizá la confiabilidad, como ya lo mencionamos.

6. Arquitectura Diagrama de clases:

7. Metodología Para el desarrollo del proyecto “Calculador de puntos de función y COCOMO” se decidió utilizar la metodología de desarrollo ágil XP, por las siguientes razones (considerando que no tenemos mucho tiempo): Busca la sencillez y simplicidad Permite iteraciones rápidas a través del uso de los spikes Se programa en parejas Permite una comunicación total La documentación no es exhaustiva Nuestro equipo de trabajo es pequeño (4 programadores) La fecha de entrega es fija (08/01/2009) Los requerimientos no están completamente claros, y algunos se modifican a través del desarrollo.

8. Iteraciones Iteración 1 – Cálculo de PFA: Todo lo relativo a las fórmulas, maneras de ingreso de datos y cálculos de puntos de función. Diseño de interfaz Diseño de algoritmo de cálculo de los SAPF Implementación del algoritmo Prueba de funcionalidad

Iteración 2 – Almacenamiento y Consulta: conlleva el diseño e implementación de una pequeña base de datos, métodos para almacenar y consultas.

Segundo prototipo

Diseño o modificación de alguna interfaz ya hecha Diseño de un modelo relacional Implementación del modelo relacional en una base de datos Implementación de métodos para almacenar la información Iteración 3 – Estimaciones con COCOMO: implementación de versiones y modelos, con sus ajustadores y formulas correspondientes. Interfaces de selección de versiones y modelos de COCOMO Diseño del algoritmo de COCOMO Implementación del algoritmo de COCOM Evolución del prototipo Primer prototipo

Prototipo Final

9. Pruebas Se realizaron pruebas de funcionalidad, al término de cada iteración para comprobar que los cálculos eran realizados exactamente y que se seguía de manera fiel los métodos de estimación utilizados.

10.

Discusiones

La aplicación queda como base para un posterior proyecto que gestione de manera completa la estimación de los proyectos de software, ofreciendo variadas técnicas y métodos, para que con semejante abanico de posibilidades, el usuario (el analista de sistemas en este caso) pueda tomar decisiones más exactas y mejor ajustadas a la realidad, con menos incertidumbre y más seguridad. Los métodos, como tales, no pueden ser tomados como una referencia absoluta e inamovible en cuanto a sus resultados. La experiencia e intuición de los analistas experimentados sigue siendo la mejor estimación posible, sin embargo, es bueno ayudarse teniendo una referencia comprobada como buena a través de cientos de proyecto de software, para la realización de las estimaciones, y es aquí donde entra en juego nuestra aplicación.

Conclusiones En la actualidad es muy utilizada la técnica de puntos de función, sin embargo esta técnica aunque en primer plano parece simple, en la realidad resulta tremendamente tediosa, por lo cual es necesario que para poder aplicar esta técnica de manera correcta y ahorrar tiempo se debe de automatizar el proceso, que es el objetivo principal del proyecto. Aunque las técnicas de estimación son utilizadas y a menudo producen resultados acertados, la realidad es que este proceso depende mucho de la experiencia del que lo calcula, es decir que su criterio siempre es necesario, por lo que los métodos de estimación tienden a ser subjetivos.

El formar parte de un equipo que se debe de auto organizar y auto dirigir es una experiencia nueva y enriquecedora, da la pauta a que se puedan correr ciertos riesgos que sabemos serán absorbidos por el equipo entero, pero que a la larga, nos dará experiencia sobre lo que hicimos bien y lo que no, ayudándonos a mejorar para los próximos proyectos que vengan.

Sobre los autores Carlos Valdez es estudiante de 10º semestre, se especializa en el diseño de sitios y páginas Web, programación en Java, y se maneja con soltura en entornos GNU/Linux. Pueden contactarlo a través del mail [email protected]. Gustavo Ayapan es estudiante de 10º semestre, se enfoca en el desarrollo a través de productos Microsoft, y una de sus aficiones son las redes sociales y el chat. Pueden contactarlo a través del mail [email protected]. Audie Juárez es un estudiante de 10º semestre, aficionado a los automóviles y al diseño web, con altos conocimientos sobre programación en Visual Basic, GNU/Linux, etc. Pueden contactarlo por el mail [email protected]. Jorge Yass es estudiante de 10º semestre, es aficionado a jugar ajedrez y a programar, su lenguaje favorito es Turbo Pascal y no teme que lo tachen de obsoleto. Pueden contactarlo al mail [email protected].

Referencias y material consultado Guía sobre la elaboración de un artículo de proyectos de software. Ing. Luis Espino. Contenido de la clase magistral y laboratorio del curso de Software Avanzado, escuela de vacaciones Diciembre 2008. Ing. Luis Espino y Aux. Mario Bautista. Pressman, Roger. S. Ingeniería del Software, McGraw Hill, 6ta edición.