• Author / Uploaded
• Alberto Figueroa

Citation preview

Grupo para el Desarrollo de Tecnologías de Software

Manual de Requerimientos. Ingeniería de Software Introducción a IR ¿Por Qué? En uno de los párrafos más citados en la bibliografía de la Ingeniería del Software, Frederick P. Brooks [Brooks, 1987], dice : "La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante... Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto." Entonces tenemos que los requerimientos se deben descubrir antes de empezar a construir un producto, y que:

• •

Puede ser algo que el producto debe hacer O una cualidad que el producto debe tener.

Un requerimiento existe porque:

• •

El tipo de producto demanda ciertas funciones o cualidades, Porque el cliente quiere que ese requerimiento sea parte del producto final

Así que si no se tienen los requerimientos correctos, no se puede diseñar o construir el producto correcto y, consecuentemente, el producto no permitirá a los usuarios finales realizar su trabajo. Y esto está confirmado por estudios que demuestran que más del 60% de los errores de diseño se originan durante las etapas de requerimientos y análisis. Los requerimientos se pueden dividir en:

• •

Funcionales y No-funcionales

Los funcionales definen qué hace el sistema (describen todas las entradas y salidas), es decir, las funciones del sistema. Por su parte, los no-funcionales definen los atributos que le indican al sistema cómo realizar su trabajo (eficiencia, hardware, software, interfase, usabilidad, etc.); es el cómo, cuándo y cuánto del qué.

1

Grupo para el Desarrollo de Tecnologías de Software

¿Qué es? La Ingeniería de Requerimientos se define, según Ortas [Ortas 1997], como un : "conjunto de actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces más de una)." Otras definiciones: “Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema” Boehm 1979. “Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones”. STARTS Guide 1987. “Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos” Leite 1987. “Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto” Rational Software Entonces, "Ingeniería de Requerimientos" se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto determinado. El uso del término "ingeniería" implica que se deben utilizar técnicas sistemáticas y repetibles para asegurar que los requerimientos del sistema estén completos y sean consistentes y relevantes. ¿Para qué un Proceso de Ingeniería de Requerimientos? El Proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales obtenemos, validamos y mantenemos el documento de especificación de requerimientos (ESRE). Las actividades del proceso incluyen la extracción de requerimientos, el análisis, la negociación y la validación. No existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de requerimientos y muchas veces tenemos también que recurrir a consultores, ya que ellos tienen una perspectiva mas objetiva que las personas involucradas en el proceso. Cualquier tarea en donde el resultado sea importante, se puede realizar de mejor manera al utilizar algún tipo de proceso ordenado. Para obtener este orden, diseñamos nuestros procesos basándonos en algún modelo que nos guíe a la hora de diferenciar y secuenciar las actividades.

2

Grupo para el Desarrollo de Tecnologías de Software

Por ende, veremos a continuación los modelos aplicables a la Ingeniería de Requerimientos, los analizaremos y veremos cuál se aplica mejor a nuestro escenario, para continuar con el análisis detallado de las diferentes etapas implicadas en este proceso, y las herramientas que mejor se aplican a cada una. Beneficios de la IR Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son: • Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. • Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. • Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. • Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.). • Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso. • Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Los Requerimientos Ya habíamos dicho que un requerimiento es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo, y/o una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. Definiciones

•

Es una declaración en un Lenguaje Natural incluye los diagramas de los servicios del sistema y sus límites operacionales. Escrito para clientes.

3

Grupo para el Desarrollo de Tecnologías de Software

• •

Especificación de Requerimientos. Un documento estructurado con descripción o detalle de los servicios del sistema. Escrito como un contrato entre el cliente y el contratista. Especificación de Software. Descripción detallada de software, la cual, puede servir como una base para diseño o implementación. Escrito para desarrolladodres.

Características de los requerimientos Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes. Necesario Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector. Verificable Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas. Dificultades para definir los requerimientos • Los requerimientos no son obvios y vienen de muchas fuentes. • Son difíciles de expresar en palabras (el lenguaje es ambiguo). • Existen muchos tipos de requerimientos y diferentes niveles de detalle. • La cantidad de requerimientos en un proyecto puede ser difícil de manejar. • Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros. • Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. • Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. • Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada

4

Grupo para el Desarrollo de Tecnologías de Software

proyecto. •Sistemas de Software grandes con problemas de direccionamiento. •Problemas de tal manera complejos que puede ser que nunca se comprendan completamente y donde los desarrolladores van comprendiendo el sistema durante su desarrollo •Por lo tanto, los requerimientos son normalmente incompletos e inconsistentes Razones para la Inconsistencia

• • • • •

Los sistemas de software grandes deben mejorar su actual situación. Es difícil anticipar los efectos que el sistema tendrá en la organización. Usuarios diferentes tienen requerimientos y prioridades diferentes. Hay constantemente compromiso de cambios en los requerimientos. Los usuarios finales del sistema y la organización que paga por el sistema tienen requerimientos diferentes. El prototipado es requerido para clarificar requerimientos

Lectores de los Requerimientos

Requerimientos II Tipos de Requerimientos

• • • • • •

Requerimientos Durables. Establecer requerimientos derivados de las actividades de la organización del cliente. Por ejemplo, un hospital siempre tendrá doctores, enfermeras, etc. Puede ser derivado de modelos de dominio. Requerimientos Volátiles. Los requerimientos cambian durante el desarrollo o cuando el sistema está en uso. En un hospital, los requerimientos se derivan de las políticas saludcuidados Requerimientos Cambiantes. Los requerimientos que cambian por el ambiente del sistema. Surgimiento de los Requerimientos. Requerimientos que surgen como una comprensión del desarrollo del sistema. Requerimientos en Consecuencial. Requerimientos que resultan de la introducción del sistema a la computadora. Requerimientos Compatibles. Requerimientos que dependen de otros sistemas o de otros procesos de la organización.

5

Grupo para el Desarrollo de Tecnologías de Software

Definición de requerimientos no funcionales Son aspectos del sistema visibles para el usuario, que no están relacionados de forma directa con el comportamiento funcional del sistema. Abarcan diversos aspectos:

• • • • • • • •

interfaz de usuario y factores humanos: tipo de interfaz, experiencia,... documentación: documentación requerida, destinatarios, tipo de documentación técnica,... consideraciones de hardware: compatibilidad con otro hardware, existencia de otros sistemas,... características de ejecución: usuarios concurrentes, carga de trabajo,... gestión de errores y excepciones cuestiones de calidad: fiabilidad, disponibilidad, robustez,... modificaciones futuras ambiente físico: condiciones climáticas, exposición a golpes, accidentes,... seguridad recursos consumidor por el sistema

Especificación Complementaria Captura otros requisitos, información y restricciones que no se recogen en los casos de uso o en el Glosario Comprende:

• • • • • • • •

requisitos FURPS+ : funcionalidad, facilidad de uso, fiabilidad, rendimiento y soporte (funcionality, usability, reliability, performance, supportability) informes restricciones de software y hardware (sistemas operativos, plataformas, redes, sistemas de bases de datos,...) restricciones de desarrollo (herramientas de proceso y desarrollo,...) otras restricciones de diseño e implementación cuestiones de internacionalización (monedas, medidas, idiomas,...) documentación (usuario, instalación, administración) y ayuda licencia y cuestiones legales estándares (técnicos, de seguridad, de calidad,...) cuestiones del entorno físico (temperatura, vibraciones,...) cuestiones operacionales (gestión de errores, frecuencia de copias de seguridad,...) reglas del dominio o negocio

El Glosario Es la lista de los términos relevantes y sus definiciones

• •

Reduce problemas de comunicación y requisitos ambiguos: evita que un término se utilice de forma distinta por diferentes personas involucradas en el desarrollo Debe comenzarse cuanto antes

El glosario como Diccionario de Datos El diccionario de datos recoge datos sobre los datos (metadatos)

6

Grupo para el Desarrollo de Tecnologías de Software

• •

• •

fase de inicio: el glosario debe ser un documento sencillo de términos y descripciones fase de elaboración: se amplía a un diccionario de datos, incorporando atributos sobre los términos: o alias o descripción o formato (tipo, longitud, unidad) o relaciones con otros elementos o rango de valores o reglas de validación Es importante tener en cuenta las unidades (medida, moneda,...) puede haber términos compuestos Hay términos que incluyen otros elementos ejemplo: Venta puede incluir fecha, lugar, cliente, lugar,...

Proceso de la IR Las Grandes Etapas

• • • •

Estudio de Factibilidad. Encuentran los usuarios actuales que sus necesidades son satisfechas dada la tecnología y el presupuesto disponible? Análisis de Requerimientos. Encontrar que el sistema requiere del mantenimiento de intereses. Definición de Requerimientos. Definir los requerimientos en una forma comprensible para el cliente. Especificación de Requerimientos. Define los requerimientos en detalle

Proceso de la IR

7

Grupo para el Desarrollo de Tecnologías de Software

Documento de Requerimientos Es la declaración oficial de lo que es requerido para que el sistema sea desarrollado. Incluye la definición y especificación de requerimientos. No es un documento de diseño. Tanto como sea posible, es un conjunto de lo que es el sistema y como lo hará. Requerimientos del Documento de Requerimientos

• • • • • •

Especificación de la conducta externa del sistema. Especificar los límites de la implementación. Fácil de cambiar. Sirve como una herramienta de referencia para mantenimiento Recuerda el ciclo de vida del sistema, esto es, predice cambios. Proporciona respuestas características a un evento no esperado.

Estructura del documento de Requerimientos

• • • • • • •

Introducción. Describe la necesidad de crear el sistema y cuales son sus objetivos. Glosario. Define los términos técnicos usados. Modelos del Sistema. Define los modelos que muestran los componentes del sistema y las relaciones entre ellos. Definición de Requerimientos Funcionales. Define los servicios que serán proporcionados. Definición de Requerimientos No-funcionales. Definir las limitantes del sistema y el proceso de desarrollo. Evolución del Sistema. Definir las suposiciones fundamentales en las cuales el sistema se basa y se anticipan los cambios. Especificación de Requerimientos. Especificación detallada de los requerimientos funcionales del sistema. Apéndices

• •

Descripción de la plataforma de Hardware del Sistema. Requerimientos de la base de Datos (quizá como un modelo ER)

Cambios en el ESRE El documento de requerimientos debe ser organizado, de tal forma que los cambios en los requerimientos puedan ser hechos sin tener que re-escribir demasiado. Las referencias externas deben ser minimizadas y las secciones del documento deben ser tan modulares como sea

8

Grupo para el Desarrollo de Tecnologías de Software

posible. Los cambios son fáciles cuando se trata de un documento electrónico. Sin embargo, la falta de estándares para documentos electrónicos lo hace difícil.

Actividades de la IR Usualmente podemos dividir las prácticas de la IR en 4 actividades, a saber: a.- Extracción (Análisis del Problema) b.- Análisis (Negociación del Problema) c.- Especificación d.- Validación (incluida evolución) Como toda división de tareas, no es una estricta representación de la realidad, sino que se hace con el fin de sistematizar la realización de la IR. En general la delimitación entre una actividad y la otra no es tan clara, ya que están sumamente interrelacionadas, existiendo un alto grado de iteración y retroalimentación entre una y otra. Extracción (Análisis del Problema) Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los AN deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. El objetivo de esta actividad es entender las verdaderas necesidades del negocio. “Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean” . Aquí vemos nuevamente la importancia que tiene una buena comunicación entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades. Esto no suele ser tarea fácil: muchas veces los clientes/usuarios no tienen una idea clara de sus necesidades reales, diversas personas dentro de la organización tienen necesidades encontradas, pueden existir limitaciones técnicas o tecnológicas para cumplir con algunos requerimientos, etc. Pero, en definitiva, descubrir los requerimientos del sistema no sólo implica preguntar a las personas qué quieren: es un proceso delicado que involucra comprender el domino de aplicación, es decir, obtener un conocimiento del área general de aplicación del sistema; comprender el problema en sí, lo que implica que se debe extender y especializar el conocimiento sobre el dominio general para que se aplique al cliente en particular; comprender

9

Grupo para el Desarrollo de Tecnologías de Software

