- Qué es - Objetivo - Requisitos de un Estimador - Cuando se lleva a cabo - Técnicas de estimación - Métodos de estimación

1. Estimación de
proyectos de software
Andrés Felipe Montoya Ríos
re.vu/AndresMontoya
@montoya118
Edwar Andrés Ruiz Medina
@EdwarRuiz324

2. ¿Que es la estimación?
Estimación
“Apreciar, poner precio, evaluar algo”
Estimación de proyectos de software
“Actividad de la planificación del proyecto de sw
que intenta determinar cuánto dinero, esfuerzo,
recursos y tiempo tomará construir un sistema o
producto sw”.

3. ¿En qué consiste la estimación
de proyectos software?
 «Aplicación continua de
técnicas basadas en las
medidas de los procesos
de desarrollo del software
y sus productos, para
producir una información
de gestión significativa y a
tiempo. Esta información
se utilizará para mejorar
esos procesos los
productos que se obtienen
de ellos» (SYMONS, C.,
1998).

4. ¿Cuál es el objetivo de la
estimación?
 Predecir las variables involucradas en el proyecto con
cierto grado de certeza.
 Trata de aportar una predicción de algún indicador
importante para la gestión de proyectos de
software tiempo, esfuerzo, cantidad de defectos
esperados entre otros.
 Es razonable conocer, antes de comenzar a desarrollar
el SW, cuánto se va a invertir, qué tareas se deben
realizar y cuánto tiempo se necesitará.

5. ¿Quién es y cuál es el objetivo del
estimador de un proyecto software?
 El estimador debe ser un profesional que no tenga
ningún interés, directo o indirecto, en los resultados del
proceso de estimación y que este únicamente guiado
por su profesionalismo.
 El principal objetivo del estimador es obtener
estimaciones de calidad, las cuales no tienen siempre
por qué coincidir con las expectativas de la empresa
en términos de costo y tiempo.

6. Requisitos que debe cumplir
un buen estimador…
 Formación y experiencia profesional adecuada.
 Una posición en la organización que le permita adoptar un
juicio independiente.
 Debe basarse en un método que pueda ser explicado,
cuestionado, discutido y auditado.
 Debe poder describir su experiencia en cada estimación.
 Debe documentar su estimación, incluyendo los resultados
obtenidos y cualquier información necesaria para hacer el
proceso de estimación repetible y verificable.

7. ¿Cuándo se debe llevar a cabo?
La estimación es un proceso continuo. A
medida que el proyecto avanza, más se conoce
de él, y por lo tanto más parámetros están
disponibles para introducir en un modelo de
estimación.
La estimación continua nos permite el uso de un
único modelo coherente que pueda capturar y
utilizar la información sobre el proyecto a
medida que éste se conozca.

8. El proceso de estimación comienza usando
unas pocas variables claves para proveer las
«macrocaracterísticas» de un proyecto, y
evoluciona incorporando información de más
bajo nivel para producir las «micro-
características» del proyecto.

9. Ejemplo con un MCVS en
cascada

10. TÉCNICAS DE ESTIMACIÓN…

11. Técnicas de estimación…
 La opinión de los expertos
Esta técnica se basa en la experiencia profesional de
los Participantes en el proyecto de estimación.
 La analogía
o Se basa en la comparación directa de uno o más
proyectos pasados.
o Para poder utilizar esta técnica es necesario disponer
de una base de datos histórica de proyectos finalizados
con la que poder realizar la comparación.
o Los proyectos deben tener muchas similitudes en
cuanto a su esquema.

12. Técnicas de estimación…
 La descomposición
o Consiste en la descomposición de un producto en
componentes más pequeños, o descomponer un
proyecto en tareas de nivel inferior.
o La estimación se hace a partir del esfuerzo requerido
para producir los componentes más pequeños o para
realizar las tareas de nivel inferior.
 Las ecuaciones de estimación:
o Son fórmulas matemáticas que establecen la relación de
algunas medidas de entrada (que normalmente es la
medida del tamaño del producto) y determinan el
esfuerzo que se requerirá.

13. MÉTODOS DE ESTIMACIÓN…

14. Método de puntos de casos de uso
método de estimación y cálculo de tamaño del software basado en
cuentas hechas sobre los casos de uso para un sistema de
software.
 Cuantificación de características funcionales del Sistema:
o Clasificación de Actores,
o Clasificación de los Casos de Uso
o Obtención del Peso o Puntos de Casos de Uso
 Cuantificación de características no funcionales del Sistema:
o Clasificación de Factores de Complejidad Técnica (FCT)
o Clasificación de Factores Ambientales (FA)
o Cálculo de Puntos de Casos de Uso Ajustados (PCU)

15. Clasificación de Actores...
Todos los actores del sistema deben ser clasificados como
Simple, Promedio y Complejo:
 Actor Simple: Se trata de otro sistema interactuando a
través de una interfaz de programación definida y
conocida (API).
 Actor Promedio: Es otro sistema interactuando a través
de un protocolo (como TCP/IP).
 Actor Complejo: se trata de una persona interactuando
con el sistema a través de una interfaz gráfica de
usuario (GUI) o página Web.

16.  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).

17. Clasificación de Casos de Uso a
partir de las Transacciones
Teniendo el modelo de casos de uso, cada uno de ellos
debe clasificarse como Simple, Medio o Complejo, de
acuerdo al número de transacciones descritas en el caso
de uso. Se clasifican desacuerdo a lo siguiente:
 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.

