Estimación de Costes del Software. Carlos Castillo Diestra

Transcripción

1 Estimación de Costes del Software Carlos Castillo Diestra

2 Propósito Es propósito es mostrar como generar estimaciones fiables del esfuerzo, duración y costes para la producción de software.

3 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

4 Contenido o Estimación de software o Técnicas de estimación o Modelo de costes algorítmicos o Modelo COCOMO

5 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. ( )

6 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 millones de dólares.

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

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

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

10 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

11 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?

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

13 Elementos que hay que estimar ELEMENTO Duración Esfuerzo Coste Tiempo (meses, años, etc) UNIDAD Unidad de esfuerzo (personas.mes,personas.año, etc) Dólares, euros, soles, etc.

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

15 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

16 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

17 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

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

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

20 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)

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

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

23 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ño C 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)

24 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-8 PF 3 Modelo de Matson, Barnett y Mellichamp: E = 585,7 + 15,12PF

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

26 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

27 COCOMO-81 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.

28 COCOMO-81

29 COCOMO-81 - Básico 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

30 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

31 COCOMO 81 - Intermedio Conductores de Coste: 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

32 COCOMO 81 - Intermedio Conductores de Coste: 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

33 COCOMO 81 - Intermedio Descripción Leves inconvenientes Conductores de Coste: Ejemplo Requerimientos de Seguridad del Software Pérdidas fácilmente recuperables Pérdidas moderadas Grandes Perdidas Financieras Perdidas Humanas Nivel Muy Bajo Bajo Nominal Alto Muy alto Extra Alto Multiplicador 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 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

34 Guía para usar el Modelo COCOMO o o o Si no sabe como configurar un conductor de coste (factor de esfuerzo) entonces usar los valores nominales. Si no puede decidir entre dos configuraciones tomar la más cercana a la nominal. 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.

35 Ejemplo 1 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á 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: FASE % ESFUERZO COSTO PERSONA MES (soles) Análisis y Diseño 40% 5000 Programación 30% 4000 Pruebas 30% 6000

36 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): F RSS = 1,15 (Perdidas financieras) 2. Uso de Herramientas Software : F UHS = 0,83 (Herramienta CASE) Costo persona mes promedio: CPM = 0,4 * ,30 * ,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): ESF real = ESF x F RSS x F UHS = 521,34 x 1,15 x 0,83 = 497,62 personas mes Costo del Proyecto: C = ESF real x CPM = 497,62 x 5000 = soles.

37 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 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 soles. Desde el punto de vista económico, valdría la pena comprar dicho paquete?.

38 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: F ESO = 0,96 (Más de 3 años en linux) Costo persona mes promedio: 4000 soles

39 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): ESF real = ESF x F ESO = 875,33 x 0,96 = 840,3168 personas mes Costo del Proyecto: C = ESF real x CPM = 840,3168 x 4000 = ,2 soles.

40 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 =( ESF real 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 C = 630,23 x soles C = soles Por lo tanto, comparando los costos de las alternativas, conviene comprar el paquete para desarrollar software.

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

42 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 4. Opera House de Sidney. Recuperado el 12 de junio de 2013, de

43