Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Analista. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Analista. Mostrar todas las entradas

domingo, octubre 07, 2012

Casos de Abuso, Parte 12: El Ingeniero de Requisitos es un psíquico


Bueno, esta me la sé también con Analistas, con Diseñadores, con Programadores y hasta con Gerentes de Proyectos. También con usuarios. Cada uno de nosotros piensa que todos los demás en el proyecto están igualmente motivados, que tienen las mismas habilidades, que conocen todo el entorno necesario para entender el sistema. Y No es así. También creemos que los demás piensan como nosotros mismos, que ven el universo como lo vemos nosotros. Y Tampoco es así.
Como receptores de información siempre tenemos un mecanismo infalible: “el qué más.” Como en ¿Qué más debo saber de este proceso? ¿Qué más me puede decir de este modelo? ¿Qué otra cosa esconde este escenario? ¿Quién más necesita esta funcionalidad? ¿En qué otro momento se requiere esta información? Como emisores también debemos estar prestos a brindar toda la información que requiera nuestro interlocutor. ¿Qué más necesita saber? ¿Tiene alguna otra pregunta? ¿Son necesarios más ejemplos? ¿Quiere hablar con alguien más?
Y no me refiero solamente a la comunicación usuario-analista, sino también a la que ocurre al interior del equipo de desarrollo: cuando presentamos los casos de uso, cuando exponemos la arquitectura, cuando mostramos la realización de casos de uso o el modelo de datos y, sobre todo, cuando documentamos el software. Todo esto debemos hacerlo con la premisa de “documentar para el resto”, para el resto de la organización, para el resto del equipo del proyecto, para los usuarios, para los socios de negocios, para los proveedores, incluso para personas ajenas al producto, al proyecto y a la misma compañía, como consultores, expertos del dominio de negocio o técnico y otro tipo de personas. Este es otro de los momentos cuando recomiendo el uso formal de UML y del español (o de algún otro idioma necesario) acorde al público, o sea, terminología del negocio para los usuarios, léxico técnico para los técnicos.
Impacto en la calidad: Medio.
Aquí termina por ahora este análisis, al menos en lo que se refiere a la enumeración de casos de abuso. Volveremos con un capítulo sobre conclusiones y recomendaciones.
Entre tanto, ¿qué otros errores se les ocurren? ¿Qué otros abusos creen que han estado cometiendo ustedes o sus colegas?
No dejen de contarme y lo discutiremos más adelante.

martes, octubre 02, 2012

Casos de Abuso, Parte 11: Cada caso de uso se diseña e implementa de manera independiente


El diseñador y el desarrollador sólo ven el caso de uso en desarrollo sin importarles el sistema como un todo.  Cuando esto se hace así, y no por paquetes relacionados, corremos el riesgo de no armar el “rompecabezas” con facilidad al final de la operación.
Y lo que es peor, muchas veces durante el diseño e implementación del caso de uso no tenemos en cuenta los lineamientos arquitectónicos impuestos a la solución. El producto termina siendo una colcha de retazos mal cosidos. Esta situación convierte los hitos de integración del producto, iteración tras iteración, fase tras fase, en un serio dolor de cabeza para el arquitecto, los diseñadores y los mismos programadores. Entonces surgen los reprocesos, el desperdicio de código, rediseños, y el resultado final: un producto de mala calidad.
El tratamiento: la arquitectura del software. Una que sirva como una gran lista de chequeo para los diseñadores y para los implementadores del producto. La arquitectura de software es la organización fundamental de un sistema, formado por sus componentes, las relaciones entre ellos mismos y con el entorno, y los principios que gobiernan su diseño y evolución (IEEE 1471-2000). Según Booch, Kruchten y otros, la Arquitectura de Software incluye decisiones acerca de la organización de un sistema de software como:
·         La selección de los elementos estructurales que componen el sistema y sus interfaces
·         El comportamiento del sistema, especificado en las colaboraciones entre esos elementos
·         La composición de estos elementos estructurales y comportacionales en subsistemas más grandes
·         El estilo arquitectónico que guía esta organización
Toda arquitectura de software comienza por una arquitectura funcional o vista de casos de uso, un subconjunto del modelo de casos de uso del sistema, compuesto a su vez por los así llamados casos de uso o requisitos arquitectónicos. Después están la vista lógica, que le habla a los analistas y diseñadores sobre la estructura del software. La vista de implementación, que les cuenta a los programadores detalles sobre el manejo del software. Por su parte, la vista de procesos habla de desempeño, escalabilidad y puesta en marcha a los integradores del sistema. Y también está la vista de despliegue que nos explica de manera lacónica la topología del sistema, aspectos de la entrega del mismo, de instalación y de comunicación subyacentes.
El diseño y la implementación de todo el producto de software debe obedecer a estas restricciones, casi leyes, impuestas por la arquitectura así descrita. Es lo que hace posible que los casos de uso se diseñen en grupos heterogéneos de paquetes o subsistemas diferentes.
Impacto en la calidad: Alto.

