EPN – ASI Desarrollo de Software

ESTIMACION DE PROYECTOS DE SOFTWARE

Introducción:

El objetivo de la planificación del proyecto de software es proporcionar un marco de

trabajo que permita al gestor estimar razonablemente los recursos, costo y programa de
trabajo.
Sin embargo aunque la estimación se la realiza en etapas tempranas del proyecto ésta se
debe ajustar a lo largo del transcurso del mismo, pues entre más conozca menor será el
grado de incertidumbre y las estimaciones serán más precisas.

La estimación se basa en las métricas de proyectos anteriores, las cuales sirven de línea
base sobre las que, de acuerdo a la clasificación de los proyectos y una evaluación del
tamaño y complejidad del software se utilizan en las técnicas y modelos existentes.

Este trabajo contiene, en una primera parte algunos conceptos que son necesarios para
realizar una buena estimación: ámbito y complejidad del software, luego analizaremos
cuando un proyecto es factible, y finalmente algunos modelos empíricos de estimación,
COCOMO el cual es uno de los más utilizados, la ecuación del software también será
tratada y la medición orientada a objetos que es un modelo nuevo aún en desarrollo.

ESTIMACION DEL SOFTWARE

Una de las primeras actividades de este proyecto es la estimación, que es la base de

todas las demás actividades de la planificación.

Características del proyecto a estimar.

Complejidad del proyecto. Tiene un gran efecto sobre la incertidumbre; que es

inherente a la planificación.
El tamaño del proyecto. Es otro factor importante que puede afectar a la precisión
y eficacia de las estimaciones.
Grado de estructuración del proyecto. Se refiere a la facilidad con que las
funciones pueden ser compartidas y a la naturaleza de la información que debe ser
procesada.

Giovanny Cholca 1
EPN – ASI Desarrollo de Software

Observaciones acerca de la estimación

La estimación y planificación temporal de un proyecto software requiere: experiencia,
buena información histórica, coraje de confiar en las métricas, para obtener buenos
resultados, debido a que cada proyecto es diferente, cada empresa es diferente y el
contexto de los sistemas que desarrollamos cambian constantemente, no existe un
método que se adapte completamente a cualquier proyecto, así la estimación debe
ajustarse localmente.

Hay cuatro factores que influyen significativamente en las estimaciones:

La complejidad del proyecto.

El tamaño del proyecto.
El grado de incertidumbre estructural.
Disponibilidad de información histórica.

ÁMBITO DEL SOFTWARE Y FACTIBILIDAD

Son las funciones y características, datos de entrada, salida y el contenido que se
presenta a los usuarios finales.

El ámbito se define mediante:

Mediante una descripción narrativa.

Los usuarios desarrollan un conjunto de casos de uso.
Así mismo se debe analizar si el software es factible de acuerdo a:

Tecnología
Finanzas
Tiempo
Recursos

TÉCNICAS DE DESCOMPOSICIÓN

Tamaño del software

¿Cómo se define tamaño del software?, es un resultado cuantificable del proyecto. Se

pueden asumir dos enfoques: directo, se mide mediante líneas de código (LDC) e
indirecto, se mide mediante puntos de función (PF).
Putman y Myers sugieren:

Tamaño de lógica difusa,

Tamaño de punto de función
Tamaño de componentes estándar
Tamaño del cambio
Estos resultados se fusionan estadísticamente para crear una estimación basada en tres
puntos o del valor esperado, se desarrolla: valores optimistas (bajos), valores
probables y valores pesimistas (altos)

Giovanny Cholca 2
EPN – ASI Desarrollo de Software

Estimación basada en el problema

Los datos de LDF y PF son distintas técnicas de estimación, pero que tienen varias
características en común, y se utilizan en dos formas para estimar el proyecto de
software:

i. Como variable para estimar el tamaño del software

ii. Como métrica de línea base recolectada de proyectos históricos

Teniendo el ámbito del software, se descompone el mismo en funciones problemas,

