3ero Manual IngenieSistemasI

INGENIERA DE SISTEMAS - I
Presentacin
Ingeniera de Sistemas I Grupo IDAT Desarrollo y Edicin a cargo del Programa de Computacin e Informtica. Director Ejecutivo Coordinador Acadmico : : Ing. Rolando Rojas Gallo Ing. Jos Garca La Riva Sr. Julio Cabrera Calle. Srta. Katy Lzaro Nez Prof. Jorge Gonzales Marav Prof. Ponce Becerra, Carol Fanny Prof. Cuya Camara, Jos Departamento de Impresiones del Grupo IDAT
Coordinador Administrativo : Diseo y Diagramacin : Elaborado por : Produccin :
Los derechos de edicin, distribucin y contenidos de este texto son de exclusividad del GRUPO IDAT.
Presentacin
Ingeniera de Sistemas I pertenece a la lnea formativa que imparte conocimientos relacionados con el proceso de ingeniera de software, metodologa RUP y UML (Lenguaje de Moldeamiento Unificado) para desarrollar un software de calidad. El presente manual se ha diseado por captulos que se desarrollan en las semanas acadmicas, en cada captulo se desarrollan los contenidos tericos con ejemplos resueltos y propuestos. El curso es terico-prctico, cuenta con laboratorio para desarrollar casos de proyectos de software utilizando la herramienta de modelado de Rational Roose, bsicamente se desarrolla la disciplinas de Modelado de Negocio y Modelo de Requerimientos.
ndice
Presentacin Captulo 1: Ingeniera Software, RUP y UML 1. 2. 3. 4. Ingeniera de Software Metodologa RUP Tcnicas de Recoleccin de Informacin UML 5 9 11 18 32 39 45 50 51 77 106
Capitulo 2: Modelo de Negocio 1. Modelo de Caso de Uso del Negocio 2. Modelo de Anlisis del Negocio Capitulo 3: Modelo de Requerimientos Bibliografa
1
CAPTULO
Ingeniera Software, RUP y UML
Ingeniera de Software Metodologa RUP Tcnicas de Recoleccin de Informacin UML
Ingeniera de Sistemas I
INGENIERA DE SOFTWARE
1. QU ES INGENIERA DE SOFTWARE Es la disciplina o rea de la informtica que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad. Esta ingeniera trata con reas muy diversas de la informtica y de las ciencias de la computacin, tales como construccin de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de informacin y aplicables a infinidad de reas: negocios, investigacin cientfica, medicina, produccin, logstica, banca, control de trfico, meteorologa, derecho, Internet, Intranet, etc. 2. MODELOS DE PROCESOS DE INGENIERA DE SOFTWARE La ingeniera de software tiene varios modelos, paradigmas o filosofas de desarrollo en los cuales se puede apoyar para la realizacin de software, de los cuales podemos destacar a stos por ser los ms utilizados y los ms completos: Modelo en cascada o Clsico (modelo tradicional) Modelo en espiral (modelo evolutivo) Modelo de prototipos Desarrollo por etapas Desarrollo iterativo y creciente o Iterativo e Incremental RAD (Rapid Application Development)
3. METODOLOGAS DE DESARROLLO DE SOFTWARE Qu metodologa debo usar para el desarrollo de un Software? Todos en algn momento nos hemos hecho esta pregunta, cuando hemos tenido que desarrollar un sistema o aplicacin de software. Y de hecho esta pregunta se torna muy importante, pues como arquitectos de Software, debemos tener un plano en que apoyarnos. Todo desarrollo de software es riesgoso y difcil de controlar, pero si no llevamos una metodologa de por medio, lo que obtenemos es clientes insatisfechos con el resultado y desarrolladores an ms insatisfechos. Sin embargo, muchas veces no se toma en cuenta el utilizar una metodologa adecuada, sobre todo cuando se trata de proyectos pequeos de dos o tres meses. Lo que se hace con este tipo de proyectos es separar rpidamente el aplicativo en procesos, cada proceso en funciones, y por cada funcin determinar un tiempo aproximado de desarrollo. Cuando los proyectos que se van a desarrollar son de mayor envergadura, ah si toma sentido el basarnos en una metodologa de desarrollo, y empezamos a buscar cual sera la ms apropiada para nuestro caso. Lo cierto es que muchas veces no encontramos la ms adecuada y terminamos por hacer o disear nuestra 11
PROGRAMA DE COMPUTACIN E INFORMTICA- IDAT
Ingeniera de Sistemas I propia metodologa, algo que por supuesto no esta mal, siempre y cuando cumpla con el objetivo. Muchas veces realizamos el diseo de nuestro software de manera rgida, con los requerimientos que el cliente nos solicit, de tal manera que cuando el cliente en la etapa final (etapa de prueba), solicita un cambio se nos hace muy difcil realizarlo, pues si lo hacemos, altera muchas cosas que no habamos previsto, y es justo ste, uno de los factores que ocasiona un atraso en el proyecto y por tanto la incomodidad del desarrollador por no cumplir con el cambio solicitado y el malestar por parte del cliente por no tomar en cuenta su pedido. Obviamente para evitar estos incidentes debemos haber llegado a un acuerdo formal con el cliente, al inicio del proyecto, de tal manera que cada cambio o modificacin no perjudique al desarrollo del mismo. Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosas que dejaron de mencionar, recin en la etapa final del proyecto, pese a que se les mostr un prototipo del software en la etapa inicial del proyecto. Los proyectos fracasan cuando exceden el tiempo y presupuesto, o simplemente no cumplen con las expectativas del cliente. Para dar una idea de qu metodologa podemos utilizar y cual se adapta ms a nuestro medio, mencionar tres de ellas de las que se consideran las ms importantes, tal como: RUP, XP y MSF.
Rational Unified Process (RUP)

La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process, es un proceso de desarrollo de software. Un Proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema de software. Sin embargo el proceso de desarrollo es ms que un simple proceso; es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones y diferentes tamaos de proyectos. El Proceso Unificado est basado en componentes, lo cual quiere decir que el sistema de software en construccin est formado por componentes de software interconectados a travs de interfaces bien definidas. El Proceso Unificado se basa en: Dirigido por Casos de Uso Centrado en la Arquitectura Es Iterativo e Incremental El RUP se divide en 4 fases: Inicio, El Objetivo en esta etapa es determinar la visin del proyecto. Elaboracin, En esta etapa el objetivo es determinar la arquitectura ptima. Construccin, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. Transicin, El objetivo es llegar a obtener el release del proyecto.
12
Ingeniera de Sistemas I Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes. Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo dos disciplinas:
Disciplina de Desarrollo:
Ingeniera de Negocios: Entendiendo las necesidades del negocio. Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado. Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software. Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado. Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo los solicitado esta presente. Disciplina de Soporte Configuracin y administracin del cambio: Guardando todas las versiones del proyecto. Administrando el proyecto: Administrando horarios y recursos. Ambiente: Administrando el ambiente de desarrollo. Distribucin: Hacer todo lo necesario para la salida del proyecto.
Figura_01: Fases e Iteraciones de la Metodologa RUP
13
Ingeniera de Sistemas I Es recomendable que a cada una de estas iteraciones se les clasifique y ordene segn su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentacin que se tendra en cada entregable o en cada iteracin.
Los elementos del RUP son:

Actividades, Son los procesos que se llegan a determinar en cada iteracin. Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso. Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo. Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologas ms importantes para alcanzar un grado de certificacin en el desarrollo del software.
Principales Beneficios del RUP:

Provee lineamientos para un desarrollo eficiente de software de calidad Captura-Presenta las mejores prcticas Aprender de la experiencia anterior Verificar la calidad Desarrollo iterativo Arquitectura basada en componentes Modelar visualmente el sistema Mejora la comunicacin con los usuarios Extensin del material de capacitacin Promueve una visin y una cultura Comn Guas sobre cmo utilizar herramientas Reduce Riesgos e incrementa la Predictibilidad
Extreme Programing (XP)

Es una de las metodologas de desarrollo de software ms exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodologa consiste en una programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto.
Figura_02: Metodologa Extreme Programing
14
Caractersticas de XP, la metodologa se basa en: Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantndonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantramos a obtener los posibles errores. Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean patrones o modelos estndares, siendo ms flexible al cambio. Programacin en pares: una particularidad de esta metodologa es que propone la programacin en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.
Qu es lo que propone XP?

Empieza en pequeo y aade funcionalidad con retroalimentacin continua El manejo del cambio se convierte en parte sustantiva del proceso El costo del cambio no depende de la fase o etapa No introduce funcionalidades antes que sean necesarias El cliente o el usuario se convierte en miembro del equipo
Derechos del Cliente

Decidir que se implementa Saber el estado real y el progreso del proyecto Aadir, cambiar o quitar requerimientos en cualquier momento Obtener lo mximo de cada semana de trabajo Obtener un sistema funcionando cada 3 o 4 meses
Derechos del Desarrollador

Decidir como se implementan los procesos Crear el sistema con la mejor calidad posible Pedir al cliente en cualquier momento aclaraciones de los requerimientos Estimar el esfuerzo para implementar el sistema Cambiar los requerimientos en base a nuevos descubrimientos
Lo fundamental en este tipo de metodologa es:

La comunicacin, entre los usuarios y los desarrolladores La simplicidad, al desarrollar y codificar los mdulos del sistema La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales
15
Microsoft Solution Framework (MSF)

Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos y prcticas de uso, que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas.
Figura_03: Metodologa MSF
MSF tiene las siguientes caractersticas: Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es limitado a un especfico lugar. Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin, proyectos que requieren 50 personas a ms. Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnologa. MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de Diseo de Proceso y finalmente el modelo de Aplicacin. Modelo de Arquitectura del Proyecto: Diseado para acortar la planificacin del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a travs del lanzamiento de versiones. Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo de personas disponibles. Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberacin de versiones y explicando su relacin con el Modelo de equipo. Modelo de Gestin del Riesgo: Diseado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratgicas correctas y controlar 16
Ingeniera de Sistemas I las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar. Modelo de Diseo del Proceso: Diseado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseo eficiente y flexible a travs de un enfoque iterativo. Las fases de diseo conceptual, lgico y fsico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores. Modelo de Aplicacin: Diseado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para disear y desarrollar aplicaciones software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un solo ordenador o incluso en varios servidores. Conclusin: Todas las metodologas modernas usan al UML, para el desarrollo de sus modelos. La Metodologa RUP es ms adaptable para proyectos de largo plazo. La Metodologa XP en cambio, se recomienda para proyectos de corto plazo. La Metodologa MSF se adapta a proyectos de cualquier dimensin y de cualquier tecnologa. Podemos concluir adems, que lo ms importante antes de elegir la metodologa que usars para la implementacin de tu software, es determinar el alcance que tendr y luego de ah ver cual es la que ms se acomoda en tu aplicacin.
17
METODOLOGA RUP
1. INTRODUCCIN Es un proceso para el desarrollo de aplicaciones, es un conglomerado de las mejores prcticas para conducir las actividades de desarrollo, del equipo de la ingeniera de software. Como una plataforma de procesos que abarca todas las prcticas de la industria, el RUP permite seleccionar fcilmente el conjunto de componentes de proceso que se ajustan a las necesidades especficas del proyecto. Se podrn alcanzar resultados predecibles unificando el equipo con procesos comunes que optimicen la comunicacin y creen un entendimiento comn para todas las tareas, responsabilidades y artefactos. Desde un nico sitio web centralizado de intercambio, el Software Rational, las plataformas, herramientas y expertos de dominios proveen los componentes de proceso necesarios para el desarrollo de software de calidad. Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la evolucin del proceso, caractersticas principales y estructura del proceso. RUP es un producto comercial desarrollado y comercializado por Rational Software, una compaa de IBM. 2. CARACTERSTICAS ESENCIALES Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres caractersticas esenciales: est dirigido por los Casos de Uso, est centrado en la arquitectura, y es iterativo e incremental.
Proceso dirigido por Casos de Uso

Los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario y no slo en trminos de funciones que sera bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor aadido. Los Casos de Uso representan los requisitos funcionales del sistema. Los Casos de Uso no slo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.
Proceso centrado en la arquitectura

La arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes, lo que permite tener una visin comn entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.
18
Ingeniera de Sistemas I La arquitectura involucra los aspectos estticos y dinmicos ms significativos del sistema, est relacionada con la toma de decisiones que indican cmo tiene que ser construido el sistema y ayuda a determinar en qu orden. Adems la definicin de la arquitectura debe tomar en consideracin elementos de calidad del sistema, rendimiento, reutilizacin y capacidad de evolucin por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.
Proceso iterativo e incremental

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la funcin en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes ms pequeas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, as durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteracin (un recorrido ms o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto. Una iteracin puede realizarse por medio de una cascada como se muestra en la Figura 04. Se pasa por los flujos fundamentales (Requisitos, Anlisis, Diseo, Implementacin y Pruebas), tambin existe una planificacin de la iteracin, un anlisis de la iteracin y algunas actividades especficas de la iteracin. Al finalizar se realiza una integracin de los resultados con lo obtenido de las iteraciones anteriores.
Figura_04: Una iteracin RUP
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteracin se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificacin de 19
Ingeniera de Sistemas I los detalles de la siguiente iteracin, el equipo tambin examina cmo afectarn los riesgos que an quedan al trabajo en curso. Toda la retroalimentacin de la iteracin pasada permite reajustar los objetivos para las siguientes iteraciones. Se contina con esta dinmica hasta que se haya finalizado por completo con la versin actual del producto. 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 hace un mayor o menor hincapi en los distintas actividades. 3. MEJORES PRCTICAS DE RUP RUP identifica 6 best practices con las que define una forma efectiva de trabajar para los equipos de desarrollo de software.
Gestin de requisitos
RUP brinda una gua para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y restricciones. Utiliza una notacin de Caso de Uso y escenarios para representar los requisitos.
Desarrollo de software iterativo

Desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto nfasis, segn la fase del proyecto.
Desarrollo basado en componentes

La creacin de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente sern ensamblados para generar el sistema. Esta caracterstica en un proceso de desarrollo permite que el sistema se vaya creando a medida que se obtienen o se desarrollan sus componentes.
Modelado visual (usando UML)

UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema software. Es un estndar de la OMG (http://www.omg.org). Utilizar herramientas de modelado visual facilita la gestin de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual tambin ayuda a mantener la consistencia entre los artefactos del sistema: requisitos, diseos e implementaciones. En resumen, el modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software.
Verificacin continua de la calidad

Es importante que la calidad de todos los artefactos se evale en varios puntos durante el proceso de desarrollo, especialmente al final de cada iteracin. En esta verificacin las pruebas juegan un papel fundamental y se integran a lo largo de todo 20
Ingeniera de Sistemas I el proceso. Para todos los artefactos no ejecutables las revisiones e inspecciones tambin deben ser continuas.
Gestin de los cambios

El cambio es un factor de riesgo crtico en los proyectos de software. Los artefactos software cambian no slo debido a acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo, especialmente importantes por su posible impacto son los cambios en los requisitos. Por otra parte, otro gran desafo que debe abordarse es la construccin de software con la participacin de mltiples desarrolladores, posiblemente distribuidos geogrficamente, trabajando a la vez en una release, y quizs en distintas plataformas. La ausencia de disciplina rpidamente conducira al caos. La Gestin de Cambios y de Configuracin es la disciplina de RUP encargada de este aspecto. 4. ESTRUCTURA DEL PROCESO El proceso puede ser descrito en dos dimensiones o ejes: Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinmicos del proceso. Indica las caractersticas del ciclo de vida del proceso expresado en trminos de fases, iteraciones e hitos. Se puede observar en la Figura 05 que RUP consta de cuatro fases: Inicio, Elaboracin, Construccin y Transicin. Como se mencion anteriormente cada fase se subdivide a la vez en iteraciones. Eje vertical: Representa los aspectos estticos del proceso. Describe el proceso en trminos de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles.
Figura_05: Estructura de RUP
4.1 Estructura Dinmica del proceso. Fases e iteraciones

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo concluye con una generacin del producto para los clientes. 21
Ingeniera de Sistemas I Cada ciclo consta de cuatro fases: Inicio, Elaboracin, Construccin y Transicin. Cada fase se subdivide a la vez en iteraciones, el nmero de iteraciones en cada fase es variable. Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones crticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podran ser los criterios aplicables a cada iteracin. Los hitos para cada una de las fases son: Inicio, Elaboracin, Construccin, Transicin. Las fases y sus respectivos hitos se ilustran en la Figura 06.
Figura_06: Fases e hitos en RUP
La duracin y esfuerzo dedicado en cada fase es variable dependiendo de las caractersticas del proyecto. Sin embargo, la Figura ilustra porcentajes frecuentes al respecto. Consecuente con el esfuerzo sealado, la Figura ilustra una distribucin tpica de recursos humanos necesarios a lo largo del proyecto. Esfuerzo Tiempo Dedicado Inicio 5% 10% Elaboracin 20% 30% Construccin 65% 50% Transicin 10% 10%
Figura: Distribucin tpicas de esfuerzo y tiempo
A. Inicio
Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y Casos de Uso, y se disean los Casos de Uso ms esenciales (aproximadamente el 20% del modelo completo), se desarrolla una descripcin del producto final a partir de una buena idea. Se desarrolla, un plan de negocio para determinar que recursos deben ser asignados al proyecto. Los objetivos de esta fase son: Establecer el mbito del proyecto y sus lmites. Encontrar los Casos de Uso crticos del sistema, los escenarios bsicos que 22
Ingeniera de Sistemas I definen la funcionalidad. Mostrar al menos una arquitectura candidata para los escenarios principales. Estimar el coste en recursos y tiempo de todo el proyecto. Estimar los riesgos, las fuentes de incertidumbre. Los resultados de la fase de inicio deben ser [RSC98]: Un documento de visin: Una visin general de los requerimientos del proyecto, caractersticas clave y restricciones principales. Modelo inicial de Casos de Uso (10-20% completado). Un glosario inicial: Terminologa clave del dominio. El caso de negocio. Lista de riesgos y plan de contingencia. Plan del proyecto, mostrando fases e iteraciones. Modelo de negocio, si es necesario Prototipos exploratorios para probar conceptos o la arquitectura candidata.
B. Elaboracin
El propsito de la fase de elaboracin es analizar el dominio del problema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos. En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos de Uso crticos identificados en la fase de inicio. Tambin debe demostrarse que se han evitado los riesgos ms graves. Definir, validar y cimentar la arquitectura. Completar la visin. Crear un plan fiable para la fase de construccin. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede. Demostrar que la arquitectura propuesta soportar la visin con un coste razonable y en un tiempo razonable. Al terminar deben obtenerse los siguientes resultados: Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos y actores identificados, la mayora de los casos desarrollados. Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito no asociado con un Caso de Uso especfico. Descripcin de la arquitectura software. Un prototipo ejecutable de la arquitectura. Lista de riesgos y caso de negocio revisados. Plan de desarrollo para el proyecto. Un caso de desarrollo actualizado que especifica el proceso a seguir. Un manual de usuario preliminar (opcional). Si no se superan los criterios de evaluacin quiz sea necesario abandonar el 23
Ingeniera de Sistemas I proyecto o replanterselo considerablemente.
C. Construccin
La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a travs de las sucesivas iteraciones. Durante esta fase todos los componentes, caractersticas y requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una versin aceptable del producto. Los objetivos concretos segn incluyen: Minimizar los costes de desarrollo mediante la optimizacin de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo. Conseguir una calidad adecuada tan rpido como sea prctico. Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rpido como sea prctico. Los resultados de la fase de construccin deben ser : Modelos Completos (Casos de Uso, Anlisis, Diseo, Despliegue e Implementacin) Arquitectura ntegra (mantenida y mnimamente actualizada) Riesgos Presentados Mitigados Plan del Proyecto para la fase de Transicin. Manual Inicial de Usuario (con suficiente detalle) Prototipo Operacional beta Caso del Negocio Actualizado Los criterios de evaluacin de esta fase son los siguientes: El producto es estable y maduro como para ser entregado a la comunidad de usuario para ser probado. Todos los usuarios expertos estn listos para la transicin en la comunidad de usuarios. Son aceptables los gastos actuales versus los gastos planeados.
D. Transicin
La finalidad de la fase de transicin es poner el producto en manos de los usuarios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentacin, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuracin, instalacin y facilidad de uso del producto. En se citan algunas de las cosas que puede incluir esta fase: Prueba de la versin Beta para validar el nuevo sistema frente a las expectativas de los usuarios Funcionamiento paralelo con los sistemas legados que estn siendo sustituidos por nuestro proyecto. 24
Ingeniera de Sistemas I Conversin de las bases de datos operacionales. Entrenamiento de los usuarios y tcnicos de mantenimiento. Traspaso del producto a los equipos de marketing, distribucin y venta. Los principales objetivos de esta fase son: Conseguir que el usuario se valga por si mismo. Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario. Los resultados de la fase de transicin son : Prototipo Operacional Documentos Legales Caso del Negocio Completo Lnea de Base del Producto completa y corregida que incluye todos los modelos del sistema Descripcin de la Arquitectura completa y corregida Las iteraciones de esta fase irn dirigidas normalmente a conseguir una nueva versin. Los criterios de evaluacin de esta fase son los siguientes: El usuario se encuentra satisfecho. Son aceptables los gastos actuales versus los gastos planificados.
4.2 Estructura Esttica del proceso. Roles, actividades, artefactos y flujos de trabajo
Un proceso de desarrollo de software define quin hace qu, cmo y cundo. RUP define cuatro elementos los roles, que responden a la pregunta Quin?, las actividades que responden a la pregunta Cmo?, los productos, que responden a la pregunta Qu? y los flujos de trabajo de las disciplinas que responde a la pregunta Cundo? (ver Figura) .
Figura_07: Relacin entre roles, actividades, artefactos 25

Figura_08: Detalle de un workflow mediante roles, actividades y artefactos
A. Roles
Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempear diversos roles, as como un mismo rol puede ser representado por varias personas. 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 . RUP define grupos de roles, agrupados por participacin en actividades relacionadas. Estos grupos son: Analistas:
Analista de procesos de negocio. Diseador del negocio. Analista de sistema. Especificador de requisitos.
Desarrolladores: Arquitecto de software. Diseador Diseador de interfaz de usuario Diseador de cpsulas. Diseador de base de datos. Implementador. Integrador. Gestores: Jefe de proyecto Jefe de control de cambios. Jefe de configuracin. Jefe de pruebas Jefe de despliegue 26
Ingeniera de Sistemas I Ingeniero de procesos Revisor de gestin del proyecto Gestor de pruebas. Apoyo: Documentador tcnico Administrador de sistema Especialista en herramientas Desarrollador de cursos Artista grfico Especialista en pruebas: Especialista en Pruebas (tester) Analista de pruebas Diseador de pruebas Otros roles: Stakeholders. Revisor Coordinacin de revisiones Revisor tcnico Cualquier rol
B. Actividades
Una actividad en concreto es una unidad de trabajo que una persona que desempee un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en trminos de crear o actualizar algn producto.
C. Artefactos
Un producto o artefacto es un trozo de informacin que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final . Un artefacto puede ser cualquiera de los siguientes: Un documento, como el documento de la arquitectura del software. Un modelo, como el modelo de Casos de Uso o el modelo de diseo. Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un Caso de Uso o un subsistema.
D. Flujos de trabajo
Con la enumeracin de roles, actividades y artefactos no se define un proceso, necesitamos contar con una secuencia de actividades realizadas por los diferentes roles, as como la relacin entre los mismos. Un flujo de trabajo es una relacin de actividades que nos producen unos resultados observables. A continuacin se 27
Ingeniera de Sistemas I dar una explicacin de cada flujo de trabajo.
- Modelado del negocio

Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la organizacin donde se va a implantar el producto. Los objetivos del modelado de negocio son : Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado (organizacin objetivo). Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Derivar los requisitos del sistema necesarios para apoyar a la organizacin objetivo. Para lograr estos objetivos, el modelo de negocio describe como desarrollar una visin de la nueva organizacin, basado en esta visin se definen procesos, roles y responsabilidades de la organizacin por medio de un modelo de Casos de Uso del negocio y un Modelo de Objetos del Negocio. Complementario a estos modelos, se desarrollan otras especificaciones tales como un Glosario.
- Requisitos:
Este es uno de los flujos de trabajo ms importantes, porque en l se establece qu tiene que hacer exactamente el sistema que construyamos. En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos. Los objetivos del flujo de datos Requisitos es : Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podra hacer. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. Definir el mbito del sistema. Proveer una base para la planeacin de los contenidos tcnicos de las iteraciones. Proveer una base para estimar costos y tiempo de desarrollo del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario. Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los requisitos no funcionales representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad especfica. Por ejemplo requisitos de facilidad de uso, fiabilidad, eficiencia, portabilidad, etc.
28
Ingeniera de Sistemas I Para capturar los requisitos es preciso entrevistar a todos los interesados en el proyecto, no slo a los usuarios finales, y anotar todas sus peticiones. A partir de ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos. En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se disea la interfaz grfica de usuario. Para ello habitualmente se construyen prototipos de la interfaz grfica de usuario que se contrastan con el usuario final.
- Anlisis y Diseo
El objetivo de este flujo de trabajo es traducir los requisitos a una especificacin que describe cmo implementar el sistema. Los objetivos del anlisis y diseo son : Transformar los requisitos al diseo del futuro sistema. Desarrollar una arquitectura para el sistema. Adaptar el diseo para que sea consistente con el entorno de implementacin, diseando para el rendimiento. El anlisis consiste en obtener una visin del sistema que se preocupa de ver qu hace, de modo que slo se interesa por los requisitos funcionales. Por otro lado el diseo es un refinamiento del anlisis que tiene en cuenta los requisitos no funcionales, en definitiva cmo cumple el sistema sus objetivos.
- Implementacin
En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. Adems se deben hacer las pruebas de unidad: cada implementador es responsable de probar las unidades que produzca. El resultado final de este flujo de trabajo es un sistema ejecutable. En cada iteracin habr que hacer lo siguiente: Planificar qu subsistemas deben ser implementados y en que orden deben ser integrados, formando el Plan de Integracin. Cada implementador decide en que orden implementa los elementos del subsistema. Si encuentra errores de diseo, los notifica. Se prueban los subsistemas individualmente. Se integra el sistema siguiendo el plan. La estructura de todos los elementos implementados forma el modelo de implementacin. La integracin debe ser incremental, es decir, en cada momento slo se aade un elemento. De este modo es ms fcil localizar fallos y los componentes se prueban ms a fondo. En fases tempranas del proceso se pueden implementar prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el principio, probar tecnologas o disear la interfaz de usuario. Los prototipos pueden ser exploratorios (desechables) o evolutivos. Estos ltimos llegan a transformarse en el sistema final. 29
- Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida. Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son: Encontrar y documentar defectos en la calidad del software. Generalmente asesora sobre la calidad del software percibida. Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio de demostraciones concretas. Verificar las funciones del producto de software segn lo diseado. Verificar que los requisitos tengan su apropiada implementacin. Las actividades de este flujo comienzan pronto en el proyecto con el plan de prueba (el cual contiene informacin sobre los objetivos generales y especficos de las prueba en el proyecto, as como las estrategias y recursos con que se dotar a esta tarea), o incluso antes con alguna evaluacin durante la fase de inicio, y continuar durante todo el proyecto. El desarrollo del flujo de trabajo consistir en planificar que es lo que hay que probar, disear cmo se va a hacer, implementar lo necesario para llevarlos a cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma que la informacin obtenida nos sirva para ir refinando el producto a desarrollar.
- Despliegue
El objetivo de este flujo de trabajo es producir con xito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen: Probar el producto en su entorno de ejecucin final. Empaquetar el software para su distribucin. Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios. Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos.
Este flujo de trabajo se desarrolla con mayor intensidad en la fase de transicin, ya que el propsito del flujo es asegurar una aceptacin y adaptacin sin complicaciones del software por parte de los usuarios. Su ejecucin inicia en fases anteriores, para preparar el camino, sobre todo con actividades de planificacin, en la elaboracin del manual de usuario y tutoriales. Gestin del proyecto La 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.
30
Ingeniera de Sistemas I Los objetivos de este flujo de trabajo son: Proveer un marco de trabajo para la gestin de proyectos de software intensivos. Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y monitorear el proyecto. Proveer un marco de trabajo para gestionar riesgos. La planeacin de un proyecto posee dos niveles de abstraccin: un plan para las fases y un plan para cada iteracin.
Configuracin y control de cambios

La finalidad de este flujo de trabajo es mantener la integridad de todos los artefactos que se crean en el proceso, as como de mantener informacin del proceso evolutivo que han seguido.
Entorno
La finalidad de este flujo de trabajo es dar soporte al proyecto con las adecuadas herramientas, procesos y mtodos. Brinda una especificacin de las herramientas que se van a necesitar en cada momento, as como definir la instancia concreta del proceso que se va a seguir. En concreto las responsabilidades de este flujo de trabajo incluyen: Seleccin y adquisicin de herramientas Establecer y configurar las herramientas para que se ajusten a la organizacin. Configuracin del proceso. Mejora del proceso. Servicios tcnicos.
El principal artefacto que se usa en este flujo de trabajo es el caso de desarrollo que especifica para el proyecto actual en concreto, como se aplicar el proceso, que productos se van a utilizar y como van a ser utilizados. Adems se tendrn que definir las guas para los distintos aspectos del proceso, como pueden ser el modelado del negocio y los Casos de Uso, para la interfaz de usuario, el diseo, la programacin, el manual de usuario.
31
TCNICAS DE RECOLECCIN DE INFORMACIN

Existen varias tcnicas para capturar requisitos de usuarios, de las cuales examinaremos algunas: 1. La entrevista Dentro de las tcnicas utilizadas para recopilar informacin, las entrevistas ocupan un lugar preponderante en consideracin con el tiempo que ocupan y el objetivo que tienen. Por lo general, son la mayor fuente de informacin del analista. La entrevista es una forma de conversacin, no de interrogacin. Durante la entrevista el analista no se limita solo a informarse de los puntos que le interesan, sino que adems aprovecha la oportunidad para explicar su trabajo a los usuarios y crear un clima sociolgico favorable. Para llevar a efecto una entrevista se deben realizar una serie de pasos y cumplir una serie de reglas para poder asegurar el xito de la misma. Los distintos pasos que se deben realizar son: 1. Preparacin 2. Ejecucin 3. Recapitulacin
a) Preparacin
Se debe coordinar con el usuario la fecha, la hora y el lugar. Se debe garantizar la privacidad, evitar las interrupciones y disponer de un tiempo adecuado. Se deben de obtener criterios previos acerca de las personas que se van a entrevistar para poder desarrollar una conversacin ms natural. Se deben preparar cuidadosamente las preguntas a realizar o la gua de la entrevista.
b) Ejecucin
Se debe ser correcto y no preguntar cosas que se pueden obtener por otras vas a menos que se desee comprobar algo. El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. Se debe ser puntual, identificarse y explicar los objetivos de la entrevista Se debe prestar la mxima atencin durante el desarrollo, crear un clima favorable, evitar caer en discusin con los usuarios, no hacer criticas, utilizar una terminologa adecuada, no adelantarse a ningn criterio ni opinin de 32
Ingeniera de Sistemas I los usuarios y mucho menos sacar conclusiones instantneas sobre la informacin recibida. Diferenciar entre los hechos y las opiniones, entre la actividad o funcin que realiza y el como la realiza, tratando siempre que la informacin recopilada sea lo mas objetiva posible. Evitar que la entrevista sea larga o se convierta en inoportunas por razones imprevistas, si esto ocurre se debe posponer. Al despedirse se debe mostrar agradecimiento y dejar coordinado otro posible encuentro. Al final se debe hacer una pequea recapitulacin de la informacin recopilada para verificar los hechos registrados.
c) Recapitulacin
Se deben revisar las notas para reordenarlas y organizarlas por temas, pasarlas en limpio y comprobar que no existan contradicciones. La recapitulacin de las entrevistas se hace en el modelo Registro de Acuerdos y Observaciones Entrevistado: Juan Perez (Jefe de Almacn) Entrevistador: Ana Garca Sistema Fecha: 3 de Marzo Tema: Realizar un
Objetivos de la Entrevista: Obtener requerimientos del usuario para realizar un sistema de calidad. 1. Cul es su opinin del sistema de computadora actual? 2. Cules son algunos de los problemas que experimenta para recibir informacin a tiempo? 3. Describa el proceso de almacn. 4. Qu reportes genera en un mes? 5. Liste sus dos prioridades mximas para el departamento de almacn? 6. Tiene comunicacin automatizado con los dems departamentos? 7. Qu espera del nuevo sistema a implantar? 2. El Cuestionario. Los cuestionarios constituyen la nica forma posible de poder relacionarse con un gran nmero de personas para conocer varios aspectos del sistema, sin tener que estar presente. Los cuestionarios como medio para recoger opiniones o hacer encuestas pueden ser de gran utilidad si se usa en forma adecuada, o sea, si se aplican en una situacin especifica para la cual fueron diseados especialmente y adems este diseo rene una serie de requisitos. Hay dos formas de cuestionarios: abiertos y cerrados.
33
Ingeniera de Sistemas I Abiertos: Se utilizan par recoger sentimientos, opiniones, referencias. Cerrados: Limitan las respuestas posibles a travs de un estilo cuidadoso en la pregunta.
Respuestas de cuestionario cerrado:

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 los nmeros de cuenta en las facturas: 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
34
Ingeniera de Sistemas I 3. Revisin de documentos Toda entidad debe emitir y archivar un conjunto de documentos de informacin donde aparezcan los indicadores principales de la entidad relacionados con su actividad fundamental. Por lo general las entidades tambin emiten y archivan un conjunto de informes o modelos de inters para el organismo central o ministerio al cual pertenecen. Adems, toda entidad debe tener un Sistema de Contabilidad, un Sistema de Fuerza de Trabajo uno de Abastecimiento, uno de Medios Bsicos, etc. Cada uno de los cuales posee toda la informacin de la entidad sobre esos aspectos especficos. Muchos o todos los indicadores que Ud. necesita deben estar reflejados en estos documentos. Pero muchas veces en los documentos no se refleja exactamente lo que uno quiere buscar y debe hacer un procesamiento de ellos. A pesar de que se haga un anlisis profundo de los documentos, hay indicadores que la entidad no recopila y son sumamente tiles para el analista; entonces, hay que ir a la investigacin o a realizar ciertos experimentos. 4. Investigacin y experimentacin Dentro de los indicadores que son muy importantes para el analista y que la entidad generalmente no posee, estn: El tiempo que se demora realizar cada proceso del sistema actual. La cantidad de errores que se cometen al realizar los procesos del sistema actual. La frecuencia y otros indicadores de algunos documentos. Ciertas normas y consumos. Hay dos cosas que por su importancia nos debemos detener en ellos y es como conocer el tiempo que demora la realizacin de un proceso y la cantidad de errores que se cometen en un proceso que generalmente son cuestiones de inters. 5. Trabajo creativo en grupos
Brainstorming (Tormenta de ideas)

Permite generar gran cantidad de ideas en breve tiempo. Se desarrolla con un Grupo de expertos, idealmente de 8 a 10 personas, an cuando puede variar entre 6 y 12, mantenindose eficacia. Se expone un problema a los presentes, o se les enva un memorndum previo. Las ideas se generan y exponen por los asistentes en forma clara y precisa, evitando discursos, sin que medie ninguna crtica o evaluacin de stas, por descabelladas que pudieran parecer. En esta atmsfera no crtica, las personas se sienten libres para decir lo que piensan y estas ideas, an en el caso de que no tuvieran valor, pueden dar origen a otras por asociacin. Las ideas se recogen y listan en pliegos de papel que se mantienen a la vista de todos. Estas ideas se valoran posteriormente.
35
Ingeniera de Sistemas I La generacin de ideas y su recogida puede realizarse, dependiendo de las caractersticas del Grupo y sus integrantes, segn 3 variantes: 1. Los integrantes dan las ideas espontneamente y se van listando. 2. Se realizan varias rondas, cada integrante lanza una idea en su turno o puede pasar en una ronda. Se van listando las ideas. Se contina el proceso hasta que todos pasen. 3. Una persona que acta como facilitador, pide a los presentes que escriban en una hoja de papel sus ideas. Estas se recogen y organizan en pliegos que se presentan al Grupo, que puede repetir el proceso de generacin de ideas por asociacin con las que se presentan. Merita destacar brevemente el papel que desempea en esta y otras tcnicas el denominado facilitador, que es quien debe propiciar el clima y los resultados ptimos; para ello: No dirige, sino que facilita el trabajo del Grupo, la elaboracin y exposicin de ideas creativamente. Brinda confianza para expresar las ideas, evita ataques, permite y promueve la participacin de todos. No evala, apoya ni se solidariza con ninguna de las ideas. Garantiza la agilidad del desarrollo de la actividad y el logro de sus objetivos. A pesar de ser el brainstorming una poderosa herramienta para la generacin de ideas, pueden presentarse algunas situaciones tales como: Las ideas no son expuestas cuidadosa y rigurosamente. Se monopoliza por uno o varios integrantes del Grupo. La generacin de ideas puede verse frenada por la presencia de uno o varios participantes. Existen conflictos o controversias en el seno del Grupo que pueden influir en la acogida y posterior valoracin de las ideas. En estas situaciones es conveniente la utilizacin de otras tcnicas: Brainwriting (Escritura de ideas), Gallery method ( Galeria de ideas ), Bloc de notas colectivo, Focus Group, etc. 6. Workshop Es un taller propiamente el espacio donde se realiza un trabajo manual o artesano, como el taller de un pintor o un alfarero, un taller de costura o de elaboracin de alfajores, una reunin para levantamiento de informacin, etc.; aunque tambin puede designar otros conceptos derivados a ste.
36
Ejemplo de WorkShop Workshop N 1

Escenario Entrevistado: : Oficina de Administracin
Apellidos y Nombres : Cargo E-mail

Agenda:
Betsy Franco Alva : Administradora General : betsyfranco@hotmail.com
Conocer el funcionamiento general de la empresa. Identificar los procesos que se llevan a cabo en las diferentes reas.
Lugar, fecha y hora de la entrevista:
Lugar : Fecha : Hora Inicio : Hora Fin :
Oficina de Administracin 15 Marzo de 2010 17:30 18:30
Preguntas preliminares:
Cul es el giro de la empresa? Cul es la misin de la empresa? Cul es su visin? Cul es el mercado al cual estn dirigidos sus productos: nacional o internacional? Quines son sus clientes potenciales? Quines son sus proveedores? Quines son la competencia?
Preguntas y respuestas: 1. Qu responsabilidad tiene usted como Administradora General en la empresa? Soy la responsable de todas las reas de la empresa, es decir, velo por el cumplimiento de las funciones que se han asignado a cada empleado. Adems ante cualquier problema que se pudiera presentar soy la responsable directa de solucionarlo de la mejor manera posible.
37
Ingeniera de Sistemas I 2. Podra decirme brevemente a que se dedica la empresa? La empresa naci con la finalidad de comercializar artculos para un bazar, electrodomsticos y juguetes, que son importados. 3. Podra describirme la arquitectura de la empresa? La empresa posee tres reas fundamentales que son Ventas, Compras y Almacn que funcionan de manera conjunta y ordenada supervisadas por Administracin General. 4. Podra describir brevemente los procesos de que se llevan a cabo en cada rea y como los controla? El Departamento De Ventas se encarga de controlar las ventas mediante la recepcin de pedidos, es decir todo el manejo de documentacin que circula en esta rea. El Departamento de Compra se encarga del control de las compras, es decir de todo el manejo de documentacin que se emite en esta rea en lo referente a reabastecimiento de stock. El Departamento de Almacn se encarga del control del almacn, adems de generar listados sobre los productos con sus respectivos cdigos que se requiere para ventas. 5. Actualmente la empresa cuenta con algn sistema que agilice sus operaciones? No. La mayora de ellas se realizan en forma manual y algunas pocas con la ayuda de hojas de clculo. 6. Qu es lo que buscan obtener con la implementacin de un sistema? En todo giro de negocios existen operaciones que se deben realizar con un debido cuidado y con el ms mnimo error para obtener los mayores beneficios, y eso es lo que nosotros buscamos; es por ello que requerimos un sistema que agilice los procesos y los controle, reduciendo al mnimo el tiempo empleado en ello. Adems la empresa tambin requiere la elaboracin de una pgina web que se encargue de marketear los artculos que ofrecemos as como que tambin tenga la caracterstica de enviarnos sus pedidos va correo electrnico, etc.. Eso es lo que buscamos.
38
UML
El UML es una tcnica de modelado de objetos y como tal supone una abstraccin de un sistema para llegar a construirlo en trminos concretos. El modelado no es ms que la construccin de un modelo a partir de una especificacin. Un modelo es una abstraccin de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensin del original y por lo tanto facilita dicha comprensin. Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los msicos representan la msica en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los leos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. Los modelos adems, al no ser una representacin que incluya todos los detalles de los originales, permiten probar ms fcilmente los sistemas que modelan y determinar los errores. Segn se indica en la Metodologa RUP, los modelos permiten una mejor comunicacin con el cliente por distintas razones: Es posible ensear al cliente una posible aproximacin de lo que ser el producto final. Proporcionan una primera aproximacin al problema que permite visualizar cmo quedar el resultado. Reducen la complejidad del original en subconjuntos que son fcilmente tratables por separado. Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes del problema y omite el resto. Los lenguajes de programacin que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificacin total con detalles que no son importantes para el algoritmo que estn implementando. Con la creacin del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, mediante los diagramas, es decir, mediante representaciones grficas que contienen toda la informacin relevante del sistema. Dando una breve introduccin al tema; se puede decir que UML no es una metodologa, si no ms bien es un lenguaje (pero no de programacin), una notacin, que permite visualizar, especificar, construir y documentar el modelado de sistemas; sea cual fuere el ciclo de vida elegido para el anlisis, diseo e implementacin del mismo. UML es de reciente aparicin y, al ser no propietario, es usado y refinado por muchas empresas, grupos de investigadores y desarrolladores a nivel mundial. UML significa Unified Modeling Language: Lenguaje de Modelado o Modelamiento Unificado. El Lenguaje de Modelado Unificado es un lenguaje usado para especificar, 39
Ingeniera de Sistemas I visualizar y documentar los diferentes aspectos relativos a un sistema de software bajo desarrollo, as como para modelado de negocios y otros sistemas no software. Puede ser utilizado con cualquier metodologa, a lo largo del proceso de desarrollo de software, en cualquier plataforma tecnolgica de implementacin (Unix, Windows etc.). Es un sistema notacional (que, entre otras cosas, incluye el significado de sus notaciones) destinado a los sistemas de modelado que utilizan conceptos orientados a objetos. Los principales factores que motivaron la definicin de UML fueron: la necesidad de modelar sistemas, las tendencias en la industria del software, unificar los distintos lenguajes y mtodos existentes e innovar los modelos. 1. DEFINICIONES DE UML El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. Mientras que ha habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. El UML es una tcnica de modelado de objetos y como tal supone una abstraccin de un sistema para llegar a construirlo en trminos concretos. El modelado no es ms que la construccin de un modelo a partir de una especificacin. Un modelo es una abstraccin de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensin del original y por lo tanto facilita dicha comprensin. UML es una consolidacin de muchas de las notaciones y conceptos ms usadas orientados a objetos. Empez como una consolidacin del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas orientadas a objetos ms populares. 2. BREVE RESEA HISTRICA El desarrollo de UML comenz en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation comenzaron a trabajar en la unificacin de los lenguajes de modelado Booch y OMT, desde este momento fueron reconocidos mundialmente en el desarrollo de metodologas orientadas a objetos. As, en octubre de 1995, terminaron su trabajo de unificacin obteniendo el borrador de la versin 0.8 del denominado Unified Method. Hacia fines de este mismo ao, Ivar Jacobson (creador de la metodologa OOSE - Object Oriented Software Engineer) se uni con Rational Software para obtener finalmente UML 0.9 y 0.91 en junio y octubre de 1996, respectivamente. Igualmente, UML incorpora ideas de otros metodlogos entre los que podemos 40
Ingeniera de Sistemas I incluir a Peter Coad, Derek Coleman, Ward Cunningham, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs-Brock y Ed Yourdon. Luego, muchas organizaciones como Microsoft, Hewlett-Packard, Oracle, Sterling Software MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjectTime, Platinum Technology, Ptech, Taskon, Reich Technologies, Softeam se asociaron con Rational Software Corporation para dar como resultado UML 1.0 y UML 1.1. Hoy en da llegamos hasta UML 1.4 y UML 2.0. En la siguiente figura se muestra de forma grfica y resumida la evolucin de UML.
3. CARACTERSTICAS DE UML UML es una especificacin de notacin orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un nmero de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto. UML permite describir un sistema en diferentes niveles de abstraccin, simplificando la complejidad sin perder informacin, para que tanto usuarios, lderes y desarrolladores puedan comprender claramente las caractersticas de la aplicacin. Definicin formal de un metamodelo comn que define el lenguaje para expresar modelos de anlisis y diseo. Un metamodelo se define como un modelo que sirve para expresar otros modelos, y son indispensables para poder definirlos sin ambigedades. 41
El mtodo del UML recomienda utilizar los procesos que otras metodologas tienen definidos. 4. DIAGRAMAS: Vistazo General En todos los mbitos de la ingeniera se construyen modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar, los ingenieros de software deberan igualmente construir modelos de los sistemas software. Para la construccin de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los dems, por lo cual con un nico modelo no tenemos bastante. Varios modelos aportan diferentes vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes. As, UML recomienda la utilizacin de nueve diagramas para representar las distintas vistas de un sistema.
Los diagramas de UML:

Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupndola en descripciones de acciones ejecutadas por un sistema para obtener un resultado. Se utiliza para entender el uso del sistema Diagrama de Clases: muestra las clases (descripciones de objetos que comparten caractersticas comunes) que componen el sistema y cmo se relacionan entre s. Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones. A diferencia de los diagramas anteriores, estos diagramas se enfocan en la perspectiva de casos reales o prototipos. Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Diagrama de Secuencia: enfatiza la interaccin entre los objetos y los mensajes que intercambian entre s junto con el orden temporal de los mismos. Diagrama de Colaboracin: igualmente, muestra la interaccin entre los objetos resaltando la organizacin estructural de los objetos en lugar del orden de los mensajes intercambiados. Diagrama de Estados: Se utiliza para analizar los cambios de estado de los objetos. Muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son tiles en sistemas que reaccionen a eventos. Diagrama de Actividades: Es un caso especial del diagrama de estados, simplifica el diagrama de estados modelando el comportamiento mediante flujos de actividades. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos. Diagrama de Componentes: muestra la organizacin y las dependencias entre un conjunto de componentes. Se usan para agrupar clases en componentes o mdulos. 42
Diagrama de Despliegue (o implementacin): muestra los dispositivos que se encuentran en un sistema y su distribucin en el mismo. Se utiliza para identificar Sistemas de Cooperacin: Durante el proceso de desarrollo el equipo averiguar de qu sistemas depender el nuevo sistema y que otros sistemas dependern de l. 5. Vistas La practica de crear diagramas para visualizar sistemas desde perspectivas o vistas diferentes no est limitado a la industria de la construccin. En el contexto del software, existen cinco vistas complementarias que son las ms importantes para visualizar, especificar, construir y documentar la arquitectura del software. En el UML las vistas existentes son: Vista casos de uso: se forma con los diagramas de casos de uso, colaboracin, estados y actividades. Vista de diseo: se forma con los diagramas de clases, objetos, colaboracin, estados y actividades. Vista de procesos: se forma con los diagramas de la vista de diseo. Recalcando las clases y objetos referentes a procesos. Vista de implementacin: se forma con los diagramas de componentes, colaboracin, estados y actividades. Vista de despliegue: se forma con los diagramas de despliegue, interaccin, estados y actividades.
Como podemos ver el nmero de diagramas es muy alto, en la mayora de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. UML esta pensado para el modelado tanto de pequeos sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar 43
Ingeniera de Sistemas I compuestos por millones de lneas de cdigo y ser realizados por equipos de centenares de programadores. 6. DIAGRAMAS UML 2.0 En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos se clasifica como se muestra en la figura 09.
Diagramas Estticos o Estructurales

