Modelo de Gestión de Proyectos Software:
Estimación del Esfuerzo de Desarrollo
Marcela P. Varas C.
Depto. Ing. Informática y Cs. de la Computación
Universidad de Concepción
e-mail:
mvaras@inf.udec.cl
Noviembre 1995
Abstract.

La gestión de un proyecto es una tarea vital para el éxito del mismo. Dentro de la gestión, la planificación juega un importante rol, debido a que es en esta etapa donde se debe hacer las asignaciones de los recursos disponibles, para lo que es necesario estimar costos y plazos para el proyecto a realizar.

En este trabajo se propone un método para realizar estimaciones tempranas del esfuerzo de desarrollo, en términos de horas hombre a partir de la especificación del software a realizar. El método en cuestión se basa en diversas propuestas para apoyar esta problemática, adaptándolas y generando a partir de ellas un mecanismo adecuado a la realidad de la región.

keywords:

Modelos de Gestión, Planificación de Proyectos Software, Estimación de Esfuerzo, Métricas del Tamaño, Modelos de Estimación, Estimación Temprana, Métricas Orientadas a la Función.

1. Introducción

La planificación de un proyecto se basa en una buena estimación del esfuerzo requerido para realizarlo, y para apoyar esta difícil tarea, se han desarrollado varios métodos que han encontrado aceptación comercial en forma creciente en la planificación del desarrollo de software.

La mayoría de estos métodos incluyen modelos empíricos de estimación y poseen como variable manejadora del costo principal el tamaño de la aplicación a desarrollar, lo que es suficientemente difícil de estimar como para que se justifique pensar en automatizar o apoyar fuertemente esta tarea con la generación de un método fácil de usar.

Por otro lado, aquellos modelos que fueron desarrollados con base empírica, pueden carecer de validez en ambientes de desarrollo distintos a aquel del que se obtuvieron los datos.

Para el caso de los modelos basados en líneas de código, se puede observar que en la actualidad, las herramientas de desarrollo proveen la capacidad de disminuir substancialmente el esfuerzo de codificación, pues la tendencia actual ya no es codificar, sino generar código. Por el lado de las técnicas basadas en el enfoque de puntos de función, el problema radica en que la estimación sólo puede realizarse con un diseño externo acabado de la aplicación, y si consideramos la utilización de herramientas de generación de código (CASE o 4GL's), a la altura en que por fin se puede realizar la estimación ya se ha consumido la mayor cantidad del esfuerzo del desarrollo (es decir, si antes el esfuerzo se centraba en la fase de construcción vía codificación en algún lenguaje de programación, hoy el esfuerzo se centra en las fases de diseño, ya que la codificación se ve fuertemente asistida por herramientas automatizadas), por lo que la estimación ya no es tan útil.

Todos los puntos mencionados anteriormente, dificultan que la utilización de modelos de gestión sea una práctica generalizada en los administradores de proyectos de desarrollo de software.

Situación Actual

En la mayoría de las empresas donde se produce software para apoyar el negocio (es decir, que el giro de la empresa no es desarrollo de software), se utilizan técnicas de gestión que apoyan débilmente a la planificación, consistente generalmente en la utilización de software que facilitan la generación de planes y cartas, diagramación del avance, etc. Estos productos software parten de la base de que los recursos a consumir son conocidos a priori.

Por otro lado, dada la carencia de este apoyo, los administradores se basan principalmente en técnicas de descomposición, con la añadidura de un juicio experto.

En empresas que se dedican exclusivamente al rubro de la informática, existe una cultura más arraigada en el sentido de la necesidad de formalizar los mecanismos de estimación de esfuerzo. Se utilizan principalmente métricas orientadas a la función, aunque sin utilizar modelos empíricos de estimación. Las medidas de las aplicaciones son ponderadas por un índice de productividad de la organización para estimar el esfuerzo.

2. Modelos de Estimación

.

Líneas de código

La métrica de tamaño tradicional para estimar el esfuerzo de desarrollo y productividad ha sido LOC (Lines Of Code) o SLOC (Source Lines Of Code). Se han propuesto varios modelos de estimación, la mayoría de ellos son funciones de las líneas de código o de las miles de líneas de código que tendrá el software a desarrollar. Generalmente, el modelo de estimación de esfuerzo consiste de dos partes. La primera provee una base de estimación como una función del tamaño del software, y es de la siguiente forma:

donde E es el esfuerzo estimado en meses hombre, A, B y C son constantes y KLOC es el tamaño estimado del sistema final en miles de líneas de código. La segunda parte del modelo modifica esta estimación en base a cuantificar la influencia de factores de ambiente, por ejemplo la utilización de diferentes metodologías, habilidad del equipo de desarrollo y restricciones de hardware.

La definición de KLOC es importante si se quiere comparar los distintos modelos que se han propuesto en la literatura. Algunos de ellos incluyen líneas de comentarios, y otros no. Del mismo modo, la definición del esfuerzo estimado E es también importante., ya que E puede representar sólo el esfuerzo de codificación, o en el otro extremo, el esfuerzo total del análisis, diseño, codificación, test y mantención. Por estas razones, comparar estos modelos se torna complejo.

Los principales problemas de utilizar líneas de código como métrica para estimación del esfuerzo son la falta de una definición universal de línea de código, su dependencia con el lenguaje de desarrollo y la dificultad de estimar en fases tempranas del desarrollo la cantidad de líneas que tendrá una aplicación.

Puntos de función

El análisis por puntos de función es un método para cuantificar el tamaño y la complejidad de un sistema software en términos de las funciones de usuario que este desarrolla (o desarrollará). Esto hace que la medida sea independiente del lenguaje o herramienta utilizada en el desarrollo del proyecto [1].

El análisis por puntos de función está diseñado para medir aplicaciones de negocios; no es apropiado para otro tipo de aplicaciones como aplicaciones técnicas o científicas. Esas aplicaciones generalmente median con algoritmos complejos que el método de puntos de función no está diseñado para manejar[5].

El enfoque de puntos de función tiene características que permiten superar los principales problemas de utilizar líneas de código como métrica del tamaño del software. Primero, los puntos de función son independientes del lenguaje, herramientas o metodologías utilizadas en la implementación; por ejemplo, no tienen que considerar lenguajes de programación, sistemas de administración de bases de datos, hardware, o cualquier otra tecnología de procesamiento de datos[4]. Segundo, los puntos de función pueden ser estimados a partir de la especificación de requisitos o especificaciones de diseño, haciendo posible de este modo la estimación del esfuerzo de desarrollo en etapas tempranas del mismo. Como los puntos de función están íntimamente relacionados con la declaración de requisitos, cualquier modificación a ésta, puede ser reflejada sin mayor dificultad en una re estimación.

Tercero, como los puntos de función están basados en una visión externa del usuario del sistema, los usuarios no técnicos del software poseen un mejor entendimiento de lo que los puntos de función están midiendo. El método resuelve muchas de las inconsistencias que aparecen cuando se utiliza líneas de código como métrica del tamaño del software.

En resumen, los puntos de función aparecen con ventajas substanciales por sobre las líneas de código, para fines de estimación temprana del tamaño del software, y por ende, del esfuerzo de desarrollo. Además es una medida ampliamente utilizada, y con éxito, en muchas organizaciones que desarrollan software en forma masiva.

Puntos de Característica.

Debido a que el análisis por Puntos de Función fue diseñado para software de negocios y no es fácil de generalizar a aplicaciones científicas, de tiempo real y otras, Caper Jones [18] propuso ampliaciones a este método, generando una métrica que denominó Puntos de Característica. Ésta da cabida a aplicaciones cuya complejidad algorítmica es alta.

Este método considera los mismos elementos que considera Albrecht [1] en su análisis por puntos de función, sólo que añade la variable "número de algoritmos" y elimina los niveles de complejidad, así, cada cuenta es pesada por un valor único para ese componente (es decir, se le asigna complejidad media).

3. Estimación Temprana del Tamaño del Software.

Para realizar la planificación de un proyecto software, es necesario poseer una estimación certera del esfuerzo necesario para el desarrollo lo más temprano posible, idealmente, con sólo la etapa de especificación de requisitos cubierta.

Se tiene que a esta altura del desarrollo del software, difícilmente se puede realizar una estimación certera de la cantidad de líneas de código que tendrá la aplicación, ya que en este nivel no tiene por qué estar decidida la herramienta de desarrollo. Sólo se podría entrar a realizar una estimación certera en los comienzos de la etapa de construcción, con un diseño acabado. Por otro lado, la determinación de los Puntos de Función podría realizarse a partir de la especificación de requisitos, pero los factores correctores según la complejidad de la aplicación pueden estimarse con certeza una vez que se ha entrado de lleno a la etapa de diseño. Si bien es posible realizar la estimación de puntos de función en fases anteriores que la estimación de LDC, se desearía poder realizar una estimación certera en base únicamente a la especificación de requisitos.

De una "buena" especificación de requisitos se pueden obtener las características de la aplicación a desarrollar, antes de que comience el desarrollo del software. Si a partir de estas características se puede obtener una estimación del tamaño del software, se tendría una estimación temprana del tamaño del mismo.

De este modo, al contar con una estimación temprana del tamaño de lo que se desea desarrollar, se puede realizar una estimación del esfuerzo en etapas tempranas del desarrollo. Esto es debido a que el tamaño del software es la variable manejadora de costo principal del desarrollo.

Una estimación temprana sería útil para generar la planificación del proyecto, la cual podría corregirse con el apoyo de las técnicas basadas en los puntos de función o líneas de código en etapas más avanzadas del desarrollo.

4. Métrica para Estimación Temprana del Tamaño del Software.

Para poder realizar una estimación temprana, se propone la utilización de la métrica de puntos de función modificada.

Este método consiste en clasificar, listar y contar a partir de la especificación de requisitos todos los componentes, desagregados en:

a. Entradas Externas.

b. Salidas Externas

c. Archivos Lógicos

d. Consultas.

En el método original además se consideraba la clasificación Archivos de Interfaces externos, los cuales son utilizados para la comunicación entre aplicaciones. Debido a que a esta altura del desarrollo difícilmente se puede contar con esta información, se ha eliminado. En caso de ser obvia la necesidad de contar con un archivo de interface, éste debe cuantificarse como un archivo lógico más.

Para resolver el problema de determinar la complejidad asociada a cada componente de la aplicación (difícil de conocer en esta etapa), se ha optado por asignar a todos los componentes una complejidad promedio. Esta es una aproximación válida, debido a que normalmente "en media" las aplicaciones son de complejidad promedio, teniendo sólo unos pocos componentes de complejidad simple y otros complejos.

De este modo, la fórmula para obtener los puntos de función para estimación temprana (PFET) es la siguiente:

Donde

PFET : Puntos de función para estimación temprana.

IN : Número de Entradas Externas

OUT : Número de Salidas Externas

INQ : Número de Consultas

FILE : Número de Archivos Lógicos

ACP : Factor de Ajuste de Complejidad de Proceso

5. Obtención de un Modelo Empírico

Para obtener un modelo empírico de estimación del esfuerzo, es necesario contar con registros de proyectos concluidos, con sus tamaños estimados en puntos de función para estimación temprana y el esfuerzo de desarrollo (sin incluir puesta en marcha ni mantenimiento) medido en horas hombre.

En este proyecto, se utiliza el modelo propuesto en [1], ya que se cuenta con los datos de los proyectos desde los cuales se obtuvo el modelo, sus tamaños están medido en la medida de Puntos de Función para estimación temprana y la medida del esfuerzo corresponde a la que se utilizará en este proyecto. Con estos antecedentes, se le puede adaptar a la organización una vez que se cuente con información acerca de proyectos terminados.

Con respecto a la obtención del modelo, se utilizarán herramientas de la inferencia estadística, que se especifican en [11].

Método de Regresión Lineal.

Se han de registrar datos de Esfuerzo y Tamaño de proyectos concluidos. En base a estos registros se obtendrá un modelo de la forma

Esfuerzo = f (tamaño del software)

donde el esfuerzo es medido en horas hombre, y el tamaño del software está medido en puntos de función para estimación temprana.

Para fines estadísticos, hay que notar que la variable predictora o independiente es el tamaño del software, y la variable respuesta o dependiente es el esfuerzo de desarrollo.

Así, el esfuerzo E es función del tamaño T, de la forma

Esta ecuación corresponde a un modelo de regresión lineal simple, donde los parámetros a y b quedan determinados por:

donde n es el número de registros, Ti es el registro i-ésimo del tamaño y Ei es el registro i-ésimo del esfuerzo.

Comentario

No se ha explicitado mayormente el método estadístico para la obtención de modelos empíricos principalmente porque existe la posibilidad de obtener un modelo de estimación utilizando redes neuronales, cuestión que queda como una proyección de este proyecto.

6. Características que debe poseer un modelo de estimación del esfuerzo.

Se declaran las siguientes características como deseables en todo modelo de estimación que pretenda apoyar la etapa de planificación de proyectos de desarrollo de software.

a. Poder adaptarse a la productividad de la organización.

b. Considerar el costo de comunicación entre personas.

c. Incorporar guías útiles para estimar aquellos parámetros que son subjetivos o no se deducen en forma explícita a partir del modelo.

d. Usable.

e. Constar de etapas simples de entender y definidas en forma precisa.

f. Objetivo.

g. Costo efectivo.

h. Proveer medios para adaptarse a cambios en el ambiente de desarrollo.

i. Permitir una estimación temprana.

7. Método Propuesto.

Se propone un método que posibilita realizar estimaciones tempranas disminuyendo el costo de obtener registros de proyectos terminados en la organización. Se posibilita la disponibilidad de estimaciones tempranas apenas se comienza a utilizar el método.

Las estimaciones tempranas están garantizadas por la utilización correcta de la métrica de Puntos de Función para Estimación Temprana y la existencia de un modelo de estimación "importado". Se garantiza la adaptación del modelo a la organización, dado que se este se "sintoniza" en forma incremental cada vez que se finaliza un proyecto.

Con respecto a las características declaradas como deseables en el punto anterior, este método (automatizado) satisface en distinto grado cada una de dichas condiciones.

Se ha especificado y diseñado una herramienta software, que automatiza el proceso que se describe a continuación, el cual se propone para ser aplicado en organizaciones de desarrollo de software.

Para cada proyecto de desarrollo, clasificarlo de acuerdo a sus características (sistema de información administrativo, científico) y a la tecnología de desarrollo (si es relevante).

Para cada proyecto de desarrollo de software que haya finalizado la etapa de especificación de requisitos, registrar su tamaño en PFET.

Estimar el esfuerzo de desarrollo utilizando algún modelo disponible para su tipo (en su defecto, utilizar el modelo propuesto en [1]).

Corregir dicha estimación por el Factor de Apoyo Tecnológico, en caso de estar utilizándose tecnologías nuevas, que no posean un modelo empírico asociado.

Para cada proyecto de desarrollo de software que haya finalizado la etapa de diseño externo, registrar su tamaño en PF y PC (si posee complejidad algorítmica).

Estimar el esfuerzo de desarrollo utilizando algún modelo disponible para su tipo (en su defecto, utilizar el modelo propuesto en [1]).

Corregir dicha estimación por el Factor de Apoyo Tecnológico, en caso de estar utilizándose tecnologías nuevas, que no posean un modelo empírico asociado.

Para cada proyecto terminado, registrar el esfuerzo de desarrollo en horas hombre.

Determinar un nuevo modelo empírico de estimación, agregando la nueva información al conjunto de datos de proyectos anteriores.

Determinar un modelo empírico de estimación asociado a proyectos desarrollados con tecnologías que mejoran la productividad, si corresponde. De este modo, se evitará la realización de correcciones por factor de apoyo tecnológico a los futuros proyectos de características similares.

Se propone la generación de modelos asociados a tipos de proyectos, esto es, diferenciar proyectos por criterios tecnológicos o humanos (desarrollados con herramientas distintas o por equipos de desarrollo diferentes).

Para sobrellevar el problema de la no existencia de modelos, se propone la "sintonización" de un modelo externo documentado (como aquel propuesto en [1]), para ir adaptándolo incrementalmente a la organización, a medida que se van terminando proyectos de cada tipo.

Para solucionar el problema de la constante migración hacia herramientas que mejoran la productividad, se ha incluido en la especificación del software una componente de "Incremento de la productividad por Apoyo Tecnológico", que constituye un factor asignado por el administrador del proyecto, que corregirá las estimaciones realizadas utilizando modelos de estimación basados en proyectos desarrollados con tecnologías anteriores. En este caso, se debe crear un nuevo tipo de proyectos (desarrollados con tecnología nueva) y utilizar el factor de corrección (para estimaciones hechas con el modelo determinado a partir de proyectos desarrollados con tecnología antigua) hasta que se tenga información suficiente como para generar un modelo independiente.

8. Conclusiones

Estado Actual del Proyecto

Actualmente, se cuenta con una especificación y diseño completos de un software que automatiza el método propuesto. El software está especificado de modo que se puede adaptar a cualquier organización de desarrollo de software, con un diseño a un nivel abstracto, el que sólo hay que adaptar levemente a la realidad de cada organización en particular.

Proyecciones

Como primera proyección de este proyecto está la implementación del software especificado y diseñado en su forma preliminar. Para ello, se debe implantar en alguna organización y adaptarse a ella. Para la implementación e implantación del método propuesto se deben realizar dos pasos fundamentales. El primer paso consiste en analizar detalladamente los tipos de aplicaciones que se desarrollan, además de estandarizar la semántica de los ítems contemplados en el método, esto con el fin de conseguir medidas consistentes e independientes de los individuos que las realicen. El segundo paso consiste en implementar una política de registros seria, con medidas consecuentes para el esfuerzo que cada tipo de recurso ha dedicado a un proyecto en particular.

También hay que considerar en cambiar el método de determinación de modelos de estimación a la utilización de redes neuronales, lo que implica un estudio acucioso de esta tecnología, y la revisión de trabajos relacionados.

Otra proyección, en caso de desechar la utilización de redes neuronales, es el estudio más detallado de técnicas de regresión no sólo lineales, y de técnicas para validar y corregir los modelos, así como de variables de calidad de los modelos.

Por otro lado, se debe seguir investigando la existencia de un modelo de estimación más moderno que aquel propuesto en [1], para que la sintonización del mismo no necesite de un gran caudal de proyectos terminados.

Existe la posibilidad de estudiar una actualización del modelo. Esto considera actualizar las características generales de la aplicación que son consideradas para el ajuste de complejidad de procesamiento. Se debe estudiar las herramientas de desarrollo actualmente en uso, y las características de los software de negocios de hoy. Además se podría considerar la modificación de los ponderadores del método para adaptarlo a otro tipo de aplicaciones.

Limitaciones de la solución.

Una limitación de la solución es la necesidad aún de un diseño externo, idealmente tener un modelo de datos y un Diagrama de Flujo de Datos de Nivel 0, o diagrama de contexto para poder aplicar con mayor seguridad el método de determinación del tamaño de la aplicación propuesto (PFET).

Otro factor que limita el uso de este método (automatizado), es su generalidad a sistemas tradicionales. Cualquier organización que desee implantar esta solución para sus estimaciones de esfuerzo, debe plantearse si es válida en su realidad organizacional. El modelo es susceptible de ser adaptado. Es más, en el software especificado y diseñado, los valores de los pesos utilizados para ponderar cada variable considerada para cuantificar la medida de PFET y PF o PC puede ser modificada para ser adaptada a un tipo de software en particular.

Otra variable importante de considerar es que el modelo escogido para ser sintonizado a las diversas organizaciones se obtuvo a partir de proyectos desarrollados principalmente en COBOL, por lo que puede ser muy poco certero para aquellos desarrollos con herramientas más modernas. Lamentablemente no se encontró un modelo más moderno que estuviese debidamente documentado.

Otra limitante es la utilización de sólo regresión lineal, utilizando como variable dependiente el Esfuerzo y como variable independiente el tamaño de la aplicación en Puntos de Función para Estimación Temprana. El supuesto de que siempre los modelos son lineales, es débil. Hay que explorar otros posibles modelos, y las técnicas necesarias para su obtención. A partir de este estudio, se debe completar el diseño del software.

Conclusiones Generales.

No existen soluciones universales en esto de la estimación del esfuerzo de desarrollo de software. Lo propuesto corresponde a una solución general que debe ser adaptada a las realidades particulares de la organización donde se implantará tanto el método como el software que lo automatiza.

La solución propuesta, pretende satisfacer los requisitos declarados como deseables para todo modelo de gestión que intente apoyar la etapa de planificación. A juicio de la autora, estos requisitos son satisfechos de manera satisfactoria por el método propuesto.

La solución propuesta se basa en el análisis por puntos de función, principalmente por las ventajas que esta métrica tiene. De todos modos, al ser este método propuesto hace más de una década y basado en proyectos realizados con herramientas de aquellos años, es necesario realizar una actualización de los conceptos presentes en tal método.

Es así como resulta necesario definir claramente la semántica de cada uno de los conceptos presentes en las cuentas de los puntos de función para estimación temprana, como también para los puntos de función y puntos de característica. De este análisis resultará el significado de "una entrada externa" para esta organización, por ejemplo. Así como también es necesario adaptar el significado de las características generales de la aplicación.

Lo que se debe realizar es replantear la semántica de estas características generales y de las ponderaciones de los parámetros relevantes. Para esto, es necesario realizar un estudio acucioso de las aplicaciones actualmente realizadas, poniendo énfasis en un sólo tipo, ya que no existen soluciones universales.

El proceso de estimación del esfuerzo no es gratuito. Es necesario esfuerzo adicional en cada organización. Esto se debe tener muy presente a la hora de implementar un método probado en alguna organización externa, lo que no significa que otorgará buenos resultados en cualquier otra.

9. Bibliografía y Referencias.

[1] Allan J. Albrecht and John E. Gaffney, "Software Function, Lines of Code, and Development Effort Prediction: A Software Science Validation", IEEE Transactions on Software Engineering, vol SE-9, No 6, November 1983.

[2] Jack E. Matson, Bruce E. Barrett, and Joseph M. Mellichamp, "Software Development Cost Estimation using Function Points", IEEE Transactions on Software Engineering, vol 20, no 4, April 1994.

[3] Barry W. Boehm and Philip N. Papaccio, "Understanding and Controlling Software Costs", IEEE Transactions on Software Engineering, vol. 14, no 10, October 1988.

[4] Graham C. Low and D. Ross Jeffery, "Function Points in the Estimation and Evaluation of the Software Process", IEEE Transactions on Software Engineering, vol 16, no 1, Juanary 1990.

[5] Charles R. Symons, "Function point Analysis: Difficulties and Improvements", IEEE Transactions on Software Engineering, vol 14, no1, January 1988.

[6] Jeffery, G. C. Low, and M. Barnes, "A Comparison of Function Point Counting Techniques", Transactions on Software Engineering, vol 19, no 5, May 1993.

[7] Norman Fenton, "Software measurement: A Necessary Scientific basis", IEEE Transactions on Software Engineering, vol 20, no 3, March 1994.

[8] Tridas Mukhopadhyay and Sunder Kekre, "Software effort Models for Early Estimation of Process Control Applications", Transactions on Software Engineering, vol 18, no 10, october 1992.

[9] June Verner and Graham Tate, "A Software Size Model", IEEE Transactions on Software Engineering, vol 18, no 4, April 1992.

[10] W. Boehm, "Software Engineering Economics", Englewood Cliffs, NJ: Prentice-Hall, 1981.

[11] Luis Cid, Arturo Mora, María Valenzuela, "Inferencia Estadística", Universidad de Concepción, Facultad de Ciencias, Departamento de Matemática, 1990.

[12] Marcela Varas C, "Proyecto de Mención: Modelo de gestión de proyectos Software", Universidad de Concepción, Facultad de Ingeniería, Departamento de Ingeniería Informática y Ciencias de la Computación, 1994.

[13] Roger S. Pressman, "Ingeniería del Software, Un Enfoque Practico", tercera Edición, McGraw-Hill editores, 1994.

[14] Ian Sommerville, "Software Engineering", Fourth Edition, Addison-Wesley Publishing Company, 1992.

[15] Caper Jones, "Programming Productivity", McGraw-Hill, 1986

[16] Marcela Varas C, "Modelo de Gestión de Proyectos Software: Estimación del Esfuerzo de Desarrollo", Informe de Habilitación Profesional para optar al Título de Ingeniero Civil Informático, Universidad de Concepción, 1995.