archivo

Archivos diarios: marzo 19, 2011

En este artículo, voy a centrarme en exponer una definición de lo que son los casos de uso, los actores y las relaciones que existen entre casos los casos de uso.

Independientemente de lo que comente, lo importante es ser conscientes de que los casos de uso describen comportamientos del sistema ante interacciones con agentes externos y que esa descripción se puede hacer de múltiples formas, de manera que para un sistema de información puede haber una infinidad de soluciones que sean totalmente válidas.

¿Qué es un caso de uso?

– Conjunto de funcionalidad.
– Tienen relación con uno o más requisitos funcionales del sistema.
– Logra un objetivo discreto para el usuario.
– Visión de caja negra con respecto a los actores en cuanto a que reciben una petición y devuelven unos resultados.
– Con significado en sí mismo.
– Externamente visible (con excepción de algunos casos de uso que sean utilizados por otros), de manera que especifica la forma de funcionar del sistema tal y como se vería desde el exterior (capta una funcionalidad visible para el usuario).
– Aporta valor al actor que lo utiliza.
– Se expresaría como una secuencia de mensajes intercambiados por el sistema y uno o más actores.

¿Qué es un actor?

– Entidad externa al sistema que interactúa con él.
– Puede ser humano u otro sistema (externo).

¿Cuáles son las relaciones entre casos de uso?

Include: se representa como una flecha discontínua entre un caso de uso y otro. El sentido de la flecha va del caso de uso principal al secundario, estereotipada con la palabra include. Viene a representar que el caso de uso principal incluye al secundario, es decir, que hace uso del mismo para poder llevar a cabo su funcionalidad. Este tipo de casos de uso tienen razón de ser en aquellos casos donde un funcionalidad o comportamiento pueda ser utilizado por diferentes casos de uso o bien, porque la complejidad de un caso de uso, aconseje que se fraccione su comportamiento en diversos casos de uso.

Extend: se representa como una flecha discontínua entre un caso de uso y otro. El sentido de la flecha va del caso de uso secundario al principal, estereotipada con la palabra extend. En este caso, el caso de uso secundario proporciona una funcionalidad adicional al caso de uso principal, pero que solo se produce en algún caso, es decir, existirán circunstancias en las cuales el caso de uso principal se ejecutará completamente sin que para ello tenga que hacer uso del caso de uso que lo extiende, en esto se diferencia del include donde necesariamente se tiene que llevar a cabo el caso de uso secundario para que se pueda realizar el objetivo que persigue el caso de uso principal (en su camino básico). Por este motivo, si un caso de uso es extendido por otro, debe tener un camino alternativo que haga referencia a ese comportamiento que proporciona el otro caso de uso, pero que no se ejecuta en todos los casos.

Herencia: este tipo de relación se utiliza con mucho menos frecuencia que las anteriores, de hecho es muy utilizada entre los actores, pero por ejemplo en los diagramas de casos de uso que suelen entregar en proyectos de mi organización casi nunca los he visto aplicados a los casos de uso. Cuando un caso de uso hereda de otro, conserva su comportamiento. Se representa como una línea continua que va del caso de uso específico al más abstracto teniendo en el extremo el triángulo que representa la generalización en UML. En este tipo de relaciones el caso de uso específico hereda todas las características del más general, permitiendo dotarle de un significado y funcionalidad concreto.

Con respecto a los casos de uso, soy un converso, hasta hace poco tiempo pensaba que eran un trámite más en el proceso de desarrollo de software y que no aportaban nada. Ahora pienso todo lo contrario y, como la mayoría de los conversos, defiendo al máximo la realización de este entregable del proceso de análisis del sistema de información, ya que efectivamente, contribuye al ajuste del catálogo de requisitos y sirve de complemento idóneo al mismo en el sentido de que describe el comportamiento del sistema de información desde el punto de vista de la interacción entre el mismo y los diferentes actores, ya sean personas u otros sistemas.

