Estimating Software Project Size and Effort Using Lines of Code (LOC

Ph.D. Franklin Parrales 1
23/10/2021
Proceso de Software Carrera de Software
ESTIMACIÓN DE
PROYECTOS DE SOFTWARE
Unidad 4
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Proceso de Software

23/10/2021
Objetivo general de la Unidad 4
Analizar los aspectos principales para la estimación de
proyectos de software alineados a metodologías usadas en
la industria para desarrollar proyectos de software
escalables.

23/10/2021
Bibliografía consultada
• Pressman, Roger S.
"Ingeniería del
software." Un
enfoque (7maEd.
2011). Cap. 26
• Guerra, L., Bedini, A.
“Gestión de
Proyectos de
Software”. Editorial
UTFSM, ISBN 956-
7051-06-2, Chile,
abril 2005. Cap. 5

23/10/2021
Contenido
• Recursos.
• Técnicas de Descomposición.
• Estimación de Líneas de Código (LDC) y Puntos de
Función (PF).
• Líneas de Código (LDC) v/s Puntos de Función (PF).
• Modelos para las Estimaciones
• Modelo COCOMO Intermedio.
• Modelo Algorítmico de Costos de Software.
• Modelo de Estimación para Proyectos Cliente/Servido
• Modelo de estimación para aplicaciones
Intranet/Internet
• Otros modelos

23/10/2021
Recursos del proyecto
project
people
skills
number
location
reusable
software
OTS
components
full-experience
components
new
components
part.-experience
components
environment
hardware
software
tools
network
resources

23/10/2021
Proceso de Estimación propuesto.
Medir lo que
quiere el
usuario
Estimar lo
que Costara
(esfuerzo)
Descomponer
por fases y
tareas
Historial
Empresa
Especificación de
requerimientos
Requisitos a
Cumplir
Medida de lo que
quiere el usuario
Estimación
del Esfuerzo
Tareas a
realizar

23/10/2021
Estimación del proyecto
• Debe entenderse el
alcance del proyecto
• Es necesaria la
descomposición de tareas
• Las métricas históricas son
muy útiles
• Deben utilizarse al menos
dos técnicas diferentes
• La incertidumbre es
inherente al proceso

23/10/2021
Método basado exclusivamente en los
recursos: Parkinson
• En la estimación consiste en ver de cuanto
personal y durante cuanto tiempo se dispone de
el, haciendo esa estimación.
• En la realización:
“El trabajo se expande hasta
consumir todos los recursos
disponibles”
(Ley de Parkinson)

23/10/2021
Contenido
• Recursos.
Función (PF).
• Modelo de Estimación para Proyectos Cliente/Servido
Intranet/Internet
• Otros modelos

23/10/2021
Descomposición funcional
descomposición
funcional
Declaración
de
Alcance
Realizar un
"análisis" gramatical

23/10/2021
Objetivo
• Descomponer el esfuerzo estimado en
tareas.
• Para esto identificaremos:
– Entregables del proyecto,
– Fases del proyecto y
– Tareas del proyecto.

23/10/2021
Descomposición en actividades del
proyecto (WBS)
• Work
Breakdown
Structure
(WBS)
– Método de
representar de
forma
jerárquica los
componentes
de un proceso
o producto.

23/10/2021
proyecto (WBS)

23/10/2021
proyecto (WBS)
1.1. Estudiar
Sistema Actual
1.2. ide. nuevas
carácteristica
1.0. Especificar
necesidades
2.1. Estudiar
Procesos
2.2. Estudiar
Datos
2.0. Analizar
Contabilidad
3.1. Diseño
B.D
3.2. Diseño
Programas
3.0. Diseñar
Aplicación
4.1. Creación
Esquema
4.2. Codificación
Programas
4.0. Codificación
5.1. Prueba
Unidades
5.2. Prueba del
Sistema
5.0. Pruebas
0.0. Proyecto
Contabilidad

23/10/2021
Basados en la descomposición del
proyecto
• En la estimación consiste en ver de cuanto personal y
durante cuanto tiempo se dispone de el, haciendo esa
estimación.
• El método es tener todo la detalle usando: Bottom-up
o TopDown
– En esta técnica por cada componentes hay que estimar un
costo de su desarrollo.
– La estimación total del proyecto es la suma de sus
parciales.
– Para poder aplicar esta técnica se debe aplicar un método
WBS
• Actividades directas al proyecto (40%).
• Actividades indirectas al proyecto (30%).
• Actividades de desperdicio del proyecto (30%)

23/10/2021
Basados en la descomposición del
proyecto
• La técnica es:
– Dividir el proyecto en fases
– Dividir fases en tareas
– Dividir tareas en subtareas
– Estimar cada subtarea
– Totalizar
– Añadir 5% de reuniones y 15% de gestión
– Añadir 20% (Hard) y 20% (Soft)

23/10/2021
Basado en los componentes del
producto o proceso de desarrollo:
• Bottom-up
– Se descompone el proyecto en las unidades
lo menores posibles.
– Se estima cada unidad y se calcula el coste
total.
• Top-Down
– Se ve todo el proyecto, se descompone en
grandes bloques o fases.
– Se estima el coste de cada componente.

23/10/2021
Método basado exclusivamente en el
mercado: precio para vender
(Pricing to win)
• Lo importante es conseguir el contrato.
• El precio se fija en función de lo que creemos
que esta dispuesto a pagar el cliente.
• Si se usa en conjunción con otros
métodos puede ser aceptable,
para ajustar la oferta.
• Peligro si es el único método
utilizado.

23/10/2021
Contenido
• Recursos.
Función (PF).
• Modelo de Estimación para Proyectos Cliente/Servidor
Intranet/Internet
• Otros modelos

23/10/2021
Líneas de Código (LDC) y Puntos de
Función (PF)
• Los datos de LDC y PF se utilizan de dos formas
durante la estimación del proyecto de software:
1. Como una variable de estimación que se utiliza para
“dimensionar” cada elemento del software.
2. Como métricas de línea base recopiladas de proyectos
anteriores y utilizadas junto con variables de estimación para
desarrollar proyecciones de costo y de esfuerzo.
• Mientras las LDC se estiman directamente, los PF se
determinan indirectamente mediante la estimación de
numero de entradas, salidas, archivos de datos,
consultas e interfaces, así como también de catorce
valores de ajuste de complejidad.
• ¿Serán correctas las estimaciones?
– “No podemos asegurarlo”, deberán prevalecer la experiencia y
el sentido común.

23/10/2021
Métricas del software orientadas al tamaño
Las métricas del software orientadas al tamaño provienen de la
normalización de las medidas de calidad y/o productividad
considerando el «tamaño» del software que se haya producido.
• Productividad = KLDC/persona-mes
• Calidad = errores/KLDC
• Documentación = pags. Doc/ KLDC
• Costo = $/KLDC

23/10/2021
Estimación de Líneas de Código (LDC)
• Las líneas de código fuente (LDC o LOC) es
una métrica de software que se utiliza para
medir el tamaño de un programa informático
contando el número de líneas en el texto del
código fuente del programa.
• LOC se usa generalmente para predecir la
cantidad de esfuerzo que se requerirá para
desarrollar un programa, así como para
estimar la productividad de la programación o
la capacidad de mantenimiento una vez que
se produce el software.

23/10/2021
Ejemplo: Declaración de alcance
• El software CAD mecánico aceptará datos geométricos
bidimensionales y tridimensionales de un ingeniero.
• El ingeniero interactuará y controlará el sistema CAD a través
de una interfaz de usuario que exhibirá características de
buen diseño de interfaz hombre / máquina.
• Todos los datos geométricos y otra información de apoyo se
mantendrán en una base de datos CAD.
• Se desarrollarán módulos de análisis de diseño para producir
el resultado requerido, que se mostrará en una variedad de
dispositivos gráficos.
• El software estará diseñado para controlar e interactuar con
dispositivos periféricos que incluyen un mouse, digitalizador,
impresora láser.

23/10/2021
Ejemplo: estimación de LOC (LDC)
FUNCTIONS ESTIMATED LOC
- User Interface and Control Facilities (UICF) 2,300
- Two Dimensional Analysis (2DGA) 5.300
- 3D Geometric Analysis Function (3DGA) 6,800 ***
- Database Management (DBM) 3,350
- Computer Graphic Display facility (CGDF) 4,950
- Peripheral Control Function (PCF) 2,100
- Design Analysis Modules DAM) 8.400
_____________________________________________________________
TOTAL ESTIMATED LOC ( ∑ LOC ) 33.200
=========================================================
For Example:- Using the Expected Value Equation we can calculate the
Estimated Value for
(3DGA) Function as follows:-
Optimistic Estimation = 5,000 LOC
Most Likely Estimation = 6,700 LOC
Pessimistic Estimation = 9,000 LOC

23/10/2021
Los datos históricos obtenidos de las métricas indican los siguientes promedios
organizacionales:
La productividad media es 620 LOC / Pm (Lines of Code Per Month)
El costo laboral promedio es $8,000 Per month.
El costo de una línea de código se puede calcular de la siguiente manera
(COST / LOC)
COST / LOC = (8000 / 620) = $13
El costo total estimado del proyecto y el esfuerzo del proyecto se pueden
calcular de la siguiente manera:
Considerando que el Total de LOCs ( ∑ LOC) para el Sistema es 33,200
➢ Costo total estimado del proyecto = (33200 * 13 ) = $431,600
➢ Esfuerzo estimado del proyecto = (33200 / 620) = ~ 54 Personas-Mes
Ejemplo: estimación de LOC (LDC)

23/10/2021
Métricas del software orientadas a la función
• Las métricas del software orientadas a la función
utilizan una medida de la funcionalidad entregada por
la aplicación como un valor de normalización.
• Ya que la funcionalidad no se puede medir
directamente, se debe derivar (calcular) mediante
otras medidas directas.
• Punto de función:
– La metodología fue desarrollada por Allan J. Albrecht,
como una métrica del tamaño de un sistema de
información automatizado
– Se calcula (a partir de un prototipo) determinando 5
características de dominio de información
– Factor de Ponderación: simple, medio o complejo. Valor
de complejidad determinado de manera subjetiva por c/
organización.

23/10/2021
Punto de función
factor de complejidad
puntos función
# de entradas de usuario
# de salidas de usuario
# de peticiones (consultas)
# de archivos
# of interfaces externas
parámetro de medida
3
4
3
7
5
conteo
factor de ponderación
simple prom. complejo
4
5
4
10
7
6
7
6
15
10
=
=
=
=
=
conteo-total
X
X
X
X
X

23/10/2021
Puntos de Función: Valores de ajuste
de complejidad
Factor
de
Complejidad
Técnica

23/10/2021
Números de entrada de usuario: se cuenta cada entrada del usuario que
proporcione al software diferentes datos orientados a la aplicación. Las entradas
deben ser distinguidas de las peticiones que se contabilizan por separado.
Numero de salida del usuario: se encuentra cada salida que proporciona la
usuario información orientada a la aplicación. En este contexto las salidas se
refieren a informes, pantalla, mensajes de error. Los elementos de datos
individuales dentro de un informe se encuentran por separado.
Números de peticiones al usuario: una petición esta definida como una
entrada interactiva que resulta de la generación de algún tipo de respuesta
en forma de salida interactiva. Se cuenta cada petición por separado.
Numero de archivos: se cuenta cada archivo maestro lógico, o sea
una agrupación lógica de datos que puede ser una parte en una gran
base de datos o un archivo independiente.
Numero de interfaces externas: se cuentan todas las interfaces legibles
por la maquina por ejemplo: archivos de datos, en cinta o discos que son
utilizados para transmitir información a otro sistema.
Punto
de
función
1
2
3
4
5

23/10/2021
Ejemplo: estimación de FP(1)
• La descomposición para la estimación basada en FP se centra en los valores del
dominio de la información más que en las funciones del software.
• A los efectos de esta estimación, se supone que el factor de ponderación de
complejidad es el promedio.
Puntos de Función No ajustados (PFNA)

23/10/2021
∑ Fi =52
Factor de Complejidad
Técnica

23/10/2021
El número estimado de FP se calcula:
FPestimated = count-total *[0.65 + 0.01*(Fi)]
FPestimated = 320 *[0.65 + 0.01*(52)] = 374.4 ~ 375
FPestimated = 375
Productividad media organizacional = 6.5 FP/pm
El costo laboral promedio es = $8000 por mes, aproximadamente $1230/FP
($8000 / 6.5).
Según la estimación de FP y los datos históricos de productividad, el costo
total estimado del proyecto es de $ 461,000 y el esfuerzo estimado es de 58
meses-persona.

23/10/2021
Contenido
• Recursos.
Función (PF).
Intranet/Internet
• Otros modelos

23/10/2021
Líneas de Código (LDC) v/s Puntos de
Función (PF)
• LDC y PF son técnicas de estimación distintas,
a pesar de que ambas tienen varias
características en común.
• Los métodos de estimación LOC (líneas de
código), FP (punto de función) consideran el
tamaño como la medida.
– En LOC, el costo se calcula en función del número de
líneas.
– En FP, el costo se calcula en función del número de
varias funciones del programa.

23/10/2021
Líneas de Código (LDC) v/s Puntos de
Función (PF)
• Las técnicas de estimación de LDC y PF difieren en el nivel
de detalle que se requiere para la descomposición y el
objetivo de la partición.
• Cuando se utiliza LDC como variable de estimación, la
descomposición es absolutamente esencial y a menudo se
toman para considerables niveles de detalle.
– Cuanto más grande sea el grado de particionamiento, más
probable será que pueda desarrollar estimaciones más exactas.
• Para estimaciones de PF, la descomposición funciona de
diferente manera.
– En lugar de centrarse en la función, se estiman cada una de las
características del dominio de información entradas, salidas,
archivos de datos, peticiones, e interfaces extremas y los
catorce valores de ajuste de la complejidad.
– Las estimaciones resultantes se utilizan para derivar un valor de
PF que se pueda unir a datos pasados y utilizar para generar
una estimación.

23/10/2021
Métricas del software orientadas al tamaño
• Las métricas usadas para estimar el tamaño del
producto de software deben ser razonablemente fáciles
de usar en etapas tempranas del proyecto y fácilmente
mensurables una vez que el trabajo ha finalizado.
• Las LDC miden en forma directa el tamaño del producto
de software. Se calculan simplemente contando las
instrucciones de código fuente de cada componente del
producto de software excluyendo, generalmente, los
comentarios y blancos.
• Los PF miden de forma indirecta el tamaño del producto
de software, realizando su calculo mediante el uso de
otras medidas directas.

23/10/2021
Ventajas y Desventajas de las LDC
• Ventajas
– Fácil de calcular
– Base de cálculo de
modelos de
estimación de costos
de software existentes
– Existencia de literatura
al respecto
– Fácil de automatizar
• Desventajas
– Dependencia del
lenguaje de
programación
– Difícil de estimar en
etapas tempranas del
proyecto
– Difícil de calcular en
lenguajes de
programación no
procedurales

23/10/2021
Contenido
• Recursos.
Función (PF).
Intranet/Internet
• Otros modelos

23/10/2021
Siete maneras de estimar costos...
1. Modelado algorítmico de costos
– Usando algunas métricas de software (generalmente tamaño - LOC) e
información histórica de costos
– Puntos de Función, COSMIC FFP, Puntos de Objecto
– Fórmulas Matemáticas: Curva Raleigh-Putnam
– Modelos de Regresión: COCOMO
2. Juicio de un experto
3. Estimación por analogía
4. Ley de Parkinson
– El trabajo se amplía para llenar el tiempo disponible...
5. De acuerdo al precio para ganar el proyecto (Pricing to win)
6. Estimación Top-down
– Se estima en base a las funciones lógicas y no en base los componentes
requeridos para implementarlos.
7. Estimación Bottom-up
– Agregar el costo de los componentes hasta llegar al costo de todo el
producto.

23/10/2021
Aplicación a
desarrollar
Coste
...
f(x)
x
y
z
v
u
Modelado algorítmico de costos
• Se basan en la utilización de fórmulas que
aplicadas sobre modelos top-down o bottom-up
producen una estimación de coste del proyecto

23/10/2021
Modelos empíricos de estimación
Forma general:
esfuerzo = coeficiente de ajuste * tamaño
exponente
generalmente medido en
meses-persona de
esfuerzo requerido
ya sea una constante o un
número derivado en función
de la complejidad del
proyecto
normalmente LOC pero
también puede ser un
punto de función
calculado
empíricamente
• Los modelos de estimación para software de computadora utilizan fórmulas
derivadas empíricamente para predecir el esfuerzo en función de LOC o FP
• Los valores resultantes calculados para LOC o FP se ingresan en un modelo
de estimación

23/10/2021
Modelos empíricos de estimación
➢ Ejemplo de un modelo de estimación basado en
LOCs producidas (Bailey-Basili model)
E = 5.5 + 0.73  (KLOC)1.16
➢ Ejemplo de un modelo de estimación basado en
FP (Kemerer model)
E = -37 + 0.96 FP
➢ Los modelos de estimación deben calibrarse
para las necesidades locales (particulares)

23/10/2021
Putnam
• Relaciona cantidad de personas-mes y la
duración del proyecto.
• Y=2Kate-at²
Y = Personas-mes en cada punto
K = Esfuerzo total del proyecto,
(Área bajo la curva)
a = Cte. asociada a la aceleración
de entrada de personas en el
proyecto,
t = instante del tiempo.
0
2
4
6
8
10
12
14
16
0
2
4
6
8
1
0
1
2
1
4
1
6
1
8
2
0
2
2
2
4
Meses de Desarrollo
Esfuerzo
Asignado

23/10/2021
La ecuación del software [PUT92] (1)
➢ Es un modelo multivariado
➢ Se ha derivado de los datos de productividad
recopilados para más de 4000 proyectos
contemporáneos de software
E = [LOC  B0.333/P]3  (1/t4)
➢ Donde,
– E = esfuerzo en meses-persona o años-persona
– t = duración del proyecto en meses o años
– B = “special skills factor” (factor de habilidades
especiales)
– P = “productivity parameter” (parámetro de
productividad)

23/10/2021
➢ Para programas pequeños (KLOC = 5 to 15)
– B = 0.16
➢ Para programas mayores de 70 KLOC
– B = 0.39
➢ P = 2000 para el desarrollo de software
embebido en tiempo real
➢ P = 10,000 para telecomunicaciones y
sistemas s / w
➢ P = 28,000 para aplicaciones de sistemas
empresariales

23/10/2021
➢ Fórmulas simplificadas
– tmin = 8.14 (LOC/P)0.43 en meses para tmin > 6
meses
• tmin = tiempo de Desarrollo mínimo
– E = 180 Bt3 en personas-meses para E  20
personas-meses
• Aquí t es representado en años

23/10/2021
➢ Suele ser más rentable adquirir software que desarrollar
➢ Los gerentes tienen muchas opciones de adquisición
– El software se puede comprar (o licenciar) listo para usar
– Los componentes de software de "experiencia completa" o "experiencia
parcial" se pueden adquirir e integrar para satisfacer necesidades
específicas
– El software puede ser personalizado por un contratista externo para
cumplir con las especificaciones del comprador.
➢ La decisión de comprar/desarrollar SW se puede hacer en base a
las siguientes condiciones
– ¿El producto de software estará disponible antes que el software
desarrollado internamente?
– ¿El costo de adquisición más el costo de personalización será menor
que el costo de desarrollar el software internamente?
– ¿El costo del soporte externo (por ejemplo, un contrato de
mantenimiento) será menor que el costo del soporte interno?
Decisión de comprar/desarrollar SW

23/10/2021
Crear
un
árbol
de
decisiones

23/10/2021
(path probability) x (estimated path cost)
i i
For example, the expected cost to build is:
expected cost = 0.30 ($380K) + 0.70 ($450K)
similarly,
expected cost = $382K
build
reuse
buy
contr
expected cost =
= $429 K
Cálculo
del
costo
esperado

23/10/2021
➢ Sin embargo, es importante señalar que muchos
criterios, no solo el costo, deben considerarse
durante el proceso de toma de decisiones.
➢ La disponibilidad, la experiencia del
desarrollador / vendedor / contratista, el
cumplimiento de los requisitos, la “política” local
y la probabilidad de cambio son solo algunos de
los criterios que pueden afectar la decisión final
de construir, reutilizar, comprar o contratar.

23/10/2021
Subcontratación
➢ Las actividades de ingeniería de SW se
contratan a un tercero que realiza el trabajo a un
costo menor y, con suerte, de mayor calidad.
➢ El trabajo de SW realizado dentro de una
empresa se reduce a una actividad de gestión
de contratos
➢ La decisión de subcontratar puede ser
estratégica o táctica.
➢ Tiene méritos y deméritos

23/10/2021
Contenido
• Recursos.
Función (PF).
Intranet/Internet
• Otros modelos

23/10/2021
Modelo COCOMO Intermedio
• Añade al modelo básico 15 factores de ajuste, también
llamados multiplicadores del esfuerzo o guías de coste.
– Tamaño B.D., experiencia analistas, herramientas, … (15 en
total, varían de 0.75-1.66)
• Se logra una mayor precisión en la estimación gracias a los
nuevos factores.
• La fórmula es la misma que la del modelo básico pero con el
añadido del factor (multiplicando).
Effort = a * (SIZE)b *M
Multiplicador FAE
Submodelos intermedios a b c d
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32
FAE es un factor de ajuste de esfuerzo que normalmente fluctúa entre 0,9 y 1,4.
Miles de Líneas de código Factores de escala

23/10/2021
Cálculo de FAE
Es a través de los Puntos de Función (PF).
Hoy en día es la forma más utilizada y para ello se requiere utilizar
los factores de conversión correspondiente al lenguaje utilizado.
Para ello se debe utilizar la siguiente tabla (Factores de costo), que
contiene 15 atributos que deben ser evaluados para el proyecto.
Estos atributos se utilizan para ajustar el esfuerzo del proyecto al
entorno real, incrementando la precisión de la estimación

23/10/2021
Atributos del modelo Intermedio
• Software:
• RELY: Indica las
consecuencias para el usuario
si falla el producto.
• DATA: Relación Tamaño de la
BD / Líneas de código.
• CPLX: Complejidad del
producto.
• Hardware:
• TIME: Limitaciones en el
porcentaje del uso de la CPU.
• STOR: Limitaciones en el
porcentaje del uso de la
memoria.
• VIRT: Volatilidad de la máquina
virtual.
• TURN: Tiempo de respuesta.
• Personal:
• ACAP: calificación de los
analistas.
• AEXP: experiencia del
personal.
• PCAP: calificación de los
programadores.
• VEXP: experiencia del personal
en la máquina virtual.
• LEXP: experiencia en el
lenguaje.
• Proyecto:
• MODP: uso de prácticas
modernas de programación.
• TOOL: uso de herramientas de
desarrollo de software.
• SCED: limitaciones en el
cumplimiento de la
planificación.

23/10/2021
Cálculo de FAE
Factores de Costo

23/10/2021
SIZE con Puntos de Función (1)
Después de valorizar los Factores de Costo del Proyecto, se procede a
valorizar los Factores Funcionales de Peso, con la siguiente tabla:
Para obtener los Factores Funcionales de Peso, se debe seleccionar la
complejidad del Proyecto, y multiplicarlo, por cada valor obtenido para los
factores funcionales. Para ello se requiere previamente un prototipo, del
cual se obtendrán N° de Entradas de usuario, N° salidas usuario, etc.
Luego de esto, se debe sumar el resultado total de la multiplicación para
los 5 puntos evaluados (factores funcionales de peso).

23/10/2021
SIZE con Puntos de Función (2)
Del resultado obtenido, se puede obtener los
puntos de función aplicando la siguiente
fórmula:
PF = [Σfactores funcionales de peso] * [0.65 +
(0.01 * Σfactores costo)]
El valor resultante de la conversión PF, debe
ser multiplicado por la tabla de conversión a
líneas de código (LOC), la cual está
determinada por el lenguaje de desarrollo a
utilizar en el proyecto.
LOC = PF * Correlación
La tabla de conversión es la siguiente ->
Tabla
de
Conversión
de:
Correlación
Código
Fuente
a
PF

23/10/2021
Ejemplo “SIZE con Puntos de Función”
Supongamos que se quiere desarrollar un proyecto transaccional
que operará en plataforma web y su tamaño es mediano.
¿Cuál será el esfuerzo requerido, tiempo de desarrollo, personal utilizado
en el proyecto ?
1

23/10/2021
Utilizando un prototipo se llena la tabla asociada a los factores de Peso.
PF = [Σfactores funcionales de peso] * [0.65 + (0.01 * Σfactores de costo)]
Aplicando la formula se tiene:
PF = [513] * [0,65 + (0,01 * 14,91)]
PF= 409,9383
Continuación Ejemplo:

23/10/2021
Continuación Ejemplo
Luego se procede a aplicar la formula de Conversión a LOC:
Como ya se dijo anteriormente, el lenguaje a utilizar es JAVA.
Entonces se tiene que
LOC = PF * Correlación
LOC = 409,9383 * 46
LOC =18857,1618 (Líneas de Código)
KLOC = 18857,1618 / 1000
KLOC = 19 (Kilo o miles de línea de código)

23/10/2021
Calculo de la variable FAE (multiplicador):
FAE = 0,88 * 1,08 * 1,15 * 1,3 * 1,00 * 1,15 * 1,00 * 1,29 * 0,86 *
1,21 * 1,07 * 0,91 * 0,91 * 1,1 = 2.137854971

23/10/2021
E = a(KLOC)b * FAE
D = c(E)d
P = E/D
C = P *Salario
Como ya se había dicho, el proyecto es de mediano tamaño.
Entonces se tiene:
Esfuerzo (E) = 3,0*( 19)1,12 * 2,137 = 173,48 meses/hombre
Duración (D)= 2,5*(173,48)0,35 = 6,07 meses
Personal (P)= 173,48 / 6.07 = 28,54 personas
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32

23/10/2021
Ejemplo “MODELO INTERMEDIO”
• Debemos desarrollar un
software de no muy elevada
dificultad, con las siguientes
restricciones:
• 3 meses para el desarrollo
del proyecto software.
• Debe estar implementado
en el lenguaje Visual Basic
• PF=261,36 (dato conocido)
• Calculo del esfuerzo:
Necesitamos hallar la
variable SIZE.
LENGUAJE LDC/PF
Ensamblador 320
C 150
COBOL 105
Pascal 91
Prolog/LISP 64
C++ 64
Visual Basic 32
SQL 12
2

23/10/2021
• SIZE = (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000
= 8,363
• Usaremos el tipo Orgánico ya que núestro proyecto no supera
las 50 KLOC, y es el mas apropiado en este caso.
• Coeficientes a usar:
Ejemplo estimación
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32

23/10/2021
• Calculo de la variable FAE (multiplicador):
CONDUCTORES DE COSTE VALORACIÓN
Muy
bajo
Bajo Nominal Alto Muy
alto
Extr.
alto
Fiabilidad requerida del software 0,75 0,88 1.00 1,15 1,40 -
Tamaño de la base de datos - 0,94 1.00 1,08 1,16 -
Complejidad del producto 0,70 0,85 1.00 1,15 1,30 1,65
Restricciones del tiempo de ejecución - - 1.00 1,11 1,30 1,66
Restricciones del almacenamiento principal - - 1.00 1,06 1,21 1,56
Volatilidad de la máquina virtual - 0,87 1.00 1,15 1,30 -
Tiempo de respuesta del ordenador - 0,87 1.00 1,07 1,15 -
Capacidad del analista 1,46 1,19 1.00 0,86 0,71 -
Experiencia en la aplicación 1,29 1,13 1.00 0,91 0,82 -
Capacidad de los programadores 1,42 1,17 1.00 0,86 0,70 -
Experiencia en S.O. utilizado 1,21 1,10 1.00 0,90 - -
Experiencia en el lenguaje de programación 1,14 1,07 1.00 0,95 - -
Prácticas de programación modernas 1,24 1,10 1.00 0,91 0,82 -
Utilización de herramientas software 1,24 1,10 1.00 0,91 0,83 -
Limitaciones de planificación del proyecto 1,23 1,08 1.00 1,04 1,10 -
Ejemplo estimación

23/10/2021
– Calculo de la variable FAE (multiplicador):
• FAE = 1,15 * 1,00 * 0,85 * 1,11 * 1,00 * 1,00 * 1,07 * 0,86 * 0,82 * 0,70
* 1,00 * 0,95 * 1,00 * 0,91 * 1,08 = 0,53508480
– Cálculo del esfuerzo del desarrollo:
• E = a (SIZE)b * FAE = 3,2 * (8.363)1,05 * 0,53508480 = 15,91 personas
/mes
– Cálculo tiempo de desarrollo:
• T = c Esfuerzod = 2,5 * (15,91)0,38 = 7,15 meses
– Productividad:
• PR = SIZE/Esfuerzo = 8363/15,91 = 525 ,64 LDC/personas mes
– Personal promedio:
• P = E/T = 15,91/7,15 = 2,22 personas
Ejemplo estimación
Según los resultados necesitaremos un equipo de 3 personas trabajando alrededor de 7 meses, pero
como una restricción era 3 meses incrementamos a 6 el numero de personas. 1 Jefe de proyecto, 2
Analistas, 2 programadores y 1 Responsable de calidad.

23/10/2021
Contenido
• Recursos.
Función (PF).
Intranet/Internet
• Otros modelos

23/10/2021
Modelo Algorítmico de Costos de Software
(MACOS)
• Usa de base la métrica Puntos de Función y un Factor de Ajuste (FA)
asociado a características del producto y del ambiente de desarrollo,
para calcular el Esfuerzo Ajustado Estimado, EAE (medido en Horas -
Hombre) y el Tiempo de Desarrollo Estimado, TDESE (medido en
Horas).
• El Factor de Ajuste del modelo MACOS considera la incidencia de 32
factores asociados a aspectos técnicos del diseño y construcción del
producto de software, así como al entorno en el que se realiza el
proyecto.
• Estos factores se clasifican en: difíciles de cuantificar y cuantificables.
– Para cuantificar estos factores se asigna a cada uno
un valor denominado grado de influencia (GI), que
varía entre -5 y +5, el cual indica la incidencia del
factor en los costos del proyecto, donde el signo
más significa aumento del esfuerzo y el signo menos
significa disminución del esfuerzo

23/10/2021
Factores difíciles de cuantificar
• INTUSU : Calidad de las interfaces con el usuario.
• ESPREQ : Calidad de la especificación de requerimientos.
• RECONT : Existencia de un plan de recursos y control del
proyecto.
• PLAPRO : Existencia de un plan detallado del proyecto.
• TESTVV : Existencia de un plan detallado de pruebas, de
verificación y validación.
• AMBTRA : Calidad del ambiente de trabajo.
• SEGPRI : Restricciones de seguridad y privacidad existentes.
• DOCEXI : Calidad de la documentación.
• CONPER : Calidad de la administración del proyecto.

23/10/2021
Factores cuantificables, perceptibles
para el usuario del producto
• VOLTRA : Volumen de transacciones a realizar
• TAMADB : Tamaño de la base de datos.
• DATARC : Características de captura, validación,
actualización y almacenamiento de datos.
• FACOPE : Facilidad de operación
• FAFPLCA : Facilidad y flexibilidad de cambio.
• RENOPE : Rendimiento requerido para la operación del
producto de software.
• CONPRO : Confiabilidad del producto de software entregado.
• RESTPO : Restricciones en el tiempo de desarrollo
• Del ambiente usuario
– MODOP : Modo de desarrollo y operación del producto de software.
– EXUSUA : Experiencia del usuario en la aplicación y en el
procesamiento de datos.

23/10/2021
Factores cuantificables, perceptibles
para el desarrollador
• Del personal de desarrollo
– CAPAN : Capacidad de los analistas.
– EXPANA : Experiencia de los
analistas.
– CAPRO : Capacidad de los
programadores.
– EXPMV : Experiencia del grupo en la
plataforma de desarrollo (configuración
de hardware y software) necesaria
para el desarrollo del producto de
software.
– EXPLEN : Experiencia en el lenguaje
– COMPE : Continuidad del personal
• Del computador
– RAPCPU : Restricciones del
almacenamiento principal y de uso de
CPU durante el desarrollo.
– TRESPOC : Tiempo de respuesta
promedio del computador.
– VOLAMV : Volatilidad de la plataforma
de desarrollo.
• Del proyecto
– HERRAD : Herramientas de ayuda
utilizadas.
– PMOPRO : Prácticas modernas de
programación utilizadas.
• Del producto
– COMPLP : Complejidad del producto
de software.
– FAICMA : El diseño del producto de
software contempla su facilidad de
instalación, conversión y
mantenimiento.

23/10/2021
El modelo MACOS sigue los siguientes pasos:
• Paso 1: Calcular los Puntos de Función No Ajustados (PFNA), esto es,
contar por categoría las entradas, salidas, consultas, archivos internos
e interfaces con otros productos de software. Asignar a cada una de
ellas, una de las siguientes ponderaciones: Simple, Promedio o
Compleja.
PFi = cuentai * ponderación; i=1,…, 5
PFNA = suma( PFi )
• Paso 2: Calcular el FA de la siguiente manera:
– A cada uno de los 32 factores que componen el Factor de Ajuste (FA), asignar uno de
los grados de influencia (GI), según su incidencia en los costos del proyecto.
SGI = suma(GIi), i=1,...,32
FA = 1 + (SGI/400)
– Calcular el Esfuerzo Ajustado Estimado:
EAE = 1,04 * (PFNA)1,22 * FA [horas-hombre]
– Calcular el Tiempo de Desarrollo estimado: Contar el personal de tiempo completo
disponible para el desarrollo del proyecto (NPTC) según los antecedentes del
proyecto y la productividad del personal que se asignará.
TDESE = EAE/NPTC [horas]

23/10/2021
Contenido
• Recursos.
Función (PF).
Intranet/Internet
• Otros modelos

23/10/2021
Modelo de Estimación para Proyectos Cliente/Servidor
• El modelo que se plantea para calcular la estimación de esfuerzo de
los proyectos Cliente/Servidor, se basa en PF. Para aplicarlo a
proyectos Cliente/Servidor se debe tener en cuenta los siguientes
puntos al calcular los puntos de función:
– En la componente de los archivos de interface externos, la ponderación
se verá afectada por la complejidad de la creación de la base de datos
del sistema. Por esto se deberá dar un peso de promedio o complejo a
este componente, dependiendo del tamaño de la base de datos.
– En la componente de los archivos internos lógicos, se tomaran de todas
las bases de datos (que intercalan con el sistema), como unidades
separadas, es decir, cada tabla de la base de datos (o archivo de la
base de datos) se tomará como un archivo interno lógico.
– En cuanto al calculo del factor de complejidad para los puntos de
función, se tendrá mucho cuidado a todas aquellas características
relacionadas a la comunicación entre las bases de datos, ya que serán
las que influirán en un alto nivel durante la ejecución del sistema.
• El modelo considera los puntos de función (medidos) del sistema y
el número de archivos (o el número de tablas que contiene la base
de datos) (medidos) del sistema, como se verá más adelante. Con
estas dos variables independientes se podrá estimar el esfuerzo del
desarrollo del sistema

23/10/2021
Pasos para aplicar el modelo a un
proyecto Cliente/Servidor
Se presenta a continuación los pasos a seguir para
estimar el esfuerzo de desarrollo de un proyecto
Cliente/Servidor:
• Paso 1: Calcular los Puntos de Función del proyecto
– Definir en forma global para el proyecto: Entradas,
Salidas, Consultas, Archivos lógicos internos y Archivos
de interfase externos. Asociar a cada ítems de los grupos
mencionados la identificación de simple, promedio o
complejo según corresponda a las condiciones de
desarrollo, observadas en ellos. Por ejemplo:

23/10/2021
• Paso 2: Obtener los Puntos de Función No ajustados (PFNA),
el que estará dado por:
𝑃𝐹𝑁𝐴 = σ𝑖=1
5
𝑃𝐹𝑖 ,
donde 𝑃𝐹𝑖 cantidad de veces en que se obtendra el item x factori
(o pesoi) donde i=1 al 5
– Por ejemplo: Suponiendo que se tiene los mismos datos que el
caso anterior

23/10/2021
• Paso 3: Obtener el Factor de Complejidad Técnica, el que
estará dado por:
𝐹𝐶 = 0.65 + 0.01 σ𝑖=1
14
𝑐𝑖
• Paso 4: Finalmente para obtener el valor de Puntos de
Función (PF), estará dado por:
𝑃𝐹 = 𝑃𝐹𝑁𝐴 + 𝐹𝐶𝑇
– Por lo tanto se obtienen los Puntos de Función en [PF] del
proyecto.
• Paso 5: Aplicación del Modelo para Estimación de Proyectos
C/S
Esfuerzo Estimado=11.453+ 0.031⋅ X + 0.112⋅Y [PM] donde:

23/10/2021
• Paso 6: Presentación de resultados
– En estos momentos hemos encontrado el Esfuerzo
Estimado del proyecto en estudio en unidades [PM]
(Persona–Mes, es decir, el tiempo en meses que se tarda
una persona en realizar el proyecto entero solo),
dependiendo del número de personas a trabajar en el
proyecto se va disminuyendo el tiempo de desarrollo del
proyecto.

23/10/2021
Contenido
• Recursos.
Función (PF).
Intranet/Internet
• Otros modelos

23/10/2021
Modelo de estimación para
aplicaciones Intranet/Internet
• En este modelo de estimación, se modifica la técnica de PF para
destacar la importancia del concepto de reutilización en el
desarrollo de aplicaciones Intranet/Internet.
• Para analizar el impacto de la reusabilidad en los proyectos se
definen los siguientes factores que influyen directamente en la
reutilización. Estos factores se han clasificado en tres categorías y
se muestran en la siguiente Tabla:
Factores
de
MACOS

23/10/2021
Modelo de estimación para
aplicaciones Intranet/Internet
• Para los factores anteriores es necesario considerar
las siguientes ponderaciones, estas se utilizan para
llevar a cabo el ajuste de las estimaciones.
Factor
de
Reutilización

23/10/2021
Fases de la Metodología
• Fase 1: Analizar los requerimientos funcionales del sistema a
desarrollar.
• Fase 2: Aplicar la técnica actual de punto de función, para los
requerimientos establecidos en el punto anterior.
• Fase 3: Identificar los factores candidatos para definir los
componentes reusables a utilizar en la estimación mostrada
en la tabla de Ponderación para los factores. A cada uno de
estos factores se les debe estimar el porcentaje de
reutilización a partir de las ocurrencias, como muestra en la
siguiente Tabla

23/10/2021
Fases de la Metodología
• Fase 4: Finalmente predecir el impacto de los componentes
reusables en el nuevo desarrollo. A través de la siguiente Tabla de
ponderaciones presentada, encontrar el factor de reutilización
Cálculo
del
factor
de
reutilización
• Fase 5: Analizar el resultado obtenido en la fase 2, para combinarlos con
los del paso anterior y obtener la nueva estimación.
Pf reuso = Pf teorico* (1- factor de reuso)
• Con lo que se obtiene el esfuerzo en PF corregido por la reutilización

23/10/2021
Contenido
• Recursos.
Función (PF).
Intranet/Internet
• Otros modelos

23/10/2021
Estimación con casos de uso
• A diferencia de una LOC o PF, el “caso de uso” de una persona
puede requerir meses de esfuerzo, mientras que el de otra puede
implementarse en un día o dos.
• Smith [Smi99] sugiere que los casos de uso pueden usarse para
estimación, pero sólo si se consideran dentro del contexto de la
“jerarquía estructural” donde se usan para describir
• Smith [Smi99] argumenta que cualquier nivel de esta jerarquía
estructural puede describirse mediante no más de 10 casos de uso.
Cada uno de éstos abarcaría no más de 30 escenarios distintos
• En consecuencia, antes de poder usar los casos de uso para
estimación, se establece el nivel dentro de la jerarquía estructural,
se determina la longitud promedio (en páginas) de cada caso de
uso, se define el tipo de software (por ejemplo, tiempo real,
empresarial, ingeniería/científico, webapp, incrustado) y se
considera una arquitectura burda para el sistema.

23/10/2021
• El software CAD (usado en la sección inicial de esta unidad) se
compone de tres grupos de subsistemas:
– subsistema de interfaz de usuario (incluye UICF),
– grupo de subsistemas de ingeniería (incluye los subsistemas 2DGA,
3DGA y DAM) y
– grupo de subsistemas de infraestructura (incluye los subsistemas
CGDF y PCF).
• Seis casos de uso describen el subsistema de interfaz de usuario.
Cada uno se describe mediante no más de 10 escenarios y tiene
una longitud promedio de seis páginas.
• El grupo de subsistemas de ingeniería se describe mediante 10
casos de uso (se considera que están en un nivel superior de la
jerarquía estructural). Cada uno de estos casos de uso tiene no más
de 20 escenarios asociados con él y una longitud promedio de ocho
páginas.
• Finalmente, el grupo de subsistemas de infraestructura se describe
mediante cinco casos de uso con un promedio de sólo seis
escenarios y una longitud promedio de cinco páginas.

23/10/2021
• Una vez establecidas dichas características pueden usarse datos
empíricos para establecer el número estimado de LOC o PF por
caso de uso (por cada nivel de la jerarquía).
• Entonces se usan datos históricos a fin de calcular el esfuerzo
requerido para desarrollar el sistema. Para ilustrar cómo puede
realizarse este cálculo, considere la siguiente relación:
LOC estimadas= N x LOCprom + [(Sa/Sh – 1) (Pa/Ph – 1)] x LOCajuste
• Donde:
✓ N: número real de casos de uso
✓ LOCprom: LOC promedio históricas
por caso de uso para este tipo de
subsistema
✓ LOCajuste: representa un ajuste
con base en n por ciento de
✓ LOCprom: donde n se define
localmente y representa la
diferencia entre este proyecto y
los proyectos “promedio”
✓ Sa: escenarios reales por caso
de uso
✓ Sh: escenarios promedio por
caso de uso para este tipo de
subsistema
✓ Pa: páginas reales por caso de
uso
✓ Ph: páginas promedio por caso
de uso para este tipo de
subsistema
El ajuste representa hasta n por ciento de las LOC promedio históricas por caso de uso.

23/10/2021
Usando la relación anotada en la expresión anterior, con n = 30%, se elaboró la
tabla siguiente:
Observe la primera hilera de la tabla; los datos históricos indican que el software UI
requiere un promedio de 800 LOC por caso de uso cuando el caso de uso no tiene
más de 12 escenarios y se describe en menos de cinco páginas.
Dichos datos se ajustan razonablemente bien para el sistema CAD
(LOCajuste=800x0.70=560). Por tanto, la estimación LOC para el subsistema de
interfaz de usuario se calcula con la expresión de la diapositiva anterior.
Usando el mismo enfoque se hacen estimaciones para los grupos de subsistemas
de ingeniería e infraestructura. La tabla resume las estimaciones e indica que el
tamaño global del CAD se estima en 42 500 LOC.

23/10/2021
Utilizando 620 LOC/pm como la productividad promedio para sistemas de este
tipo y una tarifa de mano de obra de $ 8000 por mes, el costo por línea de
código es de aproximadamente $ 13 ($8000/620). Según la estimación del
caso de uso y los datos históricos de productividad, el costo total estimado del
proyecto es de $ 552,000 y el esfuerzo estimado es de 68 meses-persona.

23/10/2021
Estimación para proyectos OO(1)
1. Desarrolle estimaciones utilizando descomposición de esfuerzo,
análisis de FP y cualquier otro método que sea aplicable para
aplicaciones convencionales.
2. Usando el modelado de requisitos, desarrolle casos de uso y
determine un conteo. Reconocer que el número de casos de uso
puede cambiar conforme avance el proyecto.
3. A partir del modelo de análisis, determine el número de clases
clave (denominadas clases de análisis).
4. Categorizar el tipo de interfaz para la aplicación y desarrollar un
multiplicador para clases de apoyo:
– Interface type Multiplier
– No GUI 2.0
– Text-based user interface 2.25
– GUI 2.5
– Complex GUI 3.0

23/10/2021
Estimación para proyectos OO(2)
5. Multiplique el número de clases clave (paso 3) por el multiplicador
para obtener una estimación del número de clases de apoyo.
6. Multiplique el número total de clases (clave + soporte) por el
número medio de unidades de trabajo por clase. Lorenz y Kidd
sugieren de 15 a 20 días-persona por clase.
7. Verifique la estimación basada en clases multiplicando el número
promedio de unidades de trabajo por caso de uso

23/10/2021
Estimación sobre proyectos ágiles
1. Cada escenario de usuario (un mini-caso de uso) se considera por
separado para fines de estimación.
2. El escenario se descompone en el conjunto de tareas de ingeniería
de software que serán necesarias para desarrollarlo.
3. Cada tarea se estima por separado. Nota: la estimación puede
basarse en datos históricos, un modelo empírico o "experiencia".
– Alternativamente, el "volumen" del escenario se puede estimar en LOC, FP
o alguna otra medida orientada al volumen (por ejemplo, recuento de casos
de uso).
4. Las estimaciones de cada tarea se suman para crear una
estimación del escenario.
– Alternativamente, la estimación de volumen para el escenario se traduce en
esfuerzo utilizando datos históricos.
5. Las estimaciones de esfuerzo para todos los escenarios que se
implementarán para un incremento de software dado se suman
para desarrollar la estimación de esfuerzo para el incremento.

23/10/2021
Modelo de estimación para webapps
Los webapps adoptan con frecuencia el modelo de proceso ágil. Puede usarse
una medida de PF modificada, junto con los pasos que se destacan en la
estimación sobre proyectos ágiles. Roetzheim [Roe00] sugiere el siguiente
enfoque cuando adapta puntos de función para estimación de webapps:
• Entradas son cada pantalla o formulario de entrada (por ejemplo, CGI o
Java), cada pantalla de mantenimiento y, si usa una metáfora de etiquetas
de libreta, cualquier etiqueta.
• Salidas son cada página web estática, cada guión de página web dinámica
(por ejemplo, ASP, ISAPI u otro guión DHTML) y cada reporte (ya sea
basado en web o administrativo por naturaleza).
• Tablas son cada tabla lógica en la base de datos más, si usa XML para
almacenar datos en un archivo, cada objeto XML (o colección de atributos
XML).
• Las interfaces conservan su definición como archivos lógicos (por ejemplo,
formatos de registro único) dentro de las fronteras del sistema.
• Consultas son cada una de las publicaciones externas o el uso de una
interfaz orientada a mensaje. Un ejemplo usual son las referencias externas
DCOM o COM.

23/10/2021
ESTIMACIÓN DE
PROYECTOS DE SOFTWARE
Unidad 4
Final de la unidad
Y del curso…. !Muchas gracias
a todos!

Estimating Software Project Size and Effort Using Lines of Code (LOC

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Estimating Software Project Size and Effort Using Lines of Code (LOC

Similar to Estimating Software Project Size and Effort Using Lines of Code (LOC (20)

More from Franklin Parrales Bravo

More from Franklin Parrales Bravo (20)

Recently uploaded

Recently uploaded (20)

Estimating Software Project Size and Effort Using Lines of Code (LOC