JENNIFER ANDREA CANO GUEVARA

INGENIERIA DE SISTEMAS
La Estimacin
No necesita realizarse en una forma improvisada.
La experiencia es una gran ayuda.
La estimacin implica riesgo inherente, y este conduce
a la incertidumbre.
El riesgo de la estimacin se mide por el grado de
incertidumbre en las estimaciones cuantitativas para
recursos, costos y programa de trabajo.
La dificil tarea de estimar
La estimacin de software es difcil. Los
jefes, directivos, clientes y desarrolladores no
parecen entender por qu la estimacin es
tan difcil.
No se puede estimar con precisin el costo
de un programa hasta que se comprendan
con detalle cada una de las funciones que
realizar el sistema. La incertidumbre sobre
la naturaleza del producto aporta
incertidumbre a la estimacin.

Estimacin
Un gran error en la estimacin puede hacer la
diferencia entre Ganancia o Perdida.
Mala
Estimacin
Desastre para
el
Desarrollador
FACTORES QUE INFLUYEN EN EL
COSTO DEL SOFTWARE
La estimacin de lo que costar el desarrollo de un
software es una de las actividades de planeacin que
reviste especial importancia, ya que una de las
caractersticas que debe tener un producto de software
es que su costo sea adecuado, de lo contrario el
proyecto puede fracasar.

Los factores que afectan el costo
del software
1. Capacidad del programador
2. Complejidad del producto
3. Tamao del programa
4. Tiempo disponible
5. Confiabilidad requerida

El Proceso de Estimacin
1. Estimar el tamao del
producto ( en nmero de lneas
de cdigo fuente o puntos de
funcin ).

2. Estimar el esfuerzo ( personas
- mes ).

3. Estimar el plan ( meses ).

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

Estimacin Basada en el Problema
Tcnicas de Descomposicin
Tamao del Software
Podemos considerar dos tamaos del software:
Tamao en LDC.
Tamao en PF.
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.

Tcnicas de Descomposicin
Tamao del Software
- La habilidad para traducir la estimacin del tamao en
esfuerzo y dinero. Depende fundamentalmente de la
existencia de mtricas.
El grado en que el plan del proyecto refleja las
habilidades del equipo de software.

Tcnicas de descomposicin
Basadas en el Problema
Dicha estimacin puede basarse en:
Datos histricos.
Experiencia/intuicin.
Con estos valores se calcula un valor esperado:
VE = (Vo + 4Vm + Vp)/6
Una vez estimado el tamao se aplican los datos
histricos de productividad LDC

Tcnicas de Descomposicin
Basadas en el Proceso
La tcnica ms comn para estimar un proyecto es
basar la estimacin en el proceso que se va a utilizar

Utilizando el proceso identificamos un conjunto
pequeo de actividades de trabajo o tareas de trabajo y
se estima el esfuerzo requerido para llevar a cabo cada
tarea

METRICA

Un Mtodo y una escala cuantitativos que pueden ser
usados para determinar el valor que toma cierta
caracterstica en un producto de software concreto.

Ecuaciones de los Modelos
Empiricos
CLASIFICACION DE LAS METRICAS
MTRICAS TCNICAS: Se centran en las caractersticas de
software.

MTRICAS DE CALIDAD: proporcionan una indicacin
de cmo se ajusta el software a los requisitos implcitos y
explcitos del cliente.

MTRICAS DE PRODUCTIVIDAD. Se centran en el
rendimiento del proceso de la ingeniera del software.

CLASIFICACION DE LAS METRICAS
MTRICAS ORIENTADAS A LA PERSONA. Proporcionan
medidas e informacin sobre la forma que la gente
desarrolla el software de computadoras y sobre todo el
punto de vista humano de la efectividad de las
herramientas y mtodos.

MTRICAS ORIENTADAS AL TAMAO. Es para saber en
que tiempo voy a terminar el software y cuantas personas
voy a necesitar.


CLASIFICACION DE LAS METRICAS

MTRICAS ORIENTADAS A LA FUNCIN. Son
medidas indirectas del software y del proceso por el
cual se desarrolla.

