You are on page 1of 90

Análisis Orientado a Objetos

Ingeniería del Software M.C. José Martín Olguín Espinoza

M.C. Martín Olguín (C) 2004

Contenido del Curso
1.Introducción a la Ingeniería de Software
1.1. Definiciones de Ingeniería de Software 1.2. Características del Software 1.3. Aplicaciones del Software 1.4. Fases básicas del desarrollo del software (definición, desarrollo, mantenimiento).

M.C. Martín Olguín (C) 2004

…Contenido del Curso
2.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. 2.4.2. 2.4.3. Modelo Incremental Modelo Espiral Modelo Espiral WIN-WIN

M.C. Martín Olguín (C) 2004

.1.2.4. Antecedentes 3. Martín Olguín (C) 2004 ..Contenido del Curso 3.El Proceso Unificado de Desarrollo (RUP) 3. Dirigido por casos de uso 3.3.. Centrado en la Arquitectura 3.C. Iterativo e Incremental M.

C.Administración de proyectos de software 4.…Contenido del Curso 4. Componentes de un proyecto de software 4. Personal 4.2. Proyecto M. Martín Olguín (C) 2004 .4. Producto 4.1. Proceso 4.5.3.

Clases y Objetos 5. Herencia 5.Conceptos del Paradigma OO 5.…Contenido del Curso 5.1. métodos y servicios 5. Operaciones. El paradigma orientado a objetos 5.8. Martín Olguín (C) 2004 .7.C.6.5. Atributos 5.2. Polimorfismo M. Encapsulamiento 5. Mensajes 5.3.4.

4.2.5.1.1. Vista de Componentes 6. Clasificadores y mecanismos de extensión M.1.…Contenido del Curso 6. Vista lógica 6.1. Vista de la Implementación 6.El UML 6. Martín Olguín (C) 2004 .1. Vista de Casos de Uso 6.3.1.C.1. Vistas 6.

2. 6. 6. 6.6. 6.2..5.1.3.2.2.Contenido del Curso 6.2. 6. Diagramas 6.2. 6. Martín Olguín (C) 2004 Diagramas de caso de uso Diagramas de clases Diagramas de objetos Diagramas de estado Diagramas de secuencia Diagramas de colaboración Diagramas de actividad Diagramas de componentes Diagramas de implementación .8.2. 6..2.2.2..9. M.7.2.4. 6.C.

Arquitectura del Software 8.. Modelo de Análisis 8. Modelo de Diseño 8. Especificación de Requisitos 7. Patrones de Diseño M..2.2. Martín Olguín (C) 2004 .Diseño OO 8.3..Contenido del Curso 7.Ingeniería de Requisitos y Análisis OO 7.1.C.1.

5.1. Modelo de Implementación 10.3. Pruebas de validación M. Pruebas del modelo de análisis y el de diseño 10..2.4.Contenido del Curso 9.Implementación 9. Pruebas de unidad 10.2.. Pruebas de integración 10. Pruebas OO 10.C. Martín Olguín (C) 2004 ..1. Conceptos 10. Programación Orientada a Objetos 9.

. Métricas para el modelo de diseño OO 11.Contenido del Curso 11. Métricas orientadas a operaciones M.3.C.2. Métricas orientadas a clases 11. Martín Olguín (C) 2004 .. Conceptos 11. Métricas OO 11..4.1.

Ingeniería del Software: un enfoque práctico. The Rational Unified Process Philippe Krutchen Addison-Wesley M. Ingeniería de Software Orientado a Objetos Bernd Bruegge Pearson Educación 3. Martín Olguín (C) 2004 . Roger Pressman McGraw-Hill 2.Bibliografía 1. 5ta edición.C.

. El Proceso Unificado de Desarrollo de Software Ivar Jacobson... Martín Olguín (C) 2004 . Design Patterns Erich Gamma Addison-Wesley 3. Grady Booch y James Rumbaugh Addison-Wesley M. User Guide Grady Booch. James Rumbaugh.C. Ivar Jacobson Addison-Wesley 2.Bibliografía 1. The Unified Modeling Language.

C. Martín Olguín (C) 2004 .Unidad 1 Introducción a la Ingeniería del Software M.

documentos asociados y esquemas de configuración necesarios para que estos programas operen. Martín Olguín (C) 2004 .Software  Es el conjunto de programas de cómputo. [Sommerville. 2001] M.C.

