Planificacin y Estimacin de

Proyectos de Software

Ing. Pablo Sevilla Jarquin

pasj@guegue.com.ni
Planificacin Temporal
La planificacin temporal para proyectos de desarrollo de
software puede verse desde dos perspectivas bastante
diferentes.
La fecha final de lanzamiento del sistema basado en computadora
ya ha sido (irrevocablemente) establecida.
La organizacin del software se ve forzada a distribuir el esfuerzo dentro del
marco prescrito.
El segundo asume que se han estudiado limites cronolgicos
aproximados pero que la fecha final es fijada por la organizacin
del software.
El esfuerzo se distribuye para hacer un mejor uso de los
recursos y la fecha final se define despus de un cuidadoso
anlisis del elemento de software.
Desdichadamente, la primera perspectiva se encuentra
bastante mas a menudo que la segunda.
Estimacin y Planificacin
Estimacin=prediccin de duracin, esfuerzo y
costos requeridos para realizar todas las
actividades y constituir todos los productos
asociados con el proyecto.
La planificacin es el proceso de:
Seleccin de una estrategia para la obtencin de producto
final.
Definicin de actividades a realizar para lograr ese
objetivo.
Coordinacin de concurrencia y solapamiento de dichas
actividades.
Asignacin de recursos a las mismas.
Estimacin y Planificacin

Estimacin: Prediccin cuantitativa de

aspectos del Proyecto.
Planificacin: Organizacin de gente y
tareas.
La Planificacin es el primer paso en la
realizacin de un proyecto informtico y en
gran parte, el responsable del xito o fracaso
del mismo.
Observaciones Acerca de la
Estimacin
La estimacin la lleva a cabo el gestor del
proyecto
La estimacin y planificacin temporal de un
proyecto software requiere:
- Experiencia.
- Buena informacin histrica.
- Coraje de confiar en las mtricas y la
experiencia.
Observaciones Acerca de la
Estimacin
Hay cuatro factores que influyen
significativamente en las estimaciones:
La complejidad del proyecto.
El tamao del proyecto.
El grado de incertidumbre estructural.
Se han definido requisitos?
Separabilidad de funciones.
Acotado.
La informacin que se maneja es clara?
Disponibilidad de informacin histrica.
Observaciones Acerca de la
Estimacin
Complejidad del proyecto
La complejidad es relativa a la experiencia en
proyectos anteriores.
Existen medidas sobre la complejidad de
proyectos basadas en el diseo y cdigo
(mtricas tcnicas).
En la fase de estimacin no son aplicables
porque no hay ni diseo ni cdigo.
Por eso hay que utilizar medidas ms subjetivas
(ej. PF).
Observaciones Acerca de la
Estimacin
Tamao del proyecto
En los proyectos grandes, crece la
interdependencia entre los componentes del
proyecto.
Interdependencia descomposicin del
producto en elementos muy grandes dificulta
el proceso de estimacin
Observaciones Acerca de la
Estimacin
Grado de incertidumbre estructural
Estructura:
Grado en que los requisitos se han definido.
Facilidad con la que se pueden compartimentalizar
funciones.
Naturaleza jerrquica de la informacin a procesar.
Incertidumbre estructural baja mejor
descomposicin del producto mejor
estimacin.
Observaciones Acerca de la
Estimacin
Informacin histrica
Aquellos que no pueden recordar el pasado,
estn condenados a repetirlo.
La existencia de mtricas del software de
proyectos anteriores facilita la estimacin.
En cualquier caso, la estabilidad de los
requisitos por parte del cliente es fundamental
para la estimacin
El Proceso de Planificacin del
Proyecto
El objetivo de la planificacin del proyecto de
software es proporcionar un marco de trabajo
que permita al gestor hacer estimaciones
razonables de recursos, coste y programa de
trabajo.

Estas estimaciones se hacen al comienzo del

proyecto
Hay que actualizarlas segn progresa ste
mbito del Software y Factibilidad

La primera actividad de la planificacin del proyecto

