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.

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

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/

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 :

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

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

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

Estás leyendo una previsualización.

Eche un vistazo a continuación

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

Más Contenido Relacionado

Presentaciones para usted (20)

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

Más de Franklin Parrales Bravo (20)

Más reciente (20)