Relación con el empleo de la primera herramienta o método

– Cambiar de herramientas a mitad del proyecto

– Falta de control automático en algunos procesos.

Riesgos definidos:

– RAE: Contingencia o proximidad de un daño. Cada una de las contingencias que pueden ser objeto de un contrato de seguro.

– Guía ISO/CEI73: Combinación de la probabilidad de un suceso y sus consecuencias.

– The Institute for Risk Management –IRM: Utiliza la definición de la guía ISO/CEI73.

Alcances:

– Riesgo se usa en el caso de que exista al menos una posibilidad de consecuencia negativa.

– A veces el riesgo surge de la posibilidad de desviación con respecto al resultado o suceso previsto.

– Un riesgo es cualquier evento que puede ocurrir durante un proyecto y que reduce la posibilidad de éxito. Es una probabilidad potencial. Corresponde a una posibilidad, no es una certeza.

– Una probabilidad/evento/incidente no es más que un riesgo que se concreta. Algunos piensan que hablar de riesgos es signo de negatividad, sin embargo, compartir el conocimiento relacionado con posibles problemas que pueden afectar a un proyecto es una muestra de compromiso y profesionalismo.

Ejemplos:

– Profesional inadecuado.

– Crecimiento y/o cambio excesivo de los requerimientos.

– Tamaño del proyecto.

– Elaboración excesiva de los requerimientos.

– Calendarios, costos o presupuestos irreales.

– Falta de calidad en el producto.

– Diseño inadecuado.

– Proceso y ambiente de desarrollo, nuevas tecnologías.

– Balas de plata o soluciones mágicas.

Algunos impactos:

– Costos/tiempos excedidos.

– Funcionalidad inadecuada del producto/servicio.

– Proyecto cancelado.

– Cambios fuertes dentro del equipo de trabajo/personal del proyecto.

– Insatisfacción del cliente.

– Daño de la imagen corporativa.

– Productos con pobre rendimiento.

– Problemas legales.

Gestión de riesgos:

– Identificación y análisis de riesgos.

– Planificación de riesgos:

• Plan de mitigación de riesgos.
• Plan de contingencia.

– Seguimiento y control de riesgos.

Identificación y análisis de riesgos:

– Cada proyecto es diferente del resto, pese a esto, de todas formas existen riesgos comunes a ellos.

– La experiencia es fundamental en este aspecto.

– Una técnica de identificación de riesgos es observar las restricciones del proyecto (restricciones presupuestarias, de personal, de tecnología, etc).

– Una forma de expresarlo es utilizar el esquema: condición-consecuencia.

– A cada riesgo asignar una probabilidad de ocurrencia. Esta probabilidad puede ser una simple opinión, sin que se pueda determinar con exactitud. Se puede expresar numéricamente, en porcentajes, o también como alta, media, baja.

– Seleccionar una escala sencilla de asignación de probabilidad (1 a 3 y no 1 a 30). Importante: mantener la misma escala a lo largo del proyecto.

– A cada riesgo asignar un nivel de severidad o impacto. El objetivo es asignar un valor que represente la pérdida, en monto, tiempo o funcionalidad, tras la ocurrencia del riesgo. Expresarla en forma numérica. Seleccionar una escala sencilla de asignación de probabilidad (de 1 a 3) y mantener la misma para todo el proyecto.

Planificación de riesgos:

– Plan de mitigación: Consiste en planificar y tomar las acciones necesarias de antemano para llevar la exposición al riesgo a un nivel aceptable. Estrategias de mitigación: minimizar la probabilidad de ocurrencia y/o el impacto; transferir la responsabilidad a un tercero; evitar el riesgo tomando medidas que cambien la forma de ejecutar cierta parte del proyecto.

– Plan de contingencia: Focalizado en minimizar el impacto del riesgo, en caso de ocurrencia. Planificar cómo reaccionar para minimizar el impacto, focalizándose en las consecuencias. Determinar alarmas que indiquen cuándo entrar en contingencia. Hacer los planes de contingencia con anterioridad.

Seguimiento y control de riesgos:

– Mantener una costumbre de tiempo con riesgos, por ejemplo, revisar periódicamente los riesgos cada cierta cantidad de reuniones.

– Checar el progreso en la mitigación de riesgos.

– Actualizar el estado del riesgo al observarse cambios.

Resumen

– La gestión de riesgos debe ser proactiva.

– Debe evaluarse los riesgos en forma continua durante la vida del proyecto.

– Se debe establecer un mecanismo formal de administración y control de riesgos.