1978] M. Martín Olguín (C) 2004 . [Zelkovitz.C.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.

operar y mantenerlos. [Bohem.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. 1976] M. Se conoce también como desarrollo de software o producción de software. Martín Olguín (C) 2004 .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.C. [Bauer. 1972] M.

es decir.C. La aplicación de un enfoque sistemático. Martín Olguín (C) 2004 . la aplicación de ingeniería al software. 1993] M. El estudio de enfoques como en (1) [IEEE.Ingeniería del Software  Definición 4:  1. 2. disciplinado y cuantificable al desarrollo. operación (funcionamiento) y mantenimiento del software.

Martín Olguín (C) 2004 . hasta el mantenimiento de éste después de que se utiliza.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. 2001] M.C. [Sommerville.

Ingeniería de Software e Ingeniería de Sistemas Teoría de Sistemas Ingeniería de Sistemas Ingeniería de Software M. Martín Olguín (C) 2004 .C.

Sistema  Un sistema es una colección de componentes interrelacionados que trabajan conjuntamente para cumplir algún objetivo. M. Martín Olguín (C) 2004 .C.

M. Los ingenieros de sistemas no sólo están relacionados con el software. Martín Olguín (C) 2004 .C. distribuir y mantener sistemas como un todo. implementar. validar. diseñar.Ingeniería de Sistemas   La ingeniería de sistemas consiste en la actividad de especificar. sino también con el hardware y las interacciones del sistema con los usuarios y su entorno.

no se fabrica.Características del Software    El software se desarrolla.C. Martín Olguín (C) 2004 . El software no se descompone. Aunque la industria tiende a ensamblar componentes. M. se echa a perder. la mayoría del software es hecho a la medida.

 Confiabilidad    Eficiencia  Usabilidad  M. El software debe ser fácil de utilizar. no debe causar daños físicos o económicos en el caso de una falla del sistema. El software debe ser fiable. El software debe aprovechar al máximo los recursos del sistema.C. Martín Olguín (C) 2004 . seguro.Atributos de un buen software  Mantenibilidad  El software debe poder evolucionar para cumplir con las necesidades de cambio de los clientes.

Martín Olguín (C) 2004 .C.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.

Tarea  Leer de Pressman la sección 1. Martín Olguín (C) 2004 .C.4 Mitos del Software y discutir en clase cada uno de los mitos presentados. M.

Martín Olguín (C) 2004 .C.Unidad 2 Modelos de Proceso del Software M.

que generan un producto de software.C. M. las cuales son llevadas a cabo por los ingenieros de software.Proceso de Software  Es un conjunto de actividades y resultados asociados. 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. Martín Olguín (C) 2004 .C. Organizaciones diferentes utilizan procesos diferentes M.

Es una abstracción de un proceso real.C. Martín Olguín (C) 2004 . 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.Modelos de Proceso del software   Es una descripción de un proceso del software que se presenta desde una perspectiva particular.

Modelo de Cascada Definición de requerimientos Diseño de sistemas y de software Implementación y Prueba de unidades Integración y prueba del sistema Operación y mantenimiento M.C. Martín Olguín (C) 2004 Royce. Los Angeles Adoptado por el DoD . 1970 “Managing the development of Large software systems: Concepts And techniques” IEEE Conference.

Modelo en “V”
Operación y mantenimiento

Definición de requerimientos

Pruebas de aceptación

Diseño de sistemas

Pruebas de sistema

Diseño de programas

Pruebas de unidad Y de integración

Codificación
M.C. Martín Olguín (C) 2004

Desarrollo Evolutivo

Modelo Construcción de prototipos
Especificación Versión inicial

Bosquejo de la descripción

Desarrollo

Versiones Versiones Versiones intermedias intermedias intermedias

Validación

Versión final

M.C. Martín Olguín (C) 2004

Modelo Incremental
The management of software engineering Mills et al., 1980 I BM Systems Journal

Bosquejo de los requisitos

Definir incrementos

Diseñar la arquitectura

Diseñar incremento

Validar incremento

Integar incremento

Validar sistema

Origen del Extreme Programming (XP)
M.C. Martín Olguín (C) 2004

Sistem a final
Embracing change with extreme programming Beck, K. 1999 IEEE Computer

Modelo en espiral

M.C. Martín Olguín (C) 2004

A spiral model of software development and enhancement Bohem, 1988 I EEE Computer

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

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.C.org/programs/roadmaps/Roadmap Presentación el miércoles 25 de agosto M.agilealliance.

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. Martín Olguín (C) 2004 .C. M.

C... Nivel 2: Repetible. M. Nivel 3: Definido. Nivel 4: Administrado. Nivel 1: Inicial. Martín Olguín (C) 2004 . Nivel 5: Optimización..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.

Martín Olguín (C) 2004 .Nivel 1: Inicial    El proceso se define ad hoc.C. Es caótico. El éxito depende del esfuerzo individual. M.

la planificación y la funcionalidad.C. Martín Olguín (C) 2004 . Se toman en cuenta experiencias anteriores para repetir las actividades necesarias en el proceso.Nivel 2: Repetible   Se establecen los procesos de administración del proyecto para dar seguimiento a los costos. M.

M. Martín Olguín (C) 2004 .C.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.

Se establecen estándares de calidad. M. Mediante la utilización de las métricas se comprenden y se controlan cuantitativamente tanto los productos como el proceso. Martín Olguín (C) 2004 .C.Nivel 4: Administrado    Se implementan métricas detalladas para los proyectos.

C. ideas y tecnologías innovadoras. M. Martín Olguín (C) 2004 .Nivel 5: Optimización  El proceso se mejora continuamente mediante la retroalimentación cuantitativa del proceso.

Auditores CMM  Requisitos:     Haber participado en una evaluación en los dos años anteriores a su solicitud de cursos.C. Cursar las asignaturas. Martín Olguín (C) 2004 . Ser líder en una evaluación CMM a una organización dentro de los dos años siguientes a los cursos. Obtener la aprobación del tutor. M. asesorado por un tutor certificado.

Tarea  Investigar información sobre organizaciones de software con certificación CMM.C. Martín Olguín (C) 2004 .    Tamaño Tiempo requerido para lograr la certificación Costo M.

C.Unidad 3 El Proceso Unificado de Desarrollo (RUP) M. 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.C. Martín Olguín (C) 2004 . diferentes niveles de competencia y diferentes tamaños de proyectos. M. para diferentes áreas de aplicación. diferentes tipos de organizaciones.

C. Martín Olguín (C) 2004 .Estructura del RUP M.

RUP y UML  El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparación de todos los planos del sistema. UML es una parte integral del Proceso Unificado. De hecho. M.C. Martín Olguín (C) 2004 . fueron desarrollados a la par.

 Centrado en la arquitectura (architecture-centric).  M.  Iterativo e incremental.C. Martín Olguín (C) 2004 .Características clave del RUP Dirigido por casos de uso (use-case driven).

Unidad 4 Administración de Proyectos M. Martín Olguín (C) 2004 .C.

over the time estimate. and offers fewer features and functions than originally specified. Resolution Type 3. with all features and functions as initially specified.standishgroup. Martín Olguín (C) 2004 Fuente: www. or project challenged: The project is completed and operational but over-budget. or project success: The project is completed on-time and on-budget. Resolution Type 2. or project impaired: The project is canceled at some point during the development cycle.com . M.C.Exito en proyectos de software en 1994 Resolution Type 1.

Martín Olguín (C) 2004 . J.S.Exito en Proyectos de Software en 1998 28% 26% Fracaso Total Excedido (tiempo y/o costo) Exitoso 46% Fuente: “Critical Succes Factors in Software Projects” Reel.C. IEEE Software mayo de 1999 M.

C. M. supervisión y control del personal. Martín Olguín (C) 2004 . del proceso y de los eventos que ocurren mientras evoluciona el software.Administración de proyectos de software  Implica la planificación. desde la fase preliminar hasta la implementación operacional.

No existen procesos de software estándar. M.Características de los proyectos de software    El producto es intangible. Comúnmente los proyectos grandes son “únicos”. Martín Olguín (C) 2004 .C.

Martín Olguín (C) 2004 .Las cuatro P's de la administración de proyectos  Personal  El factor humano Objetivos y el ámbito del producto Estructura de apoyo para la planeación Administración de la complejidad  Producto   Proceso   Proyecto  M.C.

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.

.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”... La comunicación entre el jefe y los miembros del equipo es vertical. Martín Olguín (C) 2004 . 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. M.C. 1981.

M.. La resolución de problemas es una actividad del grupo. La comunicación es horizontal. Descentralizado Democrático (DD) o “Egoless”: No tiene un jefe permanente.. Martín Olguín (C) 2004 .C.Personal   Descentralizado Controlado (DC): Un jefe definido que coordina tareas específicas y jefes secundarios con responsabilidades sobre subtareas. La solución de problemas se hacen por consenso.. la comunicación es horizontal y vertical. se nombran de acuerdo a la tarea.

C.. Modularidad. M. Comunicación requerida.Personal  ¿Qué factores se deben considerar cuando se estructura un equipo de software?      Complejidad del proyecto (dificultad del problema. Martín Olguín (C) 2004 . tamaño del software) Tiempo de desarrollo. Calidad...

C.. M. Martín Olguín (C) 2004 .Personal  Discusión sobre ventajas y desventajas de cada tipo de organización...

. Distribución de habilidades de acuerdo al problema. en “Work Organization: Paradigms for Project Management and Organization. L.Personal  ¿Cómo creamos un equipo de alto rendimiento?  Según Constantine.. 1993:    Confianza entre los miembros del equipo.C. Martín Olguín (C) 2004 . M. Los inconformistas deben ser excluidos..

M. 1998:   Atmósfera de trabajo frenética. del negocio o personales que provocan fricción entre los miembros del equipo.C. malgastan energía y se descentran de los objetivos Alta frustración causada por factores tecnológicos. en “Homeopathic Remedies for Team Toxicity”.. M.Personal  ¿Qué factores pueden contaminar el desempeño de un equipo?  Según Jackman.. 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. Martín Olguín (C) 2004 ... Definición confusa de los papeles a desempeñar produciendo una falta de responsabilidad y la acusación correspondiente.. M. Continua y repetida exposición al fallo que conduce a una pérdida de confianza y una caída de la moral.C.

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 ...

11 M. Martín Olguín (C) 2004 .6 al 3. 3.Tarea   Leer el capítulo 3 del Pressman 5ta. 3.1.C. edición Realizar los problemas 3.4.

Martín Olguín (C) 2004 .Tareas de la Administración de Proyectos  Estimación del tamaño del proyecto    LDC PF COCOMOII Barras de Actividad Red de actividades  Planificación temporal     Administración del Riesgo Supervisión y Control M.C.

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. Martín Olguín (C) 2004 .C. 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.

J.ifpug. a diferencia de LDC.1 M.. Martín Olguín (C) 2004 . “Measuring Application Development Productivity”. A.C.org versión 4.Puntos de Función    Es una medida de la funcionalidad entregada por la aplicación.  Consultar en www. Octubre 1979. Es una medida indirecta. Proceedings IBM Application Development Symposium. Propuesta por primera vez en:  Albretch.

Cálculo de PF Factor de ponderación Parámetros de medición Número de entradas de usuario Número de salidas de usuario Número de peticiones de usuario Número de archivos Número de interfaces externas Conteo Total (UFP) M.C. Martín Olguín (C) 2004 Cuenta Simple Medio Complejo [ ]x3 [ ]x4 [ ]x3 [ ]x7 [ ]x5 [ ]x4 [ ]x5 [ ]x4 [ ]x10 [ ]x7 [ ]x6 [ ]x7 [ ]x6 [ ]x15 [ ]x10 = = = = = .

65 + 0..C.01 x  (F )] i M.. 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..

¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado? 6. ¿Son complejas las entradas.C. ¿Existen funciones de procesamiento distribuido? 4. ¿Es crítico el rendimiento? 5. ¿Las entradas interactivas se harán en múltiples pantallas y operaciones? 8. ¿El diseño del código es reutilizable? 12. ¿El diseño incluye conversión e instalación? 13. ¿Es complejo el procesamiento interno? 11. ¿El diseño facilita los cambios y la usabilidad? M. salidas. ¿Requiere el sistema copias de seguridad y de recuperación fiables? 2. 14. ¿Se actualizan los archivos maestros de forma interactiva? 9. archivos y peticiones? 10. Martín Olguín (C) 2004 0-5 .Fi 1. ¿Requiere el sistema entradas de datos interactivas? 7. ¿El diseño incluye soporte para múltiples instalaciones en diferentes orgs. ¿Se requiere comunicación de datos? 3.

McGraw-Hill.Relación entre LDC y PF Lenguaje de Programación LDC/PF (media) 320 128 106 106 90 64 32 16 12 Ensamblador C COBOL FORTRAN Pascal C++ Visual Basic PowerBuilder SQL Jones. C. Martín Olguín (C) 2004 . Estimating Software Costs. 1998 M.C.

Puntos de Objeto    También es una medida indirecta del software.C. Martín Olguín (C) 2004 . Los elementos que toma en cuenta son:    Pantallas Informes (reportes) Componentes (o código en 3GL) M. NO es una medida de las clases necesarias para construir la aplicación.

