Gerencia de Proyectos

CAPITULO I

BIENVENIDOS AL DESARROLLO RPIDO

Este primer capitulo se inicia planteando la visin desde diferentes perspectivas sobre la concepcin del trmino desarrollo rpido. Para los efectos del libro, se puntualiza el desarrollo rpido como un trmino genrico que representa un desarrollo veloz o planificaciones cortas. En palabras ms sencillas, significa desarrollar software con velocidades superiores a las alcanzadas actualmente. nfasis en la velocidad de desarrollo. Seguidamente, se aborda el punto sobre como lograr el desarrollo rpido, se plantean dos principios bsicos requeridos para lograr el xito en proyectos de este tipo, los cuales son: seleccionar mtodos eficaces en lugar de mtodos ineficaces, y el segundo, seleccionar mtodos orientados especficamente a alcanzar sus objetivos de planificacin. Finalmente se plantea una serie de mtodos de desarrollo orientados a la planificacin: los que mejoran la velocidad de desarrollo, que permiten acortar los tiempos de entrega del software; los que reducen el riesgo en planificacin, que permiten asegurar el cumplimiento de los tiempos estimados; y finalmente, los que hacen visible el progreso, que propician la imagen de un proyecto bajo control. Al conjugar lo mtodos adecuados, junto con un plan para usarlos, se obtendrn mejoras significativas en los resultados de proyectos de desarrollo rpido. CAPITULO II ESTRATEGIA PARA EL DESARROLLO RPIDO Entonces, un proyecto de desarrollo rpido es cualquier proyecto en el que se requiera hacer

El segundo capitulo, se inicia haciendo una referencia a que de nada sirve contar con los mejores recursos al momento de desarrollar una actividad de equipo, si estos no se encuentran debidamente coordinados, y si no existe una estrategia para aprovechar su mximo
Garcia Freddy, Garcia Mildred, Montes Ramn Pgina 1 de 17

Gerencia de Proyectos

potencial. As mismo, se seala una estrategia para obtener desarrollo rpido, basado en cuatro pilares fundamentales: evitar errores clsicos, aplicar bases de desarrollo, gestionar los riesgos y aplicar mtodos orientados a la planificacin. Contar con estos cuatro pilares debidamente posicionados, y que cada uno de ellos sea lo ms fuerte posible, constituye el apoyo ptimo para lograr el mejor plan posible en un proyecto de desarrollo rpido. Punto seguido, se definen las cuatro dimensiones de la velocidad de desarrollo: personas, proceso, producto y tecnologa. Sobre la primera dimensin, personas, se hace referencia a una gran cantidad de estudios cuyas conclusiones sealan que los temas relacionados con personas, tienen un impacto fundamental en la productividad y calidad del software. Los mtodos ms efectivos para apoyar los procesos de desarrollo rpido, son aquellos que sacan provecho al potencial humano de los desarrolladores. Queda claro entonces, que la base de la productividad de un proyecto de software, esta ntimamente ligado a temas de personal como la motivacin, seleccin de personal, equipo de trabajo y formacin. Sobre el proceso, representa un rea casi tan relevante como el personal dentro del mbito de la estrategia para el desarrollo rpido. Muchas empresas han centrado sus esfuerzos en mejorar sus procesos de desarrollo, con lo que han logrado obtener mejoras substanciales en cuanto a tiempo, costos y errores. Algunas premisas para lograr un proceso optimo se definen a continuacin: evitar la repeticin de trabajo, el control de calidad que incluye el aseguramiento de la calidad del producto final y la deteccin de errores en el momento indicado para emplear menos tiempo y menos costo para corregirlo.
Garcia Freddy, Garcia Mildred, Montes Ramn

Contar con
Pgina 2 de 17

Gerencia de Proyectos

