Presentación de PowerPoint

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
o
o
o
Estimación de software
Técnicas de estimación
Modelo de costes algorítmicos
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.
Elementos que hay que estimar
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.
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
o
o
o
Basados en la experiencia.
Basado exclusivamente en los recursos.
Método basado exclusivamente en el mercado.
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
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.
COCOMO-81
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
Embebido
ESF = 3,6  (KLDC)1,20 TDES= 2,5  (ESF)0,32
TDES= 2,5  (ESF)0,35
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
Embebido
ESF = 2,8  (KLDC)1,20  FEC TDES= 2,5  (ESF)0,32
TDES= 2,5  (ESF)0,35
Se considera un conjunto de atributos denominados conductores de
coste:
FEC = п FEi
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
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
COCOMO 81 - Intermedio
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
Multiplicador
0.75
0.88
1.00
1.15
Extra Alto
1.40
Tamaño de la Base de Datos
Descripción
Nivel
Muy Bajo
KB/KLDC
<=10
KB/KLDC >10 y
<=100
KB/KLDC
>100 y <=1000
KB/KLDC
>1000
Bajo
Nominal
Alto
Muy alto
Multiplicador
0.94
1.00
1.08
Extra Alto
1.16
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
Multiplicador
1.29
1.13
1.00
0.91
0.82
Extra Alto
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.
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á 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:
FASE
% ESFUERZO
COSTO PERSONA MES (soles)
Análisis y Diseño
40%
5000
Programación
30%
4000
Pruebas
30%
6000
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. PrenticeHall.
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/whysoftware-fails
4. Opera House de Sidney. Recuperado el 12 de junio de 2013,
de http://www.cairnsunlimited.com/es/opera_sidney.htm
[email protected]
[email protected]