Entradas etiquetadas como desarrollo

Líneas Base

Una línea base es el compromiso, negociado y aceptado, que se alcanza con el cliente para que este comprenda que hemos de poner un alto en la captación de necesidades con miras a enfocarnos por unos días, en construir aquello nos ha pedido hasta el día de hoy.

Como estrategia de organización del proyecto, su principal virtud es la de permitir la gestión de requerimientos, al introducir pausas regulares en las exigencias del cliente, con miras a ver primero el logro de las primeras ideas, antes de introducir nuevas variaciones.

Al contar con las líneas base como estrategia de gestión de requisitos, es posible disminuir el riesgo que representan para los proyectos las especificaciones incompletas: simplemente no vamos a aspirar a tener todas las cartas en la mano, vamos a trabajar con lo que tenemos hasta un punto y luego, alcanzados los primeros objetivos, volver a recoger lo que se nos haya escapado la primera vez.

Por lo mismo, es posible también reducir el riesgo de desorden en los requisitos del proyecto. Hay una disciplina en el equipo del trabajo, que se le puede explicar al cliente. Dicho de otra forma, es una forma educada de pedirle paciencia.

Anuncios

, , , , , , , ,

Deja un comentario

Casos de Uso: Flujos de Eventos

Un caso de uso es un escenario de interacción entre el sistema y un ente externo; es decir: es la descripción de una funcionalidad del sistema, visto desde el punto de vista de un ente externo que demanda dicha funcionalidad.

Al ente externo le llamamos actor por cuanto un caso de uso puede ser visto también como un guión, que a la manera de los guiones de una obra de teatro, dice paso a paso lo que el actor ha de hacer.

Es mucho lo que podemos decir de un caso de uso: nombre, descripción, pre condiciones, etc. Sin embargo, el aspecto más interesante de un caso de uso luego de la descripción del mismo es sin duda el flujo de eventos.

Al flujo de eventos lo podemos relacionar con un dialogo. Línea a línea, el flujo de eventos indica quien habla y qué dice. La secuencia se suele iniciar con algo dicho por el actor, y se continua intercalando sucesivamente lo hecho por el sistema con lo dicho por el actor. A cada una de estas líneas o indicaciones, le podemos llamar paso.

Un buen flujo de eventos recoge con detalle la identidad de quien realiza el paso, expresando sin ambigüedad la acción realizada. Es decir, que un buen paso ha de ser siempre una oración con sentido completo, escrita en voz activa, iniciando con el nombre del actor o bien del sistema que realiza la acción e indicando exhaustivamente los elementos de información que se intercambian.

Dichas oraciones con sentido completo, sin ambigüedad y demás características ya mencionadas, no son difíciles de redactar. Son de hecho la forma más directa de decir lo que hay que decir. Y es que a la hora de redactar un flujo de eventos debemos evitar recurrir a formas de redacción en prosa típicas de nuestros textos comunes. No vale sustituir el nombre del actor por un pronombre o demostrativo que le haga referencia. A la larga, dicha omisión del nombre del actor va a ser una fuente de ambigüedad y nos puede traer problemas.

Si bien para quienes acostumbran a redactar con estilo, estas normas para los flujos de eventos pueden sonar extrañas, son normas muy comunes para cuando queremos redactar documentos de requisitos. Básicamente estamos aplicando aquí los mismos consejos que se dan para redactar bien un requisito tradicional, del estilo “el sistema debe…” por lo que en Internet abundan los detalles sobre este particular.

Finalmente, la prosa tiene su refugio en la descripción breve de un caso de uso; y dado que es esta descripción breve la parte más importante del caso de uso, podemos decir que a la final todos vamos a poder estar contentos. Quienes quieren una redacción con estilo van a encontrar lo que buscan en la descripción breve y quienes necesitan los detalles operativos del caso de uso lo van a encontrar en los pasos del flujo de eventos.

, , , , , , , , ,

5 comentarios

¿Qué son las llamadas Mejores Prácticas?

Las mejores prácticas son características reconocibles de los procesos de las organizaciones de éxito. Suelen ser conductas observables, llenas de sentido común; que al estar presentes en las mejores empresas de cada sector, se piensa que son parte del éxito de dichas empresas. Por supuesto, se piensa también que de asumirse, toda empresa se puede beneficiar, por lo que la predica en pos de las mejores prácticas es parte importante de la planificación a largo plazo de las organizaciones que desean mejorar y crecer.

A nivel personal, podemos establecer un símil con los consejos más comunes sobre como llevar una vida sana y exitosa. Consejos tales como “pensar antes de actual” o bien el elemental “dormir lo suficiente cada noche” son el equivalente de las mejores prácticas, aplicadas a como conducir la propia vida.

En el caso de las empresas, se confía en los institutos de investigación de cada sector, quienes identifican sistemáticamente las prácticas en uso, con el objetivo de publicar catálogos de mejores prácticas, que sean apropiadas para el sector industrial que se este considerando. Dichos catálogos suelen ser de acceso libre y son conocidos bajo diferentes denominaciones, como si se estuviera hablando de cosas diferentes en cada sector. Pero no hay confusión que valga: para todo sector valen distintas mejores prácticas, pero llámense como se quieran llamar, todas son mejores prácticas y poco más.

Cuando se esta diseñando un proceso empresarial, es útil considerar las mejores prácticas conocidas del sector o actividad en la que el proceso vive. Dado que existen gran cantidad de sectores, el analista de procesos puede beneficiarse de conocer que se considera como una buena idea, dando entonces una base sistemática para identificar objetivos de diseño para los procesos, más allá de cubrir las necesidades inmediatas demandadas por los clientes.

He de hacer notar también, que muchas de las mejores prácticas pueden ser apoyadas por sistemas de información apropiados; o dicho de otra forma, que hoy en día existen gran cantidad de sistemas de información, muchos de ellos construidos para dar cumplimiento a una o más de las mejores prácticas de sector destino del sistema.

Así que el asunto de las prácticas conviene tenerlo en mente.

, , , , , , , ,

Deja un comentario

Casos de Uso Avanzados: Relación de Inclusión

El modelado de casos de uso persigue capturar la funcionalidad del sistema visto desde el punto de vista de sus operadores –actores– por lo que es fundamentalmente una construcción de elementos de modelado comprensibles por los clientes –stakeholders– y no solo por los analistas.

Sin embargo, en ocasiones es conveniente introducir algunos pocos elementos que no sean directamente los conceptos que manejan los clientes. Por ejemplo, en aras de evitar la redundancia, es posible pensar en extraer algunos fragmentos que nos permita indicar en uno o más casos de uso este fragmento repetido, por referencia en lugar de repetirlo en cada caso.

A este proceso de extracción del fragmento repetido lo modelamos por medio de la relación de inclusión <<include>>, tal como se ve en el siguiente diagrama:

Fig. 1 – Relación de inclusión entre casos de uso

En la figura, el caso de uso “A” es un fragmento, que define un trozo de un flujo de eventos que es referido por el caso de uso “B”. En este tipo de relación, el caso incluido (el “A”) debe ser un fragmento, nunca un caso concreto, en tanto que el caso que incluye (el “B” del ejemplo) si ha de ser un caso de uso completo.

A diferencia de la relación de extensión, aquí ninguno de los casos de uso involucrados puede ser entendidos por completo como piezas aisladas. Por un lado, el caso incluido es solo un fragmento, por lo que no es posible considerarlo un caso de uso pleno; en tanto que el caso que incluye al hacer referencia a un fragmento externo tiene necesariamente que ser entendido en presencia del fragmento.

Formalmente, como para el glosario:

Relación de Inclusión <<include>> Un caso de uso concreto incluye a un fragmento de caso de uso, cuando como parte de su descripción breve o su flujo de eventos, se hace referencia al texto del fragmento; de forma tal que lo dicho en el fragmento pasa a ser parte de la especificación del caso de uso.

Para lograr que se entienda el concepto, nada mejor que un ejemplo. Supongamos que estamos hablando de un sistema de gestión de agenda de un empresas con gerentes y asistentes. En este sistema hemos identificado dos casos de uso:

Código: UC-0100.
Nombre: Acepta cita.
Actor: Gerente.
Descripción: El Gerente visualiza su calendario de citas y aprueba aquellas citas que desee aceptar.

Código: UC-0200.
Nombre: Coordina cita.
Actor: Asistente.
Descripción: El asistente busca un momento apropiado para las citas pendientes al visualizar el calendario de citas del Gerente. Indica para cada cita propuesta la descripción, el día y la hora.

Tabla 1 – Casos de uso del sistema

Como se nota, en ambos casos se requiere de visualizar la agenda. Es posible imaginar que esta función abarca no solo la visualización del calendario, sino también ciertas funciones de búsqueda y filtrado por criterios. Para especificar esta funcionalidad pero evitar hacerlo en cada uno de los flujos de eventos de los casos de uso ya definidos, se opta por crear un fragmento que contenta esos detalles e incluirlo en los casos de uso originales. La situación da lugar al siguiente diagrama:

Fig. 2 – Modelo de casos de uso con un
ejemplo de relación de inclusión

De esta forma, evitamos tener que definir en múltiples lugares una misma funcionalidad. Sin embargo, el fragmento que se incluye ha de ser visto siempre como lo que es: un fragmento sin significado completo. En verdad es una lastima que de momento no tengamos una forma de marcar a los fragmentos de manera que se diferencien a simple vista de los casos de uso. Sugiero que al menos, en tanto surge un estereotipo estándar para esta tarea, tengamos una serie de numeración particular para los fragmentos. O bien, tomar la iniciativa y definir un estereotipo de UML por nosotros mismos.

Naturalmente que a la hora de hacer la especificación detallada de los casos de uso, en particular en los flujos de eventos, debemos marcar muy claramente en que lugar se ha de realizar la inclusión de lo dicho en el fragmento.

La relación de inclusión es claramente diferente a la relación de extensión y espero que haya quedado claro. La inclusión es una relación entre un caso de uso concreto y un fragmento, en tanto que la extensión involucra casos de uso concretos.

Por otra parte, a diferencia de la relación de extensión, la inclusión en cierta forma modifica al caso que incluye, por cuanto el fragmento define una parte de la funcionalidad del caso de uso completo. Esto significa que el caso de uso que incluye no puede ser entendido por completo en ausencia del fragmento que se incluye; algo muy diferente a la situación en una relación de extensión.

, , , , , , , , , , , , ,

30 comentarios

Casos de Uso Avanzados: Relación de Extensión

En muchas ocasiones el uso de características avanzadas de los casos de uso generan dudas en los equipos de desarrollo. La razón básica es que estos modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el uso de las relaciones de inclusión y extensión, entre otras características.

Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad y sencillez, existen situaciones en que hacer uso de una relación avanzada entre casos de uso mejora en lugar de reducir, la claridad del modelo de requisitos. De ahí por tanto que todo analista de requisitos debe comprender perfectamente el significado de estas relaciones. En el presente post abordamos la relación de extensión <<extend>>.

Técnicamente como para el glosario, la relación de extensión <<extend>> se define como:

Relación <<extend>> Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero. Se denota con una relación que apunta del caso extendido al caso base y la conexión se hace o bien al principio del flujo de eventos principal del caso base o en alguno de los puntos de extensión que este haya definido.

La notación gráfica es la siguiente:

Fig. 1 – Relación de extensión <<extend>>

La relación del ejemplo significa que un caso de uso ya existente (el caso “A”) se aprovecha en la definición de un segundo caso (el caso “B”). Dado que la reutilización que requerimos agrega funcionalidad pero no altera al caso base, se ha optado por la relación de extensión. Dicha relación se ha denotado gráficamente con una flecha de dependencia desde el caso extendido (el caso “B”) al caso base (el caso “A”). La dependencia la hemos estereotipado con <<extend>> para que quede claro lo que pretendemos decir.

A nivel de los flujos de eventos, se podría decir que el flujo principal del caso base no se ve alterado, pero que en cambio, el flujo de eventos del caso extendido hace referencia al primero, de manera tal que no puede ser entendido en ausencia de los pasos del caso base.

A fin de contar con un ejemplo completo, consideremos un sistema de compras electrónico. Digamos que este sistema va a atender tanto a clientes finales como a clientes corporativos, permitiendo que adquieran productos en nuestra tienda en línea. La diferencia será que los clientes corporativos hacen compras masivas, quizás programando la entrega a lo largo de un periodo de tiempo de lo que compraron. Esta visión la podemos expresar en el siguiente diagrama:

Fig. 2 – Ejemplo de relación <<extend>> en un sistema
de tienda electrónica en Internet

Ahora si vamos al caso de uso base “Compra artículo (UC-0100)” podríamos tener la funcionalidad de escoger el artículo a comprar y el de pagar con tarjeta de crédito, por ejemplo. Esta funcionalidad esta disponible a los clientes finales, tal como se ve en el diagrama.

Por su parte, los clientes corporativos pueden escoger el artículo a comprar y el modo de pago: digamos tarjetas de crédito. Además el caso de uso captura también la funcionalidad de programar la entrega parcial de lo comprado a lo largo de un periodo de tiempo. Dado que gran parte del caso de uso “Compra masiva (UC-0200)” es idéntica a la encontrada en el caso del cliente final, optamos por reutilizar la especificación por vía de la relación de extensión.

Los criterios a aplicar para saber si la relación de extensión es aplicable son los siguientes:

  1. Hay cuando menos un caso base y un caso extendido.
  2. El caso base no se ve modificado por la existencia del caso extendido.
  3. El caso base es un caso concreto atado a cuando menos un actor.
  4. El caso extendido incorpora al caso base por completo.

La relación de extensión guarda relación con todos los restantes tipos de reutilización que están definidas para los casos de uso; en particular la relación es muy intima con la relación de inclusión <<include>> sin embargo la diferencia primordial entre <<extend>> e <<include>> es la modificación del caso base. Extensión no implica cambio, en tanto que la inclusión añade funcionalidad al caso base.

Otra relación, la herencia, es similar también a la extensión. En este caso la diferencia es que la herencia cambia o puede cambiar, la naturaleza de lo dicho en el caso base. Por ejemplo, podemos decir que aquello que fue llamado “artículo” en el caso base es ahora referido más detalladamente como “libro” o “juguete”. La herencia de casos de uso reutiliza al caso base sí, pero nos permite alterar la semántica de los detalles; algo que la relación de extensión (ni la de inclusión) pueden hacer.

Por tanto concluyamos: la relación de extensión permite reutilizar una especificación pero sin modificar al caso base.

, , , , , , , , , , , , ,

32 comentarios