– Se debe involucrar a todos los interesados (stakeholders) en el proyecto en esta identificación y seguimiento de riesgos.

UML: Caso de uso

Reflexión: Lo más difícil de construir un sistema es precisamente saber cómo construirlo. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto al sistema si es hecha mal. Ninguna parte es tan difícil de corregir más adelante. Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto (Frederik P).

Conceptos:

– Ningún sistema se encuentra aislado. Cualquier sistema interactúa con actores humanos o mecánicos que lo utilizan con algún objetivo.

– Los casos de uso describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista del usuario.

– Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.

– Los casos de uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo.

– Están basados en el lenguaje natural, es decir, son entendidos por los usuarios.

– Los casos de uso son independientes del método de diseño que se utilice.

– Un caso de uso es una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor.

– Un caso de uso involucra la interacción de actores y el sistema u otros sujetos.

– A nivel de sistemas, un caso de uso describe un conjunto de secuencias, donde cada secuencia representa la interacción de los elementos externos al sistema (sus actores) con el propio sistema.

– En realidad, estos comportamientos son funciones a nivel del sistema que se utilizan durante la captura de requisitos y el análisis, para visualizar, especificar, construir y documentar el comportamiento esperado del sistema.

– Un caso de uso representa un requisito funcional del sistema global.

Actores:

– Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso desempeñan.

– Normalmente, un actor representa un rol que es desempeñado por una persona, un dispositivo hardware, o incluso, otro sistema al interactuar con el nuestro.

– Ejemplo: Si una persona trabaja para un banco, su rol es responsable de préstamos y si tiene cuenta en el banco, su rol es cliente.

– Una instancia de un actor representa una interacción individual con el sistema de una forma específica.

– Aunque se utilizan actores en los modelos, estos no forman parte del sistema (están fuera de la aplicación, en el entorno que lo rodea).

– En un sistema en ejecución, una persona puede tener 2 roles.

– Los actores se representan como «siluetas humanas» o también llamados «monigotes».

– Se pueden definir categorías generales de actores (cliente) y especializarlos (cliente comercial) a través de relaciones de generalización.

Casos de uso:

– Un caso de uso describe qué hace un sistema (o subsistema), pero no especifica cómo lo hace.

– Cuando se modela, es importante tener clara la separación de intereses entre las vistas externa e interna.

– Cada caso de uso debe tener un nombre que lo distinga del resto.

– Un nombre es una cadena de texto, denominado nombre.

– Un nombre de un caso de uso puede constar de texto con cualquier número de letras, números y la mayoría de los signos de puntuación (exceptuando los dos puntos, utilizados para separar el nombre de un caso de uso del paquete que lo contiene).

– En la práctica, los nombres de los casos de uso son expresiones verbales que describen algún comportamiento del vocabulario del sistema que se está modelando.

Actores y casos de uso:

– Los actores solo se pueden conectar a los casos de uso a través de asociaciones.

– Una asociación entre un actor y un caso de uso indica que el actor y el caso de uso se comunican entre sí, y cada uno puede enviar y recibir mensajes.

Casos de uso y flujo de eventos:

– El comportamiento de un caso se puede especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro para que alguien ajeno al sistema lo entienda fácilmente.

– Cuando se escribe este flujo de eventos, se debe incluir cómo empieza, cuándo empieza y en qué instante el caso de uso, cuándo interactúa con los actores y qué objetivos (variables) se intercambian.

– Se definen 2 tipos de flujos: flujo básico y alternativos del comportamiento.

– Ejemplo: En el contexto de cajero automático, se podría describir de manera narrativa el caso de uso «validar usuario» de la siguiente forma:

– Flujo de eventos principal: El caso de uso comienza cuando el sistema pide al cliente un número de identificación personal. El cliente puede introducir un PIN por el teclado. El cliente acepta la entrada pulsando enter. El sistema comprueba que el PIN es válido, si es válido el sistema acepta la entrada y se acaba el caso de uso.

– Flujo de eventos excepcional: El cliente puede cancelar una transacción en cualquier momento, pulsando cancelar y de esta forma reinicia el caso de uso. No se efectúa ningún cambio a la cuenta del cliente.

– Flujo de eventos excepcional: El cliente puede borrar un PIN en cualquier momento antes de introducirlo, y volver a teclear un nuevo PIN.

– Flujo de eventos excepcional: Si el cliente introduce un PIN inválido, el caso de uso vuelve a empezar. Si esto ocurre 3 veces en una sesión el sistema cancela la transacción completa, lo que impide que el cliente pueda realizar algún tipo de operación.

Especificación formal de casos de uso:

