Determinación de Riesgos

Para la determinación de los riesgos, los vamos a dividir en diferentes tipos: tamaño del producto, impacto en el negocio, relacionados con los clientes, proceso, tecnológicos, de entorno de desarrollo y los asociados con el tamaño de la plantilla de personal.

Para abordar cada uno de estos riesgos, se rellenará una plantilla con la siguiente estructura:

  • Incertidumbre: Probabilidad de que surja el riesgo.
  • Categoría del impacto: despreciable, marginal, crítico y catastrófico.
  • Evaluación de las consecuencias del riesgo: rendimiento, mantenimiento, tiempo de desarrollo y coste.
  • Actuación en consecuencia: decisiones tomadas para intentar minimizar el impacto del riesgo, y reacción al mismo.

1. Riesgos del Tamaño del Producto:

Tamaño de la base de datos crezca hasta consumir toda la capacidad:

  • Incertidumbre: 1%, ya que es complicado que el sistema consuma la totalidad del almacenamiento secundario de que disponga el sistema
  • Categoría del impacto: Crítico
  • Evaluación de las consecuencias del riesgo: en caso de que se produjera este riesgo, el cliente no podría seguir trabajando con la aplicación ya que no podría añadir más información al sistema.
  • Actuación en consecuencia: Se intentará que el sistema se instale al menos con una capacidad extra de unos 20 MB. Si no es posible o se termina consumiendo toda la capacidad, adquirir un dispositivo de almacenamiento con capacidad suficiente.

Desviación de la estimación de costos establecida:

  • Incertidumbre: 50%. Este riesgo tiene esta alta probabilidad de que suceda debido a que inicialmente (cuando se realiza la estimación), no se conoce en profundidad todos los percances e inconvenientes que puedan aparecer en cada una de las etapas del desarrollo
  • Categoría del impacto: marginal
  • Evaluación de las consecuencias del riesgo: Mayor duración en la realización de algunas de las tareas, lo que produce mayor duración en el desarrollo del sistema global
  • Actuación en consecuencia: Se intentará ajustar lo más posible a la realidad la estimación de costos. Si se tiene que modificar, también se modificará la planificación, introduciendo nuevos datos y recomponiendo todas las tareas que derivan de la tarea en la que se ha producido el riesgo.

2. Riesgos de Impacto en el Negocio:

Fecha límite de entrega no razonable:

  • Incertidumbre: 50%. Este riesgo tiene esta probabilidad de que suceda debido a que inicialmente (cuando hemos realizado la estimación y la planificación), no se conoce en profundidad todos los percances e inconvenientes que puedan aparecer en cada una de las etapas del desarrollo, y esto puede llevar a retrasar la entrega final del producto
  • Categoría del impacto: Crítico
  • Evaluación de las consecuencias del riesgo: Mayor duración en la realización de algunas de las tareas, lo que produce mayor duración en el desarrollo del sistema global, y como consecuencia, la entrega del producto final se verá desplazada en el tiempo.
  • Actuación en consecuencia: Se intentará poner una fecha límite holgada para evitar que este riesgo se produzca. Si aún así sucede, tendremos que modificar el hito de entrega final de la planificación y amoldarnos a la nueva fecha de entrega, así como ir modificando progresivamente el archivo de planificación conforme se conozcan los detalles de la duración de cada una de las tareas.

Mala satisfacción del usuario final:

  • Incertidumbre: 5%. Es baja dicha probabilidad porque en el desarrollo del proyecto interactuaremos con el usuario en gran medida, de tal manera que es el que irá imponiendo la especificación del sistema deseada, y por lo tanto el producto final será semejante a lo que el cliente quiere.
  • Categoría del impacto: Crítico
  • Evaluación de las consecuencias del riesgo: En caso de que el cliente esté disconforme con algún aspecto del producto final, éste deberá ser cambiado a uno semejante al que el cliente solicita.
  • Actuación en consecuencia: Para que esto no ocurra, se tienen programadas varias entrevistas con el cliente, de tal forma que se va moldeando el producto conforme el cliente impone las especificaciones Si se llega al punto de la mala satisfacción, se deberá de realizar una nueva entrevista con el cliente para que explique lo que realmente quiere y, a partir de ella, redactar una nueva especificación con los cambios oportunos. Después se realizará el proceso de análisis y diseño de las partes afectadas, y la implementación correspondiente.