estndares de desarrollo de software a fin de mantener el control sobre el proyecto; gestionar los riesgos asociados con la planificacin; enfoque de los recursos a los objetivos del proyecto; planificar la asignacin de recursos en base al modelo de ciclo de vida que mas se adapte al proyecto; orientacin al cliente visualizando el proyecto de desarrollo de software desde la asesora y determinacin de requerimientos hasta la construccin a partir de una especificacin. Sobre producto, el tamao y caractersticas del producto plantean una relacin directamente proporcional al proceso de planificacin y por ende a los tiempos de desarrollo del proyecto. esfuerzo invertidos para concluir el proyecto. Sobre tecnologa, resalta que el uso de herramientas efectivas tiende a mejorar la velocidad de desarrollo. Finalmente la sinergia es un aspecto fundamental entre las cuatro dimensiones anteriormente mencionadas, para el desarrollo rpido. Sobre la interrogante, Cul de las dimensiones es la ms importante?, es vlido decir, que ser la naturaleza misma del proyecto, as como el entorno que lo rodea, los que definirn cuales dimensiones debern ser ampliadas y cuales sern limitadas, pero siempre forzando al mximo cada una ellas para lograr alcanzar el xito global. En otro orden de ideas, es importante sealar, que los niveles de compromiso en la velocidad del desarrollo, estar definido por las distintas situaciones que enmarquen el proyecto. Incrementar la velocidad de desarrollo ser generalmente un aspecto deseable, pero muy probablemente puede tener impacto en los costos del proyecto.
Garcia Freddy, Garcia Mildred, Montes Ramn Pgina 3 de 17

A mayor tamao del

producto y/o caractersticas ms ambiciosas, mayor ser el tiempo y el

Gerencia de Proyectos

Existen diferentes estndares de desarrollo orientados a la planificacin, entre los que se sealan, los mtodos tradicionales, el desarrollo eficiente, desarrollo eficiente orientado al mejor plan y el desarrollo rpido a fondo. Cada uno de ellos puede tener incidencias distintas en cuanto a: la planificacin, los costos y el producto. El desarrollo eficiente, se logra evitando los errores clsicos, trabajando sobre bases firmes de desarrollo y mediante una adecuada gestin de riesgos. Este enfoque, propicia tiempos ptimos de Con el desarrollo desarrollo, basado ms en una adecuada organizacin del proyecto que en el empleo de mtodos de desarrollo rpido. eficiente, se pueden obtener mejores planificaciones a menor costo y mejor calidad de producto que los enfoques tradicionales de las organizaciones. El desarrollo eficiente orientado hacia el mejor plan, resulta de una variacin del desarrollo eficiente, que pudiera implementar mtodos que incrementen la velocidad de desarrollo, reduzcan los riesgos de planificacin, o que mejoren la visibilidad del progreso del proyecto. Este enfoque, pudiera impactar los costos del proyecto, as como ciertas caractersticas del producto final. El ltimo enfoque, es el llamado desarrollo rpido a fondo, el cual consiste en la implementacin de mtodos eficientes e ineficientes, para acortar los tiempos del proyecto, sin importar que esto signifique incremento en costos, altos riesgos o grandes concesiones en las caractersticas del producto final.

Garcia Freddy, Garcia Mildred, Montes Ramn

Pgina 4 de 17

Gerencia de Proyectos

Al final de este captulo, se presenta una estrategia alternativa para desarrollo rpido, que se basa en hacer uso de un personal altamente calificado y comprometido con el proyecto, as como tcnicas interesantes de motivacin, que permitan obtener un mximo rendimiento de los recursos y por ende resultados altamente aceptables. Esta estrategia, aunque cuenta con algunas limitaciones y riesgos intensos, en algunos casos podra llegar a tener xito. Sin embargo, esta estrategia no garantiza el xito del proyecto, ya que prcticamente no se puede controlar. Suele provocar problemas de motivacin, generalmente provocado por posibles fallas en las metas del desarrollador, as como el agotamiento. No se puede repetir, ya que produce un agotamiento intenso en el personal, y una empresa no puede reparar fcilmente el dao humano provocado por estos proyectos. Es duro para organizaciones no dedicadas al software, ya que se basa en superfiguras del desarrollo y no en la coordinacin, cooperacin y planificacin; incluso cuando la velocidad de desarrollo sea ms rpida de la habitual, nunca habr forma de saber cuanto durar el proyecto. Es probable que los tiempos de desarrollo se vean afectados por otro grupo de trabajo del proyecto, como el de pruebas o documentacin. En resumen, esta estrategia alternativa de desarrollo, asegura un esfuerzo extraordinario del personal del proyecto, pero esto no significa, ni garantiza el xito global del proyecto. CAPITULO III ERRORES CLSICOS