es determinar el mbito del software
Recordemos que mbito:
Contexto. Cmo encaja el software a construir en un
sistema, producto o contexto de negocios mayor y qu
limitaciones se imponen como resultado del contexto.
Objetivos de informacin. Qu objetos de datos
visibles al cliente se obtienen del software? Qu
objetos de datos son requeridos de entrada?
Funcin y rendimiento. Qu funcin realiza el software
para transformar la informacin de entrada en una salida?
Hay caractersticas de rendimiento especiales que
abordar?
mbito del Software y Factibilidad

El cliente es el nico que puede ayudarnos a

determinar el mbito.
Por tanto la comunicacin con el cliente es
fundamental.
La comunicacin se puede iniciar con las
preguntas de contexto libre.
Hay tres grupos dentro de estas preguntas
mbito del Software y Factibilidad

El primer grupo se centra en el cliente, los

objetivos globales y los beneficios:
- Quin est detrs de la solicitud de este trabajo?
- Quin utilizar esta solucin?
- Cul ser el beneficio econmico de una buena
solucin?
- Hay otro camino para la solucin?
mbito del Software y Factibilidad

El segundo grupo permiten comprender mejor el

problema y que el cliente exprese sus percepciones
sobre una solucin:
Cmo caracterizara (el cliente) un resultado
correcto que se generara con una solucin
satisfactoria?
Con qu problemas se enfrentar esta solucin?
Puede mostrarme (o describirme) el entorno en el
que se utilizar la solucin?
Hay aspectos o limitaciones especiales de
rendimiento que afecten a la forma en que se
aborde la solucin?
mbito del Software y Factibilidad

El ltimo grupo se centra en la efectividad de la

reunin. Se denominan metacuestiones:
Es usted la persona apropiada para responder a estas
preguntas? Son oficiales sus respuestas?
Son relevantes mis preguntas para su problema.
Estoy realizando muchas preguntas?
Hay alguien ms que pueda proporcionar informacin
adicional?
Hay algo ms que debiera preguntarle?
Estas preguntas y otras similares ayudan a romper
el hielo y a iniciar la comunicacin esencial
mbito del Software y Factibilidad
Veamos un ejemplo de mbito
Se va a desarrollar un sistema automtico de gestin de
pasos a nivel.
El sistema identifica al tren cuando se encuentra a 1 km del paso a
nivel.
Una vez identificado se enciende una luz roja, suena una campana
y se baja la barrera.
La seal debe bajarse en 30 sg. (el tren llega en 72 sg., ya que
circula a 50 km/h).
Despus de que el ltimo vagn del tren pase a 10 m. del paso a
nivel, se levanta la barrera, deja de sonar la campana, y cuando la
barrera est elevada se apaga la luz roja.
El planificador del proyecto examina la especificacin del
mbito y extra todas las funciones principales del software,
as como el rendimiento y las restricciones.
Actividades asociadas ... mbito del
software
Funcin Rendimiento Restricciones
Detectar tren 1 km.
Detectar ltimo 10 m. despus paso
vagn
Bajar barrera 30 sg.
lo ms rpido
Subir barrera posible
Encender luz 1 sg.
Apagar luz 1 sg.
Sonar campana 1 sg.
Para campana 1 sg.

La funcin no es independiente del rendimiento y/o las restricciones

