Ingeniería de Software I INF – 2720 – “A”

CAPITULO IV
Estimación de Costos de un Proyecto de Software
4.1. La importancia de estimar los costos.

☻La estimación de lo que costará el desarrollo de un software

☻Es una de las actividades de planeación que reviste especial
importancia,
☻Una de las características que debe tener un producto de software
 Es que su costo sea adecuado,
 De lo contrario el proyecto puede fracasar.
“Apreciar, poner precio, evaluar algo”

☻Las estimaciones están asociadas con el esfuerzo, costo y el tiempo

de las actividades identificadas del proyecto.
☻El objetivo de la estimación de proyectos es reducir los costos e
incrementar los niveles de servicio y de calidad.

4.2. Técnicas de estimación de costos de Software

☻Utilizar técnicas de descomposición relativamente sencillas para

generar las estimaciones de costos y esfuerzo del proyecto.
(“divide y vencerás”)

☻Se han de establecer de antemano el ámbito del proyecto.

☻Como bases para la realización de estimaciones se usan datos de
software de proyectos pasados.
☻El proyecto se descompone en partes más pequeñas que se
estiman individualmente.

Dos tipos de enfoque:

 Directo: se utilizan las LDC para medir el tamaño.
 Indirecto: el tamaño se representa mediante puntos de
función (PF).

1
Ingeniería de Software I INF – 2720 – “A”

☻El valor esperado para la variable de estimación, E, puede

obtenerse como una media ponderada de las estimaciones LDC o
PF optimista (a), más probable (m), y pesimista (b) de las
estimaciones LDC o PF por ejemplo:
E = (a + 4m + b)/6

 Opinión de expertos
 Estimaciones análogas
 Técnicas de descomposición
 Modelos empíricos de estimación

4.3. La técnica del juicio del experto

 Barbara Kitchenham -> “adivinación basada en la experiencia

personal”
 Sistematización y mejora de opiniones de diversas personas
 Medias aritméticas
 Búsquedas de consensos

 La técnica más utilizada para la estimación de costos es el uso del

juicio experto, que además es una técnica de tipo jerárquica hacia
abajo.

 El juicio experto se basa en la experiencia, en el conocimiento anterior

y en el sentido comercial de uno o más individuos dentro de la
organización.
 La mayor ventaja del juicio experto, que es la experiencia, puede llegar
a ser su debilidad; el experto puede confiarse de que el proyecto sea
similar al anterior; pero bien puede suceder que haya olvidado algunos
factores que ocasionan que el sistema nuevo sea significativamente
diferente; o, quizás, el experto que realiza la estimación no tenga
experiencia en ese tipo de proyecto.

 Para compensar tales factores, los  expertos algunas veces en

conjunto tratan de llegar a un consenso en el estimado; lo anterior

2
Ingeniería de Software I INF – 2720 – “A”

tiende a minimizar las fallas individuales y la falta de familiaridad en

proyectos particulares neutralizando las tendencias personales y el
deseo de ganar (posiblemente inconsciente) un contrato a través de
una estimación optimista.

4.4. Estimación del costo por la técnica DELPHI

 La técnica DELPHI fue desarrollada en la corporación Rand en 1948,

 Con el fin de obtener el consenso de un grupo de expertos sin contar

con los efectos negativos en las reuniones de grupos.

 La técnica puede adaptarse a la estimación de costos de la siguiente

manera:
1. Un coordinador proporciona a cada experto la documentación con la
definición del sistema y una papeleta para que escriba su
estimación.
2. Cada experto estudia la definición y determina su estimación en
forma anónima; los expertos pueden consultar con el coordinador,
pero no entre ellos.
3. El coordinador prepara y distribuye un resumen de las estimaciones
efectuadas, incluyendo cualquier razonamiento extraño efectuado
por alguno de los expertos.
4. Los expertos realizan una segunda ronda de estimaciones, otra vez
anónimamente, utilizando los resultados de la estimación anterior.
En los casos que una estimación difiera mucho de las demás, se
podrá solicitar que también en forma anónima el experto justifique su
estimación.
5. El proceso se repite tantas veces como se juzgue necesario,
impidiendo una discusión grupal durante el proceso.
Ventajas
 Comparación de experiencias anteriores y el proyecto anterior
Inconvenientes
 Subjetividad de las personas
 Inexperiencia de las personas

3
Ingeniería de Software I INF – 2720 – “A”

4.5. Estimación del costo por división de trabajos

 Problemas complejos como para considerarlos en su totalidad

 Aplicar soluciones del tipo divide y vencerás
 Se obtienen así una serie de problemas más pequeños y
manejables
Pasos a seguir
 Descomposición del software funciones que pueden ser estimadas
de forma individual
 Elección de una variable de estimación, y realizar las estimaciones
sobre esa variable para cada una de las funciones
 Aplicación de las métricas de productividad a la variable de
estimación apropiada y se obtiene el coste y el esfuerzo para cada
función

4.6. Modelo de costo por algoritmo o módulo

4.7. Modelos de estimación

 Orientados a LDC y PF
 Orientado a los casos de uso
Empíricos
 Jerarquía de modelos COCOMO
 COCOMO Básico
 COCOMO Intermedio
 COCOMO Avanzado

4
 Tipo de actor Descripción Factor
Ingeniería de Software I INF – 2720 – “A”
Simple Interfaz de programación de aplicaciones 1
Promedio Interfaz de comunicación vía protocolo 2
Complejo Interfaz gráfica de usuario 3

Estimación Orientada a los casos de uso

 Se calcula teniendo en cuenta:
o Peso de los actores
o Pesos de los casos de uso
o Pesos de los factores técnicos
 Después de redondea a través de estimaciones a criterio del jefe de
proyecto.
 Peso de los actores
Tipo de actor Descripción Factor
Simple Interfaz de programación de aplicaciones 1
Promedio Interfaz de comunicación vía protocolo 2
Complejo Interfaz gráfica de usuario 3

Finalmente, se cuentan los actores de acuerdo a su

clasificación o grado de complejidad, multiplicando cada
subtotal por su factor de complejidad y sumando cada producto
obteniéndose el peso de los actores sin ajustar (PASA).

 Peso de los casos de uso

☻ Casos de Uso Simple: Tres o menos transacciones (o pasos).
☻ Casos de Uso Promedio: entre 4 o 7 Transacciones.
☻ Casos de Uso Complejos: Más de 7 Transacciones.

Los factores de peso asociados a la clasificación son los

siguientes:

Tipo caso de uso Descripción Factor

Simple 3 o menos transacciones 5
Promedio de 4 a 7 transacciones 10
Complejo más de 7 transacciones 15

5
Ingeniería de Software I INF – 2720 – “A”

Al igual que las clasificación de los actores las cuentas de las

transacciones de los casos de uso se multiplican por los
factores de complejidad y finalmente se suman los productos
obteniéndose el peso de las transacciones sin ajustar (PTSA)

 Obtención de Factores de Peso o Puntos de Casos de Uso Sin

Ajustar (PCUSA).

Es la suma del Peso de los Actores Sin ajustar más el Peso de las
Transacciones Sin Ajustar, es decir:

PCUSA = PASA + PTSA

 Cuantificación de características no funcionales del Sistema.

El método considera las características de complejidad técnica

tomando en cuenta algunos requerimientos no funcionales como un
factor de ajuste al Sistema, y además, factores ambientales que se
concentran en las características del equipo de desarrollo.

En ambos casos m, se debe evaluar cada Factor multiplicado por un

valor que corresponde a los siguientes grados de influencia:
o 0: Sin influencia
o 3: Promedio
o 5: Fuerte influencia

 Clasificación de Factores de Complejidad Técnica (FCT)

Se adjunta tabla con los factores de peso que incorporan la
complejidad técnica del sistema y algunas características no
funcionales, en este caso, en cada uno de los ítems se tomaron en
cuenta factores de complejidad propios de sistemas desarrollados
bajo orientación a objetos.

6
Ingeniería de Software I INF – 2720 – “A”

Factor Descripción Factor de Peso

T1 Sistema Distribuido 2
T2 Rendimiento o tiempo de respuesta 2
T3 Eficiencia del usuario final 1
T4 Complejidad de procesamiento interno 1
T5 Reusabilidad del código 1
T6 Facilidades de intalación 0.5
T7 Facilidades de uso 0.5
T8 Portabilidad 2
T9 Facilidades de cambio 1
T10 Concurrencia 1
T11 Características de seguridad 1
T12 Provee acceso directo a terceras partes 1
T13 Requerimientos de entrenamiento especial 1

Facto Descripción Factor de Peso Nivel Factor Peso*Nivel

r
0: Sin influencia
3: Promedio
5: Fuerte influencia
T1 2
2
1
T4 1
1
0.5
0.5
2
1
1
1
T12 1
T13 1

7
Ingeniería de Software I INF – 2720 – “A”

Total FactorT

 Para obtener el factor final se debe multiplicar cada item (T1 a T13)
por el grado de influencia sobre el sistema y se obtiene la suma
llamada FactorT, de acuerdo a la siguiente Fórmula:
FCT = 0.6 + (0.01*FactorT)
 Clasificación de Factores Ambientales (FA)

Corresponden en términos generales, las características del equipo

de desarrollo en cuanto a perfiles, experiencia y capacidad técnica.

Factor Descripción Factor de Peso

F1 Conocimiento del proceso de desarrollo 1.5
F2 Experiencia en la aplicación 0.5
F3 Experiencia en Orientación a objetos 1
F4 Capacidad de liderazgo de los analistas 0.5
F5 Motivación 1
F6 Estabilidad de los requerimientos 2
F7 Trabajadores part-time -1
F8 Dificultad de los lenguajes de programación 2

Facto Descripción Factor de Peso Nivel Factor Peso*Nivel

r
0: Sin influencia
3: Promedio
5: Fuerte influencia
F1 1.5
0.5
1
F4 0.5
1
2
-1
F8 2

8
Ingeniería de Software I INF – 2720 – “A”

Total FactorA

Para obtener el factor final se debe multiplicar cada item (F1 a F8)
por el grado de influencia sobre el sistema y se obtiene la suma
llamada FactorA, de acuerdo a la siguiente Fórmula:

FA = 1.4 + (-0.03*FactorA)

 Cálculo de Puntos de Casos de Uso Ajustados (PCU)

Finalmente, se obtiene la siguiente fórmula que representa los
puntos de casos de uso ajustados:
PCU = PCUSA* FCT*FA
 Estimación del esfuerzo
Estimación del proyecto

o Revisar EF, ¿Cuántos factores en la puntuación no llegan al

nivel promedio (3) de F1 – F6 y cuantos están por encima de 3
F7 y F8?
o (menos de 3) Horas hombre = 20 * PCU
o (menos de 5) Horas hombre = 28 * PCU
o (5 o más) Riesgo de no poder lanzarse el proyecto

 Resumen del esfuerzo se muestra en la siguiente tabla

Tiempo Esfuerzo
Actividad
(%) (horas/persona)
Análisis 10 176.4
Diseño 20 352.8
Programació 40 705.6
n
Pruebas 15 264.6
Sobrecarga 15 264.6
Total 100 1764.0

9
Ingeniería de Software I INF – 2720 – “A”

Finalmente

EP = 1764.0 (horas/persona)

8 horas laborales, 5 días a la semana, sueldo de 2000 bolivianos

10