Conch Silo ER pero wn sesgo espectico es menor que el costo de loreducon de ‘ego, no se itete seducitel riesgo sino contin supersin CAPITULO 25. cesnén DEL miESGO 761 y mecanismos para garantizar que los documentos se elaboran en forma oportuna. Este es un mecanismo para asegurar la continuidad en caso de que un individuo cru- cial abandone el equipo. El gestor del proyecto debe supervisar los documentos cui- dadosamente para asegurarse de que cada uno puede permanecer por si solo y que cada uno contiene informacién que seria necesaria si una nueva persona se viera obligada a unirse al equipo de software en algin momento a la mitad del proyecto. La gestién del riesgo y los planes de contingencia suponen que los esfuerzos de reduccién han fracasado y que el riesgo se ha vuelto una realidad. Continuando con el ejemplo, el proyecto ya esta bien avanzado y varias personas anuncian que renun- ciaran. Si se ha seguido la estrategia de reduccién, el respaldo esta disponible, la in- formacion se ha documentado y el conocimiento se ha dispersado entre el equipo. Ademés, el gestor del proyecto puede reenfocar temporalmente los recursos (y rea- justar la calendarizacion del proyecto) hacia aquellas funciones completamente es- tructuradas, asi permite que los nuevos elementos que deben agregarse al equipo “tomen el ritmo”. A los individuos que deciden marcharse se les pide detener todo el trabajo y pasar sus iltimas semanas “aprendiendo el modo de transferencia”. Esto puede incluir la adquisicion de conocimiento en videos, el desarrollo de “documen- tos comentados” o reuniones con otros miembros del equipo que permaneceran en el proyecto. Es importante sefialar que los pasos de reduccion, supervision y gestion del ries- go (RSGR) generan costos adicionales en el proyecto. Por ejemplo, utilizar el tiempo para “respaldar” cualquier tecnologia critica cuesta dinero. Por lo tanto, parte de la gestion del riesgo consiste en evaluar cudndo los beneficios que generan los pasos RSGR se rezagan frente a los costos asociados con su implementacién. En esencia, él planificador del proyecto realiza un clasico andlisis costo-beneficio. Si los pasos con que se evita el riesgo de elevada movilidad de personal aumentaran tanto el cos- to del proyecto como su duracin en un estimado de 15 por ciento, pero el factor de costo predominante es el “respaldo", el gestor puede decidir no implementar este pa- 0, Por otra parte, si los pasos con que se evita el riesgo se proyectan para aumen- tar los costos en 5 por ciento y la duracin en sélo 3 por ciento, el gestor probable mente pondré todo en su lugar. En un proyecto grande es posible definir 30 0 40 riesgos. Si para cada uno se iden- tifican entre tres y siete pasos de gestion del riesgo, jésta puede convertirse por si misma en un proyecto! Por esta razon se adapta la regla 80-20 de Pareto al riesgo de software. La experiencia indica que 80 por ciento del riesgo del proyecto global (es decir, 80 por ciento del potencial para falla del proyecto) puede explicarse sdlo con 20 por ciento de los riesgos identificados. El trabajo realizado durante los prime ros pasos del andlisis de riesgo ayudar al planificador a determinar cuales de los riesgos se encuentran en ese 20 por ciento (por ejemplo, riesgos que conduzcan a la mayor exposicion al riesgo). Por esta raz6n, algunos de los riesgos identificados, evaluados y proyectados pueden no incluirse en el plan RSGR, ya que no se ubican ervel critico 20/por ciento (los riesgos con la mayor prioridad de proyecto),Hoja de infor- macion del [WIL97}. PARTE CUATRO GESTION Dr PROYECTOS DE SOFTWARE ELriesgo no esté limitado al proyecto de software. Los riesgos pueden ocurrir des- pués de que el software se ha desarrollado exitosamente y entregado al cliente. Es- tos riesgos estan tipicamente asociados con las consecuencias de la falla de softwa- te en el campo El andlisis de seguridad y peligros de software (LEV95] son actividades de asegura- miento de la calidad del software (capitulo 26) que se enfocan en la identificacion y evaluacion de los peligros potenciales que pudieran afectar al software negativa- mente y provocar una falla en todo el sistema. Si los peligros se pueden identificar temprano en el proceso de ingenieria del software, las caracteristicas de disefio de software se pueden especificar de modo que eliminen o controlen los peligros po- tenciales. © ene: 242) Fe 9/5/04 Descripcion: Sélo 70 por ciento de los componentes de software calendarizados pare reviilizacién de hecho se integrarén en la aplicacién, La funcionolided restante tendré que desorrellarse de manera personalizada. Refinamiento/contexto: Subcondicién 1: Cierlos componentes de reutlizacién fueron desorrollados por un tercer participante sin conocimiento de los esténdares de diseiio internos Subcondicign 2: El esténdor de disefo para los componentes de interfaces no ho sido solidificado y tal vez no concuerden con ciertos componentes reutilizables existentes. Subcondicién 3: Cierlos componentes reutlizables se han implementado en un lenguaje que no soporte el entorno destino. Reduccin/supervision: 1. Contactar con el tercer parficipante para determiner la concordancia con los ‘estandores de disefo 2, Presionar pare completar los esténdares de interiaz; considerar lo estructura del componente cuando se decide acerce del protocolo de la interfaz. 3. Verificar para determinar el némero de componentes en la categoria 3 de subcondicién; verficar para determiner si se puede adquirir el soporte para el lenguaie. Gestién/plan de contingencia/disparador: la ER se calcula en 20 200 délares. Asignar esta cantidad dentro del costo de contingencia del proyecto. Desarrollar una calendarizacién revised suponiendo que se tendrdn que construir 18 componentes adicionales; asigner e! personel en concordancia, Disparador: los pasos de reduecién son improductivos al. 1/7/04. Estado actual: 12/5/04; Inician los pasos de reduccién. Elaboré: 0. Gagne Asignado a: B. LasterCAPITULO 25. crstiON DEL'RIESGO 763 Enel plan del proyecto de software se puede incluir una estrategia de gestion de ries- g0 0 los pasos de gestién del riesgo organizarse por separado en un Plan de reduc- cién, supervision y gestion del riesgo. El plan RSGR documenta todo el trabajo realiza- do como parte del analisis del riesgo y el gestor del proyecto lo emplea como parte del plan global del proyecto. Algunos equipos de software no elaboran un documento RSGR formal. En su lu- gar, cada riesgo se documenta individualmente mediante una hoja de informacién del riesgo (HIR) [WIL97]. En la mayoria de los casos la HIR se mantiene empleando un sistema de base de datos, de modo que la creacién y las entradas de informacién, ordenamiento de prioridades, busquedas y otros analisis se logran facilmente. En la figura 25.4 se ilustra el formato de la HIR. Una vez documentado el plan RSGR y que el proyecto ha comenzado, se inician los pasos de reduccién y supervision del riesgo. Como ya se ha comentado, la reduc- cin del riesgo es una actividad encaminada a evitar el problema. La supervision del riesgo es una actividad de seguimiento del proyecto con tres objetivos principales: 1) valorar si los riesgos predichos de hecho ocurren; 2) asegurar que los pasos para evi- tar el riesgo definidos para éste se estan aplicando con propiedad; y 3) recopilar in- formacion que pueda usarse en futuros andlisis de riesgo. En muchos casos, a los problemas que ocurren durante un proyecto es posible darles seguimiento hacia mas de un riesgo. Otra labor de la supervision del riesgo es intentar ubicar el origen (qué riesgos provocaron qué problemas a través del proyecto) beta Poa Gestién del riesgo 2) Objetivo: El objetivo de as herromientss de - cod riesgo, opoyar las ealegios de redecién del igo piel ll ege-ovoyuder ob sauipi-dalpro-. -y generar muchos roporieealonados con ange. ecto a defnirlosiesgos, valorar sv impado y probobil- Herramientas representantivast Bed,» sng bina cde tocol roves 31 Pade sscrobacs en Avizona Scie Univer fin oy < x ‘20s.c8u.edu/~sdm/merrill/riskman.himl), es un sistema Mecéinica: En general, las herramientos de gestién del ‘expatio evéroluacién da riesgo qua identifica resgos riesgo ouxilion en la identifcacién de riesgos genéricos ol ebatiamloe cn al proyece proporcionar una lista de riesgos usvoles de proyecto yde negocios, ofrecer listas de verificacién u otras téenicas “de Risk Radar, desarrollada por SPMIN (www.spmn.com), au entrevista” que auxilien en la identificacién de riesgos es- xilic @ los gestores de proyectos a identificar y gestio- pecificos del proyecto, asignar probabilidad e impacto o nar riesgos. 4 Las herramientas anotadas aqui son una muestra de esia categoria. En la mayorla de los casos los nombres de las mismas son marcas registradas por sus respectives desarrolladores.764 PARTE CUATRO GESTION DE PROYECTOS DE SOFTWARE RiskTrak, desarrollada por RST (www.risktrac.com), cpoya _X:PRIMER, desarrollada por GrafP Technologies (www. a identificacién, el andlisis, el reporte y la gestién de .grafp.com), es unc herramienta genérica basade en riesgos a través de un proyecto de software. Web que predice qué puede salir mal en un proyecto € Riske, desarrolloda por C/S Solutions (www.CS-solutions, ‘com), $e integra con Microsoft Project pore cuantificar incertidumbres de calendarizacién, coslos identifica el origen de las causas de potenciales fallas y contramedidas efectivas. Siempre que en un proyecto de software esté mucho en juego, el sentido comun dic- ta el anilisis de riesgos, Sin embargo, muchos gestores de proyecto de software lo hacen informal y superficialmente, si es que lo hacen. El tiempo empleado en iden- tificar, analizar y gestionar el riesgo paga por si mismo dividendos en muchas for- ‘mas: menos trastornos durante el proyecto, una mayor habilidad para seguir y con- trolar un proyecto, y la confianza que lega cuando se planifican los problemas an- tes de que ocurran. EI andlisis de riesgos puede absorber una cantidad significativa de esfuerzo de planificacion del proyecto. La identificaci6n, proyeccién, evaluacién, gestion y super- vision toman tiempo. Pero el esfuerzo bien vale la pena. Para citar a Sun Tzu, el ge- neral chino que vivi6 hace 2 500 afios: “Si usted conoce al enemigo y se conoce a si mismo, no necesita temer el resultado de cien batallas”. El entemigo del gestor del proyecto de software es el riesgo. IAFC88] Software Risk Abatement, AFCS/AFLC Pamphlet 800-45, U.S, Air Force, 30 de septiem- bre de 1988, [BOE89] Boehm, B. W., Software Risk Management, IEEE Computer Society Press, 1989. ICHA89] Charette, R.N., Software Engineering Risk Analysis and Management, McGraw-Hill/Inter- text, 1989. ICHA92] Charette, R.N,, “Building Bridges over Intelligent Rivers", en American Programmer, Vol. 5, num. 7, septiembre de 1992, pp. 2-9. IDRU75] Drucker, P, Management, W. H. Heinemann, 1975. IGIL88} Gilb, T., Principles of Software Engineering Management, Addison-Wesley, 1988. [GLU94) Gluch, D. P, “A construct for Describing Software Development Risks", CMU/SEI-94- ‘TR-14, Software Engineering Institute, 1994. IHAL98} Hall, E, M., Managing Risk: Methods for Software Systems Development, Addison-Wesley, 1998 [HIG95) Higuera, R. P, “Team Risk Management”, en CrossTalk, U.S. Dept. of Defense, enero de 1995, pp. 2-4 IKAR96] Karolak, D. W., Software Engineering Risk Management, IEEE Computer Society Press, 1996, IKEI98] Keil, M. et al., “A Framework for Identifying Software Project Risks”, en CACM, vol. 41, nim. 1, noviembre de 1998, pp. 76-83. [LEV95] Leveson, N. G., Software System Safety and Computers, Addison-Wesley, 1995. ISE193) “Taxonomy-Based Risk Identification”, Software Engineering Institute, CMU/SEI-93-TR: 6, 1993.CAPITULO 25 crsiSN pr rirsGo 765 ITHO92] Thomsett, R., “The indiana Jones School of Risk Management”, en American Program- mer, vol. 5, num. 7, septiembre de 1992, pp. 10-18. [WIL97| Williams, R. C.,J, A. Walker'y A.J, Dorofee, “Putting Risk Management into Practice”, en IEEE Software, mayo de 1997, pp. 75-81 25.1. Ofrecer cinco ejemplos de otros campos que ilustren los problemas asociados con una estrategia de riesgo reactiva. 25.2. Describir la diferencia entre “riesgos conocides” y “riesgos predecibles” 25.3. Agregar tres preguntas o t6picos adicionales a cada una de las listas de verificacion de riesgo que se presentan en el sitio Web SEPA. 25.4. A usted se le ha pedido construir software para apoyar un sistema de edicién de video de bajo costo. El sistema acepta como entrada video digital, almacena el video en disco y luego permite que el usuario haga una amplia variedad de ediciones al video digitalizado. El resulta- do puede entonces grabarse en DVD u otro medio audiovisual. Investigue un poco acerca de sistemas de este tipo y luego elabore una lista de riesgos tecnolégicos que enfrentaria al comen- Zar un proyecto con estas caracteristicas. 125.5, Usted es el gestor de proyecto de una gran compaiiia de software. Se le solicita dirigir un equipo que est desarrollando software de procesamiento de textos de “nueva generacion” ‘Cree una tabla de riesgos para el proyecto. 25.6. Describir la diferencia entre componentes de riesgo y controladores de riesgo. 25.7. Desarrollar una estrategia de teduccién de riesgo y especificar actividades de reduccion de riesgo para tres de los riesgos anotados en la figura 25.2 25.8. Desarrollar una estrategia de supervision de riesgo y especificar actividades de supervi- sion de riesgo para tres de los riesgos anotados en la figura 25.2. Asegurese la identificacion de los factores que se supervisaran para determinar si el riesgo se esta volviendo mas o menos pro- bable. 26.9. Desarrollar una estrategia de gestion del riesgo y especificar actividades de gestion del riesgo para tres de los riesgos anotados en la figura 25.2. 25.10. Inténtese refinar tres de los riesgos anotados en la figura 25.2 y luego créense hojas de informacién de riesgo para cada uno. 26.11. Represéntense tres de los riesgos anotados en la figura 25.2 empleando un formato CTC. 25.12. Vuélvase a calcular la exposicién al riesgo examinada en la seccién 25.4.2 cuando el cOsto/LDC es de 16 délares, y la probabilidad de 60 por ciento. 26.13. :Puede pensar en una situacién en la que un riesgo de alta probabilidad y alto impacto no seria considerado como parte de su plan RSGR? 25.14. Describanse cinco areas de aplicacién de software en las que el analisis de la seguridad y los peligros del software serfan una preocupacion principal. La bibliografia de gestion del riesgo de software se ha expandido significativamente durante la década pasada. DeMarco y Lister (Dancing with Bears, Dorset House, 2003) han escrito un libro entretenido y lticido que guia a los gestores y profesionales de software a través de la gestion del riesgo. Moynihan (Coping with IT/IS Risk Management, Springer-Verlag, 2002) presenta con- sejos pragmaticos de gestores de proyecto que lian continuamente con él. Royer (Project Risk766 PARTE CUATRO GESTION DE PROYECTOS DE SOFTWARE. ‘Management, Management Concepts, 2002) y Smith y Merritt (Proactive Risk Management, Pro ductivity Press, 2002) sugieren un proceso proactivo para la gestidn del riesgo. Karolak (Softw rre Engineering Risk Management, Wiley, 2002) ha escrito una guia que introduce un modelo de anélisis de riesgo facil de usar y que contiene valiosas listas de verificacién y cuestionarios que’ se apoyan en un paquete de software. Schuyler (Risk and Decision Analysis in Projects, PMI, 2001) considera el andlisis de desde una perspectiva estadistica, Hall (Managing Risk: Methods for Software Systems ment, Addison-Wesley, 1998) presenta uno de los tratamientos mas exhaustivos de la matena_ Myerson (Risk Management Processing for Software Engineering Models, Artech House, 1997) considera métricas, seguridad, modelos de proceso y otros tépicos. Grey (Practical Risk Assess ment for Project Management, Wiley, 1995) escribiG un itil manual de la evaluacién del riesgo. Su tratamiento abreviado offece una buena introduccién ala materia. Capers Jones (Assessment and Control of Software Risks, Prentice-Hall, 1994) presenta una ex- posicién detallada de los riesgos de software que incluye datos recopilados a partir de cientos de proyectos de software. Jones define 60 factores de riesgo que pueden afectar el resultado de Jos proyectos de software. Boehmn [BOE89] sugiere excelentes formatos de cuestionario y listas) de verificacion que pueden resultar invaltables en la identificacién de riesgos. Charette [CHA8% presenta un tratamiento detallado de las mecénicas del analisis de riesgo, y utiliza teoria de pro babilidad y técnicas estadisticas para analizar riesgos. En un volumen adicional, Charette (A> lication Strategies for Risk Analysis, McGraw-Hill, 1990) analiza el riesgo en el contexto de ta ‘Ingenieria tanto de sistemas como de software, y sugiere estrategias pragmiticas para la ges tion del riesgo, Gilb (Principles of Software Engineering Management, Addison-Wesley, 1988) pre~ senta un conjunto de “principios” (en ocasiones graciosos y a veces profundos) que pueden ser- vir como una guia valiosa para la gestién del riesgo. Ewusi-Mensah (Software Development Failures: Anatomy of Abandoned Projects, MIT Press. 2003) y Yourdon (Death March, Prentice-Hall, 1997) analizan lo que ocurre cuando los riesgos abruman a un equipo de proyecto de software. Bernstein (Against the Gods, Wiley, 1998) presen- ta una entretenida historia del riesgo que se temonta a tiempos antiguos. El Software Engineering Institute ha publicado muchos informes detallados y guias acerca: del analisis y la gestion del riesgo. El folleto AFSCP 800-45 (AFC88] del Air Force Systems Com- mand describe las técnicas de identificacién y reduccién de riesgos. Cualquier nimero del ACM Software Engineering Notes tiene una seccion titulada “Riesgos para el publico” (editor, P.G. New mann). Si usted quiere las més recientes y mejores historias de horror de software, éste es el = gar al que tiene que ir. En Internet hay disponible una amplia variedad de fuentes de informacion acerca de gestion del riesgo de softwate. Una lista actualizada de referencias en la World Wide Web se puede en- contrar en el sitio Web SEPA: http://www.mhhe.com/presssman.