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

ccd@upnorte.edu.pe ccastillod@hotmail.com