Estimacion de proyectos de software

ESTIMACION DE PROYECTOS DE SOFTWARE

INTRODUCCIÓN

Una de las mayores dificultades en la administración de proyectos de desarrollo de
software, es el poder estimar los recursos necesarios requeridos, tales como, mano de
obra (horas/hombre), tiempo, costos asociados al desarrollo, entre otros; en etapas
tempranas del desarrollo, con el fin de anticipar resultados no esperados al desarrollo
del proyecto.

Muchos modelos de estimación de costos y esfuerzos han sido desarrollados, entre los
más conocidos se cuentan: COCOMO y puntos por función, los cuales son de gran
utilidad para los administradores de proyectos siempre y cuando sean correctamente
utilizados. El enfoque de puntos por función desarrollado por Albrecht y Gaffney sirvió
de base a un nuevo método mejorado de estimación, llamado Mk-II, desarrollado por
Symons.

DIFERENTES ENFOQUES PARA MEDIR ESFUERZO Y COSTO EN EL
DESARROLLO DE SOFTWARE

Dentro de los elementos más débiles del desarrollo de software, están la estimación de
esfuerzo y el costo. Es por esta razón que existe una alta motivación al desarrollo y
utilización de métodos para tales estimaciones. A continuación se muestran cuatro
enfoques para estimar el esfuerzo y costo en el desarrollo de software.

a). Juicio de un Experto

Este enfoque consiste en que los administradores de proyecto consultan a un experto,
quien estudia el nuevo proyecto y sugiere sus mejores estimaciones. La desventaja del
enfoque es que tiende a ser subjetivo debido a que considera la experiencia del experto
y sus percepciones de él, con respecto al proyecto.

b). Estimación mediante analogía.

Una estimación inicial basada en la experiencia con proyectos similares previos es
mejorada por considerar diferencias entre los viejos y nuevos proyectos. Las
condiciones en que se dieron a lugar los antiguos proyectos, deberán ser tomadas en
cuenta. Para este enfoque es necesario que las organizaciones de desarrollo de
proyectos, mantengan una base de datos con información respecto a los proyectos
desarrollados.

c). Enfoque por Descomposición

El proyecto es descompuesto en pequeños componentes, y el esfuerzo y costo de
desarrollar cada componente es estimado por analogía. Este enfoque se basa en el punto
anterior, y por ende las organizaciones de desarrollo mantienen guardados, esfuerzo y
costo de los componentes estándares de desarrollo. Ellos debieran ajustarse de acuerdo a
características específicas y complejidades relacionadas con componentes equivalentes
del desarrollo de un nuevo proyecto.

d). Modelos de estimación

Variados modelos de estimación cuantitativos han sido desarrollados, de acuerdo a
análisis estadístico de datos actuales, en base al esfuerzo y tiempo de desarrollo de
muchos proyectos de software. Por ejemplo, algunos modelos de costos, estiman el
costo y duración de desarrollo, como una función del tamaño del software y factores de
productividad específicos, tal como la experiencia del equipo de desarrollo y la
complejidad de la aplicación. Uno de los más populares modelos de costo es
COCOMO, desarrollado por Boehm, el cual define el esfuerzo del desarrollo como una
función del tamaño del software:

esfuerzo = a x (tamaño del software)b

donde el esfuerzo es medido en meses-hombre, y tamaño del software es dado en miles
de líneas de código (LOC) entregados a los usuarios (sin contar líneas de comentarios).
Los parámetros a y b son determinados por el tipo de proyecto (donde una distinción es
hecha entre modelos 'orgánico', 'encajado' y 'semiseparados') y el nivel del modelo
COCOMO (distinguiendo entre niveles 'básico', 'intermedio' y 'detallado').

Basado en el esfuerzo, la duración del proyecto ('lapso de tiempo') es estimado como
sigue:

Lapso_tiempo = c x (esfuerzo)d

Donde el parámetro c es determinado por el tipo de proyecto, y el parámetro d es
determinado por ambos: el tipo de proyecto y el nivel del modelo.

A pesar de que ellos siendo basados sobre métodos cuantitativos, varios estudios han
mostrado que estos modelos de estimación no han cosechado suficientes buenos
resultados. Una mayor limitación esta en el uso de la cantidad de líneas de código
(LOC) para estimación de otras estadísticas. Este número no es conocido
tempranamente en las etapas de desarrollo y su estimación es problemática. Por
consiguiente, no es posible obtener buenas estimaciones para el esfuerzo y duración,
cuando ellas son necesitadas por la administración del proyecto.

