Estimación del Esfuerzo en Proyectos Informáticos

Planeación y Gestión de
Proyectos Informáticos

Parte 2: Estimación del Esfuerzo

Material académico preparado por:
Ph.D, Marta Silvia Tabares B.
Universidad de Medellín
Fecha de última actualización: 5-Sep-2011

Bibliografía
• Jose Onofre Montesa Andrés. ESTIMACIÓN DEL ESFUERZO EN EL
DESARROLLO DE SOFTWARE. Universidad Politécnica de Valencia, Escuela
Universitaria de Informática. 2000.
• Roger Pressman. Ingeniería del Software (6ª ED.). Mcgraw-hill /
Interamericana.2006.
• Ian Sommerville. Ingeniería de Software (6ª ED.). Addison Wesley. 2002.
• Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis
and Design with UML Version 2.0 - An Object Oriented Approach, Second
Edition. John Wiley & Sons © 2005.
• Carroll, E.R., “Estimating Software Based on Use Case Points”. Proc. In
OOPSLA’05, Oct.2005, USA. Pag: 257-265.

Escenario de la Gestión del Proyecto

Factibilidad del
Gestión del Proyecto
Proyecto

Cronograma de
Recursos Monitoreo del Riesgos
Actividades

TAREAS DE SOPORTE

Normas de Validación y Gestión del Trazabilidad
Calidad Verificación Cambio (Rastreabilidad)

Material Preparado por MARTA SILVIA TABARES B. - UdeM

Problemática de la estimación
• Averiguar lo que costara de desarrollar una
aplicación.(meses-persona, ptas., …)
• Momento en que se desea conocer el coste
(gráfico de Boehm)
• Siempre se quiere muy pronto (Yourdon)

4

Precisión de las estimaciones en
función de la fase del proyecto.
4.5
4
3.5
3
2.5
2
1.5
1
0.5
0
Viabilidad

Planificación

Detallado
General

Entrega
Desarrollo y
Diseño
y requisitos

Diseño

test
5


Proceso de Estimación propuesto

Especificación de Requisitos a
requerimientos Cumplir Tareas a
realizar

Medir lo que
Estimación Descomponer
quiere el
del Esfuerzo por fases y
usuario tareas

Estimar lo
Medida de lo que que Costara
(esfuerzo) Historial
quiere el usuario Empresa

6

Estimar desde la Experiencia

Experiencia Individual

Experiencia de Empresa

7

Métodos utilizados para la estimación
de proyectos
• Basados en la experiencia.
• Basado exclusivamente en los recursos
• Método basado exclusivamente en el
mercado.
• Basado en los componentes del producto o en
el proceso de desarrollo.
• Métodos algorítmicos

8

Métodos basados exclusivamente en
la experiencia:
• Juicio experto
– Puro
– Delphi
• Analogía
• Distribución de la utilización de recursos en el
ciclo de vida

9

Juicio experto: Puro
• Un experto estudia
las especificaciones y
haces su estimación.
• Se basa
fundamentalmente
en las vivencias en
proyectos anteriores.
• Si desaparece el
experto, la empresa
se arriesga a estimar
de forma incorrecta

10

Juicio experto: Grupal

• Un grupo de expertos son
informados del proyecto y tratan
de establecer el costo del
desarrollo tanto en esfuerzo,
como su duración.

• Las estimaciones
en grupo suelen
ser más asertivas que
las individuales. Al menos hay
menos margen del error o en su
defecto varios lo comparten.


Método de trabajo del Wideband
Delphi
• Se dan las especificaciones a un grupo de expertos.
• Se les reúne para que discutan tanto el producto como la
estimación.
• Remiten sus estimaciones individuales al coordinador.
• Cada estimador recibe información sobre su estimación, y las
ajenas pero de forma anónima.
• Se reúnen de nuevo para discutir las estimaciones.
• Cada uno revisa su propia estimación y la envía al coordinador.
• Se repite el proceso hasta que la estimación converge de forma
razonable.

12

Analogía

Consiste en comparar las
especificaciones de un
proyecto, con las de otros
proyectos.

13

