viernes, 29 de marzo de 2013

Corto y simple de entender es mejor


Los casos de uso funcionan mejor como instrumentos de
comunicación mientras más cortos y más simple sean,
sin dejar por fuera nada esencial en el proceso
Cuando hay que comprender el problema y la solución, mientras más corto y más sencillo es es el contenido, mejor es el resultado. Dentro de una conversación sobre la etapa de definición o de conceptualización de una solución de gestión de información, hemos dedicado algunos post para hablar de los requisitos, así como de los "casos de uso". Estos últimos los presentamos como un interesante instrumento de comunicación, útil en numerosas ocasiones. Pero cualquier descripción acerca de ellos, particularmente señalando sus virtudes, está incompleta si no se incluye también la conversación polémica de sus limitaciones y malos usos, un tema sobre el que hay discusiones abiertas, sin bien más entre la gente ligada al software que a la Arquitectura de información.

El valor que aportan los casos de uso es la comunicación gráfica de la vinculación entre las acciones y pasos principales de un proceso y los actores que los ejecutan. Funcionan excelentemente en la medida en que sean lo más cortos y comprensibles que sea posible. Obviamente sin dejar por fuera los elementos esencias del proceso.

El punto importante es entender que mucha información puede ser demasiada información. En efecto, un excesivo desarrollo de los casos de uso puede no aportar claridad sino confusión.

La razón por la cual los casos de uso no deben detallarse demasiado es que, cuando se trata de comprender globalmente un proceso, si hay muchos detalles en la información, lo más probable es que se nos diluya la concentración en aspectos irrelevantes y perdamos de vista las relaciones principales. Si eso sucede, las virtudes expositivas de los casos de uso se pierden.

Lo que esencialmente se debe comunicar en ellos, lo que debemos entender después de haberlos visto, es algo relativamente simple: cuáles son los actores involucrados en el proceso, cuáles son los pasos que se realizan y cuáles son las decisiones principales que bifurcan el proceso hacia un lado o hacia otro.

Una de las cosas que confunde acerca de los casos de uso es que como en alguna literatura hay mucha insistencia en ciertas herramientas y plantillas, en ocasiones la forma diluye la esencia. Por otro lado, si se pierde de vista su propósito principal y se confunde su sentido con un instrumento para documentar al detalle todos los requisitos, o todo sobre cada requisito, se pierde su razón de ser.

Por ejemplo, los casos de uso están pensados para describir transacciones, no requisitos no funcionales (ver Después de la visión viene la lista de requisitos). Deben ayudar a comprender el proceso, no a documentar la interfaz de usuario. Deben ser una ayuda para la comprensión de la esencia, no una documentación comprehensiva. Si se tiene esto en mente y si no nos perdemos en los detalles de forma, seguramente los escribiremos bien.

Como vemos, los errores en los casos de uso tienen que ver cuando se entra demasiados detalles, de fondo o de forma. Los buenos Arquitectos de Información de un modo natural trabajan en una zona cercana los usuarios concentrándose y aportando la compresión de la esencia de los procesos, por ellos suelen escribir casos de uso simples y descriptivos.

viernes, 22 de marzo de 2013

Más sobre los caso de uso en el desarrollo de aplicaciones


Los casos de uso deben pensarse como un interesante
instrumento de comunicación gráfica de los requisitos.
Muchas heramientas pueden usarse para escribirlos
La semana pasada conversamos sobre la gran importancia que tienen los casos de uso para asegurar la eficacia de una solución y su calidad. Vimos que resultan útiles en el establecimiento de un lenguaje común en todas las fases del ciclo de vida de una aplicación de gestión de información. Ayudan a la definición de la solución en la conceptualización y se usan en la verificación y validación de resultados en durante las fases de diseño, desarrollo e implementación. Hoy queremos apuntar elementos adicionales en relación al cómo se usan y al qué debe incluirse en ellos. Este conocimiento ayudará a reforzar lo dicho anteriormente acerca de su importancia.