Otras desventajas del Modelo COCOMO

• Hoy en día, el número de líneas de código (LOC) en el modelo COCOMO, no es
un factor representativo, si se trabaja con un lenguaje 4GL o 3GL, ya que a
modo de ejemplo una instrucción en un lenguaje de alto nivel, tal como Visual
Basic, podría equivaler a 50 instrucciones en Lenguaje COBOL.

• En los lenguajes Orientados a Objetos, existe el concepto de Encapsulamiento,
el cual traduce el código neto de la aplicación, a un mínimo de líneas de trabajo.

Cuándo y para que se debería usar el Modelo COCOMO?

En rigor se debería usar al final del Ciclo de Desarrollo de Software y para estimar el
costo(o precio) del producto de software. Otra utilidad posible se debe a que una vez

obtenido los resultados de la aplicación del modelo, estos pueden ser utilizados para
futuras estimaciones de nuevos proyectos, mediante la aplicación de analogías.

MÉTODOS DE ESTIMACIÓN BASADOS EN LA FUNCIONALIDAD DEL
SISTEMA

La funcionalidad del sistema expresa la variedad de funciones que el sistema de
software provee a sus usuarios. Los modelos de estimación de software se basan sobre
la funcionalidad, y no dependen de las etapas de desarrollo, solo de la especificación del
sistema. Por lo tanto, es posible hacer estimaciones una vez que el sistema es
especificado en términos funcionales, en un etapa inicial del desarrollo. Enseguida se
revisan dos métodos relacionados.

a). El Método Puntos por Función

Este método, desarrollado por Albrecht y Gaffney, es ampliamente conocido en Estados
Unidos y Europa. El método estima el tamaño del software, contando los 'puntos por
función' del sistema. Esto es realizado en tres pasos.

Primero: Se calcula el 'conteo de función sin ajuste' (UFC). De acuerdo al modelo, un
sistema de Software consiste de cinco tipos de componentes:

1. Entradas externas.
2. Salidas externas.
3. Consultas externas.
4. Archivos lógicos internos.
5. Archivos de interfaces externas.

Para cada uno de estos tipos de componentes, el número de itemes en el sistema es
contabilizado, y el nivel de complejidad es determinado (distinguiendo entre 3 niveles:
simple, mediano y complejo). Cada nivel tiene una importancia o peso (provisto por el
modelo). El UFC es calculado como sigue:

Segundo: Se calcula el 'factor de complejidad técnica' (TFC). El factor de complejidad
del sistema es determinado de acuerdo a 14 atributos técnicos. Cada atributo le es
asignado un peso entre 0 (como mínimo) hasta 5 (el valor más alto). El TCF es
calculado como sigue:

Donde Fi es el peso del atributo i.

Tercero: El tamaño del sistema es calculado en términos del número de 'puntos por
función' (FP):

FP = UFC x TCF

Para usar el método, el departamento de desarrollo de software tiene que mantener una
base de datos de los proyectos, la cual debería incluir datos de su duración (lapso de
tiempo), horas de trabajo, puntos por función (FPs), productividad (FPs por hora), etc.
Basado en esta base de datos, el costo (en términos de tiempo y costo) de un FP puede
ser calculado. Una vez realizado esto, el FP de cualquier proyecto nuevo, puede ser
calculado de acuerdo a lo formulado anteriormente, y así los costos estimados son
derivados.

Estudios empíricos sobre métodos de puntos por función revelan que existe una alta
correlación entre el esfuerzo de desarrollo y la funcionalidad del sistema. Sin embargo,
algunos estudios señalan ciertas limitaciones:

• El método no siempre define claramente como contar el número de puntos por
función de cada componente. Sin un claro acuerdo de que o como contar, es
difícil de obtener estimaciones exactas que permitan comparar proyectos
diferentes.

• El peso de los componentes que han sido determinados por Albrecht y Gaffney
son basados sobre el análisis de desarrollo de proyectos en un ambiente IBM;
ellos no son necesariamente validos para desarrollo de proyectos en otros tipos
de ambientes.

• El TCF (factor de complejidad técnica) es calculada según 14 atributos
específicos. No es razonable pensar que un conjunto constante de atributos
pueda determinar la complejidad de algún sistema.

b). El método Mk- II FP

