Desarrollo Rapido de Aplicaciones.doc

Gerencia de Proyectos

CAPITULO I BIENVENIDOS AL DESARROLLO RÁPIDO

Este primer capitulo se inicia planteando la visión desde diferentes perspectivas sobre la

concepción del término desarrollo rápido. Para los efectos del libro, se puntualiza el desarrollo

rápido como un término genérico que representa un desarrollo veloz o planificaciones cortas. En

palabras más sencillas, significa desarrollar software con velocidades superiores a las alcanzadas

actualmente. Entonces, un proyecto de desarrollo rápido es cualquier proyecto en el que se requiera

hacer énfasis en la velocidad de desarrollo.

Seguidamente, se aborda el punto sobre como lograr el desarrollo rápido, se plantean dos

principios básicos requeridos para lograr el éxito en proyectos de este tipo, los cuales son:

seleccionar métodos eficaces en lugar de métodos ineficaces, y el segundo, seleccionar métodos

orientados específicamente a alcanzar sus objetivos de planificación. Finalmente se plantea una

serie de métodos de desarrollo orientados a la planificación: los que mejoran la velocidad de

desarrollo, que permiten acortar los tiempos de entrega del software; los que reducen el riesgo en

planificación, 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

métodos adecuados, junto con un plan para usarlos, se obtendrán mejoras significativas en los

resultados de proyectos de desarrollo rápido.

CAPITULO II ESTRATEGIA PARA EL DESARROLLO RÁPIDO

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 máximo potencial. Así

mismo, se señala una estrategia para obtener desarrollo rápido, basado en cuatro pilares

fundamentales: evitar errores clásicos, aplicar bases de desarrollo, gestionar los riesgos y aplicar

métodos orientados a la planificación. Contar con estos cuatro pilares debidamente posicionados, y

que cada uno de ellos sea lo más fuerte posible, constituye el apoyo óptimo para lograr el mejor plan

posible en un proyecto de desarrollo rápido.

Punto seguido, se definen las cuatro dimensiones de la velocidad de desarrollo: personas,

proceso, producto y tecnología.

Garcia Freddy, Garcia Mildred, Montes Ramón Página 1 de 13


Sobre la primera dimensión, personas, se hace referencia a una gran cantidad de estudios

cuyas conclusiones señalan que los temas relacionados con personas, tienen un impacto

fundamental en la productividad y calidad del software. Los métodos más efectivos para apoyar los

procesos de desarrollo rápido, 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 motivación, selección de personal, equipo de

trabajo y formación.

Sobre el proceso, representa un área casi tan relevante como el personal dentro del ámbito

de la estrategia para el desarrollo rápido. 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

continuación: evitar la repetición de trabajo, el control de calidad que incluye el aseguramiento de la

calidad del producto final y la detección de errores en el momento indicado para emplear menos

tiempo y menos costo para corregirlo. Contar con estándares de desarrollo de software a fin de

mantener el control sobre el proyecto; gestionar los riesgos asociados con la planificación; enfoque

de los recursos a los objetivos del proyecto; planificar la asignación de recursos en base al modelo

de ciclo de vida que mas se adapte al proyecto; orientación al cliente visualizando el proyecto de

desarrollo de software desde la asesoría y determinación de requerimientos hasta la construcción a

partir de una especificación.

Sobre producto, el tamaño y características del producto plantean una relación directamente

proporcional al proceso de planificación y por ende a los tiempos de desarrollo del proyecto. A

mayor tamaño del producto y/o características más ambiciosas, mayor será el tiempo y el esfuerzo

invertidos para concluir el proyecto.

Sobre tecnología, 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 rápido.

Sobre la interrogante, ¿Cuál de las dimensiones es la más importante?, es válido decir, que

será la naturaleza misma del proyecto, así como el entorno que lo rodea, los que definirán cuales



dimensiones deberán ser ampliadas y cuales serán limitadas, pero siempre forzando al máximo cada

una ellas para lograr alcanzar el éxito global.

En otro orden de ideas, es importante señalar, 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.

Existen diferentes estándares de desarrollo orientados a la planificación, entre los que se

señalan, los métodos tradicionales, el desarrollo eficiente, desarrollo eficiente orientado al mejor plan