para ser evaluadas individualmente y obtener valores para LDC y PF, entonces se
aplican métricas (LDC/pm o PF/pm) las cuales resultan en el tamaño o costo de la
función, que combinadas derivan en la estimación global del proyecto.
Sin embargo esta estimación basada en métricas de productividad es dispersa, por lo
que se debe considerar que no es suficiente, el dominio del problema debe calcular las
métricas de LDC/pm o PF/pm
Consejo: Definir una taxonomía de proyectos para establecer un dominio permite
obtener métricas más precisas.
Cuando se estima un nuevo proyecto primero debe ubicarse en un dominio, y luego
aplicar el promedio del dominio apropiado para la productividad y así generar la
estimación¨
El valor esperado se calcula mediante una ponderación de:
S = (Sopt + 4Sm + Spes) / 16

Estimación con casos de uso

Desarrollar un enfoque de estimación de casos de uso es un problema debido a:

No existe un formato estándar para describir los casos de uso.

Están descritos con diferentes grados de abstracción (dependen del
usuario).
Los casos de uso no explican la complejidad de las funciones y de las
características del software.
Los casos de uso no explican el comportamiento de las diferentes
funciones y características.
Para evitar estos problemas Smith sugiere el uso de los casos de uso en la
estimación pero dentro de un contexto de “jerarquía estructural”, ésta se describe
con no más de 10 casos de uso y 30 escenarios distintos para cada caso de uso.

Giovanny Cholca 3
EPN – ASI Desarrollo de Software

Como en toda estimación utilizamos datos históricos según la ecuación:

LDC estimada = N x LDCprom + [(Sa/Sh 1) + (Pa/Ph – 1)] x LDCajuste

Donde:

N = número real de casos de uso

LDCprom = promedio histórico de LDC
LDCajuste = diferencia entre este proyecto y los proyectos promedio
Sa = escenarios reales de casos de uso
Sh = escenarios promedio de casos de uso
Pa = páginas reales por caso de uso
Ph = páginas promedio por caso de uso

MODELOS EMPIRICOS DE ESTIMACIÓN

No hay ningún modelo específico para todo proyecto de software, como vimos en las
secciones anteriores utilizamos datos históricos, pero éstos están limitados a una
muestra pequeña de proyectos anteriores, además que cada escenario y grupo de trabajo
es diferente da lugar a que cada modelo se debe adecuar localmente.

EL MODELO COCOMO
COCOMO son las siglas para COnstructive COst MOdel (Modelo constructivo de
costos)

Este modelo es una jerarquía de modelos de estimación que aborda:

Modelo de composición de la aplicación, al inicio del ciclo de vida, cuando se

realiza la recolección de requerimientos.
Modelo de etapa de diseño temprano, se utiliza cuando se realiza el diseño de la
aplicación, en la evaluación de la tecnología.
Modelo de etapa posterior, cuando ya se encuentra en la fase de construcción
del software.
Además de estos tres modelos, COCOMO hace una clasificación en tres tipos de
proyecto, ya que la productividad no es la misma para todos los proyectos. Los tipos de
proyecto son:

Organic Mode (Orgánico): Proyectos pequeños con pocos requerimientos, sin

innovación tecnológica, usualmente un solo equipo de trabajo.
Semidetached Mode (Semiacoplado): Proyectos de complejidad media, con algo
de innovación tecnológica, ya interviene más de un equipo de trabajo.
Embedded Mode (Encajado): Proyectos de complejidad alta, con requerimientos
rigurosos y con varios equipos trabajando coordinadamente.

Giovanny Cholca 4
EPN – ASI Desarrollo de Software

Las ecuaciones del modelo COCOMO tienen la forma general:

E = a · Lb · CDA,

T = c · Ed

Donde:

E es el esfuerzo (en personas-mes), L son las líneas de código (en miles), T es el tiempo
de desarrollo del proyecto (en meses) y CDA los cost driven attributes.

a, b, c y d son coeficientes que el modelo proporciona como resultado del análisis de los
datos de sesenta y tres proyectos realizados entre 1965 y 1980, de tamaños que varían
de 2 a 1.000 KLDC y con una productividad que se sitúa entre 28 y 250 LDC por
persona-mes.

Para que COCOMO funcione se supone que:

No se tienen en cuenta los comentarios en el recuento de las LDC.

Se admite la equivalencia siguiente: 1 persona/mes son 152 horas de trabajo.
Se considera que los requerimientos son estables.
Se acepta que el proyecto está bien gestionado

COCOMOII
La siguiente versión del modelo, COCOMOII, aun se encuentra en fase de elaboración,
es más complejo y al igual que su antecesor presenta tres modelos:

• Modelo de composición de aplicaciones, uso de prototipos, se definen puntos de