1. e.g. no es lo mismo bajar la barrera en 30 sg. Que en 15 sg.
2. e.g. no es lo mismo detectar el ltimo vagn que detectar al tren
cuando pase a 500 m. despus del paso.
Actividades asociadas ... mbito del
software
Adems del mbito el software interacta con otros elementos
Por tanto el concepto de interfaz tambin es vital para la
planificacin temporal
Interfaz:
Hardware.
Software.
De usuario.
Procedimientos.
Otro aspecto importante durante la estimacin es el de la fiabilidad
del
Software
Ntese que se mide a posteriori, pero estamos en estimacin
En funcin del tipo de aplicacin este factor se vuelve ms o menos
crtico ( ej. Juego, control de avin)
Recursos
La segunda tarea de la planificacin del desarrollo de
software es la estimacin de recursos requeridos para
acometer el esfuerzo de desarrollo, Estos recursos son:
Personas.
Componentes software reutilizables.
Herramientas de hardware/software.
Cada recurso queda especificado mediante cuatro
caractersticas:
Descripcin del recurso.
Informe de disponibilidad.
Fecha cronolgica en la que se requiere el recurso.
Tiempo durante el que ser aplicado el recurso.
Las dos ltimas caractersticas son la ventana temporal
Recursos
Respecto al personal hay que especificar su
posicin en la organizacin y su especialidad
El nmero de personas requerido debe estimarse
como veremos en este tema
Gran parte de la reutilizacin del software se debe a
la tecnologa de componentes, Respecto a la
planificacin, tenemos cuatro tipos de
componentes:
Ya desarrollados.
Ya experimentados.
Con experiencia parcial.
Nuevos.
Estimacin de Proyectos de
Software
Estimar el costo del software es vital
Las estimaciones nunca podrn ser exactas
Cuanto mejor estimemos, ms rentable ser nuestro
proyecto
Estimar es difcil, ya que:
Los requisitos inciales no estn totalmente
delimitados.
Puede que necesitemos utilizar tecnologas nuevas.
Las personas involucradas en el proyecto
pueden tener distintos grados de experiencia.
Estimacin de Proyectos de
Software
Tcnicas de estimacin
- Retrasar la estimacin lo mximo posible. Cuanto
ms la retrasemos, ms precisa ser.
Estimacin por analoga. Utilizar el costo de
proyectos similares ya terminados.
Precio para ganar. El costo se estima en todo el
dinero que el cliente puede gastar en el proyecto.
Tcnicas de descomposicin. Estiman el costo
descomponiendo el producto y/o el proceso.
Modelos empricos. Modelos de regresin que
relacionan esfuerzo con tamao o funcionalidad
Tcnicas de Descomposicin
La tcnica de descomposicin basada en el problema, se
basa en la descomposicin del producto en funciones y
estimar el tamao del software
Por tanto, la primera estimacin que sirve de base para todas
las dems, es la estimacin del tamao del software
Podemos considerar tres tamaos del software:
Tamao en LDC.
Tamao en PF.
Tamao en Punto Objeto (PO)
En cualquier caso, la precisin de la estimacin depende de:
El grado en el que el planificador ha estimado adecuadamente el
tamao del producto a construir.
Modelos de Estimacin de Costos
de Proyectos Informticos
Mtrica

Una mtrica es, pues, una asignacin

de valor a un atributo de una entidad
propia del software, ya sea un
producto o un proceso.
Mtrica
Cuando hablamos de un atributo nos referimos
a una determinada caracterstica que
pretendemos medir y cuantificar.
Cuando hablamos de un producto nos
referimos, por ejemplo, a un cdigo, un diseo,
una especificacin, etc.
Cuando se habla de un proceso se hace
referencia a una etapa de la construccin del
software y a la manera de llevarlo a cabo: un
diseo, unas pruebas, etc.
Mtrica

En general, se puede decir que las diferentes

mtricas intentan evaluar tres grandes
magnitudes generales:
La calidad y el tamao (a menudo del producto)
y la productividad (frecuentemente del proceso
de construccin del producto), aunque lo hacen
desde muchos puntos de vista diferentes.
Mtricas del producto y del
proceso
Las mtricas del producto, que miden diferentes
aspectos del software obtenido, a menudo a
partir de cdigo fuente expresado en un
lenguaje informtico determinado.
Las mtricas del proceso, que intentan medir
determinados atributos que hacen referencia al
entorno de desarrollo del software y tienen en
cuenta la manera de construirlo.
Mtricas de calidad y de
productividad
La calidad de un producto, segn la definicin
del estndar ISO 8402, es el conjunto de
funcionalidades y caractersticas de un producto
o servicio que se centran en su capacidad de
satisfacer las necesidades, ya sea implcitas o
bien explicitadas claramente, de un cliente o
usuario.
Mtricas de calidad y de
productividad
Las mtricas de calidad se asocian a unos
determinados atributos medibles, no siempre
evidentes, para reconocer la presencia o
ausencia de calidad.
Las mtricas de productividad recogen la
eficiencia del proceso de produccin de
software y relacionan el software que se ha
construido con el esfuerzo que ha costado
elaborarlo.
Mtricas de calidad y de
productividad
A menudo las diferentes unidades de medida se
combinan en indicadores resumidos, como ejemplos
podemos encontrar, entre otros, los siguientes:

