Material Apoyo Ingenieria del Software USAL Argentina

8,380 views

Published on

Published in: Technology, Business
2 Comments
1 Like
Statistics
Notes
  • muy bueno, me sirvió de mucho thx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • me parece interesante, bajando
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
8,380
On SlideShare
0
From Embeds
0
Number of Embeds
3,895
Actions
Shares
0
Downloads
263
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

Material Apoyo Ingenieria del Software USAL Argentina

  1. 1. Ingeniería del Software
  2. 2. Nuevo orden (Sistemas basados en computadoras) No hay nada más difícil de llevar a cabo, más peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción de un nuevo orden de cosas. Maquiavello
  3. 3. Concepto <ul><li>La ingeniería del software ocurre como consecuencia de un proceso denominado ingeniería de sistemas de computadora . </li></ul><ul><li>No solo se concentra en el software, sino que se concentra en una variedad de elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información. </li></ul>
  4. 4. Gestión de Proyectos –tres “pes”-
  5. 5. El Espectro de la gestión <ul><li>El gestor que se olvida de que el trabajo de ingeniería del SW es un esfuerzo humano intenso, nunca tendrá éxito en la gestión de proyectos. </li></ul><ul><li>Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. </li></ul><ul><li>Finalmente, el administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. </li></ul>
  6. 6. Conceptos sobre gestión de proyectos <ul><li>La gestión eficaz de un proyecto de software se centra en las </li></ul><ul><li>Tres “PES”: </li></ul><ul><ul><li>Personal. </li></ul></ul><ul><ul><li>Problema. </li></ul></ul><ul><ul><li>Proceso. </li></ul></ul>
  7. 7. Personal <ul><li>Modelo de madurez de la capacidad de gestión de </li></ul><ul><li>persona. </li></ul><ul><li>Aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software. </li></ul>
  8. 8. Personal <ul><li>El MMCGP (Modelo de Madurez de la capacidad de gestión de personal) define las siguientes áreas prácticas clave para el personal que desarrolla software: </li></ul><ul><li>Reclutamiento. </li></ul><ul><li>Selección. </li></ul><ul><li>Gestión de rendimiento. </li></ul><ul><li>Entrenamiento. </li></ul><ul><li>Retribución. </li></ul><ul><li>Desarrollo cultural. </li></ul><ul><li>Espíritu de equipo. </li></ul>
  9. 9. Personal Las organizaciones que alcanzan una gran madurez en el área de gestión de personal tienen una mayor probabilidad de implementar unas eficaces prácticas de ingeniería del software.
  10. 10. Personal <ul><li>Los participantes </li></ul><ul><li>Gestores superiores , que definen los aspectos de negocio que a menudo tienen una significativa influencia en el proyecto. </li></ul><ul><li>Gestores (técnicos) del proyecto , que deben planificar, modificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software. </li></ul><ul><li>Profesionales , que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación. </li></ul><ul><li>Clientes , que especifican los requisitos para la ingeniería del SW. </li></ul><ul><li>Usuarios finales , que interaccionan con el SW una vez que se ha entregado para la producción. </li></ul>
  11. 11. Jefes de Equipos <ul><li>¿Qué es lo que buscamos cuando seleccionamos a alguien para dirigir un proyecto de SW? </li></ul><ul><ul><li>Motivación. </li></ul></ul><ul><ul><li>Organización. </li></ul></ul><ul><ul><li>Ideas o Innovación. </li></ul></ul>
  12. 12. Motivación <ul><li>La habilidad para motivar al personal técnico para que produzca conforme a sus mejores capacidades. </li></ul>
  13. 13. Organización <ul><li>La habilidad para moldear procesos existentes que permita al concepto inicial transformarse en un proyecto final. </li></ul>
  14. 14. Ideas o Innovación <ul><li>La habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los límites establecidos para un producto o aplicación de SW particular </li></ul>
  15. 15. Gestor de Proyectos <ul><li>las características que definen a un gestor de </li></ul><ul><li>proyecto eficiente resalta cuatro apartados </li></ul><ul><li>claves: </li></ul><ul><li>Resolución del problema. </li></ul><ul><li>Dotes de gestión. </li></ul><ul><li>Incentivo de los logros. </li></ul><ul><li>Influencia y construcción de espíritu de equipo. </li></ul>
  16. 16. Resolución del problema <ul><li>Un gestor puede diagnosticar los aspectos tecnológicos y de organización. </li></ul><ul><li>Estructurar una posible solución </li></ul><ul><li>Aplicar todo lo aprendido en proyectos anteriores. </li></ul><ul><li>Flexibilidad para cambiar la gestión si los intentos iniciales no dan el resultado esperado. </li></ul>
  17. 17. Dotes de Gestión <ul><li>Un buen gestor de proyecto de SW debe tomar las riendas. </li></ul><ul><li>Debe tener confianza para asumir el control cuando sea necesario. </li></ul><ul><li>garantizar que los buenos técnicos sigan su instinto. </li></ul>
  18. 18. Incentivos de los logros <ul><li>Recompensar la iniciativa y los logros. </li></ul><ul><li>Demostrar, a través de sus acciones que no se penalizará si se corren riesgos controlados. </li></ul>
  19. 19. Influencia y construcción de espíritu de equipo. <ul><li>Debe de ser capaz de “leer” a la gente. </li></ul><ul><li>Debe se capaz de entender mensajes verbales y no verbales. </li></ul><ul><li>Reaccionar ante la necesidades de las personas que mandan señales. </li></ul><ul><li>El gestor debe mantener el control en situaciones de gran estrés. </li></ul>
  20. 20. El Equipo de SW <ul><li>Existen casi tantas estructuras de </li></ul><ul><li>organización de personal para el </li></ul><ul><li>desarrollo de SW como organizaciones </li></ul><ul><li>que se dedican a ello. </li></ul>
  21. 21. <ul><li>las políticas y prácticas de un cambio en la organización no están dentro del alcance de las responsabilidades del gestor de un proyecto de SW. </li></ul><ul><li>la organización del personal directamente involucrado en un nuevo proyecto de SW esta dentro del ámbito del gestor del proyecto. </li></ul>El Equipo de SW
  22. 22. <ul><li>La mejor estructura de personas que compondrá el equipo, sus niveles de preparación y la dificultas general del problema. </li></ul><ul><li>Se sugieren tres organigramas de equipo genérico. </li></ul><ul><ul><li>Descentralizado democrático (DD). </li></ul></ul><ul><ul><li>Descentralizado controlado (DC). </li></ul></ul><ul><ul><li>Centralizado controlado (CC). </li></ul></ul>El Equipo de SW
  23. 23. <ul><li>No tiene un jefe permanente. </li></ul><ul><li>Se nombran coordinadores de tareas a corto plazo. </li></ul><ul><ul><li>se sustituyen por otros para diferentes tareas. </li></ul></ul><ul><li>Las decisiones sobre problemas y enfoques se hacen por consenso del grupo. </li></ul><ul><li>La comunicación entre los miembros del equipo es horizontal. </li></ul>Descentralizado democrático (DD)
  24. 24. <ul><li>Tiene un jefe definido. </li></ul><ul><ul><li>coordina tareas específicas y jefes secundarios. </li></ul></ul><ul><li>La resolución de problemas sigue siendo una actividad del grupo. </li></ul><ul><ul><li>La implementación de soluciones se reparte entre subgrupos por el jefe de equipo. </li></ul></ul><ul><li>La comunicación entre subgrupos e individuo es horizontal. </li></ul><ul><li>Hay comunicación vertical a lo largo de la jerarquía de control. </li></ul>Descentralizado controlado (DC)
  25. 25. <ul><li>El jefe del equipo se encarga de la resolución de problemas de alto nivel y la coordinación interna del grupo. </li></ul><ul><li>La comunicación entre el jefe y los miembros del equipo es vertical. </li></ul>Centralizado controlado (CC)
  26. 26. <ul><li>Siete factores a considerar </li></ul><ul><li>La dificultad del problema que hay que resolver. </li></ul><ul><li>el tamaño del programa resultante en líneas de código. </li></ul><ul><li>el tiempo que el equipo estará junto(Tº de vida del equipo. </li></ul><ul><li>el grado en que el problema puede ser modularizado. </li></ul><ul><li>la calidad requerida y fiabilidad del sistema que se va a construir. </li></ul><ul><li>la rigidez de la fecha de entrega. </li></ul><ul><li>el grado de comunicación requerido para el proyecto. </li></ul>Factores a considerar
  27. 27. Paradigmas de organización <ul><li>Para equipos de ingeniería del SW </li></ul><ul><li>Paradigma cerrado. </li></ul><ul><li>Paradigma aleatorio. </li></ul><ul><li>Paradigma abierto. </li></ul><ul><li>Paradigma sincronizado. </li></ul>
  28. 28. Paradigma cerrado <ul><li>Estructura a un equipo con una jerarquía tradicional de autoridad (similar al equipo CC). </li></ul><ul><li>Trabajan bien cuando producen SW similar a otros anteriores. </li></ul><ul><li>Menos innovadores. </li></ul>
  29. 29. Paradigma aleatorio <ul><li>Estructura al equipo libremente y depende de la iniciativa individual de los miembros. </li></ul><ul><li>se requiere innovación o avances tecnológicos. </li></ul><ul><li>son excelentes. </li></ul><ul><li>chocan cuando se requiere un “rendimiento ordenado”. </li></ul>
  30. 30. Paradigma abierto <ul><li>Intenta estructurar a un equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado. </li></ul><ul><li>Utiliza mucha de la innovación que tiene lugar cuando se utiliza el paradigma aleatorio. </li></ul><ul><li>El trabajo se desarrolla con mucha comunicación y toma decisiones consensuadas. </li></ul><ul><li>son adecuados para la resolución de problemas complejos. </li></ul><ul><li>Pueden no tener un rendimiento tan eficiente como otros equipos. </li></ul>
  31. 31. Paradigma Sincronizado <ul><li>Se basa en la compartimentación natural de un problema. </li></ul><ul><li>Organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos. </li></ul>
  32. 32. Cohesión de equipos <ul><li>Tendemos a usar la palabra “equipo” </li></ul><ul><li>demasiado libremente en el mundo de los </li></ul><ul><li>negocios, denominado “equipo” a cualquier </li></ul><ul><li>grupo de gente asignado para trabajar junta. </li></ul><ul><li>Pero muchos de estos grupos no parecen </li></ul><ul><li>equipos. No tienen una definición común de </li></ul><ul><li>éxito o un espíritu de equipo identificable. Lo </li></ul><ul><li>que falta es un fenómeno que denominamos </li></ul><ul><li>“ cuajar”. </li></ul>
  33. 33. Cohesión de equipos <ul><li>Un equipo cuajado es un grupo de gente tejido tan fuertemente que el todo es mayor que la suma de las partes. </li></ul>
  34. 34. Cohesión de equipos <ul><li>Cuando el equipo empieza a cuajar, la probabilidad de éxito empieza a subir. El equipo puede convertirse en imparable, un monstruo de éxito. No necesita ser dirigidos de una manera tradicional y no necesitan que se les motive. Están en su gran momento. Comparten una meta en común </li></ul>
  35. 35. Técnicas de coordinación de proyectos <ul><li>Formal, enfoque impersonal. </li></ul><ul><li>Formal, procedimientos interpersonales. </li></ul><ul><li>Informal, procedimientos interpersonales. </li></ul><ul><li>Comunicación electrónica. </li></ul><ul><li>Red interpersonal. </li></ul>
  36. 36. Formal, enfoque impersonal <ul><li>Incluyen documentos de Ingeniería del SW y entregas (Cod. fuente) memorandos técnicos, planificaciones del programa y herramientas de control del proyecto, peticiones de cambios, informes de seguimiento de errores e información de estado e inspecciones de diseño y de código. </li></ul>
  37. 37. Formal, procedimientos interpersonales <ul><li>Se concentra en las actividades de garantía de calidad. Aplicada a productos de ingeniería del SW. Incluyen reuniones de revisión de estado e inspecciones de diseño y de código. </li></ul>
  38. 38. Informal, procedimientos interpersonales <ul><li>Incluye reuniones de grupo para la divulgación de información y resolución de problemas. </li></ul><ul><li>Definición de requisitos y del personal de desarrollo. </li></ul>
  39. 39. Comunicación electrónica <ul><li>Agrupa correo electrónico. </li></ul><ul><li>Boletines de noticias electrónicos. </li></ul><ul><li>Página WEB. </li></ul><ul><li>Sistemas de video conferencia. </li></ul>
  40. 40. Red interpersonal <ul><li>Discusiones informales con personas que no están en el proyecto pero que pueden tener experiencia. </li></ul><ul><li>discusión de puntos. </li></ul>
  41. 41. Problema <ul><li>El gestor del proyecto requiere </li></ul><ul><li>estimaciones cuantitativas y un plan </li></ul><ul><li>organizado. Pero no dispones de </li></ul><ul><li>información sólida. Un análisis detallado de los </li></ul><ul><li>requisitos daría la información necesaria para las </li></ul><ul><li>estimaciones. A menudo lleva semanas o meses. </li></ul><ul><li>Los requisitos pueden ser fluidos, cambiando a </li></ul><ul><li>medida que progresa el proyecto. Aún así, necesita un plan “YA”.Debe examinar el problema justo al inicio del proyecto </li></ul>
  42. 42. Ámbito del SW <ul><li>La primera actividad de gestión es determinar </li></ul><ul><li>el ámbito del SW. Se define respondiendo a </li></ul><ul><li>las siguientes cuestiones: </li></ul><ul><li>Contexto. </li></ul><ul><li>Objetivos de información. </li></ul><ul><li>Función y rendimiento. </li></ul>
  43. 43. Contexto <ul><li>Encajar el SW a construir en un sistema. La limitaciones se imponen como resultado del contexto. </li></ul>
  44. 44. Objetivos de información <ul><li>Qué datos visibles se obtienen del cliente. Qué datos son requeridos de entrada. </li></ul>
  45. 45. Función y rendimiento <ul><li>Qué función realiza el SW para transformar la información de entrada en una salida. </li></ul>
  46. 46. Ámbito de proyecto <ul><li>Los enunciados del SW estar delimitados. Nº de usuarios simultáneos, tamaño de la lista de correo, máximo de Tº de respuesta. </li></ul>
  47. 47. Descomposición del problema <ul><li>El particionamiento, es el corazón </li></ul><ul><li>del análisis de requerimiento. Se </li></ul><ul><li>aplica en: </li></ul><ul><ul><li>La funcionalidad que debe entregarse. </li></ul></ul><ul><ul><li>El proceso que se empleará para entregarlo </li></ul></ul>
  48. 48. Proceso <ul><li>El gestor del proyecto debe decidir qué modelo de </li></ul><ul><li>proceso es le más adecuado para el proyecto, </li></ul><ul><li>después debe definir un plan preliminar basado en </li></ul><ul><li>un conjunto de actividades válidas. Una vez </li></ul><ul><li>establecido el plan preliminar, empieza la </li></ul><ul><li>descomposición del proceso. Se debe crear un plan </li></ul><ul><li>completo reflejando las tareas requeridas a las </li></ul><ul><li>personas para cubrir las actividades. </li></ul>
  49. 49. Maduración del problema y proceso <ul><li>La planificación de un proyecto empieza con la maduración del problema y del proceso. Todas las funciones se deben tratar dentro de un proceso de ingeniería por el equipo de SW. </li></ul><ul><li>Conjunto de actividades: </li></ul><ul><ul><ul><li>Comunicación con el cliente. </li></ul></ul></ul><ul><ul><ul><li>Planificación. </li></ul></ul></ul><ul><ul><ul><li>Análisis de riesgo. </li></ul></ul></ul><ul><ul><ul><li>Ingeniería. </li></ul></ul></ul><ul><ul><ul><li>Construcción y entrega. </li></ul></ul></ul><ul><ul><ul><li>Evaluación del cliente. </li></ul></ul></ul>
  50. 50. Comunicación con el Cliente <ul><li>Tareas requeridas para establecer una comunicación eficiente entre el desarrollador y el cliente. </li></ul>
  51. 51. Planificación <ul><li>Tareas requeridas para definir los </li></ul><ul><li>recursos, la planificación temporal del </li></ul><ul><li>proyecto y cualquier información relativa </li></ul><ul><li>a él. </li></ul>
  52. 52. Análisis de riesgo <ul><li>Tareas requeridas para valorar los riesgos técnicos y de gestión. </li></ul>
  53. 53. Ingeniería <ul><li>Tareas requeridas para construir una o más representaciones de la aplicación. </li></ul>
  54. 54. Construcción y entrega <ul><li>Tareas requeridas para construir, probar </li></ul><ul><li>instalar y proporcionar asistencia al </li></ul><ul><li>usuario. </li></ul>
  55. 55. Evaluación del cliente <ul><li>Tareas requeridas para obtener </li></ul><ul><li>información de la opinión del cliente </li></ul><ul><li>basadas en la evaluación de las </li></ul><ul><li>representaciones de SW creadas durante </li></ul><ul><li>la fase de ingeniería e implementación </li></ul><ul><li>durante la fase de instalación </li></ul>
  56. 56. Gestión efectiva de un proyecto de software
  57. 57. <ul><li>10 Causas de fracaso </li></ul><ul><li>Solución en busca de un problema. </li></ul><ul><li>Solo el equipo del proyecto esta interesado en el resultado final. </li></ul><ul><li>Nadie a cargo. </li></ul><ul><li>Plan carece de estructura. </li></ul><ul><li>Plan carece de detalle. </li></ul><ul><li>Presupuesto inferior al requerido. </li></ul><ul><li>Recursos asignados insuficientes. </li></ul><ul><li>No hay seguimiento contra un plan. </li></ul><ul><li>El equipo no se comunica. </li></ul><ul><li>El proyecto se aparta de sus metas originales. </li></ul>Gestión efectiva de un proyecto de software
  58. 58. Gestión Efectiva <ul><li>Ambito de trabajo. </li></ul><ul><li>Riesgos. </li></ul><ul><li>Recursos. </li></ul><ul><li>Tareas. </li></ul><ul><li>Hitos. </li></ul><ul><li>Esfuerzo. </li></ul><ul><li>Plan. </li></ul>
  59. 59. Recursos - Software <ul><li>Gestión de proyectos </li></ul><ul><li>Soporte </li></ul><ul><li>Análisis y Diseño </li></ul><ul><li>Programación </li></ul><ul><li>Prueba e Integración </li></ul><ul><li>Simulación y creación de prototipos </li></ul><ul><li>Mantenimiento </li></ul>
  60. 60. Integración de Sistemas
  61. 61. <ul><li>La actividad de asumir responsabilidades </li></ul><ul><li>contractuales por la combinación </li></ul><ul><li>de productos y/o servicios propios y/o de </li></ul><ul><li>terceros en una solución que satisfaga los </li></ul><ul><li>requerimientos específicos del Cliente. </li></ul>Integración de sistemas
  62. 62. <ul><li>Elementos Esenciales </li></ul><ul><li>Manejo del Riesgo. </li></ul><ul><li>Manejo de Proyectos. </li></ul><ul><li>Integración y Testeo. </li></ul>Integración de sistemas
  63. 63. Integración de Sistemas <ul><li>Componentes Típicos </li></ul><ul><li>Precio Fijo. </li></ul><ul><li>Desarrollo Standard. </li></ul><ul><li>Manejo de Subcontratistas. </li></ul><ul><li>Test de Aceptación. </li></ul><ul><li>Garantizar el Funcionamiento. </li></ul>
  64. 64. Integración de Sistemas
  65. 65. Integración de Sistemas <ul><li>Factores Críticos de Éxito </li></ul><ul><li>Involucrarse tempranamente. </li></ul><ul><li>Acordar relaciones de trabajo con el cliente. </li></ul><ul><li>Acordar relaciones de trabajo con los distintos grupos. </li></ul><ul><li>Efectiva utilización de terceras partes. </li></ul><ul><li>Soporte continuo de la gerencia. </li></ul><ul><li>Capacidad de gerenciamiento Técnico y Comercial de los recursos y capacidades técnicas. </li></ul><ul><li>Mediciones /Incentivos apropiados. </li></ul><ul><li>Seguimiento positivo de logros y éxitos. </li></ul>
  66. 66. Integración de Sistemas <ul><li>¿Qué es un contrato? </li></ul><ul><li>Un acuerdo entre dos ó más partes para hacer ó no hacer alguna cosa definida. </li></ul><ul><li>Un acuerdo exigible por ley. </li></ul>
  67. 67. Desarrollo y Gerenciamiento <ul><li>Objetivos del Manejo de Proyectos </li></ul><ul><li>Producir un resultado o producto definido en total concordancia con el presupuesto y cronograma. </li></ul>
  68. 68. Desarrollo y Gerenciamiento <ul><li>Consideraciones: </li></ul><ul><ul><li>Cada cliente tiene necesidades únicas. </li></ul></ul><ul><ul><li>Cada proyecto tiene único requerimientos, cronogramas, ambientes, etc.. </li></ul></ul><ul><li>Manejo de un proyecto debe ser: </li></ul><ul><ul><li>Flexible. </li></ul></ul><ul><ul><li>Adaptado a un proyecto específico. </li></ul></ul><ul><ul><li>Trabajado/Adaptado continuamente para asegurar el éxito. </li></ul></ul>
  69. 69. Desarrollo y Gerenciamiento <ul><li>Principales causas de problemas </li></ul><ul><li>Tomar compromisos anticipadamente a la definición de requerimientos. </li></ul><ul><li>Baja estimación del alcance y complejidad del proyecto. </li></ul><ul><li>Aceptar cambios sin una clara valoración del impacto sobre el costo y plan del proyecto. </li></ul><ul><li>No totalmente definido y/o manejado el riesgo. </li></ul><ul><li>Incompleto manejo de los Subcontratistas. </li></ul>
  70. 70. Desarrollo y Gerenciamiento <ul><li>La actividad de subcontratar desarrollo de Software es uno de los </li></ul><ul><li>mayores riesgos. </li></ul><ul><li>Para contener el riesgo se debe trabajar con los subcontratistas. </li></ul><ul><li>Desarrollar un plan de gerenciamiento: </li></ul><ul><ul><ul><li>Asegurar que el/los subcontratista/s tengan aceptables desarrollos. </li></ul></ul></ul><ul><ul><ul><li>Metodología - Ciclo de vida de desarrollo. </li></ul></ul></ul><ul><ul><ul><li>Estándares - Codificación, Documentación, Planes de Testeo, etc. </li></ul></ul></ul><ul><ul><ul><li>Asegurarnos que los subcontratistas nos entienden. </li></ul></ul></ul><ul><ul><ul><li>Requerimientos para inspecciones. </li></ul></ul></ul><ul><ul><ul><li>Criterios de Aceptación. </li></ul></ul></ul><ul><ul><ul><li>Educar, entrenar y dar dirección de gerenciamiento donde hay déficit de conocimientos. </li></ul></ul></ul><ul><ul><ul><li>Regularmente revisar sus progresos. </li></ul></ul></ul><ul><ul><ul><li>Proveer un efectiva interface el/los sub/s y el Cliente. </li></ul></ul></ul><ul><ul><ul><li>Ayudarlos a tener Éxito. </li></ul></ul></ul>
  71. 71. <ul><li>Gerente de Proyecto </li></ul><ul><li>Único punto de responsabilidad para alcanzar todos los compromisos del Proyecto. </li></ul><ul><li>Representar la empresa frente al cliente en todos los temas del Proyecto. </li></ul><ul><li>Puede delegar tareas en otros pero retiene la totalidad de la Responsabilidad. </li></ul><ul><li>El Cliente y cada subcontratista deben identificar un correspondiente Gerente de Proyecto como la primer interface. </li></ul>Desarrollo y Gerenciamiento
  72. 72. <ul><li>Manejo del Riesgo </li></ul><ul><li>El manejo esta siempre presente a través del ciclo de vida de un sistema. </li></ul><ul><li>Desafiar cada suposición hecha sobre el programa. </li></ul><ul><li>La fase de propuesta es el período de tiempo Crítico. </li></ul><ul><li>Se requiere Identificación temprana, Evaluación y Planeamiento de la contención. </li></ul>Desarrollo y Gerenciamiento
  73. 73. <ul><li>Manejo del Riesgo </li></ul><ul><li>Resistir la tentación de dimensionar el riesgo demasiado bajo. </li></ul><ul><ul><li>Una medida de la calidad de la propuesta es una realista y contenida evaluación del riesgo. </li></ul></ul><ul><ul><li>NO BAJO RIESGO. </li></ul></ul><ul><li>El Mayor Riesgo determina el Mayor Precio para el Cliente. </li></ul><ul><ul><li>VERDADERO- Pero compartiendo parte de nuestra evaluación de riesgo y planes de contención con el cliente se demostrará nuestro profesionalismo. </li></ul></ul>Desarrollo y Gerenciamiento
  74. 74. <ul><li>Sumario </li></ul><ul><li>El éxito del Gerenciamiento de Proyecto requiere </li></ul><ul><li>del Gerente de Proyecto y del Equipo del Proyecto: </li></ul><ul><li>Entender </li></ul><ul><li>El proceso de desarrollo. </li></ul><ul><li>Los requerimientos. </li></ul><ul><li>La solución. </li></ul><ul><li>Planificar </li></ul><ul><li>La implementación. </li></ul><ul><li>La organización. </li></ul>Desarrollo y Gerenciamiento
  75. 75. <ul><li>Sumario </li></ul><ul><li>Manejar </li></ul><ul><li>Los recursos del Proyecto (Propios, del Cliente y Sucontratistas). </li></ul><ul><li>El Plan. </li></ul><ul><li>El Riego. </li></ul><ul><li>Controlar </li></ul><ul><li>El progreso. </li></ul><ul><li>Los problemas. </li></ul><ul><li>Los cambios. </li></ul>Desarrollo y Gerenciamiento
  76. 76. Trabajo en Equipo ¿De quién es el trabajo?
  77. 77. Primeras Restricciones <ul><li>Fechas de entrega. </li></ul><ul><li>Presupuesto. </li></ul><ul><li>Disponibilidad del Personal. </li></ul>
  78. 78. Planificación Temporal <ul><li>Identificar tareas. </li></ul><ul><li>Fijar interdependencias entre tareas. </li></ul><ul><li>Estimar esfuerzo de cada tarea. </li></ul><ul><li>Asignar personal. </li></ul><ul><li>Construir la red. </li></ul><ul><li>Establecer el camino crítico. </li></ul>
  79. 79. Análisis de Riesgos <ul><li>Identificación. </li></ul><ul><li>Cálculo. </li></ul><ul><li>Priorización. </li></ul><ul><li>Estrategias de control. </li></ul><ul><li>Resolución. </li></ul><ul><li>Supervisión. </li></ul>
  80. 80. Trabajo en Equipo <ul><li>Esta es la historia acerca de cuatro personas llamadas TODOS, ALGUIEN, CUALQUIERA y NADIE . </li></ul><ul><li>“ Había que cumplir una tarea muy importante, y se le ordenó a TODOS hacerla. TODOS estaban seguros de que ALGUIEN lo haría, pero NADIE lo hizo. ALGUIEN se enojó, porque era un trabajo de TODOS. </li></ul><ul><li>TODOS pensaron que CUALQUIERA pudo haberlo hecho, pero NADIE se dio cuenta de que TODOS no lo iban a hacer. Al fin, TODOS acusaron a ALGUIEN cuando NADIE hizo lo que CUALQUIERA pudo haberlo hecho”. </li></ul>
  81. 81. Trabajo en Equipo <ul><li>Una aproximación: </li></ul><ul><li>Una reunión de gente trabajando coordinadamente, por un objetivo común, que logra un mejor resultado que los que obtendrían los mismos individuos trabajando por su cuenta. </li></ul>
  82. 82. Trabajo en Equipo <ul><li>¿Qué es Trabajo en Equipo? </li></ul><ul><ul><li>(por lo que No es) </li></ul></ul><ul><ul><li>No es reunionismo. </li></ul></ul><ul><ul><li>No es necesariamente toma de decisiones en equipo. </li></ul></ul><ul><ul><li>No es perdida de individualidad. </li></ul></ul><ul><ul><li>No es perdida de autoridad. </li></ul></ul>
  83. 83. Trabajo en Equipo <ul><li>¿Qué es Trabajo en Equipo? </li></ul><ul><ul><li>(por lo que Si es) </li></ul></ul><ul><ul><li>Tener un objetivo ó meta común. </li></ul></ul><ul><ul><li>Estar dispuesto a sacrificar intereses. personales ó del grupo, momentáneamente. </li></ul></ul><ul><ul><li>Tener confianza en los demás. </li></ul></ul><ul><ul><li>Disposición a compartir información. </li></ul></ul><ul><ul><li>Sentir en carne propia los problemas ajenos. </li></ul></ul>
  84. 84. Trabajo en Equipo <ul><li>Diagnosticando la salud del grupo </li></ul><ul><ul><li>Intercomunicación entre los miembros del grupo. </li></ul></ul><ul><ul><li>Objetividad del grupo con respecto a su propio funcionamiento. </li></ul></ul><ul><ul><li>Responsabilidad interdependiente de todos los miembros. </li></ul></ul><ul><ul><li>Adecuada coherencia del grupo. </li></ul></ul>
  85. 85. Métricas - Línea Base <ul><li>Beneficios: </li></ul><ul><li>Estratégicos. </li></ul><ul><li>Proyecto. </li></ul><ul><li>Técnicos. </li></ul>
  86. 86. ¿Por qué fallan las estimaciones ?
  87. 87. Factores claves <ul><li>Cambio constante en los requerimientos. </li></ul><ul><li>Falta de técnicas. </li></ul><ul><li>Falta de planificación. </li></ul><ul><li>Ausencia de recaudos. </li></ul><ul><li>Falta de conocimiento de procesos de </li></ul><ul><li>estimación. </li></ul><ul><li>Mal manejo de problemas políticos. </li></ul><ul><li>No tomar como base casos anteriores. </li></ul>
  88. 88. <ul><li>Factores clave para estimar bien: </li></ul><ul><li>Disponibilidad de registros precisos sobre proyectos anteriores. </li></ul><ul><li>Adopción de metodologías estándar. </li></ul><ul><li>Estos dos factores ayudaran a concebir las métricas. </li></ul>Factores Claves
  89. 89. Métricas del proyecto ¿Por qué métricas ?
  90. 90. Métricas Que miden Productividad Calidad Beneficios Futuras Estimaciones Medidas Directas Indirectas
  91. 91. ¿Qué se puede medir ? <ul><li>El proceso del software (para mejorarlo). </li></ul><ul><li>El proyecto del software (para ayudar a estimar, control de calidad, evaluación de productividad, control de proyectos). </li></ul><ul><li>Calidad del producto (para ayudar el la toma de decisiones tácticas a medida que el proyecto evoluciona). </li></ul>
  92. 92. Medidas , métricas e indicadores <ul><li>Medida: Indicación cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto. </li></ul><ul><li>Medición: Es el acto de determinar una medida. </li></ul><ul><li>Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. </li></ul><ul><li>Indicador: Es una métrica o una combinación de métricas que proporcionan una visión profunda del proceso del SW, del proyecto del SW o del producto en sí. </li></ul>
  93. 93. Mediciones del software <ul><li>Las mediciones del mundo físico se pueden clasificar de dos maneras: </li></ul><ul><ul><li>Medidas directas : Ej. Longitud de un tornillo </li></ul></ul><ul><ul><li>Medidas indirectas : Ej. Calidad de los tornillos producidos, medidos contando los artículos defectuosos </li></ul></ul><ul><li>Las métricas del SW, se categorizan de forma similar </li></ul><ul><ul><li>Directas: líneas de código producidas (LDC), velocidad de ejecución, tamaño de memoria </li></ul></ul><ul><ul><li>Indirectas: funcionalidad, calidad, complejidad. </li></ul></ul>
  94. 94. Costo y métricas de calidad <ul><li>Defecto/fallo Vs. Error </li></ul><ul><li>Defecto y fallo: son sinónimos dentro del contexto del proceso del software. Implican un problema de calidad que es descubierto una vez entregado el software al cliente. </li></ul><ul><li>Error: Problema de calidad detectado por los ingenieros u otros dentro del proceso del software. </li></ul>
  95. 95. <ul><li>Revisiones técnicas formales </li></ul><ul><li>Encontrar errores durante el proceso de forma que no se conviertan en defectos después de la entrega. </li></ul><ul><li>Tratar de descubrir errores al principio para que no se propaguen al paso siguiente del proceso del software. </li></ul>Costo y métricas de calidad
  96. 96. <ul><li>Las actividades de diseño introducen entre el 50 al 65 % de todos los errores (y en último lugar todos los defectos). </li></ul><ul><li>Sin embargo, se ha demostrado que las revisiones técnicas formales (RTF) son efectivas en un 75 % a la hora de detectar errores. </li></ul><ul><li>Con la detección y eliminación de un gran porcentaje de errores, el RTF reduce el costo de los pasos siguientes en la fase de desarrollo y de mantenimiento. </li></ul>Costo y métricas de calidad
  97. 97. <ul><li>Datos basados en Experiencia </li></ul><ul><li>Implementating software inspections IBM </li></ul><ul><li>Error descubierto en diseño cuesta corregirlo 1,0 unidad monetaria </li></ul><ul><li>Tomando la medida como base </li></ul><ul><li>Antes de la prueba 6,5 unidades </li></ul><ul><li>Durante la prueba 15 unidades </li></ul><ul><li>Después de la entrega 60-100 unidades </li></ul>Costo y métricas de calidad
  98. 98. Indicadores Proyecto/Proceso <ul><li>Indicadores de proceso: Permiten a una organización de ingeniería del software tener una visión profunda de la eficacia de un proceso ya existente. (las métricas del proceso se recopilan de todos los proyectos y durante un largo período de tiempo) </li></ul><ul><li>Indicadores de proyecto: Permiten al gestor de proyectos del SW (1) evaluar el estado de un proyecto en curso; (2) seguir la pista de los riesgos potenciales; (3) detectar la áreas de problemas antes de que se conviertan en críticas; (4) ajustar el flujo y las tareas del trabajo; (5) evaluar la habilidad del equipo. </li></ul>
  99. 99. Métricas orientadas al tamaño <ul><li>Si una organización mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño. </li></ul>
  100. 100. Métricas simples - orientadas al tamaño- <ul><li>Errores por KLDC (miles de líneas de código, KiloLDC). </li></ul><ul><li>Defectos por KLDC. </li></ul><ul><li>Páginas de documentos por KLDC. </li></ul><ul><li>Errores/persona-mes. </li></ul><ul><li>LDC/persona mes. </li></ul>
  101. 101. Para lograr buenas métricas <ul><li>Utilice el sentido común y una sensibilidad organizativa al interpretar datos de métricas. </li></ul><ul><li>No utilice métricas para evaluar a particulares. </li></ul><ul><li>Trabaje con profesionales y equipos para establecer objetivos claros y métricas que se vayan a utilizar para alcanzarlos. </li></ul><ul><li>No utilice nunca métricas que amenacen a particulares y/o equipos. </li></ul>
  102. 102. Factor de complejidad <ul><li>Evaluar cada factor en una escala de 0 a 5 </li></ul><ul><li>0 No influencia. </li></ul><ul><li>1 Incidental. </li></ul><ul><li>2 Moderado. </li></ul><ul><li>3 Medio. </li></ul><ul><li>4 Significativo. </li></ul><ul><li>5 Esencial. </li></ul>
  103. 103. <ul><li>No sabemos si estamos mejorando </li></ul><ul><li>No podemos establecer metas </li></ul>¿Qué pasa si no medimos?
  104. 104. <ul><li>Duración de entrevistas. </li></ul><ul><li>Extrapolación. </li></ul><ul><li>Estándares de programación. </li></ul>Otras Técnicas
  105. 105. Sugerencias para lograr buenas métricas <ul><li>Utilice el sentido común y una sensibilidad organizativa al interpretar datos de métricas. </li></ul><ul><li>No utilice métricas para evaluar a particulares. </li></ul><ul><li>Trabaje con profesionales y equipos para establecer objetivos claros y métricas que se vayan a utilizar para alcanzarlos. </li></ul><ul><li>No utilice nunca métricas que amenacen a particulares y/o equipos. </li></ul>
  106. 106. Estimaciones - Factores de riesgo <ul><li>Tamaño del esfuerzo. </li></ul><ul><li>Grado de estructuración, definición y variabilidad. </li></ul><ul><li>Complejidad basada en esfuerzos pasados. </li></ul>
  107. 107. Ambito del Software <ul><li>Función. </li></ul><ul><li>Rendimiento. </li></ul><ul><li>Restricciones. </li></ul><ul><li>Interfaces. </li></ul><ul><li>Fiabilidad. </li></ul>
  108. 108. Recursos <ul><li>Humanos. </li></ul><ul><li>Hardware. </li></ul><ul><li>Software. </li></ul><ul><li>Reusabilidad. </li></ul>
  109. 109. Control de calidad del software
  110. 110. Control de calidad del software <ul><li>Mito </li></ul><ul><li>La calidad del software es algo en lo que se empieza a preocupar una vez que se ha generado el código. </li></ul><ul><li>NO ! </li></ul>
  111. 111. <ul><li>Calidad: Una característica o atributo de algo. </li></ul><ul><ul><li>Como atributo de un artículo, la calidad se refiere a las características mensurables. </li></ul></ul><ul><ul><ul><li>Cosas que se pueden comparar con estándares: Longitud, color, etc </li></ul></ul></ul><ul><ul><li>Sin embargo el SW como entidad intelectual es mas difícil. </li></ul></ul><ul><ul><ul><li>Complejidad ciclomática, cohesión, líneas de código. </li></ul></ul></ul>Control de calidad del software
  112. 112. <ul><li>Calidad </li></ul><ul><li>De Diseño: características que especifican los Ingeniería del SW para un artículo.(grado de materiales, tolerancias, especificaciones de rendimiento) – Etapa de diseño. </li></ul><ul><li>Calidad de concordancia: grado de cumplimiento de las especificaciones de diseño – Etapa de implementación </li></ul>Control de calidad del software
  113. 113. <ul><li>Control de calidad </li></ul><ul><li>Es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. </li></ul><ul><li>Feedback </li></ul><ul><li>Las actividades de control pueden ser </li></ul><ul><ul><li>Manuales </li></ul></ul><ul><ul><li>Automatizadas </li></ul></ul><ul><ul><li>Combinación </li></ul></ul>Control de calidad del software
  114. 114. <ul><li>Garantía de calidad: o aseguramiento de </li></ul><ul><li>La calidad, consiste en la auditoría y las </li></ul><ul><li>funciones de gestión. </li></ul><ul><li>Esto asegura que la calidad del producto se está cumpliendo y de no ser así es responsabilidad del área de control afrontar los problemas y revisiones </li></ul>Control de calidad del software
  115. 115. <ul><li>Costo de la calidad Incluye los costos asociados a la búsqueda de la calidad o relacionados en la obtención de la calidad </li></ul><ul><ul><li>Prevención </li></ul></ul><ul><ul><ul><li>Planificación de la calidad </li></ul></ul></ul><ul><ul><ul><li>Revisiones técnicas formales </li></ul></ul></ul><ul><ul><ul><li>Equipo de pruebas </li></ul></ul></ul><ul><ul><ul><li>Formación </li></ul></ul></ul><ul><ul><li>Evaluación </li></ul></ul><ul><ul><ul><li>Inspección en el proceso y entre procesos </li></ul></ul></ul><ul><ul><ul><li>Mantenimiento de equipos </li></ul></ul></ul><ul><ul><ul><li>Pruebas </li></ul></ul></ul>Control de calidad del software
  116. 116. <ul><li>Fallos (antes de ser entregados al cliente) </li></ul><ul><ul><li>Revisión. </li></ul></ul><ul><ul><li>Reparación. </li></ul></ul><ul><ul><li>Análisis de modalidades de fallos. </li></ul></ul><ul><li>Fallos externos (ya entregado al cliente) </li></ul><ul><ul><li>Resolución de quejas. </li></ul></ul><ul><ul><li>Devolución y sustitución de productos. </li></ul></ul><ul><ul><li>Soporte en línea. </li></ul></ul><ul><ul><li>Trabajo de garantía. </li></ul></ul>Control de calidad del software
  117. 117. Control de calidad del software <ul><li>La garantía de calidad del software </li></ul><ul><li>(SQA)Software Quality assurance) es una </li></ul><ul><li>actividad de protección que se aplica a lo largo de todo el proceso de ingeniería del software. </li></ul>
  118. 118. <ul><li>La SQA engloba un enfoque de gestión de calidad; tecnología de ingeniería del software efectiva (métodos y herramientas), revisiones técnicas formales que se aplican durante el proceso del software; una estrategia de software multiescalada; control de la documentación del software y de los cambios realizados, un procedimiento que asegure un ajuste a los estándares de desarrollo del software (cuando sea posible); y mecanismos de medición y de generación de informes. </li></ul>Control de calidad del software
  119. 119. <ul><li>Calidad del software </li></ul><ul><li>Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado </li></ul>Control de calidad del software
  120. 120. <ul><li>Variación entre muestras </li></ul><ul><li>Ejemplos : </li></ul><ul><ul><li>Circuitos integrados </li></ul></ul><ul><ul><li>Rutina de búsqueda </li></ul></ul><ul><ul><li>Hay que reducir la variación es el centro de control de calidad. </li></ul></ul>Control de calidad del software
  121. 121. <ul><li>Ejemplo: Queremos reducir la diferencia entre los recursos necesarios planificados para terminar proyecto y los recursos reales utilizados (personas, equipo y tiempo). </li></ul><ul><ul><li>Reducción de errores ocultos. </li></ul></ul><ul><ul><li>Reducción de diferencias de velocidad. </li></ul></ul><ul><ul><li>Precisión en respuestas de soporte. </li></ul></ul>Control de calidad del software
  122. 122. <ul><ul><li>Los requisitos del software son la base de las medidas de calidad. </li></ul></ul><ul><ul><li>Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del SW. </li></ul></ul><ul><ul><li>Existe un conjunto de requisitos implícitos que a menudo no se mencionan (Ej. buen mantenimiento) </li></ul></ul>Control de calidad del software
  123. 123. <ul><li>Actividades del SQA </li></ul><ul><li>Ingeniería del SW: Aplican métodos técnicos sólidos y medidas, realizando revisiones técnicas formales y llevando a cabo pruebas del software bien planificadas. </li></ul><ul><li>Auditoria y control de gestión </li></ul>Control de calidad del software
  124. 124. <ul><li>Propósito del plan </li></ul><ul><li>Referencia </li></ul><ul><li>Gestión. </li></ul><ul><ul><li>Organización. </li></ul></ul><ul><ul><li>Tareas. </li></ul></ul><ul><ul><li>Responsabilidad. </li></ul></ul><ul><li>Documentación. </li></ul><ul><ul><li>Propósito </li></ul></ul><ul><ul><li>Documentos requeridos de ingeniería del software </li></ul></ul><ul><ul><li>Otros documentos </li></ul></ul><ul><li>Estándares, prácticas y convenciones </li></ul>Control de calidad del software
  125. 125. Manejo de Riesgo del Proyecto
  126. 126. Manejo de Riesgo del Proyecto Una Definición En primer lugar, el riesgo concierne a lo que ocurra en el futuro. El hoy y el ayer ya no nos conciernen realmente, porque ahora ya estamos recogiendo los frutos de lo que sembramos en el pasado. La cuestión es si podemos, entonces, modificando nuestras acciones de este momento, crear una oportunidad para una situación diferente y mas esperanzada de nuestro mañana. Esto significa, en segundo lugar, que el riesgo implica un cambio que puede venir dado por cambios de opiniones, acciones ó lugares….(En tercer lugar), el riesgo implica una elección, y falta de certeza de que la elección sea la correcta. Así, paradójicamente, el riesgo, como la muerte ó los impuestos, es una de las pocas cosas inevitables de la vida. Robert Charette
  127. 127. Manejo del Riesgo del Proyecto <ul><li>¿Que es Riesgo? </li></ul><ul><li>Riesgo es un evento posible, indeseable y no planificable que puede resultar en la no concreción de uno o más de los objetivos del proyecto . </li></ul><ul><li>El Riesgo tiene tres componentes </li></ul><ul><ul><li>Un evento </li></ul></ul><ul><ul><li>Probabilidad de ocurrencia de ese evento </li></ul></ul><ul><ul><li>Impacto de ese evento </li></ul></ul><ul><li>Nota : Todos los proyectos tienen riesgos. Si los riesgos son ignorados, Ud. esta incrementando la probabilidad que el proyecto pueda fallar de alguna manera. </li></ul>
  128. 128. Manejo del Riesgo del Proyecto <ul><li>¿Porque Manejo del Riesgo? </li></ul><ul><li>Para Proteger </li></ul><ul><ul><li>Costo. </li></ul></ul><ul><ul><li>Cronogramas. </li></ul></ul><ul><ul><li>Requerimientos. </li></ul></ul><ul><li>Prevenir sorpresas </li></ul><ul><li>Focalizarnos en producir la oferta correcta la primer vez. </li></ul><ul><li>Prevenir a la gerencia por las crisis </li></ul><ul><li>Prevenir/minimizar los problemas antes de su ocurrencia ó, si estos ocurren, antes que crezcan. </li></ul>
  129. 129. Manejo del Riesgo del Proyecto <ul><li>El Manejo de Riesgo de un proyecto incluye los procesos relacionados con la identificación, análisis y tratamiento del riesgo del proyecto. </li></ul><ul><li>Lo cual implica la maximización de los eventos positivos y la minimización de las consecuencias de los eventos negativos. </li></ul>
  130. 130. Manejo del Riesgo del Proyecto <ul><li>Los principales procesos del Manejo de Riesgo del proyecto son: </li></ul><ul><li>Identificación del riesgo, determinando cuales riesgos son potenciales a afectar el proyecto, documentando las características de cada uno. </li></ul><ul><li>Clasificación del riesgo, evaluando riesgos e interacciones entre riesgos para dimensionar los resultados posibles del proyecto. </li></ul><ul><li>Desarrollo de la respuesta al riesgo, definición de los paso para la intensificación de las oportunidades y el manejo de las amenazas. </li></ul><ul><li>Control de la respuesta al riesgo, respondiendo a los cambios en el riesgo sobre el curso de acción del proyecto. </li></ul>
  131. 131. Manejo del Riesgo del Proyecto <ul><li>Identificación del Riesgo: </li></ul><ul><li>Internos/Externos </li></ul><ul><ul><li>Asignaciones del Staff/Estimaciones de Costo. </li></ul></ul><ul><ul><li>Campos del Mercado/Acciones del Gobierno. </li></ul></ul><ul><li>Del Proyecto </li></ul><ul><ul><li>Presupuestarios/de Agenda/de Recursos/del Cliente. </li></ul></ul><ul><li>Técnicos </li></ul><ul><ul><li>Diseño/Implementación/Tecnología de Punta. </li></ul></ul><ul><li>Del Negocio </li></ul><ul><ul><li>Excelente Producto que Nadie Quiere/Pérdida del Soporte de los gestores. </li></ul></ul><ul><ul><li>Pérdidas Presupuestarias y/o de Personal. </li></ul></ul>
  132. 132. Manejo del Riesgo del Proyecto <ul><li>Clasificación del Riesgo: </li></ul><ul><ul><li>Probabilidad de que riesgo ocurra (sea real). </li></ul></ul><ul><ul><li>Consecuencias del riesgo sobre el proyecto. </li></ul></ul><ul><li>Actividades para la calificación del riesgo. </li></ul><ul><ul><li>Establecimiento de una escala que refleje la probabilidad del riesgo. </li></ul></ul><ul><ul><li>Definición de las consecuencias del riesgo. </li></ul></ul><ul><ul><li>Estimación del impacto del riesgo. </li></ul></ul><ul><ul><li>Documentación de la exactitud general de la proyección del riesgo. </li></ul></ul>
  133. 133. Manejo del Riesgo del Proyecto <ul><li>Desarrollo de la respuesta al riesgo: </li></ul><ul><li>Invalidación </li></ul><ul><ul><li>Eliminación de una amenaza, usualmente por eliminación de la causa. </li></ul></ul><ul><li>Mitigación </li></ul><ul><ul><li>Reducción de la probabilidad de ocurrencia del riesgo, reducción del impacto del riesgo en el proyecto ó ambos. </li></ul></ul><ul><li>Aceptación </li></ul><ul><ul><li>Activa, desarrollo de un plan de contingencia. </li></ul></ul><ul><ul><li>Pasiva, aceptación de una menor ganancia en caso de ocurrencia. </li></ul></ul>
  134. 134. Manejo del Riesgo del Proyecto <ul><li>Mensajes claves del Manejo de Riesgos </li></ul><ul><li>Manejar el riesgo es esencial para el éxito del proyecto. </li></ul><ul><li>El riesgo incluye oportunidades de ganar así como potencialmente de perder. </li></ul><ul><li>Manejar el riesgo requiere disciplina. </li></ul><ul><li>El Manejo del riesgo es un proceso repetitivo hecho a través del ciclo de vida del proyecto. </li></ul><ul><li>El Riesgo puede ser MANEJADO </li></ul>

×