El tercer captulo, intitulado Errores Clsicos, se inicia presentando una serie de resultado de estudios realizados a travs de los aos, en los
Garcia Freddy, Garcia Mildred, Montes Ramn Pgina 5 de 17

Gerencia de Proyectos

que queda evidenciado que las probabilidades de que un proyecto del cual se espera una productividad pobre la tenga, es realmente elevada. En cambio, resulta una gran sorpresa que proyectos de los cuales se espera una alta productividad, no la tengan. Lo anterior demuestra que a pesar de que muchas cosas se hagan bastante bien, algunos pequeos errores pueden afectar la productividad y echar por tierra todo lo bueno que se ha construido. En el mundo de desarrollo de software, un pequeo error puede acarrear consecuencias catastrficas para el desarrollo de un proyecto. Para caer en un desarrollo lento, basta con cometer algn error, para obtener un desarrollo rpido es necesario evitar cometer errores. Algunos hbitos o tcnicas poco efectivas de software, han sido elegidas tantas veces a travs del tiempo, y aparecen de forma tan repetitiva en circunstancias similares, que para efectos del libro han sido denominadas errores clsicos. Por lo general, estos errores no producen los resultados esperados por sus ejecutores. Un aspecto interesante a resaltar sobre los errores clsicos, es que evitarlos no garantiza obtener un desarrollo rpido, pero si se cometen, se puede estar seguro de que conseguir un desarrollo lento. A continuacin, se presenta un resumen de los mencionados errores clsicos, agrupados desde el punto de vista de las dimensiones de velocidad de desarrollo: Persona Error clsico Motivacin dbil Descripcin Estudios han demostrado de que uno de los factores primordiales determinantes de la
Pgina 6 de 17

Garcia Freddy, Garcia Mildred, Montes Ramn

Gerencia de Proyectos

Personal mediocre

Empleados problemticos incontrolados Hazaas

Aadir ms personal a un proyecto retrazado

Oficinas repletas y ruidosas

Fricciones entre los clientes y los desarrolladores

Expectativas poco realistas

Falta de un promotor efectivo del proyecto

Falta de participacin de

productividad es la motivacin. Un grupo poco motivado es poco productivo. Tal como la motivacin, las capacidades individuales de los miembros del equipo, as como sus relaciones grupales, inciden altamente en la productividad y la velocidad de desarrollo. Mantener empleados problemticos en el equipo de proyecto, suele distorsionar la armona del grupo y por ende afecta los objetivos del proyecto. Las pretensiones de realizar actos heroicos, fomenta la adicin de riesgos al proyecto, e impide la cooperacin y fraternizacin entre varios elementos del proyecto. Este es uno de los errores ms frecuentes, cuando se realiza esto, generalmente es ms la productividad que resta a los miembros existentes del equipo, que la que aaden los nuevos integrantes. Para un desarrollador, el ambiente de trabajo, es igualmente un factor incidente en la productividad. Los desarrolladores que trabajan en oficinas privadas y silenciosas, son ms productivos que los que trabajan en lugares pblicos y ruidosos, lo cual alarga los planes de desarrollo. Esto trae como consecuencia, mala comunicacin entre las partes, lo cual se traduce en una pobre especificacin de requerimientos, diseos no ajustados a las necesidades del cliente, y en algunos casos hasta el rechazo del producto final. Aunque por si mismas, las expectativas irreales no alargan el plan de proyecto, la probabilidad de alcanzarlas es muy baja, y esto pudiera dar la impresin de que el proyecto estuviera fuera de control o mal planificado. Sin un promotor ejecutivo efectivo, el resto de personal de alto nivel de la empresa, podra forzar a que se acepten fechas de entrega irreales y/o cambios que debiliten el proyecto. Los principales participantes del esfuerzo de
Pgina 7 de 17

Garcia Freddy, Garcia Mildred, Montes Ramn

Gerencia de Proyectos

los implicados

Falta de participacin del usuario

Poltica antes que desarrollo Ilusiones

desarrollo, deben implicarse en el proyecto. La coordinacin estrecha y la coordinacin adecuada de los esfuerzos y recursos, depende en gran medida de que se hayan implicado en el proyecto la totalidad de sus participantes. Los proyectos que no involucran al usuario desde el principio, corren el riesgo de que no se comprendan y satisfagan debidamente los requerimientos del producto. Colocar la poltica por encima de los resultados, resulta fatal para el desarrollo orientado a velocidad. Las ilusiones al inicio del proyecto, impiden llevar a cabo una planificacin coherente y ajustada a la realidad.

Proceso Error clsico Planificacin excesivamente optimista Descripcin Fijar un plan excesivamente optimista, predispone a que el proyecto falle por infravalorar sus alcances, y supone una excesiva presin para los desarrolladores que pudiera mermar su productividad. Adems, de reducir el tiempo para actividades crticas que pudieran afecta el logro de los objetivos. Si no se ejerce una gestin activa del riesgo, basta con que solo vaya mal una cosa para pasar de un desarrollo rpido a un desarrollo lento. Si no se gestiona adecuadamente la contratacin de desarrolladores externos, es ms probable ralentizar el proyecto que acelerarlo. Riesgos como requerimientos inestables o interfaces mal definidas, pueden ser enormes cuando un contratado entra en escena. Si no se planifica para obtener un desarrollo rpido, no se puede esperar obtenerlo. Ciertos problemas pueden ocurrir en el desarrollo del proyecto que ameriten dejar la planificacin. El problema no es el
Pgina 8 de 17

Gestin de riesgo insuficiente Fallos de los contratados

Planificacin insuficiente Abandono de la planificacin bajo presin

Garcia Freddy, Garcia Mildred, Montes Ramn

Gerencia de Proyectos

Prdida de tiempo en el inicio difuso

Escatimar en las actividades iniciales Diseo inadecuado

Escatimar en el control de calidad

Control insuficiente de la directiva

Convergencia prematura o excesivamente frecuente

Omitir tareas necesarias en la estimacin Planificar ponerse al da ms adelante Programacin a destajo

abandono, sino en no crear un plan alternativo. Es muy comn que esta prdida de tiempo al inicio del proyecto, desencadene en una planificacin muy agresiva para tratar de recuperar el tiempo perdido. Es preferible, acortar los tiempos de inicio y tener una planificacin ms holgada. Los proyectos que escatiman en los trabajos iniciales, generalmente tendrn que hacerlos en otro momento, con un costo superior al haberlo hecho bien al principio. Es el resultado de una escatimacin en las actividades de diseo. Un diseo inadecuado, crea un entorno de alta presin que dificulta la posibilidad de considerar la mayor cantidad de alternativas de diseo. El nfasis en diseo, va mas orientado a conveniencia que ha calidad. Minimizar las actividades de control de calidad, podra conllevar a el alargue de algunas actividades finales para poder alcanzar la calidad de producto deseada. Esta situacin atenta contra la velocidad de desarrollo. Las figuras de alto rango en la organizacin, deben estar en la capacidad de monitorear si este va por buen camino, para poder ejercer los correctivos necesarios y mantener encarrilado el proyecto. En proyectos hechos con prisa, hay una marcada tendencia a forzar prematuramente la convergencia de sus elementos en repetidas ocasiones, lo cual no beneficia al producto. Solo son una prdida de tiempo que prolonga el plan. Las actividades ocultas y el esfuerzo omitido en la planificacin, suele aumentar el plan de desarrollo entre un 20 y 30 por ciento. Un tipo de reestimacin, es responder inapropiadamente al retraso del plan. En muchos proyectos con retraso, se plantea recuperarlo ms tarde, pero nunca se hace. Muchas empresas piensan que un grupo de desarrolladores suficientemente motivados,
Pgina 9 de 17

Garcia Freddy, Garcia Mildred, Montes Ramn

Gerencia de Proyectos

pueden solventar cualquier obstculo, inclusive, una planificacin demasiado ambiciosa.

Producto Error clsico Descripcin Exceso de requerimientos Algunos proyectos, tienen ms requerimientos de los que necesitan desde su inicio, lo cual supone esfuerzos que alargan el plan de trabajo y no agrega valor significativo al producto final. Cambio de las Nuevas prestaciones del producto a lo largo prestaciones de la vida del proyecto, garantiza que no se alcanzar la fecha de entrega. Este alargue en las fechas de entrega del proyecto atenta contra el desarrollo rpido. Desarrolladores Los desarrolladores encuentran fascinante meticulosos las nuevas tecnologas, y en ocasiones invierten esfuerzos probando nuevas prestaciones de las herramientas sin importar si son necesarias o no par el producto final. Tiras y aflojas en la Cuando se aprueba un retraso del plan de negociacin proyecto que no marcha segn lo esperado pero adicionalmente se agregan nuevas prestaciones al producto, se esta aceptando y corrigiendo un error pero de inmediato se est cometiendo otro. Desarrollo orientado a la Si el proyecto fuerza los limites de la investigacin informtica porque necesita la creacin de nuevos algoritmos o nuevas tcnicas de computacin, entones no es un proyecto de desarrollo software, sino de investigacin en software. Los planes de investigacin sobre software no son predecibles tericamente. Tecnologa Error clsico Sndrome de la panacea Descripcin Aferrarse a una nueva tcnica, tecnologa o procedimiento rgido, no resuelve en absoluto los problemas de planificacin.
Pgina 10 de 17

Garcia Freddy, Garcia Mildred, Montes Ramn

Gerencia de Proyectos

Sobreestimacin del empleo de nuevas herramientas o mtodos

Cambiar de herramienta a la mitad del proyecto

Falta de control automtico del cdigo fuente

Los beneficios de las nuevas tcnicas son parcialmente desplazados por la curva de aprendizaje, tambin suponen nuevos riesgos que solo se descubren usndolas. Estimaciones demasiado ambiciosas en el aumento de la productividad al implementar nuevas tecnologas, aumenta el riesgo de obtener retrasos en la planificacin. Cuando se esta en la mitad de un proyecto, la curva de aprendizaje, rehacer cierto trabajo y los inevitables errores cometidos con una herramienta nueva, normalmente anulan cualquier beneficio. El control manual de actualizaciones de los programas, que pudieran estar siendo actualizados simultneamente y la imposibilidad de regresar a versiones anteriores del cdigo fuente, pudiera causar retrasos, prdida de secciones de programas o esfuerzos de sincronizacin que afectan los recursos del proyecto.

CAPITULO IV

BASES DEL DESARROLLO DE SOFTWARE

Cuando se trabaja para construir un producto o un sistema, es importante seguir una serie de pasos que le ayude a obtener el resultado oportuno de calidad. Esto se logra teniendo en cuenta las bases del desarrollo de software. Los ingenieros de software y sus gestores adaptan el proceso a sus necesidades y entonces lo siguen. Adems las personas que han solicitado el software tienen un papel a desempear en el proceso del software. Esto es de vital importancia ya que proporciona estabilidad, control y organizacin a una actividad que puede volverse catica en muchos de los casos.

Garcia Freddy, Garcia Mildred, Montes Ramn

Pgina 11 de 17

Gerencia de Proyectos

Las bases para el desarrollo de software son las Bases de Gestin, Bases Tcnicas, Bases de control de Calidad y por ultimo seguir las instrucciones, de esta forma podemos estar seguros que el producto tendr un elevado nivel de calidad y que no existirn tropiezos que hagan tambalear el proyecto. Las bases de gestin esta compuesta por tres etapas,

planificacin, Seguimiento y Medicin, es estas etapas estn implcitos unos de los aspectos mas importantes del desarrollo de software ya que es donde se dejan claras las reglas y se traza el plan a seguir durante todo el desarrollo del software. En la primera etapa se debe hacer una estimacin del tamao del producto y ello a su vez involucra el esfuerzo que ser necesario para la construccin del mismo, esto conlleva a una cadena ntimamente relacionada en la cual si se realiza una buena estimacin, existe una alta probabilidad de que se haga una planificacin efectiva y a su vez un desarrollo exitoso. Obviamente esta etapa de desarrollo debe llevar un seguimiento en el cual se comprueba que se esta cumpliendo con la planificacin que ya fue elaborada y que el proyecto no se va a desviar del objetivo o meta principal. Aunado a esto se deben aplicar ciertas tcnicas para poder hacer las mediciones correspondientes y de esta forma visualizar el progreso del software de una manera ms exacta y eficiente. Sin duda las Bases tcnicas nos proporcionan una visin general del desarrollo y construccin como tal del sistema o proyecto de informacin, y esta dividida en tres fases principales, que son la Gestin de los requerimientos que se traducen en el punto de acuerdo entre el
Garcia Freddy, Garcia Mildred, Montes Ramn Pgina 12 de 17

