Desarrollo de software. Casos de uso I

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).

• actor
• análisis del sistema de información
• ASI
• CASE
• caso de uso
• catálogo de requisitos
• desarrollo de software
• diagrama de actividad
• diagrama de casos de uso
• estimación por puntos de casos de uso
• Gestión de Proyectos
• herramientas CASE
• proyecto de desarrollo de software
• requisito
• requisito software