PD. Para saber sobre Arquitectura de Software, específicamente sobre el modelo de las 4 + 1 vistas expuesto por Krutchen, pueden tener en cuenta la siguiente referencia:
P.B. Kruchten, “The 4 + 1 View Model of Architecture,” IEEE Software, pp. 42–50, Nov. 1995. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=469759&isnumber=9910
También la encuentran en:
Además, sobre análisis y diseño de casos de uso, en particular, sobre realización de casos de uso, pueden visitar mi Lectura Fundamental 10:
Y sobre programación orientada a objetos, pueden leer mi Lectura Fundamental 11: Orientación a Objetos: Un Enfoque Teórico Moderno (Actualizado)

domingo, septiembre 30, 2012

Casos de Abuso, Parte 10: Los flujos de eventos en los casos de uso son escritos en pseudocódigo


Este es el que yo llamo “síndrome del programador que se volvió analista”, algo así como el hombre-lobo del proceso de desarrollo de software. Creo que todos los que hemos recorrido este largo pero tortuoso laberinto que significa el ciclo de vida del desarrollo de software hemos experimentado, al menos, una o más de esas manifestaciones “fenomenoides” del universo informático. Además, este abuso es primo del abuso 5, donde usamos detalles técnicos en la documentación del caso de uso.
El antídoto es sencillo: un caso de uso siempre, sin ninguna excepción, se escribe en terminología del negocio, con las palabras que usa el usuario en sus actividades diarias. Si esto no es posible, quizás no estamos ante un caso de uso.
Nada de incluir expresiones como: “si ocurre esto entonces hacer aquello”, en cambio usar distintas secuencias o flujos alternos; o “mientras se cumpla una condición, realizar estas acciones”, en vez de ello, describir el conjunto de acciones para un elemento-sujeto de la condición y en los requisitos especiales del caso de uso dejar de manifiesto que puede haber uno o más elementos para esa condición. Y mucho menos usar nombres de “variables”, ciclos for o while o selección múltiple. Lo único que lograremos con ello es confundir a los usuarios.
Veamos con un caso de uso algo escueto un ejemplo típico:
Caso de uso: Retirar fondos
Actor: Cliente
Secuencia Básica:
1.    El caso de uso inicia cuando el cliente decide retirar dinero en efectivo de un cajero automático
2.    El sistema solicita la cantidad de dinero a retirar
3.    El Cliente ingresa la cantidad de dinero a retirar
4.    El sistema verifica el saldo del Cliente
5.    Si el Saldo del Cliente es mayor que o igual a la cantidad a retirar, el cajero entrega el dinero. De lo contrario, muestra el mensaje “Fondos insuficientes”
6.    El caso de uso termina
Los pasos 4 y 5 de este caso de uso son una muestra de lo que no se debe hacer al documentar requisitos. En cambio, podríamos decir:
4.    El sistema verifica que el Cliente tiene saldo suficiente en su cuenta y entrega el dinero.
5.    El caso de uso termina
Para el caso de falta de fondos, escribimos una secuencia alternativa. Esta estrategia además posibilita una implementación más rápida y “limpia” del caso de uso y permite al equipo de pruebas tener mayor visibilidad de los escenarios para verificar el software.
Impacto en la calidad: Alto.

PD. Para saber más de sobre casos de uso, abecés, anatomía, prácticas y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en mi Gazafatonario IT.

miércoles, septiembre 26, 2012

Casos de Abuso, Parte 9: Todos los requisitos funcionales se documentan en casos de uso


