Cap. 4 Inicio
La mayoría de los proyectos requieren una etapa inicial breve en la que se estudian las siguientes preguntas:
* Cuál es la visión y el análisis del negocio para este proyecto?
* Es viable?
* Comprar y/o construir?
* Estimación aproximada del coste:
* Deberíamos abordarlo o no seguir?
El objetivo de la etapa de inicio no es definir todos los requisitos, o generar una estimación creíble o plan de proyecto. Aún a riesgo de simplificar demasiado, la idea es hacer la investigación justa para informar una opinión racional y justificable del propósito global y la viabilidad del nuevo sistema potencial, y decidir si merece la pena invertir en un estudio más profundo (el objetivo de la fase de elaboración).
La fase de inicio en una frase:
Vislumbrar el alcance del producto, visión y análisis del negocio.
El principal problema resuelto en una frase:
¿Está de acuerdo el personal involucrado en la visión del proyecto, y merece la pena invertir en un estudio serio?
Inicio: una analogía
En el negocio petrolero, cuando se está considerando una nueva zona, algunos de los pasos que hay que abordar son:
1.- Decidir si hay evidencias suficientes o un análisis del negocio que justifique perforaciones de exploración.
2.- De ser así, llevar a cabo medidas y perforaciones de exploración.
3.- Proporcionar información del alcance y estimación.
4.- Pasos adicionales...
La fase de inicio es como el primer paso en esta analogía. En el primer paso, no se predice cuánto petróleo hay, o el coste o esfuerzo para extraerlo. Es prematuro ( no hay suficiente información).
En términos del UP, el paso de exploración realista se corresponde con la fase de elaboración. La fase de inicio que la precede es parecida a un estudio de viabilidad para decidir si incluso merece la pena invertir en perforaciones de exploración. Por lo tanto, en el desarrollo iterativo y el UP, los planes y estimaciones de la fase de inicio no deben considerarse fiables. Simplemente proporcionan una percepción del orden de la magnitud del grado de esfuerzo, para ayudar en la decisión de continuar o no.
La fase de inicio podría ser muy breve
El propósito de la fase de inicio es establecer una visión inicial de los objetivos del proyecto, determinar si es viable y decidir si merece la pena llevar a cabo algunas investigaciones serias en la fase de elaboración. Si esta decidido de antemano que el proyecto se hará sin ninguna duda, y es claramente viable (quizás porque el equipo ha desarrollado proyectos parecidos antes), entonces la fase de inicio será especialmente breve. Podría incluir los primeros talleres de requisitos, planificación de la primera iteración y, entonces, rápidamente, cambiar a la elaboración.
¿Qué artefactos podrían crearse en la fase de inicio?
Una idea clave con respecto al desarrollo iterativo es comprender que estos artefactos sólo se completan parcialmente en esta fase, se refinarán en iteraciones posteriores, e incluso no deberían crearse a menos que se considere probable que añadirán valor práctico real.
Por ejemplo, el Modelo de Casos de Uso podría listar los nombres de la mayoría de los casos de uso y actores esperados, pero quizás sólo describiría en detalle el 10% de los casos de uso -hecho con el pro-pósito de desarrollar una visión de alto nivel y sin detalles del alcance, objetivo y riesgos del sistema.
Nótese que en la fase de inicio se podrían realizar algunas tareas de programación con el objeto de crear prototipos de "pruebas de conceptos", para clarificar unos pocos requisitos mediante (generalmente) prototipos orientados a la interfaz de usuario, hacer experimentos de programación para cuestiones técnicas críticas.
¿No es eso mucha documentación?
Hay que recordar que los artefactos se deberían considerar opcionales. Se debe elegir sólo aquellos que realmente añadan valor al proyecto, y desecharlos si no se aprueba que merezcan la pena.
Lo importante de un artefacto no es el documento o el diagrama es sí mismo, sino el pensamiento, análisis y disposición activa (y entonces se registra, para evitar re-inventar o tener que repetir las cosas de palabra).
##Es recomendable almacenar digitalmente los artefactos en lugar de papel ##
Obsérvese también que los artefactos UP de los proyectos anteriores se pueden utilizar en otros posteriores. Es normal que haya muchas similitudes entre proyectos en cuanto a los artefactos de riesgos, gestión del proyecto, pruebas y entorno. Todos los proyectos UP organizarán los artefactos de la misma manera, con los mismos nombres (Lista de Riesgos, Marco de Desarrollo, etc)
No se entendió el inicio cuando...
........
--------------------------------------------------------------------------------------------------------------------------
Cap. 5 Comprensión de Requisitos
Los requisitos son capacidades y condiciones con las cuales debe ser conforme el sistema, y más ampliamente el proyecto. El primer reto del trabajo de los requisitos es encontrar, comunicar, y recordar (que normalmente significa registrar) lo que se necesita realmente, de manera que tenga un significado claro para el cliente y los miembros del equipo de desarrollo.
El UP fomenta un conjunto de buenas prácticas, una de las cuales es la gestión de requisitos. "Un enfoque sistemático para encontrar, documentar, organizar y seguir la pista de los requisitos cambiantes del sistema" ; en concreto, haciéndolo con destreza y sin ser descuidado. Fíjese en la palabra cambiantes; el UP acepta el cambio en los requisitos como un motor fundamental del proyecto. Otro término importante es encontrar, es decir, extraer cuidadosamente mediante técnicas tales como escritura de casos de uso y talleres de requisitos.
Como se indica en la figura siguiente, un estudio sobre los costes reales en diferentes empresas reveló que el 37% de ellos estaban relacionados con los requisitos, de manera que las cuestiones de requisitos constituyen la principal causa de problemas... La respuesta iterativa es utilizar un proceso que acepte el cambio y la retroalimentación como motores centrales en el descubrimiento de los requisitos.
Tipos de requisitos
En el UP, los requisitos se clasifican de acuerdo con el modelo FURPS+, un nemotécnico que significa los siguientes tipos de requisitos:
* (Functional) Funcional: características, capacidades y seguridad.
* (Usability) Facilidad de uso: factores humanos, ayuda, documentación.
* (Realiability) Fiabilidad: frecuencia de fallos, capacidad de recuperación de un fallo y grado de previsión.
* (Performance) Rendimiento: tiempos de respuesta, productividad, precisión, disponibilidad, uso de recursos.
*(Supportability) Soporte: adaptabilidad, facilidad de mantenimiento, internacionalización, configurabilidad.
El "+" en FURPS+ indica requisitos adicionales, tales como:
* Implementación: limitación de recursos, lenguajes y herramientas, hardware...
* Interfaz: restricciones impuestas para la interacción con sistemas externos.
* Operaciones: gestión del sistema en su puesta en marcha. <------- (no sé qué esto)
* Empaquetamiento: <------- (definir esto)
* Legales: licencias, etc.
Algunos de estos requisitos se denominan colectivamente atributos de calidad, requisitos de calidad, o las "-ilities" de un sistema. Éstos comprenden: facilidad de uso (usability), fiabilidad (reliability), rendimiento (performance) y soporte (supportability). Lo normal es dividir los requisitos en funcionales (comportamiento) y no funcionales (todos los demás); a algunos no les gusta esta amplia generalización, pero se utiliza de manera muy extendida.
Los requisitos funcionales se estudian y recogen en el Modelo de Casos de Uso y en la lista de características del sistema del artefacto Visión. Los otros requisitos se pueden recoger en los casos de usos con los que están realcionados, o en el artefacto Especificación Complementaria. El artefacto Visión resume los requisitos de alto nivel que se elaboran en estos otros documentos. El Glosario agrupa y clarifica los términos que se utilizan en los requisitos. El Glosario en el UP también comprende el concepto de diccionario de datos, que reúne los requisitos relacionados con los datos, como reglas de validación, valores aceptables, etc. Los prototipos son un mecanismo para clarificar qué es lo que se quiere o es posible.
Como veremos cuando estudiemos el análisis arquitectural, los requisitos de calidad influyen fuertemente en la arquitectura de un sistema. Por ejemplo, un requisito de alto rendimiento y alta fiabilidad influirá en la elección de componentes software y hardware, y en sus configuraciones. La necesidades de fácil adaptación , debido a cambios frecuentes en los requisitos funcionales, igualmente dará forma al diseño del software.
Lecturas adicionales
Textos orientados a los casos de uso, como Writting Effective Use Cases, Cockburn
Acerca de requisitos, Cuerpo de Conocimientos en Ingeniería del Software (SWEBOK, Software Engineering Body of Knowledge) disponible en www.swebok.org
El SEI (www.sei.cmu.edu) tiene varias propuestas relacionadas con los requisitos de calidad. ISO e IEEE
Algunas advertencias con respecto a los libros generales sobre requisitos y casos de uso no enfocados en UP, e inclusive enfocados en UP.
1. La mayoría están escritos bajo la influencia de un ciclo de vida en cascada planteando la definición "precisa" de los requisitos por adelantado, antes de pasar al diseño y la implementación.
2. ... la idea principal de los casos de uso, tal y como la concibe Ivar Jacobson y el UP, es hacer los casos de uso el elemento central del enfoque de requisitos global (sustituyendo a otros documentos de requisitos como elemento central); los casos de uso impregnan y dirigen el trabajo de requisitos, en lugar de considerarse como una técnica de apoyo auxiliar a nivel inferior o medio, añadida a los documentos o enfoques de requisitos tradicionales.
--------------------------------------------------------------------------------------------------------------------------
Cap. 6 Modelo de casos de uso: escritura de requisitos en contexto
La escritura de casos de uso (historias de uso de un sistema) es una técnica excelente para entender y describir los requisitos.
El UP define el Modelo de Casos de Uso en la disciplina Requisitos. Básicamente, es el conjunto de todos los casos de uso; es un modelo de la funcionalidad y entorno del sistema.
Los clientes y los usuarios finales tienen objetivos (también conocidos como necesidades) y quieren sistemas informáticos que les ayuden a conseguirlos.
Los casos de uso son un mecanismo son un mecanismo para ayudar a mantenerlo simple y entendible para todo el personal involucrado. De manera informal, son historias del uso de un sistema para alcanzar objetivos. A continuación presentamos un ejemplo de caso de uso en formato breve:
p. 44
Procesar Venta: Un cliente llega a una caja con artículos para comprar. El cajero utiliza el sistema PDV para registrar cada artículo comprado. El sistema presenta una suma parcial y detalles de cada línea de venta. El cliente introduce los datos del pago, que el sistema valida y registra. El sistema actualiza el inventario. El cliente recibe un recibo del sistema y luego se va con los artículos.
Antecedentes
...
p. 45
Casos de uso y valor añadido
En primer lugar, algunas definciones informales: un actor es algo con comportamiento, como una persona (identificada por un rol), sistema informatizado u organización; por ejemplo un cajero.
Un escenario es una secuencia específica de acciones e interacciones entre actores y el sistema objeto de estudio; también se denomina instancia de caso de uso. Es una historia particular del uso de un sistema, o camino a través del caso de uso; por ejemplo, el escenario de éxito de compra de artículos con pago en efectivo, o el escenario de fallo al comprar debido al rechazo de la transacción de pago con la tarjeta de crédito.
Informalmente entonces, un caso de uso es una colección de escenarios con éxito y fallo relacionados, que describe a los actores utilizando un sistema para satisfacer un objetivo. Por ejemplo, a continuación presentamos un caso de uso en formato informal que incluye algunos escenarios alternativos.
Un conjunto de instancias de casos de uso, donde cada instancia es una secuencia de acciones que se un sistema ejecuta, produciendo un resultado observable de valor para un actor particular [RUP]
La expresión "un resultado observable de valor" es sutil pero importante, porque destaca el hecho de que el comportamiento del sistema debería preocuparse de proporcionar valor al usuario.
NOTA: una actitud clave en el trabajo con casos de uso es centrarse en la pregunta: ¿Cómo puedo, utilizando el sistema, proporcionar un valor observable al usuario, o cumplir sus objetivos? en lugar de simplemente, pensar en los requisitos del sistema en términos de una "lista de lavandería" de características o funciones. <------no entiendo esto!!!!
Casos de uso y requisitos funcionales
Los casos de uso son requisitos; ante todo son requisitos funcionales que indican qué hará el sistema. En términos de los tipos de requisitos FURPS+, los casos de uso se refieren fundamentalmente a la "F" (funcional o de comportamiento), pero también pueden utilizarse para otros tipos, especialmente cuando esos otros tipos están estrechamente relacionados con un caso de uso.
Para ser claros: los casos de uso son requisitos (aunque no todos los requisitos). Algunos piensan en requisitos sólo como listas de características y funciones de la forma "el sistema deberá hacer...". No es así, y una idea clave de los casos de uso (por lo general) reducir la importancia o el uso de las listas de características detalladas al estilo antiguo y más bien, escribir casos de uso para los requisitos funcionales.
Los casos de uso son documentos de texto, no diagramas, y el modelo de casos de uso es, sobre todo, una acción de escribir texto, no dibujar. Sin embargo, UML define un diagrama de casos de uso para ilustrar los nombres de casos de uso y actores, y sus relaciones.
Tipos de casos de uso y formatos
Casos de uso de caja negra y las responsabilidades del sistema
Los casos de uso de caja negra. Son la clase más común y recomendada; no describen el funcionamiento interno del sistema, sus componentes o diseño, sino que describe el sistema en base a las responsabilidades que tiene, que es una metáfora común y unificadora en el pensamiento orientado a objetos (los elementos de software tiene responsabilidades y colaboran con otros elementos que tienen responsabilidades).
A través de la definición de las responsabilidades del sistema con casos de uso de caja negra, es posible especificar "qué" debe hacer el sistema (los requisitos funcionales) sin decidir "cómo" lo hará el diseño se resume algunas veces como el "qué" frente al "cómo". Este es un tema importante en un buen desarrollo de software: evite durante el análisis de requisitos tomar decisiones acerca del "cómo", y especifique el comportamiento externo del sistema, como una caja negra. Después, durante el diseño, cree una solución que satisfaga la especificación.
Ejemplo:
Tipos de formalidad
Los casos de uso se escriben con formatos diferentes, dependiendo de la necesidad. Además del tipo de visibilidad, de caja negra frente a caja blanca, los casos de uso se escriben con varios grados de formalidad:
* Breve: resumen conciso de un párrafo, normalmente del escenario principal con éxito. El anterior ejemplo de Procesar Venta.
* Informal: formato de párrafo en un estilo informal. Múltiples párrafos que comprenden varios escenarios. El anterior ejemplo de Gestionar Devoluciones.
* Completo: el más elaborado. Se escriben con detalle todos los pasos y variaciones, y hay secciones de apoyo como precondiciones y garantías de éxito.
Ejemplo completo: Procesar Venta
El formato usecases.org
El formato más extendido, uno de los más extendidos esté en www.usecases.org
La variación de dos-columnas
....
Explicación de las secciones
Elementos del prólogo
Actor principal: el actor principal que recurre a los servicios del sistema para cumplir un objetivo.
El [sistema] funciona siguiendo un contrato entre el personal involucrado, donde los casos de uso detallan la parte de comportamiento del contrato... El caso de uso, como contrato de comportamiento, captura captura y sólo el comportamiento relacionado con la satisfacción del personal involucrado.
Importante: Personal involucrado y lista de intereses
Esto contesta la pregunta: ¿Qué debería estar en un caso de uso? La respuesta es: lo que satisfaga los intereses de todo el personal involucrado. Además, empezando con el personal involucrado y sus intereses antes de antes de escribir el resto del caso de uso, tenemos un modo de recordarnos cuáles deberían ser las responsabilidades más detalladas del sistema. Por ejemplo, ¿habría identificado una responsabilidad para gestionar la comisión del vendedor si no hubiese listado en primer lugar la persona involucrada vendedor y sus intereses? En el mejor de los casos al final, pero quizás no lo habría tenido en cuenta durante la primera sesión de análisis. El punto de vista del interés personal del interés personal involucrado proporciona un procedimiento metódico y completo para el descubrimiento y registro de todos los comportamientos requeridos.
Precondiciones y garantías de éxito (postcondiciones)
Las precondiciones establecen lo que siempre debe cumplirse antes de comenzar un escenario en el caso de uso. Las precondiciones no prueban en el caso de uso, sino que son condiciones que se asumen que son verdad. #que ya se cumplen# Normalmente, una precondición implica un escenario de otro caso de uso que se ha completado con éxito, como inicio de sesión. Nótese que hay condiciones que deben ser verdad pero no tienen un valor práctico para que se escriban como "el sistema tiene energía". Las precondiciones comunican suposiciones importantes de las que el escritor del caso de uso piensa que los lectores deberían ser avisados.
Las garantías de éxito (o postcondiciones) establecen que debe cumplirse cuando el caso de uso se completa con éxito (o bien el escenario principal de éxito o algún camino alternativo). La garantía debería satisfacer las necesidades de todo el personal involucrado.
Escenario principal de éxito y pasos (o Flujo Básico)
También recibe el nombre de escenario del "camino feliz", o más prosaico "Flujo Básico". Describe el camino de éxito típico que satisface los intereses del personal involucrado. Nótese que, a menudo, no incluye ninguna condición o bifurcación. Aunque no incorrecto o ilegal.
Sugerencia: Posponga todas las sentencias condicionales y de bifurcación a la sección Extensiones.
El escenario recoge los pasos, que pueden ser tres tipos:
1. Una interacción entre actores.
2. Una validación (normalmente a cargo del sistema)
3. Un cambio de estado realizado por el sistema (por ejemplo, registrando o modificando algo).
El primer paso de un caso de uso, normalmente no está incluido en esta clasificación, sino que se indica el comienzo del escenario.
Un estilo habitual es poner con mayúsculas los nombres de los actores para facilitar la identificación. También podemos observar el estilo que se utiliza para indicar una repetición.
NOTA: El Sistema que se está estudiando en sí mismo debería considerarse un actor cuando juega un rol de actor colaborando con otros sistemas.
Extensiones (o Flujo Alternativos)
Las extensiones son muy importantes. Indican todos los otros escenarios o bifurcaciones, tanto de éxito como de fracaso.
En la escritura de casos de uso completos, la combinación del camino feliz y los escenarios de extensión deberían satisfacer "casi" todos los intereses del personal involucrado. Este punto está limitado, puesto que algunos intereses se podrían capturar mejor como requisitos no funcionales escritos en la Especificación Complementaria en lugar de en los casos de uso.
Los escenarios de extensión son bifurcaciones del escenario principal de éxito y, por lo tanto, pueden ser etiquetados de acuerdo con él.
Una extensión tiene dos partes: la condición y manejo.
Guía: Escriba la condición como algo que pueda ser detectado por el sistema o un actor. Para contrastar:
5.a El sistema detecta un fallo en la comunicación con el servicio externo del sistema de cálculo de impuestos.
Cuando el manejo incluya una serie de pasos:
3-6.a. El Cliente le pide al Cajero que elimine un artículo de la compra:
1. El Cajero introduce el identificador del artículo para eliminarlo de la compra.
2. El Sistema muestra la suma parcial actualizada.
Al final del manejo del manejo de la extensión, por defecto, el escenario se une de nuevo con el escenario principal de éxito, a menos que la extensión indique otra cosa (como interrumpir el sistema).
(Ver caso bastante complejo de "pago de crédito") Inclusive esto pudiera ser un motivo para expresar la extensión como un caso de uso aparte.
Y otras notaciones para la extensiones.
Requisitos especiales
Si un requisito no funcional, atributo de calidad o restricción se relaciona de manera específica con un caso de uso, se recoge en el caso de uso. Esto incluye cualidades tales como rendimiento, fiabilidad y facilidad de uso, y restricciones de diseño ( a menudo, en dispositivos de entrada/salida) que son obligados o se consideran probables.
* Interfaz del usuario con pantalla táctil en un gran monitor de pantalla plana. El texto debe ser visible a un metro de distancia.
* Tiempo de respuesta para la autorización de crédito 30 segundos 90 % de las veces.
* Internacionalización del lenguaje del texto que se muestra.
* Reglas de negocio que se puedan añadir en ejecución en los pasos 3 y 7.
Un consejo clásico del UP es registrar estos requisitos con el caso de uso, y constituye un lugar razonable al escribir primero el caso de uso. Sin embargo, muchos expertos encuentran útil reunir al final todos lo requisitos no funcionales en la Especificación Complementaria, para favorecer la gestión del contenido, comprensión y legibilidad que, normalmente, se tienen que considerar estos requisitos en conjunto durante el análisis arquitectural.
p.56
Lista de tecnología y variaciones de datos
A menudo, encontramos variaciones técnicas en cómo se debe hacer algo, pero no en qué, y es importante registrarlo en el caso de uso. Un ejemplo típico es una restricción técnica impuesta por el personal involucrado con respecto a las tecnologías de entrada o salida de datos. Por ejemplo, uno de los interesados podría decir, "El sistema PDV debe soportar la entrada de la cuenta de crédito utilizando un lector de tarjetas y el teclado". Nótese que éstos son ejemplos de decisiones o restricciones de diseño prematuras, pero algunas veces son obvias e inevitables, especialmente en relación con las tecnologías de entrada/salida.
También es necesario entender las variaciones en los esquemas de los datos, como utilizar UPCs o EAN para los identificadores de los artículos, codificados mediante el código de barras.
SUGERENCIA. Esta sección no debería contener múltiples pasos para representar la variación de comportamiento en diferentes casos. Si es necesario, dígalo en la sección Extensiones.
6.8 Objetivos y alcance de un caso de uso
¿Cómo deberían descubrirse los casos de uso? Es típico no estar seguro si algo es un caso de uso válido. Las tareas se pueden agrupar a muchos niveles de granularidad, desde uno o pocos pasos pequeños, hasta actividades de nivel de empresa.
¿A qué nivel y alcance deberían expresarse los casos de uso?
#Lo siguiente ayuda a dicha identificación adecuada#
Casos de uso para los procesos del negocio elementales
¿Cuál de éstos es un caso de uso válido?
* Negociar un Contrato con el Proveedor.
* Gestionar las Devoluciones.
* Iniciar Sesión.
Podría argumentarse que todos ellos son casos de uso a diferentes niveles, dependiendo de los límites del sistemas, actores y objetivos. La evaluación de estos candidatos se presenta después de una introducción a los procesos del negocio elementales.
Es por ello que es indicado preguntar ¿cuál es el nivel útil para expresar los casos de uso en el análisis de requisitos de la aplicación?
Guía: El caso de uso EBP
Para el análisis de requisitos de una aplicación informática, céntrese en los casos de uso al nivel de procesos de negocio elementales (EBPs, Elementary Business Processes)
(EBP es un término parecido a tarea de usuario)
EBP se podría definir como:
Una tarea realizada por una persona en un lugar, en un instante, como respuesta a un evento del negocio, que añade un valor cuantificable para el negocio y deja los datos en un estado consistente, ej. Autorizar Crédito, o Solicitar Precio (se perdió la fuente original) <---- no entiendo esto último
No se trata de un pequeño paso como "eliminar una línea de pedido" o "imprimir el documento". Sino que el caso de uso está formado probablemente por cinco o diez pasos. Probablemente dura entre unos pocos minutos y una hora. Como con la definición, hace hincapié en añadir valor observable y cuantificable al negocio, y llega a un acuerdo en ele que el sistema y los datos se encuentran en un estado estable y constante.
NOTA: Un error típico de los casos de uso es definir muchos casos de uso a un nivel muy bajo; es decir, como un paso simple, subfunción o subtarea en un EBP.
Violaciones razonable de la guía EBP
Aunque los casos de uso "base" de una aplicación deberían satisfacer la guía EBP, normalmente es crear un "sub" casos de uso separados que representan subtareas, o pasos, en un caso de uso base.
Por ejemplo, una subtarea o extensión como "pago a crédito" podría repetirse en varios casos de uso base. Es conveniente separarlo en un caso de uso propio (que no satisface la guía EBP) y conectarlo a varios casos de uso base, para evitar duplicaciones del texto.
Casos de uso y objetivos
Los actores tienen objetivos (o necesidades) y utilizan las aplicaciones para ayudarles a satisfacerlos. En consecuencia, un caso de uso de nivel EBP se denomina caso de uso de nivel de objetivo de usuario, para remarcar que sirve (o debería servir) para satisfacer un objetivo de un usuario del sistema, o el actor principal.
Esto nos lleva a recomendar el siguiente procedimiento:
1. Encontrar los objetivos del usuario
2. Definir un caso de uso para cada uno
En lugar de preguntar "¿Cuáles son los casos de uso?", uno comienza preguntando: "¿Cuáles son tus objetivos?". De hecho, el nombre del caso de uso para un objetivo debería reflejar dicho objetivo, para resaltar este punto de vista. Objetivo: capturar o procesar una venta; caso de uso: Procesar Venta.
Nótese que debido a esta simetría, la guía EBP se puede aplicar igualmente para decidir si un objetivo o un caso de uso se encuentran a un nivel adecuado.
#Dicho de otro modo#
Imagine que estamos en un taller de requisitos. Nos podríamos preguntar:
* "¿Qué haces?" (una pregunta bastante orientada al caso de uso) o
* "¿Cuáles son tus objetivos?"
Es más probable que las respuestas a la primera pregunta reflejen soluciones y procedimientos actuales, y las complicaciones asociadas a ellos. # Esto debe evitarse #
Las respuestas a la segunda pregunta, especialmente combinada con una investigación para ascender en la jerarquía de objetivos ("¿cuál es el objetivo de ese objetivo?"), abren la visión de soluciones nuevas y mejoradas, centradas en añadir valor al negocio, y llegar al corazón de los que el personal involucrado quiere del sistema que se está estudiando.
Ejemplo: aplicación de la guía EBP
Descubriendo los requisitos del PDV
Obsérvese que la estrategia del analista de buscar de manera ascendente en la jerarquía de objetivos para encontrar los objetivos de usuario de un nivel superior que todavía satisfagan la guía EBP, para obtener el objetivo real detrás de la acción, y también para entender el contexto de los objetivos.
"Evitar robos..." es de un nivel superior a un objetivo de usuario; podría llamarse objetivo de la empresa, y no es un EBP. ... esto lo vamos a dejar de lado por ahora.
Disminuyendo el nivel del objetivo a "identificarme en el sistema y ser validado" se acerca al nivel de objetivo de usuario. ¿Pero es el nivel EBP? No añade valor observable o cuantificable al negocio. Si el responsable del comercio pregunta: "¿Qué hiciste hoy?" y dices "¡Inicie sesión 20 veces!", no se impresionaría. En consecuencia, es un objetivo secundario, siempre disponible para hacer algo útil, y no es un EBP u objetivo del usuario. En cambio, "capturar una venta" cumple el criterio para ser un EBP u objetivo de usuario.
Otro ejemplo podría ser, en algunas tiendas existe un proceso denominado "abrir caja", en el cual un cajero inserta su propia bandeja del cajón de caja en el terminal, inicia la sesión, e indica al sistema el dinero que hay en caja. Abrir caja es un caso de uso de nivel EBP (o nivel de objetivo de usuario); el paso de inicio de sesión; en lugar de un caso de uso de EBP, es un objetivo de subfunción para llevar a cabo el objetivo de abrir caja.
p.60
Objetivos y casos de uso de subfunción
Aunque "identificarme y ser validado" (o "iniciar sesión") se ha eliminado como objetivo de usuario, es un objetivo de nivel más bajo, denominado objetivo de subfunción.
No es ilegal escribir casos de uso para objetivos de subfunción, pero no siempre es útil, ya que añade complejidad al modelo de casos de uso; puede haber cientos de objetivos de subfunción (o casos de uso de subfunción) en un sistema.
Un punto importante es que el número y granularidad de los casos de uso influyen en el tiempo y la dificultad para entender, mantener y gestionar los requisitos.
Un motivo válido, más común para representar un objetivo de subfunción como caso de uso, es cuando la subfunción se repite o es una precondición en muchos casos de uso de nivel de objetivos de usuario. Este hecho se cumple probablemente en el caso de uso de "identificarme y ser validado", que es una precondición de la mayoría, si no todos, los otros casos de uso de nivel de objetivos de usuario.
En consecuencia, podría escribirse como el caso de uso Autenticar Usuario.
Objetivos y casos de uso pueden ser compuestas
Normalmente, los objetivos son compuestos, desde el nivel de empresa ("ser rentable"), que incluyen muchos objetivos intermedios a nivel de uso de la aplicación ("se capturan las ventas"), que a su vez incluyen objetivos de subfunción dentro de las aplicaciones ("la entrada válida").
De manera análoga, los casos de uso se pueden escribir a niveles diferentes para satisfacer estos objetivos, y pueden estar compuestos de casos de uso de nivel inferior.
Estos diferentes niveles de objetivos y casos de uso son una fuente típica de confusión en la identificación del nivel adecuado de los casos de uso de una aplicación. La guía EBP proporciona una orientación para eliminar casos de uso de nivel excesivamente bajo.
6.9 Descubrimiento de actores principales, objetivos y casos de uso
Los casos de uso se definen para satisfacer los objetivos del usuario de actores principales.
1. Elegir los límites del sistema ¿Es sólo una aplicación de software, el hardware y la aplicación como un todo, que lo utiliza más de una persona o una organización completa?
2. Identificar los actores principales (aquellos que tienen objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema).
3. Para cada uno, identificar sus objetivos de usuario. Elevarlos al nivel de objetivos de usuario más alto que satisfaga la guía EBP.
4. Definir los casos de uso que satisfagan los objetivos del usuario; nombrarlos de acuerdo con sus objetivos. Normalmente, los casos de uso del nivel de objetivo de usuario se corresponderán uno a uno con los objetivos de usuario, aunque hay al menos una excepción.
p.61
Paso 1: Elegir el límite del sistema
Para este caso de estudio, el propio sistema PDV es el sistema que se está diseñando; todo lo que queda fuera de él, está fuera de los límites del sistema, incluyendo el cajero, el servicio de autorización de pagos, etc.
Si no está clara la definición de los límites del sistema que se está diseñando, se puede aclarar definiendo lo que está fuera (los actores principales externos y de apoyo). Una vez identificados los actores externos, los límites se vuelven más claros. Por ejemplo, ¿se encuentra la responsabilidad de autorización de pagos completa en los límites del sistema? No, hay un actor del servicio externo de autorización de pagos.
Pasos 2 y 3: Identificar los actores principales y objetivos
Es artificial establecer de manera estricta que la identificación de los actores principales es antes que los objetivos de usuario; en un taller de requisitos, la gente pone en común sus ideas y dan lugar a una mezcla de ambos. Algunas veces los objetivos ponen de manifiesto a los actores, o viceversa.
Guía: Centrar la discusión en los actores principales en primer lugar, ya que establece ya que establece el marco de las investigaciones posteriores.
Preguntas útiles para encontrar los actores principales y objetivos
Además de los actores principales y objetivos obvios, las preguntas siguientes ayudan a identificar otros que se podrían haber pasado:
¿Quién arranca y para el sistema? ¿Quién se encarga de la administración del sistema?
¿Quién gestiona a los usuarios y la seguridad? ¿Existe un proceso de control que reinicie el sistema si falla?
¿Existe un proceso de control que reinicie el sistema si falla? ¿Quien evalúa la actividad o el rendimiento?
¿Cómo se gestionan las actualizaciones de software? ¿Quién evalúa los registros?
¿Actualizaciones automáticas o no? ¿Se recuperan de manera remota?
p. 62
Actores principales y de apoyo
Recordemos que los actores principales tienen objetivos de usuario que se satisfacen mediante el uso de servicios del sistema. Acuden al sistema para que les ayude. Al contrario que los actores de apoyo, que proporcionan servicios al sistema que se está diseñando.
Recordemos también que los actores principales pueden ser (entre otras cosas) otros sistemas informáticos, como procesos software "guardianes" ("watchdog").
Sugerencia: Desconfía si ninguno de los actores principales se corresponde con un sistema informático externo.
La lista actor-objetivo
Recoge los actores principales y sus objetivos de usuario en una lista actor-objetivo. En términos de los artefactos UP, debería corresponderse con una sección del artefacto Visión.
Por ejemplo:
El Sistema de Actividades de Ventas es una aplicación remota a la que se le solicitará con frecuencia datos de ventas desde cada nodo PDV en la red.
Dimensión de la planificación del proyecto
A esta lista se le añaden las columnas prioridad, esfuerzo y riesgo.
La complicada realidad
Son necesarias muchas "tormentas de ideas" y discusiones durante los talleres de requisitos. Consideremos el ejemplo anterior que ilustraba la aplicación de la regla EBP al objetivo "iniciar sesión". Durante el taller, mientras se crea esta lista, el cajero podría proponer "iniciar sesión" como objetivo del usuario. El analista de sistemas profundizará y se da cuenta que no cumple la guía EBP, y lo descarta como objetivo del usuario. Por supuesto, la realidad es incluso algo diferente a esto puesto que un analista con experiencia cuenta con un conjunto de heurísticas, procedentes de experiencias o estudios anteriores, una de las cuales es "la autenticación es rara vez un EBP", y de este modo es probable que se elimine rápidamente.
El actor principal y los objetivos de usuario dependen del límite del sistema
¿Por qué es el cajero, y no el cliente, el actor principal del caso de uso de Procesar Venta? ¿Por qué no aparece el cliente en la lista actor-objetivo?
La respuesta depende del límite del sistema que se esté diseñando, como se ilustra en la siguiente figura. Si consideramos la empresa o el servicio de caja como un sistema agregado (<-----no entiendo esta frase), el cliente es un actor principal, con el objetivo de obtener artículos o servicios, y marcharse. Sin embargo, desde el punto de vista de únicamente el sistema PDV (que es la elección del límite del sistema para este caso de estudio), éste atiende el objetivo del cajero (y de la tienda) de procesar la venta del cliente.
Actores y objetivos por medio del análisis de eventos
Otro enfoque para ayudar en la búsqueda de los actores, objetivos y casos de uso, es identificar los eventos externos. ¿Cuáles son, de dónde proceden y por qué? A menudo, un grupo de eventos pertenecen al mismo objetivo o caso de uso de nivel EBP. Por ejemplo:
