www.monografias.

com

Estimacion de tiempo y esfuerzo en proyectos de software

1.
2.
3.
4.
5.
6.

Resumen
Introduccin
Cuestiones generales sobre la estimacin
Tcnicas de estimacin
Conclusiones
Bibliografa

RESUMEN
La estimacin es una de las actividades ms importante en el Proceso de Desarrollos de Productos de
Software. El presente trabajo expone la importancia y los objetivos de esta etapa, explica brevemente
algunas de las tcnicas que ms se utilizan actualmente, estimacin basada en Lneas de Cdigo, en
Puntos de Funcin, en Puntos de Casos de Uso, y el mtodo del COCOMO II. Se exponen las debilidades
de estas tcnicas y se propone brevemente la idea de una solucin.
PALABRAS CLAVES
Estimacin, Estimacin en proyectos de Software, Mtodos de Estimacin.

INTRODUCCION
El proceso de gestin del proyecto de software comienza con un conjunto de actividades que, globalmente,
se denominan planificacin del proyecto. [1]
La planificacin es una de las etapas ms importantes en el desarrollo de cualquier proyecto, incluyendo los
proyectos de software, esta etapa contiene diversas actividades: mbito de Software, Recursos y
Estimacin esta ltima es el centro del presente trabajo.
Aunque la estimacin es ms un arte que una ciencia, es una actividad importante que no debe llevarse a
cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costes y de tiempos. Y dado que la
estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como una gua
para una buena ingeniera del software, no es en absoluto aconsejable embarcarse sin ella. [1]
La estimacin la lleva a cabo el gestor del proyecto. La estimacin y planificacin temporal de un proyecto
software requiere de experiencia, buena informacin histrica, o una buena tcnica de estimacin en la que
se confe plenamente por los resultados que arroje.

CUESTIONES GENERALES SOBRE LA ESTIMACION.

1.1.
Estimacin. Objetivos e Importancia.
El objetivo de la Estimacin es predecir las variables involucradas en el proyecto con cierto grado de
certeza, trata de aportar una prediccin de algn indicador importante para la gestin de proyectos de
software tiempo, esfuerzo, cantidad de defectos esperados entre otros sin dejar de tener en cuenta que la
incertidumbre y el riesgo son elementos inherentes.
La estimacin es importante no solo para predecir el valor de variables concretas dentro de un proyecto sino
para determinar su viabilidad, no tiene sentido iniciar un proyecto que est destinado al fracaso por no
contar con el tiempo, el esfuerzo o los recursos necesarios para llevarlo a cabo. En la actualidad son
muchos los proyectos que fracasan, e incumplen sus plazos de entrega. En la figura I se muestra un grfico
con el xito de proyectos de software por ao segn el Standish Group, aunque el grfico revele informacin
hasta el ao 2004 la realidad no es muy diferente en la actualidad.

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Figura I. xito de proyectos de software segn Standish Group.

La estimacin de tiempo y esfuerzo es til para la asignacin de recursos, apoya la evaluacin del impacto
de los cambios, y la reprogramacin de un proyecto, permite asignar recursos a los proyectos, facilita su
gestin y apoya planificaciones realistas permitiendo que los resultados sean ms consistentes con lo
planificado. Para que la estimacin sirva a estos fines debe ser lo suficientemente temprana y precisa. [2]
La actividad de estimar en proyectos de software es altamente complicada, en ocasiones se estima teniendo
un conocimiento mnimo del proyecto, no se cuenta con informacin histrica que pueda apoyar el proceso
de estimacin actual, pocas veces se obtienen especificaciones confiables y completas.
1.2.
El tamao en la estimacin
La precisin en una estimacin de proyectos de software se predice basndose en una serie de cosas, el
grado en el que el planificador ha estimado adecuadamente el tamao del producto a construir, la habilidad
de traducir la estimacin del tamao en esfuerzo humano, tiempo y dinero, el grado en el que el plan de
proyecto refleje las habilidades del equipo de software, la estabilidad de los requisitos de software y el
entorno que soporta el esfuerzo de la ingeniera de software. [2]
Como una estimacin de proyecto es tan buena como la estimacin del tamao del trabajo que va a llevarse
a cabo, el tamao representa el primer reto importante del planificador de proyectos. [2]
A diferencia de los objetos palpables, obtener el tamao en proyectos de software resulta complicado, los
profesionales del rea no han llegado a un consenso en cmo medirlo. Las lneas de cdigo (LOC) a pesar
de ser la medida ms utilizada dependen del ambiente de programacin, del lenguaje y de la habilidad del
programador. Las medidas de funcionalidad son otras de las ms frecuentes estas dependen mucho del
juicio de expertos.
Actualmente existen tcnicas de estimacin muy utilizadas alguna de ellas son las que se basan en Lneas
de cdigo Fuente, en Puntos de Funciones, y Casos de Uso.

TECNICAS DE ESTIMACION
1.3.
Puntos de Funcin de Albrecht.
El objetivo de esta tcnica es medir la cantidad de funcionalidad a partir de la especificacin de un sistema,
con independencia de la tecnologa con la que pudiera ser desarrollado.
Lo primero es calcular los puntos de funcin (PF) sin ajustar para lo cual que se requiere determinar:
Tipos de funcin de datos
Ficheros Lgicos Internos(ILF)
Ficheros de Interfaces Externos(EIF)
Tipos de Funciones de Transacciones
Entradas Externas(EI)
Salidas Externas(EO)
Consultas Externas(EQ)
Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Al identificar estos elementos se les clasifican de complejidad alta, media, baja y se le asigna un peso.
Luego se calculan los Puntos Funcionales sin ajustar sumando las cantidades de cada tipo de objeto
multiplicadas por su ponderacin. Luego se calculan los puntos funcionales ajustados multiplicndolos por
un factor de ajuste que se calculan tomando en cuentas 14 factores de complejidad tcnica. Estos factores
son valorados en una escala de 0 a 5. La valoracin de estos factores puede generar una variacin de ms
menos 35%. [3]
1.3.1. Algunos problemas con esta tcnica
Subjetividad en el factor tecnologa y en los pesos.
Uso temprano, se necesita una especificacin completa del sistema.
Su clculo no puede automatizarse completamente depende del juicio experto.
No son independientes de las metodologas de anlisis y diseo usadas.
No son sufrientemente tempranos para la gestin de proyectos ya que cuando se dispone de los
elementos para calcularlos se ha invertido entre el 15 y el 40% del esfuerzo .[4]
1.4.
Estimacin Basada en Casos de Uso
El mtodo utiliza los actores y casos de uso relevados para calcular el esfuerzo que significar
desarrollarlos. A los casos de uso se les asigna una complejidad basada en transacciones, entendidas como
una interaccin entre el usuario y el sistema, mientras que a los actores se les asigna una complejidad
basada en su tipo, es decir, si son interfaces con usuarios u otros sistemas. Tambin se utilizan factores de
entorno y de complejidad tcnica para ajustar el resultado.
Consta de cuatro etapas, en las que se desarrollan los siguientes clculos:
Factor de peso de los actores sin ajustar (UAW)
Factor de peso de los casos de uso sin ajustar (UUCW)
Puntos de caso de uso ajustados (UCP)
Esfuerzo horas-hombre
1.4.1. Factor de peso de los actores sin ajustar (UAW)
En la primera de estas etapas se cuenta con una descripcin de los casos de usos, donde se especifique
cual es la funcionalidad que cada uno debe brindar. El UUCP son los puntos de casos de uso sin ajustar
para tener una idea de la dificultad de los casos de uso e interfaces, tomando en cuenta los pesos de los
actores (UAW) y los pesos de los casos de uso (UUCW). UUCP = UAW + UUCW.
El UAW se calcula determinando si cada actor es una persona u otro sistema, adems evala la forma en la
que este interacta con el caso de uso, y la cantidad de actores de cada tipo. Se le asigna un valor que
puede ser Simple (Otro sistema que interacta con el sistema a desarrollar mediante una interfaz de
programacin (API)), Medio (Otro sistema interactuando a travs de un protocolo (ej. TCP/IP) o una persona
interactuando a travs de una interfaz en modo texto) o Complejo (Una persona que interacta con el
sistema mediante una interfaz grfica (GUI)). Se cuentan los actores de cada tipo que fueron identificados y
se multiplican por su factor correspondiente para obtener el resultado por cada tipo de actor, luego se
suman cada producto para obtener el UAW.
Tipo de
actor

Descripcin

Factor

Simple

Otro sistema que interacta con el sistema a desarrollar mediante una interfaz de
programacin (API).

Medio

Otro sistema interactuando a travs de un protocolo (ej. TCP/IP) o una persona

interactuando a travs de una interfaz en modo texto.

Complejo

Una persona que interacta con el sistema mediante una interfaz grfica (GUI).

Tabla 1: Peso de los actores sin ajustar.

La frmula sera: UAW = Sum(cantidadDeUnTipoDeActor*Factor)
1.4.2. Factor de peso de los casos de uso sin ajustar (UUCW)
Para determinar el factor de peso de los casos de uso sin ajustar (UUCW) se procede de manera muy
similar al anterior, pero para determinar el nivel de complejidad se puede realizar mediante dos mtodos:
basado en transacciones o basado en clases de anlisis. En ambos mtodos se le asigna una clasificacin
correspondiente a las transacciones o a las clases que pueden ser Simple, Medio o Complejo, se le asigna
un factor dependiendo de la clasificacin anterior, este se multiplica por la cantidad de elementos que son
clasificados de la misma manera y luego se suman los tres productos.
Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Basado en transacciones: Toma en cuenta el nmero de transacciones que se pueden realizar en un caso
de uso y lo evala segn la siguiente tabla:
Tipo de caso de uso Descripcin

Factor

Simple

3 transacciones o menos 5

Medio

4 a 7 transacciones

Complejo

Ms de 7 transacciones 15

10

Tabla 2: Peso de las transacciones.

Basado en clases de anlisis.
Toma en cuenta el nmero de clases que tiene un caso de uso y lo evala segn la siguiente tabla:
Tipo de caso de uso Descripcin

Factor

Simple

Menos de 5 clases 5

Medio

5 a 10 clases

Complejo

Ms de 10 clases 15

10

Tabla 3: Peso de las clases de anlisis.

1.4.3. Puntos de caso de uso ajustados (UCP)
Para determinar los puntos de casos de usos ajustados esto se utilizan las siglas UCP y se obtiene al
multiplicar el UUCP (puntos de casos de usos sin ajustar) el TCF (Factores Tcnicos) y el EF (Factores
ambientales) quedando la operacin de la siguiente forma:
UCP = UUCP x TCF x EF
Factores de complejidad tcnica
Este se compone de 13 puntos que evalan la complejidad de los mdulos del sistema que se desarrolla,
cada uno de estos factores tienen un peso definido con los cuales se obtendr puntos ponderados por cada
uno de ellos, segn la valoracin que se le asigne. Para una mejor comprensin, a continuacin se mostrar
una tabla con los tems:
Factor Descripcin

Peso

T1

Sistema distribuido.

T2

Objetivos de performance o tiempo de respuesta.

T3

Eficiencia del usuario final.

T4

Procesamiento interno complejo.

T5

El cdigo debe ser reutilizable.

T6

Facilidad de instalacin.

0.5

T7

Facilidad de uso.

0.5

T8

Portabilidad.

T9

Facilidad de cambio.

T10

Concurrencia.

T11

Incluye objetivos especiales de seguridad.

T12

Provee acceso directo a terceras partes.

T13

Se requiere facilidades especiales de entrenamiento a usuario. 1

Tabla 4: Peso de los factores de complejidad tcnica.

Cada uno de estos puntos se debe evaluar segn la siguiente escala:
Descripcin Valor
Irrelevante De 0 a 2.
Medio

De 3 a 4.

Esencial

Tabla 5: Escala de los factores de complejidad tcnica.

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Las frmulas para este punto son:

TFactor = Sum (Valor*Peso)
TCF = 0.6 + (0.01 * TFactor)
Para realizar este clculo, se debe evaluar cada factor, asignndole un valor como se menciona
anteriormente, despus se multiplican y se suma cada producto para obtener el TFactor. Luego, se debe
seguir la segunda frmula multiplicando el TFactor por 0.01 y sumar el resultado a 0.6, esto nos va a dar el
TCF.
Los factores sobre los cuales se realiza la evaluacin son 8 puntos, que estn relacionados con las
habilidades y experiencia del grupo de personas involucradas con el desarrollo del proyecto. Estos factores
se muestran a continuacin:
Factor Descripcin

Peso

E1

Familiaridad con el modelo de proyecto utilizado. 1.5

E2

Experiencia en la aplicacin.

0.5

E3

Experiencia en orientacin a objetos.

E4

Capacidad del analista lder.

0.5

E5

Motivacin.

E6

Estabilidad de los requerimientos

E7

Personal part-time

-1

E8

Dificultad del lenguaje de programacin

-1

Tabla 6: Peso de los factores ambientales.

Cada uno de estos factores se debe calificar con un valor de 0 a 5.
Las frmulas para este punto son:
EFactor = Sum(Valor * Peso)
EF = 1.4 + (-0.03 * EFactor)
Para obtener el EFactor se debe sumar todos los productos obtenidos al multiplicar el peso de cada punto
por el valor asignado, despus se multiplica por -0.03 y se le suma el 1.4. As, se obtiene el peso de los
factores ambientales (EF).
1.4.4. Esfuerzo horas-hombre
EL clculo del Esfuerzo horas-hombre se realiza con el fin de tener una aproximacin del esfuerzo,
pensando solo en el desarrollo segn las funcionalidades de los casos de uso. Anteriormente, se sugera
utilizar 20 horas persona por UCP, pero a travs del tiempo se ha ido mejorando. En este clculo intervienen
los factores ambientales y los dems elementos hallados en clculos anteriores.
Primero se debe contar la cantidad de factores ambientales del E1 al E6 que tienen una puntuacin menor a
3, tambin contar la cantidad de estos mismos del E7 y E8 que son mayores que 3.
Factor

Filtro

De E1 a E6 Factor < 3
De E7 a E8 Factor > 3
Tabla 7: Factor de el esfuerzo horas-persona.
Para evaluar el resultado o la cantidad total segn la siguiente tabla:
Horas-Persona (CF) Descripcin
20

Si el valor es<=2

28

Si el valor es<=4

36

Si el valor es>=5

Tabla 8: Cantidad de horas-persona segn el valor.

El esfuerzo en horas-persona viene dado por:
E = UCP x CF
Estas siglas significan:
E: Esfuerzo estimado en horas-persona.
UCP: Puntos de Casos de Uso ajustados.
CF: Horas-Persona.
Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Al realizar la multiplicacin del UCP por las horas- persona, se consigue un esfuerzo estimado, que
representa una parte del total del esfuerzo de todo el proyecto, generalmente un 40%. Este 40% se refiere
al esfuerzo total para el desarrollo de las funcionalidades especificadas en los Casos de Uso.
En la siguiente tabla se detallan la distribucin en porcentaje, para el esfuerzo total en el desarrollo del
proyecto:
Actividad

Porcentaje

Anlisis

10%

Diseo

20%

Programacin 40%
Pruebas

15%

Sobrecarga

15%

1.5.
Modelos paramtricos de estimacin. COCOMO II
Es un modelo emprico basado en la experiencia con proyectos (grandes). Es un mtodo bien documentado,
cuya primera versin se public en 1981. La ltima versin, COCOMO 2, tiene en cuenta diferentes
aproximaciones de desarrollo, reutilizacin, etc.
Modelo de fase posterior a la arquitectura.
Requisitos establecidos.
Arquitectura bsica del software establecida.
Construccin del software
Modelos con una estructura comn y una serie de parmetros que se pueden calibrar sobre una base de
proyectos previos.
1.6. Conclusiones sobre las tcnicas presentadas
Estas tcnicas se aplican despus que el proyecto a avanzado en ms de un 15%, o sea que ya se ha
consumido parte del esfuerzo y el tiempo que ocupa al equipo de desarrollo, por tanto la estimacin se har
en base al tiempo restante, para la estimacin basada en LOC, en PF as como en la que se basa en casos
de uso el proyecto necesita estar avanzado, las especificaciones deben de ser completas y con un mnimo
de posibilidad de ser alteradas.
La estimacin ser ms segura cuando ms elementos se tengan disponibles, a medida que ms se
avance en el proyecto menor ser la incertidumbre, pero el objetivo de la estimacin es predecir lo que
ocurrir y dejara de cumplirlo cuando ms adelantada se realice es por eso que se debe estimar en etapas
lo ms tempranas posible aun cuando el margen de error es mayor.
Uno de los problemas que se tiene para estimar correctamente es que las tcnicas de estimacin
presentadas como se menciono anteriormente se logran ya avanzado el proyecto en ms de 15 %, por lo
que se debe trabajar en encontrar una manera de estimar en fases ms temprana.
La identificacin de modelos de Negocio en las instituciones es algo que podra solucionar el problema
planteado anteriormente, en el momento de desarrollar un sistema informtico se debe identificar el proceso
o los procesos que sern automatizado, describir con seriedad esos proceso y modelarlo en algunos de los
software existentes los lenguajes que se usan con este fin. De esta manera a partir del modelado de
procesos se obtendran una serie de variables como Actividades, Roles, Entradas, Salidas, Entidades,
Funciones, etc. que serian usadas en funcin de la estimacin. Esta es una idea que est siendo trabajada
en la actualidad.

CONCLUSIONES
A diferencia de los productos industriales, tangibles la produccin de software genera productos intangibles
requiere de mucha comunicacin, intercambio entre todos las personas que intervienen en el proceso,
clientes, desarrolladores, usuarios por lo que hay un mayor grado de subjetividad, esto hace que la
estimacin sea una actividad difcil de implementar para este tipo de producto.
La dificultad que se impone para estimar no deja que esta sea una actividad trivial a la que no se considere
importante y se pueda prescindir de ella, pues es la estimacin una de las actividades principales que
intervienen en el proceso de desarrollo. Muchos de los procesos fracasan por no realizar con seriedad esta
actividad.
Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Se han desarrollado numerosos mtodos para estimar pero un gran numero con deficiencias a considerar, la
mayora permite estimar despus de un tiempo avanzado el proyecto lo que deja de considerar una etapa
en el proceso que no debe dejare de tener en cuenta. Tcnicas como Puntos de Funcin de Albrecht, las
basadas en Casos de Uso, el mtodo del COCOMO II, son algunas de las ms usadas pero que son
dependientes del juicio experto por lo que no estn desprovistas de la subjetividad.
Es necesario trabajar en la confeccin de tcnicas de estimacin que se puedan llevar a cabo en etapas
tempranas del desarrollo de software y que disminuyan el grado de subjetividad.
Referencias Bibliogrficas
[1] Rogers S. Pressman, INGENIERIA DEL SOFTWARE UN ENFOQUE PRACTICO.
[2] Morgan, JA Software Development Cost Estimation for Higher Level LenguageEnvironments ABAS
ACADEMYOF BUSINESS & ADMINISTRATIVE SCIENSE
[4] Meli R., Santillo L. FUNCTION POINT ESTIMATION METHODS

Bibliografia
Tesis Doctoral Modelos Automatizables de Estimacin muy Temprana del Tiempo y Esfuerzo de Desarrollo
de Sistemas de Informacin PEDRO_SALVETTO_LEON.
Rogers S. Pressman, INGENIERIA DEL SOFTWARE UN ENFOQUE PRACTICO
Reportes Tcnicos en Ingeniera de Software Vol. 6 N 1 (2004), pg. 1-16. ESTIMACIN DEL ESFUERZO
BASADA EN CASOS DE USO. Mario Peralta
Autor:
Lianny OFarrill Fernndez
lofarrill@uclv.edu.cu
Universidad Central Marta Abreu de las Villas
Santa Clara, Cuba
01 de mayo de 2015

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com