El que un proceso sea dirigido por casos de uso no quiere decir que toda la funcionalidad del software debe estar documentada en casos de uso. Hay requisitos que son transversales al producto, es decir, aplican en varias partes del sistema; también hay requisitos funcionales que se expresan mejor en prosa, siempre en términos del usuario, pero en narrativa; hay otras funcionalidades cuya complejidad amerita el uso de diagramas de actividad o de otro tipo de elementos gráficos o visuales para entenderse. En este último caso, siempre recomiendo el uso formal de UML como mecanismo de comunicación para no dar pie a malos entendidos o a concentración de ambigüedades.
Ya lo he expresado antes, los casos de uso apenas son uno de los mecanismos para identificar, organizar, documentar y administrar requisitos o, en el orden de ideas que estoy formulando, un receptáculo de requisitos, un depósito, un bote, una funda, un artilugio. De hecho, los casos de uso constituyen la práctica industrial más ampliamente usada en materia de requisitos de sistemas de información.
Lo digo de esta manera porque he notado que es muy fácil para las personas extraviar la noción y la práctica correcta de la Ingeniería de Requisitos y volverse “caso-de-uso-dependientes” y en ocasiones crean una especie de religión donde el acto de fe por los casos de uso toma tintes de devoción.
Como cualquier adicción, esta también va a ser difícil de desarraigar de nuestros modelos mentales. Sin embargo, vamos a intentarlo. Pero antes de eso, quiero reiterarles que soy entusiasta de los casos de uso, quienes han seguido mi Gazafatonario IT conocen las Lecturas Fundamentales, un esfuerzo medio modesto medio imponente por transmitir mi experiencia en el tema y que fueron la base de mi próximo libro, actualmente en etapa de edición.
En los últimos meses también he estado publicando sobre casos de uso 2.0, una estrategia que reúne las mejores prácticas tradicionales y ágiles para la documentación de requisitos de software, expuesta recientemente por el Dr. Ivar Jacobson y su equipo. Sobre este tema volveremos más adelante, cuando hayamos entendido, o hayamos vuelto a entender, el verdadero sentido del uso y el abuso de los casos de uso.
Este ha sido el principal objetivo de esta serie así llamada “Casos de Abuso”. En el capítulo 4 de la misma expongo las distintas formas y colores que pueden tomar los requisitos del software:
Impacto en la calidad: Bajo.
PD. Para saber más de ingeniería de requisitos, análisis de requisitos y el papel del Analista de Requisitos y de otros aspectos relacionados, pueden leer mi Lectura Fundamental 9:RUP: Fase de Concepción, Parte 2”, en mi Gazafatonario IT:

martes, septiembre 25, 2012

Casos de Abuso, Parte 8: Precondiciones vs. Validaciones y Poscondiciones vs. Resultados


A este caso de abuso originalmente lo titulé:
Las precondiciones son validaciones que hace el caso de uso al comienzo del mismo o en algún paso siguiente. Las poscondiciones y el resultado del caso de uso son una misma cosa.
Este es quizás el mayor de los abusos. Las precondiciones no ocurren dentro del caso de uso, es justamente lo contrario. Las precondiciones representan el estado en el que debe estar el sistema para que se ejecute el caso de uso a la que pertenecen. Son acciones que ocurren antes, en algún momento del tiempo, de la ejecución (o de la necesidad de ejecución) del caso de uso. Y cuando digo “en algún momento del tiempo” no me refiero a que tiene que ser inmediatamente antes del caso de uso, puede ser en cualquier instante, mientras sea antes de la ejecución del caso de uso. Para usar términos bastante reconocidos por nosotros, si un caso de uso tiene precondiciones, se encuentra deshabilitado hasta tanto todas las precondiciones no se hayan ejecutado y hayan producido los resultados necesarios para que el caso de uso se habilite y pueda ejecutarse.
Figura 2: Representación Visual de las Precondiciones y las poscondiciones de un caso de uso. Fuente: Adaptado de IBM Rational Unified Process
El error más común ocurre cuando confundimos una precondición con la validación a un elemento específico del negocio, por ejemplo, que el Cliente debe tener una cuenta corriente para solicitar aumento de cupo de sobregiro. Esta, a todas luces, es una verificación que debe ocurrir en el caso de uso “solicitar aumento de cupo de sobregiro” después de que el cliente se haya identificado, antes no es posible.
Un análisis similar puede hacerse para las poscondiciones, confundidas casi siempre con los resultados del caso de uso. Por ejemplo, es frecuente leer en la especificación de un caso de uso: “el sistema almacena los datos de la solicitud.”, “el sistema muestra el mensaje ‘no se pudo realizar la operación’.”, “el sistema cancela la ejecución del proceso.” Todas estos detalles corresponden a eventos que ocurren (deben ocurrir) dentro del caso de uso, no después de su ejecución, que es el terreno donde se mueven las poscondiciones.
Una poscondición típica puede ser: “el cliente puede consultar el estado de sus facturas.” Otra puede ser: “la cuenta del usuario queda deshabilitada.” Una más: “el cliente VIP puede modificar el estado de su reserva.” Todas estas son acciones que los usuarios pueden hacer después de que un determinado caso de uso se haya ejecutado, satisfactoriamente o no. El momento en el que se haga tampoco tiene que ser inmediatamente después, casi siempre depende de las necesidades de los usuarios particulares de cada funcionalidad.
Una situación adicional que ocurre en muchas oportunidades es que nos quedamos buscando precondiciones y poscondiciones del caso de uso durante un tiempo considerablemente extenso. Siempre recomiendo a los neófitos que si no las encuentran en las primeras de cambio pueden estar sucediendo dos cosas importantes:
  • No tenemos información suficiente del caso de uso (o no lo hemos entendido bien)

O
  • No tenemos la experiencia práctica o el conocimiento teórico suficiente para lidiar con estos dos aspectos de los casos de uso.

