Manual de Requerimientos PDF

Grupo para el Desarrollo de Tecnologas de Software
Manual de Requerimientos. Ingeniera de Software

Introduccin a IR
Por Qu? En uno de los prrafos ms citados en la bibliografa de la Ingeniera del Software, Frederick P. Brooks [Brooks, 1987], dice : "La parte ms difcil de construir un sistema es precisamente saber qu construir. Ninguna otra parte del trabajo conceptual es tan difcil como establecer los requerimientos tcnicos detallados, incluyendo todas las interfaces con gente, mquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difcil de corregir ms adelante... Entonces, la tarea ms importante que el ingeniero de software hace para el cliente es la extraccin 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 disear 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 ms del 60% de los errores de diseo se originan durante las etapas de requerimientos y anlisis. 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 cmo realizar su trabajo (eficiencia, hardware, software, interfase, usabilidad, etc.); es el cmo, cundo y cunto del qu.
Qu es? La Ingeniera de Requerimientos se define, segn Ortas [Ortas 1997], como un : "conjunto de actividades en las cuales, utilizando tcnicas y herramientas, se analiza un problema y se concluye con la especificacin de una solucin (a veces ms de una)." Otras definiciones: Ingeniera de Requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema Boehm 1979. Ingeniera 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 combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos Leite 1987. Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto Rational Software Entonces, "Ingeniera de Requerimientos" se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto determinado. El uso del trmino "ingeniera" implica que se deben utilizar tcnicas sistemticas y repetibles para asegurar que los requerimientos del sistema estn completos y sean consistentes y relevantes. Para qu un Proceso de Ingeniera de Requerimientos? El Proceso de ingeniera de requerimientos es un conjunto estructurado de actividades, mediante las cuales obtenemos, validamos y mantenemos el documento de especificacin de requerimientos (ESRE). Las actividades del proceso incluyen la extraccin de requerimientos, el anlisis, la negociacin y la validacin. No existe un proceso nico que sea vlido de aplicar en todas las organizaciones. Cada organizacin 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 ingeniera de requerimientos. Hay muchas maneras de organizar el proceso de ingeniera de requerimientos y muchas veces tenemos tambin 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 algn tipo de proceso ordenado. Para obtener este orden, diseamos nuestros procesos basndonos en algn modelo que nos gue a la hora de diferenciar y secuenciar las actividades.
Por ende, veremos a continuacin los modelos aplicables a la Ingeniera de Requerimientos, los analizaremos y veremos cul se aplica mejor a nuestro escenario, para continuar con el anlisis 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 Ingeniera 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 estimacin 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, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin 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 ingeniera 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 habamos dicho que un requerimiento es una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo, y/o una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin 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 caractersticas 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, estndares, etc. Definiciones
Es una declaracin en un Lenguaje Natural incluye los diagramas de los servicios del sistema y sus lmites operacionales. Escrito para clientes.
Especificacin de Requerimientos. Un documento estructurado con descripcin o detalle de los servicios del sistema. Escrito como un contrato entre el cliente y el contratista. Especificacin de Software. Descripcin detallada de software, la cual, puede servir como una base para diseo o implementacin. Escrito para desarrolladodres.
Caractersticas de los requerimientos Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso Un requerimiento es conciso si es fcil de leer y entender. Su redaccin 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 redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Dificultades para definir los requerimientos Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles 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 difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada
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 situacin. Es difcil anticipar los efectos que el sistema tendr en la organizacin. Usuarios diferentes tienen requerimientos y prioridades diferentes. Hay constantemente compromiso de cambios en los requerimientos. Los usuarios finales del sistema y la organizacin 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 organizacin del cliente. Por ejemplo, un hospital siempre tendr doctores, enfermeras, etc. Puede ser derivado de modelos de dominio. Requerimientos Voltiles. Los requerimientos cambian durante el desarrollo o cuando el sistema est en uso. En un hospital, los requerimientos se derivan de las polticas saludcuidados Requerimientos Cambiantes. Los requerimientos que cambian por el ambiente del sistema. Surgimiento de los Requerimientos. Requerimientos que surgen como una comprensin del desarrollo del sistema. Requerimientos en Consecuencial. Requerimientos que resultan de la introduccin del sistema a la computadora. Requerimientos Compatibles. Requerimientos que dependen de otros sistemas o de otros procesos de la organizacin.
Definicin de requerimientos no funcionales Son aspectos del sistema visibles para el usuario, que no estn relacionados de forma directa con el comportamiento funcional del sistema. Abarcan diversos aspectos:
interfaz de usuario y factores humanos: tipo de interfaz, experiencia,... documentacin: documentacin requerida, destinatarios, tipo de documentacin tcnica,... consideraciones de hardware: compatibilidad con otro hardware, existencia de otros sistemas,... caractersticas de ejecucin: usuarios concurrentes, carga de trabajo,... gestin de errores y excepciones cuestiones de calidad: fiabilidad, disponibilidad, robustez,... modificaciones futuras ambiente fsico: condiciones climticas, exposicin a golpes, accidentes,... seguridad recursos consumidor por el sistema
Especificacin Complementaria Captura otros requisitos, informacin 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 diseo e implementacin cuestiones de internacionalizacin (monedas, medidas, idiomas,...) documentacin (usuario, instalacin, administracin) y ayuda licencia y cuestiones legales estndares (tcnicos, de seguridad, de calidad,...) cuestiones del entorno fsico (temperatura, vibraciones,...) cuestiones operacionales (gestin de errores, frecuencia de copias de seguridad,...) reglas del dominio o negocio
El Glosario Es la lista de los trminos relevantes y sus definiciones
Reduce problemas de comunicacin y requisitos ambiguos: evita que un trmino 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)
fase de inicio: el glosario debe ser un documento sencillo de trminos y descripciones fase de elaboracin: se ampla a un diccionario de datos, incorporando atributos sobre los trminos: o alias o descripcin o formato (tipo, longitud, unidad) o relaciones con otros elementos o rango de valores o reglas de validacin Es importante tener en cuenta las unidades (medida, moneda,...) puede haber trminos compuestos Hay trminos 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 tecnologa y el presupuesto disponible? Anlisis de Requerimientos. Encontrar que el sistema requiere del mantenimiento de intereses. Definicin de Requerimientos. Definir los requerimientos en una forma comprensible para el cliente. Especificacin de Requerimientos. Define los requerimientos en detalle
Proceso de la IR
Documento de Requerimientos Es la declaracin oficial de lo que es requerido para que el sistema sea desarrollado. Incluye la definicin y especificacin de requerimientos. No es un documento de diseo. Tanto como sea posible, es un conjunto de lo que es el sistema y como lo har. Requerimientos del Documento de Requerimientos
Especificacin de la conducta externa del sistema. Especificar los lmites de la implementacin. Fcil de cambiar. Sirve como una herramienta de referencia para mantenimiento Recuerda el ciclo de vida del sistema, esto es, predice cambios. Proporciona respuestas caractersticas a un evento no esperado.
Estructura del documento de Requerimientos
Introduccin. Describe la necesidad de crear el sistema y cuales son sus objetivos. Glosario. Define los trminos tcnicos usados. Modelos del Sistema. Define los modelos que muestran los componentes del sistema y las relaciones entre ellos. Definicin de Requerimientos Funcionales. Define los servicios que sern proporcionados. Definicin de Requerimientos No-funcionales. Definir las limitantes del sistema y el proceso de desarrollo. Evolucin del Sistema. Definir las suposiciones fundamentales en las cuales el sistema se basa y se anticipan los cambios. Especificacin de Requerimientos. Especificacin detallada de los requerimientos funcionales del sistema. Apndices
Descripcin 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
posible. Los cambios son fciles cuando se trata de un documento electrnico. Sin embargo, la falta de estndares para documentos electrnicos lo hace difcil.
Actividades de la IR
Usualmente podemos dividir las prcticas de la IR en 4 actividades, a saber: a.- Extraccin (Anlisis del Problema) b.- Anlisis (Negociacin del Problema) c.- Especificacin d.- Validacin (incluida evolucin) Como toda divisin de tareas, no es una estricta representacin de la realidad, sino que se hace con el fin de sistematizar la realizacin de la IR. En general la delimitacin entre una actividad y la otra no es tan clara, ya que estn sumamente interrelacionadas, existiendo un alto grado de iteracin y retroalimentacin entre una y otra. Extraccin (Anlisis del Problema) Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre comnmente 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 comunicacin entre desarrolladores y clientes; de esta comunicacin con el cliente depende que entendamos sus necesidades. Esto no suele ser tarea fcil: muchas veces los clientes/usuarios no tienen una idea clara de sus necesidades reales, diversas personas dentro de la organizacin tienen necesidades encontradas, pueden existir limitaciones tcnicas o tecnolgicas para cumplir con algunos requerimientos, etc. Pero, en definitiva, descubrir los requerimientos del sistema no slo implica preguntar a las personas qu quieren: es un proceso delicado que involucra comprender el domino de aplicacin, es decir, obtener un conocimiento del rea general de aplicacin 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
el negocio, por tanto, se debe entender en profundidad cmo es que este sistema interactuar y afectar a las partes del negocio que estarn involucradas y cmo 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 anlisis 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 quin 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 transaccin bancaria : Perspectiva del cliente = Prdida de tiempo Perspectiva del banco = Posibles prdidas de clientes o Posibles soluciones pueden ser: Determinar por qu demoran los cajeros Colocar una nueva caja (implica contratacin de nuevos cajeros) Abrir una nueva sucursal (involucra personal nuevo y estudio de mercado) o Realizar transacciones por otros medios (telfono, internet, mediante cajeros automticos, autobancos, etc).
Como puede verse, mltiples soluciones aplican para el mismo problema, sin embargo, slo una de ellas ser la ms factible. Las soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva tcnica como la del negocio.
Construir un vocabulario comn: Debe confeccionarse un glosario en dnde se definan todos los trminos que tengan significados comunes (sinnimos) y que sern utilizados durante el proyecto. Por ejemplo, las palabras pignoracin, retencin, valor en suspenso, custodia, garanta, entre otras, son utilizadas para referirse a la accin de dejar una prenda (puede ser cualquier forma de ahorros) como garanta de una deuda adquirida. La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunin estn en la misma pgina, adems 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 ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la informacin necesaria para especificar un sistema adecuado. Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern afectadas por el sistema, debemos realizar algunas preguntas. Quin usar el sistema que se va a construir? Quin desarrollar el sistema? Quin probar el sistema? Quin documentar el sistema? Quin dar soporte al sistema? Quin dar mantenimiento al sistema? Quin mercadear, vender, y/o distribuir el sistema? Quin se beneficiar por el retorno de inversin del sistema?
10
Como vemos, debe conocerse la opinin de todo aqul que de una u otra forma est involucrado con el sistema, ya sea directa o indirectamente. Definir los lmites 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 restriccin ambiental, presupuestaria, de tiempo, tcnica y de factibilidad que limite el sistema que se va a construir
Definir los lmites 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 restriccin ambiental, presupuestaria, de tiempo, tcnica y de factibilidad que limite el sistema que se va a construir.
Es importante, entonces, que la extraccin sea efectiva, ya que la aceptacin del sistema depender de cuan bien ste satisfaga las necesidades del cliente y de cuan bien asista a la automatizacin del trabajo.
Anlisis (Negociacin del problema) Sobre la base de la extraccin 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 anlisis luego de haber producido un bosquejo inicial del documento de requerimientos; aqu se leen los requerimientos, se conceptan, 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 anlisis en un proceso estructurado y sistemtico, lo que convierte a esta etapa en "subjetiva" porque depende en gran medida del juicio y de la experiencia del AN. Especificacin En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la prctica, esta etapa se va realizando conjuntamente con el anlisis, pero podramos decir que la Especificacin es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin, como la notacin UML. La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluacin de los mismos antes de definir si son adecuados para el cliente. El trmino adecuado significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades tcnicas y econmicas, a la vez que se buscan resultados completos, correctos y sin ambigedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstraccin y descomposicin 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 trminos. 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 trminos de implementacin. A esta caracterstica se le
11
conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirn las actividades de diseo 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 operacin crtica del negocio. o Si existe algn 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 categorizacin de los requerimientos, puedo tomar como estrategia general el incluir los mandatarios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusin de un requerimiento, tambin 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 ms que ste sea slo deseable.
Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (pueden implementarse los requerimientos con la tecnologa actual?); factibilidades operacionales (puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades econmicas (ha sido aprobado por los clientes el presupuesto?).
En la actividad de evaluacin y negociacin, se incrementa la comunicacin 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.
Especificacin de Requisitos de Software (SRS) La especificacin de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripcin 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 informacin que sirva de soporte y gua para fases posteriores. Es importante destacar que la especificacin de requisitos es el resultado final de las actividades de anlisis y evaluacin de requerimientos; este documento resultante ser utilizado como fuente bsica de comunicacin entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementacin 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 evolucin del sistema.
12
La SRS posee las mismas caractersticas de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada caracterstica 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 caractersticas de la SRS son verificadas en la actividad de Validacin. La estandarizacin 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, adems de asegurar que se cubren todos los tpicos 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 especificacin de requisitos. Validacin de Requisitos La validacin es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; adems 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 validacin garantiza que todos los requerimientos presentes en el documento de especificacin sigan los estndares de calidad. No debe confundirse la actividad de evaluacin de requerimientos con la validacin de requerimientos. La evaluacin verifica las propiedades de cada requerimiento, mientras que la validacin revisa el cumplimiento de las caractersticas de la especificacin de requisitos. Durante la actividad de validacin pueden hacerse preguntas en base a cada una de las caractersticas que se desean revisar. A continuacin se presentan varios ejemplos: Estn incluidas todas las funciones requeridas por el cliente? (completa) Existen conflictos en los requerimientos? (consistencia) Tiene alguno de los requerimientos ms de una interpretacin? (no ambigua) Est cada requerimiento claramente representado? (entendible) Pueden los requerimientos ser implementados con la tecnologa 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 validacin de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado. La validacin es la etapa final de la IR. La validacin 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 slo debera incluir los requerimientos que son aceptables para los usuarios. Pero es inevitable que durante la validacin se descubran algunos problemas relacionados con los usuarios, y esto se debe corregir antes de aprobarse el documento final de requerimientos.
13
En definitiva, la validacin de especificaciones realmente significa asegurarse de que el documento de requerimientos represente una descripcin clara del sistema, y es una verificacin final de que los requerimientos cubren las necesidades de los usuarios. Esta etapa puede confundirse con la de anlisis, pero la diferencia es clara: mientras que en el anlisis se trabaja sobre el boceto del documento de requerimientos, en la validacin se utiliza el documento final, lo que equivale a decir, los requerimientos "depurados". Evolucin de los requerimientos Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cmo los objetivos de la organizacin pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolucin es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las ms 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 caracterstica en particular, modificacin que a la vez puede tener impacto en otros requerimientos. Por esto, la administracin de cambios involucra actividades como establecer polticas, guardar histricos 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 cdigo, ya que evita tener requerimientos emparchados en un proyecto Entre algunos de los beneficios que proporciona el control de versiones estn: Prevenir cambios no autorizados. Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de releases. Prevenir la modificacin simultnea 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
Extraccin - Anlisis del Problema

Objetivos
Describir diferentes enfoques para descubrir los requerimientos. Explicar la necesidad de un anlisis desde mltiples perspectivas Ilustrar un enfoque estructurado al anlisis de requerimientos Explicar por qu influyen los factores organizacionales y sociales en los requerimientos del sistema
Los Enfoques del Anlisis
Anlisis orientado a puntos de vista Anlisis basado en mtodos Contexto del sistema Factores sociales y organizacionales
Anlisis orientado a puntos de vista
Los especialistas representan diferentes modos de ver un problema los diferentes puntos de vista de un problema Este anlisis de mltiples 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 Automtico: Este ejemplo es un sistema de cajero automtico 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 pequeo conjunto de servicios. Los servicios incluyen disposicin de efectivo, solicitar un servicio (enviando un mensaje), estados de cuenta y transferencia de fondos Puntos de vista de Sistema de Cajero automtico:
Clientes del banco Representantes de otros bancos Ingenieros de mantenimiento en hardware y software Departamento de mercadotecnia
15
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 anlisis implica verificar qu datos son producidos y consumidos y qu suposiciones sobre las fuentes o destinos de los datos son validas Estructuras de representacin. 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 ms 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 obtencin de requerimientos. Es relativamente fcil decidir si un punto de vista es vlido Puntos de vista y servicios pueden ser pedidos para estructurar requerimientos no funcionales Anlisis basado en Mtodos Ampliamente usado para aproximarse al anlisis de requerimientos. Depende de la aplicacin de un mtodo estructurado para entender el sistema Los mtodos tienen diferentes nfasis. Algunos estn diseados para obtener los requerimientos, otros son mtodos de diseo Un mtodo orientado a puntos de vista (VORD) es usado como ejemplo aqu. Esto tambin ilustra el uso de los puntos de vista
Proceso VORD
Identificacin 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 jerarquas. Los servicios comunes son proporcionados en los niveles ms altos de la jerarqua
16
Documentacin de los puntos de vista. Refina la descripcin de los puntos de vista y los servicios identificados Representacin de los puntos de vista. Transformar el anlisis a un diseo
Informacin de servicios de los puntos de vista
Datos/Control a Puntos de vista
Jerarqua de puntos de vista
17
Plataforma cliente/disposicin de efectivo
Anlisis de datos y control
Leyenda
18
Elipses. Datos proporcionados de para un punto de vista Control de informacin, 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 mayora de los mtodos 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 invlida. 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 lmites del sistema deben ser establecidos para determinar lo que debe ser implementado stos son documentados usando una explicacin del contexto del sistema. Esto debe incluir una descripcin de los otros sistemas que estn en el ambiente Los factores organizacionales y sociales pueden influir la definicin de los lmites del sistema
Contexto del sistema de cajero
Anlisis de Requerimientos
A veces llamado exploracin de los requerimientos Involucra trabajo tcnico de grupo con los clientes para averiguar el dominio de la aplicacin, 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 lder especialista stakeholders
Problemas con el anlisis
Los especialistas (stakeholders) no saben realmente lo que quieren stos expresan requerimientos en sus trminos propios Diferentes especialistas pueden tener requerimientos en conflicto Los factores polticos y organizacionales pueden influir en los requerimientos del sistema
19
Los requerimientos cambian durante el proceso de anlisis. 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 slo puntos de vista, sino que su influyen sobre todos los puntos de vista Un buen anlisis debe ser sensitivo a esos factores pero actualmente no hay un modo sistemtico de abordar su anlisis
Un ejemplo. Considere un sistema que permite al Director General acceder a la informacin sin pasar a travs 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 sern consultados pueden proporcionar deliberadamente informacin incompleta equivocada, as que el sistema puede fallar
Anlisis Etnogrfico
Es muy importante estudiar y observar cmo trabaja la gente Las personas no tienen que explicar o articular su trabajo Los factores sociales y organizacionales de importancia deben ser observados Estudios etnogrficos han mostrado que el trabajo usualmente es ms abundante y ms complejo que lo sugerido por los modelos de sistemas sencillos
El enfoque etnogrfico combina tecnologa con prototipado. El desarrollo de un prototipo trasciende en preguntas sin respuesta lo cual enfoca el anlisis etnogrfico. La etnografa es que estudia las practicas existentes, las cuales pueden tener alguna base histrica que ya no es relevante El uso de la etnografa en el anlisis de requerimientos necesita ser desarrollado tal que pueda ser combinado con mtodos ms sistemticos Conforme la importancia de los factores humanos, sociales y organizacionales se vuelven ms ampliamente reconocidos, estos mtodos son promisoriamente desarrollados Resumen
Deben emplearse mtodos estructurados en el anlisis de requerimientos Estos deben incluir un modelo del proceso, notaciones de modelado del sistema, reglas y apuntes para el modelado del sistema y reportes estndar El mtodo VORD orientado a puntos de vista asla los puntos de vista que son externos al sistema Los lmites entre el sistema y su ambiente deben ser definidos Los factores sociales y organizacionales tienen mucha influencia en los requerimientos
Herramientas I 20
Entrevistas y cuestionarios Sistemas existentes Grabaciones de video y audio Brainstorming (tormenta de ideas) Arqueologa de documentos Aprendiz Observacin Entrevistas y cuestionarios Las entrevistas y cuestionarios se emplean para reunir informacin proveniente de personas o grupos, informacin que se obtiene conversando con el encuestado. Para la realizacin 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 comunicacin, en el cual se intercambiarn los telfonos, celulares, direcciones de e-mail y horarios de contacto. Para realizar las entrevistas, conviene llevar preparado un cuestionario. En trminos 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 categoras: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminologa. Generalmente estas son ms reveladoras, ya que los interrogados no estn limitados en sus respuestas. Son especialmente tiles en la etapa exploratoria de la investigacin, cuando el AN busca penetrar en el pensamiento del encuestado. A continuacin se presentan algunos ejemplos de preguntas abiertas: Cul es la razn por la que quiere resolver este problema? Cmo se resuelve el problema actualmente? Cul es el valor de una solucin exitosa? Quin usar el sistema que se va a construir? Cmo deseara 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 priorizacin 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. Tambin podemos volver a utilizarla cuando tenemos que negociar algn requerimiento con el cliente. Sistemas existentes Esta tcnica consiste en analizar distintos sistemas ya desarrollados que estn relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfases de usuario, observando el tipo de informacin que se maneja y cmo es manejada. Esto puede ser til para descubrir informacin importante a tener en cuenta, informacin que tal vez el cliente/usuario haya fallado en comunicar. Tambin 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
Luego de este anlisis tambin 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 (investigacin y anlisis), 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, tambin, podemos establecer contacto con profesionales que desarrollan sistemas de caractersticas comparables. Otra ventaja que presenta esta tcnica es que como estos sistemas ya estn en produccin, 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 informacin y para qu sirve, lo que resultar de suma utilidad para nuestro cliente. Tambin 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 Bsicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algn proceso en particular. En cuanto a su funcin de apoyo, es importante por cuanto permite centrar la atencin en la entrevista en s en vez de distraerse tomando notas de todo lo que se dice. Cuando se est grabando la conversacin, basta con "puntear" en una libreta los temas tratados para despus tener una gua bsica de los temas tratados y saber en qu lugar de la grabacin buscar. Adems, permite analizar los temas con ms detenimiento y con una visin ms global, pues ya se ha conversado sobre todos los puntos necesarios y se han visto los procesos ad hoc. Cuando se trata de analizar algn 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 grabacin. Debemos darle tiempo a las personas para que se distiendan y se sientan cmodas con la idea de ser grabados o filmados. Brainstorming (tormenta de ideas) Este es un modelo que se usa para generar ideas. La intencin en su aplicacin es la de generar la mxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intencin de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irn eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", etc. Las reglas bsicas a seguir son:
Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtencin de una cantidad mayor de ideas creativas.
22
Conviene suspender el juicio crtico y se debe permitir la evolucin de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generacin de ideas. Por ms 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.
Arqueologa de documentos Con la aplicacin de esta herramienta se tratan de determinar posibles requerimientos sobre la base de inspeccionar la documentacin utilizada por la empresa; por ejemplo, boletas, facturas, remitos, etc. Esta herramienta sirve ms que nada como complemento de las dems tcnicas, y nos ayuda a obtener informacin que de otra manera sera sumamente difcil conseguir. Por ejemplo, en las facturas podemos encontrar informacin que no se pensaba manejar y que en definitiva resulta de suma utilidad, como un nmero 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 informacin. Para el anlisis de cada uno de estos documentos, debemos realizar algunas preguntas, como: Cul es el propsito de este documento? Quin lo usa? Por qu? Para qu? Cules son las tareas que realizan con este documento? Se puede encontrar una relacin entre los documentos? Cul es el proceso que realiza la conexin? Cul es el documento que da ms 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 observacin, haciendo preguntas como por qu hizo eso? y qu significa eso?, y tambin realizando algn trabajo bajo la supervisin del maestro. Esta tcnica 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 tambin puede bosquejar como se conectan por medio de los distintos flujos de datos. La aplicacin de esta herramienta es muy til, ya que a veces es difcil para el cliente/usuario el explicar cmo realiza su trabajo. Es tambin una tcnica 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 implementacin requiere de mucho tiempo.
23
Observacin Es sumamente difcil describir cmo hacer el nudo de un calzado deportivo, pero es sumamente fcil 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 organizacin, vivirla, es una herramienta que debe ser tomada en cuenta. Tambin 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 organizacin; por ejemplo, ver cmo resuelven un problema que surge, como un llamado telefnico 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 Anlisis 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 informacin 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 estn 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 extraccin de requerimientos, puede ocurrir que algunos requerimientos no estn demasiado claros o que no estemos muy seguros de haber entendido
24
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, permitindonos conseguir una importante retroalimentacin en cuanto a si el sistema diseado 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, slo se podrn 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"). Tambin podemos llevar el caso de uso y bosquejar la interfase de usuario y, mediante el dilogo, manejamos la interactividad entre el usuario y el sistema. Una de las ventajas ms 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 dilogo hombre-mquina, sobre todo si existe un requerimiento no funcional como el de usabilidad. Prototipo Tangible/usable Los trminos tangible y usable se refieren a desarrollar una aplicacin (software) que el usuario pueda utilizar, es decir, con la cual pueda interactuar como si fuera la aplicacin 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 analoga con las maquetas de los arquitectos. El prototipo tangible/usable tambin resulta de suma utilidad cuando nos encontramos frente a un requerimiento no funcional de usabilidad, ms precisamente, el de facilidad de uso. Entre las desventajas ms importantes de los prototipos que podemos mencionar, se encuentran:
Costo de entrenamiento/capacitacin en la herramienta
25
Costo de realizar el prototipo. Problema de calendario. Incompletitud (puede confundir a los usuarios, hacindolos pensar que el producto final quedar como el prototipo, incompleto).
Anlisis FODA Con este anlisis 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 sealan ciertas estrategias cuya aplicacin podra conducir al xito, mientras que las debilidades sealan aquello que la empresa debe corregir.
Esta herramienta es sumamente til para analizar la situacin de una empresa y ver de qu forma podemos ayudar a disminuir las debilidades y amenazas, y cmo podemos aprovechar las oportunidades o cmo podemos crear nuevas oportunidades y cmo hacer an ms fuertes las fortalezas. Tambin nos es til para analizar el impacto de la solucin planteada en cada uno de los cuadros. Cadena de valor Todas las empresas son una coleccin de actividades que se llevan a cabo para disear, producir, distribuir, entregar y apoyar a su producto. La cadena de valor divide las empresas en nueve actividades estratgicas a fin de comprender el comportamiento de los costos en determinado negocio o industria y en las fuentes de diferenciacin presentes y futuras. En este anlisis se deben examinar los costos y el funcionamiento de cada una de las actividades productoras de valor, tratando de mejorarlos.
26
Con esta herramienta podemos analizar los flujos de informacin que intervienen en las distintas actividades. Sirve tambin, por ejemplo, en el caso de que existan sistemas operacionales automatizados, para investigar qu tipo de informacin 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 representacin de conceptos del dominio del problema. [Fowler96]. Permite mostrar conceptos, asociaciones entre conceptos y atributos de conceptos. La creacin del modelo tambin ayuda a comprender la terminologa del dominio y comunica cules son los trminos importantes y las relaciones existentes entre ellos. Concepto: categora de idea o cosas. La intencin del concepto es la descripcin de sus atributos, operaciones y significado. [Craig, L. 1999] Para representar un concepto podemos basarnos en la metodologa 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 mquina, 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 cmo funciona el negocio (relaciones entre las clases/concepto), y capturar vocabulario y conceptos (clase). Tambin es de ayuda para incluir nuevos conceptos al glosario. Diagrama de pescado (Ishikawa Diagram, Cause-and-Effect o Fishbone Diagram)
27
Es una antigua pero til herramienta que sirve, en el proceso de IR, para analizar problemas y comprender cules son sus causas. Por ejemplo,supongamos que es necesario analizar el costo de los distintos componentes, en los cuales intervienen procesos, tecnologa, gente. En la figura que se presenta como ejemplo del diagrama de pescado, se analizan las posibles causas por la que los empleados no estn contentos con el trabajo que realizan.
Como vemos en este diagrama, se distinguen 4 categoras bsicas: empleado, entorno, proceso, maquinaria (tengamos en cuenta que la aparicin de estas categoras 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 capacitacin de los empleados, y otra que es el estado antiguo de la maquinaria de trabajo. Con esta herramienta podemos analizar cmo impacta la solucin planteada para un requerimiento dado. Por ejemplo, cmo afecta al trabajo diario del empleado. Tambin en el caso de que la solucin planteada interacte con otros sistemas existentes (modificando, consultando o intercambiando informacin) 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 trminos en donde se explica su significado. En esta lista se incluyen y definen todos los trminos que requieren explicacin, mejorando as la comunicacin intergrupal y la ocmunicacin con el cliente, y mitigando el riesgo de malos entendidos. Los trminos que se incluyen provienen de todas las reas del proyecto: casos de uso, terminologa propia del negocio, etc. El glosario se va actualizando durante el transcuros del proceso de IR, perfeccionndolo en cada nuevo ciclo. Cmo hacerlo? Para realizar el glosario utilizamos dos columnas; en la primera ingresamos el nombre del trmino y, en la segunda, ingresamos su descripcin. Es importante ordenar alfabticamente esta tabla por Trmino, para as facilitar las consultas.
28
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 relacin con el ambiente. Para la construccin de este documento podemos consultar la plantilla base del DCO, brindada por ORTsf. Los puntos tratados en el documento bsicamente son:
Anlisis del entorno Descripcin general Organigrama de la empresa Misin/visin. Polticas de desarrollo, de servicios, comercial, de personal, de direccin, 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.
Tambin podemos incluir otras herramientas como el anlisis 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 (condicin de guarda), para luego pasar a la siguiente actividad o estado (transicin). Este modelo tambin permite representar actividades que ocurren en paralelo, o aquellos casos en los que una nica actividad desencadena ms de una tarea (divisin de control), o cuando se unen dos o ms actividades para formar una tercera (unin de control). Componentes del diagrama: Bifurcacin. Una bifurcacin puede tener una transicin de entrada y dos o ms de salida; en cada una de estas salidas se coloca una expresin boolena, que se evala al ingresar en la bifurcacin. Divisin y unin. Una divisin puede tener una transicin de entrada y dos o ms transiciones de salida. Despus de la divisin, las actividades asociadas de cada uno de estos caminos continan en paralelo. Por su parte, una unin puede tener dos o ms transiciones de entrada y una transicion de salida. Transiciones. Cuando finaliza una actividad, el flujo de control pasa inmediatamente al siguiente estado de acccin o estado de actividad. Este flujo se especifica con transiciones que muestran el camino de un estado de actividad al siguiente
29
Documento ESRE | Casos de uso El objetivo del documento ESRE (Documento de Especificacin 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 categoras, los no-funcionales y los funcionales. Los no-funcionales definen las caracteristcas que indican cmo el sistema debe realizar su trabajo; por ejemplo, eficiencia, hardware necesario, software, etc. Por su parte, los requerimientos funcionales definen qu hace el sistema; bsicamente 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 construccin del ESRE, ORTsf brinda una plantilla base en la cual se detallan especficamente cada uno de los puntos correspondientes. Lista de requerimientos La lista de requerimientos forma parte del documento de especificacin de requerimientos (ESRE). En este documento se listan los requerimientos funcionales que el sistema debe satisfacer.
30
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 tcnica diseada para especificar el comportamiento de un sistema. Este documento describe la posible secuencia de interacciones entre el sistema y uno o ms actores, en respuesta a un estmulo inicial proveniente de un actor. No es una simple historia especfica de eventos especficos intercambiados entre el sistema y los actores o escenario, sino que es una descripcin 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 mayora de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. Un caso de uso tpico 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 (quines intervienen en el caso de uso) Suelen ser los papeles representados por personas; tambin pueden ser otros sistemas o mquinas que interactan con el caso de uso. Ms 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. Descripcin del objetivo del caso de uso Esta debe expresar lo que ocurre desde el punto de vista del usuario. Referencia a los requerimientos especficos del sistema. Es un identificador que se corresponde con la lista de requerimientos; suele usarse una letra y un nmero como, por ejemplo, R1. Esta referencia puede indicar uno o varios requerimientos. Interfaz de usuario IU Es la forma por la cual el actor interacta 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 descripcin puede tener un curso bsico o puede ser dividida en un bsico y otros alternativos. El curso bsico es la secuencia de transacciones ms importantes que satisfacen el caso de uso; mientras que los cursos alternativos son variantes del curso bsico y, usualmente, son usados para identificar los errores de operacin del sistema.
Casa de calidad o QFD
31
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 "cmo", es decir, cmo 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 travs de algn caso de uso y, que todo caso de uso debe satisfacer algn requerimiento. Cmo hacerlo? Para realizar esta tcnica podemos utilizar un planilla de clculo, como EXCEL. Aqu se ingresar, en la filas, los identificadores de los requerimientos correspondientes a la lista de requerimientos. Los identificadores estn compuestos por una letra y un nmero, por ejemplo, R1. En tanto, en las columnas ingresamos un cdigo que corresponde al identificador utilizado para cada uno de los casos de uso. Usualmente su formato est compuesto por letras y un nmero; 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 interseccin 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 algn caso de uso y, que todo caso de uso satisface algn requerimiento. Por otra parte, tambin 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 verificacin) Esta herramienta es muy fcil 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 mrgenes del documento, ya sea en una lista de anlisis.
32
Las checklist son tiles porque brindan un recordatorio de lo que se debe buscar y reducen las chances de pasar por alto alguna verificacin importante. Y no slo son tiles para verificar requerimientos; tambin se puede aplicar con los casos de uso y con los puntos a ser tratados en el plan de agenda. Cmo hacerlo? Este anlisis se puede implementar con una hoja de clculo 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 simplificacin de la realidad que incluye aquellos elementos que tienen una gran influencia y omite aquellos elementos que no son relevantes para el nivel de abstraccin 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 secuenciacin aproximada y general de las actividades que luego deberemos realizar. As, presentamos el siguiente ejemplo, en donde cada uno de los compartimientos cubre una seccin 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 extraccin lleva al anlisis, el anlisis desencadena la documentacin, y la documentacin inicia la validacin.
33
Si vemos a este modelo como una descripcin general del proceso, es un modelo til. Sin embargo, debemos entender que la realidad del proceso de IR es mucho ms compleja que lo que se vislumbra a partir del modelo en cascada: no existen fases claramente delimitadas ya que hay una retroalimentacin 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 validacin que llevan a un cambio de requerimientos, etc.; y todo esto har que ms de una vez tengamos que volver "hacia atrs" en el proceso de IR. Modelo en espiral Un modo alternativo de presentar modelos de actividad que toma en cuenta la retroalimentacin entre etapas y la repeticin 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 ingeniera de requerimientos son repetidas hasta que se toma la decisin final, que es la aceptacin del documento de especificacin de requerimientos. Es decir, si en el diseo preliminar se encuentran problemas, entonces recorremos el ciclo nuevamente (extraccin-anlisis-especificacin-validacin) hasta que todos sean resueltos, que es lo mismo que decir que este ciclo continuar hasta que se pueda elaborar un documento aceptable. Pero tambin existen factores externos que pueden determinar la finalizacin del ciclo, como por ejemplo la presin por cumplir con un determinado cronograma. Luego del suscinto anlisis de los dos modelos bsicos 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 ms vlida la
34
aplicacin del modelo en espiral para desarrollar el proceso de IR. Y es que el modelo en espiral representa de manera ms real cmo se irn desarrollando las actividades del proceso; esto es, debido al desconocimiento del tema, se genera un grado demasiado alto de incertidumbre que slo puede disminuirse al repetir el ciclo de trabajo una y otra vez, permitiendo as ajustar todos los parmetros, cada vez en mayor detalle, hasta lograr un resultado satisfactorio.
Casos de Uso I
Breve resea de UML Es el sucesor de la oleada de mtodos de anlisis y diseo Orientados a objetos (OOA&D) que surgi a finales de la dcada de 1980 y principios de la siguiente. Desde los 80 a los 90 ocurri una explosin de metodolgicas, 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 consolidacin entre las metodolgicas de estos tres autores. Como resultado de la convergencia, unificacin, estandarizacin, nfasis en ingeniera de software y desarrollo basado en componentes, a partir de mediados de 1996 nace UML (unified modeling lenguaje). Actualmente continan trabajando en esta notacin que tiene como base la metodologa 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 ao. En resumen,UML es un lenguaje de modelado OO de propsito general
En 1997 UML 1.1 fue aprobada por la OMG convirtindose en la notacin estndar de facto para el anlisis y el diseo Orientado a Objetos. UML es el primer mtodo en publicar un metamodelo en su propia notacin, incluyendo la notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de un metamodelo autoreferencial (cualquier lenguaje de modelado de propsito general debera ser capaz de modelarse por si mismo El UML es una tcnica de modelado de objetos y como tal supone una abstraccin de un sistema para llegar a construirlo en trminos 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 creacin del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informtico o no, mediante los diagramas, es decir, mediante representaciones graficas que contienen toda la informacin relevante del sistema.
35
Objetivos del UML
Proporcionar una notacin y semnticas suficientes para poder alcanzar una gran cantidad del modelado contemporneo de una forma directa y econmica Proporcionar las semnticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnologa de componentes , el computo distribuido, ejecutabilidad, etc. Proporcionar mecanismos de extensin de forma que proyectos concretos puedan extender el metamodelo a un costo bajo. Proporcionar mecanismos de extensin de forma que aproximaciones de modelado futuras podran desarrollarse encima del UML. Proporcionar semnticas suficientes para permitir el intercambio del modelado entre una gran variedad de herramientas Proporcionar semnticas 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 extensin y especializacin. o Ser independiente del proceso de desarrollo y de los lenguajes de programacin. 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 estndar de modelado y no como un proceso estndar. 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 semnticas).
Se consideran fuera del mbito del UML tanto lenguajes de programacin, como las herramientas , como el proceso de software. Por ultimo mencionar que aunque UML abarca las tcnicas existentes, es de esperar que aparezcan nuevas tcnicas. EL UML se puede adaptar a estas nuevas tcnicas ya que dispone de mecanismos de extensin que no necesitan redefinir el ncleo UML. Los Casos de Uso Un escenario de casos de uso es una descripcin, que puede estar escrita en lenguaje natural , de una situacin que una aplicacin es capaz o no de manejar. Un caso de uso describe una forma en que un actor del mundo real (persona, organizacin o sistema externo) interacciona con el modelo. Los Casos de Uso no son parte del diseo (cmo), sino parte del anlisis (qu). De forma que al ser parte del anlisis 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 cmo este interacta con el usuario. En general , y aunque que a menudo se utilizan los trminos 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 combinacin 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
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 comunicacin 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 informtico debe ofrecer. Describe una secuencia de interacciones entre uno o ms ACTORES y el sistema, como respuesta a un estmulo inicial: diferentes escenarios Describe una interaccin tpica entre un usuario y el sistema. Establece un objetivo concreto para el usuario Definen una funcin del sistema, asocindole un nombre y una descripcin textual.
Diagrama Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn 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 lnea. En la siguiente figura se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automtico.
37
Un diagrama de casos de uso consta de los siguientes elementos:
Actores Casos de uso Relaciones de Uso, Herencia y Comunicacin
Actores Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representacin 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 ms 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 aplicacin y deben ser utilizados Otros sistemas: sistemas con los que el sistema interacta
Casos de Uso Un caso de uso es una descripcin 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 especfica. 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 especfica 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 Comunicacin
Asociacin (Comunicacin)
38
Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple.
Herencia el Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla
Generalizacin Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica. Construccin 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: cules son las tareas del actor? qu informacin 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 descripcin del Caso de Uso comprende:
el inicio: cundo y qu actor lo produce? el fin: cundo se produce y qu valor devuelve? la interaccin actor-caso de uso: qu mensajes intercambian ambos? objetivo del caso de uso: qu lleva a cabo o intenta? cronologa 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 Descripcin
39
Casos de Uso II
Segn el Proceso Unificado de Desarrollo, los principales pasos para capturar los requerimientos son:
Identificacin 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
Encontrar Actores y Casos de Uso Objetivos
Delimitar el sistema y su entorno Esbozar quin y qu (actores) interactuarn con el sistema, y qu funcionalidad (casos de uso) se espera del sistema Capturar y definir un glosario de trminos comunes esenciales para poder describir detalladamente los casos de uso del sistema. Es la actividad ms decisiva para obtener adecuadamente los requisitos responsabilidad del analista de sistemas Actividades (no tienen por qu seguir este orden) o establecer el lmite del sistema: solo software, hardware y software como un todo, lo utiliza una persona, una organizacin,... 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
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 correspondern uno a uno con los objetivos de usuario. describir brevemente (descripcin informal) cada caso de uso
42
Actores
Representan entidades externas que interactan (mantenimiento y/o operacin) 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 interacta con el sistema tiene que estar representado al menos por un actor en el modelo de casos de uso Identificacin 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 administracin? existe algn 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
Adems de actores principales y objetivos obvios, se pueden utilizar diferentes preguntas para identificar otros menos evidentes: o quin arranca y detiene el sistema? o quin administra el sistema? o quin 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 quin evala 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, informacin) al sistema en desarrollo. Por ejemplo, el servicio de autorizacin de pago). Normalmente es un sistema informtico, pero puede ser una organizacin 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
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 lmite del sistema
Identificacin de Casos de Uso
44
Escenario (o instancia de caso de uso)
Es una descripcin narrativa de lo que la gente hace y experimenta cuando trata de utilizar una aplicacin informtica, es decir, una secuencia especfica de acciones e interacciones entre los actores y el sistema objeto de estudio. Descripcin concreta e informal de una sola caracterstica 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 Identificacin de escenarios o qu tareas necesita el actor que realice el sistema? o qu informacin consulta el actor? quin crea esos datos? se pueden modificar? quin puede hacerlo? o qu cambios externos necesita informar el actor al sistema? cundo y con qu frecuencia? o de qu eventos necesita el actor que le informe el sistema? cundo 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 travs del sistema, es decir, describe una serie de interacciones relacionadas que resultan de la
45
inicializacin del caso de uso.
Las tareas se pueden agrupar a muchos niveles de granularidad .Ejemplos:
Definir estrategia de mercado Establecer poltica de descuentos Negociar contrato con proveedor Gestionar devoluciones de productos Iniciar sesin en el sistema Imprimir factura ...
Todos son casos de uso a diferentes niveles, dependiendo de los lmites del sistema, actores y objetivos PREGUNTA: a qu nivel y alcance deben expresarse los casos de uso? RESPUESTA: Para el anlisis de requisitos de una aplicacin informtica, 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 aade valor cuantificable para el negocio y deja los datos en un estado consistente. Por ejemplo, Autorizar Crdito, o Solicitar Precio
No es un pequeo paso como eliminar lnea de pedido, o imprimir factura no tarda das y mltiples sesiones como negociar contrato con proveedor Son los caso de uso base, pero puede haber otros
46
Pueden existir casos de uso que no sean EBP: o subtareas de un caso de uso base. ejemplo: Pago a Crdito 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 excepcin: agrupacin de objetivos separados del tipo Altas-Bajas-ModificacionesConsultas, en casos de uso denominados Gestionar<X>
Objetivos y casos de uso de subfuncin
Ojetivo de subfuncin: 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 subfuncin como casos de uso cuando la subfuncin se repite o es una precondicin en muchos casos de uso de nivel de objetivos deusuario Ejemplo: Identificar Usuario
47
Casos de Uso III

