JENNIFER ANDREA CANO GUEVARA

INGENIERIA DE SISTEMAS
La Estimación
 No necesita realizarse en una forma improvisada.
 La experiencia es una gran ayuda.
 La estimación implica riesgo inherente, y este conduce
a la incertidumbre.
 El riesgo de la estimación se mide por el grado de
incertidumbre en las estimaciones cuantitativas para
recursos, costos y programa de trabajo.
La dificil tarea de estimar
 La estimación de software es difícil. Los
jefes, directivos, clientes y desarrolladores no
parecen entender por qué la estimación es
tan difícil.
 No se puede estimar con precisión 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 estimación.
Estimación
 Un gran error en la estimación puede hacer la
diferencia entre Ganancia o Perdida.

Mala Desastre para

Estimación el
Desarrollador
FACTORES QUE INFLUYEN EN EL
COSTO DEL SOFTWARE
 La estimación de lo que costará el desarrollo de un
software es una de las actividades de planeación que
reviste especial importancia, ya que una de las
características 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. Tamaño del programa
 4. Tiempo disponible
 5. Confiabilidad requerida
El Proceso de Estimación
 1. Estimar el tamaño del
producto ( en número de líneas
de código fuente o puntos de
función ).

 2. Estimar el esfuerzo ( personas

- mes ).

 3. Estimar el plan ( meses ).

Técnicas de Descomposición
 La técnica de descomposición basada en el problema,
se basa en la descomposición del producto en
funciones y estimar el tamaño del software

• Por tanto, la primera estimación que sirve de base para

todas las demás, es la estimación del tamaño del
software
Estimación Basada en el Problema
Técnicas de Descomposición
Tamaño del Software
 Podemos considerar dos tamaños del software:
 Tamaño en LDC.
 Tamaño en PF.
• En cualquier caso, la precisión de la estimación
depende de:
 El grado en el que el planificador ha estimado
adecuadamente el tamaño del producto a construir.
Técnicas de Descomposición
Tamaño del Software
- La habilidad para traducir la estimación del tamaño en
esfuerzo y dinero. Depende fundamentalmente de la
existencia de métricas.
 El grado en que el plan del proyecto refleja las
habilidades del equipo de software.
Técnicas de descomposición
Basadas en el Problema
• Dicha estimación puede basarse en:
 Datos históricos.
 Experiencia/intuición.
• Con estos valores se calcula un valor esperado:
VE = (Vo + 4Vm + Vp)/6
• Una vez estimado el tamaño se aplican los datos
históricos de productividad LDC
Técnicas de Descomposición
Basadas en el Proceso
• La técnica más común para estimar un proyecto es
basar la estimación en el proceso que se va a utilizar

• Utilizando el proceso identificamos un conjunto

pequeño de actividades de trabajo o tareas de trabajo y
se estima el esfuerzo requerido para llevar a cabo cada
tarea
METRICA
 “Un Método y una escala cuantitativos que pueden ser
usados para determinar el valor que toma cierta
característica en un producto de software concreto.”
Ecuaciones de los Modelos
Empiricos
CLASIFICACION DE LAS METRICAS
 MÉTRICAS TÉCNICAS: Se centran en las características de
software.

 MÉTRICAS DE CALIDAD: proporcionan una indicación

de cómo se ajusta el software a los requisitos implícitos y
explícitos del cliente.

 MÉTRICAS DE PRODUCTIVIDAD. Se centran en el

rendimiento del proceso de la ingeniería del software.
CLASIFICACION DE LAS METRICAS
 MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan
medidas e información 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 métodos.

 MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en

que tiempo voy a terminar el software y cuantas personas
voy a necesitar.
CLASIFICACION DE LAS METRICAS
 MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son
medidas indirectas del software y del proceso por el
cual se desarrolla.
 Métricas del Software

Métricas
Medidas directas del resultado
Orientadas al y del proceso
tamaño

Métricas
Medidas indirectas del
Orientadas a la
software y del proceso
función
 Métricas orientadas al tamaño
Páginas de
documentación

Esfuerzo
humano N° de errores
(persona - mes)

LDC
Coste (USD) N° de defectos