En el primer caso, debemos siempre buscar la información que nos hace falta con las personas involucradas, los usuarios; en el segundo caso es un poco más difícil, pero mientras este tema se nos vuelve una costumbre, recomiendo no quedarnos mucho tiempo paralizados por ello y seguir adelante. Las precondiciones y las poscondiciones son aspecto importantes para el diseño y la implementación del caso de uso, pero si no las encontramos, existen otras formas de llegar a la misma solución, quizás tome un poco más de tiempo a los diseñadores, pero este será mucho menos que si los analistas se quedan horas o días buscando algo que no conocen.
Otra cosa más, tanto las precondiciones como las poscondiciones son opcionales: no siempre son un elemento adherido al caso de uso. Es posible que haya casos de uso que no tengan unas o las otras, o ambas.
Impacto en la calidad: Alto.
PD. Para saber más de precondiciones y poscondiciones y de otras características de los casos de uso pueden leer mi Lectura Fundamental 3: “Casos de Uso: del todo y de sus partes”, en mi Gazafatonario IT:

jueves, septiembre 20, 2012

Casos de Abuso, Parte 7: La realización o diseño de un caso de uso siempre se hace


Esta es el más debatible de todos los abusos. Está en una zona gris. En aras de la calidad del producto, objetivo último de todo proyecto, siempre deberíamos hacer la realización del caso de uso [3], sin tener en cuenta el grado de mayor o menor complejidad del mismo. Sin embargo, siempre encontramos factores limitantes de tiempo, de recursos y de costos que lo impiden.
Ya en el primer abuso decía que mínimo debemos hacer la realización de los casos de uso arquitectónicos. Seguramente, si hacemos bien nuestro trabajo de diseñadores de software, de esta actividad surgirán la mayoría de las  entidades del sistema, los objetos controladores, las fachadas y las interfaces, entre otros tipos de objetos. El número de casos de uso arquitectónicos varía de un proyecto a otro, pero debería girar en torno a un 20% del total de casos de uso del producto. Es una cifra un tanto arbitraria pero parece funcionar en la mayoría de los casos, al grado de haberse convertido en una práctica generalizada.
¿Y el otro 80%? Yo siempre uso el precepto de “modelar para entender lo que vamos a construir.” Si alguien en el equipo de desarrollo no entiende un caso de uso, lo que hace o como lo implementa, entonces debemos apoyarnos en el modelado para subsanar esta situación. Y la realización del caso de uso es un buen comienzo para ello. ¿De cuántos diagramas preciso? Los que sean necesarios para entender. Ni más ni menos.
Impacto en la calidad: Bajo.
PD. Sobre diseño de casos de uso, más específicamente, sobre realización de casos de uso, los invito a leer mi Lectura Fundamental 10: Realización de Casos de Uso: De los Objetos y sus Interacciones en mi Gazafatonario IT.

lunes, septiembre 17, 2012

Casos de Abuso, Parte 6: Un escenario y un caso de uso es lo mismo

Simplemente no. Muchas veces los términos se usan indistintamente, yo mismo me he visto diciendo “caso de uso” cuando realmente quiero decir “escenario”. Pero ese es otro problema.
 Figura 1: Representación Visual de un escenario de un caso de uso

Un escenario es el flujo que sigue un caso de uso durante su ejecución de acuerdo a un estímulo recibido desde el exterior, vía el Actor del caso de uso, es decir, el usuario. Las cosas así, un caso de uso puede derivar en muchos escenarios, docenas, cientos o miles, dependiendo de la complejidad y el tamaño del caso de uso. Esta es la razón principal por la cual no existe el concepto de Pruebas Exhaustivas, porque es inviable probar con anticipación todos y cada uno de los escenarios de un caso de uso. Un escenario es una instancia de un caso de uso, casi de la misma forma como un objeto es una instancia de una clase. Me refiero a que una instancia de un caso de uso es un camino concreto a través del cual la pareja actor-caso de uso es reemplazada por una persona específica (una instancia de un actor), donde valores y respuestas específicos son dados, y solamente un camino simple es tomado a través de uno o más posibles flujos del caso de uso. Los escenarios están descritos de una manera narrativa, incorporan características concretas de los usuarios y de la materia prima que estos entregan al sistema.

Un caso de uso, por su parte, está constituido por secuencias paso a paso de acciones que conforman el comportamiento de un sistema, asociados a un actor específico. Un caso de uso es muy detallado y típicamente incluye actores, una breve descripción, precondiciones, la secuencia principal y las alternativas, y hasta flujos de excepción; también describe el estado del sistema una vez que ha terminado cada secuencia, es decir, las poscondiciones.

A propósito de este mal uso, otra situación que nos está pasando es que nuestros diseños de software carecen de los escenarios de usuario como entrada principal, lo que constituye una falta importante puesto que los escenarios incluyen todos los detalles que los diseñadores requieren entender sobre lo que los usuarios están tratando de hacer y lo que ellos necesitan. Muchos desarrolladores que nunca ha escuchado acerca de un escenario de uso son capaces de adaptar los casos de uso para incluir esta información de usuario, rica y contextual.