Los caso de uso describen las transacciones que deben realizarse indicando lo que cada actor debe realizar en el marco de un determinado proceso.

Un actor es una persona o sistema involucrado que cumple un cierto rol en un proceso. Es una entidad que ejecuta uno de los pasos de un proceso.

Lo que se describe en un caso de uso es una secuencia de interacciones que se suceden a partir de un determinado evento. Por ejemplo, el inicio de una solicitud en una compañía de seguros. La introducción de un proyecto en una institución. La aceptación de un tesista por su tutor, en una universidad. El inicio de una transacción en un cajero electrónico. La secuencia de interacciones normalmente incluye alternativas que se bifurcan dependiendo de que se cumplan ciertas condiciones.

Puede verse a los casos de uso como descripciones de procesos relevantes a través de la mención de acciones que realizan ciertos actores. Como una descripción de procesos, los casos de uso puedes escribirse a diferentes niveles de detalle y profundidad y desglosarse en casos de uso más específicos, cuando así se requiere. Para dar contexto a lo que ellos especifican, normalmente se acompañan de un glosario.

Como con los casos de uso se trabaja a lo largo del ciclo de vida de las aplicaciones, es necesario prepararse para realizar seguimiento sobre sus especificaciones y documentar sus cambios. Para realizar el seguimiento de un caso de uso normalmente debe dársele una identificación, un título y llevar el registro de sus actualizaciones. Deben estar claros los actores, su descripción, sus precondiciones y post condiciones, es decir, lo que debe ocurrir en forma previa y en forma posterior a ellos.

El caso de uso como tal documenta el flujo de acciones que realizan los actores, bien sean personas o sistemas. Como son un instrumento de comunicación suele ser conveniente especificar los procesos en forma gráfica usando íconos que ayuden a entender las secuencias de pasos en los procesos.

Con los casos de uso y el glosario que normalmente los acompaña, los Arquitectos de Información que realizarán el desarrollo del prototipo o de la solución están en capacidad de crear el modelo de información preliminar o definitivo que se usará.

En los casos en que después de la Arquitectura de Información se realiza un desarrollo de software, los ingenieros que harán el desarrollo pueden eventualmente trabajar en la elaboración de versiones más refinadas, detalladas y técnicas de los casos de uso. Un camino alternativo a la escritura de casos de uso con más detalles, es el uso de prototipos funcionales, una técnica con la que trabajan exitosamente muchos Arquitectos de información.

viernes, 15 de marzo de 2013

Conceptualización de la solución y casos de uso

Los casos de uso definen actores que realizan transacciones y
son un instrumento de gran valor durante todo el
ciclo de vida de una aplicación

Continuando las conversaciones sobre las buenas prácticas metodológicas en el desarrollo de soluciones con una Arquitectura de Información bien definida, particularmente con la primera fase de ciclo de vida, que hemos llamado la fase de definición de la solución, convesaremos hoy sobre la formulación de casos de uso. El tema es obligado porque ésta es una buena práctica en la conceptualización de lo que será el desarrollo de una solución de gestión de información. Examinamos, así pues, lo que los casos de uso son y lo que aportan en el ciclo de vida de una solución.

Un caso de uso es un evento para el cual el comportamiento de la solución que se desarrolla debe estar contemplado como un proceso completamente definido.

Un caso de uso define la acción de actores en la realización de transacciones.

Los casos de uso se identifican en el análisis que se realiza en la fase de definición de la solución, al comienzo del ciclo de vida de la aplicación que se desarrolla, pero se usan también de manera significativa durante las etapas de diseño, desarrollo e implementación de la solución y de allí su importancia.

Los casos de uso son un instrumento clave de comunicación entre los usuarios y los desarrolladores de la solución durante todas las fases mencionadas y por ello es importante cuidar el lenguaje que se usa en su formulación.

