Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Caso de Uso. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Caso de Uso. Mostrar todas las entradas

lunes, junio 02, 2014

Libro: Asuntos de la Ingeniería del Software- volumen II

Portada del libro
Portada del libro
Este no es el primer libro sobre temas de la Ingeniería de Software y está lejos de ser el último; acaso sea el primero en español escrito sobre las bases de nuestra propia práctica de campo, en nuestra propia economía, con nuestra propia idiosincrasia, aunque con el suficiente equipaje teórico proveniente de la academia y de los expertos en los temas citados.
Escribí el libro originalmente como una serie de artículos en mi Gazafatonario IT y cada artículo siempre tuvo su fuente precisamente en tres aspectos primordiales: la industria del software (y por Industria quiero decir Intergrupo), la academia (léase la Universidad) y los especialistas en distintas áreas de la ingeniería de software.
El libro cubre algunos de los temas fundamentales que sirven de base al trabajo diario de los profesionales del software y que son de vital importancia para los desarrolladores actuales: el lenguaje de modelado unificado o UML, los procesos de software, la orientación a objetos y la ingeniería de requisitos con casos de uso, principalmente.
Los conceptos de ingeniería provienen necesariamente de la teoría formal de los lenguajes de modelado de sistemas, las técnicas orientadas a objetos de modelado de software, los métodos de construcción de software y la identificación, especificación y administración de requisitos de software con casos de uso, entre algunos otros. Desarrollé esos conceptos a través de cada capítulo en un estilo riguroso pero informal, más bien práctico, siempre pensando en poner de manifiesto lo que me ha funcionado a mí y a mis colegas, principalmente de Intergrupo, pero también de otras compañías del medio.
Parte 1 – Algunos Aspectos Esenciales de la Ingeniería de Software
El libro está dividido en dos secciones mayores. La primera parte del libro la dedico a explicar algunos de los asuntos que acusan recibo en la comunidad de ingenieros de software: UML, la notación estándar para modelar sistemas de software y otros sistemas que no son software; En lo que se constituye como los prolegómenos del libro, de manera sucinta describo la gran mayoría de los diagramas del lenguaje, con ejemplos breves pero suficientemente explicativos y desmitifico algunas de las creencias sobre la herramienta.
En el capítulo 2, hago una presentación general de los procesos de software y de cómo estos son usados por los practicantes de la industria, es decir, nosotros. Aquí empiezo a develar las prácticas más recurrentes para adoptar y adaptar procesos de software en una organización, tal y como lo hicimos en Intergrupo en una serie de incrementos que llevaron a convertirnos en una compañía CMMI nivel 5.
En los capítulos 3, 4 y 5 del libro, hago una vasta exposición del Proceso Unificado de Software, desde su marco general en el capítulo 3, hasta los detalles de la fase de Inicio o Concepción en los capítulos 4 y 5. En el primero de los apartados presento los conceptos inherentes al proceso y sus características: las fases y las disciplinas, las iteraciones, los roles y responsabilidades, las actividades y los artefactos. En los dos capítulos restantes, ya con miras a la segunda parte del libro, hablo profusamente de la etapa de inicio del proceso, sus principales hitos y el resultado esperado. Es aquí donde comienzo a hablar de la disciplina de ingeniería de requisitos y de casos de uso, asuntos que ocupan toda la segunda sección del libro.
Luego, en el capítulo 6, concluyo este primer segmento del libro con un tema que verdaderamente me apasiona, la orientación a objetos. Tardé muchos años en encontrar el enfoque justo para esta pieza, teórico-práctico, pero actualizado a las necesidades incesantes de los desarrolladores profesionales de este siglo 21. El capítulo contiene una serie extensa de conceptos aplicables al análisis, diseño y desarrollo de sistemas de software, incluso me atrevo a hacer una analogía en lo que he dado en llamar la Biología Informática, para que todos entendamos mejor y de una vez por todas y para siempre lo que es una clase (objetualmente hablando) y su enorme utilidad durante el ciclo de vida de construcción de software. Sobre objetos, siempre recuerdo lo que decía Edward Yourdon sobre ello: “las metodologías de la ingeniería de software orientada a objetos son la cosa más grande desde el pan tajado. En términos relacionados con computación, las técnicas orientadas a objetos son el desarrollo más importante desde la invención de las técnicas estructuradas durante las décadas de 1970 y 1980.”[1] Hoy lo siguen siendo.
Parte 2 – Ingeniería de Requisitos con Casos de Uso: Volumen 1
La segunda parte está dedicada completamente al asunto de los casos de uso como mecanismo de primera categoría para identificar, capturar, organizar, documentar y gestionar requisitos de sistemas de software. En el capítulo 7 hago una presentación concisa del tema, defino qué es un caso de uso y además establezco las diferencias sutiles que existen con los escenarios de uso de un sistema; también explico de qué se tratan los así llamados casos de uso esenciales como noción capital en la especificación de requisitos y también los distingo de los casos de uso descompuestos funcionalmente. El capítulo finaliza con el ejemplo de caso de uso más simple de todo, el caso de uso “¡Hola, Mundo!”.
En el capítulo 8 abordo el tema de los casos de uso del negocio y sus actores del negocio relacionados. También hablo de la fuente de los casos de uso, de donde provienen y hacia donde van a lo largo del ciclo de vida del software, para terminar con un ejemplo del cual luego hago un análisis exhaustivo.
En el capítulo 9 hago una descomposición de la estructura de un caso de uso y exhibo cada una de sus partes principales: la descripción breve, las precondiciones y poscondiciones del caso de uso, la secuencia básica y las alternativas y los requisitos especiales. Ya en los capítulos previos había tratado el tema del nombre y el actor del caso de uso.
Más adelante, en el capítulo 10, bajo el manto de un ejemplo representativo, enuncio mi Ley de la Terminación de un Caso de Uso, que me sirve para explicar uno por uno los puntos de una lista de verificación para saber si un caso de uso cuenta con los atributos mínimos requeridos para ser considerado un buen caso de uso. Las listas de verificación deben verse como instrumentos o herramientas de apoyo en el proceso de administración de la calidad de los productos que construimos, nunca como un documento que se debe “diligenciar”. También sirven para disminuir el nivel de subjetividad con que se revisa un producto de software o parte de este, o un artefacto relacionado con el software. Al menos, este es el mensaje que llevo implícito en esta sección del libro.
El capítulo 10 sirve como entrada al tema que abordo en el capítulo 11, este del análisis y diseño de los casos de uso, mejor conocido en el ámbito de los diseñadores de software como realización de casos de uso. Aquí evidencio la necesidad de contar con el conocimiento de conceptos tan importantes como las técnicas orientadas a objeto, que trato al final de la primera parte del libro, y donde hago un uso extenso del lenguaje de modelado unificado que trato en detalle en los prolegómenos del libro (capítulo 1). En este capítulo empiezo con una disertación sobre los problemas de comunicación existentes entre los miembros de un equipo de desarrollo de software y que son inherentes a la naturaleza humana. A continuación, con un ejemplo característico y práctico, hago una exposición detallada de los diagramas de interacción de UML, en general, y de los diagramas de secuencia, en particular, que sirven como mecanismos fundamentales para llevar a cabo estas realizaciones de casos de uso.
En el capítulo 12 cierro uno de los ciclos del libro sobre modelado de casos de uso y presento el no menos espinoso asunto de las relaciones entre actores y casos de uso y entre casos de uso. La generalización entre actores, una práctica poco usada entre los analistas de software, o muchas veces mal usadas, inicia este apartado. Luego continúo con la típica relación de inclusión de casos de uso, donde hablo de factorización de requisitos y de reusabilidad de requisitos; más adelante hago una disertación sobre la relación de extensión y sus diferencias principales con la anterior. Al final también hablo de la generalización entre casos de uso, aunque no la recomiendo mucho. Este capítulo aporta el enfoque sistémico de toda la segunda parte del libro y hace énfasis en cuando debemos usar una u otra relación, o todas ellas.
El capítulo 13 entra en el terreno de las buenas prácticas mostrando los errores más comunes que se cometen a la hora de usar casos de uso, algo que he dado en llamar “los casos de abuso”, es un juego de palabras pero ilustra a la perfección el punto al que quiero llegar. Enumero y explico una serie de dieciséis casos frecuentes de mal uso de los casos de uso, desde la mala práctica de usarlos en todo momento y en cualquier contexto, pasando por los errores habituales de documentar detalles técnicos o de la interfaz de usuario en el caso de uso, hasta la costumbre perfeccionista de solo presentar el caso de uso cuando está “felizmente” terminado, solo cuando contiene todos los detalles que se han acordado con el usuario. ¿Quién diría que lo perfecto siempre es mejor que lo bueno? Pues bien, aquí sucede exactamente lo contrario: lo acabado, lo ideal, lo absoluto es enemigo acérrimo de lo bueno, de lo que proporciona valor. Es una de las conclusiones que obtendremos al final del capítulo. Incluso muchos de nosotros hemos llegado a pensar que el analista de requisitos y otros miembros del equipo de desarrollo son síquicos y que pueden leer nuestros pensamientos y saber lo que queremos sin habérselos dicho. De todo esto se trata este estudio al que clasifico de patológico y de forense, fueron situaciones que discutí mucho con algunos de mis colegas en Intergrupo.
El último capítulo del libro fue otro de los que siempre quise escribir en mi Gazafatonario: se trata de diez más uno consejos útiles y simples para escribir efectivamente casos de uso efectivos. La aliteración en el título me sirve para abordar dos asuntos importantes: el problema de la comunicación efectiva entre las personas y el problema de la calidad y utilidad de los artefactos de software, en este caso, de los casos de uso. Me parecía razonable, después de la descripción sintomática que hago en el capítulo anterior, sobre los errores más pronunciados que cometemos a la hora de modelar sistemas de software con casos de uso, traerles algunas propuestas para remediar nuestro trabajo, hacerlo más productivo y de mejor calidad. De eso se tratan estos consejos.
Dónde conseguir el libro
El libro lo pueden conseguir en:



