La estimación de costes en los proyectos software

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)

[email protected]

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


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


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


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


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


UPM 7

Formato del método Delphi extendido

Tarea Estimación 1ª

Cambio 1 Cambio n Final

Total


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


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


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

Σ


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.


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


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.


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


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.


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


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


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


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


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


UPM 2222

III Calcular los puntos de casos de uso no ajustados

PCUNA = ∑ Factor Actor + ∑ Factor Caso de Uso


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


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


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


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)


UPM 2727

VI Determinar el valor final de los puntos de casos de uso

PCU= PCUNA*FTP*FEP


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


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


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.

La estimación de costes en los proyectos software

Documents

Transcript of La estimación de costes en los proyectos software