Impacto en la calidad: Alto.
Figura 2: Representación Visual de otro escenario de un caso de uso

Obsérvese de las dos figuras que las posibilidades son virtualmente infinitas.

miércoles, septiembre 12, 2012

Casos de Abuso, Parte 5: El caso de uso contiene detalles de formularios (pantallas) y otros aspectos técnicos (bases de datos, componentes, etc.)


Este error es reiterativo y cuando digo eso me refiero a que siempre hago énfasis en que no es así, pero algunos analistas funcionales insisten en hacer exactamente lo contrario.
Un caso de uso especifica lo que debe hacer un sistema de software. No es correcto incluir detalles de la interfaz gráfica resultante, como botones, cuadros de texto, listas de opciones, entre otros, lo mismo que otros mecanismos relativos a los elementos de software con los que se implementará el caso de uso, como referencias a componentes de software, a librerías de acceso a datos, o a tablas u otros objetos de bases de datos. Todo esto hace parte del “como” se implantará el caso de uso en el sistema una vez que esté terminado, son detalles poco entendibles para el usuario final, interesado principal en la especificación del caso de uso y de los requisitos en general.
Recordemos además que un caso de uso detalla la interacción entre el actor y el software, desde el punto de vista del usuario; es decir, al usuario solo le interesa conocer sobre los insumos que tiene que proporcionarle al sistema a través de ese caso de uso y también de los resultados que el sistema le sirve de vuelta, no cómo ese resultado es calculado, encontrado, o procesado al interior del sistema.
Ahora bien, suele ocurrir que algunos usuarios, a fuerza de lidiar durante tantos años con los sistemas, conocen de nombres de tablas y hasta de procedimientos almacenados y son capaces de establecer explícitamente de qué tabla quieren que se tome un dato o cual procedimiento requieren ejecutar en cierto momento. Estos detalles se documentan, pero se formalizan durante la etapa de Análisis y Diseño del caso de uso, cuando este se suplementa.
Los requisitos del software, y con ellos los casos de uso cuando se utilicen como mecanismo de especificación, son independientes de diseño y de implementación.
Impacto en la calidad: Medio.

martes, septiembre 11, 2012

Casos de Abuso, Parte 4: Resumen ejecutivo


Recapitulemos. Tenemos una lista corta de escenarios en donde estamos usando mal los casos de uso como instrumentos para identificar, organizar, documentar y administrar requisitos de software, tanto funcionales como no funcionales.
Estos son los casos enumerados hasta el momento:
Impacto en la calidad: Alto.
Impacto en la calidad: Bajo.
Impacto en la calidad: Medio.
Impacto en la calidad: Medio.
Entonces, ya sabemos que la especificación de requisitos de software (ERS) viene, o puede aparecer, en recipientes de distintos tamaños y diferentes formas y colores: algunos son cacharros escuetos pero con significado y suficiencia para quien los elabora y para los interesados en los mismos, otros son cristalerías sofisticadas que se aproximan a lo mundano, en el sentido de cosmopolita. Pero contienen requisitos de software, al fin y al cabo.
En términos de artefactos de especificación y modelado de sistemas de información, estoy hablando de folios de especificación funcional, con sus requisitos en prosa y todo el detalle aledaño que siempre los acompaña; pero también me refiero a la descripción de procesos del negocio, desde macro-procesos, hasta tareas simples y atómicas, pasando por procesos y subprocesos; representaciones de herramientas visuales como prototipos estáticos y simuladores.
También hago alusión a diagramas de UML, como  diagramas de actividad y de estado, diagramas de procesos, diagramas de contexto y mapas mentales, entre algunos otros; descripción de reglas y políticas del negocio; acuerdos de entendimiento entre los usuarios y el área de tecnología; listas de deseos escritas a mano; y, las más usadas, historias de usuario y casos de uso. Incluso, con las nuevas tecnologías, los requisitos de software bien pueden aparecerse en formato de videos o audios digitales, fotografías de alta definición capturadas por teléfonos inteligentes, mensajes electrónicos y trinos de 140 caracteres o menos.
Usualmente, la ERS se exhibe en una combinación de dos o más de estos instrumentos y lo único que importa es que provenga de las personas apropiadas e interesadas en el producto de software y que cada requisito cumpla o pueda cumplir con algunos atributos o rasgos de calidad:
·         Claridad
·         Atómicidad
·         Precisión
·         Verificabilidad
·         Necesidad u oportunidad
·         Priorización
La ERS, por su parte, debe ser:
·         Independiente de diseño
·         Completa
·         Consistente
·         Rastreable
·         Modificable / Extensible
Ahora ya sabemos cómo corregir algunos de esos defectos. ¿Ustedes qué creen?
Salud@s.