y el desarrollo rápido a fondo. Cada uno de ellos puede tener incidencias distintas en cuanto a: la

planificación, los costos y el producto.

El desarrollo eficiente, se logra evitando los errores clásicos, trabajando sobre bases firmes

de desarrollo y mediante una adecuada gestión de riesgos. Este enfoque, propicia tiempos óptimos

de desarrollo, basado más en una adecuada organización del proyecto que en el empleo de

métodos de desarrollo rápido. Con el desarrollo 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 variación del desarrollo

eficiente, que pudiera implementar métodos que incrementen la velocidad de desarrollo, reduzcan

los riesgos de planificación, o que mejoren la visibilidad del progreso del proyecto. Este enfoque,

pudiera impactar los costos del proyecto, así como ciertas características del producto final.

El último enfoque, es el llamado desarrollo rápido a fondo, el cual consiste en la

implementación de métodos eficientes e ineficientes, para acortar los tiempos del proyecto, sin

importar que esto signifique incremento en costos, altos riesgos o grandes concesiones en las

características del producto final.

Al final de este capítulo, se presenta una estrategia alternativa para desarrollo rápido, que se

basa en hacer uso de un personal altamente calificado y comprometido con el proyecto, así como

técnicas interesantes de motivación, que permitan obtener un máximo rendimiento de los recursos y



por ende resultados altamente aceptables. Esta estrategia, aunque cuenta con algunas limitaciones

y riesgos intensos, en algunos casos podría llegar a tener éxito.

Sin embargo, esta estrategia no garantiza el éxito del proyecto, ya que prácticamente no se

puede controlar. Suele provocar problemas de motivación, 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 fácilmente el daño 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 coordinación, cooperación y planificación; incluso

cuando la velocidad de desarrollo sea más rápida 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 documentación.

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 CLÁSICOS

El tercer capítulo, intitulado Errores Clásicos, se inicia presentando una serie de resultado de

estudios realizados a través de los años, en los 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 pequeños errores pueden afectar la productividad y echar por tierra todo lo bueno que se ha

construido.

En el mundo de desarrollo de software, un pequeño error puede acarrear consecuencias

catastróficas para el desarrollo de un proyecto. Para caer en un desarrollo lento, basta con cometer

algún error, para obtener un desarrollo rápido es necesario evitar cometer errores.

Algunos hábitos o técnicas poco efectivas de software, han sido elegidas tantas veces a

través del tiempo, y aparecen de forma tan repetitiva en circunstancias similares, que para efectos

del libro han sido denominadas errores clásicos. Por lo general, estos errores no producen los

resultados esperados por sus ejecutores.Garcia Freddy, Garcia Mildred, Montes Ramón Página 4 de 13


Un aspecto interesante a resaltar sobre los errores clásicos, es que evitarlos no garantiza

obtener un desarrollo rápido, pero si se cometen, se puede estar seguro de que conseguirá un

desarrollo lento.

A continuación, se presenta un resumen de los mencionados errores clásicos, agrupados

desde el punto de vista de las dimensiones de velocidad de desarrollo:

Persona

Error clásico DescripciónMotivación débil Estudios han demostrado de que uno de los factores

primordiales determinantes de la productividad es la motivación. Un grupo poco motivado es poco productivo.

Personal mediocre Tal como la motivación, las capacidades individuales de los miembros del equipo, así como sus relaciones grupales, inciden altamente en la productividad y la velocidad de desarrollo.

Empleados problemáticos incontrolados

Mantener empleados problemáticos en el equipo de proyecto, suele distorsionar la armonía del grupo y por ende afecta los objetivos del proyecto.

Hazañas Las pretensiones de realizar actos heroicos, fomenta la adición de riesgos al proyecto, e impide la cooperación y fraternización entre varios elementos del proyecto.

Añadir más personal a un proyecto retrazado

Este es uno de los errores más frecuentes, cuando se realiza esto, generalmente es más la productividad que resta a los miembros existentes del equipo, que la que añaden los nuevos integrantes.

Oficinas repletas y ruidosas 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 más productivos que los que trabajan en lugares públicos y ruidosos, lo cual alarga los planes de desarrollo.

Fricciones entre los clientes y los desarrolladores

