ISIII UNID3 Estimación Costo

Mediciones y Técnicas de Estimación
OBJETIVOS
 Tener una visión general sobre el Modelo de Estimación de costos.
 Conocer el concepto de Métricas, el concepto de Atributos Internos
y Externos.
 Ser capaz de realizar una Estimación de Costos en el Software.
 Conocer los diferentes tipos Estimación de Recursos.
 Tener una visión general sobre el Modelo de Puntos de Función.
 Conocer la definición de Modelo de Puntos de Función.
 Conocer y comprender el número y la complejidad de los elementos
que componen los puntos de función.
 Saber utilizar la Tabla para el cálculo de los Factores de
Complejidad
 Conocer el concepto de Distribución Genérica del Esfuerzo.
 Comprender la Estimación de primer orden de Jones.
 Comprender la Estimación por el método de CoCoMo.
 Tener una visión general sobre el Modelo de Puntos de Caso de
Uso.
 Todo
lo que se hace o define se
puede medir
 Sólo si se mide se puede controlar
 Sólo si se controla se puede dirigir
 Sólo si se dirige se puede mejorar
MÉ TRICAS
Una métrica es, una asignación

de valor a un atributo de una
entidad propia del software, ya
sea un producto o un proceso
o un proyecto.
MÉTRICAS
La medición permite ganar

comprensión acerca del
producto, del proceso y del
proyecto, al proporcionar un
mecanismo de evaluación
objetiva.
LA MÉTRICA DEL SOFTWARE
Según el contexto en
el que se apliquen
Métricas de proceso Métricas de producto
Métricas de proyecto
MÉTRICAS DE PROCESO
Las métricas de proceso se recopilan a

través de todos los proyectos y durante
largos espacios de tiempo.
Su intención es proporcionar un
conjunto de indicadores de proceso que
conduzca a mejorar el proceso de software
a largo plazo.
MÉTRICAS DE PROCESO
MÉTRICAS DE PROYECTOS
A diferencia de las métricas de proceso de
software que se usaron con propósitos
estratégicos, las medidas de proyecto de
software son tácticas.
Es decir, el gerente de proyecto y un
equipo de software usan las métricas de
proyecto y los indicadores derivados de ellas
para adaptar el flujo de trabajo del proyecto y
las actividades técnicas.
Las métricas de proyecto permiten al gerente de
un proyecto de software:
 Valorar el estado de un proyecto en marcha,
 Rastrear riesgos potenciales,
 Descubrir áreas problema antes de que se
vuelvan “críticas”,
 Ajustar el flujo de trabajo o las tareas,
 Evaluar la habilidad del equipo del proyecto
para controlar la calidad de los productos
operativos del software.
La intención de las métricas de proyecto es doble.
Se usan para minimizar el calendario de
desarrollo al hacer los ajustes necesarios para
evitar demoras y mitigar potenciales problemas y
riesgos.
Se usan para valorar la calidad del producto
sobre una base en marcha y, cuando es
necesario, modificar el enfoque técnico para
mejorar la calidad.
MÉTRICAS DE PROCESO Y PROYECTO
En general, las mediciones que se realizan son pocas y simples.
 Para el proceso estas corresponden a: Costo y esfuerzo
incurridos a lo largo del tiempo hasta la finalización del
proyecto.
 Para el producto son:
• Líneas de código o puntos de función
• Paginas de documentación escrita
• Velocidad de ejecución de los programas
• Cantidad de personal involucrado
• Experiencia del equipo de desarrollo
• Costo
• Disponibilidad de herramientas utilizadas
• Y otros
MEDICIÓN DE SOFTWARE
Las medidas directas del proceso de software incluyen
costo y esfuerzo aplicado.
Las medidas directas del producto incluyen líneas de
código (LOC) producidas, rapidez de ejecución,
tamaño de memoria y defectos reportados sobre cierto
espacio de tiempo.
Las medidas indirectas del producto incluyen
funcionalidad, calidad, complejidad, eficiencia,
confiabilidad, capacidad de mantenimiento y muchas
otras “habilidades”
En general se desea medir los siguientes
aspectos en Ingeniería de Software
Procesos o tareas a ejecutar (modelado,
diseño, prueba)
Productos entregados durante el proceso
(documentación de diseño, código fuente,
registro de prueba)
Recurso que permiten realizar el proceso
(personal, computadora, dinero)
MÉTRICAS ORIENTADAS AL TAMAÑO
Las métricas de software orientadas

al tamaño se derivan al normalizar
las medidas de calidad y/o
productividad para considerar el
tamaño del software que se produjo.
MÉTRICAS ORIENTADAS AL TAMAÑO
Productividad = KLOC / PM.

Calidad = defectos / KLOC.
Costo = $ / LOC.
Documentación= Paginas de documentación/KLOC.
Donde:
LOC = Líneas de código fuente entregada.
PM = persona mes destinados al proyecto.
MÉTRICAS ORIENTADAS A FUNCIÓN
Las métricas de software orientadas a la

función usan una medida de la funcionalidad
entregada por la aplicación como un valor de
normalización.
La métrica orientada a la función de mayor
uso es el punto de función (PF). El cálculo del
punto de función se basa en características del
dominio y de la complejidad de información del
software.
RECONCILIACIÓN DE MÉTRICAS LOC Y PF
La relación entre líneas de código

y puntos de función depende del
lenguaje de programación que se
use para implementar el software y
la calidad del diseño. Algunos
estudios intentan relacionar las
medidas PF y LOC.
RECONCILIACIÓN DE MÉTRICAS LOC Y PF
MÉTRICAS ORIENTADAS A OBJETOS
Las métricas de proyecto de software

convencional (LOC o PF) pueden usarse para
estimar proyectos de software orientados a objeto.
Sin embargo, dichas métricas no proporcionan
suficiente granularidad para los ajustes de calendario
y esfuerzo que se requieren conforme se repite a
través de un proceso evolutivo o incremental.
MÉTRICAS ORIENTADAS A OBJETOS
Lorenz y Kidd [Lor94] sugieren el siguiente

conjunto de métricas para proyectos OO:
Número de clases clave
Número de clases de apoyo
Número promedio de clases de apoyo por
clase clave
Número de subsistemas
MÉTRICAS ORIENTADAS A CU
Los casos de uso describen (de manera
indirecta, al menos) las funciones y
características visibles para el usuario que son
requisitos básicos para un sistema.
El caso de uso es independiente del lenguaje
de programación.
El número de casos de uso es directamente
proporcional al tamaño de la aplicación.
MÉTRICAS ORIENTADAS A CU
Los investigadores sugieren puntos de

caso de uso (PCU) como un mecanismo
para estimar el esfuerzo del proyecto y
otras características.
Los PCU son una función del número
de actores y transacciones implicados
por los modelos de caso de uso y su
análogo al PF en algunas formas.
MÉTRICAS DE PROYECTOS WEBAPP
El objetivo de todos los proyectos webapp es

entregar al usuario final una combinación de
contenido y funcionalidad.
Las medidas y métricas usadas para proyectos
tradicionales de ingeniería del software son difíciles
de traducir directamente a webapps.
Sin embargo, es posible desarrollar una base de
datos que permita el acceso a medidas productivas
y calidad internas derivadas de algunos proyectos.
MÉTRICAS DE PROYECTOS WEBAPP
Entre las medidas que pueden recopilarse están:
 Número de páginas web estáticas.
 Número de páginas web dinámicas.
 Número de vínculos de página internos.
 Número de objetos de datos persistentes.
 Número de sistemas externos puestos en interfaz.
 Número de objetos de contenido estáticos.
 Número de objetos de contenido dinámicos.
 Número de funciones ejecutables
MÉTRICAS
De las estadísticas que generan los

proyectos realizados se puede
obtener algunos indicadores o
métricas de calidad y productividad.
MÉTRICAS
Una forma de estimar es:
 Utilizar métricas basadas en
mediciones pasadas para hacer las
estimaciones o
 Dividir el proyecto en pequeñas
unidades o partes para facilitar la
estimación.
ATRIBUTOS DE TÉCNICAS DE ESTIMACIÓN
MODELO DE ESTIMACIÓN DE COSTOS
La estimación de costos, tiempo y

recursos para el esfuerzo de desarrollo
de software requiere experiencia, acceso
a una buena información histórica y
coraje para confiar en medidas
cuantitativas cuando todo lo que existe
son datos cualitativos.
ATRIBUTOS DE TÉCNICAS DE ESTIMACIÓN
Existen tres puntos que caracterizan al proyecto a estimar:
 Lacomplejidad del proyecto, que tiene un gran efecto
sobre la incertidumbre que es inherente a la planificación.
Esta es una medida relativa por que depende de la
familiaridad con anteriores esfuerzos.
 Eltamaño del software, es otro factor importante y puede
afectar a la precisión y eficacia de las estimaciones.
 Elgrado de estructuración del proyecto, la estructuración
se refiere a la facilidad con que las funciones pueden ser
subdivididas y la naturaleza jerárquica de la información a
ser procesada.
ESTIMACIÓN DE COSTOS EN EL SW
En todo proyecto existe un presupuesto

asignado, el cual debe ser controlado y
respetado.
Para realizar esto es necesario planificar
adecuadamente el QUE hacer, por lo cual
una de las primeras actividades a realizar
es la de estimar el costo del desarrollo.
Las estimaciones tienen asociado en forma
inherente, un grado de riesgo e incertidumbre
que incide en la probabilidad de éxito, en la
estimación y por ende en el resultado.
Los componentes principales de costo son:
Hardware
Entrenamiento
Esfuerzo
Existen siete técnicas posibles para estimar los costos
del SW
 Modelos algorítmicos, se utiliza un modelo basado en
información histórica que relaciona información
histórica de costo con alguna métrica del proyecto.
 Juicio experto, El costo es obtenido por consenso de
expertos en el desarrollo. La experiencia debe ser en
las tecnologías y aplicación a desarrollar.
 Estimación por analogía, se basa en el desarrollo
previo de proyectos similares
Existen siete técnicas posibles para estimar los costos del SW
(cont.)
 Ley de Parkinson, el trabajo se expande hasta llenar todo el
tiempo disponible
 Precio para ganar, el costo se estima según el presupuesto
disponible
 Estimación Top-Down. El costo se estima considerando la
funcionalidad total del producto y como ésta es provista por las
sub-funciones interactuantes. El costo se basa en las funciones
lógicas.
 Estimación Botton up, se estima el costo de cada componente
para luego agregarse en un costo total
Dentro de la mayor parte de las

organizaciones, la estimación de costos se basa
en las experiencias pasadas.
Desde un punto de vista ideal se deben
aplicar conjuntamente todas las técnicas
apropiadas, usando cada una de ellas como
comprobación de las otras.
Posibles costos de un sistema de información
Costos de  Costos de consulta
elaboración  Costos de alquiler o de compra de los equipos
 Costos de modificación del emplazamiento de los equipos
(a.a., seguridad, etc.)
 Costos del capital
 Costos de gestión y de personal
Costos de puesta en  Costos del software del S.O.
marcha  Costos de la instalación de los equipos de comunicaciones
(líneas telefónicas, y de datos)
 Costos del personal para la puesta en marcha
 Costos de contratación del personal y alquileres
 Costos de interrupción en el resto de la organización
 Costos de gestión necesarios para dirigir la actividad inicial
Costos  Costos de adquisición de software de aplicación
relacionados con  Costos de las modificaciones del SW para que
el proyectos encajen con los sistemas locales
 Costos del personal, gastos generales, etc. Del
desarrollo de aplicaciones internas
 Costos de entrenamiento del personal en el uso
de las aplicaciones
 Costos de recogida de información y
procedimiento de instalación
 Costos de preparación de la documentación
 Costos de la supervisión del desarrollo

Costos del  Costos de mantenimiento del sistema
proceso (HW, SW e instalaciones)
 Costos de suministros (electricidad,
Telef., etc.)
 Costos de depreciación del HW
 Costos del personal involucrado en la
gestión de los sistemas de información,
operación y actividades de
planificación
ESTIMACIÓN DE RECURSOS
 Recursos Humanos: Determinar el personal
necesario, la posición dentro de la organización, y la
especialidad requerida. La cantidad solo puede ser
determinada después de hacer una estimación.
 Recursos de HW: durante la planificación del proyecto
de SW, se deben considerar básicamente tres
categorías de HW:
 Sistema de desarrollo
 Sistema de producción
 Otros elementos de HW del nuevo sistema
ESTIMACIÓN DE RECURSOS
 Recursos de SW: herramientas que tiene distintos
propósitos como:
 Gestión de proyectos
 Soporte
 Análisis y diseño
 Programación
 Mantenimiento
 Otros.
CANTIDAD DE REFINAMIENTO POSIBLE
Investigadores han descubierto que las
estimaciones de proyectos entran dentro
de precisiones previsibles en varios
estados del proyecto.
El gráfico de convergencia de
estimación muestra como la estimación se
hace más precisa conforme avanza el
proyecto.
GRAFICO DE CONVERGENCIA DE ESTIMACIÓN
Costo del proyecto Duración del
(esfuerzo y tamaño) proyecto
4x 1,6x
2x 1,25x
1,5x 1,15x
1,25x 1,25x
1,0x 1,0x
0,8x 0,9x
0,67x 0,85x
0,5x 0,8x
0,25x 0,6x
     
Definición Definición Especificación Especificación Especificación Producto
inicial del del producto de del diseño del diseño Terminado
producto aprobada requerimientos del producto detallado
ESTIMACIÓN FRENTE A CONTROL
Las prestaciones se adaptan para
La mayoría de los adecuarse a los recursos disponibles
clientes de software
desean inicialmente
más de lo que se Conjunto de prestaciones deseado
inicialmente
pueden permitir, y
tienen que adaptar sus Tamaño del
producto Prestaciones
ideas sobre el producto
a los recursos con los Recursos
que están dispuestos a Recursos disponibles inicialmente
comprometerse.
Evolución del
Proyecto
ESTIMACIÓN FRENTE A CONTROL
Los recursos se adaptan para
adecuarse a las prestaciones deseadas
A veces el cliente
deseará adaptar
Conjunto de prestaciones deseado
tanto los recursos inicialmente
como el conjunto de Tamaño del

Prestaciones
prestaciones para producto
Recursos
llegar a un acuerdo
entre ambos.
Recursos disponibles inicialmente
Evolución del
Proyecto
CONVERGENCIA ENTRE ESTIMACIÓN Y REALIDAD
Si los clientes desean la planificación más

corta posible, no deberían presionar para
reducir la estimación o proporcionar unas
estimaciones “precisas” equivocadas.
La planificación real más corta resulta de
la programación planificada más precisa.
CONVERGENCIA ENTRE ESTIMACIÓN Y REALIDAD
Si la estimación es demasiado baja, la

planificación ineficiente conducirá al costo real
del proyecto.
Si la estimación es demasiado alta, según la
ley de Parkinson (el trabajo se reparte para
cubrir el tiempo disponible), conducirá al costo
real del proyecto.
INTRODUCCIÓN AL PROCESO DE ESTIMACIÓN
El proceso para crear una planificación exacta consta de tres pasos:
 Estimar el tamaño del producto (número de líneas de código o
puntos de función). Algunos proyectos saltan directamente a la
estimación de la planificación, pero una estimación efectiva
necesita estimar primero el tamaño del software para poder
construirlo. Este paso es con frecuencia el más difícil
intelectualmente, y ésta podría ser una de las razones por las que
se lo suelen saltar.
 Estimar el esfuerzo (personas-mes). Si tiene una estimación exacta
del tamaño y los datos previos de la organización en proyectos
similares, es fácil realizar la estimación del esfuerzo.
 Estimar la planificación (meses). Una vez que se han estimado el
tamaño y el esfuerzo, estimar la planificación resulta casi trivial.
Pero obtener la aceptación de una estimación de la planificación
realista puede ser la parte más difícil del proyecto.
MODELO DE PUNTOS DE FUNCIÓN
VISIÓN GENERAL
Objetivo: traducir en un Número el tamaño de la
funcionalidad que brinda un producto de software
 Desde el Punto de vista del usuario
 Suma ponderada de características del producto:
Transacciones
 Nro. Entradas Externas (EI- External Input)
 Nro. Salidas Externas (EO- External Output)
 Nro. Consultas Exts. (EQ- External inQuiry)
Datos
 Nro.Archivos Int. Lógicos (ILF- InternalLogical File)
 Nro.Arch. Interfaz Externa (EIF-External Interface File)
Frontera de
EI la aplicación
EQ Archivos Lógicos
EO Internos (ILF)
No mantenidos
por la aplicación
EO
datos derivados
Archivos de Interfaz
y/o afecta EQ Externos (EIF)
comportamiento
PF = PFSA x Factor de Ajuste

Modelo de Puntos de Función
Visión del Cliente - Usuario
 No todo archivo físico o tabla se traduce en un archivo
lógico interno o archivo de interfaz externo ILF (o EIF)
 No todo archivo o tabla tiene por qué ser un ILF o EIF
(archivos transitorios o de trabajo NO se cuentan)
 Una transacción que ocurre en múltiples entradas
físicas (archivo de transacciones o pantallas, con
idéntica lógica de procesamiento, se considera como
una sola transacción
 Un mismo reporte físico, pantalla o archivo de salida
pueden corresponder a más de un EO/EQ
 Reordenar o reacomodar los datos no se considera
como lógica de procesamiento única
FRONTERA DE LA APLICACIÓN
 Define lo que es “externo” a la aplicación
 Interfaz entre lo “interno” y el “mundo exterior”
 Se puede concebir como una “membrana” que atraviesan
los datos procesados por las transacciones (EI, EO, EQ)
 Encierra los archivos lógicos mantenidos por la
aplicación(ILF)
 Asiste en la identificación de los archivos lógicos
referenciados pero no mantenidos por la aplicación (EIF)
 Depende de la visión del negocio y externa del usuario
 Es independiente de consideraciones técnicas o de
implementación.
Usuario 1
Contabilidad
RR.HH. Fronteras definidas

a partir de la visión
del negocio
Ventas
¿cómo impactaría en
la cuenta total de PF
considerar esta otra
frontera?
FRONTERA DE LA APLICACIÓN (2)

FRONTERA DE LA APLICACIÓN (3)
 Incide en la cuenta total de PF
 al partir una aplicación se incrementan los PF totales porque los ILF se
cuentan una vez como tales (por lo menos) y también se cuentan
como EIF
 Sedetermina a partir de la visión de usuario basada en áreas
funcionales separadas y NO en consideraciones técnicas
 una aplicación Cliente/Servidor es una unidad; la frontera debe
englobar a ambos: Cliente y Servidor
 una aplicación que se extiende para que funcione en Internet no se
puede (por eso solo) considerar como dos aplicaciones a los efectos
de los PF
 Desconfiar de la frontera si:
 no se identifican EIF
 hay demasiados EIF o un mismo archivo es ILF en varias aplics.
PUNTOS DE FUNCIÓN (PF)
Entradas EI (External Input) :

Son todos aquellos procesos que
hacen llegar datos a la aplicación
desde el exterior, desde un usuario u
otra aplicación.
El flujo de datos deberá tener una
sola dirección, del exterior al interior.
Como consecuencia de una
entrada, siempre deberá actualizarse
un fichero lógico interno.
Entradas:
Ejemplos:
 Pantallas de entrada de datos.
 Lector de códigos de barras.
 Lector de tarjetas magnéticas y electrónicas.
 Captura de imágenes, voz, etc.
Realizaremos las siguientes preguntas para asegurarnos de contar una
entrada:
Pregunta Respuesta
Entran datos desde exterior de la aplicación Sí
Existen datos en algún fichero lógico interno que son
Sí
actualizados
El proceso es la unidad mínima de actividad que tiene sentido
Sí
para el usuario
El proceso es completo y deja al sistema en un estado
SÍ
consistente
Para el proceso subyacente se debe de cumplir
Lógica del proceso exclusiva de esta entrada, o la
A
primera vez que la contamos AoB
B Los datos elementales son diferentes de otras entradas

Clasificación de las entradas:
DIFICULTAD Número de Campos o Atributos de la Entrada
ENTRADAS
1-4 Atributos 5-15 Atributos 16 + Atributos
0 ó 1 ficheros
BAJA BAJA MEDIA
accedidos
2 ficheros
BAJA MEDIA ALTA
accedidos
3 + ficheros
MEDIA ALTA ALTA
accedidos
Salidas EO (External Output)

Son todos aquellos procesos
que hacen llegar datos desde la
aplicación hacia el exterior, a un
usuario o a otra aplicación.
El flujo de datos deberá tener
una sola dirección, del interior al
exterior
La salida debe tener por lo
menos un calculo con datos desde
la aplicación hacia el exterior.
Salidas:
 Ejemplos:
 Pantallas de salida de datos.
 Listados.
 Grabación de bandas magnéticas.
 Transferencia de datos a otras aplicaciones,
ya sea mediante ficheros o transmisión de
datos.
Realizaremos las siguientes preguntas para asegurarnos de contar una salida:
Pregunta Respuesta
El proceso envía datos o información al exterior de la aplicación Sí

El proceso es la unidad mínima de actividad con sentido para el
Sí
usuario
El proceso es completo y deja al sistema en un estado consistente SÍ

Lógica del proceso exclusiva de esta salida (o primera
A AoB
vez)
B Los datos elementales son diferentes de otras salidas
Clasificación de las salidas:

DIFICULTAD Núm ero 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
Consultas EQ (External Query) :

Son todos aquellos procesos que
están formados por una combinación
de entradas y salidas, produciendo
una consulta a los datos.
El flujo de datos deberá tener dos
direcciones.
Como consecuencia de una
consulta no se modifican los datos del
sistema.
La complejidad de la consulta viene
dada por la mayor entre la entrada y la
salida
La salida no puede contener
información derivada (calculada).
Realizaremos las siguientes preguntas para asegurarnos de contar una
consulta:
Preguntas Respuesta
Una petición atraviesa la frontera del sistema Sí
El proceso envía datos o información al exterior de la aplicación Sí
Se recuperan datos Sí
No se calculan datos derivados para enviar al exterior Sí
El proceso (entrada/salida) es la unidad mínima de actividad que tiene
Sí
sentido para el usuario
El proceso es completo y deja al sistema en un estado consistente Sí
El proceso no actualiza ningún Fichero Lógico Interno Sí
Lógica del proceso en su parte de entrada o salida, es distinto
A
del de otras consultas del sistema (o la primera vez) AoB
Los datos elementales de la entrada o salida son diferentes de
B
otras consultas
Ficheros Lógicos Internos (ILF):
Es un grupo de datos
relacionados, tal como los percibe
el usuario y que son mantenidos por
la aplicación. Se identifican a las
agrupaciones de datos que el
usuario ya conoce como relevantes
para el sistema, por ejemplo:
Clientes, Artículos, Facturas,
Proveedores, etc.
Los ficheros se cuentan una sola
vez, independientemente del
número de procesos que los
acceden.
Es importante diferenciar estos
de las entidades, relaciones, las
tablas o los ficheros resultantes del
diseño físico.
Ficheros Lógicos Internos:

 Ejemplos:
 Clientes.
 Socios.
 Artículos.
 Proveedores
Realizaremos las siguientes preguntas para asegurarnos de contar un
Fichero Lógico Interno:
Pregunta: Respuesta
Se trata de una agrupación de datos lógica o identificable desde el

punto de vista del usuario y satisface un requerimiento específico del Sí
usuario
La agrupación de datos es mantenida por procesos de la aplicación

Sí
en estudio
La agrupación de datos es mantenida mediante un proceso elemental

Sí
de la aplicación
La agrupación de datos no ha sido contada como un fichero de

Sí
interfaz externo
Clasificación de los Ficheros Lógicos 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
Externos (EIF): DIAGRAMA DE CONTEXTO
Es un grupo de datos
relacionados, tal como los
percibe el usuario,
referenciados por la
aplicación y que son
mantenidos por otra
aplicación.
Son ficheros internos
de otra aplicación
Realizaremos las siguientes preguntas para asegurarnos de contar un
Fichero de Interfaz Externo:
Pregunta Respuesta
Se trata de una agrupación de datos lógica o identificable desde
el punto de vista del usuario y satisface un requerimiento Sí
específico del usuario
La agrupación de datos es referenciada, y externa, a la
Sí
aplicación en estudio
La agrupación de datos no es mantenida mediante la aplicación
Sí
en estudio
La agrupación de datos ha sido contada como un fichero lógico
Sí
Interno en otra aplicación
La agrupación de datos no ha sido contada como un fichero
Sí
lógico Interno de la aplicación en estudio
Clasificación de los Ficheros de Interfaz:
DIFICULTAD Número de Campos o Atributos
FICHEROS
DE INTERFAZ 1-19 Atributos 20-50Atributos 51 + Atributos
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.
PUNTOS DE FUNCIÓN SIN AJUSTAR
Características del Complejidad Complejidad Complejidad
Sistema Baja Media Alta
Número de entradas X3 X4 X6
Número de salidas X4 X5 X7
Consultas X3 X4 X6
Archivos lógicos X7 X 10 X 15
internos
Archivos de interfaz X5 X7 X 10
externos
EJEMPLO DE PUNTOS DE FUNCIÓN SIN AJUSTAR
Totales
Número de entradas 6 X 3=18 2 X 4=8 3 X 6=18 44
Número de salidas 6 X 4=28 7 X 5=35 0 X 7=0 63
Consultas 0 X 3=0 2 X 4=8 4 X 6=24 32
Archivos lógicos
5 X 7 =35 2 X 10=20 3 X 15=45 100
internos
Archivos de interfaz
9 X 5=45 0 X 7=0 2 X 10=20 65
externos
Total de puntos de
304
función sin ajustar
Finalmente los PUNTOS DE FUNCION
(PF) se obtienen al ponderar los Puntos
de Función No Ajustados (PFNA) por un
factor de complejidad técnica que se
encuentra asociado a 14 características
de la aplicación.
PUNTO DE FUNCIÓN
Tabla para el cálculo de los Factores de Complejidad
Factor de complejidad Valor (0…5)
Co m un i cac ió n d e d a t o s
P ro c e s o Di s t ri bu i do
Re n d im ie nt o
I n t eg r ac ió n
Ta sa de t r an sa c c i o ne s
E n t ra d a d e Da t os O n- Li ne
E f ic i e nc i a pa r a e l u su a rio f in a l
A c t u al iz a c i o ne s O n - Li ne
L óg i c a d e p r oc es o i nt e rn o c o mp le j a
Re u sa b ili d ad d el Có d ig o
Co n t e mp la c o nv er s i ón e I ns t al ac ió n
F a c i lid a d de O p er a c ió n
I n st a la cio n e s Mú lt i pl e s
F a c i lid a d es d e Ca m bi o
To t a l
Puntos de Función – Comunicación de Datos
Los datos usados en el sistema se envían o reciben por líneas de
comunicaciones.
Valores:
0: Sistema aislado del exterior (sólo usuarios directos. Ej.: PC; BATCH ).
1: Aplicación batch con entrada de datos remota o (exclusiva) utilización
de periféricos de salida remotos.
2: Aplicación batch con entrada de datos remota y utilización de periféricos
de salida remotos.
3: Aplicación de captura de datos En_Línea o hay un sistema de
teleproceso que pasa los datos a la aplicación batch o sistema de
consulta.
4: Varios teleprocesos pero con el mismo protocolo de comunicaciones.
5: Hay teleproceso con varios protocolos de comunicación. Sistema
Abierto y con interfaces de todo tipo al exterior.
Puntos de Función
Proceso Distribuido.
Existen procesos o datos distribuidos y el control de éstos forma parte del
sistema.
Valores
0: Sistema totalmente Centralizado o no tiene como objetivo el transferir datos o
procesos entre componentes del sistema.
1: El sistema realiza sus procesos en un equipo, pero las salidas se preparan de modo
que son utilizadas vía software de otros equipos. Por ejemplo a la salida del sistema
se accede vía una hoja de cálculo o un procesador de textos en un PC.
2: El sistema captura los datos en un equipo, que les da formato, siendo enviados a
otro equipo del sistema que los trata.
3: Proceso distribuido pero con transferencia de datos "en línea" en una sola dirección.
4: Proceso de datos distribuidos y transferencia de datos "en línea" en ambas
direcciones. Por ejemplo una red de cajeros automáticos en donde éstos procesan
parte la transacción.
5: El sistema esta ejecutándose en una red con procesos cooperantes ejecutándose en
distintos equipos.
Puntos de Función
Objetivos de Rendimiento.
Si el rendimiento es un requisito del sistema, es decir, es crítico
algún factor como tiempo de respuesta o cantidad de operaciones
por hora. Se tendrá que hacer consideraciones especiales durante
el diseño, codificación y mantenimiento.
Valores
0: Rendimiento normal ( no se da énfasis ).
1: Se indican requisitos, no medida especial.
2: Crítico en algunos momentos. Procesos acabados antes de
próxima sesión de trabajo.
3: Tiempo de respuesta es crítico.
4: ... en diseño hacer análisis de rendimiento en tiempo respuesta o
cantidad operaciones/hora.
5: .. uso herramientas para alcanzar el rendimiento demandado por
el usuario
Puntos de Función
Integración de la Aplicación.
El sistema tendrá que ejecutarse en un equipo en el
que coexistirá con otros, compitiendo por los recursos,
teniendo que tenerse en cuenta en las fase de diseño.
Valores:
0: No se indican restricciones
1: Existen las restricciones usuales
2: Características de seguridad o tiempos.
3: Restricciones en algún procesador
4: El SW deberá funcionar con restricciones de uso en
algún procesador.
5: Restricciones especiales para aplicación en los
componentes distribuidos del sistema
Puntos de Función
Tasa de Transacciones.
Sí la tasa de transacciones será elevada. Se tendrá que hacer
consideraciones especiales durante el diseño, codificación e
instalación.
Valores:
0: No se prevén picos.
1: Se prevén picos poco frecuentes (mensual). Ej. automatricula
2: Se prevén picos semanales.
3: Se prevén horas en punta, diarias. Ej. Venta en
supermercados
4: Tasa de transacción tan elevada que en diseño se hace
análisis de rendimiento.
5: Análisis de rendimiento en diseño, implementación e
instalación.
Puntos de Función
Entrada de Datos On-line.
La entrada de datos será directa desde el
usuario a la aplicación, de forma interactiva.
Valores:
0: Todo es Batch.
1: 1%<entradas interactivas <7%.
5: Entradas interactivas >30%.
Puntos de Función
Eficiencia para el Usuario Final.
Se demanda eficiencia para el trabajo del usuario, es decir, se
tiene que diseñar e implementar la aplicación con interfaces
fáciles de usar y con ayudas integradas.
Valores:
0: No se da énfasis al tema
1: 1 a 3 de los factores
2: 4 a 5 de los factores
3: 6 o más factores, sin requerir eficiencia
4: ... con requerimientos que implican estudio de los factores
humanos en el diseño
5: … se demandan prototipos y herramientas para verificar que
se alcanzaran los objetivos
Puntos de Función
Eficiencia para el Usuario Final (Factores).
Tipos de factores asociados a la eficiencia del usuario.
 Menús.
 Uso de ratón.
 Ayudas "en_línea".
 Movimiento automático del cursor.
 Efectos de Scroll (papiro).
 Teclas de función predefinidas.
 Lanzamiento de procesos Batch desde las transacciones "en_línea“.
 Selección mediante cursor de datos de la pantalla;
 Pantallas con muchos colores y efectos;
 Posibilidad de "hard-copy".
 Ventanas de "pop-up";
 Aplicación bilingüe (cuenta por cuatro).
 Aplicación Multilingüe (mas de dos, cuenta por seis).
Puntos de Función
Actualizaciones On-line.
Los ficheros maestros y/o las Bases de Datos son
modificados de forma interactiva.
Valores:
0: No hay.
1: De 1 a 3 ficheros con información de control;
cantidad baja y ficheros recuperables.
2: ... pero con 4 o más ficheros de control
3: Actualización de ficheros importantes
4: ... esencial la protección ante pérdidas
5: Gran cantidad de actualizaciones interactivas;
sistemas de recuperación muy automatizados
Puntos de Función
Lógica de Proceso Interno Compleja.
La complejidad interna en un proceso esta en función de las
siguientes características:
 Especificados algoritmos matemáticos complejos.
 Proceso con lógica compleja.
 Especificado muchas excepciones, consecuencia de transacciones
incompletas, que deberán tratarse.
 Manejar múltiples dispositivos de entrada / salida.
 Se incorporarán sistemas de seguridad y control.
Valores:
0: Ninguna de las características.
1: 1 Característica.
2: 2 Características.
...
5: Las 5 características
Puntos de Función
Reusabilidad del Código.
Es necesario hacer consideraciones especiales durante el diseño,
codificación y mantenimiento para que el código se reutilice en otras
aplicaciones.
Valores:
0: No se prevé.
1: Reutilizar código en la misma aplicación.
2: Menos de un 10% de la aplicación tiene en cuenta las necesidades
de + de 1 usuario.
3: El 10 % o más ...
4: Aplicación preparada para ser reutilizable a nivel de código.
5: Aplicación preparada para ser reutilizable por medio de
parámetros.
Puntos de Función
Contempla la conversión e instalación
Se proveerán facilidades de conversión e instalación en el sistema, se
tendrá que hacer consideraciones especiales durante el diseño,
codificación y pruebas para que la conversión del sistema antiguo sean
fáciles de realizar durante la puesta en marcha del sistema nuevo.
Valores :
0: No se requiere conversión.
1: Se solicita facilidad de instalación.
2: Se solicitan procesos de conversión e instalación, no importantes
para el proyecto.
3: ... si son importantes.
4: 2 y herramientas conversión e instalación.
5: 3 y herramientas conversión e instalación; sistema crítico para la
empresa.
Puntos de Función
Facilidad de Operación.
Facilitar la explotación real de la aplicación, dedicando
especial atención durante el diseño, codificación y pruebas del
sistema.
Se pueden tener en cuenta las siguientes posibilidades de
automatización:
 Procesos de arranque, back-up y recuperación pero con
intervención del operador.
 … sin intervención del operador (vale por 2).
 Minimizar la necesidad de montar cintas u otros dispositivos
de almacenamiento externo.
 Minimizar la necesidad de manejar papel.
Puntos de Función
Facilidad de Operación
Valores:
0: No se especifica nada.
1 a 4: Sumar la cantidad de ítems de la
lista anterior.
5: Sistema automático sin intervención
humana.
Puntos de Función
Instalaciones Múltiples.
El sistema ha de incluir los requerimientos de diversas
empresas o departamentos en donde se ejecutara (incluso
plataformas). Estas características se estarán presentes
durante el diseño, codificación y pruebas.
Valores:
0: 1 solo lugar.
1: Múltiples lugares, mismo Hw y Sw.
2: En diseño se tiene en cuenta el caso (1).
3: En diseño se tiene en cuenta múltiples entornos Hw y Sw.
4: Se documenta y planea para (1) y (2).
5: Idem, para (3).
Puntos de Función
Facilidad de Cambios.
Se tendrá que hacer consideraciones especiales durante el diseño,
codificación y mantenimiento para que en el sistema sea fácil de
introducir cambios y fácil de adaptar al usuario.
Items a tener en cuenta:
Consultas flexibles del usuario:
• Simples con condiciones. lógicas And/Or que implican un
único fichero lógico. (por 1)
• Medias con cond. lógicas sobre más de 1 F.L. (por 2).
• Complejas con condiciones lógicas complejas que afectan a
varios F.L. (por 3).
Parámetros de la aplic. con tablas ajenas al código:
• El cambio se hace efectivo al arrancar el sistema. (por 1)
• El cambio es interactivo (por 2).
Puntos de Función
Facilidad de Cambios
Valores:
0: No se especifica nada
1: Un ítem de valor 1
2: Items por valor 2
3: ...
5: Items por valor 5
ESTIMACIÓN UTILIZANDO EL MODELO DE PUNTOS DE FUNCIÓN
EJEMPLO
Totales
Número de
6 X 3=18 2 X 4=8 3 X 6=18 44
entradas
Número de salidas 6 X 4=28 7 X 5=35 0 X 7=0 63
Consultas 0 X 3=0 2 X 4=8 4 X 6=24 32
Archivos lógicos
5 X 7 =35 2 X 10=20 3 X 15=45 100
internos
Archivos de interfaz
9 X 5=45 0 X 7=0 2 X 10=20 65
externos
Total de puntos de
304
función sin ajustar
ESTIMACIÓN DE LOS PUNTOS DE FUNCIÓN
EJEMPLO
Tabla para Calculo de los FC
Nro. Preguntas Vi
1 Requiere comunicación de datos? 5

2 Requiere funciones de procesamiento distribuido? 0
3 Es critico el rendimiento? 2
Será ejecutado el sistema en un entorno operativo existente y
4 fuertemente utilizado? (Integración de las aplicaciones) 3
Las transacciones de entrada se llevan a cabo sobre múltiples
5 pantallas u operaciones? 0
6 Requiere el sistema entrada de datos interactiva (On-line)? 1
Se diseño la aplicación pensando en la eficiencia del usuario
7 final? 1
8 Se utilizan archivos maestros de forma interactiva ? 2
EJEMPLO (CONT…)
9 Es complejo el procesamiento interno ? 1
10 Se ha diseñado el código para ser reutilizable ? 4
11 Están incluidas en el diseño la conversión y la instalación? 3
Que tan efectivos y/o automatizados son los procedimientos de

12 1
inicio, respaldo y recuperación? (Facilidad de Operación)
Se ha diseñado el sistema para soportar múltiples instalaciones en

13 3
diferentes organizaciones?
Se ha diseñado la aplicación para facilitar los cambios y para ser
14 4
fácilmente usada por el usuario?
Suma= 30
Valores de Ajuste
VAF = 0,65 + (0,01* Suma) = 0,65 + (0,01 * 30) 0,95
EJEMPLO
Número de entradas 6 X 3=18 2 X 4=8 3 X 6=18
Número de salidas 6 X 4=28 7 X 5=35 0 X 7=0
Consultas 0 X 3=0 2 X 4=8 4 X 6=24
Archivos lógicos internos 5 X 7 =35 2 X 10=20 3 X 15=45
Archivos de interfaz 9 X 5=45 0 X 7=0 2 X 10=20
externos
Total de puntos de función 304
sin ajustar
Multiplicador 0,95
Total de puntos de función 289
ajustados
Cantidad de líneas de código
por puntos de función
LÍNEAS DE CÓDIGO/PUNTOS DE FUNCIÓN
(DEPENDIENTE DEL LENGUAJE DE PROGRAMACIÓN)
LÍNEAS DE CÓDIGO/PUNTOS DE FUNCIÓN
(DEPENDIENTE DEL LENGUAJE DE PROGRAMACIÓN)
Para el ejemplo de 289 PF en un proyecto a

desarrollar en JAVA la estimación de cantidad
de líneas de código, utilizando el valor de la
mediana:
289 * 53 = 15.317 LDC
Estimación de
Esfuerzo
ESTIMACIÓN DE ESFUERZO
El esfuerzo de desarrollo de un proyecto significa

básicamente cuantas personas se van a ocupar en el
desarrollo de un proyecto.
El esfuerzo de un proyecto se mide en unidades
de:
Persona – Año : [PA]
Persona – Mes: [PM]
Persona – Día: [PD]
Para los cálculos tendremos en cuenta las

siguientes conversiones:
1 año posee 12 meses de trabajo.
1 año posee 240 días de trabajo.
1 mes posee 20 días de trabajo.
Por tanto utilizaremos las siguientes conversiones:
1 [PA] persona - año = 12 [PM] persona - mes

1 [PA] persona – año = 240 [PD] persona - día
1 [PM] persona – mes = 20 [PD] persona - día
Para calcular el esfuerzo se tomaran

los siguientes tipos de esfuerzo:
Esfuerzo Medido
Esfuerzo Estándar
Esfuerzo Medido: representa el tiempo real de

termino del proyecto que se obtiene por los datos
recogidos del proyecto.
Esta dado por el total de personas involucradas
por el tiempo de desarrollo
Esfuerzo Medido = No. De personas x Meses de Duración [PM]
Esfuerzo Estándar: Productividad por Puntos

Aquel que representa de Función
un esfuerzo de
[PF/PA] [PF/PM]
desarrollo tomada de
una productividad Mundial 92,5 7,70833
constante.
Tomaremos como USA 88,17 7,34750
dato para los cálculos
la productividad Canadá 111 9,25
mundial. Datos recogidos de estadísticas en la revista IT METRICS
STRATEGIE
Por tanto el esfuerzo se calculará mediante la siguiente

formula:
Puntos de Función
Esfuerzo Estándar =
Productividad (PF/PM)
El resultado en PM equivale al tiempo necesario en meses de
trabajo para una persona.
Dependiendo del caso se podrá transformar en PA o PD.
CALCULO DE ESFUERZO
Por ejemplo para 289 PF en un proyecto a
desarrollar en JAVA la estimación en meses seria:
Proyecto
[PF/PA] [PF/PM] (PF/PM)
Mundial 92,5 7,70833 37,4919
USA 88,17 7,3475 39,3331
Canada 111 9,25 31,2432
Estimación de
Primer Orden de Jones
ESTIMACIÓN DE PRIMER ORDEN DE JONES
Sí se tiene la suma total de todos los puntos
de función, se puede realizar a partir de ellos un
cálculo aproximado de la planificación (en
meses), utilizando en método que Capers Jones
ha denominado “Estimación de primer orden”.
Para utilizarlo, simplemente hay que tomar el
total de los puntos de función y elevarlo a la
potencia apropiada.
Exponentes para calcular planificaciones a partir de puntos de
función
Clase de Software Mejor caso Media Peor caso
Sistemas: incluye el SO, controladores de

dispositivos, compiladores, bibliotecas de 0,43 0,45 0,48
códigos. (científicos, militares, etc.)
Gestión: software internos utilizados en
0,41 0,43 0,46
empresas.
“Pret-a-porter”: SW empaquetados y vendidos
0,39 0,42 0,45
comercialmente
Incluye todo el tiempo de diseño, construcción y pruebas hasta

finalizar el proyecto.
No incluye el tiempo necesario para la especificación de
requerimientos.
Para el ejemplo de 289 punto de función, el calculo seria:
Sistemas 0.43 0.45 0.48
Gestión 0.41 0.43 0.46
“Pret-a-porter” 0.39 0.42 0.45

Sistemas 11 13 15
Gestión 10 11 14
“Pret-a-porter” 9 11 13
Distribución Genérica
DISTRIBUCIÓN GENÉRICA DEL ESFUERZO
Actividad Porcentaje
Análisis 10%
Diseño 20%
Programación/Codificación 40%
Pruebas 15%
Sobrecarga (Otras tareas) 15%
Para el ejemplo de 289 punto de función, la distribución sería:
Actividad Porcentaje Meses

Análisis 10% 1,5
Diseño 20% 3
Programación/Codificación 40% 6
Pruebas 15% 2,25
Sobrecarga (Otras tareas) 15% 2,25
TOTAL 100% 15
La suma de diseño, programación y pruebas dan 12 meses como
indica la media de Primer Orden de Jones.
Puntos de caso de uso
ESTIMACIÓN PARA PROYECTOS
PUNTOS DE CASO DE USO
Para la estimación de costos
de software con un enfoque
diseñado explícitamente para
SW OO. Lorenz y Kidd sugieren
el enfoque siguiente:
ESTIMACIÓN PARA PROYECTOS PUNTOS DE
CASO DE USO
Los actores se clasifican según Los casos de uso se
la complejidad de su interacción clasifican según su
con el sistema complejidad
PUNTOS DE CASOS DE
Factores Técnicos Factores de
USO SIN AJUSTAR
(UUCP) (TCF) Entorno (EF)
PUNTOS DE CASOS DE USO

AJUSTADOS (UCP)
ESTIMACIÒN DE
ESFUERZO
CASO DE USO
Calculo de Puntos de Caso de uso
1. Calcular los Puntos de Caso de Uso Sin Ajustar
(UUCP – Unadjusted Use Case Points)
2. Determinar el Factor de Complejidad Técnica
(TCF – Technical Factor) para ajuste
3. Determinar el Factor de Entorno para ajuste
(EF – Environmental Factors)
4. Calcular los Puntos de Caso de Uso Ajustados
(UCP – Use Case Points)
CASO DE USO
Clasificación de Actores:
Se debe determinar la forma en la que cada actor interactúa
con el sistema que se va a desarrollar.
Criterios:
 Actor Simple  Otro sistema interactuando a través de una
interfaz de programación definida y conocida (Ej. API)
 ActorPromedio  Otro sistema interactuando a través de
un protocolo (Ej. TCP/IP)
 ActorComplejo  interfaz gráfica de usuario (GUI) o
página Web
ESTIMACIÓN PARA PROYECTOS ORIENTADOS A OBJETOS
Clasificación de Actores:
Se debe asociar un factor de peso de acuerdo a la siguiente
tabla:
Tipo de actor Descripción Factor
Simple Interfaz de programación de aplicaciones 1
Medio Interfaz de comunicación vía protocolo 2
Complejo Interfaz gráfica de usuario 3
Se cuentan los actores según su grado de complejidad,

multiplicando cada subtotal por su factor de complejidad y
sumando cada producto obteniendo el peso de los actores sin
ajustar.
CASO DE USO
Clasificación de Casos de Uso
 Se debe determinar la complejidad de cada caso de
uso según el número de transacciones descritas en su
especificación, incluyendo los cursos de acción
alternativos
Criterios:
 Casos de Uso Simple  3 o menos transacciones
 Casos de Uso Promedio  entre 4 o 7 transacciones
 Casos de Uso Complejos  Más de 7 transacciones
ESTIMACIÓN PARA PROYECTOS PUNTOS DE CASO
DE USO
Clasificación de Casos de Uso
Se debe asociar un factor de peso según la siguiente Tabla:
Tipo caso de uso Descripción Factor

Simple 3 o menos transacciones 5
Medio de 4 a 7 transacciones 10
Complejo más de 7 transacciones 15
Se cuentan las transacciones de los CU según su grado

de complejidad, multiplicando cada subtotal por su factor
de complejidad y sumando cada producto obteniendo el
peso de los CU sin ajustar.
CASO DE USO
Puntos de Caso de Uso Sin Ajustar (UUCP)

Es la suma del peso de los actores sin ajustar
más el peso de las transacciones sin ajustar, es
decir:
UUCP = Peso Actores Sin Ajuste + Peso CU Sin Ajuste

CASO DE USO
Factor de Complejidad Técnica (TCF)
 El método considera las características de complejidad
técnica tomando en cuenta algunos RNF como un factor de
ajuste al sistema.
 Se debe evaluar cada factor multiplicado por un valor que
corresponde a los siguientes grados de influencia:
 0  Sin influencia
 1  Accidental, Influencia no significativa
 2  Moderado, Influencia moderada
 3  Medio, Influencia media
 4  Significativo, Influencia significativa.
 5  Esencial, Influencia esencial
CASO DE USO
Factores de peso que incorporan la complejidad técnica del sistema:
CASO DE USO

Se debe multiplicar cada ítem (T1 a T13) por el
grado de influencia sobre el sistema y se obtiene
la suma llamada FactorT, de acuerdo con
TCF = 0.6 + ( 0.01 × FactorT )

CASO DE USO
Factor de Entorno (EF)
 Corresponde a las características del equipo de desarrollo
en cuanto a perfiles, experiencia y capacidad técnica
 Se debe evaluar cada factor multiplicado por un valor que
corresponde a los siguientes grados de influencia:
 0  Sin influencia
 1  Accidental, Influencia no significativa
 2  Moderado, Influencia moderada
 3  Medio, Influencia media
 4  Significativo, Influencia significativa.
 5  Esencial, Influencia esencial
CASO DE USO
Factor de Entorno (EF)
Se debe multiplicar cada ítem (F1 a F8) por el grado de

influencia sobre el sistema y se obtiene la suma llamada
FactorA de acuerdo con:.
EF = 1.4 + ( -0.03 × FactorA )
CASO DE USO
Puntos de Caso de Uso Ajustados (UCP)

La siguiente fórmula que representa los puntos
de casos de uso ajustados:
UCP = UUCP × TCF × EF

ESTIMACIÓN PARA PROYECTOS - PUNTOS DE CASO DE USO
ESFUERZO
Karner originalmente sugirió que cada Punto de Casos de Uso requiere 20
horas-hombre.
Más interesante son los refinamientos posteriores que proponen una
granularidad algo más fina, según el siguiente criterio:
 Se contabilizan cuántos factores de los que afectan al Factor de ambiente
están por debajo del valor medio (3), para los factores E1 a E6.
 Se contabilizan cuántos factores de los que afectan al Factor de ambiente
están por encima del valor medio (3), para los factores E7 y E8:
 Si el total es 2 o menos, se utiliza el factor de conversión 20 horas-hombre/Punto de
Casos de Uso, es decir, un Punto de Caso de Uso toma 20 horas-hombre.
 Si el total es 3 o 4, se utiliza el factor de conversión 28 horas-hombre/Punto de Casos
de Uso, es decir, un Punto de Caso de Uso toma 28 horas-hombre.
 Si el total es mayor o igual que 5, se utiliza el factor de conversión 36 horas-
hombre/Punto de Casos de Uso, pero se recomienda efectuar cambios en el
proyecto, ya que se considera que el riesgo de fracaso del mismo es demasiado alto.
CASO DE USO
Consideraciones finales
Para llevar a cabo estimaciones es muy útil disponer
de datos históricos de estimaciones realizadas por la
propia organización anteriormente, donde esté
registrado el tamaño, coste y duración de los mismos
La estimación obtenida mediante este método sólo
aplica al esfuerzo requerido para la FASE DE
CODIFICACIÓN del proyecto. Es necesario aplicar otros
ajustes con el fin de obtener el esfuerzo de todo el ciclo
de vida del proyecto
Distribución Genérica
Actividad Porcentaje
Análisis 10%
Diseño 20%
Programación/Codificación 40%
Pruebas 15%
Sobrecarga (Otras tareas) 15%
Otras técnicas de estimación
OTRAS TÉCNICAS DE ESTIMACIÓN
DESARROLLO ÁGIL
 Estimación para desarrollo ágil: la estimación para los

proyectos ágiles aplica un enfoque de descomposición que
abarca los siguientes pasos:
 Cada escenario de usuario se considera por separado
respecto de propósitos de estimación
 El escenario se descompone en conjunto de funciones y
las tareas de ingeniería de SW que se requerirán para
desarrollarlo
DESARROLLO ÁGIL
 Cada tarea se estima por separado. La estimación se puede
basar en datos históricos, en un modelo empírico o en la
“experiencia”
 Alternativa, el “volumen” (tamaño) del escenario se puede
estimar en LDC, PF o alguna otra medida orientada al tamaño.
 Las estimaciones de cada tarea se suman para crear una
estimación para el escenario.
 Alternativamente, el volumen estimado para el escenario se
traduce en esfuerzo mediante la aplicación de datos históricos.
 Estimaciones de esfuerzo acerca de todos los escenarios que se
implementarán para un incremento de SW dado se suman con el
fin de desarrollar el esfuerzo estimado para el incremento
PROYECTOS DE ING. WEB
Estimación para proyectos de ingeniería Web: los

proyectos de ingeniería Web adoptan el modelo de
proceso ágil. Es factible emplear una medición de
punto de función modificada, con el fin de desarrollar
una estimación para la WebApp.
Roetzheim, sugiere los siguientes valores de dominio
de información cuando se adaptan puntos de función
para la estimación WebApp:
PROYECTOS DE ING. WEB
 Entradas: son cada pantalla o formato de entrada, cada

pantalla de mantenimiento.
 Salidas: son cada pagina Web estática, cada guión de
pagina Web dinámica (ej. ASP u otro DHTML)y cada
reporte (sea basado en Web o sea del todo administrativo)
 Tablas son cada tabla lógica en base de datos más, si
emplea XML para almacenar datos en un archivo, cada
objeto XML.
 Interfases, retienen su definición como archivos lógicos en
las fronteras exteriores del sistema.
 Consultas son cada interfase publicada externamente o
utiliza una interfaz orientada al mensaje.
Modelo de
Estimación
De Costos
ESTIMACIÓN DEL ESFUERZO
COCOMO II
COCOMO II es un modelo de estimación de costo utilizable en la
evaluación del esfuerzo estimado para un proyecto. Los principales
objetivos del COCOMO II son:
 Desarrollar un modelo de estimación de costo y tiempo acorde al
estilo de vida de los 1990’s y 2000’s.
 Desarrollar una base de datos de costo y capacidades de soporte
de herramientas de modo a mejorar el modelo continuamente.
 Proveer un marco de trabajo analítico y cuantitativo, y un conjunto
de herramientas y técnicas para evaluar los efectos de las mejoras en
la tecnología de software sobre el costo y el tiempo en el ciclo de vida
del software.
COCOMO II
El modelo COCOMO II completo incluye tres etapas.
La etapa 1 soporta la estimación de los esfuerzos de
prototipado o desarrollo de aplicaciones.
La etapa 2 soporta la estimación a comienzos de la etapa
de diseño de un proyecto, cuando se conoce poco acerca del
costo del proyecto.
La etapa 3 soporta la estimación en la etapa post
arquitectural del proyecto. La versión actual de COCOMO II
implementa fórmulas de la etapa 3 para estimar el esfuerzo,
tiempo, y costo requerido para desarrollar un producto software
COCOMO II
Entradas de COCOMO II
La entrada principal de COCOMO.II es el tamaño del programa, en KDSI
(Kilo Instrucciones fuentes entregadas), puntos de función o puntos de objeto.
Se deben evaluar 16 atributos adicionales, estos atributos están incluidos en 4
categorías como sigue:
 Atributos del Producto: Estos atributos describen el ambiente en el cual
opera el programa. Los atributos en esta categoría son: requerimientos de
confiabilidad, tamaño de base de datos, concordancia entre la
documentación y las necesidades del ciclo de vida, reutilización requerida y
complejidad del programa.
 Atributos de la Plataforma: Estos atributos se refieren a las limitaciones
que afectan el esfuerzo del desarrollo debido al hardware y al sistema
operativo que se están utilizando en la ejecución del proyecto. Los atributos
en esta categoría son restricciones de tiempo de ejecución, almacenamiento
principal, y volatilidad de la plataforma.
COCOMO II
 Atributos del Personal: Estos atributos describen la habilidad del
personal asignado al proyecto. Los atributos en esta categoría
incluyen: capacidad del analista, experiencia en aplicaciones,
capacidad del programador, experiencia en el lenguaje de
programación, experiencia en la plataforma, continuidad del personal.
 Atributos del Proyecto: Estos atributos se refieren a las restricciones
y condiciones bajo las cuales opera el desarrollo del proyecto. Los
atributos en esta categoría son el uso de herramientas de desarrollo
de software y desarrollo multi-sitio.
Estos factores (o multiplicadores de esfuerzo) se multiplican y de
esta forma están incorporados en las fórmulas de estimación del tiempo
y esfuerzo. El valor numérico del i-ésimo factor de ajuste es llamado EMi
y su producto es llamado factor de ajuste o EAF. El esfuerzo total
PMtotal es el producto del esfuerzo nominal y el EAF.
COCOMO II
Procesamiento COCOMO II
Utilizando COCOMO II, una evaluación nominal de
los meses-hombre basada sólo en el tamaño se
realiza al programa considerado. A continuación, se
multiplica la evaluación de todos los atributos para
obtener el esfuerzo en meses-hombre requerido por el
proyecto. Los desafíos principales al utilizar COCOMO
II son determinar el tamaño del proyecto y asignar los
valores apropiados a los atributos.
COCOMO II
Salidas de COCOMO II
La salida del modelo COCOMO II es simplemente el nivel de esfuerzo
en meses-hombre para el proyecto estimado y el tiempo en meses.
El esfuerzo puede fácilmente ser convertido a valor monetario si el costo
por mes-hombre es conocido.
La Distribución de Fases es una de las salidas. Su función es la de
mostrar un desglose del esfuerzo del software y el tiempo requerido a las
fases del ciclo de desarrollo.
Estas fases son análisis de requerimientos, diseño, implementación e
integración y prueba. Las salidas del modelo son muy básicas y no muy
flexibles, por lo tanto las métricas de rendimiento deberán ser creadas
fuera de este modelo.
COCOMO II
Calibración COCOMO II
La calibración es esencial para el uso
correcto de modelos de costo de
software. El usuario de COCOMO II
puede calibrar los EAF y las ecuaciones
de esfuerzo/tiempo del proyecto actual.
COCOMO II
Aplicabilidad de la métrica
El método de estimación COCOMO II está basado dos modelos: uno
aplicable al comienzo de los proyectos (Diseño preliminar, en inglés Early
Design) y otro aplicable luego del establecimiento de la arquitectura del
sistema (Post arquitectura, en inglés Post Architecture).
 El modelo de Diseño preliminar (Early Design) contempla la exploración
de las arquitecturas alternativas del sistema y los conceptos de operación.
En esta etapa no se sabe lo suficiente del proyecto como para hacer una
estimación fina. Ante ésta situación, el modelo propone la utilización de
Puntos de Función como medida de tamaño y un conjunto de 7 factores
(cost drivers) que afectan al esfuerzo del proyecto. Estos 7 factores son
agrupaciones de los factores que se utilizan en la otra variante del modelo
(Post Arquitectura).
COCOMO II
El modelo Post arquitectura (Post Architecture) contempla
el desarrollo y el mantenimiento de un producto software.
Esta estrategia es más precisa si se ha desarrollado una
arquitectura del sistema, la cual haya sido validada y
establecida como base para la evolución del producto. Ante
ésta situación, el modelo propone la utilización de Líneas de
código fuente y/o Puntos de Función como medidores del
tamaño, modificadores para indicar el grado de reutilización y
descarte del software, un conjunto de 17 estimadores de
costo, y un conjunto de 5 factores que afectan de manera
exponencial en el esfuerzo del proyecto.
COCOMO II
Detalles de la métrica
Tanto en el modelo de diseño preliminar como en el post arquitectural,
la estimación del esfuerzo se realiza tomando como base la siguiente
ecuación:
PM nominal = A x (Size) B
donde:
PM nominal: es el esfuerzo nominal requerido en meses- hombre
Size: es el tamaño estimado del software, en miles de líneas de
código (KSLOC) o en Puntos de Función sin ajustar (convertibles a
KSLOC mediante un factor de conversión que depende del lenguaje y
la tecnología).
COCOMO II
A: es una constante que se utiliza para capturar los
efectos multiplicativos en el esfuerzo requerido de
acuerdo al crecimiento del tamaño del software. El
modelo la calibra inicialmente con un valor de 2.94.
B: es una constante denominada Factor escalar, la

cual tiene un impacto exponencial en el esfuerzo y su
valor está dado por la resultante de los aspectos
positivos sobre los negativos que presenta el proyecto.
COCOMO II - FACTOR ESCALAR B
El factor escalar B se calcula a partir de la sumatoria de los aportes de distintas
Variables escalares, las cuales son variables que indican las características que el
proyecto presenta en lo que a su complejidad y entorno de desarrollo se refiere.
Las Variables escalares de COCOMO II son las siguientes:
 PREC, este factor de precedencia toma en cuenta el grado de experiencia previa en
relación al producto a desarrollar, tanto en aspectos organizacionales como en el
conocimiento del software y hardware a utilizar.
 FLEX, el factor de flexibilidad considera el nivel de exigencia en el cumplimiento de
los requerimientos preestablecidos, plazos de tiempos y especificaciones de
interfase.
 RSEL, indica la fortaleza de la arquitectura y métodos de estimación y reducción de
riesgos
 TEAM, esta variable refleja la cohesión y madurez del equipo de trabajo
 PMAT, relaciona el proceso de madurez del software
Estimación del esfuerzo - COCOMO II
Cada una de estas variables se cuantifica con un valor desde Muy Bajo hasta Extra
Alto. La siguiente tabla muestra los criterios, valores y niveles de cuantificación para
cada una de éstas variables:
Factor escalar
Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
(Wi)
6,2 4,96 3,72 2,48 1,24 0
PREC Absolutament
Completa Completa Algo Familiar Muy Familiar
e familiar
5,07 4,05 3,04 2,03 1,01 0
FLEX Algo de Generalmente Algo de Objetivos
Riguroso Ocasional
relajación conforme conformidad Generales
7,07 5,65 4,24 2,83 1,41 0
RESL A menudo Generalmente Mayormente Totalmente
Poco (20%) Algo (40%)
(60%) (75%) (90%) (100%)
5,48 4,38 3,29 2,19 1,1 0
Basicamente
Algo de
TEAM Interacción hay Altamente Interacción
dificultad de Cooperativa
muy dificil interacción Cooperativa total
interacción
cooperativa
7,8 6,24 4,68 3,12 1,56 0
Promedio de Promedio de Promedio de Promedio de Promedio de Promedio de
respuestas respuestas respuestas respuestas respuestas respuestas
PMAT
afirmativas en afirmativas en afirmativas en afirmativas en afirmativas en afirmativas en
el cuestionario el cuestionario el cuestionario el cuestionario el cuestionario el cuestionario
de CMMI de CMMI de CMMI de CMMI de CMMI de CMMI
COCOMO II
NIVEL DE CMMI PMAT
1 – Mitad Inferior Muy bajo
PMAT, Captura del nivel 1 – Mitad superior Bajo

de madurez de la
organización, resultado 2 Nominal
de la evaluación de
CMMI y asignándole un 3 Alto
valor correspondiente.
4 Muy Alto
5 Extra Alto
COCOMO II
Luego de la ponderación de éstas
variables, el Factor escalar se
calcula mediante la siguiente
ecuación:
B = 0.91 + 0.01 x Σ(Wi)

COCOMO II
 Si B < 1.0, el proyecto exhibe economía de escala. Es decir si un
producto aumenta el doble su tamaño el esfuerzo del proyecto es menos
del doble. Esto significa que la productividad del proceso de desarrollo de
software incrementa a medida que aumenta el tamaño del proyecto.
 Si el B = 1.0 las economías y deseconomías de escala están en
equilibrio. Este modelo lineal se usa siempre en la estimación de costos de
proyectos pequeños.
 Si el B > 1.0 el proyecto muestra deseconomía de escala. . La
productividad del proceso de desarrollo de software disminuye a medida
que aumenta el tamaño del proyecto.
Esto generalmente se debe a dos factores principales: el crecimiento de
las comunicaciones interpersonales y el de la integración de sistemas.
Integrar un producto pequeño como parte de otro requiere no sólo el
esfuerzo de desarrollar el producto sino también el esfuerzo de diseñar,
mantener, integrar y testear interfases con el resto del software.
COCOMO II
Ajuste del esfuerzo nominal
El esfuerzo calculado en la ecuación (1) es un valor
nominal y debe ser ajustado en base a las características
del proyecto. COCOMO II obtiene los datos necesarios
para el ajuste del esfuerzo nominal considerando los
Multiplicadores de Esfuerzo (EM), los cuales
representan las características del proyecto y expresan
su impacto en el desarrollo total del producto de
software.
COCOMO II
Ajuste del esfuerzo nominal
Los Multiplicadores de esfuerzo se cuantifican con una
escala que va desde Extra Bajo a Extra Alto, y cada multiplicador
tiene un valor asociado a cada nivel de la escala. Cada uno de los
modelos de estimación (Diseño preliminar y Post arquitectura)
tiene un conjunto de Multiplicadores de esfuerzo, los cuales son
acordes con la información que se maneja en cada uno de estos
modelos.
En ambos modelos, el esfuerzo ajustado se calcula
mediante la siguiente ecuación:
PM ajustado = PM nominal x Π(EMi)
COCOMO II
Multiplicadores de esfuerzo en el modelo Post arquitectura
 Para este modelo, los multiplicadores son 17, agrupados en las
siguientes categorías: producto, plataforma, personal y proyecto. A
continuación se muestran los multiplicadores, con una breve
descripción de su significado.
 Multiplicadores que afectan al producto:
RELY: Confiabilidad requerida del software. Mide el impacto que
tiene una falla en el software.
Muy bajo Bajo Nominal Alto Muy Alto
RELY Inconvenientes Bajo, y con Moderado, Altas Riesgo para
imperceptibles pérdidas con pérdidas pérdidas la Vida
fácilmente de fácil Financieras humana.
recuperables recuperación.
COCOMO II
Multiplicadores que afectan al producto:
DATA: Tamaño de la base de datos. Se mide como el
tamaño de la base en bytes sobre el tamaño del programa en
LOC. Se utiliza para dimensionar el esfuerzo requerido para
el control y la generación de datos de prueba.
Muy Bajo Nominal Alto Muy Alto
bajo
DATA D/P<10 10<=D/P<100 100<=D/P<1000 D/P>=1000
COCOMO II
CPLX: Complejidad del producto. La
complejidad se divide en cinco áreas:
Operaciones de Control, operaciones de
Cálculo, Dependencia de Dispositivos, Manejo
de Datos e Interfaces de Usuario.
ESTIMACIÓN DEL ESFUERZO – COCOMO II
COCOMO II
RUSE: Reusabilidad del código. Mide el costo
adicional requerido para diseñar componentes más
genéricos, mejor documentados y más confiables, de
manera de reutilizarlos en otros proyectos.
Muy
Bajo Nominal Alto Muy Alto Extra Alto
bajo
RUSE Por
Por Por Por línea de múltiples
Nada.
proyecto. programa producto. líneas de
producto.
COCOMO II

DOCU: Documentación. Evalúa los requerimientos
de documentación a lo largo del ciclo de vida del
proyecto.
DOCU Muchas etapas Algunas De acuerdo a Excesiva. Muy
del ciclo de vida las necesidades excesiva
están sin exactas de las .
documentación. etapas del ciclo
de vida.
COCOMO II
Multiplicadores que afectan a la plataforma:
TIME: Restricciones de tiempo de ejecución. Se expresa en
términos de porcentaje de disponibilidad de tiempo de ejecución
que será usado por el sistema, versus los recursos disponibles.
Muy bajo Bajo Nominal Alto Muy Alto Extra Alto

TIME <= 50% de uso 70 %. 85 %. 95 %.
de los recursos
disponibles
COCOMO II

STOR: Restricciones de almacenamiento
principal. Similar al multiplicador anterior, pero
relacionadas con el espacio principal de
almacenamiento.
STOR <= 50% de uso 70 % 85 % 95 %
de los recursos
disponibles
COCOMO II
PVOL: Volatilidad de la plataforma. Expresa la velocidad de
cambio del hardware y el software usados como plataforma.
Muy Bajo Nominal Alto Muy Alto Extra
bajo Alto
PVOL Grandes Grandes Grandes Grandes
Cambios Cambios Cambios Cambios
c/12 c/6 meses c/2 c/ 2
meses meses semanas
Cambios
Cambios menores Cambios Cambios
menores c/ 2 menores menores
c/ 1 mes semanas c/ 1 c/ 2 días
semana
COCOMO II
Multiplicadores que afectan al personal:

ACAP: Capacidad de los analistas. Se considera la
capacidad de análisis y diseño, eficiencia, habilidad para
comunicarse y trabajar en equipo. No se considera el nivel de
experiencia.
ACAP 15 % 35 % 55 % 75 % 90 %
COCOMO II

PCAP: Capacidad de los programadores. Se considera la
capacidad de trabajo en equipo, eficiencia y habilidad para
comunicarse. No se considera el nivel de experiencia.
PCAP 15 % 35 % 55 % 75 % 90 %
COCOMO II

AEXP: Experiencia en aplicaciones. Contempla el nivel de
experiencia del grupo de desarrollo (principalmente analistas) en
aplicaciones equivalentes.
AEXP 2 meses 6 meses 1 año 3 años 6 años

ESTIMACIÓN DEL ESFUERZO - COCOMO II

PEXP: Experiencia en la plataforma. Refleja la experiencia del
grupo de desarrollo (principalmente programadores) en el uso de
herramientas de software y hardware utilizado como plataforma.
PEXP 2 meses. 6 meses 1 año. 3 años 6 años

COCOMO II
LTEX: Experiencia en el lenguaje y herramientas de
desarrollo. Refleja la experiencia del grupo de desarrollo en
el lenguaje de programación y las herramientas de
desarrollo utilizadas.
LTEX 2 meses 6 meses 1 año 3 años 6 años.

COCOMO II
PCON: Continuidad del personal. Expresa el
porcentaje de rotación anual del personal afectado al
proyecto.
PCON 48% al año 24% al año 12% al año 6% al año 3% al año
COCOMO II
Multiplicadores que afectan al proyecto:
TOOL: Uso de herramientas de software. Contempla el uso de
herramientas, desde la edición hasta el manejo de todo el ciclo de
vida.
TOOL Edición y CASE simple y Herramientas Potentes Herramientas
codificación de poca básicas para herramientas potentes y
con debug integración todo el ciclo de a ser usadas preactivas, muy
vida con en todo el bien integradas
moderada ciclo de vida con el proceso,
integración con los métodos y la
integración reusabilidad
moderada
COCOMO II
SITE: Desarrollo en múltiples ubicaciones. Involucra la ubicación
física y el soporte de comunicaciones.

Comunicaciones
electrónicas que
Red de Comunicaciones
Algo de Fax y cubren todas las
correo electrónicas que
teléfono y teléfonos ubicaciones con la Multimedia
electrónico cubren todas las
mail individuales posibilidad de
interno ubicaciones
videoconferencias
ocasionales.
COCOMO II
SCED: Requerimientos de calendario de desarrollo. Refleja
las restricciones impuestas al grupo de desarrollo sobre la
agenda nominal estimada del proyecto.

SCED 75% del 85 % 100 % 130 % 160 %
nominal.
Valores a utilizar para los multiplicadores de esfuerzo en el modelo post-arquitectura
POST- EXTRA
EXTRA BAJO MUY BAJO BAJO NOMINAL ALTO MUY ALTO
ARQUITECTURA ALTO
RELY --- 0,82 0,92 1 1,1 1,26 ---
DATA --- --- 0,9 1 1,14 1,28 ---
PRODUCTO CPLX --- 0,73 0,87 1 1,17 1,34 1,74
DOCU --- --- 0,95 1 1,07 1,15 1,24
RUSE --- 0,81 0,91 1 1,11 1,23 ---
TIME --- --- --- 1 1,11 1,29 1,63
PLATAFORAMA STOR --- --- --- 1 1,05 1,17 1,46
PVOL --- --- 0,87 1 1,15 1,3 ---
ACAP --- 1,42 1,19 1 0,85 0,71 ---
PERSONAL PCAP --- 1,34 1,15 1 0,88 0,76 ---
PCON --- 1,29 1,12 1 0,9 0,81 ---
AEXP --- 1,22 1,1 1 0,88 0,81 ---
PEXP --- 1,19 1,09 1 0,91 0,85 ---
LTEX --- 1,2 1,09 1 0,91 0,84 ---
PROYECTO
TOOL --- 1,17 1,09 1 0,9 0,78 ---
SITE --- 1,22 1,09 1 0,93 0,86 0,8
SCED --- 1,43 1,14 1 1 1 ---
Multiplicadores de esfuerzo en el modelo de Diseño preliminar:
Para este modelo, los multiplicadores son 7, y se obtienen como combinaciones de
los multiplicadores del modelo Post arquitectura. Estos multiplicadores son:
PERS: Capacidad del personal. Está dado por la suma o la combinación porcentual
de los multiplicadores ACAP, PCAP y PCON.
Extra Muy Bajo Nominal Alto Muy Alto Extra
Bajo Bajo Alto
Suma de
ACAP, PCAP, 3,4 5,6 7,8 9 10,11 12,13 14,15
PCON
Combinación
de ACAP y 20% 39% 45% 55% 65% 75% 85%
PCAP
Rotación
anual del 45% 30% 20% 12% 9% 5% 4%
personal
RCPX: Complejidad del producto. Está dado por la combinación de
los multiplicadores RELY, DATA, CPLX y DOCU.
Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Suma de RELY, 5,6 7,8 9-11 12 13-15 16-18 19-21

DATA, CPLX y
DOCU
Énfasis en la Muy poca Poca Algo Básica Fuerte Muy fuerte Extrema
documentación
Complejidad del Muy Simple Algo Moderada Compleja Muy Extremada
producto simple compleja mente
compleja
Tamaño de la Pequeña Pequeña Pequeña Moderada Grande Muy Muy
base de datos Grande Grande
RUSE: Reusabilidad. Está dado por el mismo multiplicador RUSE del
modelo Post arquitectura.
PDIF: Dificultad de la plataforma. Está dado por la combinación de
los multiplicadores TIME, STOR y PVOL.
PREX: Experiencia del personal. Está dado por la combinación de
los multiplicadores AEXP, PEXP y LTEX.
SCED: Calendario. Está dado por el mismo multiplicador SCED del
modelo Post arquitectura.
FCIL: Facilidades. Está dado por la combinación de los
multiplicadores TOOL y SITE.
DISEÑO EXTRA MUY NOMINA MUY EXTRA
BAJO ALTO
PRELIMINAR BAJO BAJO L ALTO ALTO
RCPX 0,73 0,81 0,98 1 1,3 1,74 2,38
RUSE --- --- 0,95 1 1,07 1,15 1,24
PDIF --- --- 0,87 1 1,29 1,81 2,61
PERS 2,12 1,62 1,26 1 0,83 0,63 0,5
PREX 1,59 1,33 1,12 1 0,87 0,71 0,62
FCIL 1,43 1,3 1,1 1 0,87 0,73 0,62
SCED --- 1,43 1,14 1 1 1 ---

Ecuación de tiempo (schedule equation)

Predice el número de meses requeridos para
completar el proyecto. La duración del proyecto
está basada en el esfuerzo calculado por la
ecuación del esfuerzo:
Duración = 3.67 * (PM ajustado) [ 0.28 + 0.2 * (B-0.91) ]

Ejemplo de Aplicación del modelo
Aplicación sobre los Puntos de Función sin ajustar
Éste método es el preferido en la actualidad para la estimación del esfuerzo
cuando no se tiene información histórica a la cual recurrir.
Consiste básicamente en la aplicación de ecuaciones matemáticas sobre los
Puntos de Función sin ajustar o la cantidad de líneas de código (SLOC, Source
Lines Of Code) estimados para un proyecto.
A manera de ejemplo, consideremos los puntos de función sin ajustar del
proyecto anterior evaluado, que tiene el siguiente valor para los puntos de
función sin ajustar: UFP = 129
Para aplicar la ecuación de cálculo del esfuerzo nominal, necesitamos convertir
los puntos de función sin ajustar a KSLOC (Source Lines Of Code, en miles), y
por otro calcular el Factor escalar B de acuerdo a las características del
proyecto. Luego:
PM nominal = A x (Size) B
donde
A: tomamos el valor por defecto del modelo, ajustado en 2.94
Size: se calcula como el producto de los puntos de función sin
ajustar por un factor de conversión que depende del lenguaje a
utilizar en el desarrollo del sistema. Supongamos que utilizamos
Java (factor de conversión = 53 SLOC/UFP).
Entonces tendremos:
Size = 53 x 129 = 6.837 SLOC
B: se calcula ponderando las variables escalares mediante la
ecuación:
B = 0.91 + 0.01 x Σ(Wi)

donde se considerarán los valores de las Wi mostradas en la
siguiente tabla:
Variable Descripción Ponderación Valor

PREC El sistema es muy familiar muy alto 1,24
Algo de relajación en cuanto a la flexibilidad
FLEX del desarrollo nominal 3,04
La arquitectura es solida y los riesgos se
RESL mitigan alto 2,83
La interacción del equipo es altamente
TEAM cooperativa muy alto 1,1
PMAT La madurez del proceso de SW es baja bajo 6,24
suma (Σ(Wi)) 14,45
B = 0.91 + 0.01 x Σ(Wi) 1,0545
Finalmente, el esfuerzo nominal resulta:
PM nominal = A x (Size) B =
PM nominal = 2.94 x (6.835)1.05 = 22,32 Meses-hombre
Para completar la estimación, hay que ajustar el esfuerzo nominal de

acuerdo a las características del proyecto. El ajuste se efectúa
aplicando la ecuación:
PM ajustado = PM nominal x Π (MEi)
donde los MEi (multiplicadores de esfuerzo) varían en función del

modelo de estimación seleccionado (Diseño Preliminar o Post
arquitectura).
En nuestro caso vamos a aplicar el modelo de Diseño preliminar. Entonces,
cuantificamos los multiplicadores de esfuerzo para éste modelo:
Multiplicador Descripción Ponderación Valor
Las exigencias de confiabilidad, documentos y
RCPX voluntamen de datos son moderadas, y la complejidad Nominal 1
del producto baja
RUSE No se pretende reutilizar nada Bajo 0,95
No existen restricciones en cuanto al tiempo de CPU o al
PDIF Bajo 0,87
consumo de memoria, la plataforma es muy estable
Se tienen analistas y programadores con alta eficiencia y
PERS Alto 0,83
capacidad de trabajo en equipo. Dedicado full-time
Tanto los analistas como los programadores tienen
aproximadamente 6 meses de experiencia en la
PREX Muy Bajo 1,33
aplicación, la plataforma, el lenguaje y las herramientas
utilizadas
Se tienen herramientas CASE simples e infraestructura
FCIL Bajo 1,1
de comunicaciones básica
SCED Se requiere terminar el proyecto en el tiempo estimado Nominal 1
TOTAL ( PERS*RCPX*RUSE*PDIF*PREX*SCED*FCIL) 1,004
Con estos valores, el ajuste del esfuerzo resulta:

PM ajustado = 22,32 x 1.004 =
PM ajustado = 22,40928 Meses-hombre
Expresando el mismo valor en Horas-hombre, y teniendo
en cuenta que un mes es aproximadamente 160 horas
(20 días * 8 hs), el esfuerzo resulta:
PH ajustado = 22,40928 x 160 = 3.585,4848 Horas-hombre
Ecuación de tiempo (schedule equation)
Predice el número de meses requeridos para completar el
proyecto:
Duración = 3.67 * (PM ajustado) [ 0.28 + 0.2 * (B-0.91) ]
Para el ejemplo anterior tenemos:
Duración = 3.67 * (22,40928) [ 0.28 + 0.2 * (1.05-0.91) ]

Duración = 9,59 ≈ 10 meses
COCOMO II
Extensiones:
COCOTS (Constructive COTS)
CORADMO (Constructive Rapid Application Development Model)
COQUALMO (Constructive Quality Model)
COSEMO (Constructive Staged Schedule an Effort Model)
COPROMO (Constructive Productivity improvement Model)
BIBLIOGRAFÍA
 Guerra G., Lautaro, Bedini G., Alejandro. 2005. Gestión de Proyectos de
Software. 2da. Ed. Universidad Técnica de Santa Maria – Chile.
 Jones, Carpers. 2007. Estimación de costos y Administración de proyectos de
Software. 1ª (ed.). Mc Graw Hill
 Lledó, Pablo. 2012. Gestión Ágil de Proyectos: Lean Project Managment. 1ª
(ed.). Trafford. EEUU.
 Pressman, Roger S. PhD. (2010)Ingeniera de software. Un enfoque practico.
(7ma. Ed.). México. The McGraw-Hill
 Project Management Institute, Inc. (2008). Guía de los fundamentos para la
Dirección de Proyectos (Guía del PMBOK). (4ta.Ed.). EEUU. Global
STANDARD
 Sánchez, Salvador, Sicilia, Miguel Ángel y Rodríguez, Daniel. 2012. Ingeniería
del Software. Un enfoque desde la guía SWEBOK. 1ª (ed.). Alfaomega Grupo
Editor, S.A.
 Sommerville, Ian. 2011. Ingeniería de software. 9ª (ed.).Pearson

ISIII UNID3 Estimación Costo

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ISIII UNID3 Estimación Costo

Cargado por

Copyright:

Formatos disponibles

Mediciones y Técnicas de Estimación

Una métrica es, una asignación

La medición permite ganar

Métricas de proceso Métricas de producto

Las métricas de proceso se recopilan a

Las métricas de software orientadas

Productividad = KLOC / PM.

Las métricas de software orientadas a la

La relación entre líneas de código

Las métricas de proyecto de software

Lorenz y Kidd [Lor94] sugieren el siguiente

Los investigadores sugieren puntos de

El objetivo de todos los proyectos webapp es

De las estadísticas que generan los

La estimación de costos, tiempo y

En todo proyecto existe un presupuesto

Dentro de la mayor parte de las

 Costos de la supervisión del desarrollo

como el conjunto de Tamaño del

Si los clientes desean la planificación más

Si la estimación es demasiado baja, la

PF = PFSA x Factor de Ajuste

RR.HH. Fronteras definidas

FRONTERA DE LA APLICACIÓN (2)

Entradas EI (External Input) :

B Los datos elementales son diferentes de otras entradas

Salidas EO (External Output)

El proceso envía datos o información al exterior de la aplicación Sí

Para el proceso subyacente se debe de cumplir

Clasificación de las salidas:

Consultas EQ (External Query) :

Ficheros Lógicos Internos:

Se trata de una agrupación de datos lógica o identificable desde el

La agrupación de datos es mantenida por procesos de la aplicación

La agrupación de datos es mantenida mediante un proceso elemental

La agrupación de datos no ha sido contada como un fichero de

Clasificación de los Ficheros Lógicos Internos:

Número de entradas 6 X 3=18 2 X 4=8 3 X 6=18 44

Número de salidas 6 X 4=28 7 X 5=35 0 X 7=0 63

Consultas 0 X 3=0 2 X 4=8 4 X 6=24 32

1 Requiere comunicación de datos? 5

Que tan efectivos y/o automatizados son los procedimientos de

Se ha diseñado el sistema para soportar múltiples instalaciones en

Para el ejemplo de 289 PF en un proyecto a

El esfuerzo de desarrollo de un proyecto significa

Para los cálculos tendremos en cuenta las

Por tanto utilizaremos las siguientes conversiones:

1 [PA] persona - año = 12 [PM] persona - mes

Para calcular el esfuerzo se tomaran

Esfuerzo Medido: representa el tiempo real de

Esfuerzo Estándar: Productividad por Puntos

Por tanto el esfuerzo se calculará mediante la siguiente

Sistemas: incluye el SO, controladores de

Incluye todo el tiempo de diseño, construcción y pruebas hasta

Clase de Software Mejor caso Media Peor caso

Actividad Porcentaje Meses

PUNTOS DE CASOS DE USO

Medio Interfaz de comunicación vía protocolo 2

Complejo Interfaz gráfica de usuario 3

Se cuentan los actores según su grado de complejidad,

Tipo caso de uso Descripción Factor

Se cuentan las transacciones de los CU según su grado