Cantidad y calidad no aceptable de la documentación del producto que debe ser elaborada y entregada al cliente:

  • Incertidumbre: 5%. La probabilidad es baja porque la documentación entregada al cliente será bastante completa. Se realizará documentación de todos los pasos realizados para el diseño y desarrollo de la aplicación, y se revisará paulatinamente.
  • Categoría del impacto: Marginal
  • Evaluación de las consecuencias del riesgo: Se deberán de revisar o rehacer las partes de la documentación afectadas.
  • Actuación en consecuencia: Para minimizar la ocurrencia de este riesgo, se intentará documentar todas y cada una de las decisiones importantes que se tomen. También se intentará pasar por un proceso de aprendizaje/refresco de conceptos antes de cada etapa de análisis y diseño en el desarrollo del producto para hacer una documentación de calidad. Si aún así el cliente piensa que la documentación no es aceptable, habrá que modificar la documentación entregada. Se deberá de realizar de nuevo una entrevista con el cliente y que nos muestre las disconformidades que presenta con la documentación. Se deberá de completar y mejorar la parte de la documentación que crea el cliente que debe ser modificada.

Producto final defectuoso:

  • Incertidumbre: 4%. Es baja ya que durante el desarrollo de la aplicación habrá una fase de pruebas que hay que superar, y para superar dicha fase habrá que simular la mayoría de las posibilidades que se pueden dar en la vida real con el sistema.
  • Categoría del impacto: Catastrófico
  • Evaluación de las consecuencias del riesgo: Si se detecta que el producto es defectuoso, el producto será retirado al cliente y se intentará detectar y solucionar dicho error en el menor tiempo posible.
  • Actuación en consecuencia: Para evitar esto, se realizará una etapa de pruebas intensiva al finalizar cada uno de los prototipos, con el fin de encontrar y eliminar la mayor parte de los errores. Si se detecta alguno, se actuará de la siguiente manera: detección del fallo encontrado, buscar una posible solución, modificar el diseño, implementar de nuevo la parte afectada y hacer las respectivas pruebas para observar que se ha corregido el error. Posteriormente habrá que seguir haciendo pruebas para observar si se produce algún error como consecuencia de la modificación introducida.

3. Riesgos Relacionados con el Cliente:

El cliente no tiene una idea formal de lo que quiere:

  • Incertidumbre: 15%. Es una probabilidad media dado que el cliente no tiene por qué tener un nivel mínimo de conocimientos informáticos, y el producto que describe en las primeras entrevistas es posible que no se asemeje a lo que en realidad él mismo necesita, por lo que irá paulatinamente modificando aspectos del sistema que se diferenciarán bastante entre versiones.
  • Categoría del impacto: Catastrófica
  • Evaluación de las consecuencias del riesgo: Las consecuencias pueden ser terribles ya que si el cliente no tiene las ideas claras de lo que realmente quiere, en cualquier momento del desarrollo del producto puede cambiar de opinión y sus dudas afectarían al análisis y diseño llevado hasta la fecha.
  • Actuación en consecuencia: Para evitar la ocurrencia de este riesgo, se intentará que en todas las entrevistas tanto el cliente como nosotros sepamos en todo momento de lo que se está hablando, utilizando un lenguaje coloquial para que el cliente no se líe con tecnicismos. Eso facilitará que nos pueda expresar exactamente lo que quiere. Si aún así hay algún cambio de opinión sobre algún punto concreto, se deberá de entrevistar de nuevo al cliente y escuchar sus nuevas exigencias. Posteriormente habría que analizar qué parte de la realizada hasta el momento se podría reutilizar y el resto realizarla de nuevo, desde el análisis hasta la fase de pruebas.

El cliente no acepta realizar reuniones de requisitos:

  • Incertidumbre: 1%. Es poco probable ya que es el propio cliente el que está interesado en la realización del producto, y las reuniones son indispensables para la buena terminación del mismo.
  • Categoría del impacto: Catastrófica
  • Evaluación de las consecuencias del riesgo: En dicho caso, el cliente no nos aportaría la especificación del sistema, por lo que el producto que podamos desarrollar no se asemejará al que realmente quiere, ya que no conocemos sus necesidades.
  • Actuación en consecuencia: Para que esto no suceda, se ha concienciado al cliente de la importancia que tienen estas reuniones para el buen funcionamiento del producto. En caso de que no quiera/pueda reunirse, buscaremos a alguien relacionado con el tema que vamos a tratar (en nuestro caso una floristería) e intentaremos entrevistarlo para sacar las conclusiones necesarias para continuar con el desarrollo del proyecto.

El cliente no participa en revisiones:

  • Incertidumbre: 3%. También tiene una probabilidad baja de que suceda ya que el cliente es el que ha solicitado el producto y el que ha establecido la especificación del sistema, por lo que tendrá interés en ver como se desarrolla la construcción del mismo.
  • Categoría del impacto: Catastrófica
  • Evaluación de las consecuencias del riesgo: En caso de que esto suceda, el cliente se puede encontrar con un producto final que no le satisface lo suficiente. Esto es debido a que no ha seguido el proceso de desarrollo.
  • Actuación en consecuencia: Se intentará motivar al cliente proponiéndole cambios y dándole una visión global del sistema, para que muestre interés y se sienta parte del equipo de desarrollo. Si aún así el cliente no asiste a las revisiones del producto, nos guiaremos por el sentido común y trataremos de decidir si el producto se asemeja al que pedía el cliente, y en caso contrario, amoldarlo a sus peticiones iniciales lo máximo posible.

4. Riesgos del Proceso:

No exista un proceso de desarrollo del software:

  • Incertidumbre: 0.1%. Este caso es prácticamente imposible que suceda porque están previstas unas fases de desarrollo de software para la elaboración del producto que obligatoriamente se deberán de cumplir.
  • Categoría del impacto: Catastrófico
  • Evaluación de las consecuencias del riesgo: En caso de que se decidiese realizar el software sin un proceso de desarrollo respaldándolo, posiblemente el producto final resultante sería de mucha menor calidad con respecto al mismo obtenido siguiendo un proceso de desarrollo.
  • Actuación en consecuencia: Desde el principio se están siguiendo una serie de normas y pautas para construir el software requerido, siguiendo unas fases de desarrollo del sistema que pasan por el análisis, el diseño, la implementación y las pruebas del sistema. Si se necesitase prescindir de las mismas, deberemos de realizar una interfaz y una implementación directa del sistema final, o incluso se puede introducir un diseño de urgencia del producto, pero como se ha comentado antes, se obtendría un resultado posiblemente poco satisfactorio.

No exista una especificación de requisitos, diseño y código:

  • Incertidumbre: 0,2%. Este caso es prácticamente imposible que suceda ya que tenemos establecidas esas fases en el desarrollo de la aplicación, y sin alguno de esos tres apartados el resultado será muy pobre.
  • Categoría del impacto: Catastrófico
  • Evaluación de las consecuencias del riesgo: Como consecuencia, no tendríamos tres fases importantes en el desarrollo de la aplicación, por lo que el producto final resultante sería de muy baja calidad con respecto a otro desarrollado con esas fases. Incluso no se podría obtener un producto útil al no existir implementación.
  • Actuación en consecuencia: Esas fases están planificadas desde el comienzo del proyecto. Si se necesitase prescindir de las mismas, deberemos de realizar un producto final posiblemente poco satisfactorio. Éste será de muy mala calidad e incluso posiblemente no será válido.

5. Riesgos Tecnológicos:

El software interactúe con hardware no compatible:

  • Incertidumbre: 5%. Se ha estimado una baja probabilidad por la baja necesidad de prestaciones de que dispondrá el sistema final. Esto unido a que los equipos informáticos de hoy en día tienen unas prestaciones suficientemente elevadas para lo que el producto necesita conformaría una baja probabilidad de ocurrencia de este riesgo.
  • Categoría del impacto: Catastrófica
  • Evaluación de las consecuencias del riesgo: En caso de producirse este riesgo, el PC existente en el establecimiento no soportaría las exigencias de la aplicación (caso que se podría dar si el PC es muy antiguo), o que el software sea incompatible con el hardware existente (casi imposible por el tipo de aplicación), lo que producirá que no se pueda ejecutar la aplicación desarrollada.
  • Actuación en consecuencia: Para minimizar su ocurrencia, nos hemos asegurado de que el hardware disponible del usuario final sea compatible con el software que vamos a desarrollar, haciendo también que el resultado final requiera unas prestaciones mínimas que sean fácilmente alcanzables. Como consecuencia de que aún así no sean compatibles hardware y software, lo recomendable es que el cliente realice una compra de un PC relativamente nuevo, para que las prestaciones exigidas por la aplicación las pueda cumplir sin complicaciones.

Error en la interacción de la aplicación con la base de datos:

  • Incertidumbre: 10%. Este riesgo tiene una probabilidad media ya que la conexión con el exterior de la aplicación (con BD) puede tener riesgo de que se pueda caer, aunque la batería de pruebas sea extensa.
  • Categoría del impacto: Catastrófica
  • Evaluación de las consecuencias del riesgo: En caso de producirse este riesgo debido a cualquier fallo de conexión o fallo en la consulta o modificación de datos, la aplicación debe cerrarse. No se podrá volver a usar dicha aplicación hasta que no se localice el motivo del fallo y se corrija.
  • Actuación en consecuencia: Para minimizar las consecuencias de un error así y poder terminar bien el sistema, se comprobará siempre tras utilizar la conexión que la BD nos ha devuelto algo válido, manejando también los casos en los que falle la conexión para no cerrar de golpe la aplicación. Al producirse un error con la conexión, lo primero que debemos hacer es detectar en qué parte se ha producido. Una vez localizado (conexión, error lógico de datos, desbordamiento, etc.) se introducen en el sistema las soluciones o restricciones necesarias para que no vuelva a producirse dicho error y posteriormente se prueba para observar que no vuelve a producirse el error y otros que se hayan podido ocasionar.

La aplicación no tiene la funcionalidad pedida:

  • Incertidumbre: 2%. Es difícil que se dé este caso ya que la aplicación se ha ido elaborando a partir de la especificación dada por el cliente, en la cual mostraba la funcionalidad de la aplicación. Puede suceder que alguna función deseada se haya pasado por alto, pero no que la aplicación entera no cumpla con el cometido con el que se ha creado.
  • Categoría del impacto: Crítica
  • Evaluación de las consecuencias del riesgo: Si se ha observado que la funcionalidad de la aplicación no es la que se pedía o que algunas características no han sido tomadas en cuenta, podemos decir que la aplicación estará incompleta. La aplicación podrá seguir ejecutándose pero teniendo en cuenta la falta de dichas funcionalidades, y que existen posibilidades de que las tareas relacionadas con ellas no podrán ser realizadas.
  • Actuación en consecuencia: Para intentar evitar esto, se harán reuniones progresivas con el cliente para detectar una falta de funcionalidad lo más pronto posible. En caso de que la funcionalidad de la aplicación no sea la que se ha pedido, se debe de estudiar de nuevo las características que se han solicitado que cumpla el sistema. Posteriormente habrá que realizar el proceso de análisis, diseño e implementación de las nuevas funcionalidades tomadas en cuenta.

El cliente solicita que se debe de tener una interfaz especial:

  • Incertidumbre: 30%. Este caso se puede dar con cierta facilidad ya que hoy en día muchas de las aplicaciones pueden utilizarse, por ejemplo, con pantalla táctil.
  • Categoría del impacto: Crítico
  • Evaluación de las consecuencias del riesgo: Este riesgo no afecta al producto anterior, sino que sería una nueva versión. En este caso, lo que hay que cambiar en la aplicación será el interfaz. Habría que diseñar una interfaz nueva que cumpla con los requisitos exigidos.
  • Actuación en consecuencia: En la fase de implementación, se intentará separar lo máximo posible la parte compleja del interfaz, para en su caso facilitar el cambio de éste por otro distinto. Si surge el riesgo, hay que elaborar una nueva interfaz, teniendo en cuenta que cumpla las nuevas especificaciones. Una vez hecho esto, hay que adaptar la implementación de las funciones que teníamos con anterioridad a la interfaz nueva creada. Posteriormente hay que hacer pruebas para comprobar su correcto funcionamiento.

Pérdida de datos debido a un fallo hardware:

  • Incertidumbre: 2%. Tiene una probabilidad baja, pero existe el riesgo de perder datos debido a ruptura de disco, borrado accidental, etc.
  • Categoría del impacto: Crítico
  • Evaluación de las consecuencias del riesgo: La aparición de este riesgo supone perder el trabajo que teníamos sin almacenar en una copia de seguridad hasta el momento (al menos prácticamente todo). Por ello, tenemos que prevenir para que el impacto sea el menor posible.
  • Actuación en consecuencia: Para intentar minimizar las consecuencias, se van a realizar varias acciones: cada uno de los integrantes del equipo tendrá en todo momento una copia local en su máquina de los documentos anteriores al que en el momento se esté trabajando. Además de la copia local, tendremos los últimos cambios que se realicen almacenados en un repositorio (situado en la máquina de nuestro tutor de proyecto), al que accederemos para ir actualizando los datos conforme los tengamos preparados. Por último, una vez comience la primera fase de implementación (que será cuando empecemos a tener un gran volumen también de documentación) se programarán diversas copias de seguridad incrementales semanal o bisemanalmente. Si aún así se llega a perder gran parte de información, no queda más remedio que rehacerla de nuevo e indicarlo en la planificación.

6. Riesgos en el Entorno de Desarrollo:

Herramientas no adecuadas para realizar cualquier tarea:

  • Incertidumbre: 5%. Existe una baja probabilidad, ya que se pueden encontrar herramientas de software libre fácilmente para ayudar a realizar cualquiera de las tareas que se han planificado. Aún así, es posible que no se encuentre una herramienta que no nos permita realizar alguna funcionalidad que necesitamos.
  • Categoría del impacto: Crítico
  • Evaluación de las consecuencias del riesgo: En caso de no encontrar una herramienta que nos pueda ofrecer una funcionalidad deseada, se obtendrá una pérdida de calidad en la documentación aportada, ya que dicha tarea (por ejemplo, realización de diagramas de secuencia) deberá hacerse manualmente, teniendo todos los inconvenientes de la ausencia de ayuda que ofrece una herramienta específica. En caso de que no se pueda realizar dicha tarea del diseño manualmente, deberemos de saltarnos dicha parte del diseño, con las desventajas que ello produciría.
  • Actuación en consecuencia: Para que esto no ocurra, se ha intentado buscar las herramientas más completas en la Web, que nos permitan realizar todas las tareas planteadas en la planificación, y se ha planificado una de éstas específicamente para la búsqueda de software. Si la funcionalidad no la ofrece ninguna de las herramientas que en un principio utilizamos, se planificará un tiempo de búsqueda de nuevo para encontrar otra herramienta que nos facilite la realización de la tarea en cuestión. En caso de que se haya buscado de forma intensiva y no se encuentre la herramienta adecuada para un problema concreto, deberíamos de realizar dicha tarea directamente a mano, con sus correspondientes desventajas (en el caso de que se pueda hacer). En la realización de dichas partes del diseño a mano debemos de mostrarnos con más concentración porque será más fácil realizar un fallo que con la asistencia de una herramienta.

Formación no adecuada en todas las herramientas:

  • Incertidumbre: 20%. Puede darse con cierta frecuencia, ya que las diferentes herramientas disponen de muchas funciones que en un principio no se necesitarán, pero que posteriormente pueden ser útiles, por lo que tendremos la necesidad de volver a formarnos en dicha herramienta.
  • Categoría del impacto: Marginal.
  • Evaluación de las consecuencias del riesgo: Este riesgo no supone una gran catástrofe, ya que puede solucionarse dedicándole un poco más de tiempo a la formación sobre dicha herramienta, a través de la ayuda de la aplicación o con un manual de usuario.
  • Actuación en consecuencia: Para evitar que la aparición de este riesgo sea muy frecuente, se intentará antes de utilizar una herramienta, pasar por un período de aprendizaje intensivo, en el que obtendremos un manejo básico de las funcionalidades que en un principio utilizaremos de la herramienta. Si surge dicho riesgo, podemos solucionarlo dedicándole un poco de tiempo nuevamente a formación. Debemos de decidir los medios para completar nuestra formación sobre dicha herramienta (la ayuda de dicha herramienta, con un manual de usuario, etc.). Una vez solucionada la falta de formación, se continuará con el trabajo.

7. Riesgos Relacionados con la Plantilla de Personal:

Conocimientos o formación no adecuados del personal:

  • Incertidumbre: 30%. Puede darse con cierta facilidad que cierta persona de la plantilla no tenga la formación o los conocimientos adecuados sobre alguna parte del desarrollo del proyecto que le ha tocado elaborar.
  • Categoría del impacto: Marginal
  • Evaluación de las consecuencias del riesgo: Este riesgo no supone una gran catástrofe, ya que puede solucionarse dedicándole más tiempo, por parte de la persona concreta, a formarse sobre el campo o los campos en los que no tiene los conocimientos adecuados, a través de cualquier libro de apoyo. Además, debido a la mala formación es posible que se pueda realizar partes del diseño de forma incorrecta.
  • Actuación en consecuencia: Para intentar evitar que esto pase, supliremos las carencias de uno u otro componente gracias a la planificación de las revisiones entre los demás miembros de la plantilla de cada tarea. Si aún así nos encontramos con alguna falta de conocimiento o con errores, se puede solucionar dicho problema dedicándole un poco de tiempo a formarse sobre dicho tema y planificando de nuevo la reestructuración de la documentación tras ser formados en la tarea específica. Se deberá de decidir cómo completar la formación sobre dichos conocimientos, con la ayuda de libros de apoyo, Internet, etc. Si el proceso de formación es lo suficientemente amplio, se derivará también en cambios en el archivo de planificación, incluyendo la tarea de formación cuando sea necesario.

Problemas con la disponibilidad del personal:

  • Incertidumbre: 80%. La probabilidad de que haya problemas con la disponibilidad del personal es muy grande, ya que, al realizar el proyecto en grupo, es difícil que la disponibilidad de todos los miembros sea la misma.
  • Categoría del impacto: Crítica
  • Evaluación de las consecuencias del riesgo: Este riesgo suele producirse con frecuencia, sobre todo en la elaboración de este sistema, ya que pertenece a un proyecto fin de carrera realizado por dos alumnos con posibles problemas de disponibilidad para poder reunirse. Este caso se puede dar por varios motivos: período de vacaciones, período de exámenes, trabajo, prácticas en empresa, etc.
  • Actuación en consecuencia: No hemos considerado posible intentar prevenir este riesgo, pues deriva de cosas impredecibles (como puede ser un suspenso inesperado en una asignatura, una llamada para trabajar, enfermedades, etc.). Si se nos presenta este riesgo en cualquier momento, habrá que modificar la planificación del proyecto. Las posibles consecuencias serían: asignación de horas diferentes para la elaboración del proyecto, reducción y posterior aumento de la jornada de trabajo, inclusión de los fines de semana como días laborables, cambio en fechas de realización de las tareas que faltan por realizar, etc. En caso de que nos encontremos en período de vacaciones, debemos de retrasar las fechas de realización y entrega de las tareas que nos faltan por realizar. Si nos encontramos en período de exámenes debemos de realizar lo mismo que en el caso anterior. Si se nos presenta un trabajo o prácticas en empresa podemos hacer varias cosas: establecer las horas de trabajo en el proyecto diferentes a las que inicialmente teníamos, reducir la jornada de trabajo o establecer los fines de semana como laborables para combatir contra la falta de tiempo por el trabajo. Una vez modificada la planificación, continuar con el proceso normal.

Volver a planificación

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.