Mostrando las entradas con la etiqueta Requisitos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Requisitos. Mostrar todas las entradas
viernes, agosto 21, 2020
jueves, febrero 01, 2018
Diferencias en el tratamiento de los requisitos entre los enfoques Cascada y Ágil
¡Una pregunta de un viejo amigo me llevó una vez más por este sendero!
Es un hecho. Muchos profesionales trabajan actualmente en circunstancias desafortunadas y, sin embargo, no toman la iniciativa de cambiar su situación porque están condicionados a un formato de seguridad, conformidad y conservación, donde todo puede parecer tranquilo pero, en realidad, nada es más perjudicial para el espíritu innovador y de transformación que requerimos hoy quienes vivimos en los tiempos del VUCA*.
En particular, durante la transición de un enfoque en cascada a uno Ágil tenemos que lidiar con la búsqueda de medios y maneras para acortar el tiempo de salida al mercado y entregar productos de alta calidad y de más valor, más temprano y más frecuente y, si es posible, a un costo menor. Sin embargo, el camino hacia la Agilidad puede ser escabroso, con baches riesgosos y con personas deambulando por allí erráticamente y hasta en dirección opuesta, incluso con temor a o sin saber cómo avanzar.
Y uno de los aspectos que empiezan a diferenciar en profundidad el uso de uno u otro enfoque es este de los requisitos. Abordamos este asunto con Carlos Gil, Johnny Ordoñez, Carlos Quiroga, Luis Mulato y el grandioso equipo de coaches del Scrum Coaching Retreat Cartagena y, como siempre, llegamos a algunas conclusiones que se mueven en el terreno de los principios y, más en el fondo, de los valores Ágiles, la cultura ágil, el Ágil es algo que eres:
- En Ágil no hablamos de requisitos, más bien de respuestas a necesidades y, en otros casos, de hipótesis de cosas que queremos aprender. Cambiar el enfoque de “requisito” a “necesidad” o respuesta a necesidad, genera un sentido profundo de empatía entre todos los interesados, es decir, equipo de desarrollo de producto y usuarios o clientes finales.
- A propósito de clientes finales, en Ágil, el cliente siempre es el centro de atención. Esto habilita a los equipos a buscar las mejores formas de suplir esa necesidad o de comprobar las hipótesis. Estas en últimas son necesidades de aprendizaje.
- Creemos que esta es la distinción más grande entre las dos propuestas: el requisito te lleva a algo preestablecido, definitivo o definible claramente. Hablar de necesidades o de hipótesis abre la puerta al cambio.
- En el enfoque Cascada se definen experiencias orientadas al proceso, con momentos de interacción preconcebidos por los formularios y procesos definidos en los requisitos, y aun hablamos de interacciones y no de conversaciones con las soluciones tecnológicas. En Ágil, aspectos como la experiencia de usuario, momentos de verdad, conversaciones, son esenciales para la definición de la historia de usuario que guía el desarrollo de producto.
Vamos con las disparidades entre uno y otro enfoque cuando de requisitos se trata
Son muchas las diferencias que existen en la forma de abordar los requisitos de un producto cuando usamos (o usábamos) la forma Cascada y lo que hacemos ahora, motivados por el pensamiento Ágil. Estas que describo a continuación son apenas algunas de ellas, algunas más relevantes que otras pero significativas todas al fin y al cabo.
Al principio del proyecto o del esfuerzo de desarrollo
En Cascada se toman o "levantan" (casi) la totalidad de los requisitos al principio del proyecto, y de muchos de ellos se hace con gran detalle. En Ágil no. Se establece un alcance, sí, una visión, pero de muy alto nivel, muy horizontal, es decir, no se llega a ningún detalle excepto quizás para esas necesidades de los dos primeros Sprints (a lo sumo), la porción de producto que se va a construir durante las primeras de cambio. El llamado Mínimo (o Minimísimo) Producto Viable.
En Cascada nos tardamos semanas y hasta meses haciendo esta primera actividad. En Ágil nos tardamos unas pocas horas, a lo sumo unos pocos días, se establece un bloque de tiempo (time-box) y cuando este se acaba, se acaba.
En Cascada participa una persona del lado del equipo de desarrollo o un "subequipo", el o los analistas funcionales o de requisitos. Quizás en algún momento entra uno que otro rol, como el Arquitecto de Software. En cualquier caso, no participa todo el equipo. En Ágil participa todo el equipo de desarrollo desde el inicio, escuchando a los usuarios e interesados en el producto.
Más adelante, cuando el proyecto está en marcha
En Cascada se refinan los requisitos, hay ajustes, controles de cambios. El sobrevaluado CCC (léase Comité de Control de Cambios) que se reúne el último jueves de cada mes, mientras el cliente ve impaciente cómo su competencia se adelanta y le quita parte del mercado. Mientras tanto, en Ágil se van refinando los requisitos iteración tras iteración. Siempre nos concentramos en lo que se va a construir en los siguientes 2 sprints o iteraciones, a lo sumo. Más tiempo no, porque las cosas pueden cambiar. Los equipos Ágiles aprovechamos los cambios para brindar ventaja competitiva a nuestros clientes.
En Cascada los requisitos siempre los "administra" una persona o un subequipo (analistas), con los usuarios. En Ágil hay un Dueño de Producto (representante de los usuarios), pero la responsabilidad es de todo el equipo.
En Cascada los requisitos se construyen, como sabemos, siguiendo un proceso secuencial donde ellos se tratan aparte y son una entrada al resto de ese proceso; además, el producto se entrega como un todo. En Ágil se construye un incremento del producto en cada iteración (de muy pocos días), esto es, producto probado y funcionando con valor, potencialmente desplegable y que genera retorno de la inversión (ROI) o, al menos, permite recibir retroalimentación, con lo que podemos aprender muchísimo del comportamiento y de la reacción de los usuarios al uso del producto.
En Cascada normalmente el orden de construcción lo decide el equipo de desarrollo (quizás en cabeza de un arquitecto o un subequipo). En Ágil el orden de construcción lo decide el usuario (dueño de producto), es él quien tiene la última palabra sobre esto.
En Cascada, el énfasis en cuanto a requisitos está en la especificación (documentación) de los mismos, en otras palabras, en escribir y escribir requisitos. En Ágil, el énfasis está en la conversación que tienen los usuarios o su representante (dueño de producto) con el equipo de desarrollo. Esta conversación es cara a cara y continua, durante todo el proyecto o esfuerzo de desarrollo.
Esta última característica es lo que nos empieza a volver ágiles, cuando lo logramos nos damos cuenta que estamos usando el pensamiento Ágil y estamos dejando atrás la cascada y otras formas tradicionales de trabajo.
En Cascada se espera que prácticas de aseguramiento de calidad permitan que se entregue un producto que cumpla con casos de prueba previamente definidos y aprobados con el área de negocio. En Ágil damos espacios a prácticas como TDD y BDD para guiar la definición de los criterios de aceptación, identificando de manera temprana la respuesta real que espera el usuario final, la prueba es guiada por la retroalimentación continua, lo cual mejora el uso y por lo tanto la aceptación del usuario.
Y sobre medios o herramientas para “recolectar” y administrar requisitos
Una diferencia en cuanto a los medios o mecanismos para "recolectar" requisitos:
En Cascada se usan medios como los documentos escritos tradicionales llenos de expresiones tipo "el sistema debe hacer esto" o "el sistema debe hacer aquello", o se usan mecanismos como casos de uso, entre otros. En cualquier caso, como mencioné antes, la fuerza está en elaborar grandes cantidades de documentación de requisitos. Escribí mucho sobre esto aquí en el Gazafatonario durante la década pasada y publiqué un libro al respecto. Lo pueden encontrar en Amazon.
En Ágil, por su parte, usamos medios o mecanismos que promuevan la conversación entre los interesados (usuarios y equipo de desarrollo). Las Historias de Usuario se han constituido en el medio esencial para esto. Pueden encontrar una especie de índice de mis artículos y propuestas y las de mi gran amigo Jorge Abad sobre este tema en bit.ly/lashistoriasdelucho.
Ahora sí, cuéntame en el foro de otras diferencias a la hora de recolectar y administrar requisitos o necesidades que consideres importantes.
*VUCA: siglas en inglés de Vulnerabilidad, Incertidumbre, Complejidad, Ambigüedad
miércoles, junio 14, 2017
De las Reuniones de Requisitos - 1 -
Empiezas a construir una solución errónea y a nadie le importa...
¡Solicitas una reunión de requisitos y todo el mundo pierde la cabeza!
domingo, junio 26, 2016
¡El tamaño sí importa!
Vamos al grano. Si la mayoría de tus historias de usuario llegan a “Terminado” apenas unas pocas horas antes de la Revisión del Sprint, todavía pueden ser más pequeñas. Tu equipo debería tener historias tan pequeñas que las puedas finalizar durante las primeras horas o días del Sprint, dependiendo de la duración de este. Así te aseguras desde las primeras de cambio que el equipo está siendo productivo, está enfocado y que van a entregar valor al final de la iteración. ¡Después de todo, finalizar una tarea aumenta la moral del equipo!
Aunque el objetivo de un Sprint no debe medirse en número de historias de usuario a terminar (implementar), sino al cumplimiento de un objetivo específico, siempre es mejor “prometer” o planear terminar varias historias pequeñas o muy pequeñas que muy pocas historias medianas o grandes.
Es evidente: si tienes 10 historias en tu lista de pendientes del sprint (alias el backlog del sprint), y no terminas 2, es mucho mejor que si solo tienes 4 y terminas 2. En ambos casos fallaste en el mismo número de historias, pero en el primer escenario tuviste un acierto del 80% mientras que en el segundo apenas llegaste a la mitad de la promesa del sprint. El resultado es menos alentador si las historias terminadas son dos de 3 puntos y dejaste sin terminar o aun a punto de terminar dos historias de 13. Solo cumpliste con 6 de los treinta puntos que prometiste.
Hablando de puntos, una buena medida, algo que me ha funcionado casi siempre, es implementar historias cuyo puntaje no sobrepase entre una décima parte y una sexta parte de la velocidad del equipo. Es decir, si la velocidad del equipo de desarrollo es 30 puntos por Sprint, las historias a implementar no deberían ser más grandes de 3 a 5 puntos. Historias de ½, 1 y 2 puntos siempre son bienvenidas en este escenario.
Ahora bien, el tamaño de las historias es un concepto relativo. Un equipo de 7 o 9 personas no ve igual una historia de usuario en un sprint de 3 o 4 semanas que un equipo de 3 o 5 personas en un sprint de 1 o 2 semanas. Pero algo en lo que todos estamos de acuerdo es que, una vez terminadas, las historias deben proporcionar valor al negocio. Las cosas así, otro indicador de “pequeño” es Pareto.
El objetivo siempre es encontrar ese 20% de la historia (de funcionalidades que se van implementar vía esa historia) que genere o entregue el 80% del valor total de la misma. A partir de allí, la división se hace de manera orgánica, adicionando historias al backlog de producto que complementen la historia de “más valor”.
También ayuda el nivel de entendimiento de toda la historia y qué tan rápido llegamos a entenderla por completo. Un índice de que quizás la historia no es pequeña es que no la hemos terminado de entender, quizás no están claros algunos de los criterios de aceptación o hay nubes en la conversación (la c de conversación de la historia) relacionadas con los requisitos funcionales o no funcionales a implementar.
Una historia de usuario debe ser tan pequeña que obligue a una conversación cara a cara donde todos entiendan mejor el problema— Leonardo Agudelo (@sweepnoise) March 10, 2015
Finalmente, no solo la S de INVEST indica que la historia es pequeña (Sucinta). Un indicativo de que quizás no lo es tanto, es que algunas partes de la misma (o toda la historia) no sean negociables o que no haya consenso en su estimación o que tengamos dudas acerca de si es posible conducirla a través de un proceso que nos asegure la calidad del producto terminado o de que incluso tenga dependencias con otra(s) historia(s).
---------------------------------------------------------------------------------------------------------------
Para saber más sobre historias de usuario, puedes leer mi artículo introductorio:
Historias de Usuario: un nuevo orden en los requisitos del software:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html
Para saber más de los criterios INVEST de las historias de usuario puedes leer mi serie de artículos sobre el asunto.
La serie de artículos "Escribiendo Historias de Usuario Altamente Efectivas":
Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)
Y este otro:
De historias de usuario, culturas y del arte de narrar historias
También puedes visitar el blog Lecciones Aprendidas de mi amigo Jorge Abad:
Video de explicación: Cómo se construyen historias de usuario
Ejemplo: Una historia de usuario - Listado de Morosos
Ejemplo de historia de usuario : Ingreso al sistema
http://www.lecciones-aprendidas.info/2015/03/ejemplo-de-historias-de-usuario-ingreso.htmljueves, marzo 05, 2015
De historias de usuario, culturas y del arte de narrar historias
“Yo no sé muchas
cosas, en verdad,
Digo tan solo lo
que he visto.
Y he visto que la
cuna del hombre
la mecen con
cuentos,
que los gritos de
angustia del hombre
los ahogan con
cuentos,
que el llanto del
hombre
lo taponan con
cuentos.
Y que el miedo
del hombre
ha inventado
todos los cuentos…
Yo sé muy pocas
cosas, es verdad,
pero me han
dormido con todos los cuentos
y
sé todos los cuentos ...”
[León Felipe,
Aguaviva.]
La vida es una alegoría,
los seres humanos no solo estamos configurados como cuerpos biológicos
abastecidos de estímulos y pulsiones, pues nacemos en un entorno social y por
tanto nos relacionamos, desde lo más esencial –lo familiar, hasta lo más
universal, con nuestros semejantes. Pero además poseemos una visión personal
para interpretar nuestra cotidianidad, tenemos ideales y pensamientos,
emociones y aversiones que nos hacen actuar
de formas particulares al interpretar nuestra realidad.
En todo esto, la
narración de historias juega un papel muy importante en la construcción de conocimiento. La
narrativa es una forma de caracterizar los fenómenos de la experiencia humana. Dice
Ivar Jacobson en su libro Casos de Uso 2.0 que “la narración de historias
permite a las culturas sobrevivir y progresar; es el camino más simple y más
efectivo para pasar el conocimiento de una persona a otra. Es la mejor manera
de comunicar lo que un sistema debe hacer y hacer que todo el mundo trabaje en
el sistema sobre los mismos objetivos.” [1]
Las historias (de
usuario) establecen una manera de organizar y comunicar experiencias. Las personas
usan instintivamente la narración de historias para organizar un cúmulo de
ideas que consideran disperso; además, gracias a ellas pueden organizar lo que
saben acerca de su trabajo y de cómo lo hacen. Al narrar historias, las
personas nos invitan de una forma u otra
a investigar sus pensamientos, sus sentimientos y sus intenciones.
Finalmente, como oyentes y más tarde como lectores de las historias de usuario,
adherimos a los acontecimientos, como una exploración de la experiencia de los
usuarios, entendiéndolas mejor y de la forma más completa posible, pero sobre
todo, comprendiendo su valor real.
Quienes transitamos a
diario por el vasto universo del diseño y construcción de productos de software
sabemos que es importante enfocarnos en el valor que estos prestarán a sus
dueños, los usuarios, y a otros interesados. El mismo Jacobson dice que “solo
se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo
se usará el sistema que en las largas listas de funciones o características que
ofrecerá.” [2] Y agrega más adelante: “es fácil capturar y validar la
completitud de las historias y estas, a su vez, facilitan filtrar las formas
potenciales de usar el sistema que ofrezcan poco o ningún valor real a los
usuarios. Este foco constante en el valor permite asegurar que cada entrega del
sistema sea tan pequeña como sea posible, a la vez que tenga valor real para
los usuarios del sistema y para los interesados que financian el desarrollo.”
[3]
Cuenta
las historias, no las escribas
En su libro “Fifty Quick Ideas to Improve your User
Stories”, Gojko Adzic & David Evans [4], compilan una serie de conceptos
sobre cómo mejorar nuestras historias de usuario o, mejor aun, sobre cómo
mejorar el desempeño del equipo ágil usando la técnica de las historias de
usuario. Me interesó mucho la primera de esas ideas, muy acorde a mi interés
actual sobre las historias y la supervivencia de las culturas. Esta idea es
precisamente la del título de esta sección: cuenta historias, no las escribas.
Uno de los errores más
comunes de las personas que empiezan a usar prácticas ágiles es creer que las
historias de usuario son requisitos livianos. Las historias de usuario no son
requisitos, son más bien una carta de intención de lo que queremos que haga el
sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo
de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos.
Este malentendido conduce a situaciones en que las historias sean recolectadas
en herramientas de gestión de actividades, con muchos detalles escritos o
proporcionados por representantes del negocio.
Nada más alejado de una
buena práctica. Las historias de usuario implican un modelo totalmente
diferente, Gojko y David lo llaman “requisitos por colaboración”, un modelo donde
la transferencia de conocimiento vía documentos “pesados” se reemplaza por
involucramiento y colaboración, al mejor estilo del Manifiesto Ágil. Ya sabemos
que la conversación cara a cara es la forma más efectiva de comunicar
información y que una buena discusión entre los interesados y el equipo ágil lleva
a mejores preguntas/respuestas, opciones e ideas del producto. Cuando los
requisitos se escriben, aun si los llamamos historias de usuario, estas
discusiones nunca suceden y las mejores ideas se pierden para siempre. Tengo algo
de experiencia en esto, pasé dos décadas escribiendo requisitos de software,
todo tipo de requisitos, todo tipo de productos de software.
La recomendación es
simple, avanzan Adzic y Evans en su libro: intenta contar historias o que te
cuenten historias, en vez de escribirlas. Usa tarjetas físicas o un sistema de
tiquetes electrónicos, pero solo como recordatorios de esa conversación que
tendrás más adelante. No gastes mucho tiempo tratando de descifrar los detalles
de las historias con anticipación. Compromete a los interesados del negocio e
involucra a los miembros del equipo en una discusión, busca distintas
perspectivas de la historia y explora opciones. Esta es la forma de acceder a
los beneficios reales de trabajar con historias de usuario.
Beneficios
clave de contar historias
Las discusiones permiten
a los representantes del negocio, no solo explicar lo que quieren, sino también
asegurarse de que los miembros del equipo entiendan esto correctamente. Uno de
los mayores problemas en los modelos tradicionales son los malos entendidos
entre los distintos roles en el equipo y entre los interesados, entre quienes
existen niveles heterogéneos de conocimiento acerca de las necesidades de cada
uno, complemento además del ya típico fenómeno del “teléfono roto” [5]. Es un
hecho, explicar una historia cara a cara evita caer en vacíos de conocimiento
sobre la historia.
El segundo beneficio,
apuntan Adzic & Evans, es el análisis más rápido. Cuando el equipo completo
se involucra en una discusión, los vacíos funcionales, las inconsistencias y
los requisitos no claros se descubren más rápidamente que cuando una sola
persona (léase Analista del Negocio o similar), escribe los detalles.
Pero el beneficio más
importante de la comunicación cara a cara, comparada con el paso de información
vía documentos, es que la primera produce mejores soluciones, mejores
productos. Para ser capaz de construir buenas soluciones, las personas
necesitan conocer los planes y las oportunidades del negocio, entender el
dominio del problema, tener un conocimiento profundo de las restricciones
técnicas estar al tanto de las nuevas tecnologías que potencialmente les puedan
servir. Involucrar a un grupo de personas en el análisis desde diferentes
perspectivas ayuda al equipo a beneficiarse del conocimiento compartido.
Como
lograrlo
La excusa más común para
llenarnos de documentación es la insistencia del negocio en la aprobación
formal, las regulaciones legales o gubernamentales o las dependencias con
terceros. Si es necesario “firmar” las historias hazlo a medida que las
discutes. Es más, si el alcance final debe ser aprobado por varios interesados
en el negocio, involúcralos en las reuniones de Refinamiento, días antes de la
reunión de planificación del Sprint donde se van a construir las historias. En
cualquier caso, el Dueño de Producto juega un papel muy importante en la
consecución de tales aprobaciones. Es una de sus responsabilidades directas.
Como siempre, ensaya
distintos acercamientos y en cada retrospectiva analiza como le fue a tu
equipo. Como dice el refrán, la experiencia no se improvisa. Hasta allí el
tema, recomiendo amplísimamente los libros que usé como referencia
Referencias
[1] [2] [3] Ivar
Jacobson et all. Use Case 2.0. Ivar Jacobson
International. 2011. Traducción
de Luis
Antonio Salazar y Carlos Mario Zapata.
[4] Gojko Adzic & David Evans, Fifty Quick Ideas
to Improve your User Stories, ©
2013 – 2014 Nueri Consulting LLP
[5] Conocido también en algunas culturas o regiones como
el fenómeno o el juego del “teléfono descompuesto”
Para saber más de historias de usuario
puedes leer mi serie de artículos en este mismo Gazafatonario:
http://goo.gl/iJvj7
http://goo.gl/NZv4vj
http://goo.gl/e1DSVh
http://goo.gl/eGHQQU
lunes, junio 02, 2014
Libro: Asuntos de la Ingeniería del Software- volumen II
.jpg "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:
Suscribirse a:
Entradas (Atom)