el negocio, por tanto, se debe entender en profundidad cómo es que este sistema interactuará y afectará a las partes del negocio que estarán involucradas y cómo puede contribuir a lograr las metas de la empresa; finalmente, comprender las necesidades y restricciones de los usuarios del sistema, en particular, se deben entender los procesos de trabajo que se supone que el sistema apoyará y el rol de cualquier otro sistema que actualmente se involucre en dichos procesos. Durante el análisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Estos pasos son los siguientes :

•

Comprender el problema que se está resolviendo: Es importante determinar quién tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Por ejemplo, veamos la siguiente necesidad: o “El cliente se queja mucho por la enorme fila que debe formar para realizar una transacción bancaria” :
Perspectiva del cliente = Pérdida de tiempo
Perspectiva del banco = Posibles pérdidas de clientes o Posibles soluciones pueden ser:
Determinar por qué demoran los cajeros
Colocar una nueva caja (implica contratación de nuevos cajeros)
Abrir una nueva sucursal (involucra personal nuevo y estudio de mercado) o Realizar transacciones por otros medios (teléfono, internet, mediante cajeros automáticos, autobancos, etc).

Como puede verse, múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. Las soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva técnica como la del negocio.

•

•

Construir un vocabulario común: Debe confeccionarse un glosario en dónde se definan todos los términos que tengan significados comunes (sinónimos) y que serán utilizados durante el proyecto. Por ejemplo, las palabras pignoración, retención, valor en suspenso, custodia, garantía, entre otras, son utilizadas para referirse a la acción de dejar una prenda (puede ser cualquier forma de ahorros) como garantía de una deuda adquirida. La creación de un glosario es sumamente beneficiosa ya que reduce los términos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunión están en la misma página, además de ser reutilizable en otros proyectos. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante de ingeniería de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la información necesaria para especificar un sistema adecuado. Para saber quiénes son las personas, departamentos, organizaciones internas o externas que se verán afectadas por el sistema, debemos realizar algunas preguntas. • ¿Quién usará el sistema que se va a construir? • ¿Quién desarrollará el sistema? • ¿Quién probará el sistema? • ¿Quién documentará el sistema? • ¿Quién dará soporte al sistema? • ¿Quién dará mantenimiento al sistema? • ¿Quién mercadeará, venderá, y/o distribuirá el sistema? • ¿Quién se beneficiará por el retorno de inversión del sistema?

10

Grupo para el Desarrollo de Tecnologías de Software

Como vemos, debe conocerse la opinión de todo aquél que de una u otra forma está involucrado con el sistema, ya sea directa o indirectamente. Definir los límites y restricciones del sistema: Este punto es importante pues debemos saber lo que se está construyendo, y lo que no se está construyendo, para así entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que limite el sistema que se va a construir

•

Definir los límites y restricciones del sistema: Debemos saber lo que se está construyendo, y lo que no se está construyendo, para así entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que limite el sistema que se va a construir.

Es importante, entonces, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuan bien éste satisfaga las necesidades del cliente y de cuan bien asista a la automatización del trabajo.

Análisis (Negociación del problema) Sobre la base de la extracción realizada previamente, comienza esta fase -que se presenta sumamente compleja en un proyecto donde el dominio es desconocido- en la cual sea apunta a descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; aquí se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos. Debemos destacar que no es posible convertir el análisis en un proceso estructurado y sistemático, lo que convierte a esta etapa en "subjetiva" porque depende en gran medida del juicio y de la experiencia del AN. Especificación En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, pero podríamos decir que la Especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML. La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El término “adecuado” significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan resultados completos, correctos y sin ambigüedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y descomposición de cada problema presentado. Los principales pasos de esta actividad son:

• •

Descubrir problemas potenciales: En este paso se asegura que todas las requerimientos cumplan los términos. es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc. Clasificar los requerimientos: En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A esta característica se le

11

Grupo para el Desarrollo de Tecnologías de Software

conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las necesidades que tenga el negocio. En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. o Un requerimiento es mandatario si afecta una operación crítica del negocio. o Si existe algún proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable. o Si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario. Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatarios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo deseable.

•

Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología actual?); factibilidades operacionales (¿puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).

En la actividad de evaluación y negociación, se incrementa la comunicación entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos: • • • • • •

Documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones.

Especificación de Requisitos de Software (SRS) La especificación de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma en como hará sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores. Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación de requerimientos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolución del sistema.

12

Grupo para el Desarrollo de Tecnologías de Software

La SRS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y así sucesivamente. Las características de la SRS son verificadas en la actividad de Validación. La estandarización de la SRS es fundamental pues ayudará, entre otras cosas, a facilitar la lectura y escritura de la misma. Será un documento familiar para todos los involucrados, además de asegurar que se cubren todos los tópicos importantes. Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. En el anexo #1 se muestra una plantilla completa para la especificación de requisitos. Validación de Requisitos La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes. En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad. No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos. Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación se presentan varios ejemplos: • ¿Están incluidas todas las funciones requeridas por el cliente? (completa) • ¿Existen conflictos en los requerimientos? (consistencia) • ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua) • ¿Está cada requerimiento claramente representado? (entendible) • ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible) • ¿Está la SRS escrita en un lenguaje apropiado? (clara) • ¿Existe facilidad para hacer cambios en los requerimientos? (modificable) • ¿Está claramente definido el origen de cada requisito? (rastreable) • ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable) La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado. La validación es la etapa final de la IR. La validación representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se está haciendo, y externo, porque se debe validar con el cliente. Preferentemente, el documento de requerimientos obtenido en la etapa anterior sólo debería incluir los requerimientos que son aceptables para los usuarios. Pero es inevitable que durante la validación se descubran algunos problemas relacionados con los usuarios, y esto se debe corregir antes de aprobarse el documento final de requerimientos.

13

Grupo para el Desarrollo de Tecnologías de Software

En definitiva, la validación de especificaciones realmente significa asegurarse de que el documento de requerimientos represente una descripción clara del sistema, y es una verificación final de que los requerimientos cubren las necesidades de los usuarios. Esta etapa puede confundirse con la de análisis, pero la diferencia es clara: mientras que en el análisis se trabaja sobre el boceto del documento de requerimientos, en la validación se utiliza el documento final, lo que equivale a decir, los requerimientos "depurados". Evolución de los requerimientos Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las más frecuentes son: • Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. • Porque cambió el problema que se estaba resolviendo. • Porque los usuarios cambiaron su forma de pensar o sus percepciones. • Porque cambió el ambiente de negocios. • Porque cambió el mercado en el cual se desenvuelve el negocio. Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administración de cambios involucra actividades como establecer políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones. Tener versiones de los requerimientos es tan importante como tener versiones del código, ya que evita tener requerimientos emparchados en un proyecto Entre algunos de los beneficios que proporciona el control de versiones están: • Prevenir cambios no autorizados. • Guardar revisiones de los documentos de requerimientos. • Recuperar versiones previas de los documentos. • Administrar una estrategia de “releases”. • Prevenir la modificación simultánea a los requisitos. En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos. Proceso de analisis

14

Grupo para el Desarrollo de Tecnologías de Software

Extracción - Análisis del Problema Objetivos

• • • •

Describir diferentes enfoques para descubrir los requerimientos. Explicar la necesidad de un análisis desde múltiples perspectivas Ilustrar un enfoque estructurado al análisis de requerimientos Explicar por qué influyen los factores organizacionales y sociales en los requerimientos del sistema

Los Enfoques del Análisis

• • • •

Análisis orientado a puntos de vista Análisis basado en métodos Contexto del sistema Factores sociales y organizacionales

Análisis orientado a puntos de vista

• •

Los especialistas representan diferentes modos de ver un problema ó los diferentes puntos de vista de un problema Este análisis de múltiples perspectivas es muy importante ya que no hay un modo correcto y sencillo para analizar los requerimientos del sistema

Veamos un ejemplo de un Cajero Automático: Este ejemplo es un sistema de cajero automático que provee algunos servicios bancarios. Se emplea un sistema muy simplificado el cual ofrece algunos servicios a clientes del banco propietario del sistema y a otros clientes un pequeño conjunto de servicios. Los servicios incluyen disposición de efectivo, solicitar un servicio (enviando un mensaje), estados de cuenta y transferencia de fondos Puntos de vista de Sistema de Cajero automático:

• • • •

Clientes del banco Representantes de otros bancos Ingenieros de mantenimiento en hardware y software Departamento de mercadotecnia

15

Grupo para el Desarrollo de Tecnologías de Software

• • • •

Administradores del banco y contadores Administradores de base de datos y seguridad Ingenieros de comunicaciones Departamento de personal

•

Fuentes de datos. Los puntos de vista, son responsables de producir ó consumir datos. El análisis implica verificar qué datos son producidos y consumidos y qué suposiciones sobre las fuentes o destinos de los datos son validas Estructuras de representación. Los puntos de vista representan tipos particulares de modelos de sistemas. Particularmente apropiado para sistemas de tiempo real Receptores de los servicios. Los puntos de vista son externos al sistema y reciben servicios de éste. Es más apropiados para sistemas interactivos

• •

Puntos de vista Externos Es natural pensar en los usuarios finales como receptores de los servicios del sistema. Los puntos de vista son un medio natural de estructurar la obtención de requerimientos. Es relativamente fácil decidir si un punto de vista es válido Puntos de vista y servicios pueden ser pedidos para estructurar requerimientos no funcionales Análisis basado en Métodos Ampliamente usado para aproximarse al análisis de requerimientos. Depende de la aplicación de un método estructurado para entender el sistema Los métodos tienen diferentes énfasis. Algunos están diseñados para obtener los requerimientos, otros son métodos de diseño Un método orientado a puntos de vista (VORD) es usado como ejemplo aquí. Esto también ilustra el uso de los puntos de vista

Proceso VORD

• •

Identificación de puntos de vista. Explorar los puntos de vista que reciben servicios del sistema e identificar los servicios proporcionados a cada punto de vista Estructurar los puntos de vista. Agrupar los puntos de vista relacionados en jerarquías. Los servicios comunes son proporcionados en los niveles más altos de la jerarquía

16

Grupo para el Desarrollo de Tecnologías de Software

• •

Documentación de los puntos de vista. Refina la descripción de los puntos de vista y los servicios identificados Representación de los puntos de vista. Transformar el análisis a un diseño

Información de servicios de los puntos de vista

Datos/Control a Puntos de vista

Jerarquía de puntos de vista

17

Grupo para el Desarrollo de Tecnologías de Software

Plataforma cliente/disposición de efectivo

Análisis de datos y control

Leyenda

18

Grupo para el Desarrollo de Tecnologías de Software

-

Elipses. Datos proporcionados de ó para un punto de vista Control de información, los datos entran y/o salen de la tapa de cada cuadro Los Datos salen por la derecha de cada cuadro Las excepciones son mostradas en el fondo de cada cuadro El nombre del evento siguiente está en el cuadro de orillas gruesas

La mayoría de los métodos no incluyen facilidades para describir las excepciones En este ejemplo las excepciones son: - Tiempo transcurrido. El cliente no insertó su NIP en un tiempo razonable - Tarjeta inválida. La tarjeta no es reconocida y es devuelta - Tarjeta robada. La tarjeta está registrada como robada y es retenida por el cajero Contexto de Sistema

• • •

Los límites del sistema deben ser establecidos para determinar lo que debe ser implementado Éstos son documentados usando una explicación del contexto del sistema. Esto debe incluir una descripción de los otros sistemas que están en el ambiente Los factores organizacionales y sociales pueden influir la definición de los límites del sistema

Contexto del sistema de cajero

Análisis de Requerimientos

• • •

A veces llamado exploración de los requerimientos Involucra trabajo técnico de grupo con los clientes para averiguar el dominio de la aplicación, los servicios que el sistema debe proporcionar y las restricciones operacionales propias del sistema Debe involucrar a los usuarios finales, administradores, ingenieros de mantenimiento, etc. Quienes son llamados líder especialista “stakeholders”

Problemas con el análisis

• • • •

Los especialistas (stakeholders) no saben realmente lo que quieren Éstos expresan requerimientos en sus términos propios Diferentes especialistas pueden tener requerimientos en conflicto Los factores políticos y organizacionales pueden influir en los requerimientos del sistema

19

Grupo para el Desarrollo de Tecnologías de Software

•

Los requerimientos cambian durante el proceso de análisis. Y pueden surgir nuevos especialistas

Factores Sociales y Organizacionales

• • • •