Gerencia de Proyectos

cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente, para ello debemos tener en cuenta las metodologas de anlisis de requerimientos, los mtodos para crear los modelos del sistema, los mtodos de comunicacin y las relaciones de esa misma gestin de requerimientos con los modelos del ciclo de vida que se aplicaran posteriormente. Luego de esto se debe crear el diseo del sistema que en este caso es la segunda fase de las bases tcnicas y consiste en la aplicacin de ciertas herramientas de diagramacin en las cuales se especificara la estructura funcional del sistema y la modularidad del mismo aplicando los diferentes estilos que estn a disposicin actualmente dentro de los cuales podemos nombrar los siguientes: Diseo orientado a objetos, diseo estructurado y diseo orientado a la estructura de datos. La tercera etapa es la construccin del sistema, en esta etapa de Codificacin traduce de forma ms o menos mecnica los algoritmos especificados en la fase anterior a un determinado lenguaje de programacin. Como fruto se obtendr un programa o conjunto de programas fuente que, una vez compilado, dar lugar a un programa ejecutable. Esta etapa puede verse afectada si no se han realizado correctamente las etapas anteriores y podran causar demoras considerables en la culminacin del proyecto. Tras haber construido el sistema se debe realizar La gestin de la configuracin del software es uno de los procesos clave para toda organizacin dedicada a la Ingeniera del software, ya que posibilita una mejor organizacin del desarrollo y mantenimiento, producto, facilitando el resto de procesos de produccin.

Garcia Freddy, Garcia Mildred, Montes Ramn

Pgina 13 de 17

Gerencia de Proyectos

Durante el proceso de construccin de un software, los cambios son inevitables. Los cambios provocan confusin e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniera. La gestin de configuracin del software realiza un conjunto de actividades desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del software de computadora, es una actividad de garanta de calidad del software que se aplica en todas las fases del proceso de ingeniera del software. Por ultimo las Bases del Control de la Calidad, citando dos conceptos se podra decir que: La Calidad del software es el grado con que un sistema, componente o proceso, cumple con los requerimientos especificados y las necesidades o expectativas del cliente o usuario (IEEE, Std. 610-1990), adems, tambin se puede definir como Concordancia del software producido con los requerimientos explcitamente establecidos con los estndares de desarrollo prefijados y con los requerimientos implcitos no establecidos formalmente, que desea el usuario (Pressman 1998). Las pruebas de software son unas de las formas mas comunes de verificacin adems un producto puede probarse de acuerdo al conocimiento de la funcin especfica para la que fue diseado el producto (caja negra). Con la aplicacin de esta tcnica se adquieren pruebas que disminuyen el nmero de casos de prueba. La prueba del mtodo de la caja de cristal frecuentemente es ms eficaz para descubrir errores debido a que los programas sutiles ocurren en la interfaz de sub-programas y la prueba de Pandora se utiliza muy a menudo.
Garcia Freddy, Garcia Mildred, Montes Ramn Pgina 14 de 17

Gerencia de Proyectos

Se puede ver a las inspecciones de software como un repaso detallado y formal del trabajo en proceso. Pequeos grupos de trabajadores (4 o 5) estudian el "producto de trabajo" independientemente y luego se renen para examinar el trabajo en detalle. Los productos de trabajo son considerados en progreso hasta que la inspeccin y las correcciones necesarias estn completas. El tiempo de la inspeccin vara segn cuan familiarizado est el inspector con el material. CAPITULO V GESTIN DE RIESGOS

