Академический Документы
Профессиональный Документы
Культура Документы
CIBERTEC
ndice
Presentacin Red de contenidos Unidad de Aprendizaje 1 INGENIERA DE SOFTWARE, RUP Y UML 1.1 Tema 1 : Ingeniera de Software, Metodologa RUP y UML
Pgina
5 7
9 11 12 13 14 19 20 22 25 26 30 39 39 39 39 42
1.1.1. : Elementos claves de la Ingeniera de Software 1.1.2. : Las fases genricas de un proceso de software 1.1.3. : Modelos de Proceso de Software 1.1.4. : Metodologa RUP (Rational Unified Process -RUP) 1.1.5 : Mejores Prcticas de RUP
1.1.6. : Estructura de RUP 1.1.7. : Modelamiento Visual empleando el (UML) 1.1.8. : El Lenguaje de Modelamiento Unificado 1.1.9. : Diagramas de UML 2.0 1.2 Tema 2 : Herramienta Case y Entorno de IBM RSA
1.2.1. : Objetivos de las herramientas C.A.S.E. 1.2.2. : Tipos de herramientas C.A.S.E. 1.2.3. : Ejemplos de herramientas C.A.S.E. 1.2.4 : Rational Software Architect
Unidad de Aprendizaje 2 DISCIPLINA DEL MODELADO DEL NEGOCIO 2.1 Tema 3 : Modelado del Negocio 43 45 45 46 46 48 48 48 48 49
2.1.1. : Cundo ser necesario hacer el Modelado de Negocio? 2.1.2. : Cundo no ser necesario hacer el Modelado de Negocio? 2.1.3. : Actividades para realizar un Modelado de Negocio 2.2 Tema 4 : Modelo de Casos de uso del Negocio
2.2.1. : Determinar la situacin de la organizacin 2.2.2. : Identificar los procesos de negocio 2.2.3. : Refinar las definiciones de los procesos de negocio 2.2.4. : Artefactos del Modelo de Casos de uso del negocio
CIBERTEC
2.3 Tema 5
50 50 51
2.3.1. : Disear las realizaciones de los procesos de negocio 2.3.2. : Artefactos del Modelo de Anlisis del negocio Unidad de Aprendizaje 3 DISCIPLINA DE LA CAPTURA DE REQUISITOS 3.1 Tema 6 : Captura de requisitos
63 65 65 67 68 69 72 76 77 84 85 85 88 90 94 94 95 98 100 108
3.1.1. : Artefactos de la Captura de Requisitos 3.1.2. Actividades para realizar la Captura de Requisitos
3.1.3. : Requerimientos 3.1.4. 3.1.5. Requisitos FURPS Tcnicas para capturar requisitos
3.1.6. : Captura de requisitos a solicitud del cliente 3.1.7. : Captura de requisitos a partir del diagrama de actividades del negocio 3.2 Tema 7 : Modelo de casos de uso. 3.2.1. : Encontrar actores y casos de uso 3.2.2. Encontrar actores
3.2.3. : Encontrar casos de uso 3.2.4. 3.3 Tema 8 Crear el Diagrama de casos de uso : Estructurando el modelo de casos de uso.
3.3.1. : Objetivos 3.3.2. 3.3.3. Tipos de relaciones Casos de uso abstractos y concretos
CIBERTEC
Presentacin
Anlisis y Diseo de Sistemas I pertenece a la lnea formativa y se dicta en las carreras de Computacin e Informtica, Administracin y Sistemas. El curso imparte conocimientos relacionados con el proceso de Ingeniera de Software Orientado a Objetos que permite a los alumnos utilizar una metodologa y el lenguaje de modelamiento unificado para desarrollar un software de calidad. El manual para el curso ha sido diseado bajo la modalidad de unidades de aprendizaje, las que se desarrollan durante semanas determinadas. En cada una de ellas, hallar los logros, que debe alcanzar al final de la unidad; el tema tratado, el cual ser ampliamente desarrollado; y los contenidos, que debe desarrollar, es decir, los subtemas. Por ltimo, encontrar las actividades que deber desarrollar en cada sesin, que le permitirn reforzar lo aprendido en la clase.
El curso es terico prctico: consiste en un taller de desarrollo de proyectos de software. En primer lugar, se inicia con la comprensin de la Ingeniera de Software y el proceso de desarrollo de software RUP. Contina con la presentacin del modelamiento visual y el lenguaje de modelamiento unificado UML. Luego, se desarrolla la disciplina del Modelado del Negocio. Por ltimo, se concluye con el desarrollo de la disciplina de la Captura de Requisitos.
CIBERTEC
CIBERTEC
Red de contenidos
Ingeniera de Software
Modelado del Negocio Modelo de Casos de Uso del Negocio Modelo de Anlisis del Negocio
Captura de Requisitos
Herramientas CASE
CIBERTEC
CIBERTEC
UNIDAD
1
INGENIERA DE SOFTWARE, METODOLOGA RUP Y UML
LOGRO DE LA UNIDAD DE APRENDIZAJE Al trmino de la unidad, el alumno, a partir del correcto entendimiento de la importancia del papel que cumple la Ingeniera de Software dentro de las organizaciones, describe las ventajas y desventajas de los modelos de procesos de desarrollo de software y la importancia de emplear metodologa RUP para el correcto modelado del ciclo de vida de un software. Asimismo, el alumno describe los diagramas de UML y utiliza la herramienta CASE Rational Software Architect. TEMARIO
1.1 Tema 1 1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.1.6. 1.1.7. 1.1.8. 1.1.9. 1.2 Tema 2 1.2.1. 1.2.2. 1.2.3. 1.2.4. : : : : : : : : : : : : : : Ingeniera de Software, Metodologa RUP y UML Elementos claves de la Ingeniera de Software Las fases genricas de un proceso de software Modelos de Proceso de Software Metodologa RUP (Rational Unified Process - RUP) Mejores Prcticas de RUP Estructura de RUP Modelamiento Visual empleando el (UML) El Lenguaje de Modelamiento Unificado Diagramas de UML Herramienta Case y Entorno de IBM RSA Objetivos de las herramientas C.A.S.E. Tipos de herramientas C.A.S.E. Ejemplos de herramientas C.A.S.E. Rational Software Architect
ACTIVIDADES PROPUESTAS
Los alumnos resuelven un caso para aplicar los diagramas de UML.
CIBERTEC
10
CIBERTEC
11
El fundamento de la ingeniera del software es la capa de proceso. El proceso de la ingeniera del software es la unin que mantiene juntas las capas de tecnologa y que permite un desarrollo racional y oportuno de la ingeniera del software. El proceso define un marco de trabajo para un conjunto de reas clave de proceso que se deben establecer para la entrega efectiva de la tecnologa de la ingeniera del software. Las reas claves del proceso forman la base del control de gestin de proyectos del software y establecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.
1 2
DRAE, Diccionario de la Real Academia Espaola de la Lengua. IEEE, Institute of Electrical and Electronics Engineers. 3 ACM, Association for Computing Machinery.
CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS CIBERTEC
12
Los mtodos de la ingeniera del software indican cmo construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Los mtodos de la ingeniera del software dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas. Las herramientas de la Ingeniera del software proporcionan un enfoque automtico o semiautomtico para el proceso y para los mtodos. Cuando se integran herramientas para que la informacin creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniera del software asistida por computadora (CASE). Luego de describir cada capa, se puede afirmar que el objetivo de la ingeniera de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboracin), mediante un proceso apoyado por mtodos y herramientas.
CIBERTEC
13
1.1.1.5 Procesos Los procesos son la combinacin de estrategias, mtodos y herramientas, que en forma conjunta dan un resultado particular. Los procesos indicarn qu herramientas debern utilizarse y cundo se aplican determinados mtodos o tcnicas. Definen la secuencia en que se aplican los mtodos, los documentos que se requieren, los controles que aseguren la calidad y las mejores prcticas que permiten a los gestores a evaluar los progresos. Concretamente, el proceso de desarrollo de software define quin va a hacer qu, cundo hacerlo y cmo alcanzar un cierto objetivo.
DEFINICIN
DESARROLLO
Fallos de definicin
MANTENIMIENTO
Errores
Modificaciones y adaptaciones
Figura 1.2.- Fases genricas de un proceso de software.
1.1.2.1. Fase de definicin Se centra sobre el qu. Es decir, durante la definicin, el que desarrolla el software intenta identificar qu informacin ha de ser procesada, qu funcin y rendimiento se desea, qu comportamiento del sistema, qu interfaces van a ser establecidas, qu restricciones de diseo existen, y qu criterios de validacin se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Aunque los mtodos aplicados durante la fase de definicin variarn dependiendo del paradigma de ingeniera del software (o combinacin de paradigmas) que se aplique, de alguna manera tendrn lugar tres tareas principales: La ingeniera de sistemas o de informacin Planificacin del proyecto del software Anlisis de requisitos 1.1.2.2. Fase de desarrollo Se centra en el cmo. Es decir, durante el desarrollo un ingeniero del software intenta definir cmo han de disearse las estructuras de datos, cmo ha de implementarse la funcin dentro de una arquitectura de software, cmo han de implementarse los detalles procedimentales, cmo han de caracterizarse interfaces, cmo ha de traducirse el diseo en un lenguaje de programacin (o lenguaje no procedimental) y
CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS CIBERTEC
14
cmo ha de realizarse la prueba. Los mtodos aplicados durante la fase de desarrollo variarn, aunque las tres tareas especficas tcnicas deberan ocurrir siempre: El diseo del software La generacin de cdigo Las pruebas del software 1.1.2.3. Fase de mantenimiento Se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios: Correctivo. Para corregir los defectos. Adaptativo. Para acomodarlo a los cambios de su entorno externo. (modificaciones en la legislacin, CPU, SO, las reglas de negocio, etc.) Perfectivo. Para agregar otras funciones adicionales que van a producir beneficios. Preventivo. Tambin llamado reingeniera del software, estos cambios se realizan a fin de que se puedan corregir, adaptar y mejorar ms fcilmente los programas. Adems de estas actividades de mantenimiento, los usuarios de software requieren un mantenimiento continuo. Los asistentes tcnicos a distancia, telfonos de ayuda y sitios Web de aplicaciones especficas se implementan frecuentemente como parte de la fase de mantenimiento. 1.1.2.4. Actividades de proteccin Las fases descritas en esta visin general de la ingeniera del software se complementan con un nmero de actividades protectoras. Entre las actividades tpicas de esta categora se incluyen: Seguimiento y control del proyecto de software Revisiones tcnicas formales Garanta de calidad del software Gestin de configuracin del software Preparacin y produccin de documentos Gestin de reutilizacin Mediciones Gestin de riesgos
CIBERTEC
15
Existen muchos modelos de procesos para la ingeniera de software, entre ellos: Modelo Lineal Secuencial (Ciclo de Vida Bsico o Modelo de Cascada) Modelo de Construccin de Prototipos Modelo DRA (Desarrollo Rpido de Aplicaciones) Modelos Evolutivos de Procesos de Software: o El modelo incremental o El modelo espiral o El modelo de desarrollo concurrente Desarrollo basado en componentes
1.1.3.1 Modelo Lineal Secuencial Llamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo lineal secuencial propone un enfoque sistemtico, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. Es ideal para proyectos pequeos, rgidos, y donde se especifiquen muy bien los requisitos. Existen algunos problemas que ocurren al utilizar este modelo: Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo, pues traslapan las etapas. A menudo es difcil que el cliente exponga explcitamente todos los requisitos. El interesado debera exponer los requisitos en la etapa inicial, pero en realidad l lo hace a travs de todo el proceso y esto complica las cosas. El cliente debe tener paciencia. La primera versin del software llega al final del proceso, a veces el afn del cliente hace que la aplicacin final no cumpla con los requisitos
Anlisis
Diseo
Cdigo
Prueba
Mantenimiento
1.1.3.2. Modelo de Construccin de Prototipos Este modelo comienza con la recoleccin de requisitos, el desarrollador y el cliente definen los objetivos globales para el software, originndose un diseo rpido que se centra en una representacin de esos aspectos del software que sean visibles para el usuario/cliente. De este diseo surge la construccin de un prototipo y este es evaluado por el cliente/usuario. La interaccin ocurre cuando el prototipo satisface las necesidades del cliente.
CIBERTEC
16
Con este modelo se reduce el riesgo de construir productos que no satisfagan las necesidades del usuario. Por otro lado, reduce costos y aumenta la probabilidad de xito. Pero el problema es que el cliente se sienta decepcionado por no permitirle usar la primera versin del prototipo o que el desarrollador se sienta tentado en aumentar el prototipo para construir el sistema final sin tener en cuenta cuestiones de calidad.
Escuchar al cliente
1.1.3.3 Modelo DRA Es una adaptacin a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rpido de proyectos grandes utilizando un enfoque de construccin basado en el componente. Comprende las siguientes fases: Anlisis, diseo, cdigo, pruebas y entrega. Si no existe el compromiso entre clientes y desarrolladores o si los riesgos tcnicos son altos, los proyectos DRA fracasan.
CIBERTEC
17
1.1.3.4 Modelo Incremental Este modelo combina elementos del modelo lineal secuencial con la filosofa interactiva de construccin de prototipos; viene a suplir el problema de no poder retroceder en las fases de desarrollo del software. El primer incremento es un producto esencial, se afrontan requisitos bsicos, pero muchas funciones suplementarias quedan sin extraer. El cliente utiliza el producto central y como resultado de utilizacin o evaluacin, se desarrolla un plan para el incremento siguiente, este plan afronta la modificacin del producto central para lograr satisfacer al cliente, la entrega de funciones y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. Este modelo es apropiado para proyectos de larga duracin que no consuman muchos recursos y como el producto va desarrollndose incrementalmente, se puede financiar el proyecto por partes. Debido a la interaccin con usuarios finales cuando es necesaria la retroalimentacin hacia el grupo de desarrollo, este proceso puede exigir demasiado tiempo, agregndose un costo extra a la compaa, pues mientras estos usuarios evalan el software dejan de ser productivos para la compaa.
1.1.3.5 Modelo Espiral Es un modelo de proceso de software evolutivo que acompaa la naturaleza interactiva de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo, las ltimas iteraciones, se producen versiones cada vez ms completas de ingeniera del sistema. Este modelo se divide en un nmero de actividades estructurales o regiones de tareas, como comunicacin con el cliente, planificacin, anlisis de riesgos, ingeniera, construccin y adaptacin, evaluacin del cliente.
CIBERTEC
18
Debido a su complejidad, no se aconseja utilizarlo en pequeos sistemas. Por otro lado, resulta difcil convencer a grandes clientes de que el enfoque evolutivo es controlable.
1.1.3.6 Modelo de Desarrollo Concurrente Provee una meta descripcin del proceso de software Mientras que en el Espiral la principal contribucin es que las actividades del software ocurran repetidamente, en el Concurrente es la capacidad de describir las mltiples actividades del software que ocurren simultneamente. Dado que los requisitos cambian es muy probable que una vez haya comenzado la fase de diseo, sea necesario incorporar cambios. En estos casos No se debe detener el diseo, sino que se debe continuar si es posible al mismo tiempo que se modifican los requisitos. Por lo tanto en este modelo, diversas actividades pueden estar ocurriendo concurrentemente.
CIBERTEC
19
1.1.3.7 Desarrollo Basado en Componentes Es un modelo fuertemente orientado a la reutilizacin y trabaja sobre la base de tecnologas orientado a objetos. Este modelo consta de 4 fases ilustradas en la figura 1.9. A continuacin se describe cada fase: Anlisis de componentes: Se determina qu componentes pueden ser utilizados para el sistema en cuestin. Casi siempre hay que hacer ajustes para adecuarlos. Modificacin de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes ms adecuados (fase 1). Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para disear o determinar este marco. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integracin es parte del desarrollo en lugar de una actividad separada.
CIBERTEC
20
Colaboracin entre equipos. El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc. Demostrar valor iterativamente. Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados. Elevar el nivel de abstraccin. Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. stos se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con UML. Enfocarse en la calidad. El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin.
Desarrollo Iterativo
En funcin de la cada vez mayor complejidad solicitada para los sistemas de software, ya no es posible trabajar secuencialmente, es decir, definir primero el problema completo, luego disear toda la solucin, construir el software y finalmente, testear el producto. Es necesario un enfoque iterativo, que permita una comprensin creciente del problema a travs de refinamientos sucesivos, llegando a una solucin efectiva luego de mltiples iteraciones acotadas en complejidad. RUP utiliza y soporta este enfoque iterativo que ayuda a atacar los riesgos mediante la produccin de releases ejecutables progresivos y frecuentes que permiten la opinin e involucramiento del usuario. A travs de las iteraciones que generan releases ejecutables, se logra detectar en forma temprana los desajustes e inconsistencias entre los requisitos, el diseo, el desarrollo y la implementacin del sistema, manteniendo al team de desarrollo focalizado en producir resultados. Administracin de Requisitos
Los requisitos son las condiciones o capacidades que el sistema debe conformar. La Administracin de Requisitos es un enfoque sistemtico para hallar, documentar, organizar y monitorear los requisitos cambiantes de un sistema.
CIBERTEC
21
La Administracin de Requisitos permite: a) b) c) d) que las comunicaciones estn basadas en requisitos claramente definidos que los requisitos puedan ser priorizados, filtrados y monitoreados que sea posible realizar evaluaciones objetivas de funcionalidad y performance que las inconsistencias se detecten fcilmente
RUP describe como: a) Obtener, organizar y documentar la funcionalidad y restricciones requeridas b) Documentar y monitorear las alternativas y decisiones Las nociones de Casos de Uso y de Escenarios utilizadas en RUP han demostrado ser una manera excelente de capturar los requisitos funcionales y asegurarse que dirigen el diseo, la implementacin y la prueba del sistema, logrando as que el sistema satisfaga las necesidades del usuario. Arquitectura basada en Componentes
El proceso de software debe focalizarse en el desarrollo temprano de una arquitectura robusta ejecutable, antes de comprometer recursos para el desarrollo en gran escala. RUP describe como disear una arquitectura flexible, que se acomode a los cambios, comprensible intuitivamente y promueve una ms efectiva reutilizacin de software. Soporta el desarrollo de software basado en componentes: mdulos no triviales que completan una funcin clara. RUP provee un enfoque sistemtico para definir una arquitectura utilizando componentes nuevos y preexistentes. Modelamiento Visual
RUP muestra como representar el software visualmente para capturar la estructura y comportamiento de arquitecturas y componentes. Las abstracciones visuales ayudan a comunicar diferentes aspectos del software; comprender los requisitos, ver como los elementos del sistema se relacionan entre s, mantener la consistencia entre diseo e implementacin y promover una comunicacin precisa. El estndar UML (Lenguaje de Modelado Unificado), creado por Rational Software, es el cimiento para un modelamiento visual exitosa. Verificacin continua de la Calidad
Es necesario evaluar la calidad de un sistema respecto de sus requisitos de funcionalidad, confiabilidad y performance. La actividad fundamental es el testing, que permite encontrar las fallas antes de la puesta en produccin. RUP asiste en el planeamiento, diseo, implementacin, ejecucin y evaluacin de todos estos tipos de testing. El aseguramiento de la calidad se construye dentro del proceso, en todas las actividades, involucrando a todos los participantes, utilizando medidas y criterios objetivos, permitiendo as detectar e identificar los defectos en forma temprana. Control de Cambios
La capacidad de administrar los cambios es esencial en ambientes en los cuales el cambio es inevitable. RUP describe como controlar, rastrear y monitorear los cambios para permitir un desarrollo iterativo exitoso. Es tambin una gua para establecer espacios de trabajo seguros para cada desarrollador, suministrando el aislamiento de los cambios hechos en otros espacios de trabajo y controlando los cambios de todos los elementos de software (modelos, cdigo, documentos, etc.). Describe como automatizar la integracin y administrar la conformacin de releases.
CIBERTEC
22
El eje horizontal representa tiempo y muestra el aspecto dinmico del proceso, expresado en trminos de ciclos, fases, iteraciones, y metas. El eje vertical representa el aspecto esttico del proceso; como est descrito en trminos de actividades, artefactos, trabajadores o roles y flujos de trabajo.
1.1.6.1. Fases RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se desarrolla en mayor o menor proporcin los distintos flujos de trabajo: Inicio: En esta primera fase se define el alcance y objetivos del proyecto. Elaboracin: Se desarrolla el plan del proyecto, la especificacin de caractersticas y la arquitectura base del sistema. Construccin: Esta fase se concentra en la elaboracin, de un producto totalmente operativo y eficiente y el manual de usuario. Transicin: Fase en el cual se instala el producto en el cliente y se entrena a los usuarios.
CIBERTEC
23
1.1.6.2. Flujos de Trabajo Los flujos de trabajo son tambin conocidos como disciplinas, consisten en una secuencia de actividades que producen un resultado observable (artefacto) a cargo de algn miembro del proyecto (rol).
Existen dos grupos de flujos de trabajo: de proceso y de apoyo. Las que se describirn a continuacin. 1.1.6.3. Flujos de trabajo del proceso Orientados al desarrollo del software. Comprende: Modelado del negocio: Describe la estructura y la dinmica de la organizacin donde se va a implantar el sistema que construyamos. Requisitos: Establece exactamente lo que tiene que hacer el sistema, para ello se extrae los requisitos utilizando diferentes mtodos. Anlisis y Diseo: Traduce los requisitos a una especificacin que describe cmo implementar el sistema, creando para ello, diferentes vistas arquitectnicas. Implementacin: Tiene en cuenta el desarrollo de software, las pruebas unitarias y la integracin. Pruebas: Describe la ejecucin de pruebas y las mtricas para rastreo de defectos. Despliegue o Implantacin: Incluye actividades relacionadas con la entrega de la aplicacin.
1.1.6.4. Flujos de trabajo de apoyo o de soporte Orientados a la gestin del proyecto. stos son:
Configuracin y Control de cambios: Mantiene la integridad de todos los artefactos que se crean en el proyecto. Tambin mantiene informacin del proceso evolutivo que se ha seguido. Gestin del proyecto: Es el arte de lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios. Entorno: Cubre la infraestructura necesaria para desarrollar un sistema.
CIBERTEC
24
1.1.6.5. Roles en RUP Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Un miembro del equipo de proyecto cumple normalmente muchos roles. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el dueo de un conjunto de artefactos. Por ejemplo, la figura 1.13 ilustra el rol del arquitecto de software.
A continuacin se lista algunos roles especficos dentro de cada rol genrico: Analistas: Analista de procesos de negocio. Diseador del negocio. Analista de sistema. Especificador de requisitos.
Desarrolladores: Arquitecto de software Diseador Diseador deinterfaz de usuario Diseador de cpsulas Diseador de base de datos Implementador Integrador
Gestores: Jefe deproyecto Jefe de control de cambios Jefe de configuracin Jefede pruebas Jefe de despliegue Ingeniero de procesos Revisor degestin del proyecto Gestor de pruebas
CIBERTEC
25
Por otro lado, un modelo se considera como til si presenta las siguientes caractersticas:
CIBERTEC
26
Preciso: Describen correctamente el sistema a ser construido. Consistente: Los distintos puntos de vista no expresan cosas que entren en conflicto entre ellas. Fcil de comunicrselo a otros. Mejora la comunicacin entre los miembros del equipo usando un lenguaje grfico. Fcil de cambiar. Legible: Todas las representaciones se realizan de la manera ms simple como sea posible.
CIBERTEC
27
1.1.8.1 Breve Historia de UML Los lenguajes de modelado de objetos aparecieron en la dcada de 1980, llegando a ser unos 50 a mediados de la dcada de 1990. Unos pocos mtodos empezaron a ganar importancia, ente ellos: el Mtodo OMT (Object-Modeling Technique) de James Rumbaugh, que era mejor para el anlisis orientado a objetos, el Mtodo Booch de Grady Booch, el cual era mejor para el diseo orientado a objetos, y el Mtodo OOSE (Object-Oriented Software Engineering) de Ivar Jacobson, que era un mtodo de ingeniera de software orientado a objetos. El esfuerzo para la definicin de UML comenz en Octubre de 1994, cuando Rumbaugh se uni a Booch en Rational Software Corporation (empresa donde trabajaba Booch). Unificaron sus mtodos de modelado y elaboraron el borrador de la versin 0.8 de UML. En 1995 Jacobson tambin se incorpor a Rational, incorporando as OOSE a UML. En 1996 se public la versin 0.9 de UML. Las tres personalidades que dieron el origen a UML son conocidas como los Tres Amigos. Las organizaciones que contribuyeron a la definicin de 1.0 de UML fueron Digital Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments y Unisys. El borrador de la especificacin UML 1.0 se ofreci para su estandarizacin al OMG en enero de 1997. Luego de varios aos y varias modificaciones, OMG adopt la versin oficial de UML 2.0 a principios del ao 2005, versin que integra varios esfuerzos para la definicin de una semntica de la especificacin ms slida. UML es evolutivo, actualmente va por la versin 2.4.1. la cual fue liberada en Agosto 2011. UML 2.5 fue lanzado en octubre de 2012 como una versin "En proceso" y todava tiene que ser formalmente liberada. Los documentos de las especificaciones de UML se encuentran en la pgina web de OMG (Object Management Group). En la siguiente figura se muestra las versiones, fechas de lanzamiento y URL donde se podr consultar las especificaciones de UML.
2.5
October 2012
URL http://www.omg.org/spec/UML/2.5
CIBERTEC
28
Qu es la OMG? La OMG (Object Management Group) es una asociacin sin fines de lucro formada por grandes corporaciones, muchas de ellas de la industria del software, como por ejemplo: IBM, Apple Computer, Sun Microsystems Inc y Hewlett-Packard. Esta asociacin se encarga de la definicin y mantenimiento de estndares para aplicaciones de la industria de la computacin. Otro de los estndares definidos por la OMG, adems del UML, es CORBA, el cual permite interoperabilidad multiplataforma a nivel de objetos de negocio. 1.1.8.2 Objetivos de UML Los objetivos de UML son muchos, pero se pueden sintetizar en las siguientes: Visualizar: UML permite expresar de una forma grfica un sistema de forma que otro lo puede entender. Especificar: UML permite especificar cules son las caractersticas de un sistema antes de su construccin. Construir: A partir de los modelos especificados se pueden construir los sistemas diseados. Documentar: Los propios elementos grficos sirven como documentacin del sistema desarrollado que pueden servir para su futura revisin.
1.1.8.3 Especificaciones fundamentales de UML 2.0 En las versiones previas del UML, se haca un fuerte hincapi en que UML no era un lenguaje de programacin. Un modelo creado mediante UML no poda ejecutarse. En el UML 2.0, esta asuncin cambi de manera drstica y se modific el lenguaje, de manera tal que permitiera capturar mucho ms comportamiento ( Behavior). De esta forma, se permiti la creacin de herramientas que soporten la automatizacin y generacin de cdigo ejecutable, a partir de modelos UML. Para lograr los objetivos de UML enunciados en el punto anterior, varios aspectos del lenguaje fueron reestructurados y/o modificados. La especificacin se separ en cuatro especificaciones (paquetes) bien definidas, tal como se muestra en la siguiente figura.
Es interesante destacar que el UML 2.0 puede definirse a s mismo. Es decir, su estructura y organizacin es modelable utilizando el propio UML 2.0; de esta manera,
CIBERTEC
29
se da un ejemplo de utilizacin del UML en un dominio distinto al del desarrollo de software. En este caso, cada paquete del diagrama representa cada una de las cuatro especificaciones que componen el lenguaje. Veamos a continuacin cada una de las principales especificaciones que componen UML 2.0. 1.1.8.4 Supraestructura La superestructura del UML es la definicin formal de los elementos del UML Es aqu donde se definen los diagramas y los elementos que los componen. Esta definicin sola contiene ms de 640 pginas. La superestructura es utilizada por los desarrolladores de aplicacin. Es aquella sobre la que hablan los libros y la que la mayora conoce de versiones anteriores del UML. Se encuentra dividida en niveles. Estos niveles se conocen como:
Bsico (L1): Contiene los elementos bsicos del UML 2.0, entre ellos: Diagramas de clases, Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de Uso Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles, Diagramas de Componentes y Diagramas de despliegue. Completo (L3): Representa la especificacin del UML 2.0 completa, como por ejemplo: las Acciones, Caractersticas avanzadas y PowerTypes, entre otros.
Es importante destacar que basta con que una herramienta implemente el nivel de conformidad Bsico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad de caractersticas (features) bastante amplia entre dos herramientas distintas, aunque stas sean UML 2.0 compatibles. 1.1.8.5 Infraestructura En la Infraestructura del UML se definen los conceptos centrales y de ms bajo nivel. La Infraestructura es un meta-modelo (un modelo de modelos) y mediante la misma se modela el resto del UML. Generalmente, la infraestructura no es utilizada por usuarios finales del UML; pero provee la piedra fundamental sobre la cual la Superestructura es definida. La Infraestructura brinda tambin varios mecanismos de extensin, que hacen del UML un lenguaje configurable. Para los usuarios normales del UML basta con saber si la infraestructura existe y cules son sus objetivos. 1.1.8.6 OCL OCL son siglas en ingls que significan: Object Constraint Language y que en castellano se traducen como: Lenguaje de Restricciones de Objetos. El OCL define un lenguaje simple, para escribir restricciones y expresiones sobre elementos de un modelo. El OCL suele ser til cuando se est especificando un dominio particular mediante el UML y es necesario restringir los valores permitidos para los objetos del dominio. El OCL brinda la posibilidad de definir invariantes, precondiciones, poscondiciones y restricciones en los elementos de un diagrama. Fue incorporado a UML en la versin 1.1. Originalmente, fue especificado por IBM y es un ejemplo ms de las muchas herramientas agregadas a UML.
CIBERTEC
30
1.1.8.7 Intercambio de Diagramas La especificacin para el intercambio de diagramas fue escrita para facilitar una manera de compartir modelos, realizados mediante UML, entre diferentes herramientas de modelado. En versiones anteriores del UML, se utilizaba un Schema XML para capturar los elementos utilizados en el diagrama; pero este Schema no deca nada acerca de la manera en que el modelo deba graficarse. Para solucionar este problema, la nueva especificacin para el intercambio de diagramas fue desarrollada utilizando un nuevo Schema XML, que permite construir una representacin SVG (Scalable Vector Graphics). Esta especificacin es denominada con las siglas XMI, que en ingls significa: XML Metadata Interchange; y en castellano se traduce como: XML de Intercambio de Metadata (datos que representan datos). Tpicamente esta especificacin es solamente utilizada por quienes desarrollan herramientas de modelado UML.
CIBERTEC
1.1.9.1 Diagrama de clases Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos, operaciones y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargaran del funcionamiento y la relacin entre uno y otro.
1.1.9.2. Diagrama de componentes Un diagrama de componentes muestra las organizaciones y dependencias lgicas entre componentes software (cdigo fuente, binarios o ejecutables). Desde el punto de vista del diagrama de componentes, se tiene en consideracin los requisitos relacionados con la facilidad de desarrollo, la gestin del software, la reutilizacin, y las restricciones impuestas por los lenguajes de programacin y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un diagrama de componentes sern componentes y paquetes. En cuanto a los componentes, slo aparecen tipos de componentes, ya que las instancias especficas de cada tipo se encuentran en el diagrama de despliegue.
33
1.1.9.3. Diagrama de objetos Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias especficas de clases (objetos) en un momento particular del sistema. Utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notacin es similar a los diagramas de clase.
1.1.9.4 Diagrama de estructura compuesta Este tipo de diagrama fue especficamente diseado para la representacin de patrones de diseo, y es una de las modificaciones de mayor impacto dentro de UML 2.0. Esta modificacin al UML hace que ahora todos los Clasificadores puedan tener una estructura compuesta. Mediante una composicin de estructuras, el comportamiento de las instancias de otros Clasificadores (estructura interna) contenidos en un Clasificador determinado, puede especificarse como Colaboraciones. Los conceptos principales para describir la estructura interna son: Partes, Puertos y Conectores.
CIBERTEC
34
1.1.9.5 Diagrama de despliegue Describen la configuracin del entorno de mquinas y redes sobre el que se distribuyen componentes y procesos del sistema.
1.9.1.6 Diagrama de actividades Muestra un flujo ordenado de actividades. Los diagramas de actividades tienen un amplio nmero de usos, desde definir un flujo de programa bsico, hasta capturar los puntos de decisin y acciones dentro de cualquier proceso generalizado.
CIBERTEC
35
1.1.9.7 Diagrama de paquetes Este tipo de diagrama se usa para dividir el modelo en contenedores lgicos (paquetes) y describen las interacciones entre ellos a un nivel ms alto. Los paquetes ofrecen un mecanismo general para la organizacin de los modelos/subsistemas/capas agrupando elementos de modelado. Cada paquete se corresponde a un submodelo (subsistema) del modelo (sistema); se pueden anidar paquetes. Por ltimo, puede crearse relaciones de dependencia, esto se da cuando un componente de un paquete necesita un componente de otro paquete.
1.1.9.8 Diagrama de casos de uso Este Diagrama permite realizar la especificacin del alcance funcional del producto software que se construye y de los actores, entes que interactan con el producto software. Son usados para representar los procesos de negocio de la organizacin objetivo y las funcionalidades que representan la arquitectura del sistema por cada proceso de negocio.
CIBERTEC
36
1.1.9.9 Diagrama de mquina de estados Tpicamente este diagrama se utiliza para representar todos los posibles estados que los objetos de una clase puedan tener. Los diagramas de estado no se hacen para todas las clases, es slo para aquellas clases que tengan un nmero de estados bien definidos y en donde el comportamiento de la clase es afectado y cambiado por los distintos estados.
1.1.9.10 Diagrama de secuencia Muestra una secuencia de mensajes pasadas entre los objetos usando una lnea de tiempo vertical.
CIBERTEC
37
1.1.9.11 Diagrama de comunicacin Antes era conocida como diagrama de colaboracin. Muestra la red y la secuencia de mensajes de comunicaciones entre objetos en tiempo de ejecucin durante una instancia de colaboracin.
1.1.9.12 Diagrama de tiempo Fusionan los diagramas de secuencia y estados para proveer una vista de un estado del objeto dentro de una escala de tiempo y los mensajes que modifican ese estado. til para sistemas de tiempo real, de control automtico, etc.
CIBERTEC
38
El propsito primario de los diagramas de tiempos (o temporizados) es mostrar los cambios en el estado, o la condicin, de una lnea de vida de una instancia (de un Clasificador o un Rol de un clasificador), a lo largo del tiempo y de manera lineal. El uso ms comn es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estmulos aceptados. Un diagrama de tiempos se ve tal y como lo muestra la figura 1.30. No resulta trivial leer un diagrama de tiempos; si no se lo conoce, puede resultar poco intuitivo. 1.1.9.13 Diagrama de descripcin de la interaccin Es un diagrama que muestra cmo interactan varios diagramas de interacciones (por ejemplo, de secuencias). Este tipo de diagramas es muy til para mostrar de qu manera distintos escenarios se combinan. En el ejemplo de la figura 2.18, se muestra la interaccin de un cliente con un cajero ATM, separado en cuatro fragmentos:
Secuencia de login: la cual pedir un usuario y una clave a un cliente. (la secuencia supone que la clave y usuario ingresados son vlidos). Secuencia de seleccionar una operacin. Las operaciones permitidas por este cajero son cancelar o extraer dinero. Si cancela, se ejecutar la secuencia de deslogueo del cliente. Luego finalizar la operatoria.
CIBERTEC
39
CIBERTEC
40
CIBERTEC
41
CIBERTEC
42
CIBERTEC
43
UNIDAD
2
DISCIPLINA DEL DEL NEGOCIO MODELADO
LOGRO DE LA UNIDAD DE APRENDIZAJE Al trmino de la unidad, el alumno sustentar el primer avance de su proyecto, acerca del Modelado de negocio de la empresa en estudio, el cual est conformado por el Modelo de casos de uso del negocio, en el que identificar los objetivos, casos de uso y actores del negocio, y realizar el diagrama general de casos de uso del negocio, mientras que para el Modelo de anlisis del negocio, a los trabajadores y entidades, y realizar los diagramas de clases y de actividades del negocio. TEMARIO
2.1 Tema 3 2.1.1. 2.1.2. 2.1.3. 2.2 Tema 4 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.3 Tema 5 2.3.1. 2.3.2. : : : : : : : : : : : : Modelado del Negocio Cundo ser necesario hacer el Modelado de Negocio? Cundo no ser necesario hacer el Modelado de Negocio? Actividades para realizar un Modelado de Negocio Modelo de Casos de uso del Negocio Determinar la situacin de la organizacin Identificar los procesos de negocio Refinar las definiciones de los procesos de negocio Artefactos del Modelo de Casos de uso del negocio Modelo de Anlisis de Negocio Disear las realizaciones de los procesos de negocio Artefactos del Modelo de Anlisis dl negocio
ACTIVIDADES PROPUESTAS
Los alumnos desarrollan el Modelo de casos de uso del negocio de un proceso de negocio. Los alumnos desarrollan el Modelo de anlisis del negocio de un proceso de negocio.
CIBERTEC
44
CIBERTEC
45
CIBERTEC
46
CIBERTEC
47
Por ltimo, la actividad que ejecutaremos para obtener el Modelo de anlisis del negocio es: Disear las realizaciones de los procesos de negocio
CIBERTEC
48
CIBERTEC
49
2.2.4 .Artefactos del Modelo de Casos de uso del negocio Artefacto Descripcin
Documento que contiene la visin del negocio, un glosario de trminos del negocio, los objetivos del negocio y reglas del negocio.
Situacin del Negocio
Business Goal
Es un requisito que debe ser satisfecho por el negocio. Describe el valor deseado de una medida en particular a futuro, y se utiliza para planear y administrar las actividades del negocio. El objetivo debe ser claro, mesurable, alcanzable, realista y sensible al tiempo. Se permite la relacin de dependencia entre objetivos del negocio y la de soporte de un caso de uso del negocio. Define un conjunto de acciones que el negocio lleva a cabo y provee resultados de valor a quienes interactan con el. Describe un proceso de negocio desde un punto de vista externo que percibe algn tipo de valor. Definen los lmites de la organizacin. Representa un rol que algo o alguien externo desempea en relacin con el negocio. Puede ser asociado a uno ms casos de uso del negocio.
Business Actor
Representa la vista externa del negocio. Es un modelo que describe la direccin e intencin del negocio. La direccin es provista por los objetivos del negocio. Mientras que la intencin es expresada por los diagramas que permiten ver cmo interactuar con el entorno.
Business Use Case Model
Reporte que contiene informacin de los actores del negocio identificados en el modelo de casos de uso del negocio.
Business Actor
Documento que contiene las caractersticas de un proceso de negocio. Se realiza una especificacin por cada caso de uso de negocio.
Business Use-Case Specification
Reglas de negocio
Es una poltica o condicin que debe ser satisfecha por el negocio. Ejm: El pago de planillas se realizar los das 25 de cada mes y va depsito en cuenta bancaria.
CIBERTEC
50
Business Worker
Business Entity
Coleccin de diagramas que muestra cmo los trabajadores del negocio y entidades del negocio llevan a cabo el caso de uso del negocio. Generalmente se utilizan Diagramas de Clases, Diagramas de Actividades y Diagramas de Colaboracin para realizar el detalle de cada proceso de negocio.
CIBERTEC
51
Representa la vista interna del negocio. Es un modelo que describe la realizacin de los casos de uso del negocio. Es una abstraccin de cmo los trabajadores del negocio y las entidades de negocio se relacionan y de cmo colaboran para realizar los casos del uso del negocio.
Business Analysis Model
Reporte que contiene informacin de los trabajadores del negocio identificados en el modelo de anlisis del negocio.
Business Worker
Reporte que contiene informacin de las entidades del negocio identificadas en el modelo de anlisis del negocio.
Business Entity
Tabla 2.2.- Artefactos del Modelo de Anlisis del Negocio.
CIBERTEC
52
Un da X en Elctrica comienza cuando un cliente solicita al vendedor un producto que se encuentra en vitrina. El vendedor verifica el stock de ese producto y si hay stock, le muestra e informa de las caractersticas de ese producto. Si el cliente est de acuerdo con el producto ofrecido, el vendedor le generar un ticket de pedido indicndole el cdigo del producto y el precio. El cliente se dirige a caja y el cajero le solicita el ticket de pedido para que le genere el comprobante de pago. El cajero le pregunta al cliente la forma de pago, efectivo o tarjeta, si el cliente informa que pagara en efectivo le solicita el dinero y genera el comprobante de pago, si el cliente informa que es tarjeta, el cajero le solicitara la tarjeta (Crdito o dbito) y su DNI para pasar la tarjeta por el terminal de POS y generar el Boucher, luego de ello le genera el comprobante de pago al cliente. Ya con el comprobante el cliente se dirige al vendedor para que le haga entrega del producto.
GLOSARIO Las tarjetas de dbito pueden utilizarse para disponer de efectivo en las sucursales bancarias y cajeros automticos, consultar el saldo y los movimientos de la cuenta asociada.
En el caso de la tarjeta de crdito, el monto a pagar oscila entre un mnimo y el total gastado, pero la parte de deuda no saldada implica un inters que el titular deber abonar en sus pagos siguientes.
Objetivos del negocio: Agilizar la atencin al cliente en un 5% con respecto al ao 2013.. Conocer el progreso de las ventas mensuales.
CIBERTEC
53
Flujo Trabajo
Flujo Bsico 1. El cliente solicita el electrodomstico que se encuentra en vitrina. 2. El vendedor verifica existencia del electrodomstico. 3. Si existe, el vendedor muestra el electrodomstico al cliente. 4. El cliente evala el electrodomstico. 5. Si est de acuerdo con el electrodomstico ofrecido, el vendedor genera el ticket de pedido. 6. El vendedor emite el ticket de pedido al cliente. 7. El cliente entrega el ticket de pedido al cajero 8. El cajero pregunta forma de pago Efectivo o tarjeta 9. Si el cliente responde efectivo ,entrega el dinero 10. El cajero genera el comprobante de pago. 11. El cajero emite el comprobante de pago al cliente. 12. El cliente entrega la copia del comprobante al vendedor. 13. El vendedor sella el comprobante y entrega el electrodomstico. 14. El cliente recibe el electrodomstico y finaliza el proceso. Flujos alternativos .En el punto 3, si no hay stock disponible, el vendedor le ofrece un electrodomstico sustituto al cliente y contina con el paso 4. 1. En el punto 5, si no est de acuerdo con el electrodomstico ofrecido, termina el proceso. 2. En el punto 9, el cliente puede pagar con tarjeta crdito o dbito: a. b. c. d. e. Si el cliente responde pago con tarjeta El cajero solicita la tarjeta al usuario. El cliente entrega tarjeta y DNI. El cajero pasa la tarjeta por el terminal POS. Si es con tarjeta de crdito: i. El terminal de POS genera el Boucher. ii. El Servicio de Banca actualiza la cuenta de la empresa. iii. El cajero entrega el Boucher para su firma. iv. El cliente firma el Boucher. f. Si es con tarjeta de dbito: i. El cliente ingresa su clave secreta en el terminal POS ii. El terminal de POS genera el Boucher. iii. El Servicio de Banca actualiza la cuenta del cliente. g. El cajero genera el CDP, entrega el CDP y el Boucher al cliente. h. El caso de uso contina en el paso 12.
CIBERTEC
54
CIBERTEC
55
5. Actores de negocio
CIBERTEC
56
CIBERTEC
57
11. descripcin de los elementos de un diagrama de actividades. Artefacto Descripcin Particin asignada para cada rol. Nodo inicial que indica el inicio del Diagrama de Actividades. Define una accin de la actividad. Es conveniente nombrar las actividades con verbos en tercera persona.
Este nodo representa un punto en una actividad donde un flujo de entrada se divide en varios flujos de salida. Este nodo representa un punto en una actividad donde varios flujos de entrada estn sincronizados en un nico flujo de salida. Control de decisin a partir del cual se especifica una pregunta que lleva a dos o ms flujos de acciones. Almacn de datos que representa la instancia de una clase persistente. Flujo de objeto utilizado para representar relaciones INPUT y/o OUTPUT entre una accin e instancia de entidad de negocio. Flujo de control utilizado para representar relaciones entre acciones. Conector de flujo entre acciones o acciones y almacn de datos. Nodo Final que indica finalizacin de una secuencia de actividades. Un Diagrama de Actividades puede tener ms de un tipo de fin.
CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS CIBERTEC
58
CIBERTEC
59
ACTIVIDADES PROPUESTAS
Desarrolle el siguiente caso propuesto
El principal proceso de la empresa se inicia cuando el cliente se acercan a la tienda a realizar las consultas sobre el precio de los autos y las cuotas a pagar que se ofrecen, el Cliente es atendido por un vendedor quien le brinda toda la informacin que necesita, si el cliente est de acuerdo y acepta las condiciones se genera un certificado de Pandero por el monto total del auto que desea comprar, el cliente debe pagar su cuota de inscripcin de $200. Esta cuota puede pagarse en el local con tarjeta de crdito o dbito.
Mensualmente se realiza el sorteo de los autos y lo inicia el Gerente General que le informa al asistente de sorteos que selecciona la lista de clientes al da en el pago de sus cuotas y sortee para obtener un ganador a quien se le entrega un auto. El cliente ganador debe pagar su cuota de Adjudicacin por $500 y la puede pagar en el local con tarjeta de crdito o dbito. Flujo de trabajo del proceso: Realizar Adjudicacin del Pandero
CIBERTEC
60
8. El jefe de sorteo verifica los datos del certificado 9. Si los datos son correctos el Jefe de sorteo le emite al cliente una Constancia de Adjudicacin y le informa que debe de pasar a caja a cancelar la cuota de Adjudicacin 10. El cliente se acerca a caja 11. El cajero le solicita la Constancia de Adjudicacin y el Certificado de Pandero 12. El cliente entrega la Constancia de Adjudicacin y Certificado de Pandero. 13. El cajero verifica la Constancia de Adjudicacin y el Certificado de Pandero 14. El cajero solicita el pago de la Cuota de Adjudicacin 15. El cliente paga la cuota de Adjudicacin 16. El cajero entrega el comprobante de pago y sella la Constancia Adjudicacin como cancelada 17. El cliente recoge su auto y se retira 1.1. Flujos Alternativos 1. En el punto 9, si los datos del ganador no son conformes 2. El jefe de sorteo saca nuevamente otro boleto y contina en el paso 7. de
CIBERTEC
61
Resumen
El Modelado del negocio es una tcnica para comprender los procesos de negocio de la organizacin objetivo. El Modelo de casos de Uso del Negocio es un modelo elaborado bajo una perspectiva externa del negocio. El Modelo de Anlisis del Negocio detalla cmo el proceso de negocio es implementado internamente. Si desea saber ms acerca de estos temas, puede consultar las siguientes pginas. http://www-128.ibm.com/developerworks/rational/library/5167.html Aqu hallar una descripcin de los elementos del modelado de negocio.
CIBERTEC
62
CIBERTEC
63
UNIDAD
3
DISCIPLINA DE LA CAPTURA DE REQUISITOS
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad, los alumnos, trabajando en equipo, elaborarn y sustentarn su proyecto final sobre el modelado del negocio y la captura de requisitos, en el que identifica el modelo de casos de uso del negocio, el modelo de anlisis del negocio, y el modelo de casos de uso con sus respectivos artefactos, aplicando la metodologa RUP, el lenguaje de modelado UML y la herramienta IBM Rational Software Architect.
TEMARIO
3.1 Tema 6 3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.1.5. 3.1.6. 3.1.7. 3.2 Tema 7 3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.3 Tema 8 3.3.1. 3,3,2. 3.3.3. 3.3.4. 3.3.5. : Captura de requisitos : Artefactos de la Captura de Requisitos Actividades para realizar la Captura de Requisitos : Requerimientos Requisitos FURPS Tcnicas para capturar requisitos : Captura de requisitos a solicitud del cliente : Captura de requisitos a partir del diagrama de actividades del negocio : Modelo de casos de uso. : Encontrar actores y casos de uso Encontrar actores : Encontrar casos de uso Crear el Diagrama de casos de uso : Estructurando el modelo de casos de uso. : Objetivos Tipos de relaciones Casos de uso abstractos y concretos : Especificaciones de casos de uso : Priorizacin de los Casos de Uso
ACTIVIDADES PROPUESTAS
Los alumnos clasificarn los requisitos de una lista propuesta segn las categoras descritas por el modelo FURPS+. Los alumnos identifican los requisitos funcionales a partir de un Diagrama de Actividades del Negocio Los alumnos identifican actores y casos de uso a partir de un caso propuesto.
CIBERTEC
64
CIBERTEC
65
La propuesta del curso, para una solucin de mediana envergadura, es crear los artefactos proporcionados en la tabla 3.1.
CIBERTEC
66
Artefacto
Descripcin
Documento que define la opinin de los stakeholders del producto que se desarrollar, especificada en trminos de necesidades y caractersticas claves de los stakeholders. Contiene un esquema de los requisitos previstos, el cual proporciona la base contractual para los requisitos tcnicos ms detallados. La Especificacin de Requisitos de Software es un documento que enfoca la organizacin completa de los requisitos del proyecto. Comnmente conocido como SRS por sus iniciales en ingls. Contiene la lista de requerimientos funcionales y no funcionales. Es una coleccin de casos de uso, de actores, de relaciones, de diagramas, y de otros paquetes de ser necesario; es utilizado para estructurar el modelo de casos de uso dividindolo en piezas ms pequeas. Es un proceso especfico del sistema con identidad propia, el cual define una secuencia de acciones que el sistema realiza para un actor en particular.
Vision
Use-Case Package
Use Case
Representa un rol (humano, hardware o software) externo al sistema con el que se establece intercambio directo de informacin. Puede ser asociado a uno o ms casos de uso.
Actor
Es un modelo que captura los requisitos funcionales de los usuarios a un alto nivel y establece la estructura fundamental del sistema. Es un input esencial para las actividades en anlisis, diseo y pruebas. Reporte que contiene informacin de identificados en el modelo de casos de uso. los actores
Actor
Use-Case Specification
Documento que contiene las caractersticas de un caso de uso. Contiene primordialmente una descripcin del flujo de eventos que describen la interaccin entre los actores y el sistema. La especificacin tambin contiene otra informacin tal como precondiciones, pos condiciones y requisitos especiales. Se realiza una especificacin por caso de uso.
CIBERTEC
67
3.1.2.1 Analizar el Problema El documento Visin es el principal artefacto en el cual el anlisis del problema es documentado. Para determinar el alcance inicial del proyecto, los lmites del sistema deben ser definidos. El analista de sistema identifica usuarios y sistemas, representado por actores, los cuales interactan con el sistema. En este caso, el analista crea el Modelo de Casos de Uso que contendr slo los actores.
CIBERTEC
68
3.1.2.2 Entender las Necesidades del Stakeholder El artefacto principal es un documento refinado de la Visin. Tambin los requisitos son discutidos y expresados en trminos de Casos de Uso y Actores. Los requisitos no funcionales, que no son representados en el Modelo de Casos de Uso debern ser documentados en Especificaciones Suplementarias. El analista se relaciona con los stakeholders utilizando tcnicas para capturar requisitos, tales como las entrevistas si se encuentra en las primeras iteraciones de esta disciplina y prototipos si se encuentra en las ltimas iteraciones. Los stakeholders son un grupo de inters cuyas necesidades deben ser satisfechas por el proyecto. El papel puede ser desempeado por cualquier persona que es (o ser potencialmente) afectado por los resultados del proyecto. Por lo tanto, son fuentes de requisitos. Por ejemplo: usuarios finales del sistema, gerentes, accionistas, reguladores quines certifican la aceptabilidad del sistema. 3.1.2.3 Definir el Sistema En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso completamente para obtener un Modelo de Casos de Uso refinado y expandir los requisitos no funcionales definidos en los documentos de especificaciones suplementarias. 3.1.2.4 Administrar el Alcance del Sistema El alcance del proyecto es definido por el conjunto de requisitos definidos para ste. La clave para manejar un proyecto exitoso es administrar el alcance del proyecto cumpliendo con los recursos disponibles tales como el tiempo, la gente y el dinero. La priorizacin los casos de uso, desarrollado por el arquitecto de software, permite planificar el proyecto. 3.1.2.5 Refinar la Definicin del Sistema El output de este Workflow del RUP es una comprensin ms profunda de la funcionalidad del sistema expresada en Casos de Uso detallados y documentos de Especificaciones Suplementarias detallados. Si es necesario, una Especificacin de Requisitos de Software formal puede ser desarrollada, adems de los documentos detallados de Casos de Uso y Especificaciones Suplementarias. 3.1.2.6 Administrar los Cambios de Requisitos Los cambios a los requisitos impactan los modelos producidos en el Workflow de Anlisis y Diseo, el modelo de pruebas creado en el Workflow de Pruebas y el material de soporte al usuario final del Workflow de Despliegue. Las relaciones de trazabilidad son establecidas para identificar las relaciones entre los requisitos y otros artefactos. Las relaciones de trazabilidad son la clave para entender el impacto del cambio de los requisitos.
3.1.3. Requerimientos
Un requerimiento se define como una condicin o capacidad a la que debe ajustarse el sistema que se construye para satisfacer un contrato, norma, especificacin u otro documento formalmente impuesto.
CIBERTEC
69
El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniera de requisitos. La meta de la ingeniera de requisitos (IR) es entregar una especificacin de requisitos de software correcta y completa. Algunos otros conceptos de ingeniera de requisitos son: Segn Pressman Ingeniera de Requisitos ayuda a los ingenieros de software a entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas que conducen a comprender cul ser el impacto del software sobre el negocio, qu es lo que el cliente quiere y cmo interactuarn los usuarios finales con el software. Por otro lado, Somerville define que La ingeniera de requisitos es el proceso de desarrollar una especificacin de software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. En sntesis, el proceso de ingeniera de requisitos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requisitos para un producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendr a ayudar a determinar la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtencin y anlisis de requisitos, su especificacin formal, para finalizar con el subproceso de validacin donde se verifica que los requisitos realmente definen el sistema que quiere el cliente.
70
El smbolo "+" en FURPS+ hace referencia a que se deben incluir otros requisitos, tales como:
3.1.4.1 Funcionales Los requisitos funcionales deben incluir: Conjunto de caractersticas Capacidades Seguridad Por ejemplo, para un Sistema de Ventas: R1: Mostrar descripcin y precio de productos. R2: Registrar venta de productos. R3: Reducir stock cuando se realiza la venta. R4: Identificar al cajero utilizando un usuario y una clave. 3.1.4.2 Facilidad de Uso Deben incluir subcategoras tales como: Factores Humanos Estticos Consistencia de Interfaz de Usuario Ayuda en lnea o context-sensitive Asistentes (wizards) Documentacin de Usuario Materiales de Capacitacin/Entrenamiento Por ejemplo: R1: El sistema deber proporcionar ayudas en lnea para orientar en el uso de las interfaces. R2: Maximizar eficiencia mediante la navegacin con teclado. R3: El sistema debe tener interfaces grficas de administracin y de operacin en idioma espaol y en ambiente 100% Web, para permitir su utilizacin a travs de navegadores de Internet 3.1.4.3 Confiabilidad Frecuencia de fallos Capacidad de recuperacin a fallos Posibilidades de prediccin del programa Precisin Tiempo medio de fallos
Por ejemplo:
CIBERTEC
71
R1: El sistema debe registrar los pagos a crdito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. R2: La cuenta del usuario se bloquear por un lapso de 30 minutos luego de 4 intentos fallidos para evitar vulnerabilidades en la seguridad del sistema. 3.1.4.4 Rendimiento Condiciones impuestas a requisitos funcionales y son tales como: Velocidad Eficiencia Disponibilidad Tiempo de Respuesta Tiempo de Recuperacin Uso de recursos Por ejemplo: R1: El tiempo mximo para mostrar el reporte de cuentas por cobrar mediante un histograma es de 20 segundos. R2: El sistema debe estar disponible al 100% o muy cercano a esta disponibilidad durante el horario hbil laboral de la empresa a nivel nacional, es decir, de lunes a viernes de 8:00 a.m. a 5:00 p.m., con excepcin de los das festivos. 3.1.4.5 Soporte Es la capacidad que tiene el software de ser modificado fcilmente para adecuar mejoras o cambios. Incluye: Adaptabilidad Facilidad de mantenimiento Compatibilidad Configurabilidad Facilidad de instalacin Internacionalizacin Por ejemplo: R1: El sistema debe operar de manera independiente del navegador que se utilice (Microsoft Internet Explorer 6.0 o superior, Netscape 6.0 o superior, Mozilla FireFox). R2: El sistema deber estar orientado a que las actualizaciones slo se hagan en el sitio del servidor. 3.1.4.6 Restricciones de Diseo Tambin llamados restricciones de diseo, especifican o restringen el diseo de un sistema. Por ejemplo: R1: El sistema deber considerar en su arquitectura un modelo tres capas, donde se definen tres componentes lgicos de manera independiente: servicios de presentacin o interfaz de usuario, servicios de funcionalidad y servicios de datos. 3.1.4.7 Requisitos de implementacin Especifica restricciones de codificacin o de construccin del sistema:
CIBERTEC
72
Estndares requeridos Lenguajes de implementacin Polticas para la integridad de Bases de Datos Lmite de recursos Ambientes de Operacin
Por ejemplo: R1: El sistema debe desarrollarse con el lenguaje JAVA V1.6. 3.1.4.8 Requisitos de interfaz Especifica: Elemento externo con el que el sistema debe interactuar Restricciones o formatos, tiempos u otros factores usados en tales interacciones Por ejemplo: R1: El sistema deber proporcionar, para los diferentes reportes solicitados, salidas en documentos electrnicos (Word, Excel o Acrobat Reader). R2: En una visin preliminar de impresin se considerara que todos los textos estarn relacionados con un visor de PDF, las estadsticas y resultados de consultas estarn relacionados con Excel 2003. 3.1.4.9 Requisitos fsicos Especifican caractersticas fsicas que el sistema debe poseer. Por ejemplo: material, forma, tamao y peso. Pueden especificarse los requisitos de hardware. Por ejemplo: R1: Para que un cliente de la aplicacin pueda ejecutar procesos, en lnea, considerados en el sistema el punto de acceso deber cumplir con los siguientes requisitos mnimos. o Procesador 1.0 GHz. o Memoria 128 MB. o Disco duro 10 GB. o Sistema Operativo Windows XP o Linux. o Navegador internet Explorer 6.0 o posterior, Mozilla Firefox 2.X, Netscape Navigator 6.X o posterior con plugins para Macromedia Flash y Java. o Conexin a Internet. mnimo 56Kbps
CIBERTEC
73
El xito de esta tcnica, depende de la habilidad del entrevistador para crear un clima de confianza y de su preparacin para la misma. Despus de la entrevista, se debe analizar la informacin obtenida y construir algunos requisitos candidatos. Los puntos esenciales de esta tcnica se anotan a continuacin: Dos entrevistadores: Conviene que dos personas realicen la entrevista para mejorar la gestin del tiempo, pues uno conduce la entrevista y el otro supervisa la interaccin y toma notas. Formule tanto preguntas abiertas como cerradas: Las preguntas abiertas no presuponen ninguna respuesta particular y animan al entrevistado a hablar sobre el problema, mientras que las preguntas cerradas presentan un intervalo especfico de respuesta. Ejemplos: Pregunta abierta: Quin utiliza el sistema? Pregunta cerrada: Utiliza usted el sistema? No invente una solucin, pues puede pensar que tiene una muy buena idea de lo que necesitan los grupos de decisin, pero debe mantener esta preconcepcin a un lado durante la entrevista. sta es la nica forma de averiguar lo que realmente necesita. Escuche: sta es la nica forma en la que averiguar qu quieren los grupos de decisin, por lo tanto djeles tiempo para hablar. Permtales hablar sobre una pregunta y que la exploren de su propia forma. Si busca respuestas especficas, es posible que invente una solucin y formule preguntas cerradas basndose en esa invencin. No adivine los pensamientos: sta es una habilidad humana muy importante ya que es la base de la empata. Sin embargo, no es recomendable cuando trata de obtener requisitos, pues puede acabar especificando lo que usted necesita en lugar de con lo que necesitan los grupos de decisin. 3.1.5.2 Cuestionarios Los cuestionarios pueden ser un suplemento de utilidad para las entrevistas. Son excelentes para conseguir respuestas a preguntas cerradas. Puede descubrir preguntas claves a partir de las entrevistas e incorporar stas en un cuestionario que puede distribuir a una audiencia ms amplia. Esto le puede ayudar a validar su entendimiento de los requisitos. Por el tipo de preguntas que contiene, existen dos tipos de cuestionarios: abiertos y cerrados. Abiertos: No presuponen ninguna respuesta particular y animan al entrevistado a hablar sobre el problema para obtener opiniones y/o referencias. Cerrados: Limitan las respuestas posibles a travs de un estilo cuidadoso en la pregunta. Los tipos de respuestas de un cuestionario cerrado podran ser los siguientes: SI/NO Cree que se cometen muchos errores en la codificacin de los nmeros de cuenta en las facturas? SI NO DE ACUERDO/EN DESACUERDO Se cometen muchos errores al codificar os nmeros de cuenta en las facturas?
CIBERTEC
74
DE ACUERDO EN DESACUERDO ESCALAS Se cometen muchos errores al codificar los nmeros de cuenta en las facturas? TOTALMENTE DE ACUERDO DE ACUERDO NO ESTOY SEGURO EN DESACUERDO TOTALMENTE EN DESACUERDO NMERO De cada 100 facturas que se procesan cuntas tienen errores? Anote el nmero: ____________ RANGO De cada 100 facturas que se procesan cuntas tienen errores? 0-5 6 - 10 11 - 15 16 - 20 21 - 25 26 - 30 31 - 40 41 - 50 Ms de 50
SELECCIN DE RESPUESTAS LIMITADAS Cuando se presentan errores en la codificacin de los nmeros de cuenta en las facturas, cul es la causa ms frecuente? (Anote el nmero de la respuesta apropiada. Tambin la segunda razn ms comn y la menos comn). 1.... 2.... Los buenos cuestionarios se deben disear previamente. Un pensamiento cuidadoso, acompaado de una prueba previa, tanto del formato como de las preguntas, son la base de una recopilacin de datos significativa a travs de cuestionarios. Pautas que le ayudarn a confeccionar un buen cuestionario: 1. Determine qu datos necesitan recopilarse y qu personas son las ms calificadas para proporcionarlos. Si otros grupos pueden proporcionar datos variantes y mayor visin identifquelos tambin. 2. Seleccione el tipo de cuestionario (abierto o cerrado). Reconozca cules pueden ser ms tiles, si contienen una seccin de respuestas cerradas y otras de respuestas abiertas.
CIBERTEC
75
3. Desarrolle un Grupo de preguntas para incluirlas en el cuestionario. Las preguntas extras que son intencionalmente redundantes, pueden ser tiles al asegurar respuestas consistentes por parte de quien responda. 4. Examine el cuestionario para encontrarle fallas y defectos como: a. Interrogantes innecesarias. b. Preguntas que puedan ser mal interpretadas debido a su enfoque o forma de escritura. c. Preguntas que el sujeto no pueda responder. d. Preguntas que estn escritas de forma que se escoger la respuesta preferida. e. Preguntas que se interpretaran en forma diferente dependiendo del marco de referencia de cada entrevistado. f. Preguntas que no proporcionan opciones adecuadas de respuesta. g. Un ordenamiento no adecuado de las preguntas y respuestas. 5. Prubelo previamente en un Grupo pequeo para detectar otros problemas posibles. 6. Analice la respuesta del Grupo de prueba para asegurar que el anlisis de los datos que se busca se puede llevar a cabo con los datos recopilados. Si los datos no revelan algo que el analista no conoce, el cuestionario puede no ser necesario. 7. Realice cambios finales de edicin e imprmalo en una forma legible. 8. Distribuya el cuestionario. Cuando sea posible anote el nombre de cada persona. 3.1.5.3 Lluvia de ideas (Brainstorm) Este es un modelo que se usa para generar ideas. La intencin en su aplicacin es la de generar la mxima cantidad posible de requisitos 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. Las reglas bsicas a seguir son: Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae como consecuencia la obtencin de una cantidad mayor de ideas creativas. Conviene suspender el juicio crtico y se debe permitir la evolucin de cada una de las ideas, porque si no 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. 3.1.5.4 Prototipos Durante la actividad de extraccin de requisitos, puede ocurrir que algunos requisitos no estn demasiado claros o que no se est muy seguro de haber entendido
CIBERTEC
76
correctamente los requisitos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final. Entonces, para validar los requisitos 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 sobre la base de los requisitos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva. El desarrollo del prototipo comienza con la captura de requisitos. Desarrolladores y clientes se renen y definen los objetivos globales del software, identifican todos los requisitos que son conocidos, y sealan reas en las que ser necesaria la profundizacin en las definiciones. Luego de esto, tiene lugar un diseo rpido. El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseo rpido lleva a la construccin de un prototipo.
Descubrimiento de requisitos
Documentacin de requisitos
Obtener y comprender los requisitos de los stakeholders es difcil por varias razones: Los stakeholders a menudo no conocen lo que desean obtener del sistema informtico excepto en trminos muy generales; puede resultarles difcil
CIBERTEC
77
expresar lo que quieren que haga el sistema o pueden hacer demandas irreales debido a que no conocen el coste de sus peticiones. Los stakeholders expresan los requisitos distintos con sus propios trminos de forma natural y con un conocimiento implcito de su trabajo. Diferentes requisitos de diferentes stakeholders tienen concordancia y algunos generan conflictos.
En la figura 3.3 se muestra un modelo general para obtener y analizar requisitos. Con cada vuelta del ciclo de este modelo la comprensin de los requisitos por parte del analista mejorar. Cada equipo de desarrollo tendr su propia versin o instancia de este modelo, dependiendo de la habilidad del personal, el tipo de sistema a desarrollar y los estndares utilizados. Los pasos a seguir son: 1. Descubrimiento de requisitos. Es el proceso de interactuar con los stakeholders del sistema para recopilar sus requisitos. Para ello, se utilizan tcnicas de captura de requisitos como las entrevistas y prototipos. 2. Clasificacin y organizacin de requisitos. En esta actividad, el analista toma la recopilacin no estructurada de requisitos, grupos relacionados de requisitos y los organiza en grupos coherentes. 3. Ordenacin por prioridades y negociacin de requisitos. Inevitablemente, cuando existen muchos stakeholders involucrados, los requisitos entrarn en conflicto. Esta actividad se refiere a ordenar segn las prioridades de requisitos, y a encontrar y resolver los requisitos en conflicto a travs de la negociacin. 4. Documentacin de requisitos. Se documentan los requisitos y se contina en la siguiente vuelta de la espiral. Se pueden producir documentos de requisitos formales o informales como por ejemplo: Modelo de casos de uso para requisitos funcionales y Especificacin de Requisitos de Software que contiene todos los tipos de requisitos (funcionales y no funcionales) del sistema.
CIBERTEC
78
Es importante documentar el seguimiento de estos elementos: actividades a informatizar, requisitos funcionales y casos de uso. Ms an, si se trata de seguir requisitos funcionales de casos de uso, el cual es un proceso complicado por el hecho de que existe una relacin muchos a muchos entre ellos. Un caso de uso puede tratar muchos requisitos funcionales y un requerimiento funcional puede estar presente en varios casos de uso diferentes. Afortunadamente, existen herramientas de ingeniera de requisitos como el Requisite Pro y DOORS. Pero si no tiene ningn soporte de herramienta de modelado, tiene que hacer el trabajo manualmente. Un buen enfoque es crear una matriz denominada Matriz de Actividades y Requisitos. Estas matrices se crean a menudo en hojas de clculo. La plantilla se proporciona en la Tabla 3.2.
Una Matriz de Actividades y Requisitos es una herramienta manual utilizada para obtener requisitos funcionales a partir de actividades del negocio que se van a informatizar. Una vez identificado los requisitos funcionales, se crean los casos de uso. Por otro lado, los actores son creados a partir de los responsables de las actividades del negocio que se tienen en la matriz.
Resaltar las siguientes acciones o o o o o Verificar existencia de producto Generar Ticket Emitir ticket Generar CDP Entregar producto
CIBERTEC
79
CIBERTEC
80
CIBERTEC
Requerimiento
Verificar si existe el producto Generar de ticket imprimir ticket Generar Cdp Descargar stock
Caso de Uso
buscar producto Generar Ticket generar CDP
Actores
Vendedor Vendedor Cajero
Iteracin # o Prioridad
Realizar venta
82
Este Diagrama de Casos de Uso debe ser refinado. Nuevos casos de uso sern detectados al describir cada caso de uso obtenido; para ello, se utiliza el documento Especificacin de Caso de Uso (Ver tema: Desarrollo de Especificaciones de Casos de Uso). Por ltimo, los nuevos casos de uso sern agregados en un diagrama denominado Diagrama Estructurado de Casos de Uso, consiguiendo de esta manera, la versin final del Modelo de Casos de Uso (Ver tema: Estructurando el Modelo de Casos de Uso).
CARRERAS PROFESIONALES
CIBERTEC
83
ACTIVIDADES PROPUESTAS
1. De la lista, clasifique los requisitos segn las categoras de FURPS+. R01. El sistema deber garantizar que su despliegue se pueda realizar, ya sea en el lado del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bits sin que esto afecte el rendimiento del mismo. R02. El sistema debe contar con un Manual Tcnico de Referencia para la Aplicacin, el cual estar orientado a profesionales capacitados en aspectos tcnicos del rea de sistemas. R03. La clave de los usuarios considerar las siguientes polticas: - Expirar segn parametrizacin del sistema - Tener mnimo una longitud de 8 caracteres - Contener letras y nmeros - No puede contener espacios - No pueden repetirse las 3 ltimas contraseas - No contendr el nombre o apellido de la persona duea del usuario R04. El cdigo fuente del sistema deber cumplir con el estndar de codificacin definido en el documento Estndares y Nomenclaturas de Cdigo Fuente. R05. Utilizar el idioma castellano para los mensajes y textos en la Interfaz. R06. El sistema ser utilizado por clientes de todo el mundo. Adicionalmente, la Organizacin Pro-Turismo exige que para anunciar servicios en su portal, stos deben estar provistos en espaol, ingls y portugus. Estos tres idiomas deben ser soportados por el producto desarrollado. R07. El sistema deber permitir la creacin, modificacin, activacin, desactivacin y autorizacin de los roles de usuarios definidos. R08. El sistema deber prever contingencias que pueden afectar la prestacin estable y permanente del servicio. La siguiente es la lista de las contingencias que se deben tener en cuenta y se pueden considerar crticas: Sobrecarga del sistema por volumen de usuarios. Cada del sistema por sobrecarga de procesos. Cada del sistema por sobrecarga de transacciones. Cada del sistema por volumen de datos excedido en la base de datos. R09. El sistema deber contar con el manual de FAQ (Frequent Asked Questions), en lnea e impreso, que es un resumen con las respuestas a las preguntas ms frecuentes que se hacen los usuarios. R10. El sistema debe considerar en su arquitectura, el patrn de diseo MVC.
CIBERTEC
CARRERAS PROFESIONALES
84
Estos pasos no tienen por qu ser ejecutados en ningn orden en particular y a menudo se hacen simultneamente. De hecho, podemos trabajar por mltiples vas que producen un resultado final equivalente. Podemos, por ejemplo, comenzar encontrando algunos casos de uso (la actividad de Encontrar Actores y Casos de Uso), despus disear las interfaces de usuario (la actividad de Crear Prototipo de Interfaz de Usuario), para darnos cuenta de que necesitamos aadir un nuevo caso de uso (as que retrocederemos a la actividad de Encontrar Actores y Casos de Uso, rompiendo la secuencia estricta marcada), y as sucesivamente. Los resultados de la primera iteracin a travs de este flujo de trabajo consisten en una primera versin del modelo de casos de uso. Los resultados de cualquier iteracin subsiguiente consistirn entonces en nuevas versiones de artefactos involucrados en la creacin del modelo de casos de uso. Hay que recordar que todos los artefactos se contemplan y mejoran incrementalmente a travs de iteraciones. Las distintas actividades en el modelado de caso de uso adoptan formas diferentes en diferentes fases del proyecto. Por ejemplo, cuando un analista ejecuta la actividad de Encontrar Actores y casos de Uso durante la fase de inicio, identificar muchos actores y casos de uso nuevos. Pero cuando la actividad se realiza durante la fase de construccin, el analista har cambios secundarios en la lista de actores y casos de uso, tales como la creacin de un diagrama de casos de uso que describe mejor el modelo de casos de uso desde una perspectiva en particular.
CARRERAS PROFESIONALES
CIBERTEC
85
Tambin podemos encontrar que el mismo usuario puede ser representado por varios actores, esto es porque la misma persona puede desempear roles diferentes. Por
CIBERTEC
CARRERAS PROFESIONALES
86
ejemplo, la figura 3.5 muestra que un usuario desempea dos roles: Jefe de Almacn y Personal de almacn.
3.2.2.2 Cmo identificar actores Para identificar actores debe responder las siguientes preguntas:
Qu actores del negocio o trabajadores del negocio son responsables de las actividades a informatizar? Qu grupos de usuarios necesitan ayuda del sistema para llevar a cabo sus tareas? Qu grupos de usuarios son fundamentales para ejecutar las funciones principales del sistema? Qu grupos de usuarios son los que llevarn a cabo funciones secundarias como mantenimiento o administracin? El sistema a desarrollar interactuar con algn hardware o sistema de software?
Cualquier individuo, grupo o fenmeno que cumpla con una o ms de estas categoras es candidato para ser un actor. La figura 3.6 muestra el entorno del sistema del cual se encontrarn categoras de actores.
Para determinar si se tienen los actores correctos, se puede elegir dos o tres personas que usarn el sistema y, a continuacin, ver si el conjunto de actores obtenido es suficiente para cubrir sus necesidades.
CARRERAS PROFESIONALES
CIBERTEC
87
Por ltimo, se completa la identificacin de actores al obtener todos los casos de uso del sistema que conlleva a crear otros actores o eliminar a algunos que existen. Este proceso de refinamiento se ver en el prximo captulo Estructurando el Modelo de Casos de Uso. 3.2.2.3 Definicin de las fronteras del sistema Encontrar a los actores significa tambin definir las fronteras del sistema, que ayuda a comprender el propsito y el alcance del sistema. Slo aquellos que se comunican directamente con el sistema son actores. Por ejemplo: En un sistema de reservas de lneas areas, quines podran ser actores? Esto depende del tipo de sistema que se construye. Si est desarrollando el sistema de reservaciones, para un agente de viajes, el actor ser el agente de viaje. El pasajero no interacta con el sistema directamente, entonces no ser un actor.
En cambio, si est desarrollando un sistema de reservaciones, para que los pasajeros se puedan conectar a travs de Internet, el pasajero ahora s interactuar con el sistema y se convertir en actor.
3.2.2.4 Tiempo como actor Aunque claramente el tiempo es una entidad externa al sistema (por lo que cumple con la primera mitad de la definicin de un actor) difcilmente podremos pensar que el tiempo se encuentra interesado en una funcionalidad de nuestro sistema. En este caso, es el sistema quien va a tener inters en el tiempo, debido a que deben efectuar operaciones automticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de inters desarrollar alguna forma de capturar dicho requisito en el modelo de casos de uso. La tcnica es introducir al actor Tiempo, quien est asociado a casos de uso que capturan una funcionalidad automtica. Un ejemplo de esto sera un respaldo automtico del sistema que se ejecuta todas las noches o la generacin automtica de reporte de ventas diario, tal como se ilustra en la siguiente figura.
CIBERTEC
CARRERAS PROFESIONALES
88
3.2.2.5 Sugerencias para identificar adecuadamente a los actores del sistema Son roles (humanos, software o hardware), no personas con nombres propios. No siempre est asociado con el nombre de un cargo en la planilla de la organizacin objetivo. El nombre no debe representar reas, departamentos o partes de una organizacin sino roles de ejecucin. Cada actor debe estar asociado con al menos un caso de uso del sistema. Si no participa en ningn proceso debe ser eliminado del modelo.
3.2.2.6 Breve Descripcin de actores La breve descripcin del actor debe incluir informacin sobre: A qu o a quin representa el actor? Por qu el actor es necesario? Qu intereses tiene el actor en el sistema?
La breve descripcin debe ser realizada en pocas lneas tanto en el Modelo de Casos de Uso como en el documento Actores del Sistema. Por ejemplo, para una mquina de reciclado, los actores Cliente, Operador y Administrador pueden ser descritos de la siguiente manera: Cliente: El cliente recoge botellas, latas y cajas en casa y los trae a la tienda para obtener a cambio un reembolso. Operador: El operador es el responsable del mantenimiento de la mquina de reciclado. Administrador: El administrador es responsable de las cuestiones sobre el dinero y el servicio que la tienda ofrece a los clientes.
CARRERAS PROFESIONALES
CIBERTEC
89
llegar a una versin final. Usted recibir una mejor comprensin de los casos de uso una vez que se han descrito en detalle. 3.2.3.1 Caso de Uso Un caso de uso es un fragmento de funcionalidad que el sistema ofrece para aportar un resultado de valor para los actores. De manera ms precisa, un caso de uso especifica una secuencia de acciones que el sistema ejecuta interactuando con sus actores e incluyendo alternativas dentro de la secuencia. Las acciones pueden involucrar la comunicacin con un determinado nmero de actores as como tambin realizar clculos y trabajos dentro del sistema. Las caractersticas de un caso de uso son:
Siempre es iniciado por un actor. El actor, directa o indirectamente, ordena al sistema que se ejecute el caso de uso. Provee valor para un actor, es decir, un caso de uso debe entregar algn tipo de valor tangible para el actor. Es completo. Un caso de uso no est completo hasta que el valor final se produzca.
3.2.3.2 Cmo identificar casos de uso La mejor manera de encontrar casos de uso es considerar lo que cada actor requiere del sistema. Recuerde que el sistema existe slo para sus usuarios, y por lo tanto debe partir de las necesidades de los usuarios. Si cuenta con un Modelo de Negocio, los diagramas de actividades del Modelo de Anlisis de Negocio sern utilizados para empezar a identificar casos de uso (como se ha descrito en el punto 4 de la semana 8). Las respuestas a las siguientes preguntas ayudarn a encontrar casos de uso:
Cules son las actividades del negocio objetos de automatizacin? Cules son las tareas que el actor desea que el sistema desarrolle? El actor crea, almacena, cambia, elimina o consulta datos en el sistema? El actor necesita informar al sistema cambios generados en el entorno circundante al sistema? El actor necesita ser informado sobre la ocurrencia de situaciones externas al sistema?
Son procesos o funcionalidades del sistema, que en la mayora de los casos corresponden con opciones de ejecucin. Deben estar asociados a por lo menos un actor del sistema u otro caso de uso del sistema. Representan la generalidad del comportamiento del proceso y no una instancia o escenario especfico o caso muy particular del sistema.
3.2.3.4 Breve Descripcin de casos de uso La breve descripcin del caso de uso debe reflejar su propsito, resumiendo las acciones que ejecuta el caso de uso al interactuar con los actores. Esta descripcin se realiza, en primer lugar con algunas frases en el Modelo de Casos de Uso y ms
CIBERTEC
CARRERAS PROFESIONALES
90
adelante, con una descripcin paso a paso de lo que el sistema necesita hacer cuando interacta con sus actores, en la Especificacin de Caso de Uso. Siguiendo con el ejemplo de la mquina de reciclado, los casos de uso Reciclar artculos y Agregar nuevo tipo de botella pueden describirse de la siguiente manera: Reciclar artculos: El usuario utiliza esta mquina de reciclado para obtener automticamente un recibo que indica el monto calculado por el nmero de artculos (botellas, latas y cajas) reciclados. El recibo es cobrado en una caja registradora (mquina). Agregar un nuevo tipo de botella: Nuevos tipos de botellas se pueden agregar a la mquina iniciando en "modo de aprendizaje y la insercin de 5 muestra. De esta manera, la mquina puede medir las botellas y aprender a identificarlos. El administrador especifica el valor de reembolso para el nuevo tipo de botella.
CARRERAS PROFESIONALES
CIBERTEC
91
En segundo lugar, Qu es lo que ha solicitado el cliente que nos ha contratado? Ha solicitado que el registro de los pedidos sea va web y que sean registrados por sus clientes afiliados. Asimismo, si sus clientes afiliados lo requieren, deberan actualizar sus datos va web. Por consiguiente, tendramos ms requisitos: Registrar afiliacin para el cliente no afiliado Actualizar datos de afiliacin para el cliente afiliado Consultar pedidos para el vendedor
Por otro lado, debemos tomar en cuenta otros requisitos que sern necesarios para controlar el proceso. Por ejemplo: Actualizar estado de pedido a CANCELADO cuando el cliente pague su pedido.
El resultado de este anlisis se documenta en la Matriz de Actividades Vs. Requisitos, tal como se muestra a continuacin:
CIBERTEC
CARRERAS PROFESIONALES
92
Proceso de Negocio
Requisito R01
Actores
Venta de Electrodomsticos
CUS03
Explicacin: A partir de los requisitos se crean los casos de uso. Puede existir el caso en que ms de un requisito se implemente en un caso de uso, como por ejemplo el caso de uso de sistema CUS03 contiene dos requisitos. En la columna de actores se indican los roles que interactuarn con los casos de uso identificados. Como nuestro cliente ha solicitado implementar una solucin web para el registro de pedidos, el rol Cliente afiliado ser quien realice esa funcionalidad y no el Vendedor.
CARRERAS PROFESIONALES
CIBERTEC
93
CARRERAS PROFESIONALES
CIBERTEC
94
MODELO DE
Esta actividad se centra en relacionar los casos de uso y los actores del sistema, e identificar sus comportamientos opcionales y excepcionales. Se establece las inclusiones, extensiones y generalizaciones entre casos de uso, y las generalizaciones entre actores. Existen tres razones para estructurar el modelo de casos de uso: Hacer que los casos de uso sean fciles de entender. Extraer el comportamiento comn encontrado en varios casos de uso. Hacer que el modelo de casos de uso sea fcil de mantener. La ejecucin de cada caso de uso incluye la comunicacin con uno o ms actores. Una instancia de un caso de uso siempre es iniciada por un actor pidiendo al sistema hacer algo. Esto implica que cada caso de uso debe tener la asociacin de comunicacin con los actores. La razn de esta norma es hacer cumplir el sistema para ofrecer slo la funcionalidad que los usuarios necesitan, y nada ms. Si se encuentran casos de uso que nadie pide significa que algo est mal en el modelo de caso de uso o en los requisitos. Sin embargo, hay algunas excepciones a esta regla: Si un caso de uso es abstracto (no se instancia por separado, sino en el contexto de otro caso de uso), su comportamiento no puede incluir la interaccin con algn actor. En ese caso, el caso de uso abstracto no tendr ninguna asociacin de comunicacin con actores. Un caso de uso hijo en una relacin de generalizacin no necesita tener un actor asociado a l si el caso de uso padre describe la comunicacin con el actor. Un caso de uso base en una relacin include no necesita tener un actor asociado a l si el caso de uso incluido describe la comunicacin con el actor. Un caso de uso puede ser iniciado de acuerdo con un horario (por ejemplo, una vez a la semana o una vez al da), lo que significa que el reloj del sistema es el iniciador. El reloj del sistema es interno al sistema y el caso de uso no es iniciado por un actor, sino por un evento interno del sistema. Si ninguna interaccin de actor se produce en el caso de uso, ste no tendr ninguna asociacin con un actor. Sin embargo, se puede utilizar un actor ficticio "tiempo" para mostrar cmo el caso de uso es iniciado en el diagrama de casos de uso.
3.3.1 Objetivos
Los objetivos de esta actividad son: Extraer descripciones de funcionalidad (de casos de uso) generales y compartidas que pueden ser utilizadas por casos de uso ms especficos (generalizacin). Extraer descripciones de funcionalidad (de casos de uso) adicionales u opcionales que pueden extender casos de uso ms especficos (relaciones de extensin). Extraer descripciones de funcionalidad (de casos de uso) adicionales e incondicionales incluidas en la ejecucin de casos de uso especficos (relaciones de inclusin)
CARRERAS PROFESIONALES
CIBERTEC
95
Para entender la ejecucin de un caso de uso incluido analice la siguiente figura. Puede observar que el comportamiento del caso de uso incluido se inserta en un punto del caso de uso base. Cuando una instancia de caso de uso, el cual sigue la descripcin de un caso de uso base, llega a un punto en donde la relacin include es definida, seguir la descripcin del caso de uso incluido. Una vez que la inclusin se lleva a cabo, la instancia del caso de uso regresar al caso de uso base, en el punto donde se detuvo.
CIBERTEC
CARRERAS PROFESIONALES
96
3.3.2.2 Relacin extend Una relacin extend se define como la agregacin de pasos a la secuencia del caso de uso original, que pasar a conocerse como caso de uso base. Esta extensin se realiza en puntos indicados, llamados puntos de extensin, de manera especfica dentro de la secuencia del caso de uso base. El caso de uso puede estar aislado pero, en algunas condiciones, su comportamiento puede extenderse con el comportamiento de otro caso de uso. Esta relacin se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. De esta forma, se separa el comportamiento opcional del obligatorio. Su representacin grfica es la siguiente:
La siguiente figura ilustra la ejecucin de un caso extendido. Note que cuando una instancia del caso de uso base, llega a un lugar en donde un punto de extensin se ha definido, la condicin en la correspondiente relacin extend es evaluada. Si la condicin es verdadera, la instancia del caso de uso seguir la extensin; de lo contrario, la extensin no se ejecuta. Una vez que la instancia de caso de uso ha realizado la extensin, la instancia de caso de uso reanuda su ejecucin al caso de uso base, en el punto donde se detuvo.
CARRERAS PROFESIONALES
CIBERTEC
97
3.3.2.3 Relacin de generalizacin La generalizacin entre casos de uso es como la generalizacin entre clases. En este caso significa que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre; el hijo puede aadir o redefinir el comportamiento del padre. La relacin de generalizacin puede representarse tambin entre actores. Su representacin grfica es la siguiente:
Una instancia de caso de uso ejecutada por el caso de uso hijo seguir el flujo de eventos descritos por el caso de uso padre, insertando comportamiento adicional y modificando el comportamiento, tal como se define en el flujo de eventos del caso de uso hijo.
CIBERTEC
CARRERAS PROFESIONALES
98
La siguiente figura ilustra ejemplos de casos de uso abstractos y concretos en un Diagrama de casos de uso estructurado. Es conveniente escribir con letra cursiva el nombre del caso de uso abstracto.
CARRERAS PROFESIONALES
CIBERTEC
99
ACTIVIDADES PROPUESTAS
Elabore el Diagrama de Casos de Uso Estructurado del siguiente caso.
COLABORA- PERU
Colabora Per es una compaa dedicada a la prestacin de servicios de atencin de las relaciones entre las empresas y sus clientes a travs de Centros de Contacto Telefnico o plataformas multicanal (IVR, SMS) para brindar diferentes servicios (Tele marketing, Tele cobranza, Fidelizacin, Gestin de Datos, etc.) para aquellas empresas o instituciones que gestionan grandes carteras de clientes o demandan una fluida relacin con sus usuarios. El principal proceso de la compaa se inicia cuando una empresa se pone en contacto con nuestra compaa Colabora Per, es atendido por un vendedor quien registra un presupuesto previamente se verifica si la empresa ya se encuentra registrado, de no encontrarse deber de registrarla como nueva empresa. Posteriormente cuando el vendedor gestiona la obtencin del contrato el Jefe de Marketing registrara un contrato, previamente se obtuvo los costos del presupuesto, detallara las especificaciones del contrato y entregara una copia a la empresa contratante y al Gerente de Ventas El Gerente de Ventas enva una copia del contrato al jefe de Operaciones para iniciar la atencin del contrato, el jefe de Operaciones llama a la empresa contratante para que nos entrega la lista de deudores a llamar por telfono, Con la informacin se registra un control de trabajo, donde se importa la data de deudores entregada, esta informacin se carga quedando en un estado sin gestionar, previamente busco a la empresa para asignar los deudores Luego las tele operadoras de tele marketing ingresan al sistema al mdulo de gestin y seleccionaran la lista de deudores a gestionar haciendo una bsqueda por control de trabajo, luego que se contactan con los deudores y aceptan las condiciones se le cambia el estatus a gestin aceptada. Al final del da el Jefe de operaciones genera un reporte con los datos de los deudores que aceptaron la gestin, para ser enviados a la empresa contratante, previamente hizo una bsqueda por control de trabajo. Adicionalmente ingresa al mdulo de administracin de gestiones donde verifica las gestiones de las tele operadoras, previamente hizo una bsqueda por control de trabajo. Mensualmente el Jefe de Operaciones registra en el sistema una factura donde detalla la cantidad de gestiones aceptadas, previamente busco a la empresa contratante para signarle la factura
CIBERTEC
CARRERAS PROFESIONALES
100
CARRERAS PROFESIONALES
CIBERTEC
101
Para el tratamiento de la verificacin de la informacin, la cual retorna un valor de verdadero o falso dependiendo de si encontr o no la informacin. Verificar/Validar <informacin a verificar> Por ejemplo: Verificar Existencia de Producto, Validar Existencia de Usuario.
Para el tratamiento de documentos informales o de uso interno, el cual incluye las opciones de mantenimiento en un slo caso de uso. Gestionar/Administrar <Nombre del documento informal> Por ejemplo: Administrar Cotizacin, Gestionar Nota de Pedido. Es necesario aclarar que si uno de los documentos informales origin un documento formal ya no se puede modificar o anular. Por ejemplo, una cotizacin que se aprueba y genera una factura ya no podra modificarse o anularse.
1.3 Actores
Desde el punto de vista de un caso de uso especfico, existen dos tipos de actores: Actores primarios o principales: Activan el caso de uso. Actores secundarios: Interactan con el caso de uso despus de haberse activado.
CIBERTEC
CARRERAS PROFESIONALES
102
1. El Caso de Uso se inicia cuando es invocado por otro caso de uso base. b) Centrase en el qu, no en el cmo Mantenga los detalles de diseo fuera del caso de uso. Por ejemplo, el siguiente paso es incorrecto. 5. El Cliente pulsa el botn Aceptar. La mejor forma de expresar ese paso es la siguiente: 4. El Cliente selecciona Aceptar Pedido. c) Referencia a un caso de uso incluido Para especificar la invocacin a un caso de uso incluido se utiliza la siguiente expresin: El sistema Incluye el CU Buscar Habitacin. Por ejemplo: 7. La recepcionista solicita Buscar Habitaciones disponibles. 8. El sistema Incluye el CU Buscar Habitacin. d) Ramificacin dentro de un flujo Para indicar una ramificacin en el flujo se utiliza la palabra Si. La condicin sujeta puede llevar a un conjunto de sub-acciones (desviaciones simples) o a un subflujo (desviaciones complejas). El siguiente ejemplo utiliza ramificaciones. 5. Si la Recepcionista elige un cliente a. Si selecciona Modificar ver el Subflujo Modificar Cliente b. Si selecciona Eliminar ver el Subflujo Eliminar Cliente. e) Repeticin dentro de un flujo Para indicar la repeticin de un conjunto de acciones se utiliza al final de la accin la siguiente expresin: Si <actor> <funcin>, repite los pasos del <X1> al <X2>. Por ejemplo: ... 7. La recepcionista solicita Buscar Habitaciones disponibles. 8. El sistema Incluye el CU Buscar Habitacin. 9. El sistema muestra las habitaciones disponibles. 10. La Recepcionista ingresa la cantidad de personas para la habitacin seleccionada. 11. El sistema valida la cantidad de personas ingresada. 12. El sistema calcula y muestra el subtotal del precio a pagar y el monto total.
CARRERAS PROFESIONALES
CIBERTEC
103
13. Si la Recepcionista quiere seleccionar habitacin, repite los pasos del 7 al 12. ... 1.4.2 Subflujos
otra
Es opcional en un caso de uso. Pueden presentarse varios subflujos y cada uno de ellos sigue las mismas reglas del flujo bsico. 1.4.3 Flujos alternativos Son rutas de acceso alternativas a travs del caso de uso que capturan errores, ramificaciones e interrupciones en el flujo principal. En la figura 11.1 se ilustran los caminos posibles de una instancia de caso de uso (escenario).
11.1. Caminos del Flujo de eventos. A continuacin se muestra dos flujos alternativos para el caso de uso Generar Orden de Reparacin. <Automvil no Registrado> En el punto 8, si el sistema verifica que el Automvil no est registrado muestra el MSG Automvil no registrado, la Secretaria puede ir a Registrar Automvil y continuar con el paso 9. <Cancelar> Si la Secretaria solicita Cancelar antes de Grabar la Orden de Reparacin, el sistema cierra la interfaz y el caso de uso finaliza.
1.5 Precondiciones
Restringen el estado del sistema antes de que el caso de uso pueda empezar. Si un caso de uso no tiene ninguna precondicin se debera escribir Ninguna. Por ejemplo: 1. El Recepcionista est logeado en el sistema. 2. Lista de Clientes disponibles. 3. Lista de Habitaciones disponibles.
1.6 Poscondiciones
Restringen el estado del sistema despus de que el caso de uso se ha ejecutado. Si un caso de uso no tiene ninguna poscondicin se debera escribir Ninguna. Por ejemplo:
CIBERTEC
CARRERAS PROFESIONALES
104
1. En el sistema queda registrado la reserva con su detalle. 2. Las habitaciones seleccionadas se actualizan al estado Reservadas.
1.9 Prototipos
En esta seccin se muestran las interfaces grficas de usuario diseadas para el caso de uso. No es relevante mostrar las interfaces de los mensajes de advertencias o error.
CARRERAS PROFESIONALES
CIBERTEC
105
Datos de las habitaciones: Nmero de habitacin, Tipo, Categora, capacidad, monto por da, Sub Total y Monto Total. Adems incluye las opciones: Buscar Cliente, Buscar Habitaciones, Agregar, Eliminar, Grabar Reserva y Salir. 3. 4. 5. 6. 7. 8. 9. La Recepcionista selecciona Buscar Cliente. El sistema Incluye el CU Buscar Cliente. El sistema muestra los datos del cliente. La recepcionista ingresa la fecha de reserva y cantidad de das. La recepcionista solicita Buscar Habitaciones disponibles. El sistema Incluye el CU Buscar Habitacin. El sistema muestra datos de habitacin disponible.
10. La Recepcionista ingresa la cantidad de personas para la habitacin seleccionada y selecciona Agregar. 11. El sistema valida la cantidad de personas ingresada. 12. El sistema calcula y muestra subtotal y monto total a pagar. 13. Si la Recepcionista quiere seleccionar otra habitacin, se repite del paso 7 al 12. 14. La Recepcionista selecciona Grabar Reserva. 15. El sistema autogenera un nmero de reserva. 16. El sistema graba la reserva con su detalle y actualiza la(s) habitacin(es) en estado Reservado. 17. El sistema muestra el nmero de reserva y el MSG Reserva generada con el Nro. 99999. 18. La Recepcionista cierra la interfaz RESERVA y regresa a la interfaz del men principal del sistema y finaliza el caso de uso. 3.2. Subflujos Ninguno. 3.3. Flujos Alternativos <Cliente no existe> En el paso 5, si el sistema detecta que el cliente no existe muestra el MSG: Cliente no existe y ofrecer la posibilidad de registrar al nuevo cliente.
CIBERTEC
CARRERAS PROFESIONALES
106
<Habitaciones no disponibles> En el paso 9, si el sistema detecta que no hay habitaciones disponibles muestra el MSG: No hay habitaciones disponibles y finaliza el caso de uso. <Cantidad de Personas incorrecta> En el paso 12, si la Recepcionista ingres una cantidad mayor a la capacidad de la habitacin seleccionada, el sistema muestra el MSG Ingrese una cantidad de personas menor o igual a la capacidad de la habitacin y contina con el paso 10. <Eliminar habitacin> Si la Recepcionista solicita Eliminar una habitacin seleccionada, antes de Grabar, el sistema lo borra del detalle y el caso de uso contina en el paso 13. 4. Precondiciones 4.1. El Recepcionista est logueado en el sistema. 4.2. Lista de Clientes disponibles. 4.3. Lista de habitaciones disponibles. 5. Pos condiciones 5.1. En el sistema queda registrado la reserva con su detalle. 5.2. Las habitaciones seleccionadas se actualizan en estado Reservadas. 6. Puntos de Extensin En el paso 5, el sistema extiende al caso de uso Mantener Clientes Flujo bsico Agregar Cliente. 7. Requisitos Especiales Ninguno.
CARRERAS PROFESIONALES
CIBERTEC
107
8. Prototipos
CIBERTEC
CARRERAS PROFESIONALES
108
3.3.5.1. Objetivos El propsito de la priorizacin de los USE CASE es identificar los casos de uso primarios para la presente etapa de desarrollo del proyecto. Segn estos criterios, se determinan los casos de uso crticos para especificarlos en esta etapa del proyecto. 3.3.5.2. Alcance La priorizacin permitir darle la debida atencin (y con mas tiempo) a los USE CASE ms complejos e importante. 3.3.5.3. Priorizacin Distingue a los USE CASE crticos o primarios de los secundarios. Ms adelante, se especifica el criterio utilizado para determinar cules son primarios y cules son secundarios. o Nivel crtico (o primario) Agrupa a los USE CASE que tienen que ver con las funciones bsicas del sistema. o 3.2. Nivel de baja importancia (o secundario) Agrupa a los USE CASE que tienen que ver con las funciones de soporte del sistema y que no representan mayor riesgo para el proyecto. 3.3.5.4. Factores tomados en cuenta en la priorizacin Se tomaron en cuenta pesos (que representan porcentaje) por cada factor que afecta a cada USE CASE. Los valores que pueden tomar los factores estn en la escala del 1 al 10 (1: menor importancia; 10: mayor importancia). Se considerarn primarios a aquellos USE CASE que tengan un puntaje mayor a 6.5, ya que esto significa que superan el 65% de prioridad en el sistema (PONDERACIN). Importancia en el proceso del negocio: indica la relevancia que tiene la funcionalidad con el proceso de negocio. Una alta puntuacin revela que las transacciones de la empresa se apoyan considerablemente en la funcionalidad que tiene este USE CASE. Su ponderacin es 0.4. Complejidad de desarrollo: Indica la dificultad que se percibe del USE CASE, en cuanto a las tareas de anlisis, diseo, implementacin, pruebas e integracin del mismo. Su ponderacin es 0.3.
CARRERAS PROFESIONALES
CIBERTEC
109
Riesgo asociado: Indica la relacin que se percibe entre el USE CASE y la lista de riesgos. Un alto valor en este factor indica que el caso de uso tiene bastantes riesgos o riesgos de alto valor asociados. Los USE CASE con alto valor en este factor pueden ser considerados primarios debido a que deben ser enfrentados en las etapas iniciales. Su ponderacin es 0.2. Impacto de los requerimientos no funcionales: Indica cmo afectan los requerimientos no funcionales (usability, reliability, performance, supportability) al proceso del negocio y en qu manera el USE CASE se vera comprometido. Su ponderacin es 0.1.
EJEMPLO DE PRIORIZACION DE LOS CASOS DE USO LACTEOS LA LUZ I. A continuacin se muestra los Subsistemas de Lcteos La Luz, de acuerdo a sus objetivos y tareas.
SUBSISTEMAS
Servicios al cliente Gestin de ventas Tareas del despachador Tareas ejecutivas.
A. Servicios al cliente 1. Registrar cliente 2. Elaborar pedido 3. Rastrear pedido 4. Consultar cuenta 5. Acusar recibo / reclamo
Importancia en el proceso del negocio Registrar cliente 10 Elaborar pedido 9 Rastrear pedido 6 Consultar 9 cuenta Acusar recibo 5 /reclamo Complejidad de desarrollo Riesgo asociado Impacto de requerimientos no funcionales 9 9 8 9 7 Total
6 7 8 8 5
9 7 5 6 3
8.5 8 6.75 8 5
B. Gestin de ventas 1. Aceptar / Rechazar pedido 2. Facturar pedidos 3. Actualizar cuenta 4. Consolidar pedido 5. Ordenar produccin
CIBERTEC
CARRERAS PROFESIONALES
110
Aceptar /Rechazar pedido Facturar pedidos Actualizar cuenta Consolidar pedido Ordenar produccin
Complejidad de desarrollo
Riesgo asociado
Total
9 9 10 6
7 7 6 8
8 9 8 7
9 9 6 3
C. Tareas del despachador 1. Configurar despachos 2. Rastrear pedido 3. Configurar embalaje 4. Configurar ruta 5. Acusar recibo / reclamo 6. Devolver mercanca
Importancia en el proceso del negocio 9 7 8 7 4 4 Complejidad de desarrollo Riesgo asociado Impacto de requerimientos no funcionales 7 6 7 6 6 5 Total
Configurar despachos Rastrear pedido Configurar embalaje Configurar ruta Acusar recibo / reclamo Devolver mercanca
6 6 8 6 5 7
6 7 7 8 7 5
D. Tareas Ejecutivas 1. Obtener informacin de productos 2. Evaluar el desempeo de productos 3. Generar informe
Importancia en el proceso del negocio 8 Complejidad de desarrollo Riesgo Asociado Impacto de requerimientos no funcionales 6 Total
7.75
7.25
CARRERAS PROFESIONALES
CIBERTEC
111
II. Luego de haber priorizado cada subsistema, se agrupa por iteraciones, esta agrupacin consiste en tomar los 3 CU ms importantes del subsistema (con mayor ponderacin). Ests iteraciones debern ser desarrolladas en la fase de construccin del proceso del sistema. A. Servicios al cliente Iteracin 1 Registrar cliente Consultar cuenta Elaborar pedido Iteracin 2 Rastrear pedido Acusar Recibo / Reclamo B. Gestin de ventas Iteracin 1 Actualizar cuenta Facturar pedidos Consolidar pedido Iteracin 2 Ordenar roduccin Aceptar / Rechazar Pedido C. Tareas del despachador Iteracin 1 Configurar embalaje Configurar despacho Configurar ruta Iteracin 2 Rastrear pedido Devolver mercanca Acusar Recibo / Reclamo
8.5 8 8 6.75 5
D. Tareas ejecutivas Iteracin 1 Evaluar desempeo del producto 7.75 Generar informe Obtener informacin de productos 7
7.25
Nota.- Requerimientos primarios sern aquellos que presenten un puntaje mayor a 6.5.
CIBERTEC
CARRERAS PROFESIONALES
112
Resumen
El Modelado de casos uso nos permite representar las funcionalidades del sistema a implementar. El Modelo de casos de uso contiene a los actores y casos de uso, que son los artefactos relevantes del modelo. En el Modelo de casos de uso se crean los siguientes diagramas: Diagrama de casos de uso Diagrama de actores Diagrama de casos de uso por proceso de negocio Existen tres relaciones entre casos de uso: Generalizacin, include y extend. La generalizacin tambin se puede dar entre actores. En una relacin de generalizacin, el caso de uso hijo hereda la estructura, comportamiento y las relaciones del padre. En una relacin include, el caso de uso incluido encapsula el comportamiento necesario y reutilizado por varios casos de uso base. En una relacin extend, el caso de uso extendido encapsula el comportamiento opcional de un caso de uso base.
CARRERAS PROFESIONALES
CIBERTEC
113
CASOS PCTICOS
CIBERTEC
CARRERAS PROFESIONALES
114
Otro Servicio de la empresa es el mantenimiento de los vehculos en el taller, el cliente llevara su vehculo para su mantenimiento. El asistente del taller ingresara al sistema una solicitud de servicio, verificando previamente si el cliente se encuentra registrado, si no se encontrase deber de regstralo en el sistema, registrando la solicitud como por atender. Despus de que el servicio fue dado el cliente se acercara al rea de facturacin, el cajero tomara toda la informacin del sistema valindose de la solicitud de servicio y verificando todo los servicios que se le dio al auto generando el comprobante de pago correspondiente y registrando la solicitud como cancelada
CARRERAS PROFESIONALES
CIBERTEC
115
Glosario
Artefacto Pieza discreta de informacin que es utilizada o producida por un proceso de desarrollo de software. Caso de uso abstracto Un caso de uso es abstracto slo si se instancia en el contexto de otro caso de uso, es decir, dependen de otro caso de uso para instanciarse puesto que no existe un actor que lo active. Caso de uso concreto Un caso de uso es concreto si es iniciado por un actor y constituye un completo flujo de eventos. "Completo" significa que una instancia del caso de uso lleva a cabo toda la operacin solicitada por el actor. Condicin de guardia Condicin que se debe satisfacer para permitir que se dispare una transicin asociada. Es utilizado en Diagrama de actividades a partir de un control de decisin. CASE Computer Aided Software Engineering Ingeniera de Software asistida por computadora. Diagrama Representacin grfica de un conjunto de elementos, representado en la mayora de casos como un grafo conexo de nodos (elementos) y arcos (relaciones). Diagrama de actividades Diagrama que muestra el flujo de control datos entre actividades. Cubren la vista dinmica de un sistema. Diagrama de casos de uso Diagrama que representa procesos de negocio o funcionalidades del sistema y externos. Diagrama de clases Muestra un conjunto de clases y sus relaciones. Diagrama de componentes Muestra la organizacin y las dependencias entre un conjunto de componentes (elementos de implementacin) del sistema. Diagrama de comunicacin Diagrama de interaccin que resalta la organizacin estructural de objetos que envan y reciben mensajes.
CIBERTEC
CARRERAS PROFESIONALES
116
Diagrama de despliegue Muestra la configuracin en tiempo de ejecucin de los nodos de procesamiento y dispositivos que componen una red. Diagrama de estados Representa los estados potenciales de los objetos y las transiciones entre esos estados. Diagrama de objetos Muestra un conjunto de objetos y enlaces en un momento dado. Diagrama de Secuencia Diagrama de interaccin que resalta la secuencia temporal de los mensajes entre objetos. Elemento Constituyente atmico de un modelo. Escenario Secuencia especfica de acciones que ilustra un comportamiento. Especificacin Descripcin textual de la sintaxis y la semntica de un bloque de construccin especfico; descripcin declarativa de lo que algo es o hace. Estereotipo Extensin del vocabulario de UML que permite crear nuevos bloques de construccin derivados a partir de los existentes pero especficos a un problema concreto. Herramienta CASE Aplicacin informtica destinada a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Instancia Manifestacin concreta de un bloque de construccin de UML. Modelo Un modelo es una representacin de un sistema o aplicacin. Un modelo UML es un modelo que utiliza la notacin del Lenguaje Unificado de Modelado para representar grficamente un sistema en distintos niveles de abstraccin. Notacin Sistema de signos convencionales que se adoptan para expresar un conjunto de conceptos sobre el sistema de software por desarrollar. OMG Object Management Group Consorcio del cual forman parte las empresas ms importantes que se dedican al desarrollo de software. OMT Object-Modeling Technique Es un mtodo para el modelado orientado a objetos, creado por James Rumbaugh, que dio mayor nfasis a las notaciones grficas para el anlisis orientado a objetos.
CARRERAS PROFESIONALES
CIBERTEC
117
OOSE Object-Oriented Software Engineering Es un mtodo de ingeniera de software orientado a objetos, creado por James Rumbaugh. Ha sido llamado un enfoque para el manejo de casos de uso, en este enfoque el modelo de casos de uso sirve como un modelo central del cual todos los otros modelos son derivados. Perfiles UML Constituyen el mecanismo que proporciona el UML para extender su sintaxis y su semntica para expresar los conceptos especficos de un determinado dominio de aplicacin. Refinamiento Relacin que representa una especificacin ms completa de algo que ya ha sido especificado a cierto nivel de detalle. Requisito Caracterstica, propiedad o comportamiento deseado de un sistema. RSA Rational Software Architect Herramienta CASE de diseo y construccin para arquitectos de software y desarrolladores snior para crear aplicaciones en la plataforma Java o en C++. Permite un desarrollo basado en modelos con el lenguaje UML y unifica todos los aspectos de la arquitectura de la aplicacin de software. RUP Rational Unified Process Proceso Unificado de Rational, metodologa del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Stakeholder Personas u organizaciones que estn directamente involucradas en la elaboracin o tomas de decisiones claves acerca de la funcionalidad y propiedades de un sistema software. UML Unified Modeling Language Lenguaje unificado de modelado, notacin estndar para el modelado de sistemas Software. Workspace Es un directorio que representa el espacio de trabajo y el cual contendr los proyectos que se crean en la herramienta RSA.
CIBERTEC
CARRERAS PROFESIONALES