Los sistemas de software son usados en un contexto social y organizacional Esto puede influir o aun dominar los requerimientos del sistema Los factores sociales y organizacionales no son sólo puntos de vista, sino que su influyen sobre todos los puntos de vista Un buen análisis debe ser sensitivo a esos factores pero actualmente no hay un modo sistemático de abordar su análisis

Un ejemplo. Considere un sistema que permite al Director General acceder a la información sin pasar a través de los administradores intermedios

• • •

El estatus administrativo. El Director General pueden sentir que es muy importante para tocar un teclado. Esto puede limitar el tipo de interface empleada en el sistema Las responsabilidades administrativas. Los administradores pueden tener tiempo ininterrumpido para aprender a manejar el sistema Resistencia organizacional. Los directivos intermedios quienes serán consultados pueden proporcionar deliberadamente información incompleta ó equivocada, así que el sistema puede fallar

Análisis Etnográfico

• • • •

Es muy importante estudiar y observar cómo trabaja la gente Las personas no tienen que explicar o articular su trabajo Los factores sociales y organizacionales de importancia deben ser observados Estudios etnográficos han mostrado que el trabajo usualmente es más abundante y más complejo que lo sugerido por los modelos de sistemas sencillos

El enfoque etnográfico combina tecnología con prototipado. El desarrollo de un prototipo trasciende en preguntas sin respuesta lo cual enfoca el análisis etnográfico. La etnografía es que estudia las practicas existentes, las cuales pueden tener alguna base histórica que ya no es relevante El uso de la etnografía en el análisis de requerimientos necesita ser desarrollado tal que pueda ser combinado con métodos más sistemáticos Conforme la importancia de los factores humanos, sociales y organizacionales se vuelven más ampliamente reconocidos, estos métodos son promisoriamente desarrollados Resumen

• • • • •

Deben emplearse métodos estructurados en el análisis de requerimientos Estos deben incluir un modelo del proceso, notaciones de modelado del sistema, reglas y apuntes para el modelado del sistema y reportes estándar El método VORD orientado a puntos de vista aísla los puntos de vista que son externos al sistema Los límites entre el sistema y su ambiente deben ser definidos Los factores sociales y organizacionales tienen mucha influencia en los requerimientos

Herramientas I 20

Grupo para el Desarrollo de Tecnologías de Software

Entrevistas y cuestionarios Sistemas existentes Grabaciones de video y audio Brainstorming (tormenta de ideas) Arqueología de documentos Aprendiz Observación Entrevistas y cuestionarios Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o grupos, información que se obtiene conversando con el encuestado. Para la realización de las entrevistas debemos coordinar previamente la fecha y hora, y debemos realizar un plan de agenda, en el cual hacemos un punteo del objetivo de la entrevista. Por ejemplo, en la primer entrevista estableceremos un plan de comunicación, en el cual se intercambiarán los teléfonos, celulares, direcciones de e-mail y horarios de contacto. Para realizar las entrevistas, conviene llevar preparado un cuestionario. En términos generales, un cuestionario consiste en un conjunto de preguntas presentadas a una persona para su respuesta. La forma de la pregunta puede influir en las respuestas, por lo que hay que planearlas cuidadosamente. Las preguntas suelen distinguirse en dos categorías: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminología. Generalmente estas son más reveladoras, ya que los interrogados no están limitados en sus respuestas. Son especialmente útiles en la etapa exploratoria de la investigación, cuando el AN busca penetrar en el pensamiento del encuestado. A continuación se presentan algunos ejemplos de preguntas abiertas: ¿Cuál es la razón por la que quiere resolver este problema? ¿Cómo se resuelve el problema actualmente? ¿Cuál es el valor de una solución exitosa? ¿Quién usará el sistema que se va a construir? ¿Cómo desearía llevar a cabo esta actividad? Por su parte, las preguntas cerradas predeterminan todas las posibles respuestas y el interrogado elige entre las opciones presentadas. Estas preguntas las podemos utilizar cuando estamos estableciendo el criterio de priorización de los casos de uso con el cliente. Para cada uno preguntamos si es a corto plazo, a futuro, o Indispensable. Como vemos, la respuesta está acotada a tres opciones. También podemos volver a utilizarla cuando tenemos que negociar algún requerimiento con el cliente. Sistemas existentes Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfases de usuario, observando el tipo de información que se maneja y cómo es manejada. Esto puede ser útil para descubrir información importante a tener en cuenta, información que tal vez el cliente/usuario haya fallado en comunicar. También es útil analizar las distintas salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas.

21

Grupo para el Desarrollo de Tecnologías de Software

Luego de este análisis también podemos realizar una tormenta de ideas y así obtener requerimientos sumamente interesantes Desde mi punto de vista y, aunque requiere de cierto grado de trabajo (investigación y análisis), la podemos realizar a priori sin que intervenga el cliente/usuario; para ello, existen en internet cantidad de demos de productos que pueden resultar similares y, también, podemos establecer contacto con profesionales que desarrollan sistemas de características comparables. Otra ventaja que presenta esta técnica es que como estos sistemas ya están en producción, ya han pasado por la curva de aprendizaje del dominio del problema. Entonces, cuando analizamos estos sistemas, tenemos que tratar de pensar, por ejemplo, por qué manejan cierta información y para qué sirve, lo que resultará de suma utilidad para nuestro cliente. También es recomendable que luego de haber analizado el sistema, se lo mostremos al cliente/usuario, ya que por su experiencia puede sugerir importantes ideas nuevas. Grabaciones de video y de audio Básicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algún proceso en particular. En cuanto a su función de apoyo, es importante por cuanto permite centrar la atención en la entrevista en sí en vez de distraerse tomando notas de todo lo que se dice. Cuando se está grabando la conversación, basta con "puntear" en una libreta los temas tratados para después tener una guía básica de los temas tratados y saber en qué lugar de la grabación buscar. Además, permite analizar los temas con más detenimiento y con una visión más global, pues ya se ha conversado sobre todos los puntos necesarios y se han visto los procesos ad hoc. Cuando se trata de analizar algún proceso en particular, su ayuda es inestimable (sobretodo las filmaciones de video) ya que permite ver y analizar en detalle ese proceso la cantidad de veces que sea necesario. Y no olvidemos que filmando el lugar de trabajo estamos capturando el proceso de trabajo, lo que evita que impongamos nuestras expectativas y preferencias. Para finalizar, mencionamos que siempre es conveniente comenzar las grabaciones con preguntas poco importantes que sirvan para "relajar el ambiente", ya que el entrevistado puede ponerse nervioso durante los primeros minutos de grabación. Debemos darle tiempo a las personas para que se distiendan y se sientan cómodas con la idea de ser grabados o filmados. Brainstorming (tormenta de ideas) Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", etc. Las reglas básicas a seguir son:

•

Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas.

22

Grupo para el Desarrollo de Tecnologías de Software

•

•

Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generación de ideas. Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil. A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva. Escribir las ideas sin censura.

Arqueología de documentos Con la aplicación de esta herramienta se tratan de determinar posibles requerimientos sobre la base de inspeccionar la documentación utilizada por la empresa; por ejemplo, boletas, facturas, remitos, etc. Esta herramienta sirve más que nada como complemento de las demás técnicas, y nos ayuda a obtener información que de otra manera sería sumamente difícil conseguir. Por ejemplo, en las facturas podemos encontrar información que no se pensaba manejar y que en definitiva resulta de suma utilidad, como un número propio de la empresa que se utiliza para saber el orden que tiene la factura en la carpeta y que permite encontrar las copias del documento con mayor rapidez. En definitiva, se debe recolectar cualquier formulario o documento que sea utilizado para registrar o enviar información. Para el análisis de cada uno de estos documentos, debemos realizar algunas preguntas, como: ¿Cuál es el propósito de este documento? ¿Quién lo usa? ¿Por qué? ¿Para qué? ¿Cuáles son las tareas que realizan con este documento? ¿Se puede encontrar una relación entre los documentos? ¿Cuál es el proceso que realiza la conexión? ¿Cuál es el documento que da más problemas a los usuarios? Aprendiz Esta herramienta se basa en la idea del maestro y el aprendiz, y es una buena forma de observar el trabajo real. Aquí, el aprendiz es representado por el AN, y el usuario/cliente cumple el rol de maestro. El aprendiz se sienta con el maestro a aprender por medio de la observación, haciendo preguntas como ¿por qué hizo eso? y ¿qué significa eso?, y también realizando algún trabajo bajo la supervisión del maestro. Esta técnica puede ser combinada con la herramienta de modelo conceptual. A medida que el trabajo es observado y explicado, el AN puede realizar bosquejos para cada una de las tareas realizadas, y también puede bosquejar como se conectan por medio de los distintos flujos de datos. La aplicación de esta herramienta es muy útil, ya que a veces es difícil para el cliente/usuario el explicar cómo realiza su trabajo. Es también una técnica apropiada para un proyecto donde el problema no es estructurado, ya que es una de las mejores formas de obtener el conocimiento que se encuentra en la "cabeza" del cliente. Una de las posibles objeciones que se le pueden hacer a esta herramienta es que su implementación requiere de mucho tiempo.

23

Grupo para el Desarrollo de Tecnologías de Software

Observación Es sumamente difícil describir cómo hacer el nudo de un calzado deportivo, pero es sumamente fácil mostrar los pasos para hacerlo. Observar como se hacen las cosas es una buena manera de entender lo que estas requieren. Conectarse íntimamente con la cultura de la organización, vivirla, es una herramienta que debe ser tomada en cuenta. También podemos realizar filmaciones del lugar de trabajo, para luego observarlas y analizarlas, buscando patrones, procesos, problemas, etc. Siempre tenemos que estar atentos a lo que sucede en el entorno de la organización; por ejemplo, ver cómo resuelven un problema que surge, como un llamado telefónico que puede ocurrir mientras estamos presentes. Dentro de la estrategia de observar tenemos que tratar de buscar estructuras y patrones. La estructura del trabajo para los usuarios suele ser invisible, por lo que será nuestro trabajo realizar las abstracciones necesarias.

Herramientas II Run Use Case WorkShop Prototipos Análisis FODA Cadena de Valor Modelo de Clase Conceptual Diagrama de Pescado Glosario DCO ESRE QFD Check-List Run Use Case WorkShop (Talleres de Trabajo basados en Casos de Uso) Estos talleres de trabajo se realizan entre el cliente/usuario y el equipo de requerimientos. La primer parte del WorkShop consiste en generar los escenarios. Para esto se necesita la información que tiene para brindar el usuario/cliente. La idea es conversar por medio de los casos de uso y extraer de los usuarios las cosas esenciales que suceden cuando ocurre un evento determinado. Así, tratamos de definir la serie de usuarios y reconocer los pasos que se realizan para el caso de uso en estudio. Luego preguntamos si los pasos registrados están bien o si hay que cambiarlos o mejorarlos. Como resultado de este proceso obtenemos un excelente bosquejo del caso de uso. Una vez finalizada la etapa anterior, el equipo de requerimientos retorna a la oficina a especificar y deducir los requerimientos, a partir del conocimiento previamente adquirido. Prototipos Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no estén demasiado claros o que no estemos muy seguros de haber entendido

24

Grupo para el Desarrollo de Tecnologías de Software

correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final. Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado en base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva. Los prototipos se pueden clasificar en: Prototipo evolutivo Por ejemplo, cuando el usuario no puede o no está dispuesto a articular sus requerimientos de ninguna forma, sólo se podrán determinar mediante un proceso de ensayo y error. Así se van realizando evoluciones sobre la base del mismo prototipo hasta determinar claramente los requerimientos. Prototipo Bosquejado Para realizar esta clase de prototipo nos apoyamos, por un lado, en el rol del analista de requerimientos (AN), simulando las respuestas del sistema y realizando bosquejos de las interfases de usuario; y, por otro, el usuario, que es quien realiza las entradas ("utiliza el prototipo"). También podemos llevar el caso de uso y bosquejar la interfase de usuario y, mediante el diálogo, manejamos la interactividad entre el usuario y el sistema. Una de las ventajas más importantes es el poco esfuerzo que realizamos para aplicar los cambios. Como desventaja podemos mencionar que si bien capturamos la idea, el usuario no percibe como será realmente el diálogo hombre-máquina, sobre todo si existe un requerimiento no funcional como el de usabilidad. Prototipo Tangible/usable Los términos tangible y usable se refieren a desarrollar una aplicación (software) que el usuario pueda utilizar, es decir, con la cual pueda interactuar como si fuera la aplicación final. Cualquiera sea la herramienta de software, que elijamos utilizar, para desarrollar el prototipo, debemos recordar los siguientes puntos:

