Gestión de riesgos: Planes de contingencia

Gestión de riesgos: Planes de contingencia

R1. Problemas con los requisitos

Se debe promover que sea el cliente el que escriba en forma general el requerimiento inicial ya que esto lo lleva a clarificar sus ideas para la determinación de las necesidades. El analista debe acompañarlo con entrevistas, cuestionarios realizados previamente, observación y revisión de estos documentos, para luego pasar a la confección de la documentación técnica.

Con esto se reducirán las inexactitudes o la ambigüedad en la especificación de los objetivos del programa.

R2. Problemas legales por el software a utilizar

Hacer uso de herramientas de software libre para el desarrollo de software, sin embargo, en el caso de hacer uso de software de licencia, este deberá ser adquirido de forma legal, pagando por las licencias. El gasto deberá ser registrado en el monto de las herramientas utilizadas, además, se deberá guardar la factura o algún comprobante que garantice que el software utilizado es original y así evitar problemas legales.

R3. Errores inesperados en el software

Hacer uso de Software de control de versiones para administrar los cambios realizados en el programa por los integrantes del equipo, y así garantizar una estabilidad en el software, ya que, en caso de presentar errores en el software, se podrá regresar a la última versión estable del mismo. Además de contar con las versiones actualizadas y estables de las herramientas de desarrollo.

R4. No terminar el proyecto en tiempo y forma

Llevar un control sobre las actividades que se están realizando, además de contemplar un margen de tiempo de la estimación total por alguna complicación que pueda surgir durante el desarrollo del programa, en caso retraso, se deberá tomar medidas como:

La extensión de las horas laborales del equipo de trabajo, la repartición del trabajo entre los integrantes, la solicitud de una prorroga para la entrega del proyecto, las decisiones las deberá tomar el encardado del proyecto.

R5. Poca estabilidad del programa

Se deben de realizar pruebas al programa para determinar que es lo que puede generar el mal funcionamiento y poca estabilidad de este y corregirlo para evitar fallos durante su ejecución.

R6. Falta de conocimiento en el desarrollo del proyecto con java

Todo el personal involucrado en el proyecto deberá ser y estar capacitado para el desarrollo del software, en caso de no estarlo, se deberá contemplar en la planeación de las actividades un lapso corto de tiempo para la capacitación del personal.

En caso de ser necesario se buscaría un lenguaje alternativo con el cual el personal de trabajo este familiarizado.

R7. Exceso de costos planificados

Monitorizar el consumo de recursos regularmente: al igual que el presupuesto debe ser revisado constantemente para mantenerse dentro de los límites oportunos, lo mismo ha de hacerse en lo que respecta al uso de recursos, ya que de las personas que trabajan en un proyecto se deriva una parte importante del coste del mismo. Es necesario que cada participante en el proyecto conozca cuál es la previsión de presupuesto, ya que es obligación de todos racionalizar los consumos. Gestionar con lupa el alcance de proyecto: el presupuesto se calculó en base a una determinada planificación por lo que, si no se lleva un control de la misma, si no se gestiona meticulosamente, el presupuesto puede comenzar a inflarse.

R8. Problemas en el compilador

Hacer uso de las versiones compatibles con el equipo de trabajo y que cuente con soporte técnico, además de verificar que el compilador se ejecute de manera normal en todos los equipos que se utilizaran.

R9. Poca compatibilidad con java y el gestor de BD

Una vez obtenido los requisitos, y establecido las herramientas que se van a utilizar para el desarrollo del programa, tales como, el IDE, el gestor de base de datos, el lenguaje, etc., se debe de considerar la compatibilidad que existe entre las herramientas a usar, en caso de no haber compatibilidad, debe de investigarse una manera de establecer esa compatibilidad o hacer cambios en las herramientas a emplear.

R10. Perdida de interés en el producto por parte del cliente

Se debe de mantener al cliente informado del avance del proyecto periódicamente solo de la parte que al cliente le interesa, sin que este se involucre completamente ya que esto suele ocasionar problemas en el desarrollo del software.

Para ello se pueden realizar reuniones con el cliente para mantenerlo informado y además demostrar compromiso de que se esta trabajando en su proyecto.

R11. Cancelación del proyecto

Tener un contrato en el que se estipule que en caso de cancelación del proyecto, el cliente deberá de pagar una multa del tanto porciento del total del establecido en un inicio, el cual aumentará con forme el avance actual del proyecto.

...