18. Se cuentan los casos de uso de acuerdo a su
clasificación por numero de transacciones,
multiplicando cada subtotal por su factor de
complejidad y sumando cada producto
obteniéndose el peso de los actores sin ajustar
(PTSA).

19. 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

20. Clasificación de Factores de
Complejidad Técnica (FCT)
Son los factores de peso que incorporan la complejidad
técnica del sistema y algunas características no
funcionales, el peso se representa de la siguiente manera:
 0: Sin influencia
 3: Promedio
 5: Fuerte influencia

21. 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)

22. 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. Se
clasifican de la siguiente manera
0: Sin influencia
3: Promedio
5: Fuerte influencia

23. 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)

24. 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

25. MÉTODO DE ESTIMACIÓN
COCOMO
Cuando un ingeniero está ante un proyecto a
estimar, lo primero que debe hacer para aplicar
el COCOMO es situar su proyecto en el espacio
de dos dimensiones (modo, modelo).
Según COCOMO existen tres modos de
desarrollo, a cada uno de estos modos se le
pueden aplicar tres métodos de estimación
diferentes

26. Modo orgánico…
 El proyecto se desarrolla en equipos relativamente
pequeños
 Muchas personas relacionadas con el proyecto tienen
amplia experiencia trabajando en sistemas similares y
tienen un buen conocimiento de cómo el sistema que se
está desarrollando contribuirá a los objetivos de la
organización.
 Se desarrolla en un entorno generalmente estable, con
muy pequeña probabilidad de coincidencia en el desarrollo
de un nuevo hardware u operaciones desconocidas.
 Proyectos de tamaño relativamente pequeño. Como
máximo 50 KDSI (miles de instrucciones).

27. Modo semilibre…
El equipo del proyecto tiene un nivel medio de
experiencia en proyectos similares.
El equipo es una combinación de personal
experto e inexperto.
El tamaño del producto llega a las 300 KDSI.

28. Modo rígido…
 Proyectos que deben desarrollarse dentro de unas
limitaciones muy estrictas.
 El producto debe explotarse dentro de un entorno muy
acoplado de hardware, software, normativa y
procedimientos operativos
 Estos proyectos se desarrollan en áreas generalmente
desconocidas, lo cual lleva inicialmente a equipos
pequeños de analistas y, a una sobrecarga de
comunicación importante durante el desarrollo.
 Se aplica a proyectos de cualquier tamaño.

29. Modelo básico…
 Se suele aplicar en los desarrollos de productos
pequeños/medios Las ecuaciones de estimación de
esfuerzo y tiempo de desarrollo para cada modo de
desarrollo:
 Orgánico: MM = 2,4 (KDSI)1,05
TDEV = 2,5 (MM)0,38
 Semilibre: MM = 3,0 (KDSI)1,12
TDEV = 2,5 (MM)0,35
 Rígido: MM = 3,6 (KDSI)1,20
TDEV = 2,5 (MM)0,32

30. “KDSI = número de instrucciones de código en
miles.
MM = esfuerzo medido en meses/hombre.
TDEV = duración en meses”

31. Modelo intermedio…
Atributos del producto software:
 RELY: Fiabilidad requerida del software
 DATA: Tamaño de la base de datos.
 CPLX: Complejidad del producto.
 TIME: Limitaciones en el tiempo de ejecución
 STOR: Limitaciones de memoria principal.
 VIRT: Volatilidad de la máquina virtual
 TURN: Frecuencia de cambio en el modelo de
explotación del ordenador.

32. Atributos de personal
 ACAP: Capacitación de los analistas
 AEXP: Experiencia en aplicaciones.
 PCAP: Capacitación de los programadores
 VEXP: Experiencia en la máquina virtual.
 LEXP: Experiencia en el lenguaje de programación.
Atributos del proyecto
 MODP: Prácticas Modernas de programación.
 TOOL: Uso de herramientas para el desarrollo de
software.
 SCED: Limitaciones en la planificación.

34. La estimación de esfuerzo aplicando este
modelo es:
Modo orgánico: MM = 3,2 (KDSI) 1,05
Modo semilibre: MM = 3,0 (KDSI) 1,12
Modo rígido: MM = 2,8 (KDSI) 1,20

35. Modelo detallado…
Multiplicadores de esfuerzo por fases
En el modelo COCOMO intermedio, la distribución de
esfuerzo por fase se determina únicamente por el tamaño del
producto. En la práctica, factores como la fiabilidad
requerida, la experiencia en aplicaciones y desarrollos
interactivos afectan a unas fases más que a otras. El modelo
detallado proporciona un conjunto de multiplicadores de
esfuerzo para cada atributo en cada fase.
 Descomposición Jerárquica del producto a tres niveles:
 Nivel módulo.
 Nivel subsistema.
 Nivel sistema.

36. Modelo SLIM
 Está basado en la curva de Rayleigh, que describe la necesidad
de personal al desarrollar proyectos complejos.
 Fue desarrollada para estimar los costes de los grandes
proyectos de software. En proyectos pequeños haría falta
ajustar la ecuación.
o T= Tamaño en LDC
o C= factor dependiente del entorno ( (vale 2.000 para entornos poco
productivos, 8.000 para entornos buenos, 11.000 para entornos
excelentes)
o K= Esfuerzos de personas año
o Td= tiempo para completar el proyecto en años.

37. Conclusiones!!!