Lneas de cdigo por persona y da (indicador de

productividad).
Horas para implementar un punto de funcin (indicador de
productividad).
Nmero de errores por cada mil lneas de cdigo
(indicador de calidad).
Importe monetario por cada millar de lneas de cdigo
(indicador de costo).
Pginas de documentacin por cada mil lneas de cdigo
(indicador de documentacin).
El esfuerzo y la medida de la
productividad
La medida habitual del costo es, evidentemente,
la cantidad de dinero que cuesta producir un
software determinado; mientras que las medidas
habituales del esfuerzo se reducen siempre al
trabajo que lleva a cabo un profesional en una
determinada unidad de tiempo: un da (persona-
da), un mes (persona-mes) o un ao (persona-
ao).
Problemas terminolgicos del
hombre-mes
En primer lugar, se habl de hombre-mes como
la tarea que llevaba a cabo un hombre durante
un mes de trabajo. sta es la denominacin
habitual, que se puede encontrar a menudo
abreviada con la sigla MM, proveniente de la de
nominacin inglesa man-month.
Problemas terminolgicos del
hombre-mes
Ms adelante, pareci que la denominacin era
claramente sexista y se buscaron otros nombres
como stos:
Persona-mes: un mes de trabajo de una persona del
equipo con independencia del gnero.
Staff-month: un mes de trabajo de una persona del
equipo de proyecto.
Engineering-month: un mes de trabajo en la actividad
de ingeniera del software, que incluye, como ya
sabemos, el anlisis, el diseo, la programacin y las
pruebas para producir una determinada aplicacin o
un sistema de informacin.
El mito del hombre-mes

En resumidas cuentas, llegamos a la conclusin de que los meses y

los hombres (o las mujeres) no son intercambiables.
Mtricas orientadas al tamao y
a la funcin
Con el objetivo de medir la productividad del
proceso de construccin de software de
aplicacin, debe darse la posibilidad de
determinar las salidas que sean tiles para
relacionarlas despus con el volumen del
trabajo o el esfuerzo que representa desarrollar
un producto de software determinado

Hasta aca
Mtricas orientadas al tamao y
a la funcin
se han propuesto tambin otras unidades de
medida que, en lugar del tamao, intentan tener
en cuenta la dificultad intrnseca de construir un
software determinado; es decir, mtricas que se
refieren no al tamao del producto final
obtenido, sino a las funcionalidades que ste
incorpora.
Las lneas de cdigo

La medida ms utilizada para determinar el

tamao de un proyecto informtico ha sido,
durante mucho tiempo, la de las lneas de
cdigo del software final obtenido.
Algunas definiciones:
LOC: lneas de cdigo. Es la ms habitual y antigua.
KLOC: miles de lneas de cdigo.
DSI: instrucciones de cdigo fuente realmente
entregadas, y su mltiplo KDSI.
Las lneas de cdigo
La medida ms utilizada para determinar el tamao
de un proyecto informtico ha sido, durante mucho
tiempo, la de las lneas de cdigo del software final
obtenido.
Algunas definiciones:
NCSS: lneas de cdigo fuente sin tener en cuenta los
comentarios, y su mltiplo KNCSS
NSLOC: nuevas lneas de cdigo fuente, tal como se
realiza en el modelo COCOMO 2 para que se tenga en
cuenta que slo deben contarse las lneas de cdigo
nuevas sin contar las que incorpore automticamente el
entorno de programacin
Lneas de cdigo, productividad y
lenguajes de programacin

Las ratios de productividad tambin proceden de los

aos setenta y ochenta (de la informtica y de los
lenguajes que existan entonces). Estas ratios, que
actan como estndares de la profesin y que han sido
mencionadas de paso, son las siguientes:

a) 10 LOC por da y persona ocupada en el proyecto,

segn Barry W. Boehm a principios de los aos ochenta.

b) 350 NCSS por persona y mes, segn datos de

comienzos de los aos noventa en los proyectos de la
empresa Hewlett Packard recogidos por Robert O.
Grady.
Lneas de cdigo, productividad y
lenguajes de programacin

Caper T. Jones
Lneas de cdigo, productividad y
lenguajes de programacin

Caper T. Jones
Mtricas basadas en la Funcin

La mtrica del punto de funcin (PF) se