Esto trae como consecuencia, mala comunicación entre las partes, lo cual se traduce en una pobre especificación de requerimientos, diseños no ajustados a las necesidades del cliente, y en algunos casos hasta el rechazo del producto final.

Expectativas poco realistas 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 impresión de que el proyecto estuviera fuera de control o mal planificado.

Falta de un promotor efectivo del proyecto

Sin un promotor ejecutivo efectivo, el resto de personal de alto nivel de la empresa, podría forzar a que se acepten fechas de entrega irreales y/o cambios que debiliten el proyecto.



Falta de participación de los implicados

Los principales participantes del esfuerzo de desarrollo, deben implicarse en el proyecto. La coordinación estrecha y la coordinación adecuada de los esfuerzos y recursos, depende en gran medida de que se hayan implicado en el proyecto la totalidad de sus participantes.

Falta de participación del usuario 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.

Política antes que desarrollo Colocar la política por encima de los resultados, resulta fatal para el desarrollo orientado a velocidad.

Ilusiones Las ilusiones al inicio del proyecto, impiden llevar a cabo una planificación coherente y ajustada a la realidad.

Proceso

Error clásico DescripciónPlanificación excesivamente optimista

Fijar un plan excesivamente optimista, predispone a que el proyecto falle por infravalorar sus alcances, y supone una excesiva presión para los desarrolladores que pudiera mermar su productividad. Además, de reducir el tiempo para actividades críticas que pudieran afecta el logro de los objetivos.

Gestión de riesgo insuficiente Si no se ejerce una gestión activa del riesgo, basta con que solo vaya mal una cosa para pasar de un desarrollo rápido a un desarrollo lento.

Fallos de los contratados Si no se gestiona adecuadamente la contratación de desarrolladores externos, es más probable ralentizar el proyecto que acelerarlo. Riesgos como requerimientos inestables o interfaces mal definidas, pueden ser enormes cuando un contratado entra en escena.

Planificación insuficiente Si no se planifica para obtener un desarrollo rápido, no se puede esperar obtenerlo.

Abandono de la planificación bajo presión

Ciertos problemas pueden ocurrir en el desarrollo del proyecto que ameriten dejar la planificación. El problema no es el abandono, sino en no crear un plan alternativo.

Pérdida de tiempo en el inicio difuso

Es muy común que esta pérdida de tiempo al inicio del proyecto, desencadene en una planificación muy agresiva para tratar de recuperar el tiempo perdido. Es preferible, acortar los tiempos de inicio y tener una planificación más holgada.

Escatimar en las actividades iniciales

Los proyectos que escatiman en los trabajos iniciales, generalmente tendrán que hacerlos en otro momento, con un costo superior al haberlo hecho bien al principio.

Diseño inadecuado Es el resultado de una escatimación en las actividades de diseño. Un diseño inadecuado, crea un entorno de alta presión que dificulta la posibilidad de considerar la mayor cantidad de alternativas de diseño. El énfasis en diseño, va mas orientado a conveniencia que ha calidad.

Escatimar en el control de calidad Minimizar las actividades de control de calidad, podría Garcia Freddy, Garcia Mildred, Montes Ramón Página 6 de 13


conllevar a el alargue de algunas actividades finales para poder alcanzar la calidad de producto deseada. Esta situación atenta contra la velocidad de desarrollo.

Control insuficiente de la directiva Las figuras de alto rango en la organización, deben estar en la capacidad de monitorear si este va por buen camino, para poder ejercer los correctivos necesarios y mantener encarrilado el proyecto.

Convergencia prematura o excesivamente frecuente

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 pérdida de tiempo que prolonga el plan.

Omitir tareas necesarias en la estimación

Las actividades ocultas y el esfuerzo omitido en la planificación, suele aumentar el plan de desarrollo entre un 20 y 30 por ciento.

Planificar ponerse al día más adelante

Un tipo de reestimación, es responder inapropiadamente al retraso del plan. En muchos proyectos con retraso, se plantea recuperarlo más tarde, pero nunca se hace.

Programación a destajo Muchas empresas piensan que un grupo de desarrolladores suficientemente motivados, pueden solventar cualquier obstáculo, inclusive, una planificación demasiado ambiciosa.

Producto

Error clásico DescripciónExceso de requerimientos Algunos proyectos, tienen más 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 prestaciones Nuevas prestaciones del producto a lo largo 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 rápido.

Desarrolladores meticulosos Los desarrolladores encuentran fascinante las nuevas tecnologías, 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 negociación Cuando se aprueba un retraso del plan de proyecto que no marcha según 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 investigación

Si el proyecto fuerza los limites de la informática porque necesita la creación de nuevos algoritmos o nuevas técnicas de computación, entones no es un proyecto de desarrollo software, sino de investigación en software. Los planes de investigación sobre software no son predecibles teóricamente.



Tecnología

Error clásico DescripciónSíndrome de la panacea Aferrarse a una nueva técnica, tecnología o procedimiento

rígido, no resuelve en absoluto los problemas de planificación.

Sobreestimación del empleo de nuevas herramientas o métodos

Los beneficios de las nuevas técnicas son parcialmente desplazados por la curva de aprendizaje, también suponen nuevos riesgos que solo se descubren usándolas. Estimaciones demasiado ambiciosas en el aumento de la productividad al implementar nuevas tecnologías, aumenta el riesgo de obtener retrasos en la planificación.

Cambiar de herramienta a la mitad del proyecto

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.

Falta de control automático del código fuente

El control manual de actualizaciones de los programas, que pudieran estar siendo actualizados simultáneamente y la imposibilidad de regresar a versiones anteriores del código fuente, pudiera causar retrasos, pérdida de secciones de programas o esfuerzos de sincronización 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. Además las personas que han solicitado el software tienen un papel a desempeñar en el

proceso del software. Esto es de vital importancia ya que proporciona estabilidad, control y

organización a una actividad que puede volverse caótica en muchos de los casos.

Las bases para el desarrollo de software son las Bases de Gestión, Bases Técnicas, 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 existirán tropiezos que hagan tambalear

el proyecto.



Las bases de gestión esta compuesta por tres etapas, planificación, Seguimiento y Medición,

es estas etapas están implícitos 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 estimación del tamaño del producto y ello a su vez

involucra el esfuerzo que será necesario para la construcción del mismo, esto conlleva a una cadena

íntimamente relacionada en la cual si se realiza una buena estimación, existe una alta probabilidad

de que se haga una planificación 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

planificación 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 técnicas para poder hacer las mediciones

correspondientes y de esta forma visualizar el progreso del software de una manera más exacta y

eficiente.

Sin duda las Bases técnicas nos proporcionan una visión general del desarrollo y

construcción como tal del sistema o proyecto de información, y esta dividida en tres fases

principales, que son la Gestión de los requerimientos que se traducen en el punto de acuerdo entre

el 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 metodologías de análisis de requerimientos, los métodos para crear los modelos del

sistema, los métodos de comunicación y las relaciones de esa misma gestión de requerimientos con

los modelos del ciclo de vida que se aplicaran posteriormente.

Luego de esto se debe crear el diseño del sistema que en este caso es la segunda fase de

las bases técnicas y consiste en la aplicación de ciertas herramientas de diagramación en las cuales

se especificara la estructura funcional del sistema y la modularidad del mismo aplicando los

diferentes estilos que están a disposición actualmente dentro de los cuales podemos nombrar los

siguientes: Diseño orientado a objetos, diseño estructurado y diseño orientado a la estructura de

datos.

La tercera etapa es la construcción del sistema, en esta etapa de Codificación traduce de

forma más o menos mecánica los algoritmos especificados en la fase anterior a un determinado



lenguaje de programación. 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 podrían causar demoras considerables en la

culminación del proyecto.

Tras haber construido el sistema se debe realizar La gestión de la configuración del software

es uno de los procesos clave para toda organización dedicada a la Ingeniería del software, ya que

posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de

procesos de producción.

Durante el proceso de construcción de un software, los cambios son inevitables. Los

cambios provocan confusión 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 ingeniería.

La gestión de configuración 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 garantía de calidad del software que se aplica en todas las fases del proceso de

ingeniería del software.

Por ultimo las Bases del Control de la Calidad, citando dos conceptos se podría 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), además, también se puede definir como “Concordancia del software producido con los

requerimientos explícitamente establecidos con los estándares de desarrollo prefijados y con los

requerimientos implícitos no establecidos formalmente, que desea el usuario” (Pressman 1998).

Las pruebas de software son unas de las formas mas comunes de verificación además un

producto puede probarse de acuerdo al conocimiento de la función específica para la que fue

diseñado el producto (caja negra). Con la aplicación de esta técnica se adquieren pruebas que

disminuyen el número de casos de prueba.

La prueba del método de la caja de cristal frecuentemente es más 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.



Se puede ver a las inspecciones de software como un repaso detallado y formal del trabajo

en proceso. Pequeños grupos de trabajadores (4 o 5) estudian el "producto de trabajo"

independientemente y luego se reúnen para examinar el trabajo en detalle. Los productos de trabajo

son considerados en progreso hasta que la inspección y las correcciones necesarias estén

completas. El tiempo de la inspección varía según cuan familiarizado esté el inspector con el

material.

CAPITULO V GESTIÓN DE RIESGOS

El quinto capitulo hace referencia a la función principal de la gestión de riesgos la cual

consiste en identificar, estudiar y eliminar las fuentes de riesgo antes de que amenacen la

culminación exitosa de un proyecto. Estos riesgos pueden ser controlados en varios niveles, estos

niveles son: control de crisis, arreglar cada error, mitigación de riesgos, prevención y eliminación 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 gestión de los

riesgos de los tres primeros niveles supone que se ha perdido el control de la planificación del

proyecto.

Para llevar a cabo una planificación para la gestión de riesgos se deben de tomar en cuenta

dos elementos fundamentales los cuales son: Estimación de riesgos y Control de riesgos. La

estimación de riesgos se compone de la identificación, análisis y asignación de prioridades a los

riesgos. En cuanto al control de riesgos se compone de planificación, resolución y monitorización de

riesgos.

Existen riesgos generales en un proyecto de desarrollo rápido, los cuales se fundamentan

en los tres pilares de desarrollo rápido enunciados en el capitulo dos: cometer uno de los errores

clásicos, ignorar las bases de desarrollo y fallar en la gestión activa de riesgos. Considerando lo

anterior, se habrán considerado casi todos los tipos de riesgos de los proyectos de software, sin

embargo otros errores podrían aparecer. Una de las formas más fáciles de estar preparado ante

esto, es comprobar el proyecto frente a una lista de posibles riesgos en la planificación.

Los riesgos mas comunes en la planificación presentan grandes semejantes con los errores

clásicos ya comentados en el capitulo 3, la diferencia es que los errores clásicos 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 planificación comprende situaciones relacionadas con:

creación de la planificación, organización y gestión, entorno de desarrollo, usuarios finales, cliente,

personal contratado, requisitos, producto, fuerzas mayores, personal, diseño e implementación y

proceso.

Por otra parte, el análisis de riesgos consiste en analizar cada uno de los riesgos

identificados con el propósito de determinar su impacto. El análisis de riesgos permite elegir entre

varias alternativas de desarrollo o para gestionar los riesgos de una alternativa ya seleccionada.

En cuanto a la priorización de riesgos, se lleva a cabo luego de tener la lista de riesgos de la

planificación, se colocan por orden de prioridad tomando en cuenta los 5 primeros de tal forma que

se pueda centrar la atención en aquellos mas importantes logrando así reducir los retrasos en

tiempo estimados para el proyecto.

Luego de la priorización de riesgos se debe realizar un control de estos a través de tres

aspectos: planificación de la gestión de riesgos, resolución de riesgos y monitorización de riesgos.

La planificación de la gestión de riesgos tiene como objetivo desarrollar un plan para gestionar cada

uno de los riesgos identificados. En cuanto a la resolución de riesgos consiste en una serie de

métodos para tratar riesgos específicos como lo son: evitar el riesgo, trasladar el riesgo de una parte

del sistema a otra, conseguir información 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 también como componente en el control de riesgos la monitorización de estos lo

cual consiste en la verificación de un riesgo con la finalidad de comprobar como progresa el control

del mismo. Existe una herramienta fundamental para la monitorización la cual consiste en crear una

lista de por lo menos 10 riesgos principales que contenga además la posición del riesgo en la lista, la

posición obtenida anteriormente, el número de veces que ha aparecido y un resumen de las medidas

llevadas a cabo para controlarlo.




Documents

Desarrollo Rapido de Aplicaciones.doc