Planificación Y Modelado Unidad 3 Y 4

Unidad 3.
3.- Análisis del Proyecto.

La administración efectiva de un proyecto de software depende de planear completamente el progreso del proyecto. El Administrador del proyecto debe anticiparse a los problemas que pudieran surgir, así como preparar soluciones tentativas a esos problemas. Un plan, preparado al inicio de un proyecto, debe utilizarse como un conductor para el proyecto. Esteplan inicial debe ser el mejor posible de acuerdo con la información disponible. Este evolucionara conforme el proyecto progrese y la información disponible será mejor.

La planeación es un proceso iterativo que solamente se completa cunado el proyecto mismo se termina. Conforme la información se hace disponible, el plan debe revisarse regularmente. Las metas globales del negocio son un factorimportante que debe considerarse cuando se formula el plan del proyecto conforme esto cambie, lo cambios en el proyecto serán necesarios.

3.1.- Análisis de Riesgos.

Durante este proceso, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo.

Tipo de Riesgo | Riesgos posibles |
Tecnología | La base de datos que se utiliza en elsistema no puede procesar muchas transacciones por segundo como se esperaba.Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad. |
Personas | Es imposible reclutar personal con las habilidades requeridas para el proyecto.El personal clave esta enfermo y no disponible en momentos críticos.La capacitación solicitada para el personal no esta disponible. |Organizacional | La organización se reestructura de tal forma que una administración diferente se responsabiliza del proyecto. Los problemas financieros de la organización fuerzan a reducciones en el presupuesto del proyecto. |
Herramientas | Es ineficiente el código generado por las herramientas CASE. Las herramientas CASE no se pueden integrar. |
Requerimientos | Se proponen cambios en losrequerimientos que requieren rehacer el diseño. Los clientes no comprenden el impacto de los cambios en los requerimientos. |
Estimación | El tiempo requerido para desarrollar el software esta subestimado. La tasa de reparación de defectos esta subestimada. El tamaño del software esta subestimado. |

No existe una forma fácil de hacer esto, recae en la opinión y experiencia del administrador delproyecto. No se hace una valoración con números precisos sino en intervalos:

1.- La probabilidad de que el riesgo se valore como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%).
2.- Los efectos del riesgo pueden ser valorados como catastrófico, serio, tolerable o insignificante.

El resultado de este proceso de análisis se debe colocar en una tabla,la cual debe estar ordenada acorde a la seriedad del juego.
En la practica, para hacer esta valoración se necesita información detalla del proyecto, el proceso, el equipo de desarrollo y la organización.
Por supuesto, tanto la probabilidad y la valoración de los efectos de un riesgo cambia conforme se disponga de mayor información acerca del riesgo y los planes de administración del mismo seimplementen.

Una vez que los riesgos se hayan analizado y clasificando, se debe discernir cuales son los mas importantes que se deben considerar durante el proyecto. Este discernimiento depende de una combinación de la probabilidad del riesgo den cuestión y los efectos del mismo. En general, siempre se deben tomar en cuenta todos los riesgos catastróficos; así como todos los riesgos serios quetienen más que una moderada probabilidad de ocurrir.

Boehm (1988) recomienda identificar y supervisar los “10 riesgos más altos”, pero creo que este número es demasiado arbitrario. El número exacto de riesgo s a supervisar debe depender del proyecto. Pueden ser cinco o 15. No obstante, el número apropiado debe ser manejable. Un número muy grande de riesgos requiere obtener mucha información. De...