Post on 15-Jun-2020
M.C. Martín Olguín (C) 2004
Análisis Orientado a ObjetosIngeniería del Software
M.C. José Martín Olguín Espinoza
M.C. Martín Olguín (C) 2004
Contenido del Curso1.Introducción a la Ingeniería de Software
1.1. Definiciones de Ingeniería de Software1.2. Características del Software1.3. Aplicaciones del Software1.4. Fases básicas del desarrollo del software
(definición, desarrollo, mantenimiento).
M.C. Martín Olguín (C) 2004
…Contenido del Curso2.Modelos de Proceso del Software
2.1. Modelo en Cascada (ciclo de vida clásico)2.2. Modelo en “V”2.3. Modelo de Construcción de Prototipos 2.4. Modelos Evolutivos
2.4.1. Modelo Incremental2.4.2. Modelo Espiral2.4.3. Modelo Espiral WIN-WIN
M.C. Martín Olguín (C) 2004
...Contenido del Curso3.El Proceso Unificado de Desarrollo (RUP)
3.1. Antecedentes3.2. Dirigido por casos de uso3.3. Centrado en la Arquitectura3.4. Iterativo e Incremental
M.C. Martín Olguín (C) 2004
…Contenido del Curso4.Administración de proyectos de software
4.1. Componentes de un proyecto de software4.2. Personal4.3. Producto4.4. Proceso4.5. Proyecto
M.C. Martín Olguín (C) 2004
…Contenido del Curso5.Conceptos del Paradigma OO
5.1. El paradigma orientado a objetos5.2. Clases y Objetos5.3. Atributos5.4. Operaciones, métodos y servicios5.5. Mensajes5.6. Encapsulamiento5.7. Herencia5.8. Polimorfismo
M.C. Martín Olguín (C) 2004
…Contenido del Curso6.El UML
6.1. Vistas6.1.1. Vista de Casos de Uso6.1.2. Vista lógica6.1.3. Vista de Componentes6.1.4. Vista de la Implementación6.1.5. Clasificadores y mecanismos de
extensión
M.C. Martín Olguín (C) 2004
...Contenido del Curso6.2. Diagramas
6.2.1. Diagramas de caso de uso6.2.2. Diagramas de clases6.2.3. Diagramas de objetos6.2.4. Diagramas de estado6.2.5. Diagramas de secuencia6.2.6. Diagramas de colaboración6.2.7. Diagramas de actividad6.2.8. Diagramas de componentes6.2.9. Diagramas de implementación
M.C. Martín Olguín (C) 2004
...Contenido del Curso7.Ingeniería de Requisitos y Análisis OO
7.1. Especificación de Requisitos7.2. Modelo de Análisis
8.Diseño OO8.1. Modelo de Diseño8.2. Arquitectura del Software8.3. Patrones de Diseño
M.C. Martín Olguín (C) 2004
...Contenido del Curso9.Implementación
9.1. Programación Orientada a Objetos9.2. Modelo de Implementación
10. Pruebas OO10.1. Conceptos10.2. Pruebas del modelo de análisis y el de diseño10.3. Pruebas de unidad10.4. Pruebas de integración10.5. Pruebas de validación
M.C. Martín Olguín (C) 2004
...Contenido del Curso11. Métricas OO
11.1. Conceptos11.2. Métricas para el modelo de diseño OO11.3. Métricas orientadas a clases11.4. Métricas orientadas a operaciones
M.C. Martín Olguín (C) 2004
Bibliografía1. Ingeniería del Software: un enfoque
práctico. 5ta edición.Roger PressmanMcGraw-Hill
2. Ingeniería de Software Orientado a ObjetosBernd BrueggePearson Educación
3. The Rational Unified ProcessPhilippe KrutchenAddison-Wesley
M.C. Martín Olguín (C) 2004
...Bibliografía1. The Unified Modeling Language. User Guide
Grady Booch, James Rumbaugh, Ivar JacobsonAddison-Wesley
2. Design PatternsErich GammaAddison-Wesley
3. El Proceso Unificado de Desarrollo de SoftwareIvar Jacobson, Grady Booch y James RumbaughAddison-Wesley
M.C. Martín Olguín (C) 2004
Unidad 1
Introducción a la Ingeniería del Software
M.C. Martín Olguín (C) 2004
Software Es el conjunto de programas de
cómputo, documentos asociados y esquemas de configuración necesarios para que estos programas operen.[Sommerville, 2001]
M.C. Martín Olguín (C) 2004
Ingeniería del Software Definiciones del prólogo a la cuarta
edición en español de “Ingeniería del Software: un enfoque práctico” de Roger Pressman:
Definición 1: Ingeniería del Software es el estudio de los
principios y metodologías para desarrollo y mantenimiento de sistemas de software. [Zelkovitz, 1978]
M.C. Martín Olguín (C) 2004
Ingeniería del Software Definición 2:
Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software. [Bohem, 1976]
M.C. Martín Olguín (C) 2004
Ingeniería del Software Definición 3:
Ingeniería del software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales. [Bauer, 1972]
M.C. Martín Olguín (C) 2004
Ingeniería del Software Definición 4:
1. La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de ingeniería al software. 2. El estudio de enfoques como en (1) [IEEE, 1993]
M.C. Martín Olguín (C) 2004
Ingeniería del Software Definición 5:
Es una disciplina que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza. [Sommerville, 2001]
M.C. Martín Olguín (C) 2004
Ingeniería de Software e Ingeniería de Sistemas
Ingeniería de Sistemas
Ingeniería de
Software
Teoría de Sistemas
M.C. Martín Olguín (C) 2004
Sistema Un sistema es una colección de
componentes interrelacionados que trabajan conjuntamente para cumplir algún objetivo.
M.C. Martín Olguín (C) 2004
Ingeniería de Sistemas La ingeniería de sistemas consiste en la
actividad de especificar, diseñar, implementar, validar, distribuir y mantener sistemas como un todo.
Los ingenieros de sistemas no sólo están relacionados con el software, sino también con el hardware y las interacciones del sistema con los usuarios y su entorno.
M.C. Martín Olguín (C) 2004
Características del Software El software se desarrolla, no se fabrica. El software no se descompone, se echa a
perder. Aunque la industria tiende a ensamblar
componentes, la mayoría del software es hecho a la medida.
M.C. Martín Olguín (C) 2004
Atributos de un buen software Mantenibilidad
El software debe poder evolucionar para cumplir con las necesidades de cambio de los clientes.
Confiabilidad El software debe ser fiable, seguro, no debe causar daños físicos o
económicos en el caso de una falla del sistema. Eficiencia
El software debe aprovechar al máximo los recursos del sistema. Usabilidad
El software debe ser fácil de utilizar.
M.C. Martín Olguín (C) 2004
Aplicaciones del Software Software de sistemas Software de tiempo real Software de gestión Software de ingeniería y científico Software empotrado Software de PC’s Software basado en Web Software de IA
M.C. Martín Olguín (C) 2004
Tarea Leer de Pressman la sección 1.4 Mitos del
Software y discutir en clase cada uno de los mitos presentados.
M.C. Martín Olguín (C) 2004
Unidad 2
Modelos de Proceso del Software
M.C. Martín Olguín (C) 2004
Proceso de Software Es un conjunto de actividades y
resultados asociados, que generan un producto de software, las cuales son llevadas a cabo por los ingenieros de software.
M.C. Martín Olguín (C) 2004
Actividades comunes a todo Proceso de Software
Especificación Diseño e implementación Validación Evolución
Distintos procesos organizan estas actividades de diferentes formas y las describen a diferente nivel de detalle.
Organizaciones diferentes utilizan procesos diferentes
M.C. Martín Olguín (C) 2004
Modelos de Proceso del software Es una descripción de un proceso del
software que se presenta desde una perspectiva particular. Es una abstracción de un proceso real.
Existe una gran variedad de modelos o paradigmas de desarrollo de software: Enfoque de Cascada Desarrollo Evolutivo Desarrollo Formal Desarrollo basado en la reutilización
M.C. Martín Olguín (C) 2004
Modelo de Cascada
Definición de requerimientos
Diseño de sistemas y de software
Implementación yPrueba de unidades
Integración yprueba del sistema
Operación ymantenimiento
Royce, 1970“Managing the development ofLarge software systems: ConceptsAnd techniques”IEEE Conference, Los AngelesAdoptado por el DoD
M.C. Martín Olguín (C) 2004
Modelo en “V”
Definición de requerimientos
Diseño de sistemas
Diseño de programas
Codificación
Pruebas de unidadY de integración
Pruebas de sistema
Pruebas deaceptación
Operación ymantenimiento
M.C. Martín Olguín (C) 2004
Desarrollo Evolutivo Modelo Construcción de prototipos
Bosquejo de ladescripción
Especificación
Desarrollo
Validación
Versión inicial
Versiones intermedias
Versión final
Versiones intermediasVersiones intermedias
M.C. Martín Olguín (C) 2004
Modelo Incremental
Bosquejo de los
requisitos
Definir incrementos
Diseñar la arquitectura
Diseñar incremento
Validarincremento
Integarincremento
Validarsistema
Sistema
finalOrigen del Extreme Programming (XP)
The management of software engineeringMills et al., 1980I BM Systems Journal
Embracing change with extreme programmingBeck, K. 1999IEEE Computer
M.C. Martín Olguín (C) 2004
Modelo en espiral
A spiral model of software development and enhancementBohem, 1988I EEE Computer
M.C. Martín Olguín (C) 2004
Tarea Hacer un ensayo explicando las ventajas y
desventajas de los modelos de proceso de software analizados en clase.
M.C. Martín Olguín (C) 2004
Tarea
Preparar una exposición sobre los siguientes temas: Agile Methods Scrum XP Crystal Test-Driven Design Agile Modeling
Referencia inicial:http://www.agilealliance.org/programs/roadmaps/RoadmapPresentación el miércoles 25 de agosto
M.C. Martín Olguín (C) 2004
CMM (Capability Maturity Model) Desarrollado por el SEI (Software Engineering
Institute) Es un modelo completo basado en un
conjunto de funciones de ingeniería del software que deberían de estar presentes conforme organizaciones alcanzan diferentes niveles de madurez de su proceso.
M.C. Martín Olguín (C) 2004
...CMM
El enfoque del SEI proporciona una medida de la efectividad global de las prácticas de la ingeniería del software de una compañía y establece 5 niveles de madurez del proceso.
Nivel 1: Inicial. Nivel 2: Repetible. Nivel 3: Definido. Nivel 4: Administrado. Nivel 5: Optimización.
M.C. Martín Olguín (C) 2004
Nivel 1: Inicial
El proceso se define ad hoc. Es caótico. El éxito depende del esfuerzo individual.
M.C. Martín Olguín (C) 2004
Nivel 2: Repetible
Se establecen los procesos de administración del proyecto para dar seguimiento a los costos, la planificación y la funcionalidad.
Se toman en cuenta experiencias anteriores para repetir las actividades necesarias en el proceso.
M.C. Martín Olguín (C) 2004
Nivel 3: Definido
Se documenta el proceso para las actividades de administración y de ingeniería.
Se estandariza e integra en un proceso para toda la organización.
Todos los proyectos utilizan una versión documentada y aprobada del proceso.
M.C. Martín Olguín (C) 2004
Nivel 4: Administrado
Se implementan métricas detalladas para los proyectos.
Se establecen estándares de calidad. Mediante la utilización de las métricas se
comprenden y se controlan cuantitativamente tanto los productos como el proceso.
M.C. Martín Olguín (C) 2004
Nivel 5: Optimización
El proceso se mejora continuamente mediante la retroalimentación cuantitativa del proceso, ideas y tecnologías innovadoras.
M.C. Martín Olguín (C) 2004
Auditores CMM
Requisitos: Haber participado en una evaluación en los dos
años anteriores a su solicitud de cursos. Cursar las asignaturas. Ser líder en una evaluación CMM a una
organización dentro de los dos años siguientes a los cursos, asesorado por un tutor certificado.
Obtener la aprobación del tutor.
M.C. Martín Olguín (C) 2004
Tarea
Investigar información sobre organizaciones de software con certificación CMM. Tamaño Tiempo requerido para lograr la certificación Costo
M.C. Martín Olguín (C) 2004
Unidad 3
El Proceso Unificado de Desarrollo (RUP)
M.C. Martín Olguín (C) 2004
El RUP
Rational Unified Process El Proceso Unificado es un proceso de software
genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.
M.C. Martín Olguín (C) 2004
Estructura del RUP
M.C. Martín Olguín (C) 2004
RUP y UML
El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparación de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par.
M.C. Martín Olguín (C) 2004
Características clave del RUP
Dirigido por casos de uso (use-case driven).
Centrado en la arquitectura (architecture-centric).
Iterativo e incremental.
M.C. Martín Olguín (C) 2004
Unidad 4
Administración de Proyectos
M.C. Martín Olguín (C) 2004
Exito en proyectos de software en 1994
Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified.
Resolution Type 2, or project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.
Resolution Type 3, or project impaired: The project is canceled at some point during the development cycle. Fuente: www.standishgroup.com
M.C. Martín Olguín (C) 2004
Exito en Proyectos de Software en 1998
26%
46%
28%Fracaso Total
Excedido (tiempo y/ocosto)Exitoso
Fuente: “Critical Succes Factors in Software Projects”Reel, J.S. IEEE Software mayo de 1999
M.C. Martín Olguín (C) 2004
Administración de proyectos de software Implica la planificación, supervisión y control
del personal, del proceso y de los eventos que ocurren mientras evoluciona el software, desde la fase preliminar hasta la implementación operacional.
M.C. Martín Olguín (C) 2004
Características de los proyectos de software El producto es intangible. No existen procesos de software estándar. Comúnmente los proyectos grandes son
“únicos”.
M.C. Martín Olguín (C) 2004
Las cuatro P's de la administración de proyectos Personal
El factor humano Producto
Objetivos y el ámbito del producto Proceso
Estructura de apoyo para la planeación Proyecto
Administración de la complejidad
M.C. Martín Olguín (C) 2004
Personal Sin duda el elemento más valioso en la
Ingeniería del Software ¿Quiénes participan en un proyecto de
software? Programadores Líder de proyecto Arquitectos de software Usuarios Analistas/Diseñadores Clientes Ingenieros de requerimientos Ingenieros de proceso Ingenieros de pruebas
M.C. Martín Olguín (C) 2004
...Personal
¿Cuáles son las características deseables de un líder de proyecto? Motivador Organizado Innovador Problem Solver
M.C. Martín Olguín (C) 2004
...Personal
¿Cómo se organiza el equipo de trabajo? Marilyn Mantei en “The effect of Programming
Team Structures on Programming Tasks”, 1981, sugiere tres tipos genéricos de organización: Centralizado Controlado (CC): El jefe del equipo se
encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y los miembros del equipo es vertical.
M.C. Martín Olguín (C) 2004
...Personal
Descentralizado Controlado (DC): Un jefe definido que coordina tareas específicas y jefes secundarios con responsabilidades sobre subtareas. La resolución de problemas es una actividad del grupo, la comunicación es horizontal y vertical.
Descentralizado Democrático (DD) o “Egoless”: No tiene un jefe permanente, se nombran de acuerdo a la tarea. La solución de problemas se hacen por consenso. La comunicación es horizontal.
M.C. Martín Olguín (C) 2004
...Personal
¿Qué factores se deben considerar cuando se estructura un equipo de software? Complejidad del proyecto (dificultad del problema,
tamaño del software) Tiempo de desarrollo. Modularidad. Calidad. Comunicación requerida.
M.C. Martín Olguín (C) 2004
...Personal
Discusión sobre ventajas y desventajas de cada tipo de organización.
M.C. Martín Olguín (C) 2004
...Personal
¿Cómo creamos un equipo de alto rendimiento? Según Constantine, L. en “Work Organization:
Paradigms for Project Management and Organization, 1993: Confianza entre los miembros del equipo. Distribución de habilidades de acuerdo al problema. Los inconformistas deben ser excluidos.
M.C. Martín Olguín (C) 2004
...Personal
¿Qué factores pueden contaminar el desempeño de un equipo? Según Jackman, M. en “Homeopathic Remedies
for Team Toxicity”, 1998: Atmósfera de trabajo frenética, malgastan energía y se
descentran de los objetivos Alta frustración causada por factores tecnológicos, del
negocio o personales que provocan fricción entre los miembros del equipo.
M.C. Martín Olguín (C) 2004
...Personal
Procedimientos coordinados pobremente o fragmentados o una definición pobre o impropiamente elegida del modelo de procesos que se convierte en un obstáculo a saltar.
Definición confusa de los papeles a desempeñar produciendo una falta de responsabilidad y la acusación correspondiente.
Continua y repetida exposición al fallo que conduce a una pérdida de confianza y una caída de la moral.
M.C. Martín Olguín (C) 2004
...Personal
¿Cómo evitamos las toxinas que afectan a los equipos de software?
¿Cómo coordinar las acciones de los miembros del equipo?
M.C. Martín Olguín (C) 2004
Tarea
Leer el capítulo 3 del Pressman 5ta. edición Realizar los problemas 3.1, 3.4, 3.6 al 3.11
M.C. Martín Olguín (C) 2004
Tareas de la Administración de Proyectos Estimación del tamaño del proyecto
LDC PF COCOMOII
Planificación temporal Barras de Actividad Red de actividades
Administración del Riesgo Supervisión y Control
M.C. Martín Olguín (C) 2004
Métricas para Estimación Se clasifican en dos:
Medidas relacionadas al tamaño Se relacionan con el tamaño de la salida de alguna
actividad. La métrica más común es Líneas de Código (LDC) Dependen del lenguaje de programación y en general
no es una buena medida para POO. Medidas relacionadas a la función
M.C. Martín Olguín (C) 2004
Medidas Relacionadas a la Función Son medidas que se relacionan con la
funcionalidad del software. Las más comunes son:
Puntos de Función (PF) Puntos de Objeto (PO)
M.C. Martín Olguín (C) 2004
Puntos de Función Es una medida de la funcionalidad entregada
por la aplicación. Es una medida indirecta, a diferencia de
LDC. Propuesta por primera vez en:
Albretch, A.J., “Measuring Application Development Productivity”, Proceedings IBM Application Development Symposium, Octubre 1979.
Consultar en www.ifpug.org versión 4.1
M.C. Martín Olguín (C) 2004
Cálculo de PFFactor de ponderación
Conteo Total (UFP)
=[ ]x10[ ]x7[ ]x5Número de interfaces externas
=[ ]x15[ ]x10[ ]x7Número de archivos
=[ ]x6[ ]x4[ ]x3Número de peticiones de usuario
=[ ]x7[ ]x5[ ]x4Número de salidas de usuario
=[ ]x6[ ]x4[ ]x3Número de entradas de usuario
ComplejoMedioSimpleCuentaParámetros de medición
M.C. Martín Olguín (C) 2004
...Cálculo de PF El UFP (Unadjusted Function Point count) se
multiplica por factores de complejidad del proyecto para obtener el PF final:
PF = UFP x [0.65 + 0.01 x (Fi)]
M.C. Martín Olguín (C) 2004
Fi
14. ¿El diseño facilita los cambios y la usabilidad?
13. ¿El diseño incluye soporte para múltiples instalaciones en diferentes orgs.
12. ¿El diseño incluye conversión e instalación?
11. ¿El diseño del código es reutilizable?
10. ¿Es complejo el procesamiento interno?
9. ¿Son complejas las entradas, salidas, archivos y peticiones?
8. ¿Se actualizan los archivos maestros de forma interactiva?
7. ¿Las entradas interactivas se harán en múltiples pantallas y operaciones?
6. ¿Requiere el sistema entradas de datos interactivas?
5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?
4. ¿Es crítico el rendimiento?
3. ¿Existen funciones de procesamiento distribuido?
2. ¿Se requiere comunicación de datos?
0-51. ¿Requiere el sistema copias de seguridad y de recuperación fiables?
M.C. Martín Olguín (C) 2004
Relación entre LDC y PF
12SQL16PowerBuilder32Visual Basic64C++90Pascal106FORTRAN106COBOL128C320Ensamblador
LDC/PF (media)Lenguaje de Programación
Jones, C. Estimating Software Costs, McGraw-Hill, 1998
M.C. Martín Olguín (C) 2004
Puntos de Objeto También es una medida indirecta del
software. NO es una medida de las clases necesarias
para construir la aplicación. Los elementos que toma en cuenta son:
Pantallas Informes (reportes) Componentes (o código en 3GL)
M.C. Martín Olguín (C) 2004
Cálculo de Puntos ObjetoPeso de la complejidad
Puntos Objeto
=[ ]x10Componente 3GL
=[ ]x8[ ]x5[ ]x2Informes
=[ ]x3[ ]x2[ ]x1Pantallas
ComplejoMedioSimpleTipo de Objeto
Bohem, B., “Anchoring de software process”, IEEE Software, julio 1996
M.C. Martín Olguín (C) 2004
Técnicas de Estimación de Costos
Establece que el trabajo se expande para llenar el tiempo disponible. El costo se determina más por los recursos disponibles que por los objetivos logrados.
Ley de Parkinson
Cuando se han completado proyectos del mismo dominio de la aplicación se estima en base a la experiencia.
Estimación por analogía
Se consultan expertos en las técnicas de desarrollo propuestas y el dominio de la aplicación. Cada uno estima el costo y se consensa después de varias iteraciones.
Opinión de expertos
Utiliza un modelo con información histórica de costos, relaciona una métrica con el costo del proyecto. Se estima la métrica y se predice el esfuerzo.
Modelado del algoritmo de costos
M.C. Martín Olguín (C) 2004
El modelo COCOMO Constructive Cost Model Es un modelo de estimación empírico desarrollado
por Bohem. Se obtuvo recolectando datos de varios proyectos
de software grandes. Como resultado del análisis de los datos se
obtuvieron fórmulas y tablas que se ajustan a las observaciones.
Es muy utilizado y ha tenido seguimiento desde su aparición en 1981.
M.C. Martín Olguín (C) 2004
COCOMO II Es el modelo más reciente Consta de estimación en tres niveles:
Construcción de propotipo inicial Se usa al inicio del proyecto
Diseño inicial Se aplica cuando se tienen la mayoría de los
requisitos y diseño preliminar Postarquitectónico
Se aplica cuando ya se tiene la arquitectura
M.C. Martín Olguín (C) 2004
COCOMO II Nivel Inicial PM = (PO x (1 - Reutilización))/PRODDonde:
PM = Esfuerzo Persona-MesPO = Puntos ObjetoReutilización = %reutilización/100PROD = 4, 7, 13, 25, 50 dependiendo de la experiencia y
capacidad de los desarrolladores y/o Madurez del proceso (Muy baja, baja, normal, alta, muy alta) dada en PO/mes
M.C. Martín Olguín (C) 2004
...COCOMO II Estimación de calendario
TC = 3 x PM(0.33+0.2*(B-1.01))
Para el nivel inicial: B=1
TC = 3 x PM(0.328)
TC está dada en meses.
M.C. Martín Olguín (C) 2004
Planificación Temporal Es la actividad que distribuye el esfuerzo
estimado a lo largo de la duración prevista del proyecto.
Evoluciona con el tiempo. “El proyecto se ha completado en un 90%”
M.C. Martín Olguín (C) 2004
Gráficas de Barras de Actividad
M.C. Martín Olguín (C) 2004
Red de Actividades
M.C. Martín Olguín (C) 2004
Administración del Riesgo Etapas
Identificación de riesgos Análisis de riesgos
Valorar las probabilidades y consecuencias Planeación de riesgos
Planes para evitar o minimizar el impacto Supervisión de riesgos
Valoración constante, revisión de planes de mitigación conforme se vaya presentando información del riesgo.
M.C. Martín Olguín (C) 2004
Ejemplos de Riesgos
NegocioCambio de tecnología
ProductoBajo desempeño de la herramienta CASE
Proyecto y productoSubestimación del tamaño
Proyecto y productoRetrasos en la especificación
Proyecto y productoCambio de requerimientos
ProyectoNo disponibilidad del hardware
ProyectoCambio de administración
ProyectoRotación de personalTipoRiesgo
M.C. Martín Olguín (C) 2004
Proceso de Administración del Riesgo
Identificación deRiesgos
Análisis deRiesgos
Planeación deRiesgos
Supervisión deRiesgos
Listado de Riesgos potenciales
Listado de prioriza-ción de riesgos
Anulación de Riesgos y planes de
contingencia
Valoración de Riesgos