Una lista de casos de uso cuidadosamente elaborada es una manera de asegurar la eficacia de un sistema, ya que los desarrolladores deben usarlos como una lista de verificación de lo que hacen. En la fase de conceptualización se usan para identificar en términos concretos lo que usuarios y desarrolladores esperan que se obtenga y en la fase de diseño como una guía para garantizar que todos los casos críticos estén contemplados en la solución.

De los casos de uso se derivan los casos de prueba, que se usan en la definición de pruebas manuales y automáticas. De allí la importancia que toman para facilitar la verificación de los procesos por parte de los desarrolladores.

Otro momento importante de su aplicación ocurre en la fase de implementación, donde los casos de uso son la guía base para la validación. Validar una solución es, en gran medida, asegurar que todos los casos de uso están debidamente implementados.

Mas tarde, en el ciclo de vida, cuando luego de implementada una solución alguna variable técnica cambia (por ejemplo, un componente del hardware, del software o de la configuración del sistema) se debe realizar la evolución de la aplicación hasta garantizar su pleno funcionamiento. Esto es lo que técnicamente se llama un proceso de migración. En esas circunstancias, de nuevo, los caso de uso se convierten en una guía para la validación.

Por la gran importancia que tienen en los acuerdos de usuarios y desarrolladores durante la conceptualización de la solución, en el diseño, la verificación y el aseguramiento de la eficacia durante el desarrollo, y en la validación de los resultados durante la implementación, e incluso posteriormente, en los procesos de migración, los casos de uso son un instrumento de gran valor en el aseguramiento de la calidad de una solución de gestión de información durante todo el ciclo de vida. De allí que dedicaremos otro post para conversar más acerca de ellos.

viernes, 8 de marzo de 2013

Después de la visión viene la lista de requisitos



Después que los involucrados están identificados en la visión,
lo siguiente es el trabajo técnico de elaborar la lista de requisitos
En relación a lo que ocurre en el comienzo del ciclo de vida de una aplicación, hemos estado hablando de la primera fase: la identificación del problema y de la solución. Hemos comentado que en esta fase inicial definimos el cambio que queremos realizar y nos esforzamos en lograr una identidad de todos los involucrados en una visión común de lo esperado. La visión describe lo que percibimos como situación actual, la situación alternativa que queremos, la importancia de lograr el cambio y los beneficios que se esperan obtener con ello. Ahora bien, ¿después de ella que viene? La respuesta es que bajamos un poco más hacia los detalles, ya que lo próximo es la definición de los requisitos.

Elaborar una lista de requisitos es un trabajo técnico. Es la definición de las características, capacidades, condiciones o atributos funcionales que se espera que un sistema tenga. La lista de requisitos con los que debe cumplir una solución es una de descripción de cualidades y metas. Normalmente los requisitos no están vinculados con el cómo alcanzarlos, sino más bien establecen con precisión el qué es lo que se debe lograr.

Los requisitos pueden ser de dos tipos: funcionales o no funcionales.

Los requisitos funcionales son capacidades que debe tener un sistema  para cumplir sus objetivos y realizar eficazmente las tareas para los cuales fue diseñado. Este tipo de requisitos define lo que la solución debe hacer. Por ejemplo, tener la capacidad de generar una cierta salida, a partir del procesamiento de la información almacenada en un momento dado.

Los requisitos no funcionales son capacidades que debe tener la solución que son independientes de la función que los sistemas involucrados en ella cumplirán dentro de la institución. Con este tipo de requisitos se establecen metas de rendimiento o condiciones no técnicas o no funcionales. Por ejemplo, tener la primera fase lista para una cierta fecha, ser compatible con una cierta política de desarrollo de soluciones, resolverse con una arquitectura de información bien definida, ser compatible con un cierto sistema o reglamento, etc.

Los requisitos tienen un gran impacto en el plan y la ejecución del desarrollo de la solución, y por tanto en los costos, por lo que es importante que se exija en ellos lo que sea realmente necesario y que sean lo suficientemente precisos y claros para que sean entendidos por todos sus lectores, sin necesidad de aclaratorias.

Son más útiles y funcionan mejor si son concisos y completos como para definir lo necesario sin ambigüedad y si están redactados como cualidades verificables.

Los Arquitectos de información analizan los requisitos como parte de la definición o conceptualización de la solución. Este análisis debe contribuir a mejorar la redacción de los mismos y servir para eliminar los requisitos que sean innecesarios porque no aportan a la definición de la solución, así como incluir cualquier otro que si sea necesario para tener una lista consistente de exigencias para la solución.

Como los requisitos eventualmente se cambian, las buenas prácticas profesionales recomiendan que se haga un proceso de gestión de los mismos donde haya trazabilidad entre los cambios en los requisitos y las implicaciones de estos cambios en el plan de desarrollo de la solución, de tal manera que el proceso sea controlado. El cambio sin control de los requisitos puede impactar negativamente en el desarrollo de la solución, dificultando la convergencia de los procesos y el cumplimiento de las metas del desarrollo.

viernes, 1 de marzo de 2013

Un poco más sobre la visión: preguntas y respuestas pertinentes



Al iniciar un proyecto es importante hacerse algunas preguntas,
 así como lograr identidad en las respuestas de las personas involucradas
Cada vez que se vislumbra un cambio posible, bien sea una mejora cuantitativa, para dar eficiencia a los procesos de información actuales o un cambio cualitativo, para hacer las cosas radicalmente diferentes, es importante aclarar y hacer explícita la visión compartida. Sobre ello ya hemos hablado: La mejor manera en que un proyecto puede nacer es con una identidad compartida sobre lo que se va a hacer en la cual coincidan las personas intensamente relacionadas con el proyecto. Sin embargo hoy queremos apuntar algunos detalles más acerca de qué es lo que debe lograrse y expresarse cuando se construye esta visión común de un cambio deseable para un proceso de gestión. Nos referimos a una serie de preguntas cuyas respuestas estamos obligados manejar en el colectivo de los involucrados en el proyecto.

La visión compartida puede pensarse como una descripción de muy alto nivel. Debe ser comprendida tanto por los que toman las decisiones como por lo que implantan el cambio en sus diversas etapas. En esta compresión deben incluirse los qué (los atributos) que caracterizan el adónde se quiere llegar, pero también los por qué y los cómo fundamentales del proyecto.

En concreto, una visión compartida debe dar respuesta a las siguientes preguntas:

¿Cuál es el problema que se pretende resolver con el proyecto? ¿Por qué este proyecto es importante para la institución?

¿Cuáles son los atributos esenciales de la nueva situación a la que se espera llegar? ¿Cuáles son los elementos imprescindibles que definirán el logro a alcanzar?

¿Quiénes participan en el proyecto? ¿Cuáles son sus roles en el mismo y cuáles son las contribuciones que se esperan de cada uno?

¿Quiénes son los usuarios del proceso? ¿Cuáles son las necesidades que se les resolverán?

¿Qué representan estos cambios para la institución? ¿Por qué y por quiénes se valorarán estos cambios?

¿Cuáles son los aspectos/ características claves en el proyecto? ¿Qué se espera del equipo que diseñe e implemente la solución?

¿Cuáles son los requerimientos funcionales más importantes?

¿Cuáles son los requerimientos no funcionales que han sido incluidos por su carácter crítico? ¿Qué restricciones de diseño debe contemplar obligatoriamente la solución?

¿Cuáles son los términos claves del glosario que hay que manejar para entender el problema y la solución?

Las respuestas serán mejores mientras más concretas y cortas sean, siempre que mantengan su carácter descriptivo y su pertinencia: La ambigüedad o generalidad no ayuda mucho cuando se trata de centrar un colectivo en un proceso de cambio definido.