Los requisitos y la descripción de casos de uso, van de la mano, si bien es importante tener una primera versión del catálogo de requisitos bastante sólida antes de comenzar a realizar los diagramas de casos de uso y lo más importante, la descripción de los mismos y de sus diferentes escenarios.

Cuando se estén definiendo los casos de uso saldrán dudas que permitirán aclarar o mejorar determinados requisitos y probablemente salgan a la luz nuevas funcionalidades o necesidades no tenidas en cuenta. Por ese motivo es esperable y deseable la modificación del catálogo de requisitos tanto en el proceso de definición de los casos de uso como en la obtención de su versión definitiva.

Es importante que una vez completados los casos de uso se verifique que cuadran con los requisitos, de manera que no haya casos de uso que hagan referencia a requisitos y requisitos que no se vean reflejados en casos de uso. Para ello es necesario realizar una matriz casos de uso/requisitos que ayude a la realización de esta actividad.

Una buena descripción de los casos de uso, guía el proceso de desarrollo, en cuanto a que describe el comportamiento del sistema, descompuesto en subsistemas de análisis (es un proceso previo a la realización de los casos de uso y que permite dar a la aplicación una división por grandes niveles funcionales o procesos de negocio) y a su vez descompuesto por funcionalidades específicas que se describen como una secuencia de pasos en los que interviene el sistema y los actores o agentes externos al mismo pero que interactúan con él. Es decir, a partir de los casos de uso, con mayor o menor detalle se especificará cómo se realizarán determinadas funcionalidades sin entrar en aspectos concretos de implementación.

En muchos casos una buena definición de casos de uso, acompañada por un diseño de interfaz de usuario y navegación aprobado por los usuarios y del modelo de datos, puede resultar suficiente para la construcción con ciertas garantías de un sistema de información.

Otra de las ventajas de los casos de uso es que a partir de ellos se pueden obtener otros productos de interés para el proyecto sin esfuerzo adicional (haciendo uso de herramientas CASE), como por ejemplo diagramas de actividad (que son otra forma de representar los caminos de un caso de uso, en la cual se pasa de la descripción textual a una representación de carácter gráfico) o la obtención de una buena parte del conjunto de casos de prueba del sistema.

También pueden ser utilizados como una técnica para la estimación del coste del proyecto, aplicando la estrategia de estimación por puntos de casos de uso (conceptualmente parecida a la técnica de puntos función, pero más simple).

Uno de los aspectos que provoca una mayor desconfianza o pérdida de credibilidad hacia una persona o una organización se produce cuando no existe concordancia entre lo que dice que se va a hacer y lo que realmente lleva a cabo y crece exponencialmente con la distancia que exista entre discurso y acción.

Si realmente quieres hacer algo distinto a lo que dices, cambia tu discurso y adáptalo a las nuevas circunstancias, podrá gustar más o menos, pero por lo menos se juega de manera transparente y nadie se siente traicionado, engañado o que le están tomando el pelo.

Lo mismo eres una persona que no gustas, ya que tienes que tomar decisiones que no son agradables o lo mismo no caes simpático, pero te respetarán si eres consecuente con tus actos.

¿La bolsa o la satisfacción del cliente? Si se llega a plantear esta pregunta es porque probablemente se ha llegado a algunas (o incluso varias simultáneamente) de las siguientes situaciones:

– El proyecto estaba infravalorado.

– El alcance inicial del proyecto ha variado ostensiblemente (incluso en etapas muy tempranas del mismo).

– El cliente ha cambiado las especificaciones o requisitos en etapas muy avanzadas del desarrollo o en diversas ocasiones durante el proceso de desarrollo, sin que exista algún tipo de contraprestación económica o sin que se haya producido algún acuerdo en cuanto al cambio de unas funcionalidades o requisitos por otros.

– El cliente no ha proporcionado el apoyo que requería el proyecto (falta de implicación), lo que ha provocado que la captación de requisitos y la calidad de los mismos se haya visto muy perjudicada.

– Falta de una supervisión adecuada por parte del cliente.

– Falta de comunicación entre cliente y proveedor.

– Falta de entendimiento entre cliente y proveedor.

– Fractura en las relaciones entre cliente y proveedor.

– El proveedor ha gestionado mal el proyecto.

– El proveedor ha seleccionado incorrectamente los recursos humanos del proyecto y/o ha gestionado incorrectamente su participación y función en el mismo y no ha tomado medidas correctoras o las ha tomado demasiado tarde.

– Falta de una supervisión adecuada por parte del proveedor.

– Procesos inexistentes o inadecuados que rijan el funcionamiento del equipo de desarrollo.

– La productividad del equipo de desarrollo no ha sido buena, por circunstancias achacables al propio equipo y/o a la infraestructura de producción y soporte con la que cuenta.

– Se han cometido errores importantes en el análisis y/o en el proceso de construcción.

– El proveedor ha priorizado otros proyectos.

– El proveedor ha intentado obtener del proyecto más beneficios de los que realmente se podían obtener del mismo sin comprometerlo o sin arriesgar su resultado final.

Podría seguir citando circunstancias que provocan que se llegue a la situación límite de tomar la decisión (aunque sea indirectamente o “sin querer”) de apostar por no perder los beneficios del proyecto o porque las pérdidas no sean muy acusadas o bien apostar porque el cliente quede satisfecho.

En demasiadas ocasiones se toman decisiones salomónicas, es decir, vamos a intentar que el cliente no quede muy descontento pero sobre todo vamos a evitar que las pérdidas sean muy abultadas. Este tipo de decisiones salomónicas aplicadas como norma no suelen producir buenos resultados, ya que por un lado un cliente descontento es un cliente descontento, que lo esté más o menos es cuestión de matices y en ocasiones lo mismo da sacar un 2’5 que un 4’5 y por otro hacer un esfuerzo para que las pérdidas no sean más acusadas no evita ni que existan pérdidas o que estas no se sigan incrementando. De esta forma al final tendrás un cliente insatisfecho y además te habrá costado dinero.

No hay recetas que funcionen siempre. Lo primero que hay que valorar (e intentar hacerlo objetivamente) por parte del proveedor cuáles son las circunstancias que han llevado a una situación en la que sabe que existe riesgo de pérdidas en el proyecto (o que las expectativas de beneficio se vean comprometidas) y que además la satisfacción del cliente respecto al resultado final e incluso al propio desarrollo de los trabajos sea más que dudosa (o incluso se palpable). Sin análisis objetivo no hay nada, se tomará una decisión arbitraria que lo mismo funciona, pero que si lo hace será por casualidad. Es más existe más posibilidades de que las circunstancias empeoren tanto en lo que a satisfacción del cliente respecta como a los resultados económicos del proyecto.

Hay pocas culpas absolutas, pero también hay pocas culpas al 50%. Es importante que objetivamente se valore en qué lado cae la balanza y cuánto. Si el cliente ha fallado, en la mayor parte de las circunstancias será consciente de ello y si es razonable tenderá a ser más comprensivo con las decisiones tomadas por el proveedor, ahora bien, si el proveedor ha sido el que ha fallado, debe afrontar las consecuencias.

Otro aspecto que hay que valorar es el significado que tiene el cliente para el proveedor, ¿es un cliente interesante?, ¿me interesa seguir trabajando con él?, ¿existe la posibilidad de seguir contando con él en un futuro?, ¿cuál es su grado de influencia?.

Con todo eso hay que tomar una decisión, ajustada a las circunstancias. Se puede fallar, pero si hay errores después de analizar adecuadamente la situación por lo menos se ha fallado siendo consecuente con una estrategia, seguro que de todo esto se aprenderá en un futuro.