puede utilizar como medio para predecir el
tamao de un sistema obtenido a partir de
un modelo de anlisis. Para visualizar esta
mtrica se utiliza un modelo funcional, el
cual se evaluar para determinar las
siguientes medidas clave que son
necesarias para el clculo de la mtrica de
punto de funcin:
Nmero de entradas del usuario
Nmero de salidas del usuario
Nmero de consultas del usuario
Nmero de archivos
Nmero de interfaces externas
44
Mtricas basadas en la Funcin

La cuenta total debe ajustarse utilizando la

siguiente ecuacin:
PF = cuenta-total x (0,65 + 0,01 x Fi)
Donde cuenta-total es la suma de todas las
entradas PF obtenidas de la figura y Fi (i=1 a
14) son los "valores de ajuste de
complejidad".

45
 Para el ejemplo descrito en la figura se asume que la Fi es 44 (un
producto moderadamente complejo), por consiguiente:
PF = 50 x (0,65 + 0,01 x 44) = 54.5

Factor de ponderacin

Parmetro de medicin Cuenta Simple Media Compl.

Nmero de entradas del 3 X 3 4 6 = 9

usuario
Nmero de salidas del usuario 2 X 4 5 7 = 8

Nmero de consultas del 2 X 3 4 6 = 6

usuario
Nmero de archivos 1 X 7 10 15 = 7

Nmero de interfaces externas 4 X 5 7 10 = 20

Cuenta total 50

Clculo de puntos de funcin

Mtricas basadas en la Funcin

Basndose en el valor previsto del PF obtenido del

modelo de anlisis, el equipo del proyecto puede
estimar el tamao global de implementacin de las
funciones de interaccin.
Asuma que los datos de los que se dispone indican que
un PF supone 60 lneas de cdigo (se utilizar un
lenguaje orientado a objetos) y que en un esfuerzo de
un mes-persona se producen 12 PF.
Los puntos de funcin y la
productividad
Relacin entre puntos de funcin
y lneas de cdigo
.?
La nica manera segura de poder tener unos
estndares de productividad buenos y dignos de
ser utilizados es no depender de lo que dicen
libros y artculos (con datos obtenidos en
condiciones a menudo bien diferentes) y
disponer de los datos de productividad propios,
datos que pueden haber sido obtenidos en
proyectos anteriores del mismo tipo (en cuanto
a aplicacin y tecnologa) y con equipos de
desarrollo de calificaciones y caractersticas
personales conocidos.
Modelos de Estimacin de Costos de
Proyectos Informticos
Ing. Jos Luis Cerrn Prez
Estimacin de costos

La gestin de un proyecto informtico de gestin

empieza con la calificacin del proyecto, que
pretende, en primer lugar, obtener una idea del
volumen de trabajo que costar construir la
aplicacin (estimacin) y, en segundo lugar,
planificar en el tiempo las diferentes actividades
que es necesario llevar a cabo (planificacin).
Estimacin de costos

La primera de estas etapas se conoce tambin

con el nombre de estimacin de costos de un
proyecto informtico, ya que a partir del
esfuerzo de trabajo estimado se obtendr el
presupuesto. Del mismo modo, despus de la
planificacin y el reparto en el calendario de las
tareas que se deben a realizar, se obtienen los
plazos, etapa que tambin se conoce con el
nombre de tiempo de desarrollo del proyecto.
Estimacin de costos

La mayor parte del costo del software se

encuentra hoy en el costo de las horas de
anlisis, diseo, programacin y prueba que se
deben utilizar para obtenerlo. Por ello, cuando
aqu se habla de estimacin de costos se hace
referencia, exclusivamente, al esfuerzo humano
que ha sido necesario, es decir, a las horas de
trabajo requeridas para construir el software.
Estimacin de costos
En palabras de de Marco:

No hay modelos de costo transportables. Si

esperas que alguien en otro lugar desarrolle un
conjunto de frmulas que puedas utilizar para
prever el coste en tu propia instalacin,
probablemente tendrs que esperar para
siempre.

T. de Marco (1982, pg. 155).

Estimacin de costos

De Marco propone dos definiciones sucesivas

muy realistas de lo que es una estimacin:
Definicin implcita de estimacin: una estimacin es
la prediccin ms optimista que tiene una
probabilidad no nula de llegar a ser cierta.
Definicin propuesta por de Marco: una estimacin es
una prediccin que tiene la misma probabilidad de
estar por encima que de estar por debajo del
resultado real.
Estimacin de costos

En resumidas cuentas, estimar la carga de trabajo

que es necesario llevar a cabo para la
construccin de software de aplicacin es una
tarea que normalmente debe fracasar.
Momento de la estimacin y
grado de exactitud

Fuente: Grfico adaptado de Cost Models for Future Life Cycle Process: COCOMO 2.0 de B.W. Boehm
Modelos de estimacin

La idea de los modelos de estimacin es la de

proporcionar sistemas y mtodos generales
para proceder a realizar la estimacin de costos
en la construccin de software de aplicacin.
Modelos de estimacin

Los diferentes modelos de estimacin de costes

y/o esfuerzos en la construccin de software se
pueden dividir en cinco grandes grupos
principales:
1. Modelos con base histrica.
2. Modelos con base estadstica.
3. Tericos.
4. Compuestos.
5. Basados en estndares.
Modelos de estimacin

Modelos con base histrica.

Los modelos de base histrica son los ms
antiguos y, en cierta manera, primitivos.
A menudo se basan en la analoga con otros
proyectos parecidos y se fundamentan casi
exclusivamente en la experiencia profesional (la
historia) de los que efectan la estimacin.
Modelos de estimacin

Modelos con base estadstica.

A partir del estudio estadstico de los datos reales
disponibles tomados de un conjunto ms o menos
numeroso de proyectos ya acabados, obtienen
frmulas que relacionan las diferentes unidades de
medida del software, a menudo las lneas de
cdigo (LOC) y el esfuerzo (generalmente medido
en hombre-mes).
Modelos de estimacin

Tericos.
Estos modelos, ms que basarse en datos
estadsticos disponibles, lo que hacen es partir de
una serie de ideas generales sobre el proceso de
construccin de software y, sobre esta teora,
elaboran frmulas que relacionan diferentes
mtricas de software.
Modelos de estimacin

Compuestos.
Estos modelos intentan obtener las ventajas de los
dos sistemas anteriores: estadsticos y tericos. Es
decir, se parte de una serie de planteamientos
tericos y se complementan o corrigen con datos
estadsticos obtenidos de proyectos reales ya
acabados.
Los modelos COCOMO

COCOMO es el modelo de construccin de costes

ms conocido y utilizado de los modelos
algortmicos compuestos que se basan sobre
todo en datos estadsticos, pero tambin en
ecuaciones analticas y en un ajuste fruto de la
opinin de expertos.
El COCOMO clsico de 1981

El COCOMO clsico lo forman, en realidad, tres

modelos diferentes, que tienen en cuenta
diferentes grados de complejidad:
El COCOMO bsico es un modelo esttico vlido para
obtener una estimacin rpida del esfuerzo (meses-hombre)
en funcin del tamao (KLOC) al inicio del ciclo de vida.
El COCOMO clsico de 1981

El COCOMO clsico lo forman, en realidad, tres

modelos diferentes, que tienen en cuenta
diferentes grados de complejidad:
El COCOMO intermedio aade al clculo del esfuerzo en
funcin del tamao, el efecto de unos atributos que influyen
en el coste (CDA), con los cuales se quiere tener en cuenta
el tipo de aplicacin y tecnologa, las calificaciones y la
experiencia del personal, el entorno de diseo y
programacin y las herramientas de las que dispone, etc.
El COCOMO clsico de 1981

El COCOMO clsico lo forman, en realidad, tres

modelos diferentes, que tienen en cuenta
diferentes grados de complejidad:
El COCOMO adelantado incorpora todas las caractersticas
de la versin intermedia, pero en lugar de evaluar los CDA
con un nico valor para todo el ciclo de vida, tiene en cuenta
diferentes CDA para cada fase* de la construccin del
software.
El COCOMO clsico de 1981

Las ecuaciones del modelo COCOMO tienen siempre la

forma general que mostramos a continuacin:

E = a Lb CDA
T = c Ed

E es el esfuerzo (en personas-mes).

L son las lneas de cdigo (en KLOC)
T es el tiempo de desarrollo del proyecto (en meses)
CDA los cost driven attributes.
Finalmente a, b, c y d son coeficientes que el modelo
proporciona como resultado del anlisis de los datos de sesenta
y tres proyectos realizados entre 1965 y 1980.
El COCOMO clsico de 1981

Adems de los tres modelos, COCOMO tiene

en cuenta varios tipos de proyecto, ya que no
se obtienen los mismos datos de productividad
en todos los casos.
a) Orgnico.
b) Semiacoplado.
c) Encajado.
El COCOMO clsico de 1981

Los coeficientes que corresponden al modelo

bsico.
El COCOMO clsico de 1981

Los coeficientes que corresponden al modelo

intermedio.
El COCOMO clsico de 1981

Atributos que influyen en el costo.

El COCOMO clsico de 1981
El COCOMO clsico de 1981

En resumidas cuentas, el modelo COCOMO es

el ms serio y completo de los que existen,
aunque los resultados que se obtienen pueden
haber quedado obsoletos por la evolucin y los
cambios que ha sufrido la informtica en los
ltimos veinte aos.
El COCOMO II de los aos
noventa y a partir del 2000
El nuevo modelo COCOMO II tiene como
objetivo principal desarrollar un modelo de
estimacin de costos y planificacin del
software especialmente adecuado para los
ciclos de vida.
el COCOMO II incluye tres modelos que
corresponden a diferentes fases y modalidades
del futuro ciclo de vida.
El COCOMO II de los aos
noventa y a partir del 2000
Modelo de composicin de aplicaciones:
incluye el uso de prototipos para disminuir los
riesgos potenciales que surgen con las interfaces
grficas de usuario tpicas de herramientas RAD y
otras herramientas actuales de productividad y de la
orientacin a objetos.
En este modelo se definen unos puntos objeto que
vendran a ser una adaptacin y modernizacin de
los puntos de funcin
El COCOMO II de los aos
noventa y a partir del 2000
Modelo de diseo primerizo :
intenta obtener una primera aproximacin en las
fases iniciales del ciclo de vida, cuando todava se
conocen pocas de las caractersticas y datos
definitivos del proyecto.
Utiliza como primitivas de salida tanto las lneas de
cdigo como los clsicos puntos de funcin.
El COCOMO II de los aos
noventa y a partir del 2000
Modelo de postarquitectura:
Se aplica cuando se considera que el proyecto
dispone ya de requerimientos estables. Por otra
parte, tambin utiliza como primitivas de salida las
lneas de cdigo y los puntos de funcin.
Adems, tiene en cuenta indicadores de la
reutilizacin de software, cinco factores de escala y
hasta diecisiete factores especficos diferentes
Uso de estndares de
productividad
No es fcil, en la prctica, encontrar cul es el
modelo que ms se ajusta a la realidad del
proyecto informtico que todava est por
empezar y que preocupa al jefe de proyecto
que debe llevar a cabo la estimacin de las
cargas y los costos.
Uso de estndares de
productividad
En lugar de cuantificar cada actividad o conjunto
de estas caractersticas funcionales en lneas de
cdigo o puntos de funcin y buscar modelos
que conviertan estas mtricas en esfuerzo
(meses-hombre), es suficiente disponer
directamente, para cada actividad, del esfuerzo
estndar que ha requerido en otros proyectos
anteriores.
Uso de estndares de
productividad
Segn la opinin de un experto como Jones, se
dan las equivalencias prcticas siguientes:
1 FP = 100 LOC.
FP elevado a 0,4 = meses de desarrollo.
FP/150 = nmero de personas que son necesarias
para el desarrollo.
FP/500 = nmero de personas necesarias para el
mantenimiento futuro.
Uso de estndares de
productividad
Segn la opinin de un experto como Jones, se
dan las equivalencias prcticas siguientes:
FP elevado a 1,15 = nmero de pginas de
documentacin.
FP elevado a 1,2 = nmero de casos de prueba que
se realizan.
FP elevado en 1,25 = potencial de errores (en
proyectos nuevos).
FP elevado a 0,25 = nmero de aos que seguir en
uso la aplicacin.
Tengamos una noche
maravillosa!