[1] Yourdon, Edward. Object-Oriented System Design, an integrated approach. Prentice Hall. 1994.

miércoles, enero 23, 2013

¿Por qué existe Casos de Uso 2.0?


Necesitamos prácticas que nos apasionen y que se enfoquen en las personas sobre los procesos pero que además nos posibiliten resultados de calidad. Necesitamos además que nuestro trabajo sea aún más colaborativo y permita una integración unificada, continua. Precisamos de un enfoque que permita bajar la tensión “ellos versus nosotros” entre desarrolladores y verificadores.

Requerimos prácticas que nos licencien para manejar mejor los cambios y que nos habiliten para entregar productos de manera incremental. Y también necesitamos prácticas que soporten un mejor manejo del conocimiento de los productos que construimos y que nos apoyen cuando hacemos frente a situaciones adversas, que nos permitan mantenernos enfocados en lo que es de valor para nuestro cliente.

Casos de Uso 2.0 es precisamente eso, una práctica escalable y ágil que usa casos de uso para capturar un conjunto de requisitos y conducir el desarrollo incremental de un sistema que los ejecute. Casos de Uso 2.0 se reenfoca en lo esencial y ofrece una forma de trabajo liviana y más limpia para que los equipos de software logren los beneficios del desarrollo iterativo e incremental a un nivel corporativo.