Productividad = KLDC / persona-mes

Calidad = N° de errores (defectos) / KLDC
Coste medio = USD / KLDC
Documentación = KLDC / persona-mes
METRICA LDC
 Calcular la productividad, calidad, coste medio y documentació
acuerdo a la información proporcionada en la tabla que se mue
continuación:
 Productividad = KLDC / personas-mes
 Calidad = Nº errores (defectos) / KLDC
 Coste medio = Dólares / KLDC
 Documentación = Páginas de documentación / KLDC

PROYEC LDC ESFUERZ $(MILES) PAG. ERRORE DEFECT PERSON

TO O DOC S OS 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 métricas
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 métrica fácil de comprender.
 - Muchos modelos, herramientas automáticas y
literatura de estimación 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 difícil que el planificador estime las LCF a
producirse mucho antes de que se complete el análisis
y el diseño, más aún si no tiene datos históricos.
Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del
ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena
calidad. Una base de datos CAD contiene todos los datos geométricos y la información de soporte. Se
desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios
dispositivos gráficos.
El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y
una impresora láser.

Funciones identificadas:
Estimación en LDC de AG3D:
descomposición

interfaz de usuario y facilidades de control (IUFC)

de funciones

análisis geométrico de dos dimensiones (AG2D) optimista: 4600

análisis geométrico de tres dimensiones (AG3D) más probable: 6900
gestión de base de datos (GBD) pesimista: 8600
facilidades de la interfaz gráfica (FIG)
control periféricos (CP)
módulos de análisis del diseño (MAD) VE = (Sopt + 4Sm + Spes)/6

Datos históricos: Función LDC estimada

métricas de

productividad media de la organización en

anteriores
proyectos

proyectos similares: 620 LDC/pm IUFC 2300

AG2D 5300
Tarifa laboral: 8000 $ /mes AG3D 6800
Coste LDC: $ 13 ($12.90) GBD 3350
FIG 4950
CP 2100
MAD 8400
Coste total proyecto: $ 431.600 Total 33200
Esfuerzo estimado: 54 personas-mes

-25-
 Métricas orientadas a la función
consultas

salidas Ficheros logicos

internos

PF Ficheros de
entradas
interfaz
Estimación
Mas Valor
Optimista Pesimista
Probable Esperado
Entradas
 Informaciones que
llegan a la aplicación
desde el exterior.
 Tienen una sola
dirección (Exterior à
Interior)
 Siempre actualizan
algún fichero interno.

4. Apendice, Métrica de los puntos de función. 28

 Clasificación de las salidas
DIFICULTAD Número de Campos o Atributos de la Salida
SALIDAS
1-5 Atributos 6-19 Atributos 20 + Atributos

0 ó 1 ficheros
BAJA BAJA MEDIA
accedidos

2 ó 3 ficheros
BAJA MEDIA ALTA
accedidos

4 + ficheros
MEDIA ALTA ALTA
accedidos
Salidas
 Informaciones
elaboradas por la
aplicación que son
transmitidas al
usuario.
 Tienen una sola
dirección
(Interior a
Exterior)

4. Apendice, Métrica de los puntos de función. 30

Consultas
 Entradas que
producen
inmediatamente una
salida
 No modifica los datos
del sistema

4. Apendice, Métrica de los puntos de función. 31

Clasificación de las consultas
 Calculamos la complejidad de la parte de entrada
 Calculamos la complejidad de la parte de salida
 Nos quedamos sólo con la complejidad mayor de las
dos.

4. Apendice, Métrica de los

puntos de función. 32
Ficheros Lógicos o Internos
 Agrupaciones de datos, tal
y como los percibe el
usuario
 Es diferente de:
 Entidades y Relaciones
 Tablas o archivos resultantes
del diseño físico
 Los grupos de datos serán
accedidos y actualizados
por la aplicación

4. Apendice, Métrica de los puntos de función. 33

Clasificación de los Ficheros
Lógicos o Internos
DIFICULTAD Número de Campos o Atributos
FICHEROS
LÓGICOS 1-19 Atributos 20-50Atributos 51 + Atributos

1 Registro
BAJA BAJA MEDIA
Lógico

2 a 5 Registros
BAJA MEDIA ALTA
Lógicos

6 o más
MEDIA ALTA ALTA
Registros Lógic.
Ficheros de Interfaz
 Ficheros a los que
DIAGRAMA DE CONTEXTO
accede la aplicación
con el único objetivo
de obtener
información.
 Son mantenidos por
otras aplicaciones
 Nunca los actualiza la
aplicación.

4. Apendice, Métrica de los puntos de función. 35

 Clasificación de los Ficheros de
Interfaz
DIFICULTAD Número de Campos o Atributos
FICHEROS
DE INTERFAZ 1-19 Atributos 20- 51 + Atributos
50Atributos

1 Entidad o
BAJA BAJA MEDIA
Registro Lógico

2 a 5 Registros
BAJA MEDIA ALTA
Lógico

6 o más
MEDIA ALTA ALTA
Registros
Lógic.
TABLA PARA CALCULAR PUNTOS
DED FUNCION
FACTORES DE COMPLEJIDAD
 Son catorce factores que completan la visión externa
de la aplicación.
 No están recogidos en la funcionalidad de la
aplicación.
 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 crítico el rendimiento?
5. ¿Será ejecutado el sistema en un entorno operativo existente y utilizado?
6. ¿Se requiere entrada de datos interactiva?
1. ¿Requiere la entrada interactiva que las transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?

7. ¿Se actualizan los archivos maestros de forma interactiva?

8. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?
9. ¿Es complejo el procesamiento interno?
10.¿Se ha diseñado el código para ser reutilizable?
11.¿Están incluidas en el diseño la conversión y la instalación?
12.¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?
13.¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente utilizada por el
usuario?
 Métricas orientadas a la función

PF = cuentatotal X [0,65 + 0,01 * Sumatoria (Fi) ]

Sumatoria total resultante de

Punto de
la ejecutar las operaciones en
función
la tabla siguiente

Valores de
En función de un cuestionario
de 14 preguntas
ajuste de
complejidad
 Factor de ponderación
Parámetro de medición Cuenta Simple Media Compl.ejo

Número de entradas del usuario 3 X 3 4 6 = 9

Número de salidas del usuario 2 X 4 5 7 = 8

Número de consultas del usuario 2 X 3 4 6 = 6

Número de archivos 1 X 7 10 15 = 7

Número de interfaces externas 4 X 5 7 10 = 20

Cuenta total 50

Fig. Cálculo de puntos de función

 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".
 Valor dominio Opt. Probable Pesimista Cuenta Peso Cuenta
información est 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 recuperación 4

Comunicaciones 2
Proceso distribuido 0
Rendimiento crítico 4
Entorno operativo existente 3 PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)
Entrada de datos online 4
Transacciones entrada en varias pant. 5
Archivos maestros actualizados online 3
Complejidad valores dominio información 5
Complejidad procesamiento interno 5 PF estimado = 372
Código diseñado para reutilización 4
Conversión en diseño 3
Instalaciones múltiples 5
Aplicación diseñada para cambios 5
Coste total proyecto: $ 457.843
Datos históricos: Esfuerzo estimado: 58 personas-mes
métricas de

anteriores
proyectos

productividad media de la organización en

proyectos similares: 6,5 PF/pm
Tarifa laboral: 8000 $ /mes
Coste por PF: $ 1.230 ($1230,76)

-42-
UTILIDADES DE LOS PUNTOS DE
FUNCIÓN.
 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 técnicas de desarrollo.

4. Apendice, Métrica de los

puntos de función. 43
TECNICAS DE ESTIMACION DE
COSTOS
JUICIO EXPERTO
 La técnica más utilizada para la estimación 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 organización.
 JUICIO EXPERTO
El experto, por ejemplo, puede hacer una estimación 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 cómputo y a muchos de los
programadores que participaron en el proyecto anterior,
por lo que la estimación se puede reducir en un 20 %.
 JUICIO EXPERTO
- Mucho código y rutinas comunes se podrán reutilizar
por lo que el esfuerzo se reduce otro 20%.
- Por lo tanto el nuevo proyecto puede ser un 20% más
económico que el anterior.
JUICIO EXPERTO
Ventajas
1. Se obtiene una estimación 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 corporación 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 técnica
se lleva a cabo de la siguiente manera:
 TECNICA DELFI
 1. Un coordinador proporciona a cada experto la
documentación con la Definición del Sistema y una
papeleta para que escriba su estimación.

 2. Cada experto estudia la definición y determina su

estimación en forma anónima; 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 extraño efectuado por alguno de los
expertos.

 4. Los expertos realizan una segunda ronda de

estimaciones, otra vez anónimamente, utilizando los
resultados de la estimación anterior. En los casos en que
una estimación difiera mucho de las demás, se podrá
solicitar que también en forma anónima el experto
justifique su estimación.
 TECNICA DELFI
 5. El proceso se repite tantas veces como se juzgue
necesario, impidiendo una discusión grupal durante el
proceso.
ECUACION DE PRIMER ORDEN DE
JONES

 Carpes Jones propone una ecuación derivada del análisis de

su base de datos de cientos de proyectos.

 Este es también un modelo empírico de estimación.

 Con la suma total de puntos de función , se puede realizar a

partir de ellos un cálculo aproximado de la planificación.
ECUACION DE JONES
La ecuación de Jones tiene la forma:
TDEV = #PF n
Donde TDEV = Tiempo de planificación ( meses )
#PF = No. de Puntos de Función
n = Exponente según la tabla siguiente
ECUACION DE JONES
CLASE DE MEJOR CASO MEDIA(NOMINA PEOR CASO
SOFTWARE L)
APLICACIÓN 0.39 0.42 0.45
GESTIÓN 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 pequeño conjunto de
funciones del software ( miniproyecto ), que implica
análisis, diseño, codificación, pruebas, documentación y
evaluación del cliente.
 La técnica permite determinar el número 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 función del software.

Asegurarse de que quien haga la estimación sea el desarrollador que posea

el mayor conocimiento de la función dada.
TECNICA ITERATIVA
2.- Determine el número de programadores.
Utilizando los registros de proyectos anteriores, busque una
aproximación con el Esfuerzo del proyecto actual y deduzca
el número de programadores que convendría 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
dedicarán el 100% de la jornada en trabajo productivo.
Investigaciones de cómo usan su tiempo los programadores
indican QUE:

Ejemplo: Suponga una productividad del 50% para este

ejemplo.
TECNICA ITERATIVA
4.- Determine la longitud de la iteración.
Se busca una longitud de iteración fija para todo el proyecto,
de modo que se pueda lograr un ritmo regular de entrega
del proyecto. Cada iteración debe ser lo suficientemente
larga para realizar varias funciones del software.

Puede considerar longitudes de iteración de 2 a 8 semanas.

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

Ejemplo:
 Esfuerzo por iteración = 5 * 3 * 0.5 = 7.5 semanas-
programador
TECNICA ITERATIVA
6.- Calcular el número de iteraciones.

No. Iteraciones = ( Esfuerzo Total / Esfuerzo por Iteración ) +

1

Ejemplo:
 No. Iteraciones = ( 50 / 7.5 ) + 1 = 7.6 aprox. 8 iteraciones
7.- Calcular el tiempo de desarrollo.
Teniendo la longitud y el número de iteraciones es fácil
determinar el tiempo de desarrollo

Tdev = Long. Iteración * 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 construcción,
dependiendo de lo arriesgada que parezca la situación.
 Ejemplo:
 Considerando el factor 40-20-40, es decir, el 40% de
esfuerzo es Analisis-Diseño, 20% Codificación y 40%
Pruebas, calculamos que el tiempo posible de construcción
( codificación ) 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 sería para 24.75 semanas, 4 días más.
TECNICAS DE ESTIMACION DE
COSTOS
METODO HISTORICO
 Este método 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 jerarquía de modelos de estimación para el software.

• Las ecuaciones del modelo COCOMO básico 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
número estimado de Líneas de Código distribuídas para el
proyecto.
Jerarquías de Cocomo
• El modelo COCOMO básico es un modelo univariable
estático que calcula el esfuerzo (y el costo) del
desarrollo de software en función del tamaño del
programa expresando en líneas de código (LDC)
estimadas.
COCOMO
 El modelo COCOMO intermedio calcula el esfuerzo
del desarrollo de software en función del tamaño del
programa y de un conjunto de “conductores de costo”,
que incluyen la evaluación subjetiva del producto, del
hardware, del personal y de los atributos del proyecto.
cocomo
 El modelo COCOMO avanzado incorpora todas las
características de la versión intermedia y lleva a cabo
una evaluación de impacto de los conductores de costo
en cada fase (análisis, diseño, etc.) del proceso de
ingeniería de software.
Cocomo Orientado a los Tipos de
proyecto de software
• Modelo Orgánico. Proyectos de software
relativamente pequeños y sencillos en los que trabajan
pequeños equipos, con buena experiencia en la
aplicación, sobre el conjunto de requisitos poco rígidos
(por ejemplo, un programa de análisis termal
desarrollado para un grupo calórico).
Cocomo Orientado a los Tipos de
proyecto de software
 Modelo Semiacoplado. Proyectos de software
intermedios (en tamaño y complejidad) en los que los
equipos, con variados niveles de experiencia, deben
satisfacer requisitos poco o medio rígidos (por
ejemplo, un sistema de procesamiento de
transacciones con requisitos fijos para un hardware de
terminal o un software de gestión 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 navegación para
un avión).
COCOMO
 Las ecuaciones son de la forma:
 PM = a * ( KDSI ) b ; TDEV = c * ( PM ) d

 Programas de Aplicación: 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
Calendarización

 Fundamentos
 La realidad de un proyecto técnico, tal como uno de
software, es que hay que realizar cientos de tareas
pequeñas en un orden determinado antes de poder
alcanzar la meta final. Las tareas están
interrelacionadas en una secuencia lógica en el sentido
de que algunas de ellas no pueden empezar hasta que
otras se hayan terminado.
 Calendario
Dividir el proyecto en actividades o tareas
Estimar el tiempo necesario para realizarlas (algunas
se harán 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,...)
Duración aconsejable de una actividad: entre 1 y 8
semanas

-76-
 Calendario (cont.)
Importante tener en cuenta posibles problemas
(personal, hardware, software,...) que provocan
retrasos.
Problemas previstos: incrementar un 30% la
estimación inicial.
Problemas no previstos: incrementar un 20%.
Utilización de diagramas de Gantt y redes de
actividades

-77-
Herramientas Automáticas de
Calendarización
CONSEJOS SOBRE ESTIMACIONES
 1. Evite estimaciones improvisadas ( ojo de buen cubero ).
 2. Use datos de proyectos anteriores ( método histórico ).
 3. Las estimaciones las debe hacer el desarrollador, no el directivo.
 4. Estime por concenso ( técnica delfi ).
 5. Evite estimar el proyecto como un todo.
 6. Estime por descomposición, es decir, estime cada función o requisito del
software individualmente. Luego la suma de ellos será la estimación del
proyecto total.
 7. Utilice diferentes técnicas de estimación, compare los resultados y resuelva
las diferencias.
 8. Si es posible use una herramienta automática de estimación. Con esto tendrá
otro punto de comparación.
 9. Refine sus estimaciones a medida que conozca más detalles del proyecto.
 10. Emita una estimación preliminar después de revisar la Definición del
Sistema. Refinela durante el Análisis y de una estimación definitiva después de
revisar el Diseño. Si esto no es posible, trate de emitir su estimación definitiva
al terminar el Análisis. Si aún esto no es posible, deberá formularla solo con la
Definición del Sistema pero considere un factor de seguridad adecuado.
 11. Presente sus estimaciones usando rangos o casos ( mejor, más probable, peor
).
 12. Defienda sus estimaciones.

 Finalmente Ud. y su equipo son los que conocen el proyecto y lo desarrollarán.

En lo posible evite que un directivo le imponga una estimación que no esté
justificada, para esto debe prepararse para defender sus estimaciones.
 13. Negocíe con el cliente.
¿Preguntas?