Mtricas del Software

Mtricas
Orientadas al
tamao
Mtricas
Orientadas a la
funcin
Medidas directas del resultado
y del proceso
Medidas indirectas del
software y del proceso
Mtricas orientadas al tamao

Esfuerzo
humano
(persona - mes)
Coste (USD)
Pginas de
documentacin
N de errores
N de defectos
LDC
Productividad = KLDC / persona-mes
Calidad = N de errores (defectos) / KLDC
Coste medio = USD / KLDC
Documentacin = KLDC / persona-mes


METRICA LDC
Calcular la productividad, calidad, coste medio y documentacin de
acuerdo a la informacin proporcionada en la tabla que se muestra a
continuacin:
Productividad = KLDC / personas-mes
Calidad = N errores (defectos) / KLDC
Coste medio = Dlares / KLDC
Documentacin = Pginas de documentacin / KLDC












PROYEC
TO
LDC ESFUERZ
O
$(MILES) PAG.
DOC
ERRORE
S
DEFECT
OS
PERSON
AS
Alfa 12,100 24 168 365 134 29 3
Beta 27,200 62 440 1,224 321 86 5
Gama 20,200 43 314 1,050 256 64 6
METRICAS LDC
Con los datos contenidos en la tabla se puede obtener un conjunto de mtricas
simples adicionales:

No. De Errores por LDC 134 / 12,100 0.01 Errores / LDC

No. De Defectos por LDC 29/12,100 0.002 Defectos / LDC

Costo por LDC 168,000 / 12,100 $ 13.88 / LDC

LDC por persona-mes 12,100 / 24 904 LDC/p-m












METRICA LDC
Ventajas:
- Es una mtrica fcil de comprender.
- Muchos modelos, herramientas automticas y
literatura de estimacin se basan en LDC.

METRICA LDC
Desventajas:
Las LDC son dependientes del lenguaje. Escribir el
mismo programa en lenguajes diferentes puede arrojar
una diferencia en LCF bastante grande.
Resulta difcil que el planificador estime las LCF a
producirse mucho antes de que se complete el anlisis
y el diseo, ms an si no tiene datos histricos.


-25-
Hay que desarrollar un software CAD que aceptar datos geomtricos de 2 o 3 dimensiones por parte del
ingeniero. ste controlar el sistema CAD por medio de una interfaz que debe tener un diseo de buena
calidad. Una base de datos CAD contiene todos los datos geomtricos y la informacin de soporte. Se
desarrollarn mdulos de anlisis de diseo para producir la salida requerida que se va a visualizar en varios
dispositivos grficos.
El software se disear para controlar e interconectar diversos perifricos, como un ratn, un digitalizador y
una impresora lser.
Funciones identificadas:
interfaz de usuario y facilidades de control (IUFC)
anlisis geomtrico de dos dimensiones (AG2D)
anlisis geomtrico de tres dimensiones (AG3D)
gestin de base de datos (GBD)
facilidades de la interfaz grfica (FIG)
control perifricos (CP)
mdulos de anlisis del diseo (MAD)
Estimacin en LDC de AG3D:
optimista: 4600
ms probable: 6900
pesimista: 8600
VE = (S
opt
+ 4S
m
+ S
pes
)/6
Funcin LDC estimada

IUFC 2300
AG2D 5300
AG3D 6800
GBD 3350
FIG 4950
CP 2100
MAD 8400
Total 33200
Datos histricos:
productividad media de la organizacin en
proyectos similares: 620 LDC/pm

Tarifa laboral: 8000 $ /mes

Coste LDC: $ 13 ($12.90)
d
e
s
c
o
m
p
o
s
i
c
i

n

d
e

f
u
n
c
i
o
n
e
s

m

t
r
i
c
a
s

d
e

p
r
o
y
e
c
t
o
s

a
n
t
e
r
i
o
r
e
s

Coste total proyecto: $ 431.600

Esfuerzo estimado: 54 personas-mes
Mtricas orientadas a la funcin

salidas
entradas
consultas
Ficheros logicos
internos
Ficheros de
interfaz
PF


Estimacin
Optimista
Mas
Probable
Pesimista
Valor
Esperado
Entradas
Informaciones que
llegan a la aplicacin
desde el exterior.
Tienen una sola
direccin (Exterior
Interior)
Siempre actualizan
algn fichero interno.
4. Apendice, Mtrica de los puntos de funcin. 28
Clasificacin de las salidas
DIFICULTAD
SALIDAS
Nmero de Campos o Atributos de la Salida
1-5 Atributos 6-19 Atributos 20 + Atributos
0 1 ficheros
accedidos
BAJA BAJA MEDIA
2 3 ficheros
accedidos
BAJA MEDIA ALTA
4 + ficheros
accedidos
MEDIA ALTA ALTA
Salidas
Informaciones
elaboradas por la
aplicacin que son
transmitidas al
usuario.
Tienen una sola
direccin
(Interior a
Exterior)
4. Apendice, Mtrica de los puntos de funcin. 30
Consultas
Entradas que
producen
inmediatamente una
salida
No modifica los datos
del sistema
4. Apendice, Mtrica de los puntos de funcin. 31
4. Apendice, Mtrica de los
puntos de funcin. 32
Clasificacin de las consultas
Calculamos la complejidad de la parte de entrada
Calculamos la complejidad de la parte de salida
Nos quedamos slo con la complejidad mayor de las
dos.
Ficheros Lgicos o Internos
Agrupaciones de datos, tal
y como los percibe el
usuario
Es diferente de:
Entidades y Relaciones
Tablas o archivos resultantes
del diseo fsico
Los grupos de datos sern
accedidos y actualizados
por la aplicacin
4. Apendice, Mtrica de los puntos de funcin. 33
Clasificacin de los Ficheros
Lgicos o Internos
DIFICULTAD
FICHEROS
Nmero de Campos o Atributos
LGICOS 1-19 Atributos 20-50Atributos 51 + Atributos
1 Registro
Lgico
BAJA BAJA MEDIA
2 a 5 Registros
Lgicos
BAJA MEDIA ALTA
6 o ms
Registros Lgic.
MEDIA ALTA ALTA
Ficheros de Interfaz
Ficheros a los que
accede la aplicacin
con el nico objetivo
de obtener
informacin.
Son mantenidos por
otras aplicaciones
Nunca los actualiza la
aplicacin.
4. Apendice, Mtrica de los puntos de funcin. 35
DIAGRAMA DE CONTEXTO
Clasificacin de los Ficheros de
Interfaz
DIFICULTAD
FICHEROS
Nmero de Campos o Atributos
DE INTERFAZ 1-19 Atributos 20-50Atributos 51 + Atributos
1 Entidad o
Registro Lgico
BAJA BAJA MEDIA
2 a 5 Registros
Lgico
BAJA MEDIA ALTA
6 o ms
Registros Lgic.
MEDIA ALTA ALTA
TABLA PARA CALCULAR PUNTOS
DED FUNCION
FACTORES DE COMPLEJIDAD
Son catorce factores que completan la visin externa
de la aplicacin.
No estn recogidos en la funcionalidad de la
aplicacin.
Toman un valor entre 0 y 5
Factores de Ajuste de Complejidad: evaluar cada
factor de 0 a 5
0- Sin influencia 3- Medio
1- Incidental 4- Significativo
2- Moderado 5- Esencial

1. Requiere el sistema copias de seguridad fiables?
2. Se requieren comunicaciones de datos?
3. Existen funciones de procesamiento distribuido?
4. Es crtico el rendimiento?
5. Ser ejecutado el sistema en un entorno operativo existente y
utilizado?
6. Se requiere entrada de datos interactiva?
7. Requiere la entrada interactiva que las transacciones de entrada se
hagan sobre mltiples pantallas o variadas operaciones?
8. Se actualizan los archivos maestros de forma interactiva?
9. Son complejas las entradas, las salidas, los archivos o las
peticiones?
10.Es complejo el procesamiento interno?
11.Se ha diseado el cdigo para ser reutilizable?
12.Estn incluidas en el diseo la conversin y la instalacin?
13.Se ha diseado el sistema para soportar mltiples instalaciones en
diferentes organizaciones?
14.Se ha diseado la aplicacin para facilitar los cambios y ser
fcilmente utilizada por el usuario?
Mtricas orientadas a la funcin

PF = cuentatotal X [0,65 + 0,01 * Sumatoria (Fi) ]
Punto de
funcin
Sumatoria total resultante de
la ejecutar las operaciones en
la tabla siguiente
Valores de
ajuste de
complejidad
En funcin de un cuestionario
de 14 preguntas
Para el ejemplo descrito se asume que la Fi es 46 (un producto
moderadamente complejo), por consiguiente:
PF = 50 x (0,65 + 0,01 x 46) = 55.5 56
Donde cuenta-total es la suma de todas las entradas PF obtenidas
de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de
complejidad".

Factor de ponderacin

Parmetro de medicin
Cuenta Simple Media Compl.ejo
Nmero de entradas del usuario
3 X 3 4 6 = 9
Nmero de salidas del usuario
2 X 4 5 7 = 8
Nmero de consultas del usuario
2 X 3 4 6 = 6
Nmero de archivos
1 X 7 10 15 = 7
Nmero de interfaces externas
4 X 5 7 10 = 20
Cuenta total 50
Fig. Clculo de puntos de funcin
-42-
Valor dominio
informacin
Opt. Probable Pesimista Cuenta
est
Peso Cuenta
PF
Num. entradas 20 24 30 24 4 96
Num. salidas 12 15 22 16 5 80
Num. peticiones 16 22 28 22 4 88
Num. archivos 4 4 5 4 10 40
Num. interfaces ext. 2 2 3 2 7 14
Cuenta total 318

Copia de seguridad y recuperacin 4
Comunicaciones 2
Proceso distribuido 0
Rendimiento crtico 4
Entorno operativo existente 3
Entrada de datos online 4
Transacciones entrada en varias pant. 5
Archivos maestros actualizados online 3
Complejidad valores dominio informacin 5
Complejidad procesamiento interno 5
Cdigo diseado para reutilizacin 4
Conversin en diseo 3
Instalaciones mltiples 5
Aplicacin diseada para cambios 5
PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)
PF estimado = 372
Coste total proyecto: $ 457.843

Esfuerzo estimado: 58 personas-mes Datos histricos:
productividad media de la organizacin en
proyectos similares: 6,5 PF/pm

Tarifa laboral: 8000 $ /mes

Coste por PF: $ 1.230 ($1230,76)
m

t
r
i
c
a
s

d
e

p
r
o
y
e
c
t
o
s

a
n
t
e
r
i
o
r
e
s

4. Apendice, Mtrica de los
puntos de funcin. 43
UTILIDADES DE LOS PUNTOS DE
FUNCIN.
Comparar lo que solicit el cliente con lo que recibi.

Comparar la productividad de los diferentes entornos
de desarrollo.

Comparar la calidad que se obtiene mediante las
diferentes tcnicas de desarrollo.

TECNICAS DE ESTIMACION DE
COSTOS
JUICIO EXPERTO
La tcnica ms utilizada para la estimacin de costos es
el uso del juicio experto. El juicio experto se basa en la
experiencia, en el conocimiento anterior y en el
sentido comercial de uno o mas individuos dentro de
la organizacin.

JUICIO EXPERTO
El experto, por ejemplo, puede hacer una estimacin de
costos razonando de la siguiente manera:
- El sistema que se va a desarrollar es muy similar a uno que se
desarrollo anteriormente y que cost $ 8,000.00 y tard 4
meses.
- Se puede reutilizar la base del proyecto anterior.
- Se utilizar el mismo equipo de cmputo y a muchos de los
programadores que participaron en el proyecto anterior,
por lo que la estimacin se puede reducir en un 20 %.
JUICIO EXPERTO
- Mucho cdigo y rutinas comunes se podrn reutilizar
por lo que el esfuerzo se reduce otro 20%.
- Por lo tanto el nuevo proyecto puede ser un 20% ms
econmico que el anterior.


JUICIO EXPERTO
Ventajas
1. Se obtiene una estimacin en corto tiempo.

Desventajas
1. El experto puede confiarse y olvidar algunos factores
importantes del Nuevo proyecto, creyendo que es casi igual
al anterior.
2. El experto puede no tener familiaridad con el rea del
proyecto.

TECNICAS DE ESTIMACION DE
COSTOS
TECNICA DELFI

Se desarrollo en la corporacin Rand en 1948, con el fin de
lograr un acuerdo de un grupo de expertos sin contar con
los efectos negativos de las reuniones de grupos. La tcnica
se lleva a cabo de la siguiente manera:



TECNICA DELFI

1. Un coordinador proporciona a cada experto la
documentacin con la Definicin del Sistema y una
papeleta para que escriba su estimacin.


2. Cada experto estudia la definicin y determina su
estimacin en forma annima; los expertos pueden
consultar al coordinador, pero no entre ellos.

DELFI
3. El coordinador prepara y distribuye un resumen de las
estimaciones efectuadas, incluyendo cualquier
razonamiento extrao efectuado por alguno de los
expertos.

4. Los expertos realizan una segunda ronda de
estimaciones, otra vez annimamente, utilizando los
resultados de la estimacin anterior. En los casos en que
una estimacin difiera mucho de las dems, se podr
solicitar que tambin en forma annima el experto
justifique su estimacin.


TECNICA DELFI

5. El proceso se repite tantas veces como se juzgue
necesario, impidiendo una discusin grupal durante el
proceso.

ECUACION DE PRIMER ORDEN DE
JONES

Carpes Jones propone una ecuacin derivada del anlisis de
su base de datos de cientos de proyectos.

Este es tambin un modelo emprico de estimacin.

Con la suma total de puntos de funcin , se puede realizar a
partir de ellos un clculo aproximado de la planificacin.

ECUACION DE JONES
La ecuacin de Jones tiene la forma:
TDEV = #PF
n

Donde TDEV = Tiempo de planificacin ( meses )
#PF = No. de Puntos de Funcin
n = Exponente segn la tabla siguiente

ECUACION DE JONES
CLASE DE
SOFTWARE
MEJOR CASO MEDIA(NOMINA
L)
PEOR CASO
APLICACIN 0.39 0.42 0.45
GESTIN 0.41 0.43 0.46
SISTEMAS 0.43 0.45 0.48
TECNICA ITERATIVA
Se basa en la entrega evolutiva del software ( por etapas o
iteraciones ).
En cada etapa se construye un pequeo conjunto de
funciones del software ( miniproyecto ), que implica
anlisis, diseo, codificacin, pruebas, documentacin y
evaluacin del cliente.
La tcnica permite determinar el nmero de iteraciones y
su longitud necesaria para desarrollar el proyecto
completo.

NOTA: Las estimaciones son de los desarrolladores, no de los
gerentes.



TECNICA ITERATIVA
1.- Estimar el esfuerzo de cada funcin del software.
Asegurarse de que quien haga la estimacin sea el desarrollador que posea
el mayor conocimiento de la funcin dada.
TECNICA ITERATIVA
2.- Determine el nmero de programadores.
Utilizando los registros de proyectos anteriores, busque una
aproximacin con el Esfuerzo del proyecto actual y deduzca
el nmero de programadores que convendra utilizar.

Ejemplo:
Si en un proyecto anterior de 38 semanas-programador
requiri 4 programadores, puede ser razonable que el
nuevo proyecto requiera de 5.
TECNICA ITERATIVA
3.- Determine el factor de eficiencia de los
programadores ( productividad ).
Aunque los desarrolladores sean de tiempo completo, no
dedicarn el 100% de la jornada en trabajo productivo.
Investigaciones de cmo usan su tiempo los programadores
indican QUE:

Ejemplo: Suponga una productividad del 50% para este
ejemplo.
TECNICA ITERATIVA
4.- Determine la longitud de la iteracin.
Se busca una longitud de iteracin fija para todo el proyecto,
de modo que se pueda lograr un ritmo regular de entrega
del proyecto. Cada iteracin debe ser lo suficientemente
larga para realizar varias funciones del software.

Puede considerar longitudes de iteracin de 2 a 8 semanas.
Ejemplo: Suponer para este ejemplo que se implementar en
un lenguaje conocido, por lo que una longitud de iteracin
de 3 semanas permitir implementar de 2 a 4 funciones del
software por iteracin
TECNICA ITERATIVA
5.- Calcular el esfuerzo por iteracin.
Esfuerzo por iteracin ( semanas-programador ) = No.
Programadores * Long. Iteracin * Factor de Productividad

Ejemplo:
Esfuerzo por iteracin = 5 * 3 * 0.5 = 7.5 semanas-
programador
TECNICA ITERATIVA
6.- Calcular el nmero de iteraciones.

No. Iteraciones = ( Esfuerzo Total / Esfuerzo por Iteracin ) +
1

Ejemplo:
No. Iteraciones = ( 50 / 7.5 ) + 1 = 7.6 aprox. 8 iteraciones
7.- Calcular el tiempo de desarrollo.
Teniendo la longitud y el nmero de iteraciones es fcil
determinar el tiempo de desarrollo

Tdev = Long. Iteracin * No. Iteraciones

Ejemplo:
Tdev = 3 * 8 = 24 semanas = 6 meses.
8.- Considerar un factor de contingencia.
Agregue un factor del 10% al 20% del tiempo de construccin,
dependiendo de lo arriesgada que parezca la situacin.
Ejemplo:
Considerando el factor 40-20-40, es decir, el 40% de
esfuerzo es Analisis-Diseo, 20% Codificacin y 40%
Pruebas, calculamos que el tiempo posible de construccin
( codificacin ) es el 20% de las 24 semanas totales.

Tcodif = 0.2 * 24 = 4.8 aprox. 5 semanas
Suponiendo que nuestro factor de contingencia es del 15%
entonces el tiempo de contingencia ser

Tconting = 0.15 * 5 = 0.75 semanas o aprox. 4 dias.
Por lo tanto el plan debe ser formulado para desarrollar el
producto en 24 semanas, pero el compromiso de entrega
final sera para 24.75 semanas, 4 das ms.

TECNICAS DE ESTIMACION DE
COSTOS
METODO HISTORICO
Este mtodo se basa en registros cuidadosos que se
mantienen de esfuerzos de desarrollo previos.
MODELO DE COSTOS COCOMO
El modelo de costos COCOMO ( Modelo Constructivo
de Costos ), se basa en el uso de ecuaciones que se
utilizan de acuerdo a la complejidad del sistema a
desarrollar:


Cocomo
El Modelo Constructivo de Costos (COnstructive COst Model) es
una jerarqua de modelos de estimacin para el software.

Las ecuaciones del modelo COCOMO bsico tienen la siguiente
forma:
E = ab (KLDC) exp (bb)
D = cb (E) exp (db)

Las ecuaciones del modelo COCOMO intermedio toma la forma:
E = ai (KLDC) exp (bi) x FAE
donde E es el esfuerzo aplicado en personas-mes, KLDC es el
nmero estimado de Lneas de Cdigo distribudas para el
proyecto.

Jerarquas de Cocomo
El modelo COCOMO bsico es un modelo univariable
esttico que calcula el esfuerzo (y el costo) del
desarrollo de software en funcin del tamao del
programa expresando en lneas de cdigo (LDC)
estimadas.
COCOMO
El modelo COCOMO intermedio calcula el esfuerzo
del desarrollo de software en funcin del tamao del
programa y de un conjunto de conductores de costo,
que incluyen la evaluacin subjetiva del producto, del
hardware, del personal y de los atributos del proyecto.

cocomo
El modelo COCOMO avanzado incorpora todas las
caractersticas de la versin intermedia y lleva a cabo
una evaluacin de impacto de los conductores de costo
en cada fase (anlisis, diseo, etc.) del proceso de
ingeniera de software.

Cocomo Orientado a los Tipos de
proyecto de software
Modelo Orgnico. Proyectos de software
relativamente pequeos y sencillos en los que trabajan
pequeos equipos, con buena experiencia en la
aplicacin, sobre el conjunto de requisitos poco rgidos
(por ejemplo, un programa de anlisis termal
desarrollado para un grupo calrico).
Cocomo Orientado a los Tipos de
proyecto de software
Modelo Semiacoplado. Proyectos de software
intermedios (en tamao y complejidad) en los que los
equipos, con variados niveles de experiencia, deben
satisfacer requisitos poco o medio rgidos (por
ejemplo, un sistema de procesamiento de
transacciones con requisitos fijos para un hardware de
terminal o un software de gestin de base de datos).

Cocomo Orientado a los Tipos de
proyecto de software
Modelo Empotrado. Proyectos de software que
deben ser desarrollados en un conjunto de hardware,
software y restricciones operativas muy restringidas
(por ejemplo, software de control de navegacin para
un avin).

COCOMO
Las ecuaciones son de la forma:
PM = a * ( KDSI )
b
; TDEV = c * ( PM )
d

Programas de Aplicacin: PM = 2.4 * ( KDSI )
1.05
; TDEV =
2.5 * ( PM )
0.38

Programas de Apoyo: PM = 3.0 * ( KDSI )
1.12;
TDEV = 2.5 * (
PM )
0.35

Programas de Sistemas: PM = 3.6 * ( KDSI )
1.20;
TDEV = 2.5
* ( PM )
0.32


Calendarizacin

Fundamentos
La realidad de un proyecto tcnico, tal como uno de
software, es que hay que realizar cientos de tareas
pequeas en un orden determinado antes de poder
alcanzar la meta final. Las tareas estn
interrelacionadas en una secuencia lgica en el sentido
de que algunas de ellas no pueden empezar hasta que
otras se hayan terminado.


-76-
Calendario
Dividir el proyecto en actividades o tareas
Estimar el tiempo necesario para realizarlas (algunas
se harn en paralelo)
Los administradores
Coordinan las actividades
Organizan el trabajo para optimizar la mano de obra
Asignan y planifican recursos (personal, hardware,
software, presupuesto para viajes,...)
Duracin aconsejable de una actividad: entre 1 y 8
semanas
-77-
Calendario (cont.)
Importante tener en cuenta posibles problemas
(personal, hardware, software,...) que provocan
retrasos.
Problemas previstos: incrementar un 30% la
estimacin inicial.
Problemas no previstos: incrementar un 20%.
Utilizacin de diagramas de Gantt y redes de
actividades

Herramientas Automticas de
Calendarizacin

CONSEJOS SOBRE ESTIMACIONES
1. Evite estimaciones improvisadas ( ojo de buen cubero ).
2. Use datos de proyectos anteriores ( mtodo histrico ).
3. Las estimaciones las debe hacer el desarrollador, no el directivo.
4. Estime por concenso ( tcnica delfi ).
5. Evite estimar el proyecto como un todo.
6. Estime por descomposicin, es decir, estime cada funcin o requisito del
software individualmente. Luego la suma de ellos ser la estimacin del
proyecto total.
7. Utilice diferentes tcnicas de estimacin, compare los resultados y resuelva
las diferencias.
8. Si es posible use una herramienta automtica de estimacin. Con esto tendr
otro punto de comparacin.
9. Refine sus estimaciones a medida que conozca ms detalles del proyecto.


10. Emita una estimacin preliminar despus de revisar la Definicin del
Sistema. Refinela durante el Anlisis y de una estimacin definitiva despus de
revisar el Diseo. Si esto no es posible, trate de emitir su estimacin definitiva
al terminar el Anlisis. Si an esto no es posible, deber formularla solo con la
Definicin del Sistema pero considere un factor de seguridad adecuado.
11. Presente sus estimaciones usando rangos o casos ( mejor, ms probable, peor
).
12. Defienda sus estimaciones.

Finalmente Ud. y su equipo son los que conocen el proyecto y lo desarrollarn.
En lo posible evite que un directivo le imponga una estimacin que no est
justificada, para esto debe prepararse para defender sus estimaciones.
13. Negoce con el cliente.

Preguntas?