Pero para llegar más al corazón de Casos de Uso 2.0, necesitamos mirar la radiografía de los casos de uso: ¿Qué hizo tan popular a los casos de uso? Con el tiempo, los casos de uso alcanzaron un uso multitudinario porque comunican efectivamente lo que el sistema debe hacer, porque ponen los requisitos en el contexto de las metas de un usuario específico y porque conducen el desarrollo a través del diseño, el código y, si se quiere, las pruebas.

En el fondo, el modelado de casos de uso es una idea muy simple. Esto quiere decir que con Actores, Casos de Uso, Inclusiones y algunos otros artilugios podemos llegar al núcleo de lo que el sistema debe hacer, porque nos enfoca inequívocamente en quién (o qué) usará el sistema y nos permite encontrar con rapidez asombrosa lo que el sistema debe hacer para que ese quién logre algo útil en su proceso de negocio.

Otra pregunta que debemos responder antes de dar el salto de versión es ¿por qué necesitamos casos de uso todavía? Si hay muchas otras prácticas relacionadas de requisitos populares, ¿por qué estás no han reemplazado la necesidad de casos de uso? Por ejemplo, las historias de usuario son grandiosas para sistemas pequeños y equipos pequeños, aunque bien es cierto que con pequeños incrementos podemos construir un sistema grande.

También hay otros enfoques, como la especificación de características, fabulosa para manejo de productos; los tradicionales requisitos declarativos, excelsos para capturar cualidades independientes atómicas; el modelado de dominio, extraordinario para sistemas de funcionalidad simple y ricos en información. Sí, hay muchas otras buenas técnicas pero a todas les hace falto algo para reunirlas y proporcionar una solución simple y escalable.