domingo, septiembre 09, 2012

Casos de Abuso, Parte 3: El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración


El modelo iterativo de desarrollo de software dicta que podemos construir el sistema mediante incrementos en períodos de tiempo relativamente cortos y con un objetivo fijo. A estas fases de tiempo se les conoce como Iteraciones y al producto (resultado) de la fase se le conoce como Incremento.
En otras palabras, una iteración es un mini-proyecto con una salida bien definida: una versión incrementada, estable, probada e integrada del producto de software, con su documentación asociada. Pues bien, una de las faltas típicas que cometemos durante el ciclo de vida del software tiene que ver con esto.
Veamos de qué se trata:
Caso de Abuso 4: El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración.
Este es un error muy común al iniciarse en un proceso iterativo. Un caso de uso pasa por varias etapas o períodos durante su ciclo de vida: desde la identificación o descubrimiento del caso de uso, hasta la puesta en ejecución del mismo, pasando por la Ingeniería del Caso de Uso (conocida entre nosotros como la Ingeniería de Requisitos), el Análisis y Diseño, la Implementación, las Pruebas y el Despliegue final.
Y cada una de estas etapas ocurre a través distintas fases del proyecto y de diferentes iteraciones. Durante la fase de inicio o visionamiento del proyecto, descubrimos un número significativo de casos de uso y algunos de ellos pasan a la etapa de Ingeniería de Requisitos; muy pocos de estos casos de uso llegan a la etapa de Análisis y Diseño y ninguno llega a la Implementación.
Más adelante, durante la fase de Planeación o Elaboración del proyecto, los llamados casos de uso arquitectónicos, de los identificados en la fase previa, llegan a las etapas de implementación y pruebas, mientras que otros casos de uso son descubiertos y otros llegan al período de Ingeniería de requisitos.
Durante las siguientes fases del proyecto, algunos pocos casos de uso son identificados, los últimos, y los demás pasan, iteración tras iteración, por las etapas expuestas; pero nunca, un caso de uso se identifica y llega a implementarse en la misma iteración, por muy simple que sea. Eso sería apenas una simple coincidencia y, casi siempre, un error.
Muy relacionado con este abuso está el abuso No. 12, aunque hay diferencias fundamentales entre aquel y este. (Lo veremos en su momento)
Impacto en la calidad: Medio.

miércoles, septiembre 05, 2012

Casos de Abuso, Parte 2: El caso de uso es la única documentación necesaria para construir el software


Abusar.
(De abuso).
1. intr. Usar mal, excesiva, injusta, impropia o indebidamente de algo o de alguien. Abusaba DE su autoridad.
Real Academia Española © Todos los derechos reservados
Caso de Abuso 3: El caso de uso es la única documentación necesaria para construir el software.
Quizás esta idea surge de la premisa de que el proceso de desarrollo de software es dirigido por casos de uso [1], que es algo mucho más amplio y totalmente distinto. Además, está el factor tiempo que siempre hace falta en los proyectos de desarrollo de software.
Un caso de uso es el primer repositorio de documentación en un proyecto, puesto que es el artefacto que legitima los requisitos funcionales del software. Sin embargo, después del caso de uso y antes del código fuente hay un abismo sobre el que debemos construir un puente para ir desde la solicitud del usuario, su problema y sus necesidades, hasta un sistema de software que soporte su proceso, que resuelva su problema y cubra sus necesidades.
Ahora bien, hay casos de casos: están los llamados casos de uso arquitectónicos o más complejos, que bien podrían representar alrededor del 20% del total de casos de uso de un proyecto. A estos casos de uso debemos aplicarles rigurosamente el proceso: Análisis, Diseño, Implementación, Pruebas, Despliegue y vuelta a empezar. Y durante el Análisis y el Diseño se construyen una serie de artefactos que van desde documentos anexos hasta diagramas (de UML) de casos de uso, de secuencia, de comunicación, de clases, de estados, de actividad y de entidad-relación, entre otros. También están los requisitos no funcionales o especiales que aplican a cada uno de esos casos de uso, el pseudocódigo y los prototipos; asimismo, están los casos y procedimientos de prueba.
Es principalmente durante el período de Análisis y Diseño del caso de uso cuando ocurre la suplementación del mismo, es decir, la adición de detalles técnicos y no funcionales al caso de uso. Y en todas estas actividades intervienen todos los miembros del equipo del proyecto: unos elaboran y presentan, otros retroalimentan, complementan, realizan el siguiente paso y también lo presentan, y así, en una espiral en la que el producto se va gestando hasta quedar terminado.
Luego están los demás casos de uso del proyecto, el otro 80%. Unos son más complejos que otros desde el punto de vista de diseño, mientras que algunos son más críticos que otros desde la perspectiva del usuario. Muchos de estos casos de uso, sino todos, también deben someterse al mismo proceso que los anteriores. Lo que varía es la severidad o formalidad con que se elaboren todos esos artefactos.
Dependiendo del tipo de proyecto, de los aspectos legales del mismo y de otras variables del entorno, será necesario realizar cada documento siguiendo plantillas formales del proceso de desarrollo, casi con rigurosidad científica: diagramas de UML bien construidos y detallados, tantos como sean necesarios para entender el producto, documentos sujetos al escrutinio de revisiones técnicas y de estilo, con listas de chequeo formales y con todas las excepciones consideradas. Algunos casos de uso requerirán de tres, cinco o más diagramas de interacción, por ejemplo; otros necesitarán sólo uno de estos diagramas.
En otros proyectos, menos formales desde el punto de vista legal (aunque es difícil imaginar tal cosa), será suficiente con que estos artefactos se elaboren en reuniones de análisis y diseño en un tablero donde todo el equipo de desarrollo pueda verlos, opinar, tomar nota y entenderlos, que es el objetivo último del modelado.
La categoría de las herramientas a usar también depende de la complejidad técnica y de la formalidad legal: para unos proyectos basta lápiz y papel, o tiza y tablero, mientras que para otros serán necesarias herramientas sofisticadas de Ingeniería de Software.
En cualquier caso, nunca hay que perder de vista que el software, por naturaleza, es complejo; y que construir software, por naturaleza, es una actividad compleja. También, que las herramientas con las que se construye software (que casualmente están hechas de software) también son complejas. Y con este nivel de complejidad, no es posible que algo simple, como el caso de uso, sea capaz de resolver nuestro problema sin más colaboración.
Impacto en la calidad: Alto.
Referencias
[1]   Luis Antonio Salazar Caraballo, “RUP: Fase de Concepción”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2007/03/lecturas-fundamentales-8.html, 08 mar. 2007.
La Parte 1 de este análisis lo encuentras en: http://gazafatonarioit.blogspot.com/2012/09/casos-de-abuso-parte-1.html
Sobre abecés, anatomía y prácticas de casos de uso y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en este mismo Gazafatonario IT.