• • •

Debe demandar poco esfuerzo para realizar los cambios Debe poseer amplia flexibilidad para el manejo de las interfases de usuario. Debe consumir poco tiempo para generar un nuevo prototipo (maqueta).

Cabe remarcar que tenemos que dejar bien en claro al usuario/cliente que se trata de un prototipo y que no es el producto final; para explicar esta diferencia podemos hacer una analogía con las maquetas de los arquitectos. El prototipo tangible/usable también resulta de suma utilidad cuando nos encontramos frente a un requerimiento no funcional de usabilidad, más precisamente, el de facilidad de uso. Entre las desventajas más importantes de los prototipos que podemos mencionar, se encuentran:

•

Costo de entrenamiento/capacitación en la herramienta

25

Grupo para el Desarrollo de Tecnologías de Software

• • •

Costo de realizar el prototipo. Problema de calendario. Incompletitud (puede confundir a los usuarios, haciéndolos pensar que el producto final quedará como el prototipo, incompleto).

Análisis FODA Con este análisis se intentan identificar las principales fortalezas, oportunidades, debilidades y amenazas con las que se enfrenta una empresa. Entonces, por un lado, tenemos las oportunidades y las amenazas, que se refieren a los factores externos que pueden afectar el futuro del negocio. Por otro lado, se encuentran las fuerzas y debilidades que son factores internos; estas fuerzas señalan ciertas estrategias cuya aplicación podría conducir al éxito, mientras que las debilidades señalan aquello que la empresa debe corregir.

Esta herramienta es sumamente útil para analizar la situación de una empresa y ver de qué forma podemos ayudar a disminuir las debilidades y amenazas, y cómo podemos aprovechar las oportunidades o cómo podemos crear nuevas oportunidades y cómo hacer aún más fuertes las fortalezas. También nos es útil para analizar el impacto de la solución planteada en cada uno de los cuadros. Cadena de valor Todas las empresas son una colección de actividades que se llevan a cabo para diseñar, producir, distribuir, entregar y apoyar a su producto. La cadena de valor divide las empresas en nueve actividades estratégicas a fin de comprender el comportamiento de los costos en determinado negocio o industria y en las fuentes de diferenciación presentes y futuras. En este análisis se deben examinar los costos y el funcionamiento de cada una de las actividades productoras de valor, tratando de mejorarlos.

26

Grupo para el Desarrollo de Tecnologías de Software

Con esta herramienta podemos analizar los flujos de información que intervienen en las distintas actividades. Sirve también, por ejemplo, en el caso de que existan sistemas operacionales automatizados, para investigar qué tipo de información maneja y para qué se utiliza. Analizando este modelo, podemos buscar la forma en la cual el sistema puede ayudar a obtener mayor valor para la actividad o conjunto de actividades estudiadas. Modelo de clase conceptual | Diagrama Conceptual | Diagrama de Clases Conceptual Un modelo conceptual es una representación de conceptos del dominio del problema. [Fowler96]. Permite mostrar conceptos, asociaciones entre conceptos y atributos de conceptos. La creación del modelo también ayuda a comprender la terminología del dominio y comunica cuáles son los términos importantes y las relaciones existentes entre ellos. Concepto: categoría de idea o cosas. La intención del concepto es la descripción de sus atributos, operaciones y significado. [Craig, L. 1999] Para representar un concepto podemos basarnos en la metodología orientada a objetos, utilizando las clases como forma de representar el concepto, dado que una clase representa un concepto del dominio del problema que abarca un amplio espectro, como un pedido, una máquina, una tarea, un trabajo, etc. Esta herramienta puede ser utilizada para capturar el vocabulario del sistema que se está desarrollando. Mediante ella podemos incluir abstracciones que forman parte del dominio. Para especificar el modelo conceptual utilizamos el diagrama de clases en el cual mostramos las relaciones existentes entre las clases. Es decir, mostramos los conceptos que se manejan en el negocio y como se relacionan entre sí. Es una buena forma para obtener un idea general de cómo funciona el negocio (relaciones entre las clases/concepto), y capturar vocabulario y conceptos (clase). También es de ayuda para incluir nuevos conceptos al glosario. Diagrama de pescado (Ishikawa Diagram, Cause-and-Effect o Fishbone Diagram)

27

Grupo para el Desarrollo de Tecnologías de Software

Es una antigua pero útil herramienta que sirve, en el proceso de IR, para analizar problemas y comprender cuáles son sus causas. Por ejemplo,supongamos que es necesario analizar el costo de los distintos componentes, en los cuales intervienen procesos, tecnología, gente. En la figura que se presenta como ejemplo del diagrama de pescado, se analizan las posibles causas por la que los empleados no están contentos con el trabajo que realizan.

Como vemos en este diagrama, se distinguen 4 categorías básicas: empleado, entorno, proceso, maquinaria (tengamos en cuenta que la aparición de estas categorías va a depender del caso que se esté estudiando). En dicha figura vemos causas relacionadas con los trabajadores, con el entorno, la maquinaria y el proceso en sí. Por ejemplo, se analiza una posible causa relacionada con la capacitación de los empleados, y otra que es el estado antiguo de la maquinaria de trabajo. Con esta herramienta podemos analizar cómo impacta la solución planteada para un requerimiento dado. Por ejemplo, cómo afecta al trabajo diario del empleado. También en el caso de que la solución planteada interactúe con otros sistemas existentes (modificando, consultando o intercambiando información) el diagrama de pescado nos permite analizar los posibles problemas que pueden surgir. Esta herramienta la podemos utilizar conjuntamente con una tormenta de ideas (brainstorming), para ayudarnos a ordenar las posibles soluciones a un problema. Es decir, por un lado generamos ideas y luego utlizamos esta herramienta para organizarlas. Glosario El glosario es una simple lista de términos en donde se explica su significado. En esta lista se incluyen y definen todos los términos que requieren explicación, mejorando así la comunicación intergrupal y la ocmunicación con el cliente, y mitigando el riesgo de malos entendidos. Los términos que se incluyen provienen de todas las áreas del proyecto: casos de uso, terminología propia del negocio, etc. El glosario se va actualizando durante el transcuros del proceso de IR, perfeccionándolo en cada nuevo ciclo. ¿Cómo hacerlo? Para realizar el glosario utilizamos dos columnas; en la primera ingresamos el nombre del término y, en la segunda, ingresamos su descripción. Es importante ordenar alfabéticamente esta tabla por Término, para así facilitar las consultas.

28

Grupo para el Desarrollo de Tecnologías de Software

DCO | Diagrama de actividad El objetivo del DCO (Documento de Concepto de Operaciones) es el de comprender el entorno en el cual se encuentra el negocio, describiendo su funcionamiento interno y su relación con el ambiente. Para la construcción de este documento podemos consultar la plantilla base del DCO, brindada por ORTsf. Los puntos tratados en el documento básicamente son:

• • • • • •

Análisis del entorno Descripción general Organigrama de la empresa Misión/visión. Políticas de desarrollo, de servicios, comercial, de personal, de dirección, etc. Proceso abstracto del Negocio (ABP). El ABP abstrae los atributos y comportamientos esenciales de los procesos del negocio; permite modelar recursivamente la empresa en sus distintos niveles.

También podemos incluir otras herramientas como el análisis FODA y la cadena de valor. Diagrama de Actividad Para representar un proceso de negocio podemos utilizar otra de las herramientas que nos proporciona el UML, que es el diagrama de actividad. El diagrama de actividad o diagrama de proceso, se asemeja a un mapa de procedimientos, mostrando el flujo de actividades: se toman decisiones (bifurcaciones) de acuerdo a las condiciones (condición de guarda), para luego pasar a la siguiente actividad o estado (transición). Este modelo también permite representar actividades que ocurren en paralelo, o aquellos casos en los que una única actividad desencadena más de una tarea (división de control), o cuando se unen dos o más actividades para formar una tercera (unión de control). Componentes del diagrama: Bifurcación. Una bifurcación puede tener una transición de entrada y dos o más de salida; en cada una de estas salidas se coloca una expresión boolena, que se evalúa al ingresar en la bifurcación. División y unión. Una división puede tener una transición de entrada y dos o más transiciones de salida. Después de la división, las actividades asociadas de cada uno de estos caminos continúan en paralelo. Por su parte, una unión puede tener dos o más transiciones de entrada y una transicion de salida. Transiciones. Cuando finaliza una actividad, el flujo de control pasa inmediatamente al siguiente estado de accción o estado de actividad. Este flujo se especifica con transiciones que muestran el camino de un estado de actividad al siguiente

29

Grupo para el Desarrollo de Tecnologías de Software

Documento ESRE | Casos de uso El objetivo del documento ESRE (Documento de Especificación de Requerimientos) es el de especificar los requerimientos del sistema, o sea "qué" debe hacer el sistema. Solamente se incluyen los requerimientos del producto. Estos requerimientos los podemos clasificar en dos grandes categorías, los no-funcionales y los funcionales. Los no-funcionales definen las caracteristícas que indican cómo el sistema debe realizar su trabajo; por ejemplo, eficiencia, hardware necesario, software, etc. Por su parte, los requerimientos funcionales definen qué hace el sistema; básicamente describen todas las entradas y salidas, y las relaciones respectivas, relaciones que el sistema debe manejar. Resumiendo, y como el nombre lo indica, los requerimientos funcionales describen las funciones del sistema. En este documento debemos colocar la lista de requerimientos con las respectivas referencias a los documentos de todos los casos de uso que satifacen los requerimientos. Para la construcción del ESRE, ORTsf brinda una plantilla base en la cual se detallan específicamente cada uno de los puntos correspondientes. Lista de requerimientos La lista de requerimientos forma parte del documento de especificación de requerimientos (ESRE). En este documento se listan los requerimientos funcionales que el sistema debe satisfacer.

30

Grupo para el Desarrollo de Tecnologías de Software

Casos de uso El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. [Jacobson92]. Es una técnica diseñada para especificar el comportamiento de un sistema. Este documento describe la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor. No es una simple historia específica de eventos específicos intercambiados entre el sistema y los actores o escenario, sino que es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. Los requerimientos se pueden expresar de diferentes formas, desde texto sin formato estricto hasta expresiones en un lenguaje formal, pasando por todas las formas intermedias. La mayoría de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. Un caso de uso típico debe incluir: Nombre del caso de uso Uno de los puntos del documento es el nombre del caso de uso, el cual comienza con un verbo para remarcar que se trata de un proceso, como por ejemplo: "comprar productos", "introducir un pedido", "definir proveedor". Actores (quiénes intervienen en el caso de uso) Suelen ser los papeles representados por personas; también pueden ser otros sistemas o máquinas que interactúan con el caso de uso. Más precisamente, se puede decir que un actor es un rol interpretado por una entidad. Una persona puede interpretar varios roles y, por lo tanto, representará a varios actores. Descripción del objetivo del caso de uso Esta debe expresar lo que ocurre desde el punto de vista del usuario. Referencia a los requerimientos específicos del sistema. Es un identificador que se corresponde con la lista de requerimientos; suele usarse una letra y un número como, por ejemplo, R1. Esta referencia puede indicar uno o varios requerimientos. Interfaz de usuario IU Es la forma por la cual el actor interactúa con el sistema. Por lo general es la pantalla del sistema. Descripcion del caso de uso Aquí se separa, por un lado, el comportamiento del usuario y, por otro, el del sistema. Esta descripción puede tener un curso básico o puede ser dividida en un básico y otros alternativos. El curso básico es la secuencia de transacciones más importantes que satisfacen el caso de uso; mientras que los cursos alternativos son variantes del curso básico y, usualmente, son usados para identificar los errores de operación del sistema.

Casa de calidad o QFD

31

Grupo para el Desarrollo de Tecnologías de Software