Ahora sí, ¿por qué necesitamos casos de uso 2.0? En principio, para corregir algunos de los malentendidos:

  • Los casos de uso son livianos, no pesados
  • Los casos de uso son historias, no funciones
  • Los casos de uso son simples, no complicados
  • Los casos de uso son para todo tipo de desarrollo, no solo para desarrollo de aplicaciones nuevas y “planas”.
  • Para reenfocarnos en lo esencial, de vez en cuando viene bien un refrescamiento de ideas y de experiencias.
  • Para dar un mejor soporte a las innovaciones y mejoras tales como Desarrollo Dirigido por Pruebas (TDD), Kanban y Scrum.

Lo que hace distintivo a Casos de Uso 2.0 es que nos ayudan a entender el cuadro completo, es una práctica tan liviana como queremos que sea, habilita la entrega incremental del producto, no es solo sobre requisitos, es para todo el ciclo de vida, también es para requisitos no funcionales, para software embebido, incluso no es solo para desarrollo de software, también es para desarrollo de negocios y, finalmente, es escalable en todas las direcciones para cubrir cualquier necesidad real.

Como siempre, cuando se trata de procesos y métodos, aconsejo no desvirtuar la capacidad que tenemos los seres humanos de pensar. Lo que posibilitan las técnicas es precisamente potenciar nuestra habilidad para encontrar el mejor siguiente paso en el camino hacia la satisfacción. Al final de cuentas es el cerebro humano el que visiona productos e ideas, ninguna tecnología ni método puede reemplazar nuestro proceso de pensamiento.


Referencias

El e-Book "Use Case 2.0", sobre las buenas prácticas alrededor del uso de los casos de uso, lo pueden encontrar en www.ivarjacobson.com.

Sobre Casos de Uso 2.0 pueden leer mi serie de artículos en este Gazafatonario IT:

Casos de Uso 2.0

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20.html 

Casos de Uso 2.0 y Métodos Ágiles

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

¡Quiero una Porción de Caso de Uso!

http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-aplicable-todos-los.html 

Casos de Uso 2.0: Cosas con las cuales trabajar

http://www.gazafatonarioit.com/2012/11/casos-de-uso-20-cosas-con-las-cuales.html 

Sobre Casos de Uso pueden leer toda mi sección de Lecturas Fundamentales en este mismo Gazafatonario, empezando en:

http://www.gazafatonarioit.com/2006/11/lecturas-fundamentales.html


jueves, diciembre 06, 2012

El extraño caso del caso de uso faltante

O de cómo nunca deberíamos aceptar especificaciones de software incompletas

Los productos de software de alta calidad dependen de la completitud de los requisitos. En general, la calidad de los requisitos de software afecta la calidad de los productos de software. Los Ingenieros de Requisitos o Analistas Funcionales intentamos llenar los vacíos en la especificación del software de manera distinta, dependiendo de nuestra experiencia y del proyecto en el que se encuentren, de factores como el tiempo, la relación con el usuario, la disponibilidad de este o del grado de estabilidad de los requisitos existentes.

Algunos Analistas, por ejemplo, intentamos obtener retroalimentación de los usuarios, mientras que otros acuden a distintos interesados o a fuentes alternas de los requisitos, pero cuando no tenemos ese privilegio, simplemente hacemos suposiciones. Estas últimas pueden ser implícitas o explícitas. Las suposiciones explícitas son preferibles a las implícitas porque podemos validar aquellas posteriormente, mientras que las implícitas llegan a las fases de diseño e implementación con una alta probabilidad de estar erradas.
Ya sabemos que los requisitos de software deben ser: correctos, precisos, completos, consistentes, clasificados, verificables, modificables y trazables. Las especificaciones de requisitos completas y correctas son las requeridas por los desarrolladores para saber qué construir y por los usuarios para saber qué esperar. Una especificación de requisitos de software completa debe incluir toda la información necesaria, incluyendo restricciones y condiciones.
Ahora bien, independientemente de las técnicas de recolección de requisitos, el involucramiento del usuario es un elemento importante, ya que los requisitos vienen principalmente de las personas, no de los documentos o los sistemas existentes. Los usuarios deben ser escuchados cuidadosamente y nunca debemos hacer suposiciones implícitas puesto que estas no se comparten con los interesados aumentando así la incertidumbre en los requisitos. 
De mi propia experiencia, de la de mis colegas, y de estudios en la materia, he llegado a la conclusión de que, nosotros, los Ingenieros de Requisitos, tendemos a ser más rigurosos en la especificación de requisitos cuando:

  • El cliente es de corte militar, es decir, es un cliente rígido, con un proceso formal bien definido o es vigilado por entidades internas o externas a su organización y a las que debe rendir cuentas sobre sus acciones.
  • El análisis de requisitos hace parte de la fase actual del ciclo de vida del software, por ejemplo, cuando estamos en las fases de Inicio (UP) o Visión (MSF) y en la fase de Elaboración (UP) o Planeación (MSF). Por razones obvias, a medida que el proyecto avanza, tenemos menos tiempo para encontrar y documentar requisitos y es cuando más suposiciones se hacen sobre lo que ya está identificado.
  • Utilizamos herramientas de apoyo para la especificación y el modelado de requisitos, sobre todo herramientas que permitan realizar diagramas de casos de uso, diagramas de actividad, tableros de historias, simulaciones y prototipos, entre otros instrumentos de este tipo.
  • Hemos asistido a entrenamiento en los días previos al proyecto o hemos estado involucrados en proyectos problemáticos recientemente. Cuando esto ocurre, muy seguramente hemos estado sometidos a mucha presión y estrés, además de una limpieza de cerebro sin antecedentes y no queremos volver a equivocarnos.
  • Simplemente tenemos la experiencia suficiente y necesaria, hemos aprendido de nuestros aciertos y fallas del pasado y de las lecciones aprendidas en proyectos anteriores. Sin contar con que hemos consultado la gran cantidad de material que encontramos en este Gazafatonario IT sobre el tema.
Si algunas de o todas estas premisas no se cumplen, es muy probable que no sepamos cómo enfrentar los principales problemas en ese proceso espinoso que es la identificación de requisitos. Estos problemas se manifiestan de forma distinta:
  • Los usuarios no pueden o no saben describir muchas de sus tareas
  • Mucha información importante no llega a verbalizarse. Ocurre con frecuencia que de tanto ejecutar el proceso, este “desaparece”, se vuelve algo implícito y nadie es capaz de relatarlo.
  • En sistemas orientados a miles de usuarios, como los sistemas de la Web 2.0, a veces hay que “inventar” los requisitos. En estos casos, las suposiciones están a la orden del día y muchas de ellas nunca llegan a documentarse.
  • En general, la educción (extracción) de requisitos es un proceso pasivo, en el que el usuario espera del Analista Funcional la solicitud de conocer algo para él intentar entonces explicárselo de alguna manera.
Sobre este último síntoma, todo el proceso de identificación, clasificación, documentación y administración de requisitos de software debería ser un proceso cooperativo, que cuente con la participación del equipo técnico y de todos los interesados en el proyecto y en el producto y no solo de algunos pocos usuarios.

Finalmente, algunas técnicas bien conocidas y que son de utilidad al momento de encontrar requisitos y de las que hablaremos en otros artículos, son:
Preliminares:

Utilizar preguntas libres de contexto.

Tormenta de ideas:

Seleccionar un grupo variado de participantes.

Eliminar críticas, juicios y evaluaciones mientras los participantes sugieren ideas.

Producir muchas ideas.

Recogerlas todas por escrito.

Otro día, en otra sesión, se evalúan las ideas (se puntúan).

Elaboración de prototipos:

Útil cuando la incertidumbre es grande acerca del futuro sistema

Entrevistas:

Es el método “tradicional”,  pero debe usarse en complemento con otras técnicas, y no debe ser el primer paso de la educción. Es fundamental:

Entrevistar a la(s) persona(s) adecuadas.

Preparar las preguntas con antelación.

Utilizar diagramas, modelos, etc.

Observación y análisis de tareas:

Esta es una técnica tan antiquísima como la misma Ingeniería de Software. Un observador estudia a los futuros usuarios en su entorno de trabajo. A veces se utiliza el video. Anota todo aquello que es susceptible de mejora. Posteriormente, genera una serie de requisitos tentativos.

Casos de uso

Requisitos en contexto de uso. Sobre este asunto he expuesto docenas de artículos en este Blog.

Finalmente, recordemos que el objetivo de la Ingeniería de Requisitos es asegurar que se defina y desarrolle un producto efectivo de alta calidad desde el punto de vista de los interesados, así que si una especificación de requisitos de software incompleta es inevitable, definitivamente deberíamos aceptarla como completa haciendo suposiciones implícitas.

miércoles, noviembre 28, 2012

Casos de Uso 2.0: Cosas con las cuales trabajar


Dicen el Dr. Jacobson y sus colegas que la materia prima de Casos de Uso 2.0 son los requisitos del software, el producto de software mismo y las pruebas que demuestren que el producto obedece a esos requisitos y los ejecuta a cabalidad.
En el corazón de Casos de Uso 2.0 están el caso de uso, la historia y la porción de caso de uso. Estos elementos capturan los requisitos y conducen el desarrollo del sistema. La Figura muestra como estos conceptos están relacionados entre sí. También muestra como los cambios y los defectos impactan el uso de Casos de Uso 2.0. [1]
Mapa Conceptual de Casos de Uso 2.0
Mapa Conceptual de Casos de Uso 2.0. Fuente: eBook "Use Case 2.0", Jacobson y otros.
Ya he hablado lo suficiente sobre Requisitos en general y de Casos de Uso en particular, así que hablemos de los demás conceptos que aquí encontramos:
Los Interesados son todas aquellas personas que de una u otra manera impactan del proyecto y se ven afectados por este y por el producto que se está construyendo. Todos ellos influencias directa o indirectamente al proyecto y no solo incluyen a los usuarios del sistema, sino también a los patrocinadores, a los ejecutivos, a otras áreas de la organización y a entidades externas relacionadas de alguna forma con la organización. A todos hay que tenerlos en cuenta a la hora de delimitar las funciones del sistema.
Uno de los principales mecanismos de comunicación entre los Interesados y el equipo de construcción es que los primeros nos cuenten historias a los segundos, sus Historias. Son narrativas acerca de lo que hacen y como lo hacen, con qué, con quién interactúan y qué intercambian. Estas narrativas son el alma de los casos de uso (no confundir con Historias de Usuario que son un repositorio de esas historias, como los son los casos de uso, los requisitos en prosa, los prototipos, los tableros de historias, entre otros).
En todo proyecto siempre hay Cambios, ya sea porque cambian las políticas de la organización, cambian las expectativas de los usuarios, cambia aspectos legales o contables, o cambian los interesados o los usuarios y estos últimos quieren otra cosa. Estos cambios seguramente modificarán las historias y, por consiguiente, los requisitos y los casos de uso. Incluso pueden requerir nuevas historias. Los cambios pueden llegar en cualquier momento y las porciones de casos de uso son una buena forma de analizar su impacto en el proyecto y de incluirlos en el producto.
Las Pruebas nunca deben faltar. Es lo único que asegura la calidad total del producto y deben verse como algo intrínseco al ciclo de vida del software. Como el software se implementó vía porciones de casos de uso, que ya incluyen los casos de prueba en su especificación, esta unión “software-pruebas” se hace finalmente indivisible, es uno de los grandes aspectos que nos enseña Casos de Uso 2.0 y una práctica excepcional. El hecho de que las pruebas hagan parte de la especificación de las porciones de casos de uso es a todas luces un paso más allá hacia la solución de una gran cantidad de inconvenientes que encontramos durante la práctica diaria de la construcción del software. Incluso, de esta forma, es posible implementar prácticas como Desarrollo Conducido por Pruebas (TDD por sus siglas en inglés –Test Driven Development) y otros métodos ágiles de desarrollo de software.
Durante las pruebas encontramos Defectos y mientras estos existan sabremos que la porción de casos de uso actual no está finalizada. Los defectos pueden ser encontrados durante una revisión par, en etapas tempranas del ciclo de vida e incluso de la iteración actual, durante la misma programación del sistema, con las pruebas unitarias u otro tipo de pruebas del programador, o mientras realizamos las pruebas de calidad final de cada porción de caso de uso y las pruebas de integración del sistema. En este punto juegan un papel muy importante el uso de herramientas para automatizar pruebas, como los Robots de pruebas.
Estos son algunos de los conceptos más importantes, inherentes a las prácticas expuestas en Casos de Uso 2.0. En el libro electrónico de Jacobson [1] encuentran más detalles sobre este modelo conceptual.
Referencias:
[1] El e-Book "Use Case 2.0", sobre las buenas prácticas alrededor del uso de los casos de uso, lo pueden encontrar en www.ivarjacobson.com.
Sobre Casos de Uso 2.0 pueden leer mi serie de artículos en este Gazafatonario:
http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html
http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html
Sobre Casos de Uso pueden leer toda mi sección de Lecturas Fundamentales en este mismo Gazafatonario, empezando en:

viernes, noviembre 16, 2012

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: XI


"Los buenos consejos no son tomados en cuenta generalmente, pero eso no es motivo para no darlos."
Agatha Christie
Consejo Adicional: ¿Cómo luce un caso de uso inefectivo?
Caso de Uso: Apertura de Productos y Servicios
Secuencia Básica:
1.     Muestre una lista de productos y servicios de la siguiente forma:
  •         La ventana izquierda lista todas las categorías de productos y servicios de la compañía (Ahorro e Inversión, Crédito Hipotecario, Otros Créditos)
  •         La ventana inferior muestra los datos que se solicitan para el producto seleccionado
  •         La tercera ventana muestra todos los productos y servicios que tiene actualmente el cliente
2.     Haga:
3.     El usuario hace clic en una categoría de producto o servicio
4.     Muestre los productos disponibles en esa categoría en orden alfabético
5.     El usuario hace clic en un producto
6.     Se actualiza la ventana inferior para solicitar los datos necesarios para la apertura del producto y el usuario hace clic en el botón “Solicitar Producto”.
7.     Chequee si el usuario cumple los requisitos necesarios para solicitar ese producto y que el producto esté disponible para su “tipo de persona” (Natural o Jurídica)
8.     Si el producto está disponible y el usuario cumple los requisitos necesarios, adicione el producto al usuario. Muestre la lista actualizada de productos del usuario, con el nuevo producto en estado “Solicitado”. Si no, muestre el mensaje “El cliente no cumple los requisitos necesarios. Seleccione otro producto.”
9.     Repita desde 3 hasta que el usuario haga clic en “Terminar Solicitud”
10.   Almacene la solicitud y regrese a la pantalla principal.
¿Y cómo luce un caso de uso efectivo?
Caso de Uso: Solicitar Producto
Actor: Cliente
Secuencia Básica:
1.     El Cliente solicita abrir un producto
2.     El sistema muestra la lista de productos actuales del cliente y muestra una lista de productos disponibles
3.     El Cliente selecciona el producto a solicitar
4.     El sistema verifica que el Cliente cumple con los requisitos necesarios y adiciona el producto a la lista de productos del cliente, en estado “Solicitado”.
5.     El sistema almacena la solicitud
Veamos algunos aspectos importantes de estas dos versiones:
Versión Inefectiva
Versión Efectiva
El nombre del caso de uso no es apropiado
El nombre está escrito como una frase verbal simple (en el formato “hacer algo”)
No tiene un actor definido
Tiene un actor principal, el Cliente.
El caso de uso se refiere a “el usuario” como actor del mismo. “Usuario” no es un concepto formal, es un humano, puede actuar como diferentes instancias de varios actores distintos.
El caso de uso se refiere a “el cliente” como actor del mismo. “Actor” es un concepto formal, puede ser un humano o un sistema, existe sólo si un usuario hace algo.
Está escrita en una especie de pseudocódigo y en lenguaje técnico.
Está escrita en prosa
Relaciona muchos aspectos de la interfaz de usuario. Orientado al Sistema.
Está escrito en términos del negocio (del usuario). Orientado al Negocio.
Aborda elementos que pueden ser disímiles en su tratamiento (productos y servicios, categorías de productos)
Aborda sólo productos. Incluso, los casos de uso deberían especificarse para un único producto a la vez.
Algunos pasos son complejos, difíciles de leer o muy largos. (Pasos 1 y 8).
Los pasos son claros, en el formato “el sistema hace…el actor hace”
La secuencia básica parece abarcar todos los escenarios posibles del caso de uso
La secuencia básica deja muchos escenarios para secuencias alternativas, como la solicitud de servicios o cuando el cliente no cumpla con las condiciones exigidas.
Parece haber sido especificado por completo en una sola pasada.
Le faltan detalles, pero estimula la creación iterativa de casos de uso.
Algunos pasos describen acciones consecutivas ejecutadas por el sistema y por el usuario a la vez.
Todos los pasos están escritos como expresiones verbales simples.
El verdadero truco con los casos de uso es mantenerlos simples. No nos preocupemos acerca de las formas del caso de uso, solo procuremos garabatearlos en una hoja de papel en blanco o en una página en blanco de un procesador de palabras simple, o en unas tarjetas indexadas blancas. No nos preocupemos por cubrir todos los detalles de inmediato. Los detalles no son importantes hasta mucho después. No nos preocupemos por capturar todos los casos de uso desde el principio; esa es una tarea imposible.
La única cosa para recordar sobre casos de uso es: mañana van a cambiar. Sin importar que tan diligente seamos a la hora de capturarlos, sin importar que tan meticulosamente registremos los detalles, sin importar que tan sistemáticamente pensemos acerca de los casos de uso, sin importar el mucho esfuerzo que hagamos para explorar y analizar los requisitos, mañana los casos de uso cambiarán.
Después vendrán las herramientas sofisticadas de apoyo. Las herramientas aumentan nuestra productividad, nos ayudan a clasificar, a buscar, a estimar, pero no hacen el trabajo por nosotros.
Esta es una visión minimalista del proceso, algunos la llaman ágil. Simplemente es una manera de hacer las cosas, una manera efectiva en ciertos casos. Ese es el verdadero sentido de esto: para cada proyecto, para cada actividad, debemos buscar o construir el mejor camino para ir de principio a fin y entregar el mejor de los resultados, el único posible.

W953BAF3WB56

miércoles, noviembre 14, 2012

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: X

Consejo 10
No usemos expresiones del tipo: “el sistema verifica si se cumple tal condición” y más adelante: “si se cumple la condición, haga esto”, y para terminar: “si no se cumple la condición, haga esto otro.” Este es un patrón que viene de la programación de computadores, es más bien pseudocódigo y la primera de las acciones no cumple con una de las premisas importantes de un caso de uso y es que cada acción lleve la secuencia del caso de uso un paso más adelante que el anterior. Vemos claramente que “el sistema verifica si se cumple tal condición” no avanza en el proceso, en cambio, debemos esperar hasta la siguiente operación: “si se cumple…” para continuar la secuencia.
En cambio, escribamos el caso de uso en términos de escenarios:
n. El sistema verifica que tal condición se cumple y hace…
n+1. El actor hace…
En una secuencia alterna especificamos lo que ocurre cuando la condición no se cumple:
nA1. El sistema verifica que tal condición no se cumple y hace…
(n+1)A2. El actor hace…
Como en:
4. El sistema verifica que el Cliente tiene capacidad de endeudamiento y solicita el valor del crédito
5. El actor ingresa el valor del crédito
Y en la secuencia alterna:
4A1. El sistema verifica que el Cliente no tiene capacidad de endeudamiento y solicita la identificación del avalista
4A2. El actor ingresa la identificación del avalista
Ejemplo
Consideremos este fragmento de caso de uso para verificar los fondos de una cuenta bancaria con miras a hacer efectivo un cheque.
Caso de Uso: Verificar fondos cuenta
Actor: Cajero
Secuencia Básica:
1.     El caso de uso inicia cuando el Cajero decide verificar los fondos disponibles para un cheque
2.     El sistema solicita el tipo y número de cuenta
3.     El Cajero ingresa el tipo y número de cuenta
4.     El sistema verifica que el número de cuenta existe y que está Activa y solicita el número del cheque
5.     El cajero ingresa el número del cheque
6.     El sistema valida que el número del cheque está dentro del rango autorizado y que no está contraordenado, y solicita el valor del cheque
7.     El cajero ingresa el valor del cheque
8.     El sistema verifica que hay fondos suficientes para pagar el cheque
9.     El caso de uso termina
Secuencia Alterna 1:
4A. El número de cuenta no existe
4A.1. El sistema verifica que el número de cuenta no existe y muestra el mensaje: “El número de cuenta dado no existe. Verifique.”
4A.2. El caso de uso continúa en el paso 2 de la secuencia básica.
Secuencia Alterna 2:
6A. El número del cheque no está dentro del rango autorizado
6A.1. El sistema verifica que el número del cheque no está dentro del rango autorizado y muestra el mensaje “El número del cheque no está autorizado. Verifique.”
6A.2. El caso de uso continúa en el paso 5 de la secuencia básica
Secuencia Alterna 3:
8A. No hay fondos suficientes para pagar el cheque
8A.1. El sistema verifica que la cuenta no tiene fondos suficientes para pagar el cheque y muestra el mensaje “Fondos insuficientes. Verifique.”
8A.2. El caso de uso continúa en el paso 7 de la secuencia básica
La escritura limpia del caso de uso lo hace claro, preciso y consistente, entre otros atributos deseables en un caso de uso. Nótese que es posible que haya más secuencias alternas.
Para saber más de casos de uso pueden visitar la sección Lecturas Fundamentales de mi Gazafatonario IT. En particular, pueden leer la Lectura Fundamental 3: Casos de Uso: Del Todo y de sus Partes.
Esta serie de consejos útiles para escribir casos de uso inicia en: