EP Unidad03: Planificación financiera y análisis de riesgos

Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
1
26/01/2023
Planificación financiera y
análisis de riesgos
Unidad 3
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Elaboración de Proyectos

Carrera de Software
2
26/01/2023
Objetivo general de la Unidad 3
Comprender los procesos y técnicas para la planificación
financiera y análisis de riesgos de un proyecto de ingeniería de
software.

Carrera de Software
3
26/01/2023
Contenido:
▪ Planificación financiera de proyectos de software.
▪ Estimación de proyectos: Modelo COCOMO.
▪ Evaluación Económica de Proyectos
▪ Identificación y análisis de riesgo

Carrera de Software
4
26/01/2023
¿Qué es Proceso de planificación financiera?
▪ La planificación financiera es el proceso de elaboración de
un plan financiero integral, organizado, detallado y
personalizado, que garantice alcanzar los objetivos
financieros determinados previamente, así como los
plazos, costes y recursos necesarios para que sea posible.
▪ En esta sección nos referiremos de forma específica a la
elaboración del presupuesto financiero
▪ En proyectos grandes se refiere a la identificación de las diferentes
partidas necesarias para conseguir resultados satisfactorios:
inversión en renta fija, variable, selección de fondos, planes de
pensiones, etcétera.

Carrera de Software
5
26/01/2023
Contenido:

Carrera de Software
6
26/01/2023
Estimación
Intento por determinar cuánto dinero, esfuerzo,
recursos y tiempo tomará construir un sistema o
producto específico basado en software

Carrera de Software
7
26/01/2023
Problemática de la estimación
▪ Averiguar lo que costara de desarrollar una
aplicación.(meses-persona, $, …)
▪ Momento en que se desea conocer el coste (gráfico de
Boehm)
▪ Siempre se quiere muy pronto (Yourdon)

Carrera de Software
8
26/01/2023
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

Carrera de Software
9
26/01/2023
Medir lo que quiere el usuario.

Carrera de Software
10
26/01/2023
Estimar lo que costara
▪ Experiencia Individual
▪ Experiencia de Empresa

Carrera de Software
11
26/01/2023
Técnicas de estimación
▪ Se han desarrollado varias técnicas de estimación para
el desarrollo de software.
▪ Aunque cada una tiene sus puntos fuertes y sus puntos
débiles, todas tienen en común los siguientes
atributos:
1. Se han de establecer de antemano el ámbito del proyecto.
2. Como bases para la realización de estimaciones se usan
métricas del software de proyectos pasados.
3. El proyecto se desgloba en partes más pequeñas que se
estiman individualmente.

Carrera de Software
12
26/01/2023
Siete maneras de estimar costos...
1. Modelado algorítmico de costos
▪ Usando algunas métricas de software (generalmente tamaño) 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.

Carrera de Software
13
26/01/2023
COnstructive COst MOdel I
B. Boehm (1981)
▪ Su primera versión surgió en 1981 (Bohem, 1981).
▪ "Software Engineering Economics" (Prentice-Hall, 1981)
▪ COCOMO I es una jerarquía de modelos de estimación de costes
software que incluye submodelos básico, intermedio y detallado.
▪ Trata de establecer una relación matemática que permita estimar
el esfuerzo y tiempo requerido para desarrollar un producto.
▪ La aparición y generalización del uso de las computadoras provocó
cambios en el modelo.
▪ En 1983 se introduce el lenguaje de programación ADA (American
National Standard Institute) para reducir los costos de desarrollo de
grandes sistemas. Aquello provocó un gran impacto en los costos de
desarrollo y mantenimiento.
▪ Sufrió un refinamiento para el desarrollo de software en ADA (Bohem y
Royce, 1989)

Carrera de Software
14
26/01/2023
Modelos de COCOMO I B. Boehm (1981)
• Modelo básico: Este modelo trata de estimar, de una manera
rápida y más o menos burda, la mayoría de proyectos pequeños y
medianos.
• Modelo intermedio: En este modelo se introducen 15 atributos de
coste para tener en cuenta el entorno de trabajo. Estos atributos se
utilizan para ajustar el coste nominal del proyecto al entorno real,
incrementando la precisión de la estimación.
• Modelo detallado: Este modelo puede procesar todas las
características del proyecto para construir una estimación.
Introduce dos características principales
• Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven más
afectadas que otras por los atributos. El modelo detallado proporciona un
conjunto de multiplicadores de esfuerzo para cada atributo. Esto ayuda a
determinar la asignación del personal para cada fase del proyecto.
• Jerarquía del producto a tres niveles. Se definen tres niveles de producto.
Estos son módulo, subsistema y sistema. La cuantificación se realiza al
nivel apropiado, esto es, al nivel al que es más susceptible la variación.
1
2
3

Carrera de Software
15
26/01/2023
Constantes de COCOMO I: a y b
▪ Las ecuaciones de estimación del esfuerzo de desarrollo tienen
la forma
Effort = a * (SIZE)b *M
▪ a y b se pueden determinar por un procedimiento de ajuste de
curva (análisis de la regresión).
▪ Pero la mayoría de las organizaciones no tienen suficientes
datos para realizar dicho análisis.
▪ Por ello Boehm construyó el modelo e identificó 3 niveles de
dificultad (submodelos) que parecen categorizar muchos
proyectos de software.
▪ Otra asunción de COCOMO:
1 mes = 152 horas productivas
(8 horas por día, 19 días/mes)
(menos fines de semana, feriados, etc.)
Multiplicador
Miles de Líneas de código (KLOC) Factores de escala

Carrera de Software
16
26/01/2023
COCOMO I puede ser aplicado a tres tipos de proyectos software. Esto
nos da una impresión general del proyecto. Por ello incluye 3 submodelos
con un nivel de detalle cada vez mayor
▪ Proyectos Orgánicos (Organic) – proyectos realmente sencillos,
menores de 50 KLOC (líneas de código), en los cuales se tiene
experiencia de proyectos similares y se encuentran en entornos
estables.
▪ Proyectos medianos (Semi-detached) – son intermedios en
tamaño (menores de 300 KLOC) y complejidad, donde la experiencia
en este tipo de proyectos es variable (no tienen la misma experiencia
todos los miembros del equipo), y las restricciones son intermedias
(hay más requisitos pero no son tan rígidos).
▪ Proyectos embebidos (Embedded) – Son proyectos software que
se deben desarrollar con unos requisitos de hardware, software y de
operación.
Submodelos de COCOMO I B. Boehm (1981)

Carrera de Software
17
26/01/2023
Modelos de estimación COCOMO I
▪ Modelo básico
▪ El modelo básico se usa para obtener una aproximación rápida
del esfuerzo.
▪ Usa las variables a, b, c y d, que varían en función de los modos.
▪ Conforme se aumenta la complejidad del modo, aumentan los
valores de las variables (esfuerzo).
Effort = a * (SIZE)b
1
Miles de Líneas de código Factores de escala
Submodelos básicos a b c d
Orgánico 2,4 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32

Carrera de Software
18
26/01/2023
Effort = a*(Size)b
DevTime = c*(Effort)d
“KLOC”
PM Personas Mes
M Meses
“MODELO BASICO”
Submodelos básicos a b c d
Orgánico 2,4 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32
ATENCIÓN: Hay que utilizar con mucho cuidado el modelo básico puesto que se
obvian muchas características del entorno.

Carrera de Software
19
26/01/2023
La ecuación de COCOMO en este modo básico es:
E = a(Size)b
D = c(E)d
P = E/D
C = P *Salario
Donde :
▪ E = El esfuerzo aplicado en persona-mes.
▪ D= El tiempo de desarrollo en meses.
▪ Size = El número de líneas estimadas para el proyecto (en miles o
kilos)
▪ P = El número de personas necesarias para el proyecto.
▪ C= Costo total del proyecto (P * Salario medio) entre los
programadores y analistas.

Carrera de Software
20
26/01/2023
Ejemplo “MODELO BASICO”
Partimos de conocer el número de líneas que tendrá la
futura aplicación: Volumen = 30000 LOC = 30KLOC
Proyecto Orgánico
Esfuerzo= 2.4 * (30)1.05 = 85 PM (Personas-Mes)
DevTime = 2.5 * (85)0.38 = 13.5 M (Meses)
=> Personas: 85/13.5 = 6.3 personas
=> Productividad: 30000/85 = 353 LOC/PM
Compare:
Medio: 135 PM 13.9 M 9.7 personas
Embebido: 213 PM 13.9 M 15.3 personas
Ej.:

Carrera de Software
21
26/01/2023
▪ Modelo 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
2
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.

Carrera de Software
22
26/01/2023
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

Carrera de Software
23
26/01/2023
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.

Carrera de Software
24
26/01/2023
Cálculo de FAE Factores de Costo

Carrera de Software
25
26/01/2023
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).

Carrera de Software
26
26/01/2023
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
58 LOC for C#, 28 LOC for VB.net and 56 LOC for PHP
Arnuphaptrairong, T. (2013). Early stage software effort estimation using function point analysis: an empirical
validation. International Journal of Design, Analysis and Tools for Integrated Circuits and Systems, 4(1), 15.

Carrera de Software
27
26/01/2023
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

Carrera de Software
28
26/01/2023
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:

Carrera de Software
29
26/01/2023
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)

Carrera de Software
30
26/01/2023
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

Carrera de Software
31
26/01/2023
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

Carrera de Software
32
26/01/2023
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

Carrera de Software
33
26/01/2023
▪ 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

Carrera de Software
34
26/01/2023
• 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

Carrera de Software
35
26/01/2023
▪ 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.

Carrera de Software
36
26/01/2023
▪ Modelo Detallado: Este modelo puede procesar todas las
características del proyecto para construir una
estimación. Introduce dos características principales:
▪ Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases
se ven más afectadas que otras por los atributos. El modelo
detallado proporciona un conjunto de multiplicadores de
esfuerzo para cada atributo. Esto ayuda a determinar la
asignación del personal para cada fase del proyecto.
▪ Jerarquía del producto a tres niveles. Se definen tres niveles de
producto. Estos son módulo, subsistema y sistema. La
cuantificación se realiza al nivel apropiado, esto es, al nivel al
que es más susceptible la variación.
3

Carrera de Software
37
26/01/2023
Modelo Detallado: Estimación del esfuerzo
Fases de desarrollo: El desarrollo del software se lleva a
cabo a través de cuatro fases consecutivas:
requerimientos/planes, diseño del producto, programación
y prueba/integración.
1. Requerimientos/planes. Esta es la primera fase del ciclo de
desarrollo. Se analiza el requerimiento, se muestra un Plan de
Producto y se genera una especificación completa del
producto. Esta fase consume del 6% al 8% del esfuerzo
nominal Kn, y dura del 10% al 40% del tiempo nominal de
desarrollo td. Estos porcentajes dependen del modo y del
tamaño (de 2000 LOC a 512000 LOC).

Carrera de Software
38
26/01/2023
Modelo Detallado: Estimación del esfuerzo
2. Diseño del producto. La segunda fase del ciclo de desarrollo
COCOMO se preocupa de la determinación de la arquitectura del
producto y de las especificaciones de los subsistemas. Esta fase
requiere del 16% al 18% del esfuerzo nominal Kn, y puede
durar del 19% al 38% del tiempo nominal de desarrollo td.
3. Programación.La tercera fase del ciclo de desarrollo COCOMO
se subdivide en dos subfases: diseño detallado y prueba del
código. Esta fase requiere del 48% al 68% del esfuerzo
nominal Kn, y dura del 24% Al 64% del tiempo nominal de
desarrollo.
4. Prueba/Integración. Esta última fase consiste principalmente en
unir las diferentes unidades ya probadas. Se utiliza del 16% al
34% del coste nominal Kn y dura del 18% al 34% del td.

Carrera de Software
39
26/01/2023
Problemas con COCOMO I
▪ ¿Cuál de los modelos aplica al software que queremos
estimar?
▪ La medición por líneas de código no es válida para orientación
a objetos; entre otras cosas por la "reusabilidad" y la
herencia, características de este paradigma (e.g., puede
implicar importante aumento en productividad; pero no en
líneas de código).
▪ COCOMO I excluye las siguientes actividades:
▪ Administración
▪ Gastos generales
▪ Viajes y Otros Costos Secundarios
▪ Factores del entorno de trabajo
▪ COCOMO I asume un modelo básico de proceso de cascada
▪ 30% diseño;
▪ 30% codificación;
▪ 40% integración y pruebas.

Carrera de Software
40
26/01/2023
4 diferentes modelos:
▪ Modelo De Composición De la Aplicación: prototipado, uso de
componentes existentes, basado en “Puntos de Objetos”.
▪ Modelo de Diseño inicial: etapa del diseño de la arquitectura,
más cercano a COCOMO original, utiliza Puntos de Función
como estimación del tamaño.
▪ Modelo de Reuso: Usado para calcular el esfuerzo de integrar
componentes reutilizables.
▪ Modelo Post-Arquitectura: Para la etapa de desarrollo
propiamente dicha y mantenimiento; usa FP o LOCs como
medida del tamaño; modelo de COCOMO II mas detallado.
COnstructive COst MOdel II
B. Boehm (1995)

Carrera de Software
41
26/01/2023
Fases Del Ciclo de Vida
Plans &
Requirements
Product
Design
Detailed
Design
Code
& Unit Test
Imple-
mentatio
n
Operations &
Maintenance
Phase
out
Inception Elaboration Construction Transition
LCR
SRR
PDR
CDR
UTC
SAR
Integration
& Test
IRR
LCO
LCA
IOC
PRR
Early Design Model Post Architecture Model
COCOMO II estimation endpoints
Waterfall
RUP

Carrera de Software
42
26/01/2023
Hitos (Milestones)
▪ Hitos del Modelo Cascada
▪ LCR = Revisión de los Conceptos del Ciclo de vida
▪ SRR = Revisión de los Requisitos del Software
▪ PDR = Revisión del Diseño del Producto
▪ CDR = Revisión de Diseño Crítico (walkthrough design)
▪ UTC = Satisfacción de los Criterios de las Pruebas de Unidad
▪ SAR = Revisión de la aceptación del software
▪ Hitos del Desarrollo de Procesos RUP :
▪ IRR = Revisión de la preparación para el Inicio
▪ LCO = Revisión de los Objetivos del Ciclo de Vida
▪ LCA = Revisión de la Arquitectura del Ciclo de Vida
▪ IOC = Capacidad Inicial de las Operaciones
▪ PRR = Revisión de la Liberación Del Producto

Carrera de Software
43
26/01/2023
▪ Modelo de Reuso. Usado para calcular el esfuerzo de integrar
B. Boehm (1995)
1

Carrera de Software
44
26/01/2023
Modelo De Composición De la Aplicación
Assess Object
Counts
Clasificación de niveles de
complejidad
Asignar un peso de complejidad
a cada objeto
Determinar puntos de objeto
(object points)
Calcular Nuevos Object
Points
Calcular la tasa de
Productividad
Calcular el esfuerzo en
personas-meses.
Se modela el esfuerzo
requerido para desarrollar
sistemas que se crean a
partir de componentes
reutilizables.
Se utiliza durante las primeras etapas de la
ingeniería de software, cuando la creación
de prototipos de interfaces de usuario, la
consideración del software y la interacción
del sistema y la evaluación del rendimiento
son primordiales.

Carrera de Software
45
26/01/2023
Assess object counts: Estime la cantidad de pantallas, informes y
componentes 3GL que compondrán esta aplicación.
Clasificación de niveles de complejidad:
o Sencillo
o Medio
o difícil
Asignar peso de complejidad a cada objeto:
Los pesos se utilizan para tres tipos de objetos
o Pantalla
o Reporte
o Componentes 3GL

Carrera de Software
46
26/01/2023
Determinar puntos de objeto (object points): Agregue todas las instancias de
objetos ponderados para obtener un número y esto se conoce como
recuento de puntos de objeto.
Calcular Nuevos Object Points: Tenemos que estimar el porcentaje de
reutilización a conseguir en un proyecto. Dependiendo del porcentaje de
reutilización, se calculan los puntos de nuevo objeto (NOP).
Object Points * (100 - %reuse)
NOP = ---------------------------------------------
100
NOP son los puntos de objeto que deberán desarrollarse y difieren del
recuento de puntos de objeto porque puede haber reutilización (porcentaje
del desarrollo del Producto que se logra aprovechando la existencia del
esfuerzo de diseño o desarrollo del componente existente).

Carrera de Software
47
26/01/2023
Calcular la tasa de Productividad: La tasa de productividad se puede calcular
como:
Productivity rate (PROD) = NOP/Person month
Calcular el esfuerzo en personas-meses: Cuando se conoce PROD, podemos
estimar el esfuerzo en meses-persona como:
NOP
Effort in PM = ------------
PROD

Carrera de Software
48
26/01/2023
Considere un proyecto de aplicación de base de datos con las siguientes
características:
➢ La aplicación tiene 4 pantallas con 4 vistas cada una y 7 tablas de datos para
3 servidores y 4 clientes.
➢ La aplicación puede generar dos informes de 6 secciones cada uno a partir
de 7 tablas de datos para dos servidores y 3 clientes. Hay un 10% de
reutilización de puntos de objeto.
➢ La experiencia y la capacidad del desarrollador en un entorno similar es baja.
La madurez de la organización en términos de capacidad también es baja.
Calcule el recuento de puntos del objeto, los puntos del nuevo objeto y el
esfuerzo para desarrollar dicho proyecto.
Ejemplo: Modelo De Composición De la Aplicación

Carrera de Software
49
26/01/2023
No. de vistas
contenidas en
una pantalla
Total<4
(<2 servidores
<3 clientes)
Total<8
(2-3 servidores
3-5 clientes)
Total 8+
(>3 servidores
>5 clientes)
<3 Simple Simple Medium
3-7 Simple Medium Difficult
>8 Medium Difficult Difficult
No. de
secciones
contenidas en
un reporte
Total<4
(<2 servidores
<3 clientes)
Total<8
(2-3 servidores
3-5 clientes)
Total 8+
(>3 servidores
>5 clientes)
0 o 1 Simple Simple Medium
2 o 3 Simple Medium Difficult
4+ Medium Difficult Difficult
Solución: Echemos un vistazo a las tablas para pantallas, informes, ponderaciones
de complejidad para cada nivel.

Carrera de Software
50
26/01/2023
ObjectType Simple
Complexity
Medium
Complexity
Difficult
Complexity
Screen 1 2 3
Report 2 5 8
3GL - - 10
• Este proyecto se incluye en la categoría de modelo de estimación de composición de
aplicaciones.
• Número de pantallas = 4 con 4 vistas cada una
• Número de informes = 2 con 6 secciones cada uno
• Desde la Tabla de esta slide sabemos que cada pantalla será de complejidad media y
cada informe será de complejidad difícil.
• Usando la Tabla de pesos de complejidad, podemos calcular el recuento de puntos del
objeto
= 4 x 2 + 2 x 8 = 24

Carrera de Software
51
26/01/2023
Experiencia y capacidad
del desarrollador
PROD (NOP/PM)
Very low 4
Low 7
Nominal 13
High 25
Very high 50
Usando la fórmula NOP se calcula como:
NOP = 24 * (100-10) /100=21.6
El valor bajo de la productividad se da en la tabla de productividad
anterior = 7
Esfuerzo en PM = NOP / PROD = 21.6 / 7 = 3.086 PM

Carrera de Software
52
26/01/2023
B. Boehm (1995)
2

Carrera de Software
53
26/01/2023
Modelo de Diseño Inicial
▪ Las estimaciones pueden realizarse cuando se ha
llegado a un acuerdo sobre los requerimientos.
▪ Basada en una fórmula estándar
E = A x SizeB x M
▪ M = producto de todos los multiplicadores;
▪ A = 2.94 (calibración inicial), 2.5 (for COCOMO II.2000)
predefined
▪ Size en KLOC,
▪ B varía desde 1.1 to 1.24 desde 0.91 hasta 1.23
dependiendo de los factores de escala (for COCOMO II.2000).

Carrera de Software
54
26/01/2023
Factores de Escala B
▪ PREC = Precedencia (familiaridad con la aplicación que se
va a desarrollar)
▪ FLEX = Flexibilidad del Desarrollo
▪ RESL = Proceso de Resolución del Riesgo
▪ TEAM = Cohesión del Equipo
▪ PMAT = Madurez del Proceso
▪ El grado de RESL y TEAM es el promedio subjetivo de las
características mencionadas posteriormente.
▪ PMAT es evaluado en base a los niveles de madurez del
SEI.

Carrera de Software
55
26/01/2023
Factores de Escala B

Carrera de Software
56
26/01/2023
If B=1.0, then Linear relationship b/w Effort & Size.
If B ≠ 1.0, then Non-Linear relationship b/w Effort & Size.
If B<1.0, then the rate of increase of effort decreases as the size of
the product increases.
If B>1.0, then the rate of increase of effort increases as the size of
the product increases.
B = 0.91 + 0.01 * (Sum of rating on scaling factors for the project)
When all the scaling factors of a project are rated as extra high,
then the best value of B= 0.91 (for COCOMO II.2000)
when all the scaling factors of a project are rated as very low,
Then the worst value of B= 1.23 (for COCOMO II.2000)
Hence, the value of B may vary from 0.91 to 1.23
Cálculo del Factor de Escala B

Carrera de Software
57
26/01/2023
Multiplicadores M
▪ RCPX = Confiabilidad y complejidad de producto.
▪ RUSE = Desarollo pensando en reutilización
▪ PDIF = Dificultad de la Plataforma
▪ PERS = Capacidad del Personal
▪ PREX = Experiencia del Personal
▪ FCIL = Recursos disponibles para el desarrollo
▪ SCED =Calendario requerido para el desarrollo.
Early Design
Cost Drivers
Extra
Low
Very
Low
Low Nominal High Very
High
Extra
High
RCPX 0.73 0.81 0.98 1.0 1.30 1.74 2.38
RUSE - - 0.95 1.0 1.07 1.15 1.24
PDIF - - 0.87 1.0 1.29 1.81 2.61
PERS 2.12 1.62 1.26 1.0 0.83 0.63 0.50
PREX 1.59 1.33 1.12 1.0 0.87 0.71 0.62
FCIL 1.43 1.30 1.10 1.0 0.87 0.73 0.62
SCED - 1.43 1.14 1.0 1.0 1.0 -

Carrera de Software
58
26/01/2023
Ejemplo: Modelo de diseño inicial
Question: A software project of application generator category with estimated 50 KLOC has to
be developed. The scale factor (B) has low precedentness, high development flexibility and
low team cohesion. Other factors are nominal.
The early design cost drivers like platform difficult (PDIF) and Personnel Capability (PERS) are
high and others are nominal.
➢Calculate the Effort in person-months for the development of the project.
Early Design Cost
Drivers
Extra
Low
Very
Low
Low Nominal High Very
High
Extra
High
RCPX 0.73 0.81 0.98 1.0 1.30 1.74 2.38
RUSE - - 0.95 1.0 1.07 1.15 1.24
PDIF - - 0.87 1.0 1.29 1.81 2.61
PERS 2.12 1.62 1.26 1.0 0.83 0.63 0.50
PREX 1.59 1.33 1.12 1.0 0.87 0.71 0.62
FCIL 1.43 1.30 1.10 1.0 0.87 0.73 0.62
SCED - 1.43 1.14 1.0 1.0 1.0 -

Carrera de Software
59
26/01/2023
B = 0.91 + 0.01 * (Sum of rating on scaling factors for the project)
= 0.91 + 0.01 * (4.96 + 2.03 + 4.24 + 4.38 + 4.68)
= 0.91 + 0.01(20.29)=1.1129
= 2.5 * (50)1.1129 = 194.41 Person-months
here A=2.5 (for COCOMO II.2000) predefined
The 7 cost drivers are:
PDIF = high (1.29) PERS = high (0.83)
RCPX = nominal (1.0) RUSE = nominal (1.0)
PREX = nominal (1.0) FCIL = nominal (1.0)
SCEO = nominal (1.0)
Solución :
= 194.41 * [1.29 x 0.83]
= 194.41 x 1.07
= 208.155 Person months

Carrera de Software
60
26/01/2023
Modelo de Diseño Inicial
1. Estimación del tamaño
▪ Líneas de código
▪ Puntos de Función no
ajustados (IFPUG), los cuales
se los debe convertir a LOC.
2. Estimación de Esfuerzo (lo
obtiene el software)
3. Estimación de Tiempo (lo
obtiene el software)
http://softwarecost.org/tools/COCOMO/

Carrera de Software
61
26/01/2023
B. Boehm (1995)
3

Carrera de Software
62
26/01/2023
• Modelo de estimación más detallado.
• Se utiliza cuando se ha completado una arquitectura de ciclo de
vida del software.
• Se utiliza en el desarrollo y mantenimiento de productos de
software en los sectores de generación de aplicaciones, integración
de sistemas o infraestructura.
Donde
EM : Effort multiplier, el cual es el producto de 17 cost drivers.
PMnominal = Effort del Proyecto en person-months.
❑Lines of Codes Counting Rules
❑Function Points
❑Cost Drivers
Modelo Post-Arquitectura

Carrera de Software
63
26/01/2023
Cost
Drivers
of
Post
Architecture
• Required Software Reliability (RELY)
• Database Size (DATA)
• Product Complexity (CPLX)
• Documentation (DOCU)
• Required Reusability (RUSE)
Product
Attributes
• Execution Time Constraint (TIME)
• Platform Volatility (PVOL)
• Main Storage constraint (STOR)
Computer
Attributes
• Analyst Capability (ACAP)
• Personnel Continuity (PCON)
• Programmer Experience (PEXP)
• Programmer Capability (PCAP)
• Analyst Experience(AEXP)
• Language & Tool Experience (LTEX)
Personnel
Attributes
• Use of Software tools (TOOL)
• Required development schedule (SCED)
• Site Locations & Communications Technology b/w sites
(SITE)
Project
Attributes

Carrera de Software
64
26/01/2023
Cost Drivers of Post Architecture
Added Cost Drivers
7 cost drivers
▪ DOCU
▪ RUSE
▪ PVOL
▪ PLEX
▪ LTEX
▪ PCON
▪ SITE
Deleted Cost Drivers
5 Cost Drivers
• VIRT
• TURN
• VEXP
• LEXP
• MODP

Carrera de Software
65
26/01/2023
Cost Drivers Very Low Low Nominal High Very High Extra High
RELY 0.75 0.88 1.00 2.48 1.24 0.00
DATA 0.93 1.00 2.03 2.03 0.00
CPLX 0.75 0.88 1.00 2.83 1.41 0.00
RUSE 0.91 1.00 2.19 1.10 0.00
DOCU 0.89 0.95 1.00 3.12 1.56 0.00
TIME 1.00 1.11 1.31 1.67
STOR 1.00 1.06 1.21 1.57
PVOL 0.87 1.00 1.15 1.30
ACAP 1.50 1.22 1.00 0.83 0.67
PCAP 1.37 1.16 1.00 0.87 0.74
PCON 1.24 1.10 1.00 0.92 0.84
AEXP 1.22 1.10 1.00 0.89 0.81
PEXP 1.25 1.12 1.00 0.88 0.81
LTEX 1.22 1.10 1.00 0.91 0.84
TOOL 1.24 1.12 1.00 0.86 0.72
SITE 1.25 1.10 1.00 0.92 0.84 0.78
SCED 1.29 1.10 1.00 1.00 1.00
17
Cost
Drivers

Carrera de Software
66
26/01/2023
Estimación del Tiempo de desarrollo
El tiempo de desarrollo se puede calcular usando PMadjusted
como factor clave y la ecuación es :
Donde
= constant, provisionally set to 3.67, B = Scaling factor
TDEVnominal = calendar time in months with a scheduled constraint
PMadjusted = Estimated effort in Person months (after adjustment)
Size can be measured in any unit and the model can be calibrated
accordingly. However, COCOMO II details are:
I. Application composition model uses the size in object points.
II. The other two models use size in KLOC.
Size Measurement

Carrera de Software
67
26/01/2023
Estimación del Tiempo de desarrollo
▪ SCED%: Cronograma requerido para el desarrollo
▪ Este factor mide la restricción en los plazos de tiempo
impuesta al equipo de trabajo.
▪ Los valores se definen como un porcentaje de extensión o
aceleración de plazos con respecto al valor nominal.
▪ Acelerar los plazos produce más esfuerzo en las últimas etapas del
desarrollo, en las que se acumulan más temas a determinar por la
escasez de tiempo para resolverlos tempranamente.
▪ Por el contrario una relajación de los plazos produce mayor esfuerzo
en las etapas tempranas donde se destina más tiempo para las
tareas de planificación, especificación, validación cuidadosa y
profunda.
▪ El rango de valores posibles de SCED va desde 75% al 160%.

Carrera de Software
68
26/01/2023
Ejemplo: Modelo Post-Arquitectura
Enunciado: A software project of application generator category with estimated 50
KLOC has to be developed. The scale factor (B) has low precedentness, high
development flexibility and low team cohesion.
The identified 17 Cost drivers are high reliability (RELY), very high database size (DATA),
high execution time constraint (TIME), very high analyst capability (ACAP), high
programmers capability (PCAP). The other cost drivers are nominal.
➢Calculate the effort in Person-Months for the development of the project.
Here B = 1.1129
PMnominal = 194.41 Person-months
= 194.41 x (1.15 x 1.19 x 1.11 x 0.67 x 0.87)
= 194.41 x 0.885
= 172.05 Person-months
Solución :

Carrera de Software
69
26/01/2023
Contenido:

Carrera de Software
70
26/01/2023
Objetivo.
▪ Dado que ya tenemos la
planificación temporal
del proyecto, que
responde a:
▪ ¿Qué se hará?,
▪ ¿Quién lo hará?, y
▪ ¿Cuándo lo hará?
▪ ¿Qué recursos son
necesarios?
▪ Nos quedan unas
preguntas a responder:
▪ ¿Cuánto costará?
▪ ¿Cómo se aplicara el
recurso “capital”?

Carrera de Software
71
26/01/2023
¿Por qué?
▪ El dinero es importante
en el mundo
empresarial.
▪ Nuestros proyectos
viven en ese contexto.
▪ Las empresas tienen
muchos proyectos
pendientes, el coste es
un criterio de selección.

Carrera de Software
72
26/01/2023
El punto de partida...
▪ Disponemos de la
programación del
proyecto.
▪ Disponemos de la
aplicación de recursos
en cada instante.
Tarea: Especifica
Necesidades
Recursos: …
Duración: 2 semanas
Tarea: Diseño
Programas
Recursos: …
Tarea: Diseño B.D.
Recursos: …
Tarea: Realización
Esquema
Recursos: …
Tarea: Codificación
Program.
Recursos: …
Tarea: Pruebas
Recursos: …
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 1 0
TAREAS
Especificar Necesidades
Diseño Programas
Diseño Base de Datos
Realización Esquema
Codificación Programas
Pruebas
0 2 4 6 8 10 12 14 16
SEMANAS

Carrera de Software
73
26/01/2023
Pasos en la creación de un estudio económico.
▪ Calculo del flujo de caja:
▪ Valoración unitaria del coste de cada recurso,
▪ Calculo del flujo de pagos,
▪ Calculo del flujo de ingresos,
▪ Obtención del flujo de caja.
▪ Estudio financiero:
▪ Volumen de fondos a comprometer ,
▪ Actualización del flujo de caja.

Carrera de Software
74
26/01/2023
Los costes desde el punto de vista del proyecto.
▪ Directos:
▪ son aquellos que se pueden asignar al proyecto de forma
clara. Por ejemplo:
▪ Horas trabajadas, fungibles consumidos...
▪ Indirectos:
▪ Es difícil evaluar en que medida han aportado valor al
proyecto, suelen ser costes fijos de la empresa. Por ejemplo:
▪ Electricidad consumida, telefonista de la empresa...

Carrera de Software
75
26/01/2023
Valoración unitaria del coste de cada recurso.
▪ Se tiene que repercutir en los proyectos todos los
costes.
▪ Los costes directos son fáciles de aplicar.
▪ Los costes indirectos se suelen repercutir ponderándolos
con los costes directos.
▪ Así tendremos una valoración media del coste de los
informáticos y no sólo su coste directo.

Carrera de Software
76
26/01/2023
RecursosMes 1 2 3 4 5 6 7 8 9
Analista
Diseñador
Programador
Consultor
Instalador
Calculo del flujo de caja en un proyecto.
▪ Empezamos por fijar la
periodicidad de los
pagos:
▪ Días,
▪ Semanas o Meses.
▪ Agrupamos el uso de
recursos por periodos,
(tabla de doble entrada)
▪ recurso,
▪ periodos.

Carrera de Software
77
26/01/2023
Definición del flujo de pagos.
▪ Secuencia de pagos que se realizan en el proyecto:
▪ Por el consumo de recursos.
▪ En cada periodo.
Proyecto

Carrera de Software
78
26/01/2023
Obtención del flujo de pagos:
RecursosMes Coste
indivi.
1 2 3 4 5 6 7 8 9
Analista C1 R11 R12 R13 R14 R15 R16 R17 R18 …
Diseñador C2 R21 R22 R23 R24 R25 R26 R27 R28 …
Programador C3 R31 R32 R33 R34 R35 R36 R37 R38 …
Consultor C4 R41 R42 R43 R44 R45 R46 R47 R48 …
Instalador C5 R51 R52 R53 R54 R55 R56 R57 R58 …
Flujo de Pagos
R
i1
*C
i
R
i2
*C
i
R
i3
*C
i
R
i4
*C
i
R
i5
*C
i
R
i6
*C
i
R
i7
*C
i
R
i8
*C
i
…
▪ En cada periodo se acumula el total de recursos
multiplicado por su coste.

Carrera de Software
79
26/01/2023
Representación de los pagos acumulados (S).
Gasto acumulado
0
5
10
15
20
0 1 2 3 4 5 6 7 8 9
Planificado

Carrera de Software
80
26/01/2023
Calculo del flujo de ingresos.
▪ Conjunto de ingresos percibidos por la empresa que
desarrolla el proyecto, como consecuencia de éste.
Proyecto

Carrera de Software
81
26/01/2023
Obtención del flujo de ingresos.
▪ En cada periodo se acumula el total de ingresos
percibidos.
RecursosMes 1 2 3 4 5 6 7 8 9
Cliente I11 I12 I13 I14 I15 I16 I17 I18 …
Subvenciones I21 I22 I23 I24 I25 I26 I27 I28 …
Comisiones I31 I32 I33 I34 I35 I36 I37 I38 …
… I41 I42 I43 I44 I45 I46 I47 I48 …
Flujo de
Ingresos
Ii1 Ii2 Ii3 Ii4 Ii5 Ii6 Ii7 Ii8 …

Carrera de Software
82
26/01/2023
Obtención del flujo de caja.
▪ Se obtiene sustrayendo del flujo de Ingresos el flujo de
pagos.
▪ Se llama flujo de caja por poderse representar
mentalmente como el dinero que hay en la caja virtual
del proyecto.
Meses... 1 2 3 4 5 6 7 8 9
Flujo de ingresos I1 I2 I3 I4 I5 I6 I7 I8 …
Flujo de Pagos P1 P 2 P3 P4 P5 P6 P7 P8 …
Flujo de Caja I1-
P1
I2-
P2
I3-
P3
I4-
P4
I5-
P5
I6-
P6
I7-
P7
I8-
P8
…

Carrera de Software
83
26/01/2023
Calcular el flujo de caja del siguiente proyecto.
A 2A
B 1A
C 2A
D 1P
E 1A
F 4P
G 1A
H 2P
I 2P
J 2P
K 1P
1 2 3 4 5 6 7 8 9 10

Carrera de Software
84
26/01/2023
Teniendo en cuenta:
▪ Coste de los analistas:
▪ 400 Euros por periodo.
▪ Coste de los programadores:
▪ 200 Euros por periodo.
▪ Se cobrará 10.000 Euros cuando se finalice la tarea J.

Carrera de Software
85
26/01/2023
Representación gráfica.
-10000
-5000
0
5000
10000
15000
Flujo pagos 800 1000 1200 900 1100 600 400 400 200 200
Flujo Ingresos 0 0 0 0 0 0 0 1000 0 0
Flujo de caja -800 -1000-1200 -900 -1100 -600 -400 9600 -200 -200
Acumulado -800 -1800-3000-3900-5000-5600-6000 3600 3400 3200

Carrera de Software
86
26/01/2023
Estudio financiero:
▪ El dinero es difícil de conseguir en la empresa,
▪ Cuando se utiliza siempre se le compara con el coste
de oportunidad.
▪ Esto nos lleva a tener que observar el proyecto desde
estos dos puntos de vista:
▪ Volumen de fondos que compromete,
▪ Valor actualizado del flujo de caja.

Carrera de Software
87
26/01/2023
Volumen de fondos a comprometer.
▪ Los proyectos se insertan en la actividad financiera de
la empresa:
▪ suponen un consumo de capital, un retorno, y
▪ unas necesidades de capital disponible para hacer frente a
los pagos.
▪ Nosotros podemos mostrar la situación prevista, los
financieros tendrán que adaptarla a la realidad de la
empresa.

Carrera de Software
88
26/01/2023
Volumen de fondos a comprometer, Ejemplo:
▪ Tenemos claro un negocio,
▪ necesitamos pagar 2 millones de pesetas semanales durante
un año,
▪ obtendremos 400 millones de aquí a un año,
▪ El riesgo es nulo.
▪ A todos se nos muestra claro el negocio.
▪ ¿Os parece posible?
▪ Es de difícil realización.

Carrera de Software
89
26/01/2023
¿Cuanto dinero tiene que disponer la empresa?
-10000
-5000
0
5000
10000
15000
Flujo pagos 800 1000 1200 900 1100 600 400 400 200 200
Flujo Ingresos 0 0 0 0 0 0 0 10000 0 0
Pagos Acumul. 800 1800 3000 3900 5000 5600 6000 6400 6600 6800
Flujo de caja -800 -1000 -1200 -900 -1100 -600 -400 9600 -200 -200
Acumulado -800 -1800 -3000 -3900 -5000 -5600 -6000 3600 3400 3200

Carrera de Software
90
26/01/2023
¿Cuanto dinero tiene que disponer la empresa?
-4000
-2000
0
2000
4000
6000
8000
Flujo pagos 800 1000 1200 900 1100 600 400 400 200 200
Flujo Ingresos 0 0 2500 0 2500 0 0 4000 0 0
Pagos Acumul. 800 1800 3000 3900 5000 5600 6000 6400 6600 6800
Flujo de caja -800 -1000 1300 -900 1400 -600 -400 3600 -200 -200
Acumulado -800 -1800 -500 -1300 100 -600 -1000 2600 2400 2200

Carrera de Software
91
26/01/2023
Realizamos el mismo trabajo, ¿Cuál es la mejor
opción?
▪ ¿De cuanto capital
podemos disponer para
hacer frente al
proyecto?
▪ ¿Los euros son todos
iguales: los de un mes y
los del siguiente?
▪ ¿y el riesgo?

Carrera de Software
92
26/01/2023
Actualización del flujo de caja.
▪ Para poder comparar la rentabilidad de los proyectos,
es necesario que todos se encuentren en las mismas
condiciones.
▪ Se utilizan diversos métodos:
▪ El Valor Actual Neto: VAN
▪ El Pago equivalente por periodo
▪ La tasa interna de rentabilidad: TIR
▪ Nos vamos a centrar en el VAN.

Carrera de Software
93
26/01/2023
El valor del dinero.
▪ ¿Quien me presta 100 Euros y se los reintegro dentro
de un año?
▪ ¿Quien me presta 100 Euros y le reintegro 300 dentro
de un año?
▪ Evidentemente, disponer del dinero hoy tiene un
coste, aunque sea el coste de oportunidad.

Carrera de Software
94
26/01/2023
La tasa de interés “i”
▪ Los financieros o banco
que nos adelanten el
dinero nos marcarán un
retorno por período,
así:
▪ Si entrego 100 Euros hoy
(Actual),
▪ me reintegran 110 Euros
en un año (Futuro).
▪ Llamamos interés a la
razón entre el valor
futuro y el valor actual.
▪ En %: el 10%
1
,
0
100
110
=
=
=
Actual
Futuro
i

Carrera de Software
95
26/01/2023
Actualización de un importe en un periodo cualquiera.
▪ El valor actual de un importe a fin del primer periodo
es:
▪ Un valor futuro en el período n se actualiza aplicando:
▪ Como se puede verificar por inducción.
( ) 1
1 1
−
+

= i
futuro
Actual
( ) n
n i
futuro
Actual
−
+

= 1

Carrera de Software
96
26/01/2023
El valor de 1000 Euros actuales a un interés del 20%
0
1000
2000
3000
4000
5000
6000
7000
Valor
en
Euros
0 1 2 3 4 5 6 7 8 9 10
Años

Carrera de Software
97
26/01/2023
Valor de 1000 Euros vistos desde el momento actual.
0
200
400
600
800
1000
1200
0 5 10 15 20 25 30 35 40 45 50
Valor Actual importe instante n

Carrera de Software
98
26/01/2023
Comparación del flujo de caja y actualizado en
un proyecto
0
200
400
600
800
1000
1200
0
5
1
0
1
5
2
0
2
5
3
0
3
5
4
0
4
5
5
0
Valor Actual importe instante n

Carrera de Software
99
26/01/2023
El acumulado actualizado de un proyecto.
-2000
0
2000
4000
6000
8000
10000
1 2 3 4 5 6 7 8 9 10
Flujo de Caja
Valor actual

Carrera de Software
100
26/01/2023
El efecto de los retrasos en el proyecto
▪ Suponer que se produce un retraso en el proyecto:
▪ ¿Cómo afecta al flujo de caja?
▪ ¿Cómo afecta al flujo de caja actualizado?
▪ ¿Cómo afecta a los acumulados actualizados?

Carrera de Software
101
26/01/2023
Elaboración del presupuesto del proyecto
▪ La función del presupuesto es la de “asignar recursos”,
determinar la fuente u origen de los mismos y asegurar el
desarrollo normal del proyecto. Por lo tanto vemos que existe
una notoria interdependencia entre presupuesto y actividades.
▪ El presupuesto comprende los siguientes rubros principales:
▪ Costo de personal
▪ Viáticos
▪ Locales
▪ Material y equipo
▪ Gastos de funcionamiento
▪ Imprevistos
▪ Beneficios

Carrera de Software
102
26/01/2023
Ejemplo:
PRODUCTO CANTIDAD VALOR
UNITARIO
VALOR TOTAL
Laptops 2 $800 $1600
Smartphones 2 $350 $700
Total 4 $1150 $2300
COSTO HARDWARE
MENSUAL UNI.
TIEMPO VALOR TOTAL
Est. Egresado 2 $425 4 meses $3400
Total 2 $425 4 meses $3400
GASTOS DE TALENTO HUMANO

Carrera de Software
103
26/01/2023
Ejemplo:
MENSUAL UNI.
TIEMPO VALOR TOTAL
Internet fijo 2 $35 4 meses $280
Movilización 2 $20 4 meses $160
Suministros 1 $40 4 meses $160
Electricidad 2 $10 4 meses $80
Total $105 $680
OTROS GASTOS

Carrera de Software
104
26/01/2023
▪ También comprende el costo de cada una de las
actividades, generalmente se representa en una tabla
por rubros que al sumarse genera el total del dinero
presupuestado para el proyecto.
▪ El presupuesto guarda total relación con las
actividades del proyecto, dichas actividades deben
agruparse acorde a su naturaleza en rubros, a
continuación se presenta un formato ejemplo de
presupuesto para un proyecto.

Carrera de Software
105
26/01/2023
Elaboración del presupuesto del proyecto.
Ejemplo:
Tomado de: http://contenidos.sucerman.com/nivel2/proyectos/unidad2/leccion4.html

Carrera de Software
106
26/01/2023
Contenido:

Carrera de Software
107
26/01/2023
El Fracaso y sus Causas.
▪ Los proyectos Informáticos fracasan por:
▪ El SW nunca llega a funcionar.
▪ No se cumplen los plazos de entrega.
▪ No cumple con las funcionalidades esperadas.
▪ Razones:
▪ La complejidad era muy alta (comunicaciones, interrelación
con otros sistemas, etc..)
▪ Incertidumbre. No se tenia una idea clara de lo que se quería
obtener.

Carrera de Software
108
26/01/2023
Definición de Riesgo
▪ Riesgo es un problema potencial.
▪ Un problema es un riesgo materializado.
▪ Por problema entendemos una situación no deseable
en la que necesitaremos tiempo o dinero para
solucionarla.
▪ Un problema potencial se caracteriza por:
▪ La probabilidad de que ocurra (0<P<1)
▪ Una perdida asociada, cuantificable
▪ ...

Carrera de Software
109
26/01/2023
Circunstancias no previstas / intangibles
Un proyecto puede
convertirse en una
serie de reacciones y
eventos no esperados
• Las circunstancias no previstas ponen en riesgo el
cumplimiento de los objetivos del proyecto
• El reto para el responsable del proyecto es prevenir, anticipar
y manejar tales circunstancias
• El proyecto debe contener los elementos para el manejo y
reducción de riesgos:
• Plan de contingencia
• Diseño del elemento contractual
• Capacidad de negociación
• Alternativas técnicas
• Recursos externos a los originales

Carrera de Software
110
26/01/2023
Formas en las que se afrontan las causas de
las desviaciones
▪ Podemos observar que hay dos puntos de vista
respecto a la gestión de riesgos en P.I.
▪ muchas de las causas de fracaso se los P.I. son comunes.
▪ Se identifican e intenta situar a la organización en una situación
fuerte.
▪ cada proyecto tiene unos riesgos específicos,
▪ hay que gestionar los riesgos de forma especifica en cada caso.
▪ Realmente son visiones complementarias del
problema

Carrera de Software
111
26/01/2023
Causas comunes de fracaso(1)
(Caper Jones)
▪ Ambigüedad del objetivo.
▪ Requerimientos Cambiantes.
▪ Tardó demasiado para el mercado.
▪ Estimaciones inadecuadas.
▪ Oficinas de trabajo muy llenas.
▪ Presión excesiva de la planificación.
▪ Fricciones:
▪ Contratistas y Clientes.
▪ Directores Empresa y SW.
▪ Salarios inadecuados.

Carrera de Software
112
26/01/2023
(Caper Jones)
▪ Falta de especialización.
▪ Inadecuada estimación de la calidad
▪ Sistema de adquisición de paquetes inadecuado
▪ Inadecuada política de estándares
▪ Herramientas y métodos inadecuados
▪ Inadecuado control de configuración.
▪ Documentación inadecuada
▪ Falta de reutilización de código, datos, pruebas,
interfaces

Carrera de Software
113
26/01/2023
(Caper Jones)
▪ Bajo nivel de satisfacción de los usuarios.
▪ Curriculum inadecuados en los desarrolladores.
▪ Costes altos de mantenimiento.
▪ Ciclos de vida parciales.
▪ Inversiones pobres en tecnología.
▪ El síndrome de la bala de plata.
▪ Baja productividad.

Carrera de Software
114
26/01/2023
Causas especificas.
Gestión de los Riesgos.
▪ “Cuando un proyecto tienen éxito, no es porque no
haya tenido problemas, sino porque se han superado.”
▪ Podemos actuar de dos formas:
▪ Reactivamente:
▪ esperamos que aparezcan los problemas y los solucionamos.
▪ Proactivamente:
▪ Tratamos de identificar problemas potenciales y los atajamos

Carrera de Software
115
26/01/2023
Primer análisis de riesgos
▪ Identificar los riesgos más probables para el proyecto
▪ Estimar el costo / impacto si el riesgo se vuelve un
problema
▪ Identificar las señales que indiquen que el riesgo se
está volviendo un problema
▪ La intención es balancear los beneficios con sus riesgos
▪ Un riesgo no forzosamente es algo malo.

Carrera de Software
116
26/01/2023
Evaluación y toma de decisión de seguir
adelante
▪ En base a lo anterior se analiza si:
▪ ¿Los objetivos son viables y medibles?
▪ ¿Son factibles?
▪ ¿Son los riesgos demasiado altos?
▪ ¿Es el costo de los objetivos razonable?
▪ ¿Las personas implicadas están de acuerdo y dispuestas?
▪ ¿Se justifica el proyecto?
▪ ¿Hay razones para cancelarlo?

Carrera de Software
117
26/01/2023
Elementos de la Gestión de Riesgos
1. Identificar los factores de Riesgo.
2. Evaluar la probabilidad y el efecto sobre el proyecto.
3. Desarrollo de estrategias para mitigar los riesgos.
4. Monitorizar los factores de riesgo.
5. Invocar el plan de contingencias.
6. Gestionar la crisis.
7. Recuperarse de la crisis.
▪ Fairley, R. IEEE Software Mayo 1994

Carrera de Software
118
26/01/2023
Identificar los factores de Riesgo
▪ Se trata de visualizar el desarrollo y tomar notas de las
cosas “malas” que podrían ocurrirnos.
▪ Es aconsejable el disponer de una lista con los
problemas acaecidos en otros proyectos y revisarla.
▪ “Quien no conoce su pasado esta condenado a repetirlo”
1

Carrera de Software
119
26/01/2023
Identificar los factores de Riesgo
▪ Hay que diferenciar entre causa (factores de riesgo),
problema y síntomas.
▪ Todos los problemas potenciales no son malos,
realmente son los que hacen que este proyecto no se
haya realizado anteriormente.
▪ El mismo problema puede se visto como un reto, una
oportunidad o algo indeseable.

Carrera de Software
120
26/01/2023
Identificación de los riesgos
Reunir los stakeholders para revisar y adaptar una lista de
potenciales riesgos de requerimientos
▪ Para esto es necesario usar una lista inicial de riesgos comunes,
como por ejemplo:
▪ Falta de involucramiento del usuario.
▪ Expectativa del cliente poco realista.
▪ Los desarrolladores añaden funcionalidades innecesarias.
▪ Constante cambio de requerimientos.
▪ Pobre análisis del impacto cuando las necesidades cambian y evolucionan.
▪ Uso de nuevas técnicas o herramientas de requerimientos.
▪ Requisitos poco claros, ambiguos.
▪ Requisitos contradictorios (conflictivos).
▪ Falta de requisitos.
▪ Lluvia de ideas para identificar riesgos adicionales en base a la experiencia
del equipo, como de la cultura de la empresa y su medio ambiente

Carrera de Software
121
26/01/2023
Evaluar la probabilidad y el efecto sobre el
proyecto
▪ Evaluar la probabilidad de tener el problema.
▪ Evaluar los efectos sobre el proyecto.
▪ Clasificar los riesgos en base a la EXPOSICIÓN AL
RIESGO, que se calcula como:
▪ Probabilidad * Efecto
▪ Como consecuencia de esta clasificación habrán
riesgos importantes y otros menores.
2

Carrera de Software
122
26/01/2023
Evaluación de la probabilidad de que se de el
problema.
▪ No todos tienen la misma probabilidad.
▪ Aveces es difícil asignar una probabilidad a un
problema en concreto,
▪ Casos similares.
▪ Optimista, pesimista y lo mas probable.
▪ Recordar la ley de Murphy:
▪ “Si algo puede salir mal, saldrá mal.”
▪ Existen herramientas de simulación.

Carrera de Software
123
26/01/2023
Clasificación de los riesgos
▪ Analizar cada riesgo de acuerdo a su probabilidad y su impacto.
▪ La probabilidad. Riesgo estimado para causar un problema. Usar
una escala o rango como es:
a) Bajo: Remota posibilidad que el riesgo se realizará. Entre 0% - 25%.
b) Medio: Probabilidad moderada que ocurra el riesgo. Entre 26% - 74%.
c) Alto: Gran probabilidad o certeza de que el riesgo ocurra. Entre 75% ---
100%
▪ El impacto es el grado en que el riesgo afectan negativamente al
proceso de requisitos.
a) Bajo: Puede presentar algún impacto, insignificante.
b) Medio: Impacto manejable o marginal.
c) Alto: Impacto critico o catastrófico. Principales problemas que
necesitan ser analizados.
▪ Clasificar cada riesgo de acuerdo a cada dimensión (probabilidad e
impacto)

Carrera de Software
124
26/01/2023
Clasificación de los riesgos
Representar gráficamente las clasificaciones y
ponerse de acuerdo en los riesgos que se abordarán.
▪ Una forma de representar la clasificación final podría
ser:
Relación entre la
probabilidad e
impacto de los
riesgos

Carrera de Software
125
26/01/2023
Desarrollo de estrategias para mitigar los
riesgos
▪ Las estrategias pueden
ser de dos tipos:
▪ Plan de Acción.
▪ minimizamos o hacemos
desaparecer el riesgo.
▪ Plan de Contingencia.
▪ aceptamos el riesgo y
preparamos el plan por si
el problema se
materializa.
3

Carrera de Software
126
26/01/2023
Plan de Acción
▪ Minimizamos o hacemos desaparecer el riesgo.
▪ La acción se realiza antes de que pueda darse el
problema.
▪ Por ejemplo:
▪ Problema: Pueden aparecer dificultades al utilizar nuevas
herramientas.
▪ Acción: Contratamos a personas experimentadas con estas
herramientas.

Carrera de Software
127
26/01/2023
Plan de Acción – Mitigación de riesgos
Determinar las formas de controlar, evitar o mitigar los
posibles riesgos críticos
▪ Asignar cada riesgo crítico a un miembro del equipo quien
tendrá la responsabilidad de monitorear el riesgo. Identificar las
acciones que él o ella tendrá, los recursos necesarios para llevar
acabo las acciones, y la manera que él o ella comunicará las
acciones al equipo.
▪ Asegurar que el sponsor y el líder del equipo estén de acuerdo
con las acciones.
▪ Asegurarse que los miembros del equipo entienden como sus
acciones afectan sus requerimientos.
▪ Monitorear los riesgos a lo largo del desarrollo y gestión de
requisitos.
▪ Analizar y adicionar nuevos riesgos a los requerimientos como
ocurran, y actualizar la estrategia de mitigación de riesgo como
sea necesario.

Carrera de Software
128
26/01/2023
Algunos riesgos y estrategias que comúnmente ocurren
en los proyectos de desarrollo
Riesgos comunes en los
requerimientos
Estrategias de mitigación
Falta de participación del usuario
• Identificar a los interesados del producto.
• Crear un plan de participación de interesados.
• Usar técnicas de elicitación que atraigan a los usuarios en el
proceso
Expectativas poco realistas de los
clientes.
• Crear la visión del producto.
• Desarrollar modelos de alcance del proyecto.
• Validar requerimientos con prototipos operacionales.
Desarrolladores agregan
funcionalidades innecesarias .
• Crear la visión del producto.
• Priorizar requerimientos.
Constante cambio de
requerimientos.
• Desarrollar modelos de alcance.
• Crear una línea base para requerimientos y establecer
mecanismos de control de cambios.
Pobre análisis del impacto cuando las
necesidades cambian y evolucionan.
• Crear una línea base y seguimiento de requerimientos.
• Formalizar documentos de requerimientos.
Uso de nuevas técnicas o herramientas de
requerimientos.
• Adaptar los procesos de requerimientos para el
proyecto.
• Conducir una retrospectiva de los requerimientos.
Requisitos poco claros, ambiguos.
• Desarrollar la visión del producto.
• Desarrollar múltiples modelos de requerimientos.
• Validar los requerimientos.
Requisitos contradictorios
(conflictivos).
• Formalizar el documento de visión.
• Validar los requerimientos con el modelo de validación.
Falta de requisitos
• Desarrollar múltiples modelos de requerimientos.
• Verificar la falta de requerimientos con el modelo de
validación.

Carrera de Software
129
26/01/2023
Mitigar el riesgo en los requerimientos
▪ Los riesgos en los requerimientos son sucesos o
condiciones que ponen en peligro el desarrollo
satisfactorio del producto.
▪ Los riesgos deben ser evaluados, rastreados y
controlados a lo largo del proyecto, esto ocasiona que
se pueda tener un gran impacto de éxito en el
proyecto.
▪ Es necesario establecer estrategias que permitan
evaluar los requerimientos relacionados con el riesgo e
identificar acciones para evitar o minimizar estos
riesgos.

Carrera de Software
130
26/01/2023
Estrategia para mitigar el riesgo en los
requerimientos
▪ La estrategia para mitigar el riesgo en los
requerimientos, permite:
▪ Identificar los riesgos que podrían impedir el desarrollo
efectivo y la gestión de requisitos.
▪ Involucrar múltiples stakeholders que categorizan el riesgo
de cada requerimiento de acuerdo a su grado de ocurrencia
y a su impacto.
▪ Al equipo comunicar honestamente acerca de los
potenciales obstáculos.
▪ Identificar alternativas para administrar los riesgos por parte
del equipo.

Carrera de Software
131
26/01/2023
Ejemplo: catálogo de riesgos y estrategias de mitigación
Factor de riesgo Probabilidad Impacto
Estrategia de mitigación
Responsable
Falta de
disponibilidad del
rector para aclarar el
alcance
Media Alto Llevar a cabo un taller de
visionamiento con el actual
rector y crear modelos de
alcance en el taller.
Juan Peralta
(Gerente proyecto)
No involucramiento
del contratista
Media Alto Llevar a cabo una visita (por
ejemplo en el lugar de trabajo
hacer el seguimiento por un
medio día).
Llevar a cabo una entrevista con
el contratista cada cierto periodo
de tiempo.
María Piguave
(Analista).
Poco interés de las
secretarias de los
centros
Media Bajo Realizar un taller para indicar
las bondades de un sistema
automatizado.
Juan Peralta
(Gerente proyecto)
Poco interés de las
secretarias de
escuela
Alto Alto Realizar reuniones informativas
sobre el nuevo proceso
automatizado para resolver los
trámites de los estudiantes.
Juan Peralta
(Gerente proyecto) y
el sponsor del
proyecto.

Carrera de Software
132
26/01/2023
Plan de Contingencia
▪ Aceptamos el riesgo y preparamos el plan por si el
problema se materializa.
▪ Las actividades a realizar son las siguientes:
▪ Identificar las variables a monitorizar (factores de riesgo)
para detectar que el problema se ha materializado.
▪ Crear un plan de acción para la Crisis, consecuencia de este
problema.
▪ Planificar la recuperación de esta crisis.

Carrera de Software
133
26/01/2023
Monitorizar los factores de riesgo
▪ Se trata de los síntomas que hemos identificado en el
caso anterior, agrupados.
▪ Deberán de cuantificarse de forma precisa mediante
medidas objetivas y puntuales.
▪ Hay que disponer de un sistema de trazabilidad entre
los factores de riesgo y los problemas asociados, así
como los limites de control.
4

Carrera de Software
134
26/01/2023
Invocar el plan de contingencias
▪ Sí algún factor de riesgo excede los limites de control
habrá de tomarse las medidas previstas.
▪ Es habitual varios niveles limites,
▪ ante los primeros excesos se notifique el problema a nivel
operativo,
▪ si este no se corrige, se excede el siguiente limite, se pondrá
en marcha el plan de contingencia previsto.
5

Carrera de Software
135
26/01/2023
Gestionar la crisis
▪ El que la situación de crisis este prevista no quiere
decir que podamos relajarnos, más bien al contrario.
Deberemos estar más atentos al control de la crisis y
del resto.
▪ Puedes suceder que el plan de contingencia:
▪ funcione de acuerdo a lo previsto.
▪ fracase. En este caso pasaremos a una situación de crisis
(vista en el tema anterior)
6

Carrera de Software
136
26/01/2023
Recuperarse de la crisis
▪ Si el plan de contingencia ha ido de acuerdo a lo
previsto como si no, deberemos:
▪ Recompensar a las personas a las que se ha forzado a
trabajar más duro (ver tema anterior),
▪ Replanificar el proyecto con los retrasos y los costes que esa
situación hayan provocado.
7

Carrera de Software
137
26/01/2023
Final de la unidad
Y del curso…. !Muchas gracias
a todos!
Planificación financiera y
análisis de riesgos
Unidad 3

EP Unidad03: Planificación financiera y análisis de riesgos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a EP Unidad03: Planificación financiera y análisis de riesgos

Similar a EP Unidad03: Planificación financiera y análisis de riesgos (20)

Más de Franklin Parrales Bravo

Más de Franklin Parrales Bravo (20)

Último

Último (6)

EP Unidad03: Planificación financiera y análisis de riesgos