Este método, desarrollado por Symons, es una versión mejorada del método de puntos
por función de Albrecht y Gaffney. Este calcula los FPs multiplicando dos factores:

o Tamaño de la información procesada y
o Ajuste de complejidad técnica

De esta forma los puntos por función es:

FP = (tamaño de información procesada) x (ajuste de complejidad técnica)

• Tamaño de información procesada.

Según éste método, un sistema contiene transacciones lógicas. Una transacción realiza
un proceso de negocio aislado. Según esto cada transacción consiste de:

1. una o más tipos de entradas.
2. un proceso.
3. uno o más tipos de salidas.

El factor 'tamaño de la información procesada' es medido por el número de puntos por
función sin ajustar (UFPs), contados en todas las transacciones del sistema. Para cada
transacción el UFP es calculado como:

UFP = WI x (número de tipos de datos elementales de entrada)

+ WE x (número de tipos de entidades referenciadas)

+ WO x (número de tipos de datos elementales de salida)

Donde WI, WE y WO son pesos calibrados. (El término 'tipos de entidad' significa
archivos de la base de datos o relaciones.) El método provee reglas para contar números
de tipos de datos elementales y tipos de entidades en una transacción. El total UFPs de
un sistema es la suma de UFPs de sus transacciones.

• Ajuste de complejidad técnica

El método FP Mk -II utiliza el enfoque de Albrecht y Gaffney con los siguientes ajustes:

• El número de atributos sobre el cual el factor de ajuste es basado es 19 (en vez
de 14). Por otra parte, el usuario podría agregar más atributos que son
específicos al proyecto en cuestión.

• El peso de cada atributo puede ser calibrado (a diferencia del método de puntos
por función donde los pesos son fijos).

El factor TCA (Ajuste de complejidad técnica) es calculado como sigue:

TCA= 0.65 + C x (suma de grados de influencia para las 19 características de la
aplicación más las del cliente; características definidas)

Donde C puede ser calibrado por el usuario. En el modelo de Symons el valor de C es
0.005, lo cual significa que las características de la aplicación tienen poca influencia.

El tamaño del sistema, expresado en puntos por función (FPs) es calculado como sigue:

FP = Total UFP x TCA

Basado en el número de FPs, dos estimaciones mayores pueden ser obtenidas.

• Primero:

Donde esfuerzo es medido en horas de trabajo, y Productividad es medido en FPs por
hora. Productividad es la tasa normal del equipo de desarrollo; puede ser determinada
de acuerdo a desempeños pasados del grupo de desarrollo en proyectos y ambientes de

desarrollo similares (incluyendo el nivel de lenguaje de programación, ya sea en 3GL o
4gl), registrados en la base de datos de los proyectos. El coeficiente B depende del tipo
de sistema: en el caso de sistemas en línea (o tiempo real) B=1 y en el caso de sistemas
sea batch o por lote, B=1.5.

• Segundo:

Donde la duración es medida en lapso de semanas y la entrega es medida en FPs por
lapso de semana. El rango normal de entrega puede ser determinado de acuerdo a
desempeños pasados, similar a la productividad.

Ambos, la Productividad y la Entrega, y ahora las estimaciones de Esfuerzo y
Duración, pueden ser influenciadas y ajustadas según factores de riesgo asociados con
los proyectos específicos en cuestión. El factor de riesgo incluye:

1. Tamaño del proyecto: existen más riesgos si el proyecto es grande y el equipo de
desarrollo no tiene experiencia con esta clase de proyectos, contrario a pequeños
proyectos y un experimentado equipo de desarrollo;
2. Problema de estructura: existen más riesgos si el proyecto trata con problemas
no estructurados, contrario a los que tratan con problemas estructurados, o
similares a los existentes y proyectos bien documentados.
3. Tecnología: existe más riesgos si el grupo de desarrollo utiliza nuevos métodos
y herramientas, contrario a usar los ya existentes.

El método de estimación Mk -II ha sido implementado para un a conteo automático de
FP en varias herramientas CASE, incluyendo 'Ingeniero de Sistemas' (de LBMS) y el
'Arquitecto de Sistemas' (de Bramco).

Una importante ventaja del método Mk-II es que la medición del tamaño es basado
sobre las transacciones lógicas del sistema. El tamaño de cada transacción es
determinado según el número de tipos de datos elementales incluyendo sus entradas y
salidas, y el número de tipos de entidades (es decir, relaciones de la base de datos), que
son accesadas. El problema, sin embargo, es que la administración del proyecto debe
reconocer las transacciones del sistema y los componentes de cada transacción en una
etapa inicial del desarrollo del sistema.