C. B. IEEE Software. Martín Olguín (C) 2004 .. julio 1996 M.Cálculo de Puntos Objeto Peso de la complejidad Tipo de Objeto Pantallas Informes Componente 3GL Puntos Objeto Simple Medio Complejo [ ]x1 [ ]x2 [ ]x2 [ ]x5 [ ]x3 [ ]x8 [ ]x10 = = = Bohem. “Anchoring de software process”.

Cada uno estima el costo y se consensa después de varias iteraciones. Se consultan expertos en las técnicas de desarrollo propuestas y el dominio de la aplicación. El costo se determina más por los recursos disponibles que por los objetivos logrados. Martín Olguín (C) 2004 Utiliza un modelo con información histórica de costos.Técnicas de Estimación de Costos Modelado del algoritmo de costos Opinión de expertos Estimación por analogía Ley de Parkinson M. Cuando se han completado proyectos del mismo dominio de la aplicación se estima en base a la experiencia.C. Establece que el trabajo se expande para llenar el tiempo disponible. Se estima la métrica y se predice el esfuerzo. . relaciona una métrica con el costo del proyecto.

Martín Olguín (C) 2004 . 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.El modelo COCOMO      Constructive Cost Model Es un modelo de estimación empírico desarrollado por Bohem.C. Se obtuvo recolectando datos de varios proyectos de software grandes.

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 Se aplica cuando se tienen la mayoría de los requisitos y diseño preliminar Se aplica cuando ya se tiene la arquitectura  Diseño inicial   Postarquitectónico  M.