Relaciones entre Actores y Casos de Uso
Relaciones de comunicacin entre actores y casos de uso o representan el flujo de informacin durante el caso de uso o se puede distinguir entre el actor que inicia el caso de uso y los dems 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 lmites del sistema o qu permanece fuera del sistema o cmo se utiliza el sistema o resume el comportamiento de un sistema y sus actores
Diagrama de Caso de Uso

Sugerencias en la realizacin 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 informticos con una notacin alternativa a los actores humanos Situar los actores humanos a la izquierda y los de apoyo a la derecha Lo realmente importante es la descripcin de los casos de uso, y no tanto los diagramas
48
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
Los casos de uso son parte importante de la planificacin de las iteraciones: el trabajo de una iteracin 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 diseo, es decir, el equipo disea 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 das) Identificacin de objetivos y personal involucrado determinar alcance del proyecto Elaboracin lista actor-objetivo Iniciar diagrama de contexto de casos de uso Descripcin 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 ms profundo (fase de elaboracin) o se rechaza el proyecto
50
ejemplo de un Modelo de Casos de Uso en la fase de inicio para un sistema de PDV:
Casos de uso en la elaboracin
Fase de mltiples iteraciones de duracin fija Se construyen incrementalmente partes del sistema arriesgadas, de alto valor o significativas para la arquitectura Se identifican y clarifican la mayora de los requisitos Retroalimentacin de las fases de diseo e implementacin Se pueden realizar talleres de requisitos en cada iteracin: o no se estudian todos los casos de uso: se priorizan o se refinan los requisitos principales, que son inestables en las primeras iteraciones, estabilizndose en las ltimas escritura y reescritura de la mayora de los casos de uso, en formato completo Al final de la fase de elaboracin 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 construccin o fase de mltiples iteraciones de duracin fija, centrada en completar el sistema o puede ser necesario escribir o reescribir casos de uso menores (incluso puede necesitarse algn taller de requisitos) o el grado de cambio de los requisitos es mucho menor que en la elaboracin, pues la mayora de los casos de uso funcionales y no funcionales ms importantes deben haberse estabilizado
Priorizacin de casos de uso
Determinar cules son necesarios para el desarrollo en las primeras iteraciones y cules 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 organizacin del desarrollo incremental o disponibilidad de equipo de desarrollo Se revisa la priorizacin con el jefe de proyecto y se utiliza como entrada para la planificacin de cada iteracin del proyecto
51
Detallar Casos de Uso
Objetivo principal: describir su flujo de sucesos en detalle o cmo comienza o cmo termina o cmo interactan 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: descripcin detallada mediante texto y diagramas
52
Descripcin del Caso de Uso Secciones de la Descripcin 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 slo el comportamiento relacionado con la satisfaccin de los intereses del personal involucrado o ejemplo: Cajero: quiere entradas precisas, rpidas y sin errores de pago, ya que las prdidas se deducen de su salario. Vendedor: quiere que las comisiones de ventas estn 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 precondicin implica un escenario de otro caso de uso que se ha completado con xito, como inicio de sesin, o validacin de usuario. o ejemplo: el cajero se identifica y el sistema lo autentifica.
53
Postcondiciones: o establecen qu debe cumplirse cuando el caso de uso se completa con xito (bien el escenario principal de xito o algn 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 bsico)
Describe el camino de xito tpico que satisface los intereses del personal involucrado No suele incluir condiciones o bifurcaciones Recoge los pasos, que pueden ser de tres tipos: o una interaccin entre actores o una validacin (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 mercancas para comprar 2. El Cajero comienza una nueva venta. 3. El Cajero introduce el identificador del artculo. 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 combinacin del escenario principal y los escenarios de extensin deberan satisfacer casi todos los intereses del personal involucrado (algunos intereses se documentan como requisitos no funcionales) Ejemplos: o 3a. Identificador no vlido 1. El Sistema seala el error y rechaza la entrada o 3b. Hay muchos artculos de la misma categora y tener en cuenta una nica identidad del artculo no es importante (por ejemplo, 6 cajas de leche de la misma marca). 1. El Cajero puede introducir el identificador de la categora del artculo y la cantidad Un flujo alternativo tiene dos partes: o condicin: algo que puede ser detectado por el sistema o el actor (el Sistema detecta un fallo de comunicacin con el sistema de actualizacin 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 artculo de la compra: 1. El Cajero introduce el identificador del artculo para eliminarlo de la compra 2. El Sistema muestra la suma parcial actualizada Si una extensin es muy compleja, se puede expresar como un caso de uso aparte Pueden incluirse condiciones de extensin que se pueden dar durante cualquiera de los pasos (por ejemplo, el sistema falla, o el Cliente cancela la compra)
54
Requisitos Especiales
Se recoge cuando un requisito no funcional, atributo de calidad o restriccin se relaciona de manera especfica con un caso de uso Incluye cualidades como rendimiento, fiabilidad y facilidad de uso, y restricciones de diseo (a menudo en dispositivos de entrada/salida) que son obligados o se consideran probables. Ejemplo: o interfaz de usuario con pantalla tctil en un gran monitor de pantalla plana. El texto debe ser visible a un metro de distancia o Tiempo de respuesta para la autorizacin de crdito 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 especificacin complementaria
Refinamiento
se incorporan detalles al caso de uso se describe el flujo de eventos en mayor detalle se mejora la descripcin de las interacciones
55
Ejemplo Caso de Uso

Mquina Recicladota: Sistema que controla una mquina de reciclamiento de botellas, tarros y otros similares El sistema debe controlar y/o aceptar:
Registrar el nmero 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 botn de comienzo Existe un operador que desea saber lo siguiente: a.- Cuantos tems han sido retornados en el da. b.- Al final de cada da el operador solicita un resumen de todo lo depositado en el da. El operador debe adems poder cambiar: a,- Informacin asociada a tems. b.- Dar una alarma en el caso de que: -Item se atora. -No hay ms papel.
Como una primera aproximacin identificamos a los actores que interactan con el sistema:
56
Luego, tenemos que un Cliente puede Depositar Items y un Operador puede cambiar la informacin de un Item o bien puede Imprimir un informe:
Adems podemos notar que un item puede ser una Botella, un Tarro...
Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar algn item por un cliente o bien puede ser realizada a peticin de un operador.
Entonces, el diseo completo del diagrama Use Case es:
57
Modelo de Dominio I
Introduccin Elementos claves del modelado de dominio. Cuando se construye un modelo esttico, lo primero que tenemos que hacer es identificar las clases apropiadas que representen la abstraccin 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 generalizacin, 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 esttico de clases. Los 10 errores ms 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 anlisis. 9.- No debemos de hacer un anlisis de los objetos y acciones tan exhaustivo que nos vayamos de largo, ya que a mayor grado de detalle, menor abstraccin. 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 informacin suficiente para hacer una buena designacin de operaciones y estados. 7.- No debemos de optimizar nuestro cdigo 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 todava no se asignan las operaciones y atributos.
58
6.- No debemos debatir en cuando usar agregacin o composicin para asociaciones parte de, ya que esta decisin es un parte detallada del diseo. 5.- No debemos adelantarnos a especificar una estrategia de implementacin si no hemos modelado el espacio del problema. Las estrategias de implementacin son parte de la implementacin, por lo que los diagramas de clases no deben llevar elementos que representen tecnologas especficas. 4.- No debemos de usar nombres difciles de comprender en nuestras clases, si hay un nombre intuitivamente obvio. Entre mas obvio sea el nombre de la clases, ser mas fcil para el equipo del proyecto identificarla. 3.- No debemos hacer directamente a construcciones de implementacin como relaciones de amistad y clases parametrizadas, ya que estas son mas relevantes para el espacio de la solucin 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 reingeniera, 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 construccin 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 anlisis 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 ms 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 estn 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 ms 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
Actividades del anlisis en el proceso unificado
Crear el Modelo de Dominio Refinar el Modelo de Casos de Uso Refinar la Especificacin Complementaria Refinar el Glosario
Estas actividades se llevan a cabo a lo largo de varias iteraciones en la fase de elaboracin
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 ms importante en un anlisis 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 elaboracin Pasos en la realizacin de un modelo del dominio
Identificar y listar las clases conceptuales candidatas Representarlas en un modelo del dominio Aadir las asociaciones necesarias para registrar las relaciones que hay que mantener en memoria
60
Aadir los atributos necesarios para satisfacer los requisitos de informacin
En este caso es muy importante:
Utilizar el vocabulario del dominio al nombrar las clases conceptuales y atributos Excluir las caractersticas irrelevantes No aadir 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
Informalmente: Una clase conceptual es una idea, cosa u objeto formalmente puede considerarse en trminos de: o Smbolo: palabras o imgenes que representan una clase conceptual definicin de la clase o Extensin: conjunto de ejemplos a los que se aplica la clase
Identificacin 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 Utilizacin de una lista de categoras de clases conceptuales o Identificacin de clases nominales
Identificacin de clases conceptuales mediante una lista de categoras

Se utiliza una lista de categoras habituales que normalmente merece la pena tener en cuenta
62
Anlisis del lenguaje natural: identificacin de clases conceptuales mediante frases nominales
Heurstica de Abbot (1983) Identificar nombres y frases nominales en las descripciones textuales de un dominio, considerndolos como clases conceptuales o atributos candidatos Punto dbil: imprecisin del lenguaje natural, ambigedades (sinnimos, redundancias,...) se realiza a partir de las descripciones completas de los casos de uso
63
Lista de clases conceptuales candidatas del dominio
Generada a partir de: o lista de categoras o anlisis de lenguaje natural (frases nominales) Restringida a los requisitos que se estn estudiando actualmente
Ejemplo: lista de clases candidatas del caso de uso Procesar Venta. Registro Artculo Tienda Venta Pago Catlogo de Productos Especificacin del Producto Lnea de Ventas Cajero Cliente Encargado -----
informes: por lo general, no se recogen en el modelo de dominio porque muestran informacin derivada de otras fuentes, duplicando informacin. a discutir: es el Recibo una clase conceptual? Modelo de Dominio II Clases conceptuales de especificacin o descripcin Se utilizan para especificar o describir otras clases. Una clase EspecificacinDelArtculo no representa un Artculo, sino una descripcin de la informacin sobre los artculos: aunque se vendan todos los elementos inventariados, eliminndose las correspondientes instancias software de Artculo, permanecer la EspecificacinDelArtculo
64
estas clases son habituales en entornos de gestin (sistemas de compras, ventas, inventarios,...) y fabricacin (descripciones de los productos fabricados) se usan cuando:
Se necesita la descripcin de un artculo o servicio independientemente de la existencia actual de algn item de esos artculos o servicios La eliminacin de instancias de las cosas que describen provocan prdida de informacin que necesitara mantenerse Reduce informacin redundante o duplicada
Reduccin del salto en la representacin (salto semntico): Una de las grandes ventajas de la tecnologa de objetos : la reduccin de la diferencia entre el modo en el que el personal involucrado concibe el dominio y su representacin en el software Ejemplo:
Un pago en el Modelo del Dominio es una clase conceptual (un concepto) Un pago en el Modelo de Diseo es una clase software no son lo mismo, pero el primero inspir el nombre y definicin del segundo
65
Representar las clases en un modelo del dominio Se utiliza la notacin de clase de UML
Representacin de las Clases Conceptuales del Punto de Ventas
66
Aadir las Asociaciones Necesarias Segn UML, una asociacin es la relacin semntica entre dos o ms clasificadores que implica conexiones entre sus instancias. Se registran las asociaciones:
De las que es necesario conservar el conocimiento de la relacin durante algn tiempo (por ejemplo, la relacin entre LneaPedido y Pedido) derivadas de la Lista de Asociaciones Comunes
Es importante registrar nicamente asociaciones tiles para mantener el diagrama legible. Es ms importante dedicar tiempo a localizar las clases conceptuales que a identificar las asociaciones
Lista de asociaciones comunes Es una relacin de categoras habituales que, normalmente, merece la pena ener en cuenta
67
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 direccin por defecto para la lectura de los nombres de asociaciones es de izquierda a derecha o arriba abajo
68
Multiplicidad Indica cuntas 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 restriccin de diseo que ser (o podr ser) reflejada en el software
Puede existir cualquier tipo de multiplicidad, pero en la prctica la mayora de las asociaciones pertenecen a uno de los siguientes tipos :
Asociacin de uno a uno: tiene una multiplicidad de 1 a cada extremo. Significa que existe solamente un vnculo entre instancias de cada clase. Por ejemplo : OficialPolica tiene exactamente un NmeroIdentificacin, y ste representa a uno y slo a un OficialPolica Asociacin de uno a muchos: tiene una multiplicidad de 1 en un extremo y 0..n en el otro (a veces representado con un asterisco) Asociacin de muchos a muchos: tiene una multiplicidad de 0..n o 1..n en ambos extremos. Indica que pueden existir una cantidad arbitraria de vnculos entre instancias de las dos clases. Es el tipo ms complejo de asociacin.
Pueden existir dos o ms asociaciones entre dos clases conceptuales
69
Navegabilidad Indica que es posible enviar mensajes en la direccin de la flecha en uno de los dos extremos de asociacin no hay que especificarla hasta que el diagrama de clases sea estable
70
Asociaciones Reflexivas
Modelo de Dominio III

Continuacin de Asociaciones Agregacin Es un tipo de asociacin que se utiliza para modelar las relaciones todo-parte entre las cosas. El todo se denomina compuesto
Normalmente se identifica en el Modelo de Diseo, pero puede ser til o necesario identificar algunas relaciones de agregacin en el Modelo del Dominio. Representacin en UML: un rombo hueco o relleno en el extremo del compuesto de una asociacin todo-parte El nombre de la asociacin se suele excluir porque se piensa normalmente como Tieneparte
Agregacin de composicin
La parte es un miembro de un nico objeto compuesto y que existe una dependencia de existencia y disposicin de la parte sobre el compuesto La multiplicidad en la parte del compuesto slo puede ser 1 Ejemplo: en una relacin Coche Motor, el motor tiene sentido como tal (existe) nicamente si est asociado a un coche Representacin en UML: un rombo relleno
71
Agregacin compartida
La multiplicidad en el extremo del compuesto puede ser ms de uno: la parte puede estar simultneamente en muchas instancias del compuesto Se utiliza para conceptos abstractos, no fsicos Representacin en UML: un rombo hueco
Identificacin de la agregacin
Si hay duda, se descarta Se debe mostrar una agregacin: o cuando el tiempo de vida de la parte est ligado al tiempo de vida del compuesto (existe una dependencia de creacin eliminacin de la parte en el todo). o cuando existe un ensamblaje obvio todo-parte fsico o lgico o cuando alguna propiedad del compuesto se propaga a las partes, como la ubicacin o cuando las operaciones que se aplican sobre el compuesto se propagan a las partes, como la destruccin, movimiento o grabacin
Generalizacin
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 jerarquas de clases. Superclase conceptual: su definicin es ms general y abarca ms que la definicin 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
Jerarqua de clases
Las declaraciones sobre las superclases se aplican a las subclases Regla del 100%: el 100% de la definicin 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 inters Cuando la subclase tiene asociaciones adicionales de inters 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
Cuando definir una superclase conceptual
Cuando las subclases potenciales representan variaciones de un concepto similar Cuando las subclases se ajustarn 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 asociacin que se puede unir y relacionar con la superclase
Jerarquas de clases y herencia en el software
La herencia o es un mecanismo software para hacer que las caractersticas 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 Diseo y Modelo de Implementacin o las jerarquas de clases conceptuales del Modelo del Dominio pueden reflejarse o no en el Modelo de Diseo, dependiendo de las caractersticas del lenguaje y otras cuestiones
74
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 tambin un miembro de una subclase, entonces las clase C se denomina clase conceptual abstracta.
Clases asociacin
En un modelo del dominio, si una clase C puede tener simultneamente 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 nmeros de telfono. Se colocar el nmero de telfono en otra clase, como
75
NmeroTelfono o InformacinDeContacto, y se asocian muchas de estas clases a Persona. Gua. Hay un atributo relacionado con una asociacin el tiempo de vida de las instancias de la clase asociacin depende de la asociacin existe una asociacin muchos-a- muchos entre dos conceptos, e informacin asociada con la propia asociacin
Modelo de Dominio IV Atributos
76
Es un valor de datos lgico de un objeto Se incluyen aquellos atributos para los que los requisitos indican la necesidad de registrar su informacin Ejemplo: un recibo recoge la informacin de una venta, incluyendo fecha y hora. La direccin quiere conocer fecha y hora de las ventas. Por tanto, la clase Venta necesita los atributos fecha y hora Notacin UML: se muestran en el segundo compartimento del rectngulo 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, nmero, string y hora otros: Direccin, Color, Telfono, NIF, Cdigo Postal,... Importante: relacionar las clases conceptuales con una asociacin, no con un atributo. En caso de duda, se debe optar por usar una clase conceptual antes que un atributo. Durante el diseo y la implementacin podrn 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 (nmero de telfono, nombre de persona,...)
77
hay operaciones asociadas con l, como algoritmos de validacin (NIF, nmero 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 abstraccin de uno o ms tipos con estas cualidades (un identificador de artculo en el dominio de ventas es una generalizacin de tipos como el Cdigo de Producto Universal UPC- o el Nmero de Artculo 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 caractersticas Representacin: como clase independiente o en el compartimento de atributos de la clase, dependiendo de la utilizacin del modelo del dominio y la importancia de los conceptos en el dominio
Cantidades y unidades de los atributos

La mayora de las cantidades numricas llevan unidades asociadas no deben representarse nicamente como nmeros Ejemplos: precio, velocidad, peso ... Solucin: representar la cantidad como una clase conceptual aparte con una unidad asociada
78
Un Modelo de Dominio
Utilizacin 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 comprensin o Permite realizar tareas de anlisis en paralelo, de tal forma que diferentes equipos o personas analizan diferentes subdominios Notacin 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
80
Cmo dividir el Modelo del Dominio
Se deben poner juntos en paquetes los elementos que: o se encuentran en el mismo rea de inters (estn estrechamente relacionados por conceptos u objetivos) o estn juntos en una jerarqua de clases o participan en los mismos casos de uso o estn fuertemente asociados Consejo o utilizar un paquete Dominio que ser el raz de todos los elementos relacionados con el modelo del dominio o utilizar un paquete Elementos Bsicos, o Conceptos Comunes, para englobar todos los elementos compartidos, comunes a otros elementos, bsicos,...
81
Bibliografa
[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. Espaa. Addison Wesley. [Booch, G. ; Jacobson, I. RumbaughT, J. 2000] El Lenguaje Unificado de Modelado. Manual de Referencia. Espaa. Addison Wesley. [Brooks, 1987] No Silver Bullet. Essence and Accident in Software Engineering. USA. IEEE Computer. [Ceria, S. 2000] Ingeniera de software I. Casos de Uso. Un Mtodo Practico para Explorar Requerimientos. Argentina. Universidad de Buenos Aires UBA. [Craing, L. 1999] UML Y PATRONES. Introduccin al anlisis y diseo orientado a objetos. Espaa. Pearson. [David M. 1998] Ishikawa Fise Bone Diagram. Disponible en Internet: <http://www.mansci.uwaterloo.ca/~msci432/Notes/F_Fish_bone.htm [Fowler M. 1999] Methods In Practice: Use and Abuses Cases. USA. Disponible en Internet: <http://www.distributedComputing.com [Fowler, M ; Scott. 1999] UML gota a gota. Espaa. Pearson. [Ishikawa K. 1969] Ishikawa Diagram. USA. Disponible en Internet <http://imedia.vuse.vanderbilt.edu/mt322/library2/ishikawa.htm [Kotler, P. 1993] Direccin de la Mercadotenia. Septima Ediccin. USA. Prentice Hall. [Kotonya G. ; Sommerville I. 1998] Requirements Engineering. Processes and techniques. USA. J. Wiley. [Lasnier, C. 1995] Requerimientos: Formas de participacin del usuario. Uruguay. [Ortas, 2001] Cuestionario de Tareas. Uruguay. Universidad ORT Uruguay. [Ortas, A. 2001] Aproximacin a la Ingeniera de Requerimientos. Uruguay. Universidad ORT Uruguay. [Pressman, R. 1998] INGENIERA DEL SOFTWARE: Un enfoque prctico. Cuarta edicin. Espaa. McGraw-Hill. [Senn, James A.] Anlisis y Diseo de Sistemas de Informacin. Segunda Edicin. McGraw Hill. 1992.
82

Manual de Requerimientos PDF

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual de Requerimientos PDF

Cargado por

Copyright:

Formatos disponibles

Grupo para el Desarrollo de Tecnologas de Software

Manual de Requerimientos. Ingeniera de Software

Un requerimiento existe porque:

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Lectores de los Requerimientos

Grupo para el Desarrollo de Tecnologas de Software

El Glosario Es la lista de los trminos relevantes y sus definiciones

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Estructura del documento de Requerimientos

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Extraccin - Anlisis del Problema

Los Enfoques del Anlisis

Anlisis orientado a puntos de vista

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Informacin de servicios de los puntos de vista

Datos/Control a Puntos de vista

Jerarqua de puntos de vista

Grupo para el Desarrollo de Tecnologas de Software

Plataforma cliente/disposicin de efectivo

Anlisis de datos y control

Grupo para el Desarrollo de Tecnologas de Software

Contexto del sistema de cajero

Problemas con el anlisis

Grupo para el Desarrollo de Tecnologas de Software

Factores Sociales y Organizacionales

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Costo de entrenamiento/capacitacin en la herramienta

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Casa de calidad o QFD

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Objetivos del UML

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

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

Actores Casos de uso Relaciones de Uso, Herencia y Comunicacin

Relaciones de Uso, Herencia y Comunicacin

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Grupo para el Desarrollo de Tecnologas de Software

Encontrar Actores y Casos de Uso Objetivos