EJEMPLO DE APLICACIÓN DEL METODO MK- II

Se ilustra las partes del proceso con un pequeño ejemplo. El dibujo, muestra un simple
DFD de un sistema, el cual consiste de solamente dos transacciones, una incluye la
función 1, y la otra incluye las funciones 2-4. Los almacenes de datos, D1 y D2, y la
entidad externa E1, pertenecen a ambas transacciones. Se describe el cálculo de UFP de
la transacción que incluye las funciones 2-4.

• El componente de entrada. Se asume que existen 6 tipos de datos elementales en
el diseño de las pantallas de entrada para el flujos de dato 'transacción del
cliente' desde E1 (cliente) a la función 2: cust-iD (identificación del cliente),
acc.-number (número de acceso), name (nombre), acc.-type (tipo de acceso),
type-of-trans (tipo de transacción), amount (cantidad).

• El componente de salida. Existen dos salidas en esta transacción: una es un
mensaje de 'mala transacción' en pantalla (por ejemplo, si la cantidad excede el
balance), y la otra es una copia impresa de la transacción. Se asume que el
número total de tipos de datos elementales en las dos salidas es 14.

• El componente de proceso. En el DFD se observa, que la función 2 lee desde el
almacén de datos D1, la función 3 lee desde D2 y la función 4 escribe en D2.
Pero, según el método Mk-II, se debe mirar las relaciones de la base de datos
que son accesadas por las transacciones, y no a los almacenes de datos. Se
asume que como un resultado del proceso de diseño de la base de datos, que las
siguientes tres relaciones primarias han sido obtenidas desde los almacenes de
datos originales D1 y D2:

R1: cuenta (acc,-number, acc-type, cust.-ID, date-open, date-of-last-
trans., balance)

R2: account-events (acc.-number, date, type-of-event, amount)

R3: customers (cust.-ID, mane, address, telephone).

Se asume que las transacciones leen y escriben hacia/desde las tres relaciones:
(1) La función 2 lee los detalles del cliente desde R3; (2) La función 3 lee los
detalles de la cantidad (incluyendo el balance), desde R1; (3) La función 4
agrega los detalles del resultado a R2, y el nuevo balance a R1. En conjunto la
transacción accesa 3 relaciones, así este es el tamaño del componente de
proceso.

En orden de calcular el UFP de la transacción, multiplicamos el número de
componentes de cada tipo por su peso. Podemos usar los pesos de 'estándar
industrial' provisto por el método Mk-II, o los pesos calibrados por el
administrador del proyecto. Lo siguiente ilustra el uso de pesos estándares:

0.58 x 6 (para entrada) + 1.66 x 3 (para procesos) + 0.26 x 14 (para salida) =
12.1 UFP

El total UFP de todo el sistema es la suma de UFPs de sus transacciones. El
número de puntos por función (FPs) del sistema equivale al total de UFP
multiplicado por el TCA (Ajuste de Complejidad Técnica). Basado sobre el total
de FPs, el esfuerzo y duración del sistema será estimado mediante el uso de la
apropiada fórmula.

CONCLUSIONES

El método Puntos por Función, desarrollado por Albretch y Gaffney, hace énfasis en los
puntos por función de un sistema. Este posee ciertas desventajas, tales como por
ejemplo, que el factor de Complejidad Técnica es calculado de acuerdo a 14 atributos
específicos, según esto, no es razonable pensar, que un conjunto constante de atributos,
pueda determinar la complejidad de todo sistema. En base a lo anterior, el modelo
tiende a ser muy rígido o poco flexible, imposibilitando al administrador, ajustar el
enfoque a características específicas del sistema.

El método Mk-II es un enfoque mejorado, que se basa en el modelo anterior. Este
incluye ahora 19 atributos (en vez de 14), además permite que el administrador incluya
sus propios atributos para acomodar el modelo a la realidad del sistema. Otra
característica importante del método, es que la medida del tamaño del procesamiento de
la información, se basa en las transacciones lógicas del sistema.

http://www.monografias.com/trabajos55

Estimacion de proyectos de software

Más contenido relacionado

La actualidad más candente

Similar a Estimacion de proyectos de software

Último

Estimacion de proyectos de software