El esquema QFD (Quality Function Deployment) es una matriz que representa las casas de calidad, en las cuales las filas representan los "qué", o sea, la lista de los requerimientos, mientras que las columnas representan los "cómo", es decir, cómo se llevan a cabo los requerimientos (casos de uso). Casa de calidad: Requerimientos versus Casos de Uso. Dado un requerimiento, se marcan todos los casos de uso que lo implementan y, dado un caso de uso, se marcan todos los requerimientos en los que éste participa. Debemos recordar que todo requerimiento debe ser implementado a través de algún caso de uso y, que todo caso de uso debe satisfacer algún requerimiento. ¿Cómo hacerlo? Para realizar esta técnica podemos utilizar un planilla de cálculo, como EXCEL®. Aquí se ingresará, en la filas, los identificadores de los requerimientos correspondientes a la lista de requerimientos. Los identificadores están compuestos por una letra y un número, por ejemplo, R1. En tanto, en las columnas ingresamos un código que corresponde al identificador utilizado para cada uno de los casos de uso. Usualmente su formato está compuesto por letras y un número; por ejemplo, CU1. Luego tomamos un requerimiento, por ejemplo el R1, el cual está implementado por los casos de uso CU1 y CU3; entonces buscamos la intersección y marcamos con una cruz, como se ve en la planilla de ejemplo. No olvidemos que tenemos que verificar que todo requerimiento sea implementado por algún caso de uso y, que todo caso de uso satisface algún requerimiento. Por otra parte, también tenemos que verificar la lista de requerimientos y la lista de casos de uso, revisando que no existan cosas repetidas redactadas de diferente manera. Planilla de ejemplo: Requerimientos vs Casos de Uso Casos de Uso CU Requerimientos CU 1 ... 2 R1 R2 R3

...

CU 100

R 100 Checklist (lista de verificación) Esta herramienta es muy fácil de utilizar y proporciona una gran utilidad. En general es una lista de preguntas que el AN debe usar para evaluar cada requerimiento. Los AN deben verificar y marcar los puntos de esta lista mientras leen el documento de requerimientos. Cuando se descubren problemas potenciales, deben ser anotados, ya sea en los márgenes del documento, ya sea en una lista de análisis.

32

Grupo para el Desarrollo de Tecnologías de Software

Las checklist son útiles porque brindan un recordatorio de lo que se debe buscar y reducen las chances de pasar por alto alguna verificación importante. Y no sólo son útiles para verificar requerimientos; también se puede aplicar con los casos de uso y con los puntos a ser tratados en el plan de agenda. ¿Cómo hacerlo? Este análisis se puede implementar con una hoja de cálculo en donde las filas representan, por ejemplo, los distintos requerimientos, y las columnas representan los puntos a verificar (el contenido de la checklist). Entonces, se completan las intersecciones que correspondan con los comentarios sobre los problemas potenciales.

Modelos de la IR Un modelo es una simplificación de la realidad que incluye aquellos elementos que tienen una gran influencia y omite aquellos elementos que no son relevantes para el nivel de abstracción dado. En definitiva, los modelos son abstracciones simplificadas y estandarizadas de actividades repetitivas, generalmente producidos desde un punto de vista determinado, por lo que pueden existir diferentes modelos para un mismo proceso.

Sin embargo, en el caso del proceso de IR y desde una perspectiva "intelectual", podemos decir que todos esos diversos modelos parten de una misma base, un modelo "madre" que llamaremos "modelo-abstracto". Este tipo de modelo nos brinda una vista preliminar del proceso, una secuenciación aproximada y general de las actividades que luego deberemos realizar. Así, presentamos el siguiente ejemplo, en donde cada uno de los compartimientos cubre una sección particular del proceso.

Modelo tradicional en cascada Este modelo sugiere que los resultados de una tarea del proceso llevan a la siguiente, y así sucesivamente. En el ejemplo presentado, la extracción lleva al análisis, el análisis desencadena la documentación, y la documentación inicia la validación.

33

Grupo para el Desarrollo de Tecnologías de Software

Si vemos a este modelo como una descripción general del proceso, es un modelo útil. Sin embargo, debemos entender que la realidad del proceso de IR es mucho más compleja que lo que se vislumbra a partir del modelo en cascada: no existen fases claramente delimitadas ya que hay una retroalimentación constante entre las distintas etapas; los requerimientos del sistema van cambiando por circunstancias ajenas al proceso (como una ley nueva o un cambio de mercado que a su vez cambia las necesidades de la empresa) durante el desarrollo del mismo; se descubren problemas durante la validación que llevan a un cambio de requerimientos, etc.; y todo esto hará que más de una vez tengamos que volver "hacia atrás" en el proceso de IR. Modelo en espiral Un modo alternativo de presentar modelos de actividad que toma en cuenta la retroalimentación entre etapas y la repetición de tareas, es el llamado Modelo en Espiral. [Kotonya G.; Sommerville I. 1998].

En este diagrama, el uso de la espiral implica que las diferentes actividades de la ingeniería de requerimientos son repetidas hasta que se toma la decisión final, que es la aceptación del documento de especificación de requerimientos. Es decir, si en el diseño preliminar se encuentran problemas, entonces recorremos el ciclo nuevamente (extracción-análisis-especificación-validación) hasta que todos sean resueltos, que es lo mismo que decir que este ciclo continuará hasta que se pueda elaborar un documento aceptable. Pero también existen factores externos que pueden determinar la finalización del ciclo, como por ejemplo la presión por cumplir con un determinado cronograma. Luego del suscinto análisis de los dos modelos básicos antes mencionados, podemos concluir que dado el escenario de trabajo ("el analista se enfrenta a un dominio que desconoce y el cliente presenta un alto grado de incertidumbre con respecto al know-how de todos los procesos de su empresa") es más válida la

34

Grupo para el Desarrollo de Tecnologías de Software

aplicación del modelo en espiral para desarrollar el proceso de IR. Y es que el modelo en espiral representa de manera más real cómo se irán desarrollando las actividades del proceso; esto es, debido al desconocimiento del tema, se genera un grado demasiado alto de incertidumbre que sólo puede disminuirse al repetir el ciclo de trabajo una y otra vez, permitiendo así ajustar todos los parámetros, cada vez en mayor detalle, hasta lograr un resultado satisfactorio.

Casos de Uso I Breve reseña de UML Es el sucesor de la oleada de métodos de análisis y diseño Orientados a objetos (OOA&D) que surgió a finales de la década de 1980 y principios de la siguiente. Desde los 80 a los 90 ocurrió una explosión de metodológicas, mas de 50 presentadas. Entre ellas sobresalen las de 3 autores: Rumbaugh con OMT, Jacobson con Objectory y Booch con OOD. Booch fundó Rational en el 1991 luego en distintos momentos del 95 se le sumaron Jacobson y Rumbaugh. Desde los 90 en adelante, se trató de llegar a una consolidación entre las metodológicas de estos tres autores. Como resultado de la convergencia, unificación, estandarización, énfasis en ingeniería de software y desarrollo basado en componentes, a partir de mediados de 1996 nace UML (unified modeling lenguaje). Actualmente continúan trabajando en esta notación que tiene como base la metodología de Jacobson y complementos de Rumbaugh y Booch, la misma ya esta disponible en Ingles y lo estará en castellano a partir de diciembre de este año. En resumen,UML es un lenguaje de modelado OO de propósito general

En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño Orientado a Objetos. UML es el primer método en publicar un metamodelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un metamodelo autoreferencial (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse por si mismo El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones graficas que contienen toda la información relevante del sistema.

35

Grupo para el Desarrollo de Tecnologías de Software

Objetivos del UML

• • • • • • •

•

Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad del modelado contemporáneo de una forma directa y económica Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnología de componentes , el computo distribuido, ejecutabilidad, etc. Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el metamodelo a un costo bajo. Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras podrían desarrollarse encima del UML. Proporcionar semánticas suficientes para permitir el intercambio del modelado entre una gran variedad de herramientas Proporcionar semánticas suficientes para especificar la interfaz a bibliotecas para la comparticion y el almacenamiento de componentes del modelo. En general los objetivos de la OMG en el desarrollo de UML se centran: o Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el desarrollo e intercambio de modelos significativos. o Proporcionar mecanismo de extensión y especialización. o Ser independiente del proceso de desarrollo y de los lenguajes de programación. o Proporcionar una base formal para entender el lenguaje de modelado. o Fomentar el crecimiento del mercado de las herramientas OO. o Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones ,frameworks, patterns, y componentes. o Integrar las mejores practicas utilizadas hasta el momento. o El UML debe enfocarse como un lenguaje estándar de modelado y no como un proceso estándar. El UML debe ser aplicado en el contexto de un proceso, la experiencia ha mostrado que organizaciones diferentes y dominios del problema diferentes requieren diferentes procesos . Por ello se han centrado los esfuerzos en un metamodelo comun / que unifica la semánticas).

Se consideran fuera del ámbito del UML tanto lenguajes de programación, como las herramientas , como el proceso de software. Por ultimo mencionar que aunque UML abarca las técnicas existentes, es de esperar que aparezcan nuevas técnicas. EL UML se puede adaptar a estas nuevas técnicas ya que dispone de mecanismos de extensión que no necesitan redefinir el núcleo UML. Los Casos de Uso Un escenario de casos de uso es una descripción, que puede estar escrita en lenguaje natural , de una situación que una aplicación es capaz o no de manejar. Un caso de uso describe una forma en que un actor del mundo real (persona, organización o sistema externo) interacciona con el modelo. Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema debe hacer. Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario. En general , y aunque que a menudo se utilizan los términos caso de uso y escenario indistintamente , nos referimos a escenario como un camino dentro de un caso de uso , es decir, un camino que muestra una combinación especifica de condiciones en un caso de uso. El comportamiento del sistema de software se documenta mediante el modelo de casos de uso , que ilustra las funciones que se desean en el sistema ( casos de uso), su entorno ( actores), y

36

Grupo para el Desarrollo de Tecnologías de Software

las relaciones entre casos de uso y actores ( diagramas de caso de uso). El principal papel del modelo de casos de uso es el de permitir la comunicación entre los desarrolladores y los clientes o usuarios finales. Veamos un ejemplo de una llamada telefonica :

Definiciones

• • • • •

Un caso de uso describe cierta funcionalidad que el sistema informático debe ofrecer. Describe una secuencia de interacciones entre uno o más ACTORES y el sistema, como respuesta a un estímulo inicial: diferentes escenarios Describe una interacción típica entre un usuario y el sistema. Establece un objetivo concreto para el usuario Definen una función del sistema, asociándole un nombre y una descripción textual.

Diagrama Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. En la siguiente figura se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.

37

Grupo para el Desarrollo de Tecnologías de Software

Un diagrama de casos de uso consta de los siguientes elementos:

• • •

Actores Casos de uso Relaciones de Uso, Herencia y Comunicación

Actores Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Tipos de Actores Principales: personas que usan el sistema Secundarios: personas que mantienen o administran el sistema Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados Otros sistemas: sistemas con los que el sistema interactúa

Casos de Uso Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. Un escenario es una instancia de un caso de uso Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso

Relaciones de Uso, Herencia y Comunicación

Asociación (Comunicación)

38

Grupo para el Desarrollo de Tecnologías de Software

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

Herencia el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía

Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso () o de Herencia (). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. Construcción de Casos de Uso Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a cada Caso de Uso Preguntas clave: ¿cuáles son las tareas del actor? ¿qué información crea, guarda, modifica, destruye o lee el actor? ¿debe el actor notificar al sistema los cambios externos? ¿debe el sistema informar al actor de los cambios internos? La descripción del Caso de Uso comprende:

• • • • • •

el inicio: cuándo y qué actor lo produce? el fin: cuándo se produce y qué valor devuelve? la interacción actor-caso de uso: qué mensajes intercambian ambos? objetivo del caso de uso: ¿qué lleva a cabo o intenta? cronología y origen de las interacciones repeticiones de comportamiento: ¿qué operaciones son iteradas? situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?

Ejemplo de Descripción

39

Grupo para el Desarrollo de Tecnologías de Software

Casos de Uso II Según el Proceso Unificado de Desarrollo, los principales pasos para capturar los requerimientos son:

• • • • •

Identificación de actores y casos de uso Priorizar casos de uso detallar casos de uso Prototipar la interfaz de usuario Estructurar el Modelo de Casos de Uso

40

Grupo para el Desarrollo de Tecnologías de Software

Encontrar Actores y Casos de Uso Objetivos

• • • • •