objeto
• Modelo de diseño primerizo, primera aproximación al inicio del ciclo de vida,
cuando se conocen pocas características del producto.
• Modelo de postarquitectura, se aplica cuando ya se tienen requerimientos estables,
utiliza primitivas de salida como: LDC y TUFP (puntos de función sin ajustar)

En el modelo de postarquitectura aparecen nuevos términos, como NLDC , esto

básicamente cuando se adopta el uso de componentes genéricos o componentes
comerciales ya probados, o extender la funcionalidad de componentes propios de un
proyecto.

Los puntos de objeto, mencionados anteriormente, se calculan mediante el conteo de:

Pantallas (en la interfaz de usuario)

Reportes
Componentes que se requieran para construir la aplicación

Giovanny Cholca 5
EPN – ASI Desarrollo de Software

Cada instancia de un objeto de clasifica en uno de tres niveles de complejidad (simple,

medio o difícil), de acuerdo a la siguiente tabla:

Tipo de Peso de Paso de

Objeto complejidad
Simp Medio Difícil
le
Pantalla 1 2 3
Reporte 2 5 8
Componente 10
3GL

Una vez determinada la complejidad, el número de pantallas y componentes, se calcula

la cuenta de puntos de objeto al multiplicar el número original de instancias de objeto
por el factor de ponderación, y se suma para obtener una cuenta total de puntos de
objeto. Cuando existe un desarrollo basado en componentes o reutilización de software
se estima el porcentaje de reutilización.

NPO = (puntos objeto) x [(100 - %reut) / 100)]

NPO son los nuevos puntos de objeto
La tasa de productividad se calcula mediante:
PROD = NPO / pm
Y el esfuerzo estimado con: E = NPO / PROD

ECUACIÓN DEL SOFTWARE

Este modelo procede de datos para productividad de casi 4000 proyectos de software
contemporáneos, se ha estimado un modelo de la forma:
E = [LDC x B0.333 / P]3 x (1/t4)

Donde:

E esfuerzo en pm
t duración del proyecto en meses o años
B factor especial de habilidades
P parámetro de productividad
La ecuación del software tiene dos parámetros independientes:
estimación del tamaño (LDC)
LDC = 180Bt3 en pm
duración del proyecto
tmin = 8.14(LDC/P)0.43 en meses

Giovanny Cholca 6
EPN – ASI Desarrollo de Software

ESTIMACIÓN PARA PROYECTOS ORIENTADOS A OBJETOS

1. Desarrollar estimaciones aplicando: descomposición de esfuerzo, análisis de PF,

esto para aplicaciones convencionales.
2. Aplicar el modelo orientado a objetos desarrollar casos de uso y determinar un
conteo.
3. Determinar el número de clases clave.
4. El número de clases clave por el multiplicador determina el número de clases
soporte.
5. Multiplicar el número total de clases por el número promedio de unidades de trabajo
por clase (15-20 personas-día).

RESULTADOS
Mediante el estudio de las técnicas y modelos de estimación, nos hemos dado cuenta
que es una de las principales tareas durante la planificación, quizá de las más
importantes. Aunque muchas veces estas tareas previas al desarrollo mismo de la
aplicación son vistas como algo que retrasa el proyecto, resultan cruciales ya que como
gestores del proyecto nos ayudan a reducir la incertidumbre.

CONCLUSIONES

La estimación es una de las principales actividades de la planificación ya que el

costo del proyecto es lo que un cliente primero exige.
No existe una fórmula mágica o modelo que se adapte a cualquier proyecto, una
estimación muchas veces depende de la experiencia del gestor del proyecto y de los
datos históricos que se posea.
El número de personas que requiere un proyecto solo se determina después de que
se haya hecho una estimación del esfuerzo.
Las técnicas y los modelos son útiles al estimar pero no son confiables al 100%.

BIBLIOGRAFIA

[1] PRESSMAN Roger S. Ingeniería del Software. Un enfoque práctico 6ta

edición. McGrawHill Interamericana Mexico: (2005).

[2] Cálculo de COCOMO básico (en línea) disponible en:

http://www.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/kutcher/kutcher.
html

[3] Planificación, Control y Monitoreo de Proyectos, JUMBO, Luis; CHAVEZ

Luis, Tesis de Ingeniería de Sistemas Informáticos y Computación, (2005)

Giovanny Cholca 7