martes, septiembre 04, 2012

Casos de Abuso, Parte 1: El caso de uso se usa en todos los casos


La segunda ley de la Ingeniería del Software o el modelo Información-Materia-Energía (IME) establece que el mundo natural que forma el contexto de la inteligencia humana y la ciencia del software es una dualidad: un aspecto de ésta es el mundo físico y el otro es el mundo abstracto, donde la materia y la energía son usadas para modelar el primero, y la información, para modelar el segundo. Los modelos del mundo físico han sido bien estudiados por la Física y otras ciencias naturales. Sin embargo, el modelado del mundo abstracto todavía es un problema fundamental a ser explorado por la ingeniería del software.
Ahora bien, aunque el mundo físico es el mismo para todas las personas, el mundo natural es percibido de forma diferente por distintos individuos debido a que el mundo abstracto, como parte de éste, es subjetivo dependiendo de la información que los individuos obtienen y perciben. Y es debido a esta diversidad en la percepción del mundo abstracto que se presentan los errores en la ingeniería del software y por ello es que son más comunes de lo que a veces queremos. En el ciclo de vida de la ingeniería del software, esos errores empiezan durante la identificación, especificación y modelado de casos de uso.
Algunas de estas falencias, son las que empezaré a presentar a partir de hoy en varias entregas. Se trata de un estudio de los malos usos de los casos de uso.
Este es realmente un estudio patológico y forense: es patológico porque hago un estudio de los desórdenes más comunes encontrados durante mis continuas revisiones de casos de uso a todo lo largo de su ciclo de vida: identificación, especificación, análisis, diseño, implementación y pruebas. Quise hacer este estudio en un sentido amplio, es decir, observé estas alteraciones como procesos o estados anómalos de raíces conocidas o ignoradas. También es patológico porque extraje las pruebas que señalan la presencia de tales afecciones del examen minucioso de cada error en todos sus niveles estructurales, desde el nombre del caso de uso, hasta las secuencias básica y las alternativas del mismo, pasando por la breve descripción, las pre y poscondiciones, el actor y los requisitos especiales, entre otros aspectos. Desde este punto de vista me convertí en un anatomopatólogo o, simplemente, en un patólogo clínico de los casos de uso, si es posible trasladar ese término médico a nuestro entorno.
Es forense porque estudié los aspectos técnicos derivados de la práctica diaria de los equipos de desarrollo de software, en los que he participado centenares de veces, como sujeto activo y como perito. Bajo este último título he tratado de contribuir con mi actuación a dar valor y significación genuinos a los aciertos hechos en materia de especificación y evolución de casos de uso y también a la promoción de ciertas prácticas que creo exitosas en la industria. En particular, he tenido la oportunidad de examinar y recoger indicadores de casos de uso propios y de extraños (colegas, clientes, socios de negocio); de los modelos y especificaciones de casos de uso he determinado los elementos donde se presentan los errores, las posibles causas de los mismos y he presentado posibles soluciones.
Caso de Abuso 1: El caso de uso se usa en todos los casos.
Es un juego de palabras pero es falso. Los casos de uso son un repositorio, un mecanismo de comunicación durante el ciclo de vida de desarrollo del software. Contienen y transmiten requisitos y otros aspectos relacionados con la funcionalidad del software en construcción.
Pero hay muchas maneras de documentar todo esto: documentos de requisitos funcionales y no funcionales donde, en prosa, se especifican los detalles del producto. En otros casos se pueden usar prototipos, como en los reportes ad-hoc o estándares, donde preparar un documento en el que se muestre como lucirá un reporte es más práctico que escribir en palabras los detalles del mismo. En otros casos, serán necesarios uno o más diagramas de UML (de estados o de actividad, por ejemplo), como cuando la descripción en prosa del proceso funcional es engorrosa debido a la complejidad del proceso y, además, un prototipo no es suficiente o no aplica.
Impacto en la calidad: Bajo.
Caso de Abuso 2: Lo que no está documentado en los casos de uso no hace parte del proyecto.
Esta es una consecuencia del abuso anterior. En muchas ocasiones usamos sólo los requisitos que están consignados en casos de uso para realizar la estimación del proyecto, para considerar tiempos y recursos, para definir la arquitectura del software y para diseñar el sistema. Sólo cuando ya es muy tarde alguien recuerda que hay otras funcionalidades a diseñar e implementar y que posiblemente afecten no sólo la arquitectura del sistema, sino también los tiempos y los recursos necesarios para terminar el producto. Un caso típico ocurre cuando el producto tiene muchos procesos batch, de esos que se ejecutan por la noche o al cierre de un período específico y que hacen uso intensivo de datos sin ninguna interfaz gráfica. Otro caso se presenta con las consultas y reportes, muchas veces menoscabados, en el sentido de reducidos, por todos los involucrados en el proyecto.
Impacto en la calidad: Medio.

viernes, julio 20, 2012

Ventajas y Desventajas del Uso de Prototipos


Algunas Ventajas del uso de prototipos

1.       Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.
2.       Como información complementaria a los requisitos constituyen un gran apoyo a las estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.
3.       Son más fáciles de abordar con los usuarios finales.
4.       El usuario participa más activamente en la construcción del producto de software (La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo,  “utilizar” desde el primer momento.
5.       Se reduce el riesgo o la incertidumbre sobre la implementación del software.
6.       Su uso redunda en una mayor satisfacción del usuario con el producto final, ya que él o ella han participado activamente de su diseño.
7.       Proporciona al usuario un mayor conocimiento del sistema con una curva menor de aprendizaje.
8.       Permite a todos los involucrados entender bien y mejor el problema antes de la implementación final.

Algunas Desventajas del uso de prototipos

1.       El usuario quiere empezar a trabajar desde el primer momento con el prototipo para solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el producto.
2.       Los prototipos generan o pueden generar otro tipo de problemas si su presentación y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar inconformes luego de verlos por primera vez. También es posible que se pierda mucho tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los prototipos.
3.       Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y mucho más involucramiento si queremos que participe en su creación.
4.       Una desventaja importante a tener en cuenta es la falta de experiencia que tienen muchos Analistas Funcionales en programación y en actividades de diseño de interfaces de usuario.

Revisar/Aprobar Prototipos en Vez de Requisitos/Casos de Uso

Los prototipos son una herramienta suplementaria a la especificación de requisitos (funcionales). Con esto en mente, es posible que los usuarios revisen y aprueben estos prototipos durante la fase inicial del proyecto. Más adelante, el usuario puede confirmar su grado de satisfacción por los prototipos, más cercanos al producto final.
La otra parte de la tarea, aunque igualmente importante, es que entonces será el Analista Funcional el encargado de verificar que la descripción de los prototipos corresponda a la especificación de los requisitos en su totalidad. Las cosas así, es evidente que se incrementa el esfuerzo de los Analistas, sobre todo en la etapa de Visión y Alcance del proyecto. No obstante, el proceso de construcción de software puede mejorarse con la inclusión de guías para la elaboración de prototipos en las distintas plataformas.

Recomendación para implantar el uso de prototipos en un proceso de software

Como siempre, la recomendación es realizar algunos pilotos controlados donde pongamos en práctica el uso de prototipos en distintos proyectos, donde podamos medir y analizar los resultados con el fin de tener mejores herramientas para tomar la decisión, no solo de incluir los prototipos como una práctica común y hasta obligatoria durante el ciclo de vida, sino para que estos sean revisados/aprobados por los usuarios, en vez de los requisitos y casos de uso.