– El flujo de eventos de un caso se puede especificar de muchas formas incluyendo: texto informal (como el presentado en el ejemplo anterior), texto estructurado formal (con pre y postcondiciones), máquinas de estados, entre otros.

– Si bien la representación gráfica de casos de uso es necesaria, una descripción textual es el único camino de determinar en términos concretos diversos elementos involucrados en ellos (indicar detalles).

– Para ello, se utiliza una especificación formal de caso de uso, la que posee un formato definido.

Organización de los casos de uso:

– Los casos de uso pueden organizarse agrupándolos en paquetes.

– Los casos de uso también pueden organizarse expresando relaciones de inclusión y extensión entre ellos.

– Estas relaciones se utilizan para factorizar el comportamiento común (extrayendo ese comportamiento de los casos de uso en los que se incluye) y además, se utilizan para factorizar variantes (poniendo ese comportamiento en otros casos de uso que lo extienden).

Inclusión:

– Una relación de inclusión entre casos de uso significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base.

– El caso de uso incluido nunca se encuentra aislado, sino que es instanciado solo como parte de algún caso de uso base más amplio que lo incluye.

– La inclusión puede verse como una situación en donde el caso de uso base «toma el comportamiento» del caso de uso «proveedor».

– La relación de inclusión se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento común en un caso de uso aparte. Entre caso de uso será incluido por un caso de uso base.

– La relación de inclusión es básicamente un ejemplo de delegación: se toma un conjunto de responsabilidades del sistema y se capturan en un sitio (el caso de uso a incluir en otros casos de uso), luego se permite que otras partes del sistema (otros casos de uso) incluyan la nueva agregación de responsabilidades, siempre que se necesite utilizar esta funcionalidad.

– La relación de inclusión se representa como una dependencia, estereotipada con «include».

Extensión:

– Una relación de extensión entre casos de uso significa que un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso.

– El caso de uso base puede estar aislado, pero en algunas condiciones, su comportamiento puede extenderse con el comportamiento de otro caso de uso.

– Este caso de uso puede extenderse solo en ciertos puntos, llamados puntos de extensión.

– La extensión puede verse como una situación en donde el caso de uso que extiende incorpora su comportamiento en el caso de uso base.

– Una relación de extensión se utiliza para modelar parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema.

– También se puede utilizar una relación de extensión para modelar un subflujo separado que se ejecuta solo bajo ciertas condiciones.

– Una relación de extensión se representa como una dependencia, estereotipada como «extend».

Conceptos:

– Los diagramas de casos de uso son uno de los tipos de diagramas en UML, que se realizan para modelar aspectos dinámicos de un sistema.

– Los diagramas de casos de uso se emplean para modelar la vista de casos de uso de un sistema.

– La mayoría de las veces, esto implica modelar el contexto del sistema o subsistema o el modelado de los requisitos de comportamiento de ellos.

– Son importantes para visualizar, especificar y documentar el comportamiento.

– Presentan una vista de cómo pueden utilizarse los sistemas y subsistemas en un contexto dado.

– Los diagramas de casos de uso son un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones.

Sugerencias y consejos:

– Cuando se modelan los casos de uso en UML, cada caso de uso debe representar un comportamiento distinto e identificable del sistema o de una parte de este.

– Un caso de uso bien estructurado:

• Asigna un nombre a un comportamiento simple, identificable y razonablemente atómico del sistema o parte del sistema.
• Factoriza el comportamiento común, incorporando ese comportamiento desde otros casos de uso que incluye.
• Factoriza las variantes, colocando ese comportamiento en otros casos de uso que lo extienden.
• Describe el flujo de eventos de forma suficientemente clara para que alguien externo al sistema lo entienda fácilmente.
• Se describe por un conjunto mínimo de escenarios que especifiquen la semántica normal y las variantes del caso de uso.

– Cuando se dibuje un caso de uso:

• Hay que mostrar solo aquellos casos de uso que sean importantes para comprender el comportamiento del sistema o parte del sistema en su contexto.
• Hay que mostrar solo aquellos actores relacionados con ese caso de uso.
• Número mágico: 7 + 2 casos de uso.

– No solo describir las acciones del usuario, sino que es necesario también considerar las respuestas del sistema.

– No entrar en demasiados detalles. Los casos de uso deben describir la relación entre el usuario y el sistema.

– No separarse de la interfaz de usuario.

– No omitir texto en los cursos de acción alternativos y extensiones.

– Las pre y postcondiciones son importantes, pero merecen hasta cierto punto de atención.

Etiquetas: gestión de riesgos, proyectos de software, riesgos en proyectos