Estimación de Costes del Software - my. · PDF file(Eurotúnel), con una...
43
Estimación de Costes del Software Carlos Castillo Diestra
Transcript of Estimación de Costes del Software - my. · PDF file(Eurotúnel), con una...
Estimación de Costes del Software
Carlos Castillo Diestra
Propósito
Es propósito es mostrar como generar estimaciones fiables del esfuerzo, duración y costes para la producción de software.
Objetivos
o Comprender los fundamentos del coste del software
o Entender los principios del modelo de estimación COCOMO
o Estimar el esfuerzo, duración y coste de un software
Contenido
o Estimación de software
o Técnicas de estimación
o Modelo de costes algorítmicos
o Modelo COCOMO
Algunos proyectos famosos
• La Opera House en Sydney, que se estimó que su construcción llevaría alrededor de cinco años y tendría un coste aproximado de 7 millones de dólares. Finalmente, el costo fue de 102 millones de dólares y se demoró 14 años. (1959 – 1973)
Algunos proyectos famosos
El túnel bajo el Canal de la Mancha (Eurotúnel), con una estimación de costo de 7500 millones de dólares y plazo de entrega 1992, se terminó en 1994 con un costo de 17500 millones de dólares.
Algunos proyectos famosos
Tacoma Narrows Suspension Bridge (“Galloping Gertie”) el tercer puente más largo del mundo (tras el Golden Gate y el George Washington), que se hundió en 1940 cuatro meses y siete días después de su apertura.
Algunos proyectos famosos
En 1995 errores en el sistema del aeropuerto de Denver hicieron que el aeropuerto abra con un retraso de 16 meses y un exceso de gasto de 3500 millones de dólares.
Algunos proyectos famosos
o En 1988, la Westpac Banking Corporation decidió redefinir sus sistemas de información.
o Planificaron un proyecto de 85 millones de dólares para cinco años.
o Tres años más tarde, después de gastar 150 millones con poco éxito, asumió sus pérdidas, canceló el proyecto y elimino 500 empleados de desarrollo.
Otros Proyectos
o2004. Ford Motor Co. El sistema de compras es abandonado tras gastarse en él unos 400 millones.
o2004. J. Sainsbury PLC (UK): Sistema de SCM (Supply-change management) abandonado tras su instalación, y tras un gasto de 527 millones.
o2002. McDonald’s Corp.: Sistema de gestión de compras cancelado tras gastarse 170 millones.
o2001. Kmart Corp.: Sistema SCM cancelado tras gastar en él unos 130 millones.
o1993. Bolsa de Londres (UK): Systema Taurus es cancelado tras gasto de 600 millones.
o1993. Allstate Insurance Co.: Sistema de automatización de tareas es abandonado tras su instalación. Coste: 130 millones.
o1992. Budget Rent-A-Car, Hoteles Hilton, Marriott International y American Airlines: Sistema integrado de reservas cancelado tras un gasto de 165 millones
Interrogantes Fundamentales de la estimación
o ¿Cuánto esfuerzo se requiere para terminar una actividad?
o ¿Cuánto tiempo se necesita para terminar una actividad?
o ¿Cuál es el coste total de una actividad?
Estimación
Predicción cuantitativa de duración, esfuerzo y costes requeridos para realizar todas las actividades y constituir todos los productos asociados con un proyecto de software.
ELEMENTO UNIDAD
Duración Tiempo (meses, años, etc)
Esfuerzo Unidad de esfuerzo (personas.mes,personas.año, etc)
Coste Dólares, euros, soles, etc.
Elementos que hay que estimar
Componentes del coste del software
o Costes de Hardware y software. o Costes de viajes y entrenamiento. o Gastos Generales
• Gastos de edificios, energía eléctrica, aire acondicionado, etc.
• Gastos de redes y comunicaciones. • Gastos de instalaciones compartidas (e.g
biblioteca, personal de restaurante, etc.). o Costes de esfuerzo (Factor dominante en la
mayoria de los proyectos) • Los sueldos del personal involucrado en el
proyecto • Costes sociales y seguros.
Métodos utilizados para la estimación de proyectos.
o Basados en la experiencia.
o Basado exclusivamente en los recursos.
o Método basado exclusivamente en el mercado.
o Basado en los componentes del producto o en el proceso de desarrollo.
o Métodos algorítmicos
Métodos basados exclusivamente en la experiencia
o Juicio experto
• Puro,
• Delphi
o Analogía
o Distribución de la utilización de recursos en el ciclo de vida
Juicio experto: Puro
o Un experto estudia las especificaciones y hace su estimación.
o Se basa fundamentalmente en los conocimientos del experto.
o Si desaparece el experto, la empresa deja de estimar
Juicio experto: Wideband Delphi
o Se dan las especificaciones a un grupo de expertos.
o Se les reúne para que discutan tanto el producto como la estimación.
o Remiten sus estimaciones individuales al coordinador.
o Cada estimador recibe información sobre su estimación, y las ajenas pero de forma anónima.
o Se reúnen de nuevo para discutir las estimaciones.
o Cada uno revisa su propia estimación y la envía al coordinador.
o Se repite el proceso hasta que la estimación converge de forma razonable.
Analogía
o El coste del proyecto se estima en base a otros proyectos análogos que se han terminado previamente.
o 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: o Sistema Operativo, entornos (la primera vez
más).
o Hardware, ¿Es la primera vez que se va a utilizar?
o Personal del proyecto, ¿nuevos en la organización?
Método basado exclusivamente en los recursos: Parkinson
o En la estimación consiste en ver de cuanto personal y durante cuanto tiempo se dispone de el, haciendo esa estimación.
o En la realización:
“El trabajo se expande hasta
consumir todos los recursos
disponibles”
(Ley de Parkinson)
Método basado exclusivamente en el mercado: precio para vender.
o Lo importante es conseguir el contrato.
o El precio se fija en función de lo que creemos que esta dispuesto a pagar el cliente.
Basado en los componentes del producto o proceso de desarrollo:
o Bottom-up
• Se descompone el proyecto en las unidades lo menores posibles.
• Se estima cada unidad y se calcula el coste total.
o Top-Down
• Se ve todo el proyecto, se descompone en grandes bloques o fases.
• Se estima el coste de cada componente.
Modelo de costes algorítmico
o 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
o El coste se estima como una función matemática de los atributos del personal, producto, proyecto y plataforma.
o Tienen la siguiente estructura:
• Esfuerzo = A + B x TamañoC x M
• A, B y C son constantes que se obtienen empíricamente
• M es un multiplicador que refleja los atributos del personal, producto, proyecto y plataforma.
• Tamaño es la variable de estimación (LDC o PF)
Modelo de costes algorítmico
o Entre orientados a LDC propuestos se tienen:
• Modelo de Walston-Felix: E = 5,2 (KLDC)0,91
• Modelo de Bailey-Basisli: E = 5,5 + 0,73 (KLDC)1,16
• Modelo de Doty: E = 5,288 (KLDC)1,047
• Modelo simple de Boehm: E = 3,2 (KLDC)1,05
o Entre los modelos orientados a PF se tienen:
• Modelo de Albretch y Gaffney: E = -13,39 + 0,054PF
• Modelo de Kemerer: E = 60,62 x 7,728 x 10-8PF3
• Modelo de Matson, Barnett y Mellichamp: E = 585,7 + 15,12PF
El Modelo COCOMO
o COCOMO = COnstructive COst MOdel
o Basado en la experiencia de proyectos reales
o Modelo “Independiente”: no está ligado a un vendedor de software específico
o Larga historia: desde la versión inicial publicada en 1981 (COCOMO-81), pasando por varias instancias hasta COCOMO II.
COCOMO-81
Basado en el estudio de 63 proyectos
Jerarquía de Modelos:
o Modelo 1: Modelo básico
Calcula el esfuerzo del desarrollo en función del tamaño del programa, expresado en las líneas estimadas de código
o Modelo 2: Modelo intermedio
Calcula el esfuezo del desarrollo en función del tamaño del programa y de un conjunto de “conductores de coste”.
o Modelo 3: Modelo avanzado
Incorpora todas las características de le versión intermedia y lleva a cabo una evaluación del impacto de los conductores de coste en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software
Modos de Proyectos de Software
o Modo Orgánico
Proyectos de software pequeños y sencillos en los que trabajan pequenos equipos, con buena experiencia en la aplicación, sobre un conjunto de requisitos poco rígidos
o Modo Moderado (semi-acoplado, semi-rígido)
Proyectos de software intermedios en tamaño y complejidad en los que equipos, con variados niveles de experiencia, deben satisfacer requisitos medio rigidos.
o Modo Empotrado (embebido, rígido)
Proyectos de software complejos que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringido.
COCOMO-81
COCOMO-81
MODO ESFUERZO
(personas-mes)
TIEMPO DE
DESARROLLO
(meses)
Orgánico ESF = 2,4 (KLDC)1,05 TDES= 2,5 (ESF)0,38
Moderado ESF= 3,0 (KLDC)1,12
TDES= 2,5 (ESF)0,35
Embebido ESF = 3,6 (KLDC)1,20
TDES= 2,5 (ESF)0,32
COCOMO-81 - Básico
COCOMO 81 - Intermedio
MODO ESFUERZO
(personas-mes)
TIEMPO DE
DESARROLLO
(meses)
Orgánico ESF = 3,2 (KLDC)1,05 FEC TDES= 2,5 (ESF)0,38
Moderado ESF= 3,0 (KLDC)1,12 FEC
TDES= 2,5 (ESF)0,35
Embebido ESF = 2,8 (KLDC)1,20 FEC
TDES= 2,5 (ESF)0,32
Se considera un conjunto de atributos denominados conductores de coste:
FEC = п FEi
COCOMO 81 - Intermedio
o Producto
• Requerimientos de confiabilidad
• Tamaño de la base de datos
• Complejidad
o Computador usado
• Restricciones de tiempo de ejecución
• Restricciones de memoria principal
• Velocidad con que cambian los medios de cómputo
• Tiempo de respuesta del computador
Conductores de Coste:
COCOMO 81 - Intermedio
o Personal
• Capacidad de los analistas
• Experiencia de los analistas
• Capacidad de los programadores
• Experiencia en el sistema operativo
• Experiencia en el lenguaje de programación
o Proyecto
• Uso de técnicas modernas de programación
• Uso de herramientas de software
• Requisitos de planificación
Conductores de Coste:
COCOMO 81 - Intermedio
Tamaño de la Base de Datos
Descripción
KB/KLDC
<=10
KB/KLDC >10 y
<=100
KB/KLDC
>100 y <=1000
KB/KLDC
>1000
Nivel Muy Bajo Bajo Nominal Alto Muy alto Extra Alto
Multiplicador 0.94 1.00 1.08 1.16
Conductores de Coste: Ejemplo Requerimientos de Seguridad del Software
Descripción
Leves
inconvenientes
Pérdidas
fácilmente
recuperables
Pérdidas
moderadas
Grandes Perdidas
Financieras
Perdidas
Humanas
Nivel Muy Bajo Bajo Nominal Alto Muy alto Extra Alto
Multiplicador 0.75 0.88 1.00 1.15 1.40
Experiencia de los Analistas
Descripción 4 meses 1 año 3 años 6 años 12 años
Nivel Muy Bajo Bajo Nominal Alto Muy alto Extra Alto
Multiplicador 1.29 1.13 1.00 0.91 0.82
Guía para usar el Modelo COCOMO
o Si no sabe como configurar un conductor de coste (factor de esfuerzo) entonces usar los valores nominales.
o Si no puede decidir entre dos configuraciones tomar la más cercana a la nominal.
o No es obligatorio configurar todos los factores de coste. En un ambiente de desarrollo de un Software particular solamente algunos conductores de coste pueden ser importantes.
Ejemplo 1
FASE % ESFUERZO COSTO PERSONA MES (soles)
Análisis y Diseño 40% 5000
Programación 30% 4000
Pruebas 30% 6000
El Banco ABC encarga a la Empresa Radja S.A. el desarrollo de un sistema para que sus clientes realicen transacciones financieras vía web. Los clientes podrán consultar sus movimientos, consultar el estado de sus cuentas y realizar transferencias a terceros y pagos a cuenta. Si se estima que el software tendrá 100000 líneas de código, se usará la herramienta CASE Poseidon ¿cuál es el costo del proyecto? si el costo persona mes es el siguiente:
Ejemplo 1 - Solución
• Modelo: Intermedio
• Modo: Semiacoplado (Moderado) ESF=3 x (KLDC)1,12
• Conductores de coste:
1. Requerimentos de Seguridad del Software (Confiabilidad):
FRSS = 1,15 (Perdidas financieras)
2. Uso de Herramientas Software :
FUHS = 0,83 (Herramienta CASE)
• Costo persona mes promedio:
CPM = 0,4 * 5000 + 0,30 * 4000 + 0,3 * 6000 = 5000 soles.
• Esfuerzo Nominal (sin los conductores de coste):
ESF=3 x (KLDC)1,12 = 3 x (100)1,12 = 521,34 personas mes
• Esfuerzo Real (con los conductores de coste):
ESFreal = ESF x FRSS x FUHS = 521,34 x 1,15 x 0,83 = 497,62 personas mes
• Costo del Proyecto:
C = ESFreal x CPM = 497,62 x 5000 = 2 488 100 soles.
Ejemplo 2
La empresa WTR S.A. desea desarrollar un software para controlar máquinas de fabricación de autopartes. Se estima que el software tendrá aproximadamente 120 000 líneas de código y el costo promedio de un desarrollador será de 4000 soles mensuales. El proyecto se desarrollará bajo Linux, por lo que se contratará gente con al menos 3 años de experiencia en Linux. Bajo las condiciones descritas, la empresa CCD Data garantiza que el factor multiplicador del esfuerzo (conductores de coste) puede reducirse de 1.2 a 0.9 por medio del uso de un paquete para desarrollar software, cuyo costo es de 200 000 soles. ¿Desde el punto de vista económico, valdría la pena comprar dicho paquete? .
Ejemplo 2 - Solución
• Modelo: Intermedio • Modo: Empotrado (Control máquinas) ESF=2,8 x (KLDC)1,20 • Conductores de coste:
1. Experiencia en el Sistema Operativo: FESO = 0,96 (Más de 3 años en linux)
• Costo persona mes promedio: 4000 soles
Ejemplo 2 - Solución
Alternativa 1: Sin compra del paquete para desarrollar software
• Esfuerzo Nominal (sin los conductores de coste):
ESF=2,8 x (KLDC)1,20 = 2,8 x (120)1,20 = 875,33 personas mes
• Esfuerzo Real (con los conductores de coste):
ESFreal = ESF x FESO = 875,33 x 0,96 = 840,3168 personas mes
• Costo del Proyecto:
C = ESFreal x CPM = 840,3168 x 4000 = 3 361267,2 soles.
Ejemplo 2 - Solución
Alternativa 2: Comprando el paquete para desarrollar software • El esfuerzo se reduce en proporción de 1,2 a 0,9, por lo que se tiene el nuevo esfuerzo:
ESF =( ESFreal x 0,9 )/1,2 = (840,3168 x 0,9)/1,2 = 630,23
• Con lo cual el costo total seria:
C = Costo de desarrollo + costo del paquete
C = ESF x 4000 + 200 000
C = 630,23 x 4000 + 200 000 soles
C = 2 720 920 soles
Por lo tanto, comparando los costos de las alternativas, conviene
comprar el paquete para desarrollar software.
Conclusiones
o Para obtener buenas estimaciones para un proyecto, se deberían utilizar al menos dos o tres técnicas diferentes. Mediante la comparación y la conciliación de las estimaciones obtenidas con las diferentes técnicas, se puede obtener una estimación más exacta.
o La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y de técnicas sistemáticas pueden mejorar la precisión de la estimación.
Referencias
1. Boehm, B., Abts, C., Brown, W., Chulani, S. y Clark, B. (2009). Software Cost Estimation With Cocomo II. USA: Ed. Prentice-Hall.
2. Boehm, B. (1981). Software Engineering Economics. USA: Ed. Prentice-Hall.
3. Charette, R. (2 Setiembre 2005). Why Software Fails. Recuperado el 1 de julio de 2013, de http://spectrum.ieee.org/computing/software/why-software-fails
4. Opera House de Sidney. Recuperado el 12 de junio de 2013, de http://www.cairnsunlimited.com/es/opera_sidney.htm