El quinto capitulo hace referencia a la funcin principal de la gestin de riesgos la cual consiste en identificar, estudiar y eliminar las fuentes de riesgo antes de que amenacen la culminacin exitosa de un proyecto. Estos riesgos pueden ser controlados en varios niveles, estos niveles son: control de crisis, arreglar cada error, mitigacin de riesgos, prevencin y eliminacin de las causas principales. Tomando en cuenta estos niveles es importante resaltar que se deben controlar los riesgos en los dos ltimos niveles, ya que centrar los esfuerzos en la gestin de los riesgos de los tres primeros niveles supone que se ha perdido el control de la planificacin del proyecto. Para llevar a cabo una planificacin para la gestin de riesgos se deben de tomar en cuenta dos elementos fundamentales los cuales son: Estimacin de riesgos y Control de riesgos. La estimacin de riesgos se compone de la identificacin, anlisis y asignacin de prioridades a los riesgos. En cuanto al control de riesgos se compone de planificacin, resolucin y monitorizacin de riesgos. Existen riesgos generales en un proyecto de desarrollo rpido, los cuales se fundamentan en los tres pilares de desarrollo rpido
Garcia Freddy, Garcia Mildred, Montes Ramn Pgina 15 de 17

Gerencia de Proyectos

enunciados en el capitulo dos: cometer uno de los errores clsicos, ignorar las bases de desarrollo y fallar en la gestin activa de riesgos. Considerando lo anterior, se habrn considerado casi todos los tipos de riesgos de los proyectos de software, sin embargo otros errores podran aparecer. Una de las formas ms fciles de estar preparado ante esto, es comprobar el proyecto frente a una lista de posibles riesgos en la planificacin. Los riesgos mas comunes en la planificacin presentan grandes semejantes con los errores clsicos ya comentados en el capitulo 3, la diferencia es que los errores clsicos se cometen con mayor frecuencia, mientras que los riesgos son menos comunes o pueden ser nicos en su proyecto. Una lista completa de riesgos de planificacin comprende situaciones relacionadas con: creacin de la planificacin, organizacin y gestin, entorno de desarrollo, usuarios finales, cliente, personal contratado, requisitos, producto, fuerzas mayores, personal, diseo e implementacin y proceso. Por otra parte, el anlisis de riesgos consiste en analizar cada uno de los riesgos identificados con el propsito de determinar su impacto. El anlisis de riesgos permite elegir entre varias alternativas de desarrollo o para gestionar los riesgos de una alternativa ya seleccionada. En cuanto a la priorizacin de riesgos, se lleva a cabo luego de tener la lista de riesgos de la planificacin, se colocan por orden de prioridad tomando en cuenta los 5 primeros de tal forma que se pueda centrar la atencin en aquellos mas importantes logrando as reducir los retrasos en tiempo estimados para el proyecto.

Garcia Freddy, Garcia Mildred, Montes Ramn

Pgina 16 de 17

Gerencia de Proyectos

Luego de la priorizacin de riesgos se debe realizar un control de estos a travs de tres aspectos: planificacin de la gestin de riesgos, resolucin de riesgos y monitorizacin de riesgos. La planificacin de la gestin de riesgos tiene como objetivo desarrollar un plan para gestionar cada uno de los riesgos identificados. En cuanto a la resolucin de riesgos consiste en una serie de mtodos para tratar riesgos especficos como lo son: evitar el riesgo, trasladar el riesgo de una parte del sistema a otra, conseguir informacin acerca del riesgo, eliminar el origen del riesgo, asumir el riesgo, comunicar el riesgo, comunicarlo, controlarlo y por ultimo y muy importante recordar el riesgo. Se tiene tambin como componente en el control de riesgos la monitorizacin de estos lo cual consiste en la verificacin de un riesgo con la finalidad de comprobar como progresa el control del mismo. Existe una herramienta fundamental para la monitorizacin la cual consiste en crear una lista de por lo menos 10 riesgos principales que contenga adems la posicin del riesgo en la lista, la posicin obtenida anteriormente, el nmero de veces que ha aparecido y un resumen de las medidas llevadas a cabo para controlarlo.

Garcia Freddy, Garcia Mildred, Montes Ramn

Pgina 17 de 17