Delimitar el sistema y su entorno Esbozar quién y qué (actores) interactuarán con el sistema, y qué funcionalidad (casos de uso) se espera del sistema Capturar y definir un glosario de términos comunes esenciales para poder describir detalladamente los casos de uso del sistema. Es la actividad más decisiva para obtener adecuadamente los requisitos responsabilidad del analista de sistemas Actividades (no tienen por qué seguir este orden) o establecer el límite del sistema: solo software, hardware y software como un todo, lo utiliza una persona, una organización,... o encontrar actores principales: los que tienen objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema para cada actor

41

Grupo para el Desarrollo de Tecnologías de Software

o o o

o

identificar sus objetivos de usuario definir los casos de uso que satisfagan los objetivos de 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. describir brevemente (descripción informal) cada caso de uso

42

Grupo para el Desarrollo de Tecnologías de Software

Actores

• • •

•

•

Representan entidades externas que interactúan (mantenimiento y/o operación) con el sistema puede ser un usuario o un sistema externo Un actor representa un rol: o no se corresponde directamente con personas concretas o toda persona que interactúa con el sistema tiene que estar representado al menos por un actor en el modelo de casos de uso Identificación de actores ¿qué grupos de usuarios necesitan el sistema para su trabajo? ¿qué usuarios realizan las funciones principales del sistema? ¿qué usuarios realizan funciones secundarias, como mantenimiento o administración? ¿existe algún sistema externo de hardware o software? Se da nombre a los actores y se describen brevemente sus papeles y para qué utilizan el sistema

Identificar actores principales y objetivos

•

•

Además de actores principales y objetivos obvios, se pueden utilizar diferentes preguntas para identificar otros menos evidentes: o ¿quién arranca y detiene el sistema? o ¿quién administra el sistema? o ¿quién gestiona los usuarios y la seguridad? o ¿es un actor el “tiempo” porque el sistema hace algo como respuesta a un evento de tiempo? o ¿quién evalúa la actividad o el rendimiento del sistema?... Tipos de actores o actor principal: tiene objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema (por ejemplo, el cajero) se identifica para encontrar los objetivos de usuario, que dirigen los casos de uso o actor de apoyo: proporciona un servicio (por ejemplo, información) al sistema en desarrollo. Por ejemplo, el servicio de autorización de pago). Normalmente es un sistema informático, pero puede ser una organización o una persona se identifica para clarificar las interfaces externas y los protocolos o actor pasivo: está interesado en el comportamiento del caso de uso, pero no es principal ni de apoyo. Por ejemplo, la Agencia Tributaria.

43

Grupo para el Desarrollo de Tecnologías de Software

se identifica para asegurar que todos los intereses necesarios se han identificado y satisfecho Actor principal

• •

Tienen objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema (acuden al sistema para que les ayude) La lista actor-objetivo recoge los actores principales y sus objetivos

El actor principal y los objetivos de usuario dependen del límite del sistema

Identificación de Casos de Uso

44

Grupo para el Desarrollo de Tecnologías de Software

Escenario (o instancia de caso de uso)

• • • •

Es una descripción narrativa de lo que la gente hace y experimenta cuando trata de utilizar una aplicación informática, es decir, una secuencia específica de acciones e interacciones entre los actores y el sistema objeto de estudio. Descripción concreta e informal de una sola característica del sistema, desde el punto de vista de un solo actor Los analistas y los usuarios escriben y refinan diversos escenarios para comprender mejor lo que debe hacer el sistema Identificación de escenarios o ¿qué tareas necesita el actor que realice el sistema? o ¿qué información consulta el actor? ¿quién crea esos datos? ¿se pueden modificar? ¿quién puede hacerlo? o ¿qué cambios externos necesita informar el actor al sistema? ¿cuándo y con qué frecuencia? o ¿de qué eventos necesita el actor que le informe el sistema? ¿cuándo y con qué frecuencia?

Caso de uso

• • •

Especifica todos los escenarios posibles para una determinada funcionalidad es iniciado por un actor Puede interactuar con otros actores • Representa un flujo de eventos completo a través del sistema, es decir, describe una serie de interacciones relacionadas que resultan de la

45

Grupo para el Desarrollo de Tecnologías de Software

inicialización del caso de uso.

Las tareas se pueden agrupar a muchos niveles de granularidad .Ejemplos:

• • • • • •

Definir estrategia de mercado Establecer política de descuentos Negociar contrato con proveedor Gestionar devoluciones de productos Iniciar sesión en el sistema Imprimir factura ...

Todos son casos de uso a diferentes niveles, dependiendo de los límites del sistema, actores y objetivos PREGUNTA: ¿a qué nivel y alcance deben expresarse los casos de uso? RESPUESTA: Para el análisis de requisitos de una aplicación informática, hay que centrarse en los casos de uso al nivel de los procesos de negocio elementales (EBP, Elementary Business Processes) EBP: Tarea realizada por una persona en un lugar, en un instante, como respuesta a un evento del negocio, que añade valor cuantificable para el negocio y deja los datos en un estado consistente. Por ejemplo, Autorizar Crédito, o Solicitar Precio

• • •

No es un pequeño paso como “eliminar línea de pedido”, o “imprimir factura”” no tarda días y múltiples sesiones como “negociar contrato con proveedor” Son los caso de uso “base”, pero puede haber otros

46

Grupo para el Desarrollo de Tecnologías de Software

•

Pueden existir casos de uso que no sean EBP: o subtareas de un caso de uso base. ejemplo: “Pago a Crédito” puede aparecer en varios casos de uso base, por lo que se puede separar en un caso de uso propio conectado a varios casos de uso base

Casos de uso y objetivos

• • •

Los actores tienen objetivos y utilizan las aplicaciones para ayudarles a satisfacerlos Por tanto, un caso de uso EBP se denomina caso de uso a nivel de objetivo de usuario, para remarcar que sirve para satisfacer un objetivo de un actor principal Procedimiento: 1. encontrar los objetivos de usuario 2. definir un caso de uso para cada uno excepción: agrupación de objetivos separados del tipo Altas-Bajas-ModificacionesConsultas, en casos de uso denominados Gestionar

Objetivos y casos de uso de subfunción

• • •

Ojetivo de subfunción: subobjetivos que dan soporte a un objetivo de usuario. Por ejemplo, para cumplir el objetivo Abrir Caja el cajero necesita identificarse en el sistema. Se representan objetivos de subfunción como casos de uso cuando la subfunción se repite o es una precondición en muchos casos de uso de nivel de objetivos deusuario Ejemplo: Identificar Usuario

47

Grupo para el Desarrollo de Tecnologías de Software

Casos de Uso III Relaciones entre Actores y Casos de Uso

•

•

Relaciones de comunicación entre actores y casos de uso o representan el flujo de información durante el caso de uso o se puede distinguir entre el actor que inicia el caso de uso y los demás actores que intervienen posteriormente o los casos de uso, identificados previamente a partir de los objetivos de los actores, se representan mediante óvalos y representan una tarea que el sistema en desarrollo tiene que incorporar Diagrama de Casos de Uso: representa el contexto del sistema: o límites del sistema o qué permanece fuera del sistema o cómo se utiliza el sistema o resume el comportamiento de un sistema y sus actores

Diagrama de Caso de Uso Sugerencias en la realización de diagramas de casos de uso

• • • •

En diagramas de contexto, utilizar únicamente casos de uso de nivel de objetivos de usuario Mostrar los actores que representen sistemas informáticos con una notación alternativa a los actores humanos Situar los actores humanos a la izquierda y los de apoyo a la derecha Lo realmente importante es la descripción de los casos de uso, y no tanto los diagramas

48

Grupo para el Desarrollo de Tecnologías de Software

Un ejemplo de un diagrama de Caso de Uso

Proceso Unificado Desarrollo dirigido por casos de uso los requisitos se recogen principalmente en el Modelo de Casos de Uso

49

Grupo para el Desarrollo de Tecnologías de Software

• • •

Los casos de uso son parte importante de la planificación de las iteraciones: el trabajo de una iteración se define en parte eligiendo algunos escenarios o casos de uso completos. Por tanto, son una entrda clave para realizar estimaciones las realizaciones de casos de uso dirigen el diseño, es decir, el equipo diseña objetos y subsistemas que colaboran para ejecutar o realizar los casos de uso El trabajo con los casos de uso se realiza a lo largo de las diversas iteraciones

Casos de uso en la fase de inicio

• • • • •

Fase breve (pocos días) Identificación de objetivos y personal involucrado determinar alcance del proyecto Elaboración lista actor-objetivo Iniciar diagrama de contexto de casos de uso Descripción de casos de uso o Casos de uso importante, complejos o arriesgados se escriben en formato breve o Entre el 10-20% de los casos de uso que representan las principales funciones o son arriesgados se escriben en formato completo o Escribir lista de intereses y personal involucrado para estos casos de uso decidir si se realiza un estudio más profundo (fase de elaboración) o se rechaza el proyecto

50

Grupo para el Desarrollo de Tecnologías de Software

o

ejemplo de un Modelo de Casos de Uso en la fase de inicio para un sistema de PDV:

Casos de uso en la elaboración

• • • • •

• •

Fase de múltiples iteraciones de duración fija Se construyen incrementalmente partes del sistema arriesgadas, de alto valor o significativas para la arquitectura Se identifican y clarifican la mayoría de los requisitos Retroalimentación de las fases de diseño e implementación Se pueden realizar talleres de requisitos en cada iteración: o no se estudian todos los casos de uso: se priorizan o se refinan los requisitos principales, que son inestables en las primeras iteraciones, estabilizándose en las últimas escritura y reescritura de la mayoría de los casos de uso, en formato completo Al final de la fase de elaboración o quedan descritos en detalle entre el 80 y el 90% de los casos de uso o quedan programadas partes del sistema (entre un 10 y un 15% del sistema) Casos de uso en la construcción o fase de múltiples iteraciones de duración fija, centrada en completar el sistema o puede ser necesario escribir o reescribir casos de uso menores (incluso puede necesitarse algún taller de requisitos) o el grado de cambio de los requisitos es mucho menor que en la elaboración, pues la mayoría de los casos de uso funcionales y no funcionales más importantes deben haberse estabilizado

Priorización de casos de uso

• •

•

Determinar cuáles son necesarios para el desarrollo en las primeras iteraciones y cuáles pueden dejarse para posteriores iteraciones Cuestiones a tener en cuenta: o casos de uso con dificultad de desarrollo o casos de uso imprescindibles para la puesta en marcha del sistema o organización del desarrollo incremental o disponibilidad de equipo de desarrollo Se revisa la priorización con el jefe de proyecto y se utiliza como entrada para la planificación de cada iteración del proyecto

51

Grupo para el Desarrollo de Tecnologías de Software

Detallar Casos de Uso

•

• • •

Objetivo principal: describir su flujo de sucesos en detalle o cómo comienza o cómo termina o cómo interactúan con los actores Se detalla paso a paso la secuencia de acciones del caso de uso Se trabaja estrechamente con los usuarios reales de los casos de uso Resultado: descripción detallada mediante texto y diagramas

52

Grupo para el Desarrollo de Tecnologías de Software

Descripción del Caso de Uso Secciones de la Descripción del Caso de Uso

• •

•

Actor principal: actor que recurre a los servicios del sistema para cumplir un objetivo Personal involucrado y lista de intereses o el caso de uso captura todo y sólo el comportamiento relacionado con la satisfacción de los intereses del personal involucrado o ejemplo:
Cajero: quiere entradas precisas, rápidas y sin errores de pago, ya que las pérdidas se deducen de su salario.
Vendedor: quiere que las comisiones de ventas estén actualizadas Precondiciones: o establecen lo que siempre debe cumplirse antes de comenzar un escenario en el caso de uso. o no se prueban en el caso de uso, sino que son condiciones que se asumen que son ciertas. o normalmente una precondición implica un escenario de otro caso de uso que se ha completado con éxito, como “inicio de sesión”, o “validación de usuario”. o ejemplo: el cajero se identifica y el sistema lo autentifica.

53

Grupo para el Desarrollo de Tecnologías de Software

•

Postcondiciones: o establecen qué debe cumplirse cuando el caso de uso se completa con éxito (bien el escenario principal de éxito o algún camino alternativo) o ejemplo: se registra la venta. El impuesto se calcula de manera correcta. Se actualizan la Contabilidad y el Inventario. Se registran las comisiones. Se genera el recibo.

Escenario principal de éxito (o flujo básico)

• • •

• •