muy alta) dada en PO/mes M. 50 dependiendo de la experiencia y capacidad de los desarrolladores y/o Madurez del proceso (Muy baja.Reutilización))/PROD Donde: PM = Esfuerzo Persona-Mes PO = Puntos Objeto Reutilización = %reutilización/100 PROD = 4. 25. Martín Olguín (C) 2004 . 13.COCOMO II Nivel Inicial PM = (PO x (1 . 7. baja. alta.C. normal.

Martín Olguín (C) 2004 .COCOMO II  Estimación de calendario TC = 3 x PM(0.C.33+0...01)) Para el nivel inicial: B=1 TC = 3 x PM(0.2*(B-1.328) TC está dada en meses.. M.

Planificación Temporal    Es la actividad que distribuye el esfuerzo estimado a lo largo de la duración prevista del proyecto.C. Martín Olguín (C) 2004 . Evoluciona con el tiempo. “El proyecto se ha completado en un 90%” M.

Gráficas de Barras de Actividad M.C. Martín Olguín (C) 2004 .

C.Red de Actividades M. Martín Olguín (C) 2004 .

revisión de planes de mitigación conforme se vaya presentando información del riesgo.C.  Planeación de riesgos   Supervisión de riesgos  M.Administración del Riesgo  Etapas   Identificación de riesgos Análisis de riesgos  Valorar las probabilidades y consecuencias Planes para evitar o minimizar el impacto Valoración constante. Martín Olguín (C) 2004 .

Ejemplos de Riesgos Riesgo Rotación de personal Cambio de administración No disponibilidad del hardware Cambio de requerimientos Retrasos en la especificación Subestimación del tamaño Bajo desempeño de la herramienta CASE Cambio de tecnología M.C. Martín Olguín (C) 2004 Tipo Proyecto Proyecto Proyecto Proyecto y producto Proyecto y producto Proyecto y producto Producto Negocio .

Proceso de Administración del Riesgo Identificación de Riesgos Análisis de Riesgos Planeación de Riesgos Supervisión de Riesgos Listado de Riesgos potenciales Listado de priorización de riesgos Anulación de Riesgos y planes de contingencia Valoración de Riesgos M. Martín Olguín (C) 2004 .C.