Analogía, pueden variar los siguientes
factores:
• Tamaño: ¿mayor o menor?
• Complejidad: ¿Más complejo de lo usual?
• Usuarios: Si hay más usuarios habrán más
complicaciones.
• Otros factores:
• Sistema Operativo, entornos (la primera vez más).
• Hardware, ¿Es la primera vez que se va a utilizar?
• Personal del proyecto, ¿nuevos en la organización?

14

Distribución de la utilización de
recursos en el ciclo de vida
Usualmente las organizaciones tienen una
estructura de costos similar entre proyectos.
Se esperar que estos se distribuyan de
manera proporciona.

Estudio Planificación Diseño Desarrollo Prueba
Diseño
Viabilidad y Requisitos General Detallado

10% 17% 15% 15% 33% 10%

2 m. ?

15

Método basado exclusivamente en los
recursos
• La estimación consiste en ver de cuanto
personal y durante cuanto tiempo se
dispone de el, haciendo esa estimación.
• En la realización:
“El trabajo se expande hasta
consumir todos los recursos
disponibles”
(Ley de Parkinson)

16

Método basado exclusivamente en el
mercado
• Lo importante es conseguir el
contrato.
• El precio se fija en función de lo
que creemos que esta dispuesto
a pagar el cliente.
• Si se usa en conjunción con
otros
métodos puede ser aceptable,
para ajustar la oferta.
• Peligro si es el único método
utilizado.
17

Basado en los componentes del
producto o proceso de desarrollo:
• Bottom-up
– Se descompone el proyecto en
las unidades lo menores
posibles.
– Se estima cada unidad y se
calcula el coste total.
• Top-Down
– Se ve todo el proyecto, se
descompone en grandes
bloques o fases.
– Se estima el coste de cada
componente.
18

Métodos algorítmicos
• Se basan en la utilización de fórmulas que
aplicadas sobre modelos top-down o bottom-
up producen una estimación de coste del
proyecto
u
v
f(x)
x
Aplicación a Costo
desarrollar y
...
z

19

Putnam

• Relaciona cantidad de personas-
mes y la duración del proyecto.
• Y=2Kate-at²
Y = Personas-mes en cada punto 16
Esfuerzo
14
K = Esfuerzo total del proyecto, 12
Asignado

(Área bajo la curva) 10
8
a = Cte. asociada a la aceleración 6
de entrada de personas en el 4
2
proyecto, 0
t = instante del tiempo.
0
2
4
6
8
10
12
14
16
18
20
22
24
Meses de Desarrollo

20

COCOMO
• Partimos de conocer el número de líneas que
tendrá la futura aplicación.
• Orgánico, hay otros dos
– MM-nominal = 3.2 (KLOC)1.5
– T.desarrollo= 2.5 (MM)0.38

21

COCOMO
• Determinar los multiplicadores del esfuerzo:
– Tamaño B.D., experiencia analistas, herramientas,
… (15 en total, varían de 0.75-1.66)
• Estimación esfuerzo con las correcciones.
• Estimación de factores relacionados ($,
duración fases,…)

22

Métrica de los Puntos de Función

• Es una métrica que se puede aplicar en las
primeras fases de desarrollo.
• Se basa en características fundamentalmente
“Externas” de la aplicación a desarrollar.
• Mide dos tipos de características:
– Los elementos de función (entradas, salidas,
ficheros, etc.)
– Los factores de Complejidad.

23

Métrica de los Puntos de Función
• Partimos de los datos históricos de la
Organización
• Esfuerzo = PFA * Promedio ( Lenguaje)

24

Estimación del Esfuerzo por
Puntos de Casos de Uso (1)
• La estimación del esfuerzo de desarrollo o cambio cuando
el sistema está centrado en casos de uso tiene en cuenta
los diferentes elementos de modelo que se describen en
un modelo de casos de uso más otras características
asociadas al proceso:
– Actores
– Casos de Uso
– Factores Técnicos
– Factores de Experiencia
– Riesgos


