Post on 23-Feb-2023
Estimación de costes
Los requisitos en el coste de los proyectos software.José Luis Fernández Sánchez
Profesor titular ETSI IndustrialesUPM (Madrid, España)
jlfdez@etsii.upm.es
Junio 2014Jose Luis Fernández Sánchez-
UPM 2
Contenido1. Estado de la practica de la estimación en la
industria del software
2. La estimación en el ciclo de vida del desarrollo software
3. Principales técnicas de estimación� Método de Delphi extendido
� Parkinson
� Punto Función
� Paramétricas
� La técnica de estimación basada en casos de uso
4. Conclusión y Recomendaciones
Junio 2014Jose Luis Fernández Sánchez-
UPM 3
1. Estado de la práctica
� Muchos proyectos de desarrollo software fracasan por falta de estimaciones de esfuerzo y duración rigurosas
� En muchos casos las técnicas utilizadas por la industria son:
� ninguna
� basadas en el presupuesto disponible
� por experiencia
Junio 2014Jose Luis Fernández Sánchez-
UPM 4
2. La estimación en el ciclo de vida
Estimaciónbasada enalcance
Estimaciónbasada enla funcionalidad
Estimaciónbasada enla implementación
Precisión: + - 50%
Precisión: + - 25%
Precisión: + - 10%
La precisión de la estimación depende de los datos de entrada que se utilicen para realizarla y de la fase del ciclo de vida del desarrollo software donde se realice
Junio 2014Jose Luis Fernández Sánchez-
UPM 5
3. Técnicas de estimación
▪ Método de Delphi extendido
▪ Analogía
▪ Ley de Parkinson
▪ Punto Función
▪ Paramétricas
▪ La técnica de estimación basada en casos de uso
Junio 2014Jose Luis Fernández Sánchez-
UPM 6
Utilización de expertos
� Se basa en la decisión de un conjunto de desarrolladores con experiencia en el tipo de sistema a desarrollar
� Método Delphi Extendido
� Planificación
� Reunión de lanzamiento
� Preparación individual
� Reunión de estimación
� Consolidación de resultados
� Revisión de resultados
Junio 2014Jose Luis Fernández Sánchez-
UPM 7
Formato del método Delphi extendido
Tarea Estimación 1ª
Cambio 1 Cambio n Final
Total
Junio 2014Jose Luis Fernández Sánchez-
UPM 8
Estimación por analogía
� Se basa en comparar el proyecto con otros similares desarrollados por la organización
� Requiere disponer de una base de datos de métricas de proyectos
Junio 2014Jose Luis Fernández Sánchez-
UPM 9
Ley de Parkinson� La ley de Parkinson establece que el
esfuerzo se reparte en el tiempo disponible
� Esto implica que el coste se determina a partir de los recursos disponibles
� Por ejemplo si el proyecto tiene un plazo de 12 meses y disponemos de 5 personas el esfuerzo será de 60 personas-mes
Junio 2014Jose Luis Fernández Sánchez-
UPM 10
Puntos Función (I)
� La estimación se basa en la determinación del tamaño de las funciones/módulos a implantar en el sistema
� La técnica más utilizada en este caso es la técnica de los puntos funciónEntradas Externas x 4
Ficheros de Interfaz Externos x 7
Salidas al Exterior x 5
Consultas Externas x 4
Tablas Lógicas x 10
Puntos Función no Ajustados
Σ
Junio 2014Jose Luis Fernández Sánchez-
UPM 11
Puntos Función (II)
� La técnica de puntos función es estándar ISO:� IFPUG (ISO/IEC 20926:2009)
� COSMIC (ISO/IEC 19761:2011)
� Otras: FISMA, Mark II, NESMA.
� Actualmente se esta evolucionando IFPUG para considerar los requisitos no funcionales:� The Software Non_Functional Assessment Process
(SNAP) Release 2.1, April 2013.
Junio 2014Jose Luis Fernández Sánchez-
UPM 12
Técnicas Algorítmicas o Paramétricas
� El esfuerzo de desarrollo se obtiene utilizando expresiones matemáticas que relacionas este con ciertas métricas (líneas de código o puntos función)
� Típicas técnicas son:
� Rayleigh-Putnam
� COCOMO� COCOMO 81
� COCOMO II
Junio 2014Jose Luis Fernández Sánchez-
UPM 13
COCOMO 811
Los pasos a seguir son:
� Determinar el tamaño (KDSI)
� Determinar el esfuerzo nominal
MH= 3.2 ( KDSI) 1.05 (modo orgánico)
MH= 3.0 ( KDSI)1.12 (modo intermedio)
MH= 2.8 ( KDSI)1.2 (modo empotrado)
� Determinar el valor de los 15 multiplicadores de esfuerzo MEi
� Reestimar el esfuerzo MH= MHNOM Πi=1 a 15 (EM)i
� Estimar la duración
T= 2.5 (MH)0.38 (modo orgánico)
T= 2.5 (MH)0.35 (modo intermedio)
T= 2.5 (MH)0.32 (modo empotrado)1 B. Boehm. Software Engineering Economics. Prentice Hall 1981.
Junio 2014Jose Luis Fernández Sánchez-
UPM 14
COCOMO II 2
� Incluye aspectos como:
� cohesion del equipo de desarrollo
� continuidad del personal
� reutilización del software
� madurez en el desarrollo de software
� documentación
� desarrollo en diversas ubicaciones
2 B. Boehm. Software Cost Estimation with COCOMO II. Prentice Hall 2000.
La estimación de desarrollo software basada en casos de uso
Una adaptación de los puntos función a casos de uso del
sistema software
Junio 2014Jose Luis Fernández Sánchez-
UPM 1616
Estimación del esfuerzo del proyecto basado en casos de uso
� Este método de estimación utilizando los casos de uso, es descrito por Schneider y Winters de Rational3y basado en el trabajo inicial de Gustav Karner de Objective Systems.
� El método se basa en determinar el esfuerzo del proyecto en “horasxhombre” según:� complejidad de los actores� complejidad de los casos de uso� factores técnicos� factores de proyecto
3 Schneider G. y Winters Jason P. “Applying Use Cases. A Practical Guide”.Addison Wesley, Second Edition, Upper Saddle River (New Jersey), 2001.
Junio 2014Jose Luis Fernández Sánchez-
UPM 1717
Pasos de la estimación de esfuerzo
I. Clasificar y ponderar el efecto de los ActoresII. Clasificar y ponderar el efecto de los Casos de UsoIII. Calcular los puntos de casos de uso no ajustados (PCUNA)IV. Considerar los factores multiplicativos debidos a la complejidad
técnica del Sistema a desarrollar (FTP)V. Considerar los factores multiplicativos debidos al personal de
desarrollo, entorno de desarrollo y metodología a aplicar (FE)VI. Determinar el valor final de los puntos de casos de usoVII. PCU= PCUNA*FTP*FEP VIII. Calcular la estimación inicial del esfuerzo
Junio 2014Jose Luis Fernández Sánchez-
UPM 1818
I Clasificar y ponderar el efecto de los actores
Tipo de Actor Descripción Factor Actor
Simple El actor representa otro sistema con una API (Application Programming Interface)
definida
1
Medio Interfaz interactiva o según protocolo como TCP/IP
2
Complejo Interfaz gráfica utilizada por un típico actor usuario
3
Junio 2014Jose Luis Fernández Sánchez-
UPM 1919
II Clasificar y ponderar el efecto de los casos de uso
Tipo de Caso de Uso Descripción Factor Caso de Uso
Simple 3 o menos transacciones o su implementación
conllevaría menos de 5 clases
5
Medio De 4 a 7 transacciones o su implementación
conllevaría entre 5 y 10 clases
10
Complejo Más de 7 transacciones o su implementación
conllevaría más de 10 clases
15
Junio 2014Jose Luis Fernández Sánchez-
UPM 2020
¿Qué es una transacción en un caso de uso?
� Según Jacobson una transacción de un caso de uso representa el flujo de “ida y vuelta” entre un input del usuario (actor) y la respuesta del sistema.
� Una transacción de un caso de uso no es una transacción de base de datos.
� Cada flujo debido a una excepción contiene al menos una transacción. Lo mismo aplica a los flujos alternativos.
� Los casos de uso que representan trabajos “batch”sin interacciones con el exterior deberían ser valorados por expertos
Junio 2014Jose Luis Fernández Sánchez-
UPM 2121
Ejemplos de transacciones en CU (Collaris y Dekker)
Ejemplo única transacción1. El usuario selecciona opción X y opción Y 2. El sistema realiza la búsqueda y muestra el resultado
Ejemplo varias transaccionesTransacción
1. El usuario selecciona X2. El sistema muestra opciones Y que se derivan de la opción X
Transacción3. El usuario selecciona una o mas opciones Y4. El sistema realiza la búsqueda y muestra los resultados
Junio 2014Jose Luis Fernández Sánchez-
UPM 2222
III Calcular los puntos de casos de uso no ajustados
PCUNA = ∑ Factor Actor + ∑ Factor Caso de Uso
Junio 2014Jose Luis Fernández Sánchez-
UPM 2323
IV Considerar los factores multiplicativos debidos a la complejidad técnica del Sistema a
desarrollar (FTP)
Factor tFactor tFactor tFactor téééécnicocnicocnicocnico DescripciDescripciDescripciDescripcióóóónnnn PesoPesoPesoPeso
T1 Sistema Distribuido 2
T2 Requisitos de Tiempo de Respuesta o Volumen
1
T3 Online 1
T4 Proceso Complejo 1
T5 Reutilización 1
T6 Facilidad de instalación 0.5
T7 Facilidad de uso 0.5
T8 Portabilidad 2
T9 Facilidad de Cambio 1
T10 Concurrencia 1
T11 Requisitos de seguridad 1
T12 Acceso directo a terceros 1
T13 Existencia de Instalación de entrenamiento
1
Junio 2014Jose Luis Fernández Sánchez-
UPM 2424
Considerar los factores multiplicativos debidos a la complejidad técnica del
Sistema a desarrollar (FTP)
Se asigna a cada factor técnico un valor de 0 a 5, según su importancia en el proyecto (0= irrelevante, 5= esencial), cuando se tengan dudas poner 3.
FT = ∑ Valor *Peso
FTP = 0.6 + ( 0.01 * FT)
FTP podría variar entonces entre 0.6 y 1.3
Junio 2014Jose Luis Fernández Sánchez-
UPM 2525
V Considerar los factores multiplicativos debidos al personal de desarrollo, entorno de
desarrollo y metodología a aplicar (FE)
Factor del entornoFactor del entornoFactor del entornoFactor del entorno DescripciDescripciDescripciDescripcióóóónnnn PesoPesoPesoPeso
E1 Familiaridad con la metodología de desarrollo
1.5
E2 Experiencia en la aplicación 0.5
E3 Experiencia en la tecnología de Objetos
1
E4 Capacidad del analista principal 0.5
E5 Motivación 1
E6 Estabilidad de los Requisitos 2
E7 Programadores de terceros -1
E8 Dificultad del lenguaje de Programación
-1
Junio 2014Jose Luis Fernández Sánchez-
UPM 2626
Considerar los factores multiplicativos debidos al personal de desarrollo, entorno de desarrollo y metodología a aplicar (FE)
Se asigna a cada factor de entorno un valor de 0 a 5, según su importancia en el proyecto (0= irrelevante, 5= esencial)
FE = ∑ Valor *Peso
FEP = 1.4 + ( - 0.03 * FE)
Junio 2014Jose Luis Fernández Sánchez-
UPM 2727
VI Determinar el valor final de los puntos de casos de uso
PCU= PCUNA*FTP*FEP
Junio 2014Jose Luis Fernández Sánchez-
UPM 2828
VII Calcular la estimación inicial del esfuerzo
� La experiencia de “IBM Rational” (no tiene que ser igual para nosotros) indica que un valor adecuado sería de 20 horas hombre por PCU.
� Pero un análisis de más detalle de “IBM Rational” indica la importancia de los factores de entorno. Contabilizar el número de factores de tipo E1 a E6 con valores menores de 3, o factores de tipo E7 y E8 con valores mayores de 3, en valor absoluto. Si el total es 3 o 4 utilizar 28 horas hombre por PCU.Si el total es mayor de 5, el riesgo de realizar el Proyecto esalto
� Es mucho mejor actualizar el valor de horas hombre por PCU basándose en el histórico de nuestros propios proyectos siempre y cuando el rigor y extensión con que se describen los casos de uso sea similar y tengamos una muestra de proyectos suficientemente significativa
Junio 2014Jose Luis Fernández Sánchez-
UPM 29
Comparación PF y PCU
Menos de 30 minutosMenos de una horaTiempo para hacer una estimación 4
SiSiIndependiente de la tecnología
NoSiEstándar
Fácil de usarDificultad mediaFácil de usar
SiSiOrientado a cliente
Sí con datos históricosSi con datos históricasUtilidad
PCUPFCaracterística
4 No incluye el tiempo para hacer la especificación de requisitos
Junio 2014Jose Luis Fernández Sánchez-
UPM 30
4. Conclusión y recomendaciones� Es una buena práctica utilizar varias técnicas
conjuntamente
� Las estimaciones se repetirán en varios momentos del proyecto
� Cuando se hace la oferta
� Después de los requisitos
� Después del diseño
� Aplicar las técnicas siguiendo un proceso documentado
� Crear una base de datos de métricas de proyectos de la empresa
� Existen otras aproximaciones a utilizar con metodologías ágiles. “poker game” por ejemplo.