- - - - - - Diagrama de Objetos Diagrama de Clases Diagramas de Componentes Diagramas de Estructura compuesta (A partir de UML 2.0) Diagramas de Despliegue Diagramas de Paquetes
Diagramas Dinmicos o de Comportamiento

- Diagrama de mquina de Estado - Diagrama de actividad - Diagrama de Caso de Uso
Diagramas de Interaccin Comportamiento)

- - - -
(Subtipo
de
Diagramas
de
Diagrama de Secuencia Diagrama de Comunicacin Diagrama de Tiempos(A partir de UML 2.0) Diagrama de descripcin la interaccin(A partir de UML 2.0)
Figura _09: Jerarqua de los Diagramas de UML 2.0
44
2
CAPTULO
Modelo de Negocio
Modelo de Caso de Uso del Negocio Modelo de Anlisis del Negocio
MODELO DE NEGOCIO
La necesidad de esta disciplina surge ante el hecho de que muchos de los productos de software que se desarrollan automatizan algunos o todos los procesos existentes en un negocio, y es necesario estudiar las implicaciones de los cambios producidos por la adopcin de estos productos. Hay que entender cmo funciona el negocio que se desea automatizar para tener garantas de que el software desarrollado va a cumplir su propsito y, por esto, se hace un estudio en el dominio del negocio, adems de un dominio del software. Los objetivos del modelado de negocio son: Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado (organizacin objetivo). Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Derivar los requisitos del sistema necesarios para apoyar a la organizacin objetivo. El modelo de negocios es una tcnica para comprender los procesos de negocios de la organizacin. El modelado del negocio est soportado por dos tipos de modelos de UML: Modelo de Casos de Uso del Negocio y Modelos de anlisis del Negocios. El Modelo de Casos de Uso del Negocio describe los procesos de negocio de una empresa en trminos de casos de uso del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes, respectivamente. El modelo de Casos de Uso del Negocio se describe mediante diagramas de casos de uso. El Modelo de anlisis del Negocio es un modelo interno a un negocio. Describe como cada caso de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades del negocio y de entidades de trabajo. Cada realizacin de un caso de uso del negocio puede mostrarse en diagramas en diagramas de interaccin y diagramas de actividad. Una entidad del negocio representa algo, como una factura, que los trabajadores toman, inspeccionan, manipulan, producen o utilizan en un caso de uso del negocio. Una unidad del trabajo es un conjunto de esas entidades que conforman un todo reconocible para un usuario final. Las entidades del negocio y las unidades de trabajo se utilizan para representar los mismos tipos de conceptos que las clases del dominio, como Pedido, Artculo, Factura y Cuenta. Tambin se tendrn otros diagramas para mostrar los trabajadores, sus interacciones y como utilizan las entidades de negocios y las unidades de trabajo.
47
Ingeniera de Sistemas I Cada trabajador, entidad del negocio y unidad de trabajo puede participar en la realizacin de ms de un caso de uso del negocio. Por ejemplo, la clase Cuenta participar probablemente en las tres siguientes realizaciones de casos de uso del negocio: En Gestin de Prstamo: De la Solicitud al Desembolso, el dinero que se adquiere por el prstamo se desembolsa en una cuenta. En hacer Transferencia y Retirar y Depositar Dinero: El dinero se retira o se deposita en cuentas y se transfiere entre cuentas. Ventas: Del Pedido a la Entrega implica la transferencia de dinero de la cuenta del comprador a la del vendedor. Los creadores de RUP sealan que el modelo de negocio est soportado por dos artefactos principales: - Modelo de casos de uso del negocio. - Modelo de anlisis del negocio El conjunto completo de artefactos del modelo de negocio, se muestra en la siguiente figura:
1. Cundo ser necesario hacer el modelo de negocio? Cuando el grupo de trabajo es nuevo en la organizacin. Cuando la organizacin a enfrentado un reciente proceso de reingeniera de negocios. Cuando la organizacin esta planificando un proceso de reingeniera de negocios. Cuando el software a construir ser utilizado por una porcin importante de la organizacin. Existen flujos de trabajo complejos dentro de la organizacin que no estn documentados. 48
Ingeniera de Sistemas I Cuando se es un consultor en una organizacin en la cul no se ha trabajado antes. 2. Cundo no ser necesario hacer el modelo de negocio? Cuando se tiene conocimiento de la estructura de la organizacin, de las metas, de la visin y de los clientes/usuarios. Cuando el software a construir ser usado por una pequea parte de la organizacin, y no tiene un efecto en el resto del negocio. Cuando los flujos de trabajo de la organizacin estn bien documentados. Cuando el tiempo no lo permita, no todos los procesos tienen el tiempo necesario para completar un anlisis del negocio. 3. Actividades para realizar un modelo de negocio Determinar la situacin de la organizacin Describir el actual negocio. Identificar los procesos de negocio Refinar las definiciones de los procesos del negocio. Disear las realizaciones de los procesos del negocio. Refinar roles y responsabilidades Explorar procesos automatizados Desarrollar un modelo de dominio
En este manual, trataremos las actividades ms relevantes que permiten obtener los artefactos principales del negocio.
49
MODELO DE CASO DE USO DEL NEGOCIO

1. Determinar la situacin de la organizacin: El objetivo es reconocer el negocio en estudio para delimitarlo. Las actividades que se llevan a cabo son: Identificar la misin y visin de la organizacin y/o reas de estudio que correspondan y plasmarlo en visin del negocio. Identificar los objetivos del negocio, y documentarlos en objetivos del negocio. Estos objetivos son determinados por los stakeholders y responsables del negocio y sern usados para validar los casos de uso del negocio. Identificar las reglas del negocio y luego plasmarlas en el documento reglas del negocio. Elaborar una lista de trminos y definiciones usados comnmente en un glosario del negocio. Se ha preferido reunir los documentos anteriormente mencionados en el artefacto Situacin del Negocio. 2. Identificar los procesos del Negocio Requiere haber identificado los objetivos del negocio. El equipo de trabajo debe tener claras las fronteras del negocio que est describiendo. Para ello, debe identificar y priorizar los casos de uso del negocio y los actores de negocio involucrados. Para mostrar la interaccin entre actores de negocio y casos de uso de negocio se crea un diagrama general de casos de uso del negocio. Por cada caso de uso del negocio, se realiza una especificacin de caso de uso del negocio, conocido comnmente como BUCS (Business Use Case Specification) por las iniciales en ingls. En este documento, se indica una descripcin breve del proceso de negocio. Para describir los actores del negocio y mostrar mediante un diagrama de casos de uso del negocio su asociacin con los casos de uso de negocio encontrados, se utiliza el artefacto actores del negocio. 3. Refinar las definiciones de los procesos de negocio: a) Detallar la definicin de los casos de uso del negocio. b) Describir cmo los casos de uso del negocio soportan los objetivos del negocio. c) Verificar que los casos de uso del negocio representan correctamente cmo el negocio es conducido. Aqu se refiere a las especificaciones de caso de uso del negocio, describiendo paso a paso las actividades que se desarrollan en el proceso de negocio. 50
MODELO DE ANLISIS DEL NEGOCIO

1. Disear las realizaciones de los procesos del negocio Consiste en identificar todos los roles, productos, entregables del negocio y describir cmo el proceso del negocio ser llevado a cabo por los trabajadores y las entidades dentro del negocio. El documento que plasma la descripcin breve de trabajadores del negocio y cmo ellos manipulan las entidades del negocio es trabajadores del negocio. Adems se crea el artefacto entidades del negocio para describir las entidades del negocio y especificar, mediante diagramas de estado, los estados de cada una de las entidades. Para la realizacin de cada proceso del negocio se crea un diagrama de clases de negocio y un diagrama de actividades de negocio. Al finalizar esta actividad, se completar cada especificacin de caso de uso del negocio generado en el modelado de casos de uso de negocio, agregando al final de cada documento, los diagramas de clases y actividades correspondientes. ESTEREOTIPO DESCRIPCIN 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. Describe un proceso de negocio desde un punto de vista externo que percibe algn tipo de valor.
Representa un rol que algo o alguien externo desempea en relacin con el negocio.
51
Ingeniera de Sistemas I Representa un rol interno al negocio. Colabora con trabajadores de otro sector, es notificado de acontecimientos del negocio y manipula entidades de negocio para realizar sus responsabilidades. Ente manipulado por actores del negocio y trabajadores del negocio. Coleccin de diagramas que describe el aspecto interno de los procesos de negocio (Diagramas de clases y diagramas de actividades). En el Anexo 1 se muestran las plantillas de los documentos que se crean en la disciplina del modelado de negocio en el siguiente orden: Situacin del Negocio Actores del Negocio Especificacin de caso de uso del negocio Trabajadores del Negocio Entidades del Negocio
Como encontrar trabajadores y entidades de Negocio TRABAJADOR DE NEGOCIOS (Business Worker)

Un BW representa un rol jugado por alguien o algo dentro del negocio que realiza alguna actividad dentro del mismo. Un Business Worker (BW): Trabaja en una unidad organizacin. Interacta con otros business worker Manipula entidades de negocios+ Ejemplos
Vendedor
Cajero
Aulxiliar de Almacn
52
Ingeniera de Sistemas I Dnde encontrar Trabajadores de Negocio - BW? Roles dentro del negocio Puestos o cargos dentro de la organizacin Personas que ejecutan los procesos o las actividades de negocio Hardware o sistemas informticos dentro del negocio usados en ese momento.
Sugerencia para identificar adecuadamente los BW: Son roles (humanos, hardware y software), no personas con nombres propios Se encuentra dentro de las fronteras del negocio o campo de accin No deben representar reas, departamentos o partes de una organizacin sino roles en ejecucin. No siempre estn asociados con el nombre de un cargo en la planilla de la organizacin Cada trabajador de participar en al menos un caso de uso de negocio, sino participa en ningn proceso debe ser eliminado del modelo. CheckPoints El nombre y la descripcin deben ser claros y comprensibles (emplear sustantivos) Cada BW debe tener documentada una asociacin con otro BW si se comunican entre s. Cada BW deben de participar en un BUC Cada relacin entre un BW y otros BW o BE debe ser usada en el workflow de algn BUC Cada operacin o actividad de un BW debe ser usada debe ser usada en el workflow de algn BUC. Cada operacin o actividad de un BW debe ser usada en el workflow de algn BUC. ENTIDAD DE NEGOCIO (Business Entity) Este artefacto representa una pieza de informacin significativa que es manipulada por los actores y trabajadores del negocio. Se refiere al estado de la informacin que pasar entre cada capa como un conjunto de datos que la identifican una entidad. Las entidades del negocio de una aplicacin representa entidades reales y adems suelen ser sustantivos, como por ejemplo: Cliente, Nmina, Factura, Depsito, etc. Asimismo, las entidades de negocio son la base para compartir documentos entre los trabajadores del negocio y estas pueden ser utilizadas en diversas Realizaciones de los Casos de Uso del Negocio. Una entidad de negocio representa un conjunto de informacin con propiedades, comportamiento y semntica similares y que es usada, producida o manejada por trabajadores del negocio cuando ejecutan un caso de uso del negocio. Pueden ser tangibles e intangibles.
53
Ejemplos
Dnde encontrar entidades de negocio? Informacin que maneja cada trabajador del negocio Informacin que necesita ser ingresada, validada y consultada o comunicada en cada proceso del negocio. Objetos Fsicos Informes Transacciones Informes Documentos Sugerencias para identificar apropiadamente las entidades de negocio Participa en al menos un caso de uso Puede ser usada por diferentes trabajadores del negocio en varios casos de uso del negocio. Representan documentos, contratos, informacin solicitada, producto, conocimiento, etc. Solo debe ser considerada informacin relevante y persistente al negocio. Identificar los atributos de las clases entidades de negocio Identificar y describir la informacin que caracteriza a la entidad de negocio Informacin o propiedades que aporta la entidad del negocio en la ejecucin de las actividades en que participa. Solo debe considerarse informacin propia de la entidad del negocio descrita y no informacin que pertenezca a otra.
54
CASO DESARROLLADO Segn el flujo de trabajo propuesto desarrolle el modelo de caso de uso. CASO: SISTEMA DE GESTIN ACADMICA Flujo de Trabajo: Flujo bsico 1. El Alumno solicita al Asistente SA realizar un retiro o cambio de horario de un curso. 2. El Asistente SA verifica si el alumno est matriculado en un determinado curso. 3. Si est matriculado en un determinado curso el Asistente SA verifica si la solicitud est dentro de la fecha lmite de presentacin. 4. Si la solicitud est dentro de la fecha lmite, se verifica si corresponde a un retiro o a un cambio de horario. 5. Si es retiro de un curso el Asistente SA registra retiro. 6. Si es un cambio de horario, el Asistente SA muestra los horarios con vacantes disponibles. 7. El alumno selecciona el horario del curso. 8. El Asistente SA actualiza los datos referentes a la matrcula del alumno. Flujos alternativos 9. En el punto ( 3 ) si el alumno no est matriculado es rechazado. 10. En el punto ( 4 )si la solicitud ha pasado la fecha lmite, esta es rechazada. SOLUCIN DEL CASO: a) Actores del Negocio:
55
Ingeniera de Sistemas I b) Casos de uso del Negocio:
c) Diagrama de Caso de uso de negocio:
d) Realizaciones de caso de uso del negocio:
e) Diagrama de clases del negocio:
56
Ingeniera de Sistemas I f) Diagrama de Actividades del negocio
57
CASO PROPUESTOS CASO : Sky La empresa Sky, es una empresa que ofrece paquetes tursticos nacionales de calidad al mejor precio del mercado, que tiene como principal objetivo mejorar la atencin al cliente en un 40%. El proceso comienza cuando el Gerente Comercial ordena al Asistente Viajes la elaboracin de los paquetes tursticos a vender, el Asistente se contacta con empresas operadoras (quienes brindan servicios de hotelera, taxis, tours, etc.) para realizar los servicios que va a tener el paquete turstico. Se debe tener en cuenta que cada paquete de viajes no debe tener ms de 3 destinos para no saturar las visitas y la estancia del viajero sea ms agradable. Los turistas deben de separar los paquetes tursticos con anticipacin por lo menos 1 semana antes del viaje y as la forma de pago ser ms fcil para el turista. El Asistente de Viajes ofrece el paquete elaborado al turista interesado, solicitando los datos para que el Counter evalu disponibilidad de cupos con las empresas operadoras, si hay disponibilidad el Counter realiza reserva y genera la venta. La empresa operadora presenta liquidacin al Jefe de Contabilidad, quien verifica la informacin de la liquidacin y solicita informacin al Jefe de Ventas sobre los servicios adquiridos para comparar la informacin con la liquidacin y est conforme el Jefe de Contabilidad registra liquidacin y efecta el pago.
ELABORAR PAQUETE TURSTICO

Objetivo Innovar la elaboracin de los paquetes en un 30% Flujo Bsico 1. El Gerente Comercial ordena la creacin de paquetes tursticos al Asistente de Viajes. 2. El Asistente de Viajes define especificaciones de paquetes tursticos y elabora propuesta de paquete 3. El Asistente de Viajes presenta propuesta al Gerente Comercial. 4. Si el Gerente Comercial acepta la propuesta el Asistente de Viajes establece los servicios. 5. El Asistente de Viajes busca empresa Operadoras. 6. La Empresa Operadora envan propuesta de servicios al Asistente de Viajes. 7. El Asistente de Viajes evala propuesta de servicios. 8. El Asistente de Viajes selecciona a la empresa operadora. 9. El Asistente de Viajes establece los costos del paquete turstico. 10. El Asistente de Viajes enva la informacin final de los paquetes al gerente comercial y termina el proceso 58
Ingeniera de Sistemas I Flujos Alternativos 11. En el punto 4, si el Gerente Comercial no acepta propuesta se repite el paso 2. 12. En el punto 7 cuando el Asistente de Viajes evala la propuesta de la Empresa.Operadora y ninguna oferta es satisfactoria repite el paso 6.
CASO : Servis
La empresa Servs, es una empresa financiera que desea implementar un sistema que le permite gestionar los procesos del rea de Recursos Humanos (RRHH). El proceso comienza cuando el Jefe de RRHH revisa la solicitud y determina la cantidad de personal que se requiere y elabora un comunicado, con el cronograma para de actividades para la seleccin del personal con sus requisitos. El Jefe de RRHH revisa la relacin y autoriza la entrega al Comit de Evaluacin. Luego el Comit califica las pruebas y determina la relacin de candidatos aptos. El Jefe de RRHH consolida los resultados de las evaluaciones, verifica las referencias laborales, y selecciona al nuevo personal. El personal tiene medidas disciplinarias definidas las cuales se detallan: Sancin: Accin administrativa que castiga a un trabajador por haber cometido alguna falta de carcter disciplinario en el desempeo de sus funciones. Puede ser una amonestacin o suspensin en mayor o menor grado dependiendo de la gravedad de la falta. Amonestacin: Advertencia o llamada de atencin verbal o escrita a un trabajador por haber cometido una falta de carcter disciplinario considerada menor en el desempeo de sus funciones.
MEDIDA DISCIPLINARIA
Objetivo Mejorar el control de los trabajadores en un 70% Flujo Bsico 1. El Jefe de Unidad evala un incidente que involucra a un trabajador. 2. Si el trabajador amerita una sancin el Jefe de Unidad comunica el motivo y el incidente mediante informe al Jefe de RRHH, sugiriendo la sancin que se podra aplicar. 3. El Jefe de RRHH evala el informe sobre el incidente. 4. El Jefe de RRHH consulta el record laboral de amonestaciones y sanciones del trabajador. 5. El Jefe de RRHH segn corresponda, conversa con el trabajador. 6. Al realizar la evaluacin cuando la falta es grave : a. El Jefe de RRHH informa a la Gerencia de Administracin y recomienda 59
Ingeniera de Sistemas I la sancin correspondiente. b. El Gerente de Administracin revisa el informe preparado por el Jefe de RRHH sobre el incidente y, de ser necesario consulta con el Jefe de Unidad. c. El Gerente de Administracin ratifica o modifica la sancin propuesta por el rea de RRHH. d. El Jefe de RRHH comunica al rea de Tecnologa de Informacin para que se tomen las medidas necesarias con el acceso que tiene el trabajador a los sistemas de informacin. e. El Administrador de Redes ejecuta el procedimiento de accesos a usuarios al sistema, redes, internet y servicios. f. El Jefe de RRHH, da inicio al cese por despido o suspensin y registra la sancin. Flujos Alternativos 7. En el punto 2, si el trabajador slo amerita una amonestacin el Jefe de Unidad amonesta verbalmente al trabajador y finaliza el proceso. 8. En el punto 6 cuando la falta no es grave: a. El Jefe de Unidad genera una carta de amonestacin. b. El Jefe de Unidad entrega la amonestacin escrita al trabajador, y entregar el cargo al Jefe de RRHH. c. El Asistente de RRHH archiva en el legajo personal el cargo de la carta de amonestacin entregada al trabajador y registra la sancin. CASO : Empresa ABC La empresa ABC es una empresa financiera que desea implementar un sistema que le permite gestionar los procesos del rea de Recursos Humanos (RRHH). El proceso comienza cuando el Jefe de RRHH realiza una medicin peridicamente del nivel de desempeo de cada trabajador con respecto al cumplimiento de las funciones asignadas. Para ello verifica que se cumpla con los criterios y plazos de la evaluacin establecidos en el Programa de Evaluacin Anual para posteriormente verificar el resultado de la evaluacin y emitir opinin imparcial sobre los casos presentados. Finalmente elabora un Informe de evaluacin para consolidar los resultados en el informe final, y enviarlo al Gerente General indicando las brechas de rendimiento, variables motivacionales. El Jefe de RRHH debido a estos resultados puede tomar la decisin de rotar al personal para controlar la correcta y oportuna alternancia de puesto de trabajo y/o cargo de un trabajador dentro de la organizacin.
ROTACIN DEL PERSONAL

Objetivo Mejorar productividad de los trabajadores en un 60%
60
Ingeniera de Sistemas I Flujo Bsico 1. El Jefe de RRHH elabora el Plan de Rotacin Anual del personal en base a las necesidades y polticas de recursos humanos. 2. El Jefe de RRHH coordina con los jefes involucrados y con el trabajador. 3. El Jefe de RRHH solicita a la Gerencia General la aprobacin de dicho Plan. 4. El Gerente General revisa y aprueba el Plan de Rotacin de Personal. 5. El Jefe de RRHH hace seguimiento al Plan de Rotacin de Personal o la Solicitud de Rotacin. 6. Si hay solicitud de rotacin por el trabajador/Jefe de Unidad, el Jefe de RRHH evala el caso y coordina con el trabajador y los Jefes de las Unidades involucradas, considerando las polticas de rotacin del personal. 7. El Jefe de RRHH si aprueba la solicitud presenta el informe de rotacin de personal al Gerente de Administracin. 8. Gerente de Administracin verifica y aprueba el informe de Rotacin de Personal 9. El Jefe de RRHH registra condiciones de rotacin y aprueba 10. El Jefe de RRHH ingresar toda la informacin correspondiente para el cambio de perfil del trabajador Flujos Alternativos 11. En el Punto 6 Si no hay solicitud se pasa al punto 9. 12. En el Punto 7 el Jefe de RRHH no aprueba la solicitud de rotacin informar al trabajador o al responsable que solicit la rotacin del personal y continua con el punto 9. CASO INTEGRADOR GESTION DE RECURSOS HUMANOS El proyecto est orientado al desarrollo de un Sistema de Recursos Humanos para la Empresa Financiera ABC, con la finalidad de automatizar sus procesos. El rea de Recursos Humanos (RRHH) de la financiera desea implementar un sistema que le permita gestionar los siguientes procesos que administra: 1. Planeamiento de RRHH 2. Seleccin de Personal 2.1. Reclutamiento y Seleccin 2.2. Contratacin e Induccin 3. Desarrollo del Personal 3.1. Plan de desarrollo 3.2. Capacitacin 3.3. Evaluacin de desempeo 3.4. Rotacin de Personal
61
Ingeniera de Sistemas I 4. Mantenimiento de Personal 4.1. Legajo de Personal 4.2. Pago de Remuneraciones 4.3. Medidas Disciplinarias 4.4. Cese por despido 4.5. Cese por Renuncia 4.6. Cese por Tiempo de Servicio. El proyecto desarrollara 2 procesos: Medidas Disciplinarias Y Contratacin de Personal: 1. Especificacin del caso de uso del negocio 2. La Realizacin de los caso de uso del negocio 3. Identificacin de actores y casos de uso de cada negocio 4. Diagrama de caso de uso (inicial) del proceso analizado.
ESTRUCTURA DEL MODELAMIENTO EN RATIONAL ROSE 1. Trazabilidad del Modelo del Negocio al Modelo de Casos de Uso:
A continuacin se detalla la especificacin de caso de uso del negocio Medidas Disciplinarias utilizando la plantilla de RUP. ESPECIFICACIN CASO DE USO DEL NEGOCIO: MEDIDAS DISCIPLINARIAS Breve Descripcin: El proceso permite realizar y/o coordinar las acciones necesarias para disciplinar a un trabajador con amonestaciones o sanciones. Flujo Bsico: 1. El Jefe de Unidad evala un incidente que involucra a un trabajador. 2. Si el trabajador slo amerita una amonestacin. 2.1 El Jefe de Unidad amonesta verbalmente al trabajador y finaliza el proceso. 3. Si el trabajador amerita una sancin: 3.1 El Jefe de Unidad comunica el motivo y el incidente mediante informe al Jefe de RRHH, sugiriendo la sancin que se podra aplicar. 4. El Jefe de RRHH evala el informe sobre el incidente. 5. El Jefe de RRHH consulta el record laboral de amonestaciones y sanciones del trabajador. 6. El Jefe de RRHH segn corresponda, conversa con el trabajador. 62
7. De la evaluacin, si la falta no es grave: 7.1. El Jefe de Unidad genera una Carta de Amonestacin. 7.2. El Jefe de Unidad entrega la amonestacin escrita al trabajador, y entregar el cargo al Jefe de RRHH. 7.3. El Asistente de RRHH archiva en el legajo personal el cargo de la Carta de Amonestacin entregada al trabajador y registra la sancin. 8. Si la falta es grave: 8.1. El Jefe de RRHH informa a la Gerencia de Administracin y recomienda la sancin correspondiente. 8.2. El Gerente de Administracin revisa el informe preparado por el Jefe de RRHH sobre el incidente y, de ser necesario consulta con el Jefe de Unidad. 8.3. El Gerente de Administracin ratifica o modifica la sancin propuesta por el rea de RRHH. 8.4. El Jefe de RRHH comunica al rea de Tecnologa de Informacin para que se tomen las medidas necesarias con el acceso que tiene el trabajador a los sistemas de informacin. 8.5. El Administrador de Redes ejecuta el procedimiento de Accesos a Usuarios al Sistema, Redes, Internet y Servicios. 8.6. El Jefe de RRHH, da inicio al cese por despido o suspensin y registra la sancin. 8.7. Si la decisin fue una suspensin 8.7.1. El Jefe de RRHH genera la Carta de Suspensin al trabajador. 8.7.2. El Jefe de RRHH entrega la Carta al trabajador con copia al Ministerio de Trabajo y Promocin del Empleo en caso sea necesario, de acuerdo a las polticas de personal. 8.7.3. El Trabajador recibe y firmar el cargo de recepcin de la Carta de Suspensin. 8.7.4. El Asistente de RRHH registra la informacin de suspensin y archiva el cargo por la entrega de la Carta de Suspensin al trabajador. 8.8. Si la decisin fue un Cese por despido: 8.8.1. El Jefe de RRHH procede con el despido del trabajador (Ver Proceso de Cese por Despido). 63
Ingeniera de Sistemas I Flujos Alternativos No aplica. Para estructurar el Modelo de casos de Uso del Negocio y Modelo de Anlisis ver las figuras 1 y 2. En el Modelo de Casos de Uso del Negocio crear las carpetas: actores del negocio, casos de Uso del Negocio y Metas. Posteriormente hacer el Diagrama de caso de uso del negocio, como se muestra en la figura 3. En el Modelo de Anlisis del Negocio crear las carpetas: Trabajadores del negocio, Entidades del Negocio y realizaciones de casos de Uso del Negocio. Ver la figura No. 4. En la carpeta realizaciones CUN hacer el Diagrama de Actividades, para el proceso Medidas Disciplinados, como se muestra en la figura No. 5. Note que el Diagrama de actividades muestra paso a paso las actividades que realizan cada uno de los Actores o Trabajadores del Negocio. Las actividades que se van a automatizar se colocan de color amarrillo. Una vez identificados los casos de uso con sus roles a automatizar procedemos a la Captura de Requerimientos como casos de uso. Para estructurar el Modelo de casos de Uso del sistema ver la figuras 6. Luego haremos el diagrama de caso de uso del sistema, como se muestra en la figura 7.
Figura No 1 Estructura del Modelo de Casos de Uso del Negocio (MCUN)
64
Figura No 2 Estructura del Modelo de Anlisis del Negocio (MAN).
Figura No. 3. DCUN MEDIDAS DISCIPLINARIAS
65
Figura No. 4 TRABAJADORES DEL NEGOCIO
66
Figura No. 5. DIAGRAMA DE ACTIVIDADES MEDIDAS DISCIPLINARIAS
67
Figura No. 6. Estructura MCU
Figura No. 7. DCU Medidas Disciplinarias
68
2. Modelo de Casos de Uso sin trazabilidad del Modelo del Negocio:

Si nosotros describimos un proceso sin utilizar la plantilla de Especificacin de Caso de Uso, lo veramos as. Lo ideal es tener la plantilla y hacer su diagrama de actividades, para poder identificar claramente los actores y casos de uso del sistema. PROCESO: Seleccin de Personal Para el reclutamiento y seleccin el Gerente de un rea, se ha solicitado personal al Jefe de Recursos Humanos (RRHH), especificando el perfil del cargo. El Jefe de RRHH revisa la solicitud y determina si la cantidad de personal est contemplado en el presente ao. Si no lo est, lo enva al Gerente de Administracin para su aprobacin. Luego, revisa y determinar si el personal de la empresa puede formar parte de la seleccin para cubrir la vacante. Elabora un comunicado, con el cronograma del proceso de Seleccin y sus requisitos y lo enva por escrito o correo al Asistente Social. El Asistente Social convoca al concurso, utilizando los siguientes mecanismos: pgina web y aviso en el peridico o en las bolsas de trabajo de las universidades. Luego, recepciona el currculo vitae de los postulantes y registra aquello que tienen el perfil solicitado. Por ltimo, confecciona la relacin de candidatos preseleccionados y lo remite al Jefe de RRHH. El Jefe de RRHH revisa la relacin y autoriza la entrega al Comit de Evaluacin. El Comit de Evaluacin elabora la prueba de conocimientos, la cual es tomada por el Asistente de Recursos Humanos. Luego el Comit califica las pruebas y determina la relacin de candidatos aptos. El Asistente Social comunica va telefnica a los candidatos aptos para la evaluacin psicolgica respectiva. El psiclogo los evala y enva un informe al Jefe de RRHH con el resultado de los candidatos finalistas. El Jefe de RRHH consolida los resultados de las evaluaciones, verifica las referencias laborales, a la Central de Riesgos, RENIEC, antecedentes policiales, base de datos de personas negativas, etc. Luego elabora el cronograma de entrevistas y entrega al Asistente Social. El Comit entrevista a los candidatos, elabora un Acta de Seleccin y la suscribe. Por ltimo, el Jefe de RRHH comunica a los postulantes los resultados finales. Una vez seleccionado los candidatos, se da inicio al proceso de contratacin e induccin de personal. El Asistente Social entrega la carpeta de bienvenida al personal nuevo o personal promovido al nuevo cargo. Si se trata de una contratacin a plazo indeterminado: 69
Ingeniera de Sistemas I El Jefe de RRHH genera un memorando de Plazo Indeterminado de Trabajo y lo enva a la Gerencia de Administracin. El Gerente de Administracin firma el memorando y lo enva al Asistente Social para que entregue una copia al trabajador. Si es a plazo determinado: El Jefe de RRHH genera el contrato en tres (3) copias y lo enva a la Gerencia de Administracin. El Gerente de Administracin firma el Contrato y el Asistente Social enva tres (3) copias de Contrato de Trabajo al Ministerio de Trabajo y Promocin del Empleo. El Tutor o Jefe inmediato elabora, revisa y aprueba el Plan de Induccin en coordinacin con el Jefe de RRHH. Prepara la carpeta de Induccin con el cdigo de tica, reglamento interno, MOF, manual de polticas y reglamentos y/o manuales (segn el cargo). El proceso de Induccin se realiza en dos (2) etapas. Primero se capacita todo lo relacionado a la empresa y despus las funciones del cargo ocupado. El Trabajador inicia el trabajo de campo, que consiste en la aplicacin prctica de lo aprendido con la supervisin del tutor, el que evala y presenta un informe indicando el resultado de la induccin. El Gerente de rea evala el informe y presenta un informe al Jefe de RRHH. El Jefe de RRHH evala el informe y entrega al Asistente para su archivo. Luego, comunica al trabajador los resultados de la induccin. Si es favorable el informe, se emite un nuevo contrato, sino se emite la liquidacin de beneficios sociales. Para estructurar el Modelo de casos de Uso del Negocio agregar los Actores y Casos de Uso del Negocio y completar con el Diagrama de CUN, como se muestra en la figura No. 8. En la carpeta realizaciones CUN no se har el Diagrama de Actividades, para el proceso Capacitacin del Personal. En el Modelo de casos de Uso del sistema adicionar los actores y casos de uso del sistema. Posteriormente hacemos el diagrama de caso de uso del sistema, como se muestra en las figuras 9 y 10. Se recomienda trabajar con paquetes para cada subsistema.
70
Figura No. 8. DCUN SELECCIN DE PERSONAL
71
Figura No. 9 DCU Seleccin de Personal (Inicial)
72
Figura No. 10 DCU Seleccin de Personal (estructurado)
73
Ingeniera de Sistemas I Finalmente documentamos los artefactos creados para este proceso en el rational, como se detalla a continuacin. Identificacin y documentacin de Actores a. Gerente de rea.- Gerente de cualquier rea de la empresa que solicita incorporar personal para cumplir con sus funciones. b. Jefe de RRHH.- Encargado del rea de RRHH, que tiene como unas de sus funciones el Reclutamiento y Seleccin de Personal; y la Induccin y Contratacin de los mismos. c. Asistente Social.- Personal del rea de RRHH que apoya en el Proceso de Reclutamiento y Seleccin. d. Evaluador Psicolgico.- Personal encargado de la evaluacin Psicolgica de los Postulantes. e. Postulante.- Usuario que cumple el perfil y cargo y solicita ser considerado Postulante en el proceso de seleccin. f. Comit Evaluador.- Personas encargadas de tomar la prueba de conocimientos y entrevistas a los postulantes. Identificacin y documentacin de casos de Uso Proceso de Reclutamiento y seleccin de Personal a. Solicitar Personal.- Permite a cualquier Gerente de rea solicitar personal segn el cargo y perfil. b. Consultar Cuadro de asignacin de Personal.- Permite al Jefe de RRHH verificar el Plan Anual de Contratacin de Personal para c/u de las reas de la empresa. c. Elaborar Cronograma Seleccin.- Permite elaborar el cronograma para el proceso de seleccin, indicando los requisitos para el Postulante. d. Consolidad Resultados de Evaluaciones.- Permite resumir el resultado de las evaluaciones que tienen los postulantes. e. Verificar Referencias Personales.- Permite al Personal de RRHH verificar informacin del Postulante, Consulta a RENIEC, BD Negativas, otras. f. Elaborar Cronograma Entrevistas.- Permite elaborar el cronograma para las Entrevistas a los Postulantes. g. Registrar Postulantes.- Permite al personal de RRHH registrar los datos de los postulantes que cumplen los requisitos para el cargo (perfil), adems de listar los candidatos pre-seleccionados. 74
Ingeniera de Sistemas I h. Elaborar Prueba.- Permite al personal del Comit Evaluador preparar la prueba de conocimientos. i. Listar Candidatos.- Permite al Comit Evaluador, listar los candidatos aptos a Contratar despus de la Prueba de Conocimientos o Entrevista. j. Registrar Evaluacin Psicolgica.- Permite al Psiclogo registrar la evaluacin y listar los candidatos finalistas para la Entrevista Personal. k. Enviar CV (Web).- Permite a una persona enviar su CV, para ser aceptado como postulante. Proceso de Induccin y Contratacin: l. Generar Memo CPI.- Permite al Jefe de RRHH generar un Memo para Contrato a Plazo Indeterminado. m. Generar Contrato.- Permite al Jefe de RRHH generar un contrato para Contrato a Plazo Fijo. n. Emitir Liquidacin.- Permite al Jefe de RRHH emitir la liquidacin de beneficios sociales a un trabajador de la empresa. Incluidos Extendidos o. Buscar Trabajador.- Caso de uso incluido que permite buscar los datos de un trabajador. p. Buscar cargo.- Caso de uso incluido que permite buscar el cargo al que se postula un trabajador. q. Registrar Nuevo cargo.- Caso de uso extendido que permite registrar un nuevo cargo dentro de las funciones del personal de la empresa.
75
76
3
CAPTULO
Modelo de Requerimientos
MODELO DE REQUERIMIENTOS
Esta disciplina de Modelo de Requerimientos es desarrollar un modelo da el sistema que se va a construir. La utilizacin de los casos de uso es una forma adecuada de crear este modelo. Requerimientos: Es una condicin o capacidad a la que la aplicacin o el sistema (siendo construido). Un requerimiento de software o aplicacin puede ser definido como: a. Una capacidad de software necesaria por el usuario para resolver un problema o alcanzar un objetivo. b. Una capacidad de software que debe ser reunida o poseda por un sistema o componente del sistema para satisfacer un contrato, especificacin, estndar, u otra documentacin formal. Naturaleza de la Especificacin de Requisitos de Software. Se deben especificar los siguientes aspectos: a. b. c. d. e. Funcionalidad Interfaz Externa Rendimiento Atributos Restricciones de diseo
Ambiente de la Especificacin de Requisitos. Debe de estar descrita de tal manera que no describa aspectos del rea de diseo o de implementacin. Caractersticas de los Requisitos. Los requisitos descritos deben ser: a. b. c. d. e. f. g. Completos Implementacin Independiente Consistente y no Ambiguo Preciso Verificable Que pueda ser ledo Modificable
Aprobacin del Cliente o patrocinador. Todos los requistos descritos deben contar con ella. Un punto importante a tener en cuenta es la evolucin de los mismos y proveer mecanismos que permitan la Evolucin de la Especificacin de Requisitos, e incluir requisitos del Proyecto en la Especificacin de Requisitos. 79
Ingeniera de Sistemas I Requisitos tales como: a. Costo b. Fecha de Entrega c. Criterios de Validacin y Verificacin Requerimientos, que representan: Los requerimientos de usuarios representan el conjunto completo de resultados a ser obtenidos utilizando la aplicacin o sistema. Los requerimientos de la aplicacin deben mostrar todo lo que la aplicacin o sistema debe hacer, ms todas las restricciones sobre funcionalidad. Los requerimientos forman un modelo completo, representando la aplicacin o sistema total a algn nivel de abstraccin. Si un producto no es lo que el cliente o los usuarios quieren entonces la calidad de la construccin es irrelevante. El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios que se necesita de un sistema. Proveer los requerimientos forma parte de un lenguaje que todos comprenden, ya que todos estn involucrados, incluyendo los clientes. El primer y bsico rol de los requerimientos es por lo tanto la comunicacin. Buena Especificacin de Requerimientos: Un resultado primario de esta administracin es la Especificacin de Requerimientos, la cual define y documenta en forma completa el comportamiento externo del sistema a ser construido. Caracterizndose por: Definidos sin ambigedad Son completos Tienen consistencia Especifica el origen Evita detalles de diseo Estn enumerados
Beneficios de una Buena Administracin de Requerimientos Mejor control de proyectos complejos Mejora en la calidad del software y en la satisfaccin del cliente Reduccin en los retrasos y en los costos del proyecto Mejora en la comunicacin del equipo Facilita la conformidad con estndares y regulaciones
Los Problemas de la Administracin de Requerimientos No son siempre obvios y tienen muchas fuentes. No son siempre fciles de expresar en palabras. Hay muchos tipos diferentes a distintos niveles de detalle. El nmero puede llegar a ser inmanejable. Estn relacionados a otros en una variedad de formas. 80
Ingeniera de Sistemas I Hay muchos interesados y partes responsables. Pueden ser sensibles al tiempo El Alto Costo de Errores en los Requerimientos Hay fuertes evidencias que una efectiva administracin de requerimientos conducen los ahorros del proyecto integral. Las tres razones primarias para esto son: a. Costos de reparar errores en los requerimientos superan en mas de 10 veces a otros errores. b. Errores de requerimientos comprenden encima del 40% de todos los errores de un proyecto de software. c. Pequeos reducciones en el nmero de errores de requerimientos rinden grandes dividendos al evitar costos de re-trabajo y das de retraso. Captura de requisitos: Los requerimientos pueden ser adecuadamente capturados y comunicados a travs de Casos de Uso Los Casos de Uso son importantes instrumentos de planificacin
Tipos de requerimientos:
1. Requerimientos Funcionales Describen la funcionalidad o los servicios que se espera proveer el sistema. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del 81
Ingeniera de Sistemas I sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc. Ejemplo - Sistema de Biblioteca 1. El usuario deber tener la posibilidad de buscar referencias bibliogrficas en el conjunto inicial de la base de datos o seleccionar un sub conjunto de ella. 2. El sistema deber proveer visores adecuados para que el usuario lea documentos en el almacn de documentos. 3. A cada pedido se le deber asignar un identificador nico que el usuario podr copiar al rea de almacenamiento permanente de la cuenta. 2. Requerimientos No Funcionales Son aquellos requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema, como la capacidad de los dispositivos de entrada/salida y la representacin de datos que se utiliza en las interfaces del sistema. Sin embargo, estos requerimientos no siempre se refieren al sistema de software a desarrollar Ejemplos: Anlisis de la especificacin de Requerimientos El sistema de biblioteca puede almacenar documentos en diferentes formatos y la intencin de este requerimiento es que los visores para todos estos formatos estn disponibles. Sin embargo, el requerimiento es ambiguo puesto que no clarifica que los visores para cada formato deban ser provistos. Un desarrollador bajo la presin del tiempo sencillamente podra proporcionar un visor de texto y afirmar que se ha cumplido el requerimiento.
82
Ingeniera de Sistemas I MTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO FUNCIONALES
Identificacin de Requerimientos y Reglas del Negocio Para identificar los requerimientos correctos del negocio primero debemos de comprender como funciona, es decir cuales son las reglas del negocio. Mientras ms complejo es el sistema una mayor cantidad de vistas del mismo son necesarias para comprender su funcionamiento. Las distintas vistas del negocio pueden conseguirse a travs de un mapeo de la situacin actual utilizando a un alto nivel: a. b. c. d. e. f. El Diagrama de descomposicin funcional o mapeo de procesos. Las cadenas de responsabilidad para la atencin de los requerimientos Los Diagramas de Actividad Los Diagramas de Colaboracin Los Diagramas de Interaccin de Roles Casos de Uso del Negocio
MATRIZ DE CONSISTENCIA: Se trata de un instrumento sumamente til para estudiar la relacin causa-efecto que debe existir entre el propsito buscado por un proyecto, los resultados especficos que harn posible el cumplimiento del propsito y las actividades que subyacen y anteceden al cumplimiento de los objetivos anteriores. La matriz permite identificar varios resultados a la vez, los cuales deben guardar una relacin de causalidad con el propsito. Si no se puede demostrar fehacientemente
83
Ingeniera de Sistemas I esa relacin en forma directa, es posible que el resultado que se est planteando obtener con el proyecto no va a incidir con fuerza en el propsito y por lo tanto tampoco hay garanta de que llegue a cumplirse. En este caso, de llegarse a esa conclusin y estando ya definido el propsito, lo mejor es replantear el tipo de resultado que se est buscando. Asimismo, la matriz permite ubicar todas las actividades que se plantean como necesarias para dar cumplimiento a los resultados. Es posible que varias actividades guarden relacin causa-efecto con ms de un resultado a la vez, pero esto es un valor agregado. Lo primero que debe hacerse es determinar, segn cada resultado especificado en la matriz, cules son las actividades necesarias y que directamente le van a afectar en una relacin causa-efecto. Cuando se halla determinado la validez de esa relacin, se puede pasar a identificar a que otros resultados va a contribuir a lograr dicha actividad en forma directa, es decir tambin como un factor de causa-efecto. Sin embargo, es posible hacer una diferenciacin con puntajes asignados al grado de influencia directa que lograr una actividad sobre uno o ms resultados, entendindose que el valor ms alto se corresponde con el resultado donde el impacto va ser mayor. Adicionalmente, la matriz permite sumar en forma vertical, el total de actividades que requiere un resultado para hacerse realidad. Y por otro lado, permite la suma horizontal de los resultados que son impactados en una relacin causa-efecto por una misma actividad, identificndose as la importancia de una actividad por la cantidad de resultados a los que va a beneficiar. Hay que tener en cuenta que difcilmente un resultado esperado es originado por un solo elemento activo, requirindose uno o ms factores complementarios. Es decir, varias variables son generalmente las causantes de lograr un buen resultado, o de generar un problema. Descripcin de Actores del Sistema Se le llama Actor a toda entidad externa al sistema que guarda una relacin con este y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero tambin incluye a todos los sistemas externos as como a entidades abstractas como el tiempo. En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o ms Actores. Suele suceder sin embargo, que es el sistema quien va a tener inters en el tiempo. Es frecuente encontrar que nuestros sistemas 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 caso de uso final. Ejemplo de matriz de descripcin de actores:
84
Ingeniera de Sistemas I ACTOR Gerente ASIGNADO A: Gerente general de la empresa RESPONSABILIDAD Responsable de la produccin de cada uno de los factores de la empresa. Responsable en el seguimiento de documentos faltantes entregados por los clientes. Responsable en armar los equipos para el da. Responsable en recepcionar y coordinar los servicios para efectuarlos a un da determinado.
Administracin
Administracin de los procesos finales de los Servicios. Se encarga del orden de los trabajos y equipos.
Jefe de coordinacin
Atencin al cliente
Recepcionista
En ingeniera del software, un caso de uso es una tcnica para la captura de requisitos potenciales de un nuevo sistema o una actualizacin de software. Cada caso de uso proporciona uno o ms escenarios que indican cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especfico. Normalmente, en los casos de usos se evita el empleo de jergas tcnicas, prefiriendo en su lugar un lenguaje ms cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. Ejemplo: Nro. C_01 C_02 C_03 Caso de Uso Registrar vendedor DTV Registrar cliente Registrar servicio Registrar Gnesis detalle del Descripcin Se registra cuando es nuevo. Se registra cuando es nuevo. Se registra direccin, telfonos, tipo de servicio, etc. Se registra el cdigo de la empresa GENESIS, cuando el servicio es por GARANTIA propia de la empresa. Se graba toda informacin brindada por el cliente.
C_04
vendedor
C_05
Registrar servicio
85
Ingeniera de Sistemas I Se registra la informacin brindada por el cliente. Se actualizan los datos de la extranet corregidos por el propio cliente. Se asigna el equipo creado segn el da.
C_06
Coordinar servicio con cliente Actualizar datos del cliente Asignar equipo
C_07 C_08
Integracin de los Casos de Uso y de Actores El Lenguaje de Modelado Unificado define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso. Ejemplo de Integracin de los Casos de Uso y de Actores:
86
Ingeniera de Sistemas I Matriz de Caso de Uso y Requerimiento Funcional
MODELO DE CASO DE USO Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea. Diagrama de Contexto que delimita al Sistema de informacin. Consolida los mltiples Casos de Uso. Se puede optar por graficar de forma que se destaque: Los CU desde una visin funcional del negocio. (Podran convertirse en SubSistemas). Los CU utilizados por un Actor Incluir breve descripcin Incluir todos los actores El Glosario de Trminos nos sirve para darle consistencia a todo el modelo Podemos agrupar los CU en Paquetes en mltiples jerarquas .
Actor: Un actor es un agente, alguien o algo que solicita un servicio al sistema o acta como catalizador para que ocurra algo. Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores. 87
Caso de Uso: Representa un proceso o un requerimiento solicitado por los usuarios el cual debe ser satisfecho por el analista programador. Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso debajo de l. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema.
1. Qu es estructurar? Separar en partes el CU para hacer menos CU Para que? a. Simplificar el CU original b. Fcil entendimiento y mantenimiento c. Reutilizar el comportamiento d. Compartir entre los CU 88
Relaciones
Figura No. 1. Relaciones entre casos de uso
2. Relacin <<Include>> Dependencia entre 2 CU. CUB depende del CUI CUI ocurre obligatoriamente en el CUB. Al CUB le interesa el resultado del CUI Se extrae comportamiento comn del CU y simplifica CU complejo CUI es ABSTRACTO, es decir slo ocurre en el contexto de otro No puede ser iniciado de forma independiente por un Actor.
Figura No. 2. Relacin Include
CU: Retirar Dinero Flujo Bsico 1. El sistema incluye Identificar Cliente 2. El sistema muestra opciones 3. El Cliente selecciona Retirar Dinero CU: Identificar Cliente Flujo Bsico 1. Insertar tarjeta 2. Validad tarjeta 3. Ingresa PIN 4. Verifica PIN Flujos Alternativos 89
A1. No es vlida la tarjeta A2. Mal el PIN
3. Relacin <<Extend>> Dependencia entre 2 CU. CUE depende del CUB CUE ocurre excepcionalmente (opcional) en el CUB CUB interesa el resultado del CUE Extrae comportamiento opcional y simplifica un CU complejo CUE es ABSTRACTO En ocasiones puede ser iniciado de forma independiente por un Actor.
Figura No. 3. Relacin Extend
CU: Retirar Efectivo Flujo Bsico 1. El ATM (sistema) incluye Identificar Cliente 2. El ATM muestra opciones 3. El Cliente selecciona Retirar Efectivo 4. El Cliente ingresa cuenta y monto 5. El ATM enva transaccin al Consorcio del Banco 6. El ATM recibe informacin 7. El ATM muestra opciones 8. El ATM dispensa billetes 9. El ATM devuelve la tarjeta 10. El ATM imprime el Voucher y el CU finaliza. Puntos de extensin: En el punto 7 del FB, si el Cliente selecciona Moneda el CU se extiende al CU Retirar Moneda. CU: Retirar Moneda
90
Ingeniera de Sistemas I Breve Descripcin Este CU es extensin del CU Retirar Efectivo. Flujo Bsico 1. 2. 3. 4. El Cliente ingresa el Tipo y nmero de monedas el ATM calcula el total del retiro y solicita confirmacin El Cliente acepta El ATM dispensa las monedas y el CU finaliza.
Flujos Alternativos A1. No existen Monedas 4. Relacin <<Generalization>> entre Casos de Uso: Relacin de un CUH (hijo) con un CUP (padre). Describe el comportamiento general compartido por el padre. Describe el comportamiento especializado en el Hijo.
Figura No. 4. Relacin Generalization Casos de Uso
Comprobar Contrasea: Validacin de contrasea Scanear Retina: Validacin de puntos de retina 5. Relacin <<Generalization>> entre Actores Actores con caracterstica comunes.
91
Figura No. 5. Relacin Generalization Actores
ESPECIFICACIN DE CASO DE USO No existe estndar UML para una especificacin de caso de uso, sin embargo una plantilla para una especificacin sencilla de caso de uso utilizada comnmente contiene la siguiente informacin: - - - - - - - - - Nombre del caso de uso. Breve descripcin. Actores implicados en el caso de uso Flujo de eventos Pre-Condiciones Post-Condiciones Puntos de extensin Requisitos especiales Prototipos
EJEMPLO DE ESPECIFICACIN DE LOS CASOS DE USO DEL SISTEMA Especificacin de Caso de Uso: Listar Pedidos: 1. Breve Descripcin: El caso de uso permite administrar los pedidos de mercancas al almacn. La atencin a los pedidos se realiza mientras se encuentren en estado No Atendidos o En Atencin. 2. Flujo de Eventos: Evento disparador.- El caso de uso comienza cuando el Tcnico de Almacn (TA) selecciona la opcin Lista de Pedidos en la interfaz principal del sistema. 92
2.1. Flujo Bsico 1. El sistema incluye el caso uso Buscar Usuario. 2. El sistema muestra la interfaz LISTA DE PEDIDOS. La interfaz muestra la Lista de Pedidos en los estados No Atendidos, En Atencin, Listos para Envo y Enviados. Las listas contienen los datos: cdigo, fecha de elaboracin y fecha llegada al almacn. Incluye las opciones: Atender, Consultar, Cancelar o Salir. 3. El TA selecciona un pedido de la lista de pedidos No atendidos o En Atencin. 4. Si el TA selecciona Atender Ir al Sub Flujo Atender Pedido. 5. Si el TA selecciona Consultar Ir al Sub Flujo Consultar Pedido. 6. Si el TA selecciona Cancelar Pedido Ir al Sub Flujo Cancelar Pedido. 7. Si el TA Selecciona Salir El sistema cierra la interfaz principal y el caso de uso termina. 2.2. Sub Flujo Atender Pedido: 1. El sistema muestra la interfaz ATENDER PEDIDO. En la interfaz se muestran los Datos del usuario: cdigo y nombre, los Datos del pedido: el cdigo del pedido, fecha de llegada al almacn, fecha de atencin, direccin de envo y la Lista de productos que contiene la orden: cdigo del artculo, descripcin, cantidad solicitada, cantidad asignada, stock real, stock disponible, stock asignado. Muestra las opciones Guardar, Pasar a Envos, Incidencias y Salir. 2. El TA almacn selecciona una lnea de pedido (producto) para editarla. Para cada lnea de pedido el TA puede cambiar la cantidad asignada del stock disponible en el almacn. 3. El sistema comprueba si hay stock suficiente en el almacn y reserva el stock del almacn. 4. Si el TA decide modificar otra lnea de pedido, vuelve al punto 2. 93
5. Si el TA selecciona Guardar. El sistema guarda la orden de pedido en estado En Atencin, muestra mensaje Pedido en atencin y cierra la interfaz ATENDER PEDIDO. 6. Si el TA selecciona Pasar a Envos. El sistema guarda la orden de pedido en estado Listo para Envo, muestra mensaje Listo para envo y cierra la interfaz ATENDER PEDIDO. 7. Si el TA selecciona Incidencia. El sistema extiende al caso de uso Registrar Incidencias. 8. Si el TA selecciona Salir: El sistema muestra un mensaje de confirmacin Est seguro de No guardar los datos? El TA confirma El sistema no almacena la informacin ingresada y cierra la interfaz ATENDER PEDIDO. 2.3. Sub Flujo Consultar Pedido: 1. El sistema muestra la interfaz ATENDER PEDIDO, con todos los datos del pedido slo para lectura y la opcin Salir. 2. El TA inspecciona los datos y al finalizar selecciona Salir 3. El sistema cierra la interfaz ATENDER PEDIDO y regresa a la interfaz principal. 2.4. Sub Flujo Cancelar Pedido: 1. El sistema muestra un mensaje de confirmacin Esta seguro que desea eliminar la orden? 2. El TA confirma la cancelacin 3. El sistema cancela el pedido eliminndolo de las listas de atencin. 2.5. Flujos Alternativos: <Stock en el Lmite> En el punto 3 del SF Atender Pedido, si el stock disponible queda en cantidad negativa, el sistema muestra el mensaje Stock en el Lmite. El flujo contina en el punto 2. 3. Requerimientos Especiales: El caso de uso debe estar disponible a travs de Internet, previo logeo del usuario.
94
Ingeniera de Sistemas I Precondiciones: 1. El TA se haya logeado en el sistema. 2. Los pedidos y productos estn disponibles en el sistema. 5. Poscondiciones: 1. El pedido queda registrado en el sistema en la lista de Pedidos en Atencin. 2. El pedido queda registrado en el sistema en la lista de Listos para envo. 3. El pedido queda cancelado en el sistema. 6. Puntos de Extensin: 1. Caso de Uso Registrar Incidencia, en el paso 7.1. del SF Atender Pedido. 7. Prototipo: 7.1. Listar Pedidos (Flujo Bsico)
95
Ingeniera de Sistemas I 7.2. Atender un Pedido (Subflujo):
Especificacin de Caso de Uso: Buscar Usuario 1. Breve Descripcin El sistema permitir realizar la bsqueda del usuario. 2. Flujo de Eventos 2.1. Flujo Bsico 1. El sistema busca al usuario. 2. El sistema muestra el cdigo y nombre del usuario en la interfaz del caso de uso que lo invoco y el caso de uso finaliza. 2.2. Flujos alternativos <Usuario no encontrado> Si en el punto 1 no se encuentra al usuario, el sistema muestra un mensaje Usuario no encontrado en la interfaz del caso de uso que lo invoco y finaliza el caso de uso.
96
Ingeniera de Sistemas I PRIORIZACIN DE CASO DE USO: Se hace un ranking de CU El ranking de CU sirve de consulta para guiar el desarrollo de las versiones del software . Se consideran aspectos econmicos y de negocio. Se necesita presentar el resultado del trabajo para su aprobacin al Gerente del Proyecto. Importante para planear el desarrollo incremental. CU Crticos: Ms importantes para los usuarios porque cubren las principales tareas o funciones que el sistema ha de realizar. Definen la arquitectura bsica. CU Secundarios: Sirven de apoyo a los casos de uso crticos. Tienen un impacto ms modesto sobre la arquitectura, pero deben implementarse pronto porque responden a requerimientos de inters para los usuarios. CU Auxiliares: No son claves para la arquitectura. Completan casos de uso crticos o secundarios. CU Opcionales: Responden a funcionalidades que pueden o no estar en la aplicacin, y que no son imprescindibles en las primeras versiones. Descripcin de los requerimientos funcionales y no funcionales. Requerimientos Funcionales: Nro. RF01 RF02 RF03 RF04 Descripcin El sistema mostrar reportes diversos segn los requerimientos del usuario. Gestin administrativa y clnica de la historia del usuario Registrar la obtencin de citas de forma segura y rpida. Registrar los exmenes clnicos de los pacientes. Prioridad Media Alta Alta Alta
97
Ingeniera de Sistemas I Registrar y Consultar horario del personal mediante la interfaz web interna. Controlar los productos por laboratorios de las empresas Registrara los medicamentos nuevos Proporcionar descuentos dependiendo del tipo de pago. Proporcionara comprobante de pago dependiendo del pedido del cliente y/o paciente Evaluara descuentos dependiendo de la especialidad a tratar. Controlara las fechas de vencimientos de los productos mediante alertas
RF05 RF06 RF07 RF08 RF09 RF10 RF11
Media Media Media Media Alta Media Media
Requerimientos No funcionales: Nro. RF01 RF02 RF03 RF04 RF05 RF06 RF07 RF08 RF09 RF10 RF11 Descripcin El tiempo de respuesta a una consulta no debe exceder de los 3 s. La memoria RAM requerida es de 1 gb. El sistema es compatible con versin de Windows Xp o posterior. El sistema debe de ser confiable, realizando procesos seguros. Se deben de tener en cuenta las licencias al momento de la implantacin de software. El sistema debe ser accesible al usuario que interacte con el. La documentacin proporcionada sobre el uso del software debe ser clara y concisa. La interfaz de usuario debe adecuarse a los requerimientos del usuario, mostrando grficos en los procesos que lo requieran. El sistema debe soportar la cantidad de usuarios concurrentes. El sistema debe ser accesible a posibles modificaciones futuras en su estructura. El lenguaje de programacin ser C# Prioridad Alta Media Baja Alta
Alta Baja Media Alta Media Media
98
Ingeniera de Sistemas I RESOLUCIN DE EJERCICIOS Descripcin de los actores del sistema Nro. CU001 Caso de Uso Registrar pago cita Descripcin Tomando los datos principales del paciente y con el respectivo pago, se genera la cita con la fecha y hora indicada por el usuario. Se registra el pago del medicamento aplicando un descuento si se diera el caso. Los datos del paciente, as como exmenes son registrados en este documento. Aqu se encuentra registrados los horarios de los mdicos y especialidades. Si el historial clnico existe se procede a realizar el proceso siguiente en el escenario donde se encuentre, caso contrario se crear el historial clnico tomando los datos inciales del paciente. Realiza una bsqueda del producto en la Base de Datos, en caso de que no existiera el sistema emitir un mensaje. Para la creacin de los horarios del personal. Caso de uso generado por el Doctor luego de haber analizado al paciente. Se verifica la existencia de la cita en el da y horario establecido. Tratamiento que dar al conocer el medico luego de culminar la cita. Tratamiento a realizar al paciente. Si el pago se realiza con tarjeta de crdito, entonces se genera el nmero de cuotas a saldar dicho monto. Contiene los datos del paciente en la primera vez que es registrado. Relacionado con Aperturar HC. El rea de laboratorio registrar en el HC el resultado del anlisis. Los exmenes clnicos Se generan los horarios disponibles para cada personal dentro de la clnica. 99
CU002 CU003 CU004
Registrar pago farmacia Actualizar historial clnico Consultar horario
CU005
Consular HC
CU006 CU007 CU008 CU009 CU010 CU011 CU012 CU013 CU014 CU015 CU016 CU017
Consultar stock Registrar disponibilidad Registrar orden de anlisis Consultar cita Registrar diagnostico Seleccionar tratamiento Generar cronograma de pago Aperturar HC Registrar paciente Registrar anlisis Consultar orden de anlisis Generar horario
Integracin de los casos de uso y actores:
100
Ingeniera de Sistemas I Especificacin de los casos de usos
Caso de uso: Generar Horario

Cdigo- Nombre Descripcin Actores Requerimientos Funcional Referencias Especificacin Flujo Bsico: 1. El caso de uso comienza cuando el Jefe de Personal solicita Registrar Horario en el Men Personal. 2. El sistema muestra la interfaz Configurar Horarios con los siguientes campos: Datos del Doctor: Especialidad, Listado de Doctores. Datos del Turno: Fecha, Horarios de turno. 3. El sistema carga automticamente: Datos de la Especialidad, Listado de Doctores, Turnos a asignar y listado de consultorios. 4. El sistema emite el caso de uso: Verificar disponibilidad. 5. El Jefe de Personal selecciona la Especialidad a registrar. 6. El sistema muestra el listado de Doctores pertenecientes a la especialidad seleccionada. 7. El Jefe de Personal selecciona el Doctor requerido. 8. El Jefe de Personal selecciona las fechas en el calendario y pulsa el botn para aadirlos a la lista denominada grupo de fechas. 9. El Jefe de Personal, selecciona la fecha y pulsa en el botn <<Buscar Consultorio>>. 10. El Sistema muestra en un recuadro, el listado de consultorios clasificados por colores de acuerdo a su disponibilidad. Generar Horario(Doctor) Este caso de uso inicia cuando el Jefe de Personal asigna los horarios al personal administrativo y/o servicios que se brindan dentro de la clnica, cabe mencionar a: Doctores, Enfermeras, Cajeros, y Exmenes Clnicos. Jefe de Personal RF05 - Registrar y Consultar horario del personal mediante la interfaz web interna.
101
Ingeniera de Sistemas I 11. El Jefe de Personal, selecciona el consultorio haciendo clic derecho sobre el. 12. El sistema oculta el recuadro de consultorios. 13. El Jefe de Personal, pulsa sobre el botn <<Guardar>> 14. El sistema emite un mensaje indicado el estado de registro (registro aadido, no se pudo aadir el registro). Flujo Alternativo (Errores, excepciones, situaciones anormales) <No existen consultorios disponibles> Si en el punto 10 no se encuentran consultorios disponibles, el caso de uso finaliza. Requerimientos Especiales Pre-Condiciones 1. Usuario logeado en el sistema. 2. Lista de Especialidades, Doctores, Turnos y Consultorios disponibles. Post-Condiciones Puntos de Extensin
Caso de uso: Registrar pago cita Cdigo- Nombre Descripcin Actores Registrar pago cita (doctor). Este caso de uso inicia cuando el Jefe de Personal asigna los horarios al personal administrativo y/o servicios que se brindan dentro de la clnica, cabe mencionar a: Doctores, Enfermeras, Cajeros, y Exmenes Clnicos. Cajero Cita RF02 - Gestin administrativa y clnica de la historia del usuario RF03 - Registrar la obtencin de citas de forma segura y rpida. RF08 - Proporcionar descuentos dependiendo del tipo de pago. RF09 - Proporcionara comprobante de pago dependiendo del pedido del cliente y/o paciente RF10 - Evaluara descuentos dependiendo de la especialidad a tratar. RF13 - Mediante su interfaz web, el usuario podr generar una cita desde la comodidad de su hogar.
Requerimientos Funcional
Referencia Especificacin
102
Ingeniera de Sistemas I Flujo Bsico: 1. El caso de uso comienza cuando el Cajero solicita Emitir cita en el Men Caja. 2. El sistema muestra la interfaz CITAS con los siguientes campos: Datos del Doctor: Nombre, Especialidad. 3. El sistema carga automticamente: Datos de la Especialidad, Listado de Doctores. 4. El Cajero_Cita selecciona una especialidad. 5. El sistema muestra el registro de Doctores pertenecientes a la especialidad solicitada. 6. El Cajero_Cita selecciona un Doctor. 7. El Cajero_Cita selecciona una fecha. 8. El Cajero_Cita pulsa en el botn <<Ver>>. 9. El sistema incluye el caso de uso Consulta horario especialidad. 10. El sistema muestra la opcin nueva cita y ver detalle en caso exista registro con los datos especificados anteriormente. 11. El sistema muestra el listado de citas generadas en la fecha indicada y doctor correspondiente. 12. El Cajero_Cita pulsa sobre la opcin <<nueva cita>>. 13. El Sistema muestra el recuadro: Bsqueda de Paciente. 14. El Cajero_Cita pulsa con el Link Nueva Cita. 15. El sistema muestra el cuadro de bsqueda de paciente. 16. El Cajero_Cita ingresa los el criterio de bsqueda indicado, 17. El Cajero_Cita pulsa en el botn buscar. 18. El sistema incluye el caso de uso Consultar historial clnico. 19. El sistema muestra el resultado de dicha bsqueda. 20. El Cajero_Cita selecciona los datos del paciente a registrar. 21. El Cajero_Cita pulsa en el botn <<Asignar>>. 22. El Sistema oculta el recuadro mostrado anteriormente. 23. El Cajero_Cita pulsa sobre el botn Generar Doc. Venta. 24. El sistema muestra la interfaz Documento de Venta. 25. El sistema carga automticamente el detalle de la venta obtenida del formulario anterior. 26. El Cajero_Cita ingresa los datos del Cliente. 27. El Cajero_Cita elige una de las opciones (boleta o factura). 28. El sistema procesa datos y muestra en pantalla segn el tipo de documento. 29. El Cajero_Cita pulsa en el botn grabar. 30. El sistema guarda los datos en la base de datos correspondiente. Flujo Alternativo (Errores, excepciones, situaciones anormales) Si en el punto 8 no existen horarios disponibles, el sistema emite un mensaje y el caso de uso finaliza. Requerimientos Especiales Pre-Condiciones 1. Usuario logeado en el sistema. 2. Lista de Especialidades, Doctores, Turnos. 3. Listado de paciente disponible. Post-Condiciones Puntos de Extensin 103
CASOS PROPUESTOS
CASO : FARMACIA BYC La farmacia BYC en los ltimos aos ha aumentado el nmero de sucursales y de usuarios, lo que ha llevado a la necesidad de contar con un Sistema Informacin que le permita controlar las compras y ventas de cada sucursal. Cada sucursal cuenta con un almacn propio en donde puede consultar el stock de sus productos as como almacenarlos cuando estos son adquiridos. El Qumico Farmacutico podr en el sistema registrar las rdenes de compra de forma directa sin cotizacin o consultado alguna cotizacin realizada anteriormente. Una orden de compra contiene los datos de un slo laboratorio, y de los frmacos que pertenece a ese laboratorio y un frmaco tiene atributos: cdigo, nombre comercial, unidad medida de presentacin, unidad mnima de dispensacin, valor ltima adquisicin, descuento. El Recepcionista puede ingresar en el sistema las rdenes de ingreso de frmacos por cada orden de compra. El comprobante del proveedor es por cada ingreso y debe reflejar los precios y descuentos acordados en la orden de compra. Las ventas en farmacia se realizan al contado al cliente externo y empleados, y al crdito slo a empleados y algunos clientes potenciales autorizado por el administrador de la farmacia. El cliente se acerca a ventanilla y entrega su receta al vendedor y este busca los frmacos, si existe todo lo recetado entonces le entrega una orden de pago y si existe parcialmente le indica el valor de lo existente. Luego el cliente va a caja (Cajero) y cancela la orden y recibe un comprobante de pago, luego l entrega la orden cancelada al despachador para su entrega de frmacos. En la venta es importante que el vendedor antes de realizar la orden de pago vea que el stock sea menos las cantidades comprometidas por otras rdenes del mismo producto. Todo el movimiento y su costo promedio de un producto de un almacn se debe controlar mediante un Krdex, el cual es consultado por el Qumico Farmacutico. CASO: BIBLIOTECA El SABIO La Biblioteca El Sabio del Per desea realizar un sistema para efectuar el control de prstamos de los libros y cubculos a sus diferentes usuarios. Los libros son prestados a travs de una forma denominada Solicitud de Prstamo a los diferentes usuarios, de tal manera que el usuario puede realizar su solicitud va intranet o en una PC de la biblioteca. De la solicitud de prstamo se almacena el nmero de la misma, la fecha de solicitud y datos de los usuarios y libros. El sistema debe verificar la existencia o disponibilidad del libro. Si el libro no se encuentra el sistema dar un mensaje El libro no se encuentra disponible El bibliotecario debe dar la atencin a la solicitud de prstamo y entregar el libro solicitado. 104
Los usuarios pueden ser de dos tipos: alumnos y profesores. Los profesores pueden solicitar hasta 5 libros y los alumnos mximo 2. La reserva de los cubculos es registrada slo por los alumnos en donde deben indicar fecha reserva, su capacidad y cantidad de equipos con que cuenta. Los pedidos de los cubculos se efectan a travs de la Internet generndose un nmero nico para su identificacin, siendo registrado por los usuarios. Tambin el sistema debe verificar disponibilidad de cubculos. De los pedidos de cubculos se registra la fecha del prstamo, el turno solicitado y su correspondiente aprobacin que debe ser realizada por el auxiliar de biblioteca. El jefe de biblioteca tambin puede realizar las funciones del bibliotecario pero adems es el encargado de abastecer a la biblioteca de nuevos libros, para ello el sistema le debe permitir realizar una orden de compra al proveedor, solicitando los libros que han tenido mayor demanda en el ltimo periodo acadmico La biblioteca aplica sanciones basadas en el tiempo que excedi la entrega de uno o varios libros. De las sanciones se guarda el tipo de la sancin, fecha inicio, fecha trmino. Las sanciones se aplican en el momento en que el bibliotecario registra la devolucin del libro.
105
BIBLIOGRAFA LIBROS: Modelamiento de Sistemas con UML (Alberto Tejeda). Anlisis y Diseo orientado a objetos con UML y el Proceso Unificado (Stephen R. Schach). El Proceso Unificado de Desarrollo de Software (Ivar Jacobson, Grady Booch y James Rumbaugh). Ingeniera del Software Edicin. - Un Enfoque Practico -(R.S. Pressmam) Sexta
Anlisis y Diseo Orientado a Objetos de Sistemas - (Simon Bennett, Steve Mc Robb y Ray) Tercera Edicin. Anlisis de Sistemas de Software ( Zalatiel Carranza). DIRECCIONES WEB: http://www.programacionextrema.org/articulos/newMethodology.es.html http://www.scribd.com/doc/2563977/RUP-UML http://www.scribd.com/doc/3993682/RUP-UML http://www.slideshare.net/david.motta/modelo-del-negocio-con-rup-y-umlparte-3
106

3ero Manual IngenieSistemasI

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3ero Manual IngenieSistemasI

Uploaded by

Copyright:

Available Formats

INGENIERA DE SISTEMAS - I

Coordinador Administrativo : Diseo y Diagramacin : Elaborado por : Produccin :

Rational Unified Process (RUP)

Figura_01: Fases e Iteraciones de la Metodologa RUP

Los elementos del RUP son:

Principales Beneficios del RUP:

Extreme Programing (XP)

Figura_02: Metodologa Extreme Programing

Qu es lo que propone XP?

Derechos del Cliente

Derechos del Desarrollador

Lo fundamental en este tipo de metodologa es:

Microsoft Solution Framework (MSF)

Figura_03: Metodologa MSF

Proceso dirigido por Casos de Uso

Proceso centrado en la arquitectura

Proceso iterativo e incremental

Figura_04: Una iteracin RUP

Desarrollo de software iterativo

Desarrollo basado en componentes

Modelado visual (usando UML)

Verificacin continua de la calidad

Gestin de los cambios

Figura_05: Estructura de RUP

4.1 Estructura Dinmica del proceso. Fases e iteraciones

Figura_06: Fases e hitos en RUP

Figura: Distribucin tpicas de esfuerzo y tiempo

Ingeniera de Sistemas I proyecto o replanterselo considerablemente.

Figura_07: Relacin entre roles, actividades, artefactos 25

Figura_08: Detalle de un workflow mediante roles, actividades y artefactos

Ingeniera de Sistemas I dar una explicacin de cada flujo de trabajo.

- Modelado del negocio

Configuracin y control de cambios

TCNICAS DE RECOLECCIN DE INFORMACIN

Respuestas de cuestionario cerrado:

Brainstorming (Tormenta de ideas)

Ejemplo de WorkShop Workshop N 1

Apellidos y Nombres : Cargo E-mail

Betsy Franco Alva : Administradora General : betsyfranco@hotmail.com

Lugar, fecha y hora de la entrevista:

Lugar : Fecha : Hora Inicio : Hora Fin :

Oficina de Administracin 15 Marzo de 2010 17:30 18:30

Los diagramas de UML:

Diagramas Estticos o Estructurales

Diagramas Dinmicos o de Comportamiento

Diagramas de Interaccin Comportamiento)

Figura _09: Jerarqua de los Diagramas de UML 2.0

MODELO DE CASO DE USO DEL NEGOCIO

MODELO DE ANLISIS DEL NEGOCIO

Como encontrar trabajadores y entidades de Negocio TRABAJADOR DE NEGOCIOS (Business Worker)

PROGRAMA DE COMPUTACIN E INFORMTICA- IDAT

Ingeniera de Sistemas I b) Casos de uso del Negocio:

c) Diagrama de Caso de uso de negocio:

d) Realizaciones de caso de uso del negocio:

e) Diagrama de clases del negocio:

Ingeniera de Sistemas I f) Diagrama de Actividades del negocio

ELABORAR PAQUETE TURSTICO

ROTACIN DEL PERSONAL

Figura No 1 Estructura del Modelo de Casos de Uso del Negocio (MCUN)

Figura No 2 Estructura del Modelo de Anlisis del Negocio (MAN).

Figura No. 3. DCUN MEDIDAS DISCIPLINARIAS

Figura No. 4 TRABAJADORES DEL NEGOCIO

PROGRAMA DE COMPUTACIN E INFORMTICA- IDAT

Figura No. 5. DIAGRAMA DE ACTIVIDADES MEDIDAS DISCIPLINARIAS