• ACTORES: El proceso comienza considerando a los Actores. Para cada actor, se determina si el actor es un actor
simple, medio o complejo.
– Un actor simple representa otro sistema con una
– Interfaz de Programación de Aplicación (API) definida.
– Un actor medio es uno que otro sistema que se relaciona por un protocolo como TCP/IP, o es una persona que
se relaciona por una interfaz basada en texto.
– Un actor complejo es una persona que interactúa a través de una interfaz gráfica de usuario (GUI).
• Cuente el total de actores simples, medios y complejos y multiplique a la cantidad de cada tipo de tipo de actor el
factor de ponderación y sume el total, como se muestra en la figura.

Ponderación de Actores (Weighted Actors) por Complejidad

[Carroll 2005]


• CASOS DE USO: Para cada caso de uso, determine si es simple, medio o complejo
basado en el número de transacciones en un caso de uso, incluyendo escenarios
secundarios. Para este fin, una transacción es definida como un juego atómico de
actividades (pasos del flujo principal) que se realizan completamente o nada en total.
– Un caso de uso simple tiene 3 o menos transacciones.
– Un caso de uso medio tiene 4 a 7 transacciones.
– Un caso de uso complejo tiene más de 7 transacciones.

• Si las clases de análisis han sido definidas para el sistema, y también ha sido identificado
en cuanto a cuales son usados para poner en práctica un caso de uso particular, se debe
usar esta información en el lugar de transacciones para determinar la complejidad de
caso de uso. Nota: los casos de uso incluidos o los casos de uso que extienden no tienen
que ser considerados.

[Carroll 2005]


• Ponderación de los casos de uso:
– Cuente el total de casos de uso simple, medios y complejos y multiplique las
cantidades de cada tipo de caso de uso el factor de ponderación y sume el total.

Ponderación de Casos de Uso (Weighted Use Cases) por Complejidad

Unadjusted Use Case Points (UUCP)

UUCP = Weighted Actors + Weighted Use Cases
UUCP = 10 + 50 = 60
[Carroll 2005]


• Factores Técnicos: La ponderación de los

Ponderado de factores técnicos (Weighting Technical Factors)
factores técnicos es un ejercicio para
calcular un modificador del Punto de
Caso de Uso (UUCP) por el peso de los
factores técnicos. Esto inicia calculando
la complejidad técnica del proyecto
(llamado el factor de complejidad
técnico - TCF).
– Para calcular el TCF se tienen en
cuenta los factores definidos en la
siguiente tabla y la tasa promedio
de cada factor entre 0 a 5. Una
posición de 0 significa que el factor
es irrelevante para este proyecto, 5
significa que es esencial. Por cada
factor se multiplican su tasa por su
peso de la tabla.

[Carroll 2005]


• Para una nueva ponderación se adicionan los valores resultantes para obtener el factor
T (T factor). El Tfactor no modifica directamente el UUCP.
– Tfactor = (Weighting Factor) * Σ(Tlevel)
• Para calcular el factor de complejidad técnica (TCF), se multiplica el Tfactor por 0.01 y se
adiciona 0.6.
– TCF = (0.01 * Tfactor) + 0.6
• entonces
– TCF = (0.01 * 42) + 0.6 = 1.02
• Para calcular el tamaño del proyecto de software por casos de uso se multiplica el
factor de complejidad técnica por el UUCP.
– SzUC = UUCP * TCF
• entonces
– SzUC = 60 * 1.02 = 61.2
[Carroll 2005]


• Factores de Experiencia: El nivel de experiencia para cada miembro de equipo puede afectar la
exactitud de una estimación. Considere el nivel de experiencia para cada miembro de equipo,
llamado el factor de Experiencia (EF).

Ponderación del Factor de Experiencia (Weighting Experience Factors)

[Carroll 2005]


• Factores de Experiencia: Para calcular el EFactor (EF), de la tabla la tasa (rating) de cada
factor de 0 a 5.
– Para los factores E1-E4, 0 significa no experiencia en el factor evaluado, 3 significa
promedio, y 5 significa experto.
– Para E5, 0 significa que no hay motivación en el proyecto, 3 significa promedio, y 5
significa alta motivación.
– Para E6, 0 significa que no encaja con los requisitos, 3 significa un monto promedio de
cambio experado, y 5 significa requisitos extremadamente inestables.
– Para E7, 0 significa que el personal técnico no es medio tiempo, 3 significa en promedio
metad de grupo es medio tiempo, y 5 significa que todos los del grupo son de medio
tiempo.
– Para E8, 0 significa que se planea un fácil uso de lenguajes de programación, 3 significa
que el lenguaje es de dificultdad promedio, y 5 significa que se detecta mucha dificultad
de abordar el lenguaje para el proyecto.

[Carroll 2005]



• Por cada factor se multiplica su tasa (rating) por su valor ponderado. Todos estos se suman
para obtener el factor E.
• Efactor = (Weighting Factor) * Σ(Tlevel)
• Calculo del Factor de Experiencia (EF) multiplicado por –0.03 y adiciona 1.4.
– EF = (-0.03 *Efactor) + 1.4
– EF = (-0.03 * 12) + 1.4 = 1.04
• Para calcular los Puntos de Casos de Uso (UCP), multiplica el SzUC por el EF
– UCP = SzUC * EF
– 61.2 * 1.04 = 63.648
– ó UUCP * TCF * EF = UCP = 60 * 1.02 * 1.04 = 63.648

[Carroll 2005]



• Cálculo de las Horas-Hombre: Las horas-hombre por UPC es el cálculo de
la tasa de esfuerzo (ER) multiplicada por el valor del número de UCPs.
Datos históricos para un conjunto de proyectos podría ser un ER de 28
horas-hombre por UCP. Pero como no todos los proyectos son del mismo
tipo o el mismo alcance, el grupo de desarrollo podría decidir por una tasa
de 20 horas-hombre por UCP en proyectos simples.

• Los ER se determinan de acuerdo a los datos históricos de la gestión de
proyectos y el tipo de proyecto.

[Carroll 2005]


• Para el ejemplo, se podría tener esta situación: Se cuentan el número de factores de E1-E6 cuya tasa
está por debajo de 3 y el número de factores de E7-E8 que están por encima de 3.
– Si el total es 2 o menos, entonces use 20 horas-hombre por UCP.
– Si el total es 3 ó 4, entonces use 28 horas-hombre por UCP.
– Si el total es 5 o más entonces se considera reestructurar el equipo del proyecto ya que el
número de caidas será al menos por debajo de 5. Un valor de 5 indicates que el proyecto es
riesgoso y fallará con dicho grupo.

• Calculo de las horas-hombre:
– total horas-hombre =ER * UCP
– = 20 * 63.648 = 1,272.96 horas-hombre
– ó 28 * 63.648 = 1,782.144

• Las horas-hombre se deben ajustar por un factor o coheficiente de riesgo general o dado por cada
tipo de riesgo identificado para el proyecto. Por ejemplo:
– (1.0 + .05[%]) * 1,782.144 = 1,871.25 (horas-hombre ajustadas al proyecto)

[Carroll 2005]


La Experiencia y la Estimación
• La estimación del esfuerzo tiene una dependencia directa con el modelo de
desarrollo o metodología de desarrollo del proyecto utilizada por la organización o
gerencia del proyecto.

• La experticia o conocimiento del experto es la característica más importante que
se debe tener en cuenta al momento de hacer una estimación del esfuerzo (por
eso no cualquiera hace esta tarea). Pero es bueno tener en cuenta modelos ya
existentes como base de dicha estimación (p.ej.: COCOMO I-II, puntos de función,
estimación por casos de uso, entre otros tantos).

• La estimación depende de varias variables tales como ambientales, técnicas,
operativas, relacionadas al recurso humano, etc.

• La estimación del esfuerzo es una base para planear la distribución de las tareas
que se hacen en el EDT para dar curso al cronograma de trabajo que será
ejecutado y controlado.

Estimación del Esfuerzo en Proyectos Informáticos

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (10)

Similaire à Estimación del Esfuerzo en Proyectos Informáticos

Similaire à Estimación del Esfuerzo en Proyectos Informáticos (20)

Plus de Marta Silvia Tabares

Plus de Marta Silvia Tabares (20)

Dernier

Dernier (15)

Estimación del Esfuerzo en Proyectos Informáticos