Describe el camino de éxito típico que satisface los intereses del personal involucrado No suele incluir condiciones o bifurcaciones Recoge los pasos, que pueden ser de tres tipos: o una interacción entre actores o una validación (normalmente a cargo del sistema) o un cambio de estado realizado por el sistema (por ejemplo, registrando una venta o modificando un registro de la base de datos) El primer paso indica el evento que desencadena el comienzo del escenario Ejemplo: 1. El Cliente llega a un terminal PDV con mercancías para comprar 2. El Cajero comienza una nueva venta. 3. El Cajero introduce el identificador del artículo. 4. ... El Cajero repite los pasos 3-4 hasta que se indique 5. ...

Extensiones (o flujos alternativos)

• • •

•

• •

Indican todos los otros escenarios o bifurcaciones, tanto de éxito como de fracaso. La combinación del escenario principal y los escenarios de extensión deberían satisfacer casi todos los intereses del personal involucrado (algunos intereses se documentan como requisitos no funcionales) Ejemplos: o 3a. Identificador no válido 1. El Sistema señala el error y rechaza la entrada o 3b. Hay muchos artículos de la misma categoría y tener en cuenta una única identidad del artículo no es importante (por ejemplo, 6 cajas de leche de la misma marca). 1. El Cajero puede introducir el identificador de la categoría del artículo y la cantidad Un flujo alternativo tiene dos partes: o condición: algo que puede ser detectado por el sistema o el actor (el Sistema detecta un fallo de comunicación con el sistema de actualización de inventario) o manejo: se puede resumir en un paso o bien incluir una secuencia:
3-6a. 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 Si una extensión es muy compleja, se puede expresar como un caso de uso aparte Pueden incluirse condiciones de extensión que se pueden dar durante cualquiera de los pasos (por ejemplo, el sistema falla, o el Cliente cancela la compra)

54

Grupo para el Desarrollo de Tecnologías de Software

Requisitos Especiales

• • •

•

Se recoge cuando un requisito no funcional, atributo de calidad o restricción se relaciona de manera específica con un caso de uso Incluye cualidades 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. Ejemplo: o interfaz de usuario con pantalla táctil en un gran monitor de pantalla plana. El texto debe ser visible a un metro de distancia o Tiempo de respuesta para la autorización de crédito de 30 segundos al menos en el 90% de los casos En ocasiones resulta conveniente reunir al final todos los requisitos no funcionales en una especificación complementaria

Refinamiento

• • •

se incorporan detalles al caso de uso se describe el flujo de eventos en mayor detalle se mejora la descripción de las interacciones

55

Grupo para el Desarrollo de Tecnologías de Software

Ejemplo Caso de Uso Máquina Recicladota: Sistema que controla una máquina de reciclamiento de botellas, tarros y otros similares El sistema debe controlar y/o aceptar:

• •

• • •

Registrar el número de ítems ingresados. Imprimir un recibo cuando el usuario lo solicita: a.- Describe lo depositado b.- El valor de cada item c.- Total El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente: a.- Cuantos ítems han sido retornados en el día. b.- Al final de cada día el operador solicita un resumen de todo lo depositado en el día. El operador debe además poder cambiar: a,- Información asociada a ítems. b.- Dar una alarma en el caso de que: -Item se atora. -No hay más papel.

Como una primera aproximación identificamos a los actores que interactúan con el sistema:

56

Grupo para el Desarrollo de Tecnologías de Software

Luego, tenemos que un Cliente puede Depositar Items y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro...

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

57

Grupo para el Desarrollo de Tecnologías de Software

Modelo de Dominio I Introducción Elementos claves del modelado de dominio. Cuando se construye un modelo estático, lo primero que tenemos que hacer es identificar las clases apropiadas que representen la abstracción real que presenta el dominio del problema. La mejor fuente de clases, posiblemente son las declaraciones de alto nivel del problema, los requerimientos de bajo nivel y un conocimiento experto del espacio del problema. Posteriormente debemos de revisar la lista de clases candidatas y eliminar las que sean innecesarias. Estas pudieran ser clases redundantes, irrelevantes, incorrectas o vagas. Debemos de tomar algunas decisiones iniciales sobre generalización, al momento que construimos diagramas de clases. El modelado del dominio debe representar realmente el espacio del problema independiente del tiempo, ya que sirve como fundamento para el modelo estático de clases. Los 10 errores más frecuentes en el modelado de dominio son: 10.- No debemos asignar asociaciones de multiplicidad inmediatamente, ya que esto nos puede hacer perder tiempo y paralizar el análisis. 9.- No debemos de hacer un análisis de los objetos y acciones tan exhaustivo que nos vayamos de largo, ya que a mayor grado de detalle, menor abstracción. 8.-No debemos asignar operaciones a las clases sin antes explorar los diagramas de casos de uso y de secuencia. No es recomendable asignar operaciones durante el modelado de dominio, ya que no se cuenta con información suficiente para hacer una buena designación de operaciones y estados. 7.- No debemos de optimizar nuestro código para reusarlo antes de estar seguros de haber satisfecho los requerimientos del usuario. Esto se debe a que en este nivel, las clases no se encuentran completas, ya que en el modelado de dominio todavía no se asignan las operaciones y atributos.

58

Grupo para el Desarrollo de Tecnologías de Software

6.- No debemos debatir en cuando usar agregación o composición para asociaciones parte de, ya que esta decisión es un parte detallada del diseño. 5.- No debemos adelantarnos a especificar una estrategia de implementación si no hemos modelado el espacio del problema. Las estrategias de implementación son parte de la implementación, por lo que los diagramas de clases no deben llevar elementos que representen tecnologías específicas. 4.- No debemos de usar nombres difíciles de comprender en nuestras clases, si hay un nombre intuitivamente obvio. Entre mas obvio sea el nombre de la clases, será mas fácil para el equipo del proyecto identificarla. 3.- No debemos hacer directamente a construcciones de implementación como relaciones de amistad y clases parametrizadas, ya que estas son mas relevantes para el espacio de la solución que el del problema. 2.- No debemos crear un mapeo uno a uno entre las clases del dominio y las tablas de una base de datos relacional. En una reingeniería, las tablas delas bases de datos relacionales, pueden ser una buena fuente de clases de dominio, pero debemos tener cuidado, ya que pueden tener atributos que no necesariamente van juntos en un modelo de objetos. 1.- No debemos hacer modelos prematuros que envuelvan la construcción de soluciones llamativas, de patrones, que tienen poco o nada que ver con los problemas del usuario. Normalmente los patrones se hacen visibles durante el análisis de robustez. En la IR los casos de uso son una buena herramienta para capturar requisitos, pero siempre quedan aspectos sin resolver o que son de especial complejidad y hay que estudiar posteriormente: deben mantenerse lo más independientes posibles unos de otros, obviando detalles relativos a interacciones, concurrencia, recursos compartidos,.. ejemplo: Ingresar Dinero y Retirar Dinero son dos casos de uso que acceden a la misma cuenta y por tanto están relacionados deben escribirse utilizando el lenguaje del cliente: al usarse lenguaje natural se pierde poder expresivo y en la captura de requisitos pueden quedar sin describir adecuadamente detalles que requieren notaciones más formales Vemos que en desarrollo del proceso de la IR, podemos utilizar diferentes modelos:

Veamos cual es la diferencia entre los dos primeros modelos :

59

Grupo para el Desarrollo de Tecnologías de Software

Actividades del análisis en el proceso unificado

• • • •

Crear el Modelo de Dominio Refinar el Modelo de Casos de Uso Refinar la Especificación Complementaria Refinar el Glosario

Estas actividades se llevan a cabo a lo largo de varias iteraciones en la fase de elaboración

Modelo del dominio (o modelo conceptual) Es un artefacto de UML que muestra clases conceptuales significativas en un dominio del problema, es decir, en el mundo real. No muestra componentes software, clases software u objetos software con responsabilidades. Es el artefacto más importante en un análisis orientado a objetos (AOO). UML utiliza diagramas de clases para representar el modelo del dominio, que muestran:

• • •

Objetos del dominio o clases conceptuales Asociaciones entre las clases conceptuales Atributos de las clases conceptuales

Principal tarea: Identificar diferentes conceptos en el dominio del problema y documentar el resultado en un modelo del dominio Ejemplo: En el dominio de ventas pueden identificarse clases conceptuales como Tienda, Registro o Venta. El modelo del dominio se construye incrementalmente a lo largo de varias iteraciones en la fase de elaboración Pasos en la realización de un modelo del dominio

• • •

Identificar y listar las clases conceptuales candidatas Representarlas en un modelo del dominio Añadir las asociaciones necesarias para registrar las relaciones que hay que mantener en memoria

60

Grupo para el Desarrollo de Tecnologías de Software

•

Añadir los atributos necesarios para satisfacer los requisitos de información

En este caso es muy importante:

• • •

Utilizar el vocabulario del dominio al nombrar las clases conceptuales y atributos Excluir las características irrelevantes No añadir cosas que no se encuentran en el dominio del problema que se está estudiando

En un Modelo de Dominio no se deben incluir :

Clases conceptuales

61

Grupo para el Desarrollo de Tecnologías de Software

•

Informalmente: Una clase conceptual es una idea, cosa u objeto formalmente puede considerarse en términos de: o Símbolo: palabras o imágenes que representan una clase conceptual definición de la clase o Extensión: conjunto de ejemplos a los que se aplica la clase

Identificación de clases conceptuales

• •

Para cada escenario se identifican las clases conceptuales relacionadas con él mejor especificar en exceso un modelo del dominio con muchas clases conceptuales “de grano fino” que especificar por defecto Estrategias complementarias para identificar clases conceptuales o Utilización de una lista de categorías de clases conceptuales o Identificación de clases nominales

Identificación de clases conceptuales mediante una lista de categorías Se utiliza una lista de categorías habituales que normalmente merece la pena tener en cuenta

62

Grupo para el Desarrollo de Tecnologías de Software

Análisis del lenguaje natural: identificación de clases conceptuales mediante frases nominales

• • •

Heurística de Abbot (1983) Identificar nombres y frases nominales en las descripciones textuales de un dominio, considerándolos como clases conceptuales o atributos candidatos Punto débil: imprecisión del lenguaje natural, ambigüedades (sinónimos, redundancias,...) se realiza a partir de las descripciones completas de los casos de uso

63

Grupo para el Desarrollo de Tecnologías de Software

Lista de clases conceptuales candidatas del dominio

• •

Generada a partir de: o lista de categorías o análisis de lenguaje natural (frases nominales) Restringida a los requisitos que se están estudiando actualmente

Ejemplo: lista de clases candidatas del caso de uso Procesar Venta. Registro Artículo Tienda Venta Pago Catálogo de Productos

Especificación del Producto Línea de Ventas Cajero Cliente Encargado -----

informes: por lo general, no se recogen en el modelo de dominio porque muestran información derivada de otras fuentes, duplicando información. a discutir: ¿es el Recibo una clase conceptual? Modelo de Dominio II Clases conceptuales de especificación o descripción Se utilizan para especificar o describir otras clases. Una clase EspecificaciónDelArtículo no representa un Artículo, sino una descripción de la información sobre los artículos: aunque se vendan todos los elementos inventariados, eliminándose las correspondientes instancias software de Artículo, permanecerá la EspecificaciónDelArtículo

64

Grupo para el Desarrollo de Tecnologías de Software

estas clases son habituales en entornos de gestión (sistemas de compras, ventas, inventarios,...) y fabricación (descripciones de los productos fabricados) se usan cuando:

• • •

Se necesita la descripción de un artículo o servicio independientemente de la existencia actual de algún item de esos artículos o servicios La eliminación de instancias de las cosas que describen provocan pérdida de información que necesitaría mantenerse Reduce información redundante o duplicada

Reducción del salto en la representación (salto semántico): Una de las grandes ventajas de la tecnología de objetos : la reducción de la diferencia entre el modo en el que el personal involucrado concibe el dominio y su representación en el software Ejemplo:

• •

Un pago en el Modelo del Dominio es una clase conceptual (un concepto) Un pago en el Modelo de Diseño es una clase software no son lo mismo, pero el primero “inspiró” el nombre y definición del segundo

65

Grupo para el Desarrollo de Tecnologías de Software

Representar las clases en un modelo del dominio Se utiliza la notación de clase de UML

Representación de las Clases Conceptuales del Punto de Ventas

66

Grupo para el Desarrollo de Tecnologías de Software

Añadir las Asociaciones Necesarias Según UML, una asociación es “la relación semántica entre dos o más clasificadores que implica conexiones entre sus instancias”. Se registran las asociaciones:

• •

De las que es necesario conservar el conocimiento de la relación durante algún tiempo (por ejemplo, la relación entre LíneaPedido y Pedido) derivadas de la Lista de Asociaciones Comunes

Es importante registrar únicamente asociaciones útiles para mantener el diagrama legible. Es más importante dedicar tiempo a localizar las clases conceptuales que a identificar las asociaciones

Lista de asociaciones comunes Es una relación de categorías habituales que, normalmente, merece la pena ener en cuenta

67

Grupo para el Desarrollo de Tecnologías de Software

Nombre de Asociaciones

• •

Formato: NombreTipo – FraseVerbal – NombreTipo donde la frase verbal crea una secuencia legible y con significado en el contexto del modelo Normalmente la dirección por defecto para la lectura de los nombres de asociaciones es de izquierda a derecha o arriba abajo

68

Grupo para el Desarrollo de Tecnologías de Software

Multiplicidad Indica cuántas instancias de una clase A pueden asociarse con una instancia de una clase B

• •

En un momento concreto NO a lo largo de un periodo de tiempo

Indica una restricción de diseño que será (o podrá ser) reflejada en el software

Puede existir cualquier tipo de multiplicidad, pero en la práctica la mayoría de las asociaciones pertenecen a uno de los siguientes tipos :

•

• •

Asociación de uno a uno: tiene una multiplicidad de 1 a cada extremo. Significa que existe solamente un vínculo entre instancias de cada clase. Por ejemplo : OficialPolicía tiene exactamente un NúmeroIdentificación, y éste representa a uno y sólo a un OficialPolicía Asociación de uno a muchos: tiene una multiplicidad de 1 en un extremo y 0..n en el otro (a veces representado con un asterisco) Asociación de muchos a muchos: tiene una multiplicidad de 0..n o 1..n en ambos extremos. Indica que pueden existir una cantidad arbitraria de vínculos entre instancias de las dos clases. Es el tipo más complejo de asociación.

Pueden existir dos o más asociaciones entre dos clases conceptuales

69

Grupo para el Desarrollo de Tecnologías de Software

Navegabilidad Indica que es posible enviar mensajes en la dirección de la flecha en uno de los dos extremos de asociación no hay que especificarla hasta que el diagrama de clases sea estable

70

Grupo para el Desarrollo de Tecnologías de Software

Asociaciones Reflexivas

Modelo de Dominio III Continuación de Asociaciones Agregación Es un tipo de asociación que se utiliza para modelar las relaciones todo-parte entre las cosas. El todo se denomina compuesto

• • •

Normalmente se identifica en el Modelo de Diseño, pero puede ser útil o necesario identificar algunas relaciones de agregación en el Modelo del Dominio. Representación en UML: un rombo hueco o relleno en el extremo del compuesto de una asociación todo-parte El nombre de la asociación se suele excluir porque se piensa normalmente como Tieneparte

Agregación de composición

• • • •

La parte es un miembro de un único objeto compuesto y que existe una dependencia de existencia y disposición de la parte sobre el compuesto La multiplicidad en la parte del compuesto sólo puede ser 1 Ejemplo: en una relación Coche – Motor, el motor tiene sentido como tal (existe) únicamente si está asociado a un coche Representación en UML: un rombo relleno

71

Grupo para el Desarrollo de Tecnologías de Software

Agregación compartida

• • •

La multiplicidad en el extremo del compuesto puede ser más de uno: la parte puede estar simultáneamente en muchas instancias del compuesto Se utiliza para conceptos abstractos, no físicos Representación en UML: un rombo hueco

Identificación de la agregación

• •

Si hay duda, se descarta Se debe mostrar una agregación: o cuando el tiempo de vida de la parte está ligado al tiempo de vida del compuesto (existe una dependencia de creación – eliminación de la parte en el todo). o cuando existe un ensamblaje obvio todo-parte físico o lógico o cuando alguna propiedad del compuesto se propaga a las partes, como la ubicación o cuando las operaciones que se aplican sobre el compuesto se propagan a las partes, como la destrucción, movimiento o grabación

Generalización

•

•

• •

Actividad de identificar elementos comunes entre los conceptos y definir las relaciones de superclase (concepto general) y subclase (concepto especializado) Así, los conceptos se representan en jerarquías de clases. Superclase conceptual: su definición es más general y abarca más que la definición de una subclase Subclase conceptual: debe ser un miembro del conjunto de la superclase, es decir, es un tipo de superclase Todos los miembros del conjunto de una subclase conceptual son miembros del conjunto de su superclase

72

Grupo para el Desarrollo de Tecnologías de Software

Jerarquía de clases

• •

Las declaraciones sobre las superclases se aplican a las subclases Regla del 100%: el 100% de la definición de la superclase conceptual se debe de poder aplicar a la subclase. La subclase debe ajustarse al 100% de los atributos y asociaciones de la superclase

Cuando dividir una clase conceptual en subclases

• • • •

Cuando la subclase tiene atributos adicionales de interés Cuando la subclase tiene asociaciones adicionales de interés Cuando el concepto de la subclase funciona, se maneja, reacciona o se manipula de manera diferente a la superclase o a otras subclases, de alguna manera que es interesante. Cuando el concepto de la subclase representa una cosa animada (animal, maquinaria,...) que se comporta de manera diferente a la superclase o a otras subclases, de alguna manera que resulta interesante poner de manifiesto en el modelo del dominio.

73

Grupo para el Desarrollo de Tecnologías de Software

Cuando definir una superclase conceptual

• • • •

Cuando las subclases potenciales representan variaciones de un concepto similar Cuando las subclases se ajustarán a las reglas del 100% y la regla Es-Un-Tipo-De Cuando todas las subclases tienen un mismo atributo que se puede expresar en la superclase Cuando todas las subclases tienen la misma asociación que se puede unir y relacionar con la superclase

Jerarquías de clases y herencia en el software

•

La herencia o es un mecanismo software para hacer que las características de la superclase se apliquen a las subclases o es un concepto que no se utiliza en el Modelo del Dominio, pero sí cuando se pasa al Modelo de Diseño y Modelo de Implementación o las jerarquías de clases conceptuales del Modelo del Dominio pueden reflejarse o no en el Modelo de Diseño, dependiendo de las características del lenguaje y otras cuestiones

74

Grupo para el Desarrollo de Tecnologías de Software

Clases conceptuales abstractas Útil identificarlas pues se restringe las clases que pueden tener instancias concretas y por tanto se clarifican las reglas del dominio del problema Regla general: Si cada miembro de una clase C debe ser también un miembro de una subclase, entonces las clase C se denomina clase conceptual abstracta.

Clases asociación

• •

En un modelo del dominio, si una clase C puede tener simultáneamente muchos valores para el mismo tipo de atributo A, no se colocará este atributo en C, sino en otra clase asociada con C. Ejemplo: una Persona puede tener muchos números de teléfono. Se colocará el número de teléfono en otra clase, como

75

Grupo para el Desarrollo de Tecnologías de Software

•

NúmeroTeléfono o InformaciónDeContacto, y se asocian muchas de estas clases a Persona. Guía. Hay un atributo relacionado con una asociación el tiempo de vida de las instancias de la clase asociación depende de la asociación existe una asociación muchos-a- muchos entre dos conceptos, e información asociada con la propia asociación

Modelo de Dominio IV Atributos

76

Grupo para el Desarrollo de Tecnologías de Software

• • • •

Es un valor de datos lógico de un objeto Se incluyen aquellos atributos para los que los requisitos indican la necesidad de registrar su información Ejemplo: un recibo recoge la información de una venta, incluyendo fecha y hora. La dirección quiere conocer fecha y hora de las ventas. Por tanto, la clase Venta necesita los atributos fecha y hora Notación UML: se muestran en el segundo compartimento del rectángulo de la clase. Los tipos se muestran opcionalmente

Tipos de Atributos

•

• •

En el modelo de dominio deben usarse preferiblemente: o atributos simples: no deben ser conceptos de dominio complejos (Venta, Aeropuerto, ...) o tipos de datos: principalmente booleano, fecha, número, string y hora otros: Dirección, Color, Teléfono, NIF, Código Postal,... Importante: relacionar las clases conceptuales con una asociación, no con un atributo. En caso de duda, se debe optar por usar una clase conceptual antes que un atributo. Durante el diseño y la implementación podrán aparecer nuevos atributos que referencian a otros objetos software complejos, pero que no tienen sentido en el Modelo de Dominio

Tipos de datos como clases no primitivas

•

Un atributo que puede considerarse como un tipo de dato primitivo puede representarse como una clase no primitiva si: o está compuesto de secciones separadas (número de teléfono, nombre de persona,...)

77

Grupo para el Desarrollo de Tecnologías de Software

hay operaciones asociadas con él, como algoritmos de validación (NIF, número de la Seguridad Social,...) o tiene otros atributos (el precio de una oferta puede tener una fecha de comienzo y otra de fin) o es una cantidad con una unidad de medida (la cantidad de un pago tiene una unidad monetaria) o es una abstracción de uno o más tipos con estas cualidades (un identificador de artículo en el dominio de ventas es una generalización de tipos como el Código de Producto Universal –UPC- o el Número de Artículo Europeo – EAN -) Ejemplo: en el sistema de Punto de Venta las clases ArticuloID, Direccion y Cantidad son tipos de datos pero se pueden considerar como clases independiente debido a sus características Representación: como clase independiente o en el compartimento de atributos de la clase, dependiendo de la utilización del modelo del dominio y la importancia de los conceptos en el dominio

o

• •

Cantidades y unidades de los atributos • • •

La mayoría de las cantidades numéricas llevan unidades asociadas no deben representarse únicamente como números Ejemplos: precio, velocidad, peso ... Solución: representar la cantidad como una clase conceptual aparte con una unidad asociada

78

Grupo para el Desarrollo de Tecnologías de Software

Un Modelo de Dominio

Utilización de Paquetes

•

•

Los modelos de dominio se pueden dividir en paquetes cuando han crecido demasiado o Los paquetes incluyen conceptos fuertemente relacionados o Mejora la comprensión o Permite realizar tareas de análisis en paralelo, de tal forma que diferentes equipos o personas analizan diferentes subdominios Notación de paquetes en UML o Paquete: se representa por una carpeta o Pueden mostrarse dentro de un paquete otros paquetes subordinados o Un elemento pertenece al paquete donde está definido, pero puede ser referenciado en otros paquetes, utilizando el formato NombrePaquete::NombreElemento

79

Grupo para el Desarrollo de Tecnologías de Software

80

Grupo para el Desarrollo de Tecnologías de Software

Cómo dividir el Modelo del Dominio

•

•

Se deben poner juntos en paquetes los elementos que: o se encuentran en el mismo área de interés (están estrechamente relacionados por conceptos u objetivos) o están juntos en una jerarquía de clases o participan en los mismos casos de uso o están fuertemente asociados Consejo o utilizar un paquete Dominio que será el raíz de todos los elementos relacionados con el modelo del dominio o utilizar un paquete Elementos Básicos, o Conceptos Comunes, para englobar todos los elementos compartidos, comunes a otros elementos, básicos,...

81

Grupo para el Desarrollo de Tecnologías de Software

Bibliografía

• • • • • • • • • • • • • • • •

[Arango J. 2002] Tormenta de Ideas. Colombia. Universidad EAFIT.Disponible enInternet:http://www.eafit.edu.co/tda/boletin/TORMENTA%20DE%20IDEAS.htm [Booch, G. ; Jacobson, I. RumbaughT, J. 1999] El Lenguaje Unificado de Modelado. España. Addison Wesley. [Booch, G. ; Jacobson, I. RumbaughT, J. 2000] El Lenguaje Unificado de Modelado. Manual de Referencia. España. Addison Wesley. [Brooks, 1987] No Silver Bullet. Essence and Accident in Software Engineering. USA. IEEE Computer. [Ceria, S. 2000] Ingeniería de software I. Casos de Uso. Un Método Practico para Explorar Requerimientos. Argentina. Universidad de Buenos Aires UBA. [Craing, L. 1999] UML Y PATRONES. Introducción al análisis y diseño orientado a objetos. España. Pearson. [David M. 1998] Ishikawa Fise Bone Diagram. Disponible en Internet: