SlideShare una empresa de Scribd logo
1 de 137
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
5
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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)
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
9
26/01/2023
Medir lo que quiere el usuario.
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
10
26/01/2023
Estimar lo que costara
▪ Experiencia Individual
▪ Experiencia de Empresa
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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)
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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)
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
18
26/01/2023
Effort = a*(Size)b
DevTime = c*(Effort)d
“KLOC”
PM Personas Mes
M Meses
“MODELO BASICO”
Modelos de estimación COCOMO I
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
19
26/01/2023
Modelos de estimación COCOMO I
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.:
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
21
26/01/2023
Modelos de estimación COCOMO I
▪ 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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
24
26/01/2023
Cálculo de FAE Factores de Costo
Elaboración de Proyectos
Ph.D. Franklin Parrales
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).
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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:
Elaboración de Proyectos
Ph.D. Franklin Parrales
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)
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
30
26/01/2023
Continuación Ejemplo:
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Continuación Ejemplo:
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
36
26/01/2023
Modelos de estimación COCOMO I
▪ 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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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).
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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)
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
43
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)
1
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Modelo De Composición De la Aplicación
Elaboración de Proyectos
Ph.D. Franklin Parrales
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).
Modelo De Composición De la Aplicación
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Modelo De Composición De la Aplicación
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
49
26/01/2023
Ejemplo: Modelo De Composición De la Aplicación
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
50
26/01/2023
Ejemplo: Modelo De Composición De la Aplicación
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
51
26/01/2023
Ejemplo: Modelo De Composición De la Aplicación
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
52
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)
2
Elaboración de Proyectos
Ph.D. Franklin Parrales
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).
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
55
26/01/2023
Factores de Escala B
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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 -
Elaboración de Proyectos
Ph.D. Franklin Parrales
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 -
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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/
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
61
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)
3
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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%.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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 :
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
69
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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”?
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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: …
Duración: 4 semanas
Tarea: Diseño B.D.
Recursos: …
Duración: 2 semanas
Tarea: Realización
Esquema
Recursos: …
Duración: 1 semanas
Tarea: Codificación
Program.
Recursos: …
Duración: 7 semanas
Tarea: Pruebas
Recursos: …
Duración: 2 semanas
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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...
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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 …
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
…
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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?
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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?
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
102
26/01/2023
Elaboración del presupuesto del proyecto
Ejemplo:
PRODUCTO CANTIDAD VALOR
UNITARIO
VALOR TOTAL
Laptops 2 $800 $1600
Smartphones 2 $350 $700
Total 4 $1150 $2300
COSTO HARDWARE
PRODUCTO CANTIDAD VALOR
MENSUAL UNI.
TIEMPO VALOR TOTAL
Est. Egresado 2 $425 4 meses $3400
Total 2 $425 4 meses $3400
GASTOS DE TALENTO HUMANO
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
103
26/01/2023
Elaboración del presupuesto del proyecto
Ejemplo:
PRODUCTO CANTIDAD VALOR
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
104
26/01/2023
Elaboración del presupuesto del proyecto
▪ 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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
106
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
▪ ...
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
112
26/01/2023
Causas comunes de fracaso(2)
(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
Elaboración de Proyectos
Ph.D. Franklin Parrales
Carrera de Software
113
26/01/2023
Causas comunes de fracaso(3)
(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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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?
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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)
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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.
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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
Elaboración de Proyectos
Ph.D. Franklin Parrales
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

Más contenido relacionado

La actualidad más candente

IIS Unidad 3B Proceso de desarrollo de software
IIS Unidad 3B Proceso de desarrollo de softwareIIS Unidad 3B Proceso de desarrollo de software
IIS Unidad 3B Proceso de desarrollo de softwareFranklin Parrales Bravo
 
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWAREPSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWAREFranklin Parrales Bravo
 
AD Unidad3: Tecnologías de aplicaciones distribuidas
AD Unidad3: Tecnologías de aplicaciones distribuidasAD Unidad3: Tecnologías de aplicaciones distribuidas
AD Unidad3: Tecnologías de aplicaciones distribuidasFranklin Parrales Bravo
 
IIS Unidad1: Introducción a la Ingeniería de Software
IIS Unidad1: Introducción a la Ingeniería de SoftwareIIS Unidad1: Introducción a la Ingeniería de Software
IIS Unidad1: Introducción a la Ingeniería de SoftwareFranklin Parrales Bravo
 
Modelos de estimacion de software
Modelos de estimacion de softwareModelos de estimacion de software
Modelos de estimacion de softwareManuel Galindo Sanz
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativoIngenierosD
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del softwareJohan Prevot R
 
eXtreme programming (XP) - An Overview
eXtreme programming (XP) - An OvervieweXtreme programming (XP) - An Overview
eXtreme programming (XP) - An OverviewGurtej Pal Singh
 
Software Estimation Techniques
Software Estimation TechniquesSoftware Estimation Techniques
Software Estimation Techniqueskamal
 
IIS Unidad 3A Proceso de desarrollo de software
IIS Unidad 3A Proceso de desarrollo de softwareIIS Unidad 3A Proceso de desarrollo de software
IIS Unidad 3A Proceso de desarrollo de softwareFranklin Parrales Bravo
 
GestióN De Proyectos Software
GestióN De Proyectos SoftwareGestióN De Proyectos Software
GestióN De Proyectos SoftwareUCPR
 
Introduction agile scrum methodology
Introduction agile scrum methodologyIntroduction agile scrum methodology
Introduction agile scrum methodologyAmit Verma
 
3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIEGOS
3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIEGOS3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIEGOS
3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIEGOSDaniela Barrientos
 
Grupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-softwareGrupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-softwarePrimoLaura
 
MODELOS DE SISTEMAS DE SOFTWARE
MODELOS DE SISTEMAS DE SOFTWAREMODELOS DE SISTEMAS DE SOFTWARE
MODELOS DE SISTEMAS DE SOFTWARERocio Castellanos
 
IIS Unidad 2 Modelos de proceso del software
IIS Unidad 2 Modelos de proceso del softwareIIS Unidad 2 Modelos de proceso del software
IIS Unidad 2 Modelos de proceso del softwareFranklin Parrales Bravo
 
Agile Software Development Model
Agile Software Development ModelAgile Software Development Model
Agile Software Development ModelRitika Balagan
 

La actualidad más candente (20)

IIS Unidad 3B Proceso de desarrollo de software
IIS Unidad 3B Proceso de desarrollo de softwareIIS Unidad 3B Proceso de desarrollo de software
IIS Unidad 3B Proceso de desarrollo de software
 
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWAREPSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
 
AD Unidad3: Tecnologías de aplicaciones distribuidas
AD Unidad3: Tecnologías de aplicaciones distribuidasAD Unidad3: Tecnologías de aplicaciones distribuidas
AD Unidad3: Tecnologías de aplicaciones distribuidas
 
IIS Unidad1: Introducción a la Ingeniería de Software
IIS Unidad1: Introducción a la Ingeniería de SoftwareIIS Unidad1: Introducción a la Ingeniería de Software
IIS Unidad1: Introducción a la Ingeniería de Software
 
Modelos de estimacion de software
Modelos de estimacion de softwareModelos de estimacion de software
Modelos de estimacion de software
 
Programación Extrema - XP
Programación Extrema - XPProgramación Extrema - XP
Programación Extrema - XP
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativo
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del software
 
eXtreme programming (XP) - An Overview
eXtreme programming (XP) - An OvervieweXtreme programming (XP) - An Overview
eXtreme programming (XP) - An Overview
 
Software Estimation Techniques
Software Estimation TechniquesSoftware Estimation Techniques
Software Estimation Techniques
 
IIS Unidad 3A Proceso de desarrollo de software
IIS Unidad 3A Proceso de desarrollo de softwareIIS Unidad 3A Proceso de desarrollo de software
IIS Unidad 3A Proceso de desarrollo de software
 
Mitos de-software.
Mitos de-software.Mitos de-software.
Mitos de-software.
 
GestióN De Proyectos Software
GestióN De Proyectos SoftwareGestióN De Proyectos Software
GestióN De Proyectos Software
 
Introduction agile scrum methodology
Introduction agile scrum methodologyIntroduction agile scrum methodology
Introduction agile scrum methodology
 
3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIEGOS
3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIEGOS3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIEGOS
3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIEGOS
 
Grupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-softwareGrupo 5-modelos-de-procesos-de-software
Grupo 5-modelos-de-procesos-de-software
 
MODELOS DE SISTEMAS DE SOFTWARE
MODELOS DE SISTEMAS DE SOFTWAREMODELOS DE SISTEMAS DE SOFTWARE
MODELOS DE SISTEMAS DE SOFTWARE
 
IIS Unidad 2 Modelos de proceso del software
IIS Unidad 2 Modelos de proceso del softwareIIS Unidad 2 Modelos de proceso del software
IIS Unidad 2 Modelos de proceso del software
 
Gestión de proyecto de software
Gestión de proyecto de softwareGestión de proyecto de software
Gestión de proyecto de software
 
Agile Software Development Model
Agile Software Development ModelAgile Software Development Model
Agile Software Development Model
 

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

Estimacion De Proyecto
Estimacion De ProyectoEstimacion De Proyecto
Estimacion De Proyectojavier
 
Modelos empiricos de_estimacion
Modelos empiricos de_estimacionModelos empiricos de_estimacion
Modelos empiricos de_estimaciondanymieres33
 
Tema 3 estimacion
Tema 3 estimacionTema 3 estimacion
Tema 3 estimacioneverfavi0
 
Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareAngel Macas
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de softwareClare Rodriguez
 
Jessika parica. planificación de un proyecto de software
Jessika parica. planificación de un proyecto de softwareJessika parica. planificación de un proyecto de software
Jessika parica. planificación de un proyecto de softwareJessika Parica
 
Ra semana 9 2
Ra semana 9 2Ra semana 9 2
Ra semana 9 2victdiazm
 
Estimación para proyectos de software cap26
Estimación para proyectos de software cap26Estimación para proyectos de software cap26
Estimación para proyectos de software cap26DEBANI SALAS
 
Gestion_de_Proyectos.ppt
Gestion_de_Proyectos.pptGestion_de_Proyectos.ppt
Gestion_de_Proyectos.pptssuser73f459
 
Planificacion De Proyectos De Software
Planificacion De Proyectos De SoftwarePlanificacion De Proyectos De Software
Planificacion De Proyectos De SoftwareIván Sanchez Vera
 

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

Estimacion De Proyecto
Estimacion De ProyectoEstimacion De Proyecto
Estimacion De Proyecto
 
Modelos empiricos de_estimacion
Modelos empiricos de_estimacionModelos empiricos de_estimacion
Modelos empiricos de_estimacion
 
Modelo cocomo I
Modelo cocomo IModelo cocomo I
Modelo cocomo I
 
Tema 3 estimacion
Tema 3 estimacionTema 3 estimacion
Tema 3 estimacion
 
Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de Software
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
 
Clase9 cocomoii
Clase9 cocomoiiClase9 cocomoii
Clase9 cocomoii
 
Cocomo
CocomoCocomo
Cocomo
 
Jessika parica. planificación de un proyecto de software
Jessika parica. planificación de un proyecto de softwareJessika parica. planificación de un proyecto de software
Jessika parica. planificación de un proyecto de software
 
Cocomo ii
Cocomo iiCocomo ii
Cocomo ii
 
Capitulo5
Capitulo5Capitulo5
Capitulo5
 
Ra semana 9 2
Ra semana 9 2Ra semana 9 2
Ra semana 9 2
 
Modelo Slim
Modelo SlimModelo Slim
Modelo Slim
 
Slim
SlimSlim
Slim
 
Cocomo 1 y cocomo 2
Cocomo 1 y  cocomo 2Cocomo 1 y  cocomo 2
Cocomo 1 y cocomo 2
 
Estimación para proyectos de software cap26
Estimación para proyectos de software cap26Estimación para proyectos de software cap26
Estimación para proyectos de software cap26
 
Estimación De Proyectos De Software
Estimación De Proyectos De SoftwareEstimación De Proyectos De Software
Estimación De Proyectos De Software
 
Gestion_de_Proyectos.ppt
Gestion_de_Proyectos.pptGestion_de_Proyectos.ppt
Gestion_de_Proyectos.ppt
 
Planificacion De Proyectos De Software
Planificacion De Proyectos De SoftwarePlanificacion De Proyectos De Software
Planificacion De Proyectos De Software
 
Cocomo 1
Cocomo 1Cocomo 1
Cocomo 1
 

Más de Franklin Parrales Bravo

Presentacion del congreso ETCM del 2021 en Cuenca
Presentacion del congreso ETCM del 2021 en CuencaPresentacion del congreso ETCM del 2021 en Cuenca
Presentacion del congreso ETCM del 2021 en CuencaFranklin Parrales Bravo
 
IW Unidad 1: Introducción a la Ingeniería Web
IW Unidad 1: Introducción a la Ingeniería WebIW Unidad 1: Introducción a la Ingeniería Web
IW Unidad 1: Introducción a la Ingeniería WebFranklin Parrales Bravo
 
IW Unidad 4: Web accesible, semántica y ubicua
IW Unidad 4: Web accesible, semántica y ubicuaIW Unidad 4: Web accesible, semántica y ubicua
IW Unidad 4: Web accesible, semántica y ubicuaFranklin Parrales Bravo
 
IW Unidad 3: Ingeniería Web dirigida por modelos
IW Unidad 3: Ingeniería Web dirigida por modelosIW Unidad 3: Ingeniería Web dirigida por modelos
IW Unidad 3: Ingeniería Web dirigida por modelosFranklin Parrales Bravo
 
IW Unidad 2: Metodologías y Técnicas de la Ingeniería Web
IW Unidad 2: Metodologías y Técnicas de la Ingeniería WebIW Unidad 2: Metodologías y Técnicas de la Ingeniería Web
IW Unidad 2: Metodologías y Técnicas de la Ingeniería WebFranklin Parrales Bravo
 
AD Unidad4: Programación paralela y distribuida
AD Unidad4: Programación paralela y distribuidaAD Unidad4: Programación paralela y distribuida
AD Unidad4: Programación paralela y distribuidaFranklin Parrales Bravo
 
GCSW Unidad1: Objetos de la Gestión de Configuración del Software
GCSW Unidad1: Objetos de la Gestión de Configuración del SoftwareGCSW Unidad1: Objetos de la Gestión de Configuración del Software
GCSW Unidad1: Objetos de la Gestión de Configuración del SoftwareFranklin Parrales Bravo
 
GCSW Unidad2: Actividades de la gestión de configuración del software
GCSW Unidad2: Actividades de la gestión de configuración del software GCSW Unidad2: Actividades de la gestión de configuración del software
GCSW Unidad2: Actividades de la gestión de configuración del software Franklin Parrales Bravo
 
POO Unidad 4: Persistencia de objetos y manejo de archivos
POO Unidad 4: Persistencia de objetos y manejo de archivosPOO Unidad 4: Persistencia de objetos y manejo de archivos
POO Unidad 4: Persistencia de objetos y manejo de archivosFranklin Parrales Bravo
 
POO Unidad 3: Interfaz gráfica de usuario e hilos
POO Unidad 3: Interfaz gráfica de usuario e hilosPOO Unidad 3: Interfaz gráfica de usuario e hilos
POO Unidad 3: Interfaz gráfica de usuario e hilosFranklin Parrales Bravo
 
POO Unidad 2: Programación Orientada a Objetos
POO Unidad 2: Programación Orientada a ObjetosPOO Unidad 2: Programación Orientada a Objetos
POO Unidad 2: Programación Orientada a ObjetosFranklin Parrales Bravo
 
POO Unidad 1: Introducción a la Programación Orientada a Objetos
POO Unidad 1: Introducción a la Programación Orientada a ObjetosPOO Unidad 1: Introducción a la Programación Orientada a Objetos
POO Unidad 1: Introducción a la Programación Orientada a ObjetosFranklin Parrales Bravo
 
RD Unidad 3: IPv6, Routers y Enrutamiento
RD Unidad 3: IPv6, Routers y EnrutamientoRD Unidad 3: IPv6, Routers y Enrutamiento
RD Unidad 3: IPv6, Routers y EnrutamientoFranklin Parrales Bravo
 
RD Unidad 2: Transmisión de datos. El mundo del TCP/IP y direccionamiento iPv4
RD Unidad 2: Transmisión de datos. El mundo del TCP/IP y direccionamiento iPv4RD Unidad 2: Transmisión de datos. El mundo del TCP/IP y direccionamiento iPv4
RD Unidad 2: Transmisión de datos. El mundo del TCP/IP y direccionamiento iPv4Franklin Parrales Bravo
 
RD Unidad 1: Principios de Comunicación y Redes
RD Unidad 1: Principios de Comunicación y RedesRD Unidad 1: Principios de Comunicación y Redes
RD Unidad 1: Principios de Comunicación y RedesFranklin Parrales Bravo
 
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventosPOE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventosFranklin Parrales Bravo
 
POE Unidad 3: Aplicaciones visuales orientadas a eventos con acceso a base de...
POE Unidad 3: Aplicaciones visuales orientadas a eventos con acceso a base de...POE Unidad 3: Aplicaciones visuales orientadas a eventos con acceso a base de...
POE Unidad 3: Aplicaciones visuales orientadas a eventos con acceso a base de...Franklin Parrales Bravo
 
POE Unidad 1: Introducción a la programación visual y de eventos
POE Unidad 1: Introducción a la programación visual y de eventosPOE Unidad 1: Introducción a la programación visual y de eventos
POE Unidad 1: Introducción a la programación visual y de eventosFranklin Parrales Bravo
 
SO Unidad 1: Introducción a los Sistemas Operativos
SO Unidad 1: Introducción a los Sistemas OperativosSO Unidad 1: Introducción a los Sistemas Operativos
SO Unidad 1: Introducción a los Sistemas OperativosFranklin Parrales Bravo
 

Más de Franklin Parrales Bravo (20)

Presentacion del congreso ETCM del 2021 en Cuenca
Presentacion del congreso ETCM del 2021 en CuencaPresentacion del congreso ETCM del 2021 en Cuenca
Presentacion del congreso ETCM del 2021 en Cuenca
 
IW Unidad 1: Introducción a la Ingeniería Web
IW Unidad 1: Introducción a la Ingeniería WebIW Unidad 1: Introducción a la Ingeniería Web
IW Unidad 1: Introducción a la Ingeniería Web
 
IW Unidad 4: Web accesible, semántica y ubicua
IW Unidad 4: Web accesible, semántica y ubicuaIW Unidad 4: Web accesible, semántica y ubicua
IW Unidad 4: Web accesible, semántica y ubicua
 
IW Unidad 3: Ingeniería Web dirigida por modelos
IW Unidad 3: Ingeniería Web dirigida por modelosIW Unidad 3: Ingeniería Web dirigida por modelos
IW Unidad 3: Ingeniería Web dirigida por modelos
 
MOD Unidad 2: Tipos de modelado
MOD Unidad 2: Tipos de modeladoMOD Unidad 2: Tipos de modelado
MOD Unidad 2: Tipos de modelado
 
IW Unidad 2: Metodologías y Técnicas de la Ingeniería Web
IW Unidad 2: Metodologías y Técnicas de la Ingeniería WebIW Unidad 2: Metodologías y Técnicas de la Ingeniería Web
IW Unidad 2: Metodologías y Técnicas de la Ingeniería Web
 
AD Unidad4: Programación paralela y distribuida
AD Unidad4: Programación paralela y distribuidaAD Unidad4: Programación paralela y distribuida
AD Unidad4: Programación paralela y distribuida
 
GCSW Unidad1: Objetos de la Gestión de Configuración del Software
GCSW Unidad1: Objetos de la Gestión de Configuración del SoftwareGCSW Unidad1: Objetos de la Gestión de Configuración del Software
GCSW Unidad1: Objetos de la Gestión de Configuración del Software
 
GCSW Unidad2: Actividades de la gestión de configuración del software
GCSW Unidad2: Actividades de la gestión de configuración del software GCSW Unidad2: Actividades de la gestión de configuración del software
GCSW Unidad2: Actividades de la gestión de configuración del software
 
POO Unidad 4: Persistencia de objetos y manejo de archivos
POO Unidad 4: Persistencia de objetos y manejo de archivosPOO Unidad 4: Persistencia de objetos y manejo de archivos
POO Unidad 4: Persistencia de objetos y manejo de archivos
 
POO Unidad 3: Interfaz gráfica de usuario e hilos
POO Unidad 3: Interfaz gráfica de usuario e hilosPOO Unidad 3: Interfaz gráfica de usuario e hilos
POO Unidad 3: Interfaz gráfica de usuario e hilos
 
POO Unidad 2: Programación Orientada a Objetos
POO Unidad 2: Programación Orientada a ObjetosPOO Unidad 2: Programación Orientada a Objetos
POO Unidad 2: Programación Orientada a Objetos
 
POO Unidad 1: Introducción a la Programación Orientada a Objetos
POO Unidad 1: Introducción a la Programación Orientada a ObjetosPOO Unidad 1: Introducción a la Programación Orientada a Objetos
POO Unidad 1: Introducción a la Programación Orientada a Objetos
 
RD Unidad 3: IPv6, Routers y Enrutamiento
RD Unidad 3: IPv6, Routers y EnrutamientoRD Unidad 3: IPv6, Routers y Enrutamiento
RD Unidad 3: IPv6, Routers y Enrutamiento
 
RD Unidad 2: Transmisión de datos. El mundo del TCP/IP y direccionamiento iPv4
RD Unidad 2: Transmisión de datos. El mundo del TCP/IP y direccionamiento iPv4RD Unidad 2: Transmisión de datos. El mundo del TCP/IP y direccionamiento iPv4
RD Unidad 2: Transmisión de datos. El mundo del TCP/IP y direccionamiento iPv4
 
RD Unidad 1: Principios de Comunicación y Redes
RD Unidad 1: Principios de Comunicación y RedesRD Unidad 1: Principios de Comunicación y Redes
RD Unidad 1: Principios de Comunicación y Redes
 
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventosPOE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
 
POE Unidad 3: Aplicaciones visuales orientadas a eventos con acceso a base de...
POE Unidad 3: Aplicaciones visuales orientadas a eventos con acceso a base de...POE Unidad 3: Aplicaciones visuales orientadas a eventos con acceso a base de...
POE Unidad 3: Aplicaciones visuales orientadas a eventos con acceso a base de...
 
POE Unidad 1: Introducción a la programación visual y de eventos
POE Unidad 1: Introducción a la programación visual y de eventosPOE Unidad 1: Introducción a la programación visual y de eventos
POE Unidad 1: Introducción a la programación visual y de eventos
 
SO Unidad 1: Introducción a los Sistemas Operativos
SO Unidad 1: Introducción a los Sistemas OperativosSO Unidad 1: Introducción a los Sistemas Operativos
SO Unidad 1: Introducción a los Sistemas Operativos
 

Último

Instalacion de servicios windows, configuracion y aplicacion.
Instalacion de servicios windows, configuracion y aplicacion.Instalacion de servicios windows, configuracion y aplicacion.
Instalacion de servicios windows, configuracion y aplicacion.CZSOTEC
 
Se realiza instalacion y configuraacion servicios Windows
Se realiza instalacion y configuraacion servicios WindowsSe realiza instalacion y configuraacion servicios Windows
Se realiza instalacion y configuraacion servicios WindowsCZSOTEC
 
Webinar Resolucion2335 de 2023 Kubapp.pdf
Webinar Resolucion2335 de 2023 Kubapp.pdfWebinar Resolucion2335 de 2023 Kubapp.pdf
Webinar Resolucion2335 de 2023 Kubapp.pdfAnaRosaMontenegro
 
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptxMacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptxcalzadillasluis134
 
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVOSISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVOELIAMARYTOVARFLOREZD
 
Delitos informáticos en Slideshare.pptx
Delitos informáticos en  Slideshare.pptxDelitos informáticos en  Slideshare.pptx
Delitos informáticos en Slideshare.pptxmaykolmagallanes012
 

Último (6)

Instalacion de servicios windows, configuracion y aplicacion.
Instalacion de servicios windows, configuracion y aplicacion.Instalacion de servicios windows, configuracion y aplicacion.
Instalacion de servicios windows, configuracion y aplicacion.
 
Se realiza instalacion y configuraacion servicios Windows
Se realiza instalacion y configuraacion servicios WindowsSe realiza instalacion y configuraacion servicios Windows
Se realiza instalacion y configuraacion servicios Windows
 
Webinar Resolucion2335 de 2023 Kubapp.pdf
Webinar Resolucion2335 de 2023 Kubapp.pdfWebinar Resolucion2335 de 2023 Kubapp.pdf
Webinar Resolucion2335 de 2023 Kubapp.pdf
 
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptxMacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
 
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVOSISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
 
Delitos informáticos en Slideshare.pptx
Delitos informáticos en  Slideshare.pptxDelitos informáticos en  Slideshare.pptx
Delitos informáticos en Slideshare.pptx
 

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

  • 1. 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
  • 2. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 3. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 4. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 5. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 5 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
  • 6. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 7. Elaboración de Proyectos Ph.D. Franklin Parrales 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)
  • 8. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 9. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 9 26/01/2023 Medir lo que quiere el usuario.
  • 10. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 10 26/01/2023 Estimar lo que costara ▪ Experiencia Individual ▪ Experiencia de Empresa
  • 11. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 12. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 13. Elaboración de Proyectos Ph.D. Franklin Parrales 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)
  • 14. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 15. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 16. Elaboración de Proyectos Ph.D. Franklin Parrales 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)
  • 17. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 18. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 18 26/01/2023 Effort = a*(Size)b DevTime = c*(Effort)d “KLOC” PM Personas Mes M Meses “MODELO BASICO” Modelos de estimación COCOMO I 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.
  • 19. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 19 26/01/2023 Modelos de estimación COCOMO I 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.
  • 20. Elaboración de Proyectos Ph.D. Franklin Parrales 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.:
  • 21. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 21 26/01/2023 Modelos de estimación COCOMO I ▪ 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.
  • 22. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 23. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 24. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 24 26/01/2023 Cálculo de FAE Factores de Costo
  • 25. Elaboración de Proyectos Ph.D. Franklin Parrales 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).
  • 26. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 27. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 28. Elaboración de Proyectos Ph.D. Franklin Parrales 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:
  • 29. Elaboración de Proyectos Ph.D. Franklin Parrales 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)
  • 30. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 30 26/01/2023 Continuación Ejemplo: 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
  • 31. Elaboración de Proyectos Ph.D. Franklin Parrales 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 Continuación Ejemplo: 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
  • 32. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 33. Elaboración de Proyectos Ph.D. Franklin Parrales 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 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
  • 34. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 35. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 36. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 36 26/01/2023 Modelos de estimación COCOMO I ▪ 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
  • 37. Elaboración de Proyectos Ph.D. Franklin Parrales 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).
  • 38. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 39. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 40. Elaboración de Proyectos Ph.D. Franklin Parrales 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)
  • 41. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 42. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 43. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 43 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) 1
  • 44. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 45. Elaboración de Proyectos Ph.D. Franklin Parrales 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 Modelo De Composición De la Aplicación
  • 46. Elaboración de Proyectos Ph.D. Franklin Parrales 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). Modelo De Composición De la Aplicación
  • 47. Elaboración de Proyectos Ph.D. Franklin Parrales 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 Modelo De Composición De la Aplicación
  • 48. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 49. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 49 26/01/2023 Ejemplo: Modelo De Composición De la Aplicación 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.
  • 50. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 50 26/01/2023 Ejemplo: Modelo De Composición De la Aplicación 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
  • 51. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 51 26/01/2023 Ejemplo: Modelo De Composición De la Aplicación 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
  • 52. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 52 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) 2
  • 53. Elaboración de Proyectos Ph.D. Franklin Parrales 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).
  • 54. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 55. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 55 26/01/2023 Factores de Escala B
  • 56. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 57. Elaboración de Proyectos Ph.D. Franklin Parrales 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 -
  • 58. Elaboración de Proyectos Ph.D. Franklin Parrales 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 -
  • 59. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 60. Elaboración de Proyectos Ph.D. Franklin Parrales 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/
  • 61. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 61 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) 3
  • 62. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 63. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 64. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 65. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 66. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 67. Elaboración de Proyectos Ph.D. Franklin Parrales 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%.
  • 68. Elaboración de Proyectos Ph.D. Franklin Parrales 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 :
  • 69. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 69 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
  • 70. Elaboración de Proyectos Ph.D. Franklin Parrales 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”?
  • 71. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 72. Elaboración de Proyectos Ph.D. Franklin Parrales 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: … Duración: 4 semanas Tarea: Diseño B.D. Recursos: … Duración: 2 semanas Tarea: Realización Esquema Recursos: … Duración: 1 semanas Tarea: Codificación Program. Recursos: … Duración: 7 semanas Tarea: Pruebas Recursos: … Duración: 2 semanas 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
  • 73. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 74. Elaboración de Proyectos Ph.D. Franklin Parrales 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...
  • 75. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 76. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 77. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 78. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 79. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 80. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 81. Elaboración de Proyectos Ph.D. Franklin Parrales 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 …
  • 82. Elaboración de Proyectos Ph.D. Franklin Parrales 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 …
  • 83. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 84. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 85. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 86. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 87. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 88. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 89. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 90. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 91. Elaboración de Proyectos Ph.D. Franklin Parrales 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?
  • 92. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 93. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 94. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 95. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 96. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 97. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 98. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 99. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 100. Elaboración de Proyectos Ph.D. Franklin Parrales 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?
  • 101. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 102. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 102 26/01/2023 Elaboración del presupuesto del proyecto Ejemplo: PRODUCTO CANTIDAD VALOR UNITARIO VALOR TOTAL Laptops 2 $800 $1600 Smartphones 2 $350 $700 Total 4 $1150 $2300 COSTO HARDWARE PRODUCTO CANTIDAD VALOR MENSUAL UNI. TIEMPO VALOR TOTAL Est. Egresado 2 $425 4 meses $3400 Total 2 $425 4 meses $3400 GASTOS DE TALENTO HUMANO
  • 103. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 103 26/01/2023 Elaboración del presupuesto del proyecto Ejemplo: PRODUCTO CANTIDAD VALOR 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
  • 104. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 104 26/01/2023 Elaboración del presupuesto del proyecto ▪ 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.
  • 105. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 106. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 106 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
  • 107. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 108. Elaboración de Proyectos Ph.D. Franklin Parrales 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 ▪ ...
  • 109. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 110. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 111. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 112. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 112 26/01/2023 Causas comunes de fracaso(2) (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
  • 113. Elaboración de Proyectos Ph.D. Franklin Parrales Carrera de Software 113 26/01/2023 Causas comunes de fracaso(3) (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.
  • 114. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 115. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 116. Elaboración de Proyectos Ph.D. Franklin Parrales 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?
  • 117. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 118. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 119. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 120. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 121. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 122. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 123. Elaboración de Proyectos Ph.D. Franklin Parrales 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)
  • 124. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 125. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 126. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 127. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 128. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 129. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 130. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 131. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 132. Elaboración de Proyectos Ph.D. Franklin Parrales 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.
  • 133. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 134. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 135. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 136. Elaboración de Proyectos Ph.D. Franklin Parrales 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
  • 137. Elaboración de Proyectos Ph.D. Franklin Parrales 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