3ero Manual IngenieSistemasI

INGENIERÍA DE SISTEMAS - I

Presentación

© Ingeniería de Sistemas I – Grupo IDAT Desarrollo y Edición a cargo del Programa de Computación e Informática. Director Ejecutivo

:

Ing. Rolando Rojas Gallo

Coordinador Académico

:

Ing. José García La Riva

Coordinador Administrativo

:

Sr. Julio Cabrera Calle.

Diseño y Diagramación

:

Srta. Katy Lázaro Núñez

Elaborado por

:

Prof. Jorge Gonzales Maraví

PonceJosé Becerra, Carol Fanny Prof. CuyaProf. Camara, Producción

:

Departamento de Impresiones del Grupo IDAT

Los derechos de edición, distribución y contenidos de este texto son de exclusividad del GRUPO IDAT.

Presentación Ingeniería de Sistemas I pertenece a la línea formativa que imparte conocimientos relacionados con el proceso de ingeniería de software, metodología RUP y UML (Lenguaje de Moldeamiento Unicado) para desarrollar un software de calidad. El presente manual se ha diseñado por capítulos que se desarrollan en las semanas académicas, en cada capítulo se desarrollan los contenidos teóricos con ejemplos resueltos y propuestos. El curso es teórico-práctico, cuenta con laboratorio para desarrollar casos de proyectos de software utilizando la herramienta de modelado de Rational Roose, básicamente se desarrolla la disciplinas de Modelado de Negocio y Modelo de Requerimientos.

índice Presentación

5

Capítulo 1: Ingeniería Software, RUP y UML

9

1. 2. 3. 4.

11 18 32 39

Ingeniería de Software Metodología RUP Técnicas de Recolección de Información UML

Capitulo 2: Modelo de Negocio

45

1. Modelo de Caso de Uso del Negocio 2. Modelo de Análisis del Negocio

50 51

Capitulo 3: Modelo de Requerimientos

77

Bibliografìa

106

1 CAPÍTULO Ingeniería Software, RUP y UML •

Ingeniería de Software

•

Metodología RUP

•

Técnicas de Recolección de Información

•

UML

Ingeniería de Sistemas I

INGENIERÍA DE SOFTWARE 1. QUÉ ES INGENIERÍA DE SOFTWARE Es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad. Esta ingeniería trata áreas muy diversas la informáticasistemas y de las ciencias de la computación, talescon como construcción dede compiladores, operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a innidad de áreas: negocios, investigación cientíca, medicina, producción, logística, banca, control de tráco, meteorología, derecho, Internet, Intranet, etc.

2. MODELOS DE PROCESOS DE INGENIERÌA DE SOFTWARE La ingeniería de software tiene varios modelos, paradigmas o losofías de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos: • •

Modelo en cascada o Clásico (modelo tradicional) Modelo en espiral (modelo evolutivo)

•• • •

Modelo de por prototipos Desarrollo etapas Desarrollo iterativo y creciente o Iterativo e Incremental RAD (Rapid Application Development)

3. METODOLOGÍAS DE DESARROLLO DE SOFTWARE ¿Qué metodología debo usar para el desarrollo de un Software? Todos en algún momento nos hemos hecho esta pregunta, cuando hemos tenido que desarrollar un sistema o aplicación 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 difícil de controlar, pero si no llevamos una metodología de por medio, lo que obtenemos es clientes insatisfechos con el resultado y desarrolladores aúnnomás Sin embargo, muchas veces se insatisfechos. toma en cuenta el utilizar una metodología adecuada, sobre todo cuando se trata de proyectos pequeños de dos o tres meses. Lo que se hace con este tipo de proyectos es separar rápidamente el aplicativo en procesos, cada proceso en funciones, y por cada función 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 metodología de desarrollo, y empezamos a buscar cual sería la más apropiada para nuestro caso. Lo cierto es que muchas veces no encontramos la más adecuada y terminamos por hacer o diseñar nuestra

11 PROGRAMA DE COMPUTACIÓN E INFORMÁTICA- IDAT

Ingeniería de Sistemas I propia metodología, algo que por supuesto no esta mal, siempre y cuando cumpla con el objetivo. Muchas veces realizamos el diseño de nuestro software de manera rígida, con los requerimientos que el cliente nos solicitó, de tal manera que cuando el cliente en la etapa nal (etapa de prueba), solicita un cambio se nos hace muy difícil realizarlo, pues si lo hacemos, altera muchas cosas que no habíamos 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 modicación no perjudique al desarrollo del mismo. Por experiencia, muchas veces los usuarios nales, se dan cuenta de las cosas que dejaron de mencionar, recién en la etapa nal 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é metodología podemos utilizar y cual se adapta más a nuestro medio, mencionaré tres de ellas de las que se consideran las más importantes, tal como: RUP, XP y MSF. Rational Unied Process (RUP)

La metodología RUP, llamada así por sus siglas en inglés Rational Unied 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 más que un simple proceso; es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyectos. El Proceso Unicado está basado en componentes, lo cual quiere decir que el sistema de software en construcción está formado por componentes de software interconectados a través de interfaces bien denidas. El Proceso Unicado 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 visión del proyecto. • Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima. • Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. • Transición, El objetivo es llegar a obtener el release del proyecto.


Ingeniería 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 iteración se establecen en función de la evaluación de las iteraciones precedentes. Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos disciplinas:

Disciplina de Desarrollo: • • • • • • • • • •

Ingeniería de Negocios: Entendiendo las necesidades del negocio. Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado. Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software. Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado. Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo los solicitado esta presente. Disciplina de Soporte Conguración y administración del cambio: Guardando todas las versiones del proyecto. Administrando el proyecto: Administrando horarios y recursos. Ambiente: Administrando el ambiente de desarrollo. Distribución: Hacer todo lo necesario para la salida del proyecto.

Figura_01: Fases e Iteraciones de la Metodología RUP


Ingeniería de Sistemas I Es recomendable que a cada una de estas iteraciones se les clasique y ordene según su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como benecio la retroalimentación que se tendría en cada entregable o en cada iteración.

Los elementos del RUP son: Actividades, Son los procesos que se llegan a determinar en cada iteración. 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 metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certicación en el desarrollo del software. Principales Benecios del RUP:

• •

Provee lineamientos para un desarrollo eciente de software de calidad Captura-Presenta las mejores prácticas Aprender de la experiencia anterior Vericar la calidad Desarrollo iterativo Arquitectura basada en componentes Modelar visualmente el sistema Mejora la comunicación con los usuarios Extensión del material de capacitación Promueve una visión y una cultura “Común” Guías sobre cómo utilizar herramientas Reduce “Riesgos” e incrementa la “Predictibilidad”

» » » » » » »

• • •

Extreme Programing (XP)

Es una de las metodologías de desarrollo de software más exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al usuario nal, pues es uno de los requisitos para llegar al éxito del proyecto.

Figura_02: Metodología Extreme Programing



Características de XP, la metodología se basa en: •

• •

Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantándonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantáramos a obtener los posibles errores. Refabricación: se basa en la reutilización de código, para lo cual se crean patrones o modelos estándares, siendo más exible al cambio. Programación en pares: una particularidad de esta metodología es que propone la programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción 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 pequeño y añade funcionalidad con retroalimentación 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 Añadir, cambiar o quitar requerimientos en cualquier momento Obtener lo máximo 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 metodología es: • • •

La comunicación, entre los usuarios y los desarrolladores La simplicidad, al desarrollar y codicar los módulos del sistema La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios nales



Microsoft Solution Framework (MSF)

Esta es una metodología exible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planicación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas.

Figura_03: Metodología MSF

MSF tiene las siguientes características: • • • •

Adaptable: es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un especíco lugar. Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más. Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.

MSF se compone de varios modelos encargados de planicar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de Diseño de Proceso y nalmente el modelo de Aplicación. •

Modelo de Arquitectura del Proyecto: Diseñado para acortar la planicación del ciclo de vida. Este modelo dene las pautas para construir proyectos empresariales a través del lanzamiento de versiones.

•

Modelo de Equipo: Este modelo ha sido diseñado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura exible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamaño del proyecto y del equipo de personas disponibles.

•

Modelo de Proceso: Diseñado 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 liberación de versiones y explicando su relación con el Modelo de equipo.

•

Modelo de Gestión del Riesgo: Diseñado para ayudar al equipo a identicar las prioridades, tomar las decisiones estratégicas correctas y controlar 16 PROGRAMA DE COMPUTACIÓN E INFORMÁTICA- IDAT

Ingeniería 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 Diseño del Proceso: Diseñado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseño eciente y exible a través de un enfoque iterativo. Las fases de diseño conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores.

•

Modelo de Aplicación: Diseñado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para diseñar 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.

Conclusión: Todas las metodologías modernas usan al UML, para el desarrollo de sus modelos. • • •

La Metodología RUP es más adaptable para proyectos de largo plazo. La Metodología XP en cambio, se recomienda para proyectos de corto plazo. La Metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología.

Podemos concluir además, que lo más importante antes de elegir la metodología que usarás para la implementación de tu software, es determinar el alcance que tendrá y luego de ahí ver cual es la que más se acomoda en tu aplicación.



METODOLOGÍA RUP 1. INTRODUCCIÓN Es un proceso para el desarrollo de aplicaciones, es un conglomerado de las mejores prácticas para conducir las actividades de desarrollo, del equipo de la ingeniería de software. el Como plataforma de procesos que abarca todasdelascomponentes prácticas de la industria, RUPuna permite seleccionar fácilmente el conjunto de proceso que se ajustan a las necesidades especícas del proyecto. Se podrán alcanzar resultados predecibles unicando el equipo con procesos comunes que optimicen la comunicación y creen un entendimiento común 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 Unied Process (RUP). Se describe la evolución del proceso, características principales y estructura del proceso. RUP es un producto comercial desarrollado y comercializado por Rational Software, una compañía de IBM.

2. CARACTERÍSTICAS ESENCIALES Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características 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 técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que sería bueno contemplar. Se dene un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema. Los Casos de Uso no sólo 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 organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.


Ingeniería de Sistemas I La arquitectura involucra los aspectos estáticos y dinámicos más signicativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además la denición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser exible durante todo el proceso de desarrollo. La arquitectura se ve inuenciada 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 función 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 más pequeñas 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 iteración (un recorrido más o menos completo a lo largo de todos los ujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto. Una iteración puede realizarse por medio de una cascada como se muestra en la Figura 04. Se pasa por los ujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planicación de la iteración, un análisis de la iteración y algunas actividades especícas de la iteración. Al nalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.

Figura_04: Una iteración RUP

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los ujos de trabajo relevantes y renando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planicación de


Ingeniería de Sistemas I los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya nalizado por completo con la versión actual del producto. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades.

3. MEJORES PRÁCTICAS DE RUP RUP identica 6 best practices con las que dene una forma efectiva de trabajar para los equipos de desarrollo de software.

Gestión de requisitos RUP brinda una guía para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y restricciones. Utiliza una notación de Caso de Uso y escenarios para representar los requisitos.

Desarrollo de software iterativo Desarrollo del producto mediante iteraciones con hitos bien denidos, en las cuales se repiten las actividades pero con distinto énfasis, según la fase del proyecto.

Desarrollo basado en componentes La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien denidas, que posteriormente serán ensamblados para generar el sistema. Esta característica 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, especicar, construir y documentar los artefactos de un sistema software. Es un estándar de la OMG (http://www.omg.org). Utilizar herramientas de modelado visual facilita la gestión de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual también ayuda aimplementaciones. mantener la consistencia entreellos artefactos del sistema: requisitos, diseños e En resumen, modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software. Vericación continua de la calidad

Es importante que la calidad de todos los artefactos se evalúe en varios puntos durante el proceso de desarrollo, especialmente al nal de cada iteración. En esta vericación las pruebas juegan un papel fundamental y se integran a lo largo de todo


Ingeniería de Sistemas I el proceso. Para todos los artefactos no ejecutables las revisiones e inspecciones también deben ser continuas.

Gestión de los cambios El cambio es un factor de riesgo crítico en los proyectos de software. Los artefactos software cambian no sólo 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 desafío que debe abordarse es la construcción de software con la participación de múltiples desarrolladores, posiblemente distribuidos geográcamente, trabajando a la vez en una release, y quizás en distintas plataformas. La ausencia de disciplina rápidamente conduciría al caos. La Gestión de Cambios y de Conguración 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 dinámicos del proceso. Indica las características del ciclo de vida del proceso expresado en términos de fases, iteraciones e hitos. Se puede observar en la Figura 05 que RUP consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Como se mencionó anteriormente cada fase se subdivide a la vez en iteraciones. Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas, ujos de trabajo, actividades, artefactos y roles.

Figura_05: Estructura de RUP

4.1 Estructura Dinámica 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 generación del producto para los clientes.


Ingeniería de Sistemas I Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada fase es variable. Cada fase se concluye con un hito bien denido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podrían ser los criterios aplicables a cada iteración. Los hitos para cada una de las fases son: Inicio, Elaboración, Construcción, Transición. Las fases y sus respectivos hitos se ilustran en la Figura 06.

Figura_06: Fases e hitos en RUP

La duración y esfuerzo dedicado en cada fase es variable dependiendo de las características del proyecto. Sin embargo, la Figura ilustra porcentajes frecuentes al respecto. Consecuente connecesarios el esfuerzoaseñalado, la Figura ilustra una distribución típica de recursos humanos lo largo del proyecto.

Esfuerzo

Inicio

Elaboración

Construcción

Transición

5%

20%

65%

10%

Tiempo Dedicado

10%

30%

50%

10%

Figura: Distribución típicas de esfuerzo y tiempo

A. Inicio Durante la fase de inicio se dene el modelo del negocio y el alcance del proyecto. Se identican todos los actores y Casos de Uso, y se diseñan los Casos de Uso más esenciales (aproximadamente el 20% del modelo completo), se desarrolla una descripción del producto nal 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 límites. • Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que


Ingeniería de Sistemas I denen 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 visión: Una visión general de los requerimientos del proyecto, características clave y restricciones principales. Modelo inicial de Casos de Uso (10-20% completado). •

Un glosario inicial: Terminología 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. Elaboración El propósito de la fase de elaboración 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 nal. Este prototipo debe contener los Casos de Uso críticos identicados en la fase de inicio. También debe demostrarse que se han evitado los riesgos más graves. • • • •

Denir, validar y cimentar la arquitectura. Completar la visión. Crear un plan able para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede. Demostrar que la arquitectura propuesta soportará la visión 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 identicados, la mayoría de los casos desarrollados. Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito no asociado con un Caso de Uso especíco. Descripción 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 especica el proceso a seguir. Un manual de usuario preliminar (opcional).

Si no se superan los criterios de evaluación quizá sea necesario abandonar el


Ingeniería de Sistemas I proyecto o replanteárselo considerablemente.

C. Construcción La nalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a través de las sucesivas iteraciones. Durante esta fase todos los componentes, características y requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una versión aceptable del producto. Los objetivos concretos según incluyen: • • •

Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo. Conseguir una calidad adecuada tan rápido como sea práctico. Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea práctico.

Los resultados de la fase de construcción deben ser :  • Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación) • Arquitectura íntegra (mantenida y mínimamente actualizada) • Riesgos Presentados Mitigados • Plan del Proyecto para la fase de Transición. • Manual Inicial de Usuario (con suciente detalle) • Prototipo Operacional – beta • Caso del Negocio Actualizado Los criterios de evaluación 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 están listos para la transición en la comunidad de usuarios. Son aceptables los gastos actuales versus los gastos planeados.

D. Transición La nalidad de la fase de transición es poner el producto en manos de los usuarios nales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, conguración, instalación y facilidad de uso del producto. En se citan algunas de las cosas que puede incluir esta fase: • •

Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas de los usuarios Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por nuestro proyecto.


Ingeniería de Sistemas I • • •

Conversión de las bases de datos operacionales. Entrenamiento de los usuarios y técnicos de mantenimiento. Traspaso del producto a los equipos de marketing, distribución y venta.

Los principales objetivos de esta fase son: • •

Conseguir que el usuario se valga por si mismo. Un producto nal que cumpla los requisitos esperados, que funcione y satisfaga sucientemente al usuario.

Los resultados de la fase de transición son : • • • • • •

Prototipo Operacional Documentos Legales Caso del Negocio Completo Línea de Base del Producto completa y corregida que incluye todos los modelos del sistema Descripción de la Arquitectura completa y corregida Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión.

Los criterios de evaluación de esta fase son los siguientes: • •

El usuario se encuentra satisfecho. Son aceptables los gastos actuales versus los gastos planicados.

4.2 Estructura Estática del proceso. Roles, actividades, artefactos y ujos de trabajo

Un proceso de desarrollo de software dene quién hace qué, cómo y cuándo. RUP dene cuatro elementos los roles, que responden a la pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los ujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo? (ver Figura) .

Figura_07: Relación entre roles, actividades, artefactos 25 PROGRAMA DE COMPUTACIÓN E INFORMÁTICA- IDAT


Figura_08: Detalle de un workow mediante roles, actividades y artefactos

A. Roles Un rol dene el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar 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 dueño de un conjunto de artefactos . RUP dene grupos Estos grupos son: de roles, agrupados por participación en actividades relacionadas. Analistas:

Analista de procesos de negocio. Diseñador del negocio. Analista de sistema. Especicador de requisitos. Desarrolladores: • Arquitecto de software. • Diseñador • Diseñador de interfaz de usuario • Diseñador de cápsulas. • Diseñador de base de datos. • Implementador. • Integrador. Gestores: • Jefe de proyecto • Jefe de control de cambios. • Jefe de conguración. • Jefe de pruebas • Jefe de despliegue


Ingeniería de Sistemas I • • •

Ingeniero de procesos Revisor de gestión del proyecto Gestor de pruebas.

Apoyo: • Documentador técnico • Administrador de sistema • Especialista en herramientas • Desarrollador de cursos • Artista gráco Especialista en pruebas: • Especialista en Pruebas (tester) • Analista de pruebas • Diseñador de pruebas Otros roles: • Stakeholders. • Revisor • Coordinación de revisiones • Revisor técnico • Cualquier rol

B. Actividades Una actividad en concreto es una unidad de trabajo que una persona que desempeñe un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.

C. Artefactos Un producto o artefacto es un trozo de información que es producido, modicado 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 nal . 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 diseño. 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 enumeración de roles, actividades y artefactos no se dene un proceso, necesitamos contar con una secuencia de actividades realizadas por los diferentes roles, así como la relación entre los mismos. Un ujo de trabajo es una relación de actividades que nos producen unos resultados observables. A continuación se


Ingeniería de Sistemas I dará una explicación de cada ujo de trabajo.

- Modelado del negocio Con este ujo de trabajo pretendemos llegar a un mejor entendimiento de la organización donde se va a implantar el producto. Los objetivos del modelado de negocio son : • • • •

Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado (organización objetivo). Entender el problema actual en la organización objetivo e identicar potenciales mejoras. Asegurar que clientes, usuarios nales y desarrolladores tengan un entendimiento común de la organización objetivo. Derivar los requisitos del sistema necesarios para apoyar a la organización objetivo.

Para lograr estos objetivos, el modelo de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se denen procesos, roles y responsabilidades de la organización 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 especicaciones tales como un Glosario.

- Requisitos: Este es uno de los ujos de trabajo más importantes, porque en él se establece qué tiene que hacer exactamente el sistema que construyamos. En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios nales tienen que comprender y aceptar los requisitos que especiquemos. Los objetivos del ujo de datos Requisitos es : •

• • •

Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría hacer. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. Denir el ámbito del sistema. Proveer una base para la planeación de los contenidos técnicos de las iteraciones. Proveer una base para estimar costos y tiempo de desarrollo del sistema.

•

Denir unausuario. interfaz de usuarios para el sistema, enfocada a las necesidades y metas del

•

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 especíca. Por ejemplo requisitos de facilidad de uso, abilidad, eciencia, portabilidad, etc.


Ingeniería de Sistemas I Para capturar los requisitos es preciso entrevistar a todos los interesados en el proyecto, no sólo a los usuarios nales, y anotar todas sus peticiones. A partir de ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos. En este ujo de trabajo, y como parte de los requisitos de facilidad de uso, se diseña la interfaz gráca de usuario. Para ello habitualmente se construyen prototipos de la interfaz gráca de usuario que se contrastan con el usuario nal.

- Análisis y Diseño El objetivo de este ujo de trabajo es traducir los requisitos a una especicación que describe cómo implementar el sistema. Los objetivos del análisis y diseño son : • • •

Transformar los requisitos al diseño del futuro sistema. Desarrollar una arquitectura para el sistema. Adaptar el diseño para que sea consistente con el entorno de implementación, diseñando para el rendimiento.

El análisis consiste en obtener una visión del sistema que se preocupa de ver qué hace, de modo que sólo se interesa por los requisitos funcionales. Por otro lado el diseño es un renamiento del análisis que tiene en cuenta los requisitos no funcionales, en denitiva cómo cumple el sistema sus objetivos.

- Implementación En este ujo de trabajo se implementan las clases y objetos en cheros fuente, binarios, ejecutables y demás. Además se deben hacer las pruebas de unidad: cada implementador es responsable de probar las unidades que produzca. El resultado nal de este ujo de trabajo es un sistema ejecutable. En cada iteración habrá que hacer lo siguiente: • • • •

Planicar qué subsistemas deben ser implementados y en que orden deben ser integrados, formando el Plan de Integración. Cada implementador decide en que orden implementa los elementos del subsistema. Si encuentra errores de diseño, los notica. Se prueban los subsistemas individualmente.

• Se integra el sistema siguiendo el plan. La estructura de todos los elementos implementados forma el modelo de implementación. La integración debe ser incremental, es decir, en cada momento sólo se añade un elemento. De este modo es más fácil localizar fallos y los componentes se prueban más 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 tecnologías o diseñar la interfaz de usuario. Los prototipos pueden ser exploratorios (desechables) o evolutivos. Estos últimos llegan a transformarse en el sistema nal.



- Pruebas Este ujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al nal 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 validación de los supuestos realizados en el diseño y especicación de requisitos por medio de demostraciones concretas. Vericar las funciones del producto de software según lo diseñado. Vericar que los requisitos tengan su apropiada implementación.

Las actividades de este ujo comienzan pronto en el proyecto con el plan de prueba (el cual contiene información sobre los objetivos generales y especícos de las prueba en el proyecto, así como las estrategias y recursos con que se dotará a esta tarea), o incluso antes con alguna evaluación durante la fase de inicio, y continuará durante todo el proyecto. El desarrollo del ujo de trabajo consistirá en planicar que es lo que hay que probar, diseñar cómo se va a hacer, implementar lo necesario para llevarlos a cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma que la información obtenida nos sirva para ir renando el producto a desarrollar.

- Despliegue El objetivo de este ujo 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 ejecución nal. Empaquetar el software para su distribución. 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 ujo de trabajo se desarrolla con mayor intensidad en la fase de transición, ya que el propósito del ujo es asegurar una aceptación y adaptación sin complicaciones del software por parte de los usuarios. Su ejecución inicia en fases anteriores, para preparar el camino, sobre todo con actividades de planicación, en la elaboración del manual de usuario y tutoriales. Gestión del proyecto La Gestión 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.


Ingeniería de Sistemas I Los objetivos de este ujo de trabajo son: • • •

Proveer un marco de trabajo para la gestión de proyectos de software intensivos. Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el proyecto. Proveer un marco de trabajo para gestionar riesgos.

La planeación de un proyecto posee dos niveles de abstracción: un plan para las fases y un plan para cada iteración. Conguración y control de cambios

La nalidad de este ujo de trabajo es mantener la integridad de todos los artefactos que se crean en el proceso, así como de mantener información del proceso evolutivo que han seguido.

Entorno La nalidad de este ujo de trabajo es dar soporte al proyecto con las adecuadas herramientas, procesos y métodos. Brinda una especicación de las herramientas que se van a necesitar en cada momento, así como denir la instancia concreta del proceso que se va a seguir. En concreto las responsabilidades de este ujo de trabajo incluyen: •• • • •

Selección de herramientas Estableceryyadquisición congurar las herramientas para que se ajusten a la organización. Conguración del proceso. Mejora del proceso. Servicios técnicos.

El principal artefacto que se usa en este ujo de trabajo es el caso de desarrollo que especica para el proyecto actual en concreto, como se aplicará el proceso, que productos se van a utilizar y como van a ser utilizados. Además se tendrán que denir las guías para los distintos aspectos del proceso, como pueden ser el modelado del negocio y los Casos de Uso, para la interfaz de usuario, el diseño, la programación, el manual de usuario.



TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN Existen varias técnicas para capturar requisitos de usuarios, de las cuales examinaremos algunas:

1. La entrevista Dentro de las técnicas utilizadas para recopilar información, las entrevistas ocupan un lugar preponderante en consideración con el tiempo que ocupan y el objetivo que tienen. Por lo general, son la mayor fuente de información del analista. La entrevista es una forma de conversación, no de interrogación. Durante la entrevista el analista no se limita solo a informarse de los puntos que le interesan, sino que además aprovecha la oportunidad para explicar su trabajo a los usuarios y crear un clima sociológico 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. 2. Preparación Ejecución 3. Recapitulación a) Preparación

• • • •

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 conversación más natural. Se deben preparar cuidadosamente las preguntas a realizar o la guía de la entrevista.

b) Ejecución

• • •

Se debe ser correcto y no preguntar cosas que se pueden obtener por otras vías 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, identicarse y explicar los objetivos de la entrevista Se debe prestar la máxima atención durante el desarrollo, crear un clima favorable, evitar caer en discusión con los usuarios, no hacer criticas, utilizar una terminología adecuada, no adelantarse a ningún criterio ni opinión de



• • • •

los usuarios y mucho menos sacar conclusiones instantáneas sobre la información recibida. Diferenciar entre los hechos y las opiniones, entre la actividad o función que realiza y el como la realiza, tratando siempre que la información 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 nal se debe hacer una pequeña recapitulación de la información recopilada para vericar los hechos registrados.

c) Recapitulación

• •

Se deben revisar las notas para reordenarlas y organizarlas por temas, pasarlas en limpio y comprobar que no existan contradicciones. La recapitulación de las entrevistas se hace en el modelo “Registro de Acuerdos y Observaciones” Entrevistado: Juan Perez (Jefe de Almacén) Entrevistador: Ana García Sistema

Fecha: 3 de Marzo Tema: Realizar un

Objetivos de la Entrevista: Obtener requerimientos del usuario para realizar un sistema de calidad. 1. ¿Cuál es su opinión del sistema de computadora actual? 2. ¿Cuáles son algunos de los problemas que experimenta para recibir información a tiempo? 3. Describa el proceso de almacén. 4. ¿Qué reportes genera en un mes? 5. Liste sus dos prioridades máximas para el departamento de almacén? 6. ¿Tiene comunicación automatizado con los demás 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 número 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 situación especica para la cual fueron diseñados especialmente y además este diseño reúne una serie de requisitos. Hay dos formas de cuestionarios: abiertos y cerrados.


Ingeniería de Sistemas I Abiertos: Se utilizan par recoger sentimientos, opiniones, referencias. Cerrados: Limitan las respuestas posibles a través de un estilo cuidadoso en la pregunta.

Respuestas de cuestionario cerrado: •

si / no ¿Cree que se cometen muchos errores en la codicación de los números de cuenta en las facturas? SI

•

NO

De acuerdo/en desacuerdo Se cometen muchos errores al codicar los números de cuenta en las facturas: DE ACUERDO EN DESACUERDO

•

Escalas Se cometen muchos errores al codicar los números de cuenta en las facturas. TOTALMENTE DE ACUERDO DE ACUERDO NO ESTOY SEGURO EN DESACUERDO TOTALMENTE EN DESACUERDO

•

Número De cada 100 facturas que se procesan cuántas tienen errores? Anote el número: ____________

•

Rango ¿De cada 100 facturas que se procesan cuántas tienen errores? 0-5 6 - 10 11 - 15 16 - 20 21 - 25 26 - 30 31 - 40 41 - 50 Más de 50


Ingeniería de Sistemas I 3. Revisión de documentos Toda entidad debe emitir y archivar un conjunto de documentos de información donde aparezcan los indicadores principales de la entidad relacionados con su actividad fundamental. Por lo general las entidades también emiten y archivan un conjunto de informes o modelos de interés para el organismo central o ministerio al cual pertenecen. Además, toda entidad debe tener un Sistema de Contabilidad, un Sistema de Fuerza de Trabajo uno de Abastecimiento, uno de Medios Básicos, etc. Cada uno de los cuales posee toda la información de la entidad sobre esos aspectos especícos. Muchos o todos los indicadores que Ud. necesita deben estar reejados en estos documentos. Pero muchas veces en los documentos no se reeja exactamente lo que uno quiere buscar y debe hacer un procesamiento de ellos. A pesar de que se haga un análisis profundo de los documentos, hay indicadores que la entidad no recopila y son sumamente útiles para el analista; entonces, hay que ir a la investigación o a realizar ciertos experimentos.

4. Investigación y experimentación Dentro de los indicadores que son muy importantes para el analista y que la entidad generalmente no posee, están: • •

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 realización de un proceso y la cantidad de errores que se cometen en un proceso que generalmente son cuestiones de interés.

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, aún cuando puede variar entre 6 y 12, manteniéndose ecacia. Se expone un problema a los presentes, o se les envía un memorándum previo. Las ideas se generan y exponen por los asistentes en forma clara y precisa, evitando discursos, sin que medie ninguna crítica o evaluación de éstas, por descabelladas que pudieran parecer. En esta atmósfera no crítica, las personas se sienten libres para decir lo que piensan y estas ideas, aún en el caso de que no tuvieran valor, pueden dar srcen a otras por asociación. Las ideas se recogen y listan en pliegos de papel que se mantienen a la vista de todos. Estas ideas se valoran posteriormente.


Ingeniería de Sistemas I La generación de ideas y su recogida puede realizarse, dependiendo de las características del Grupo y sus integrantes, según 3 variantes: 1. Los integrantes dan las ideas espontáneamente 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 continúa el proceso hasta que todos pasen. 3. Una persona que actúa 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 generación de ideas por asociación con las que se presentan. Merita destacar brevemente el papel que desempeña en esta y otras técnicas 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 elaboración y exposición de ideas creativamente. Brinda conanza para expresar las ideas, evita ataques, permite y promueve la participación de todos. No evalúa, 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 generación 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 generación de ideas puede verse frenada por la presencia de uno o varios participantes. Existen conictos o controversias en el seno del Grupo que pueden inuir en la acogida y posterior valoración de las ideas.

En estas situaciones es conveniente la utilización de otras técnicas: 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 elaboración de alfajores, una reunión para levantamiento de información, etc.; aunque también puede designar otros conceptos derivados a éste.



Ejemplo de WorkShop Workshop N° 1 Escenario

:

Ocina de Administración

:

Betsy Franco Alva : Administradora General : [email protected]

Entrevistado:

◊ Apellidos y Nombres ◊ Cargo ◊ E-mail Agenda:

Conocer el funcionamiento general de la empresa. Identicar los procesos que se llevan a cabo en las diferentes áreas. Lugar, fecha y hora de la entrevista:

◊ ◊ ◊ ◊

Lugar : Fecha : Hora Inicio : Hora Fin :

Ocina de Administración 15 Marzo de 2010 17:30 18:30

Preguntas preliminares:

◊ ◊ ◊ ◊

¿Cuál es el giro de la empresa? ¿Cuál es la misión de la empresa? ¿Cuál es su visión? ¿Cuál es el mercado al cual están dirigidos sus productos: nacional o internacional? ◊ ¿Quiénes son sus clientes potenciales? ◊ ¿Quiénes son sus proveedores? ◊ ¿Quiénes 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. Además ante cualquier problema que se pudiera presentar soy la responsable directa de solucionarlo de la mejor manera posible.


Ingeniería de Sistemas I 2. ¿Podría decirme brevemente a que se dedica la empresa? La empresa nació con la nalidad de comercializar artículos para un bazar, electrodomésticos y juguetes, que son importados. 3. ¿Podría describirme la arquitectura de la empresa? La empresa posee tres áreas fundamentales que son Ventas, Compras y Almacén que funcionan de manera conjunta y ordenada supervisadas por Administración General. 4. ¿Podría 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 recepción de pedidos, es decir todo el manejo de documentación que circula en esta área. El Departamento de Compra se encarga del control de las compras, es decir de todo el manejo de documentación que se emite en esta área en lo referente a reabastecimiento de stock. El Departamento de Almacén se encarga del control del almacén, además de generar listados sobre los productos con sus respectivos códigos que se requiere para ventas. 5. ¿Actualmente la empresa cuenta con algún sistema que agilice sus operaciones? No. La mayoría de ellas se realizan en forma manual y algunas pocas con la ayuda de hojas de cálculo. 6. ¿Qué es lo que buscan obtener con la implementación de un sistema? En todo giro de negocios existen operaciones que se deben realizar con un debido cuidado y con el más mínimo error para obtener los mayores benecios, y eso es lo que nosotros buscamos; es por ello que requerimos un sistema que agilice los procesos y los controle, reduciendo al mínimo el tiempo empleado en ello. Además la empresa también requiere la elaboración de una página web que se encargue de marketear los artículos que ofrecemos así como que también tenga la característica de enviarnos sus pedidos vía correo electrónico, etc.. Eso es lo que buscamos.



UML

El UML es una técnica de modelado de objetos y como tal supone una abstracción de sistema para llegarde a construirlo términos concretos. El modelado no es másunque la construcción un modelo en a partir de una especicación. Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del srcinal y por lo tanto facilita dicha comprensión. Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música 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 n y al cabo. Los modelos además, al no ser una representación que incluya todos los detalles de los srcinales, permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la Metodología RUP, los modelos permiten una mejor comunicación con el cliente por distintas razones: •

Es posible enseñar al cliente una posible aproximación de lo que será el producto

•

nal. Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado. Reducen la complejidad del srcinal en subconjuntos que son fácilmente 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 programación que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especicación total con detalles que no son importantes para el algoritmo que están implementando. Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, mediante los diagramas, es decir, mediante representaciones grácas que contienen toda la información relevante del sistema. Dando una breve introducción tema; (pero se puede decir que UMLuna nonotación, es una metodología, si no más bien es un al lenguaje no de programación), que permite visualizar, especicar, construir y documentar el modelado de sistemas; sea cual fuere el ciclo de vida elegido para el análisis, diseño e implementación del mismo. UML es de reciente aparición y, al ser no propietario, es usado y renado por muchas empresas, grupos de investigadores y desarrolladores a nivel mundial. UML signica “Unied Modeling Language”: Lenguaje de Modelado o Modelamiento Unicado. El Lenguaje de Modelado Unicado es un lenguaje usado para especicar,


Ingeniería 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 metodología, a lo largo del proceso de desarrollo de software, en cualquier plataforma tecnológica de implementación (Unix, Windows etc.). Es un sistema notacional (que, entre otras cosas, incluye el signicado de sus notaciones) destinado a los sistemas de modelado que utilizan conceptos orientados a objetos. Los principales factores que motivaron la denición de UML fueron: la necesidad de modelar sistemas, las tendencias en la industria del software, unicar los distintos lenguajes y métodos existentes e innovar los modelos.

1. DEFINICIONES DE UML •

El Lenguaje Unicado de Modelado prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos signican. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

•

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 técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especicación. Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del srcinal y por lo tanto facilita dicha comprensión.

•

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.

2. BREVE RESEÑA HISTÓRICA El desarrollo de UML comenzó en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation comenzaron a trabajar en la unicación de los lenguajes de modelado Booch y OMT, desde este momento fueron reconocidos mundialmente en el desarrollo de metodologías orientadas a objetos. Así, en octubre de 1995, terminaron su trabajo de unicación obteniendo el borrador de la versión 0.8 del denominado Unied Method. Hacia nes de este mismo año, Ivar Jacobson (creador de la metodología OOSE - Object Oriented Software Engineer) se unió con Rational Software para obtener nalmente UML 0.9 y 0.91 en junio y octubre de 1996, respectivamente. Igualmente, UML incorpora ideas de otros metodólogos entre los que podemos


Ingeniería 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 día llegamos hasta UML 1.4 y UML 2.0. En la siguiente gura se muestra de forma gráca y resumida la evolución de UML.

3. CARACTERÍSTICAS DE UML UML es una especicación de notación orientada a objetos. Se basa en las anteriores especicaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número 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 abstracción, simplicando la complejidad sin perder información, para que tanto usuarios, líderes y desarrolladores puedan comprender claramente las características de la aplicación. Denición formal de un metamodelo común que dene el lenguaje para expresar modelos de análisis y diseño. Un metamodelo se dene como un modelo que sirve para expresar otros modelos, y son indispensables para poder denirlos sin ambigüedades.



El método del UML recomienda utilizar los procesos que otras metodologías tienen denidos.

4. DIAGRAMAS: Vistazo General En todos los ámbitos de la ingeniería se construyen modelos, en realidad, simplicaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar, los ingenieros de software deberían igualmente construir modelos de los sistemas software. Para la construcción de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los demás, 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 utilización 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 agrupándola 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 características comunes) que componen el sistema y cómo se relacionan entre sí. Diagrama de Objetos: muestra una serie de objetos (i nstancias 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 interacción entre los objetos y los mensajes que intercambian entre sí junto con el orden temporal de los mismos. Diagrama de Colaboración: igualmente, muestra la interacción entre los objetos resaltando la organización 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, simplica el diagrama de estados modelando el comportamiento mediante ujos de actividades. Muestra el ujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el ujo de control entre objetos. Diagrama de Componentes: muestra la organización y las dependencias entre un conjunto de componentes. Se usan para agrupar clases en componentes o módulos. 42 PROGRAMA DE COMPUTACIÓN E INFORMÁTICA- IDAT


Diagrama de Despliegue (o implementación): muestra los dispositivos que se

encuentran en un sistema y su distribución en el mismo. Se utiliza para identicar Sistemas de Cooperación: Durante el proceso de desarrollo el equipo averiguará de qué sistemas dependerá el nuevo sistema y que otros sistemas dependerán 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 construcción. En el contexto del software, existen cinco vistas complementarias que son las más importantes para visualizar, especicar, 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, colaboración, estados y actividades.

•

Vista de diseño: se forma con los diagramas de clases, objetos, colaboración, estados y actividades.

•

Vista de procesos: se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos referentes a procesos.

•

Vista de implementación: se forma con los diagramas de componentes, colaboración, estados y actividades.

•

Vista de despliegue: se forma con los diagramas de despliegue, interacción, estados y actividades.

Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivos, y UML permite denir solo los necesarios, ya que no todos son necesarios en todos los proyectos. UML esta pensado para el modelado tanto de pequeños sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar


Ingeniería de Sistemas I compuestos por millones de líneas de código 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 clasica como se muestra en la gura 09.

Diagramas Estáticos 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 Dinámicos o de Comportamiento -

Diagrama de máquina de Estado Diagrama de actividad Diagrama de Caso de Uso

Diagramas

de

Interacción

(Subtipo

de

Diagramas

de

Comportamiento) - Diagrama de Secuencia - Diagrama de Comunicación - Diagrama de Tiempos(A partir de UML 2.0) - Diagrama de descripción la interacción(A partir de UML 2.0)

Figura _09: Jerarquía de los Diagramas de UML 2.0


2 CAPÍTULO Modelo de Negocio •

Modelo de Caso de Uso del Negocio

•

Modelo de Análisis 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 adopción de estos productos. Hay que entender cómo funciona el negocio que se desea automatizar para tener de que el desarrollado va a cumplir su propósito y, por esto, segarantías hace un estudio ensoftware el dominio del negocio, además de un dominio del software. Los objetivos del modelado de negocio son: • • • •

Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado (organización objetivo). Entender el problema actual en la organización objetivo e identicar potenciales mejoras. Asegurar que clientes, usuarios nales y desarrolladores tengan un entendimiento común de la organización objetivo. Derivar los requisitos del sistema necesarios para apoyar a la organización objetivo.

El modelo de negocios es una técnica paraestá comprender lospor procesos de negocios de la organización. El modelado del negocio soportado dos tipos de modelos de UML: Modelo de Casos de Uso del Negocio y Modelos de análisis del Negocios. El Modelo de Casos de Uso del Negocio describe los procesos de negocio de una empresa en términos 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 análisis 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 realización de un caso de uso del negocio puede mostrarse en diagramas en diagramas de interacción y diagramas de actividad. Una entidad del negocio representa como ouna factura, quecaso los de trabajadores toman, inspeccionan, manipulan,algo, producen utilizan en un uso del negocio. Una unidad del trabajo es un conjunto de esas entidades que conforman un todo reconocible para un usuario nal. 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, Artículo, Factura y Cuenta. También se tendrán otros diagramas para mostrar los trabajadores, sus interacciones y como utilizan las entidades de negocios y las unidades de trabajo.


Ingeniería de Sistemas I Cada trabajador, entidad del negocio y unidad de trabajo puede participar en la realización de más 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 Gestión de Préstamo: De la Solicitud al Desembolso, el dinero que se adquiere por el préstamo se desembolsa en una cuenta. En hacer Transferencia y Retirar y Depositar Dinero: El dinero se retira o se deposita en cuentas y se transere 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 señalan que el modelo de negocio está soportado por dos artefactos principales: -

Modelo de casos de uso del negocio. Modelo de análisis del negocio

El conjunto completo de artefactos del modelo de negocio, se muestra en la siguiente gura:

1. ¿Cuándo será necesario hacer el modelo de negocio? • • • • •

Cuando el grupo de trabajo es nuevo en la organización. Cuando la organización a enfrentado un reciente proceso de reingeniería de negocios. Cuando la organización esta planicando un proceso de reingeniería de negocios. Cuando el software a construir será utilizado por una porción importante de la organización. Existen ujos de trabajo complejos dentro de la organización que no están documentados. 48 PROGRAMA DE COMPUTACIÓN E INFORMÁTICA- IDAT

Ingeniería de Sistemas I •

Cuando se es un consultor en una organización en la cuál no se ha trabajado antes.

2. ¿Cuándo no será necesario hacer el modelo de negocio? • • • •

Cuando se tiene conocimiento de la estructura de la organización, de las metas, de la visión y de los clientes/usuarios. Cuando el software a construir será usado por una pequeña parte de la organización, y no tiene un efecto en el resto del negocio. Cuando los ujos de trabajo de la organización están bien documentados. Cuando el tiempo no lo permita, no todos los procesos tienen el tiempo necesario para completar un análisis del negocio.

3. Actividades para realizar un modelo de negocio • • • • • • • •

Determinar la situación de la organización Describir el actual negocio. Identicar los procesos de negocio Renar las deniciones de los procesos del negocio. Diseñar las realizaciones de los procesos del negocio. Renar roles y responsabilidades Explorar procesos automatizados Desarrollar un modelo de dominio

En este manual, trataremos las actividades más relevantes que permiten obtener los artefactos principales del negocio.



MODELO DE CASO DE USO DEL NEGOCIO 1. Determinar la situación de l a organización: El objetivo es reconocer el negocio en estudio para delimitarlo. Las actividades que se llevan a cabo son: • • • •

Identicar la misión y visión de la organización y/o áreas de estudio que correspondan y plasmarlo en visión del negocio. Identicar los objetivos del negocio, y documentarlos en objetivos del negocio. Estos objetivos son determinados por los stakeholders y responsables del negocio y serán usados para validar los casos de uso del negocio. Identicar las reglas del negocio y luego plasmarlas en el documento reglas del negocio. Elaborar una lista de términos y deniciones usados comúnmente en un glosario del negocio.

Se ha preferido reunir los documentos anteriormente mencionados en el artefacto Situación del Negocio. 2. Identicar los procesos del Negocio

Requiere haber identicado los objetivos del negocio. El equipo de trabajo debe tener claras las fronteras del negocio que está describiendo. Para ello, debe identicar y priorizar los casos de uso del negocio y los actores de negocio involucrados. Para mostrar la interacción 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 especicación de caso de uso del negocio, conocido comúnmente como BUCS (Business Use Case Specication) por las iniciales en inglés. En este documento, se indica una descripción breve del proceso de negocio. Para describir los actores del negocio y mostrar mediante un diagrama de casos de uso del negocio su asociación con los casos de uso de negocio encontrados, se utiliza el artefacto actores del negocio. 3. Renar las deniciones de los procesos de negocio:

a) Detallar la denición de los casos de uso del negocio. b) Describir cómo los casos de uso del negocio soportan los objetivos del negocio. c) Vericar que los casos de uso del negocio representan correctamente cómo el negocio es conducido. Aquí se reere a las especicaciones de caso de uso del negocio, describiendo paso a paso las actividades que se desarrollan en el proceso de negocio.



MODELO DE ANÁLISIS DEL NEGOCIO 1. Diseñar las realizaciones de los procesos del negocio Consiste en identicar todos los roles, productos, entregables del negocio y describir cómo el proceso del negocio será llevado a cabo por los trabajadores y las entidades dentro del negocio. El documento que plasma la descripción breve de trabajadores del negocio y cómo ellos manipulan las entidades del negocio es trabajadores del negocio. Además se crea el artefacto entidades del negocio para describir las entidades del negocio y especicar, mediante diagramas de estado, los estados de cada una de las entidades. Para la realización de cada proceso del negocio se crea un diagrama de clases de negocio y un diagrama de actividades de negocio. Al nalizar esta actividad, se completará cada especicación de caso de uso del negocio generado en el modelado de casos de uso de negocio, agregando al nal de cada documento, los diagramas de clases y actividades correspondientes.

ESTEREOTIPO

DESCRIPCIÓN 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 algún tipo de valor.

Representa un rol que algo o alguien externo desempeña en relación con el negocio.


Ingeniería de Sistemas I Representa un rol interno al negocio. Colabora con trabajadores de otro sector, es noticado de acontecimientos del negocio y manipula entidades de negocio para realizar sus responsabilidades. Ente manipulado por actores del negocio y trabajadores del negocio. Colección 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: • • • • •

Situación del Negocio Actores del Negocio Especicación 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 organización.

•

Interactúa con otros de business worker Manipula entidades negocios+

Ejemplos

Vendedor

Cajero

Aulxiliar de Almacén


Ingeniería de Sistemas I ¿Dónde encontrar Trabajadores de Negocio - BW? • • • •

Roles dentro del negocio Puestos o cargos dentro de la organización Personas que ejecutan los procesos o las actividades de negocio Hardware o sistemas informáticos dentro del negocio usados en ese momento.

Sugerencia para identicar 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 acción

•

No deben representar áreas, departamentos o partes de una organización sino roles en ejecución. No siempre están asociados con el nombre de un cargo en la planilla de la organización Cada trabajador de participar en al menos un caso de uso de negocio, sino participa en ningún proceso debe ser eliminado del modelo.

• •

CheckPoints • • • • • •

El nombre y la descripción deben ser claros y comprensibles (emplear sustantivos) Cada BW debe tener documentada una asociación con otro BW si se comunican entre sí. Cada BW deben de participar en un BUC Cada relación entre un BW y otros BW o BE debe ser usada en el workow de algún BUC Cada operación o actividad de un BW debe ser usada debe ser usada en el workow de algún BUC. Cada operación o actividad de un BW debe ser usada en el workow de algún BUC.

ENTIDAD DE NEGOCIO (Business Entity)

Este artefacto representa una pieza de información signicativa que es manipulada por los actores y trabajadores del negocio. Se reere al estado de la información que pasará entre cada capa como un conjunto de datos que la identican una entidad. Las entidades del negocio de una aplicación representa entidades reales y además suelen ser sustantivos, como por ejemplo: Cliente, Nómina, Factura, Depósito, 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 información con propiedades, comportamiento y semántica 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.



Ejemplos

¿Dónde encontrar entidades de negocio? • • • • • • •

Información que maneja cada trabajador del negocio Información que necesita ser ingresada, validada y consultada o comunicada en cada proceso del negocio. Objetos Físicos Informes Transacciones Informes Documentos

Sugerencias para identicar 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, información solicitada, producto, conocimiento, etc. Solo debe ser considerada información relevante y persistente al negocio.

Identicar los atributos de las clases entidades de negocio • • •

Identicar y describir la información que caracteriza a la entidad de negocio Información o propiedades que aporta la entidad del negocio en la ejecución de las actividades en que participa. Solo debe considerarse información propia de la entidad del negocio descrita y no información que pertenezca a otra.



CASO DESARROLLADO Según el ujo de trabajo propuesto desarrolle el modelo de caso de uso.

CASO: SISTEMA DE GESTIÓN ACADÉMICA Flujo de Trabajo: •

Flujo básico

1. El Alumno solicita al Asistente SA realizar un retiro o cambio de horario de un curso. 2. El Asistente SA verica si el alumno está matriculado en un determinado curso. 3. Si está matriculado en un determinado curso el Asistente SA verica si la solicitud está dentro de la fecha límite de presentación. 4. Si la solicitud está dentro de la fecha límite, se verica 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 matrícula 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 límite, esta es rechazada.

SOLUCIÓN DEL CASO: a) Actores del Negocio:


Ingeniería 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:


Ingeniería de Sistemas I f) Diagrama de Actividades del negocio



CASO PROPUESTOS CASO : “Sky ” La empresa “Sky”, es una empresa que ofrece paquetes turísticos nacionales de calidad al mejor precio del mercado, que tiene como principal objetivo mejorar la atención al cliente en un 40%. El proceso comienza cuando el Gerente Comercial ordena al Asistente Viajes la elaboración de los paquetes turísticos a vender, el Asistente se contacta con empresas operadoras (quienes brindan servicios de hotelería, taxis, tours, etc.) para realizar los servicios que va a tener el paquete turístico. Se debe tener en cuenta que cada paquete de viajes no debe tener más de 3 destinos para no saturar las visitas y la estancia del viajero sea más agradable. Los turistas deben de separar los paquetes turísticos con anticipación por lo menos 1 semana antes del viaje y así la forma de pago será más fácil 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 liquidación al Jefe de Contabilidad, quien verica la información de la liquidación y solicita información al Jefe de Ventas sobre los servicios adquiridos para comparar la información con la liquidación y está conforme el Jefe de Contabilidad registra liquidación y efectúa el pago.

ELABORAR PAQUETE TURÍSTICO •

Objetivo

Innovar la elaboración de los paquetes en un 30% •

Flujo Básico

1. El Gerente Comercial ordena la creación de paquetes turísticos al Asistente de Viajes. 2. El Asistente de Viajes dene especicaciones de paquetes turísticos 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 envían propuesta de servicios al Asistente de Viajes. 7. El Asistente de Viajes evalúa propuesta de servicios. 8. El Asistente de Viajes selecciona a la empresa operadora. 9. El Asistente de Viajes establece los costos del paquete turístico. 10.El Asistente de Viajes envía la información nal de los paquetes al gerente comercial y termina el proceso


Ingeniería 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 evalúa la propuesta de la Empresa.Operadora y ninguna oferta es satisfactoria repite el paso 6.

CASO : “Servis” La empresa “Servís”, es una empresa nanciera 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 selección del personal con sus requisitos. El Jefe de RRHH revisa la relación y autoriza la entrega al Comité de Evaluación. Luego el Comité calica las pruebas y determina la relación de candidatos aptos. El Jefe de RRHH consolida los resultados de las evaluaciones, verica las referencias laborales, y selecciona al nuevo personal. El personal tiene medidas disciplinarias denidas las cuales se detallan:

Sanción: Acción administrativa que castiga a un trabajador por haber cometido alguna falta de carácter disciplinario en el desempeño de sus funciones. Puede ser una amonestación o suspensión en mayor o menor grado dependiendo de la gravedad de la falta. Amonestación: Advertencia o llamada de atención verbal o escrita a un trabajador por haber cometido una falta de carácter disciplinario considerada menor en el desempeño de sus funciones.

MEDIDA DISCIPLINARIA •

Objetivo

Mejorar el control de los trabajadores en un 70% •

Flujo Básico

1. de Unidad evalúauna un incidente involucra a uncomunica trabajador. 2. El Si Jefe el trabajador amerita sanción elque Jefe de Unidad el motivo y el incidente mediante informe al Jefe de RRHH, sugiriendo la sanción que se podría aplicar. 3. El Jefe de RRHH evalúa 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 según corresponda, conversa con el trabajador. 6. Al realizar la evaluación cuando la falta es grave : a. El Jefe de RRHH informa a la Gerencia de Administración y recomienda


Ingeniería de Sistemas I la sanción correspondiente. b. El Gerente de Administración 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 Administración ratica o modica la sanción propuesta por el Área de RRHH. d. El Jefe de RRHH comunica al Área de Tecnología de Información para que se tomen las medidas necesarias con el acceso que tiene el trabajador a los sistemas de información. 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 suspensión y registra la sanción. •

Flujos Alternativos

7. En el punto 2, si el trabajador sólo amerita una amonestación el Jefe de Unidad amonesta verbalmente al trabajador y naliza el proceso. 8. En el punto 6 cuando la falta no es grave: a. El Jefe de Unidad genera una carta de amonestación. b. El Jefe de Unidad entrega la amonestación 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 amonestación entregada al trabajador y registra la sanción.

CASO : “Empresa ABC” La empresa “ABC” es una empresa nanciera 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 medición periódicamente del nivel de desempeño de cada trabajador con respecto al cumplimiento de las funciones asignadas. Para ello verica que se cumpla con los criterios y plazos de la evaluación establecidos en el Programa de Evaluación Anual para posteriormente vericar el resultado de la evaluación y emitir opinión imparcial sobre los casos presentados. Finalmente elabora un Informe de evaluación para consolidar los resultados en el informe nal, y enviarlo al Gerente General indicando las brechas de rendimiento, variables motivacionales. El Jefe de RRHH debido a estos resultados puede tomar la decisión de rotar al personal para controlar la correcta y oportuna alternancia de puesto de trabajo y/o cargo de un trabajador dentro de la organización.

ROTACIÓN DEL PERSONAL •

Objetivo

Mejorar productividad de los trabajadores en un 60%



Flujo Básico

1. El Jefe de RRHH elabora el Plan de Rotación Anual del personal en base a las necesidades y políticas 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 aprobación de dicho Plan. 4. El Gerente General revisa y aprueba el Plan de Rotación de Personal. 5. El Jefe de RRHH hace seguimiento al Plan de Rotación de Personal o la Solicitud de Rotación. 6. Si hay solicitud de rotación por el trabajador/Jefe de Unidad, el Jefe de RRHH evalúa el caso y coordina con el trabajador y los Jefes de las Unidades involucradas, considerando las políticas de rotación del personal. 7. El Jefe de RRHH si aprueba la solicitud presenta el informe de rotación de personal al Gerente de Administración. 8. Gerente de Administración verica y aprueba el informe de Rotación de Personal 9. El Jefe de RRHH registra condiciones de rotación y aprueba 10. El Jefe de RRHH ingresar toda la información correspondiente para el cambio de perl 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 rotación informar al trabajador o al responsable que solicitó la rotación 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 nalidad de automatizar sus procesos. El Área de Recursos Humanos (RRHH) de la nanciera desea implementar un sistema que le permita gestionar los siguientes procesos que administra: 1. Planeamiento de RRHH 2. Selección de Personal 2.1. Reclutamiento y Selección 2.2. Contratación e Inducción 3. Desarrollo del Personal 3.1. Plan de desarrollo 3.2. Capacitación 3.3. Evaluación de desempeño 3.4. Rotación de Personal


Ingeniería 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 Contratación de Personal: 1. Especicación del caso de uso del negocio 2. La Realización de los caso de uso del negocio 3. Identicación 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 continuación se detalla la especicación de caso de uso del negocio “Medidas Disciplinarias” utilizando la plantilla de RUP.

ESPECIFICACIÓN CASO DE USO DEL NEGOCIO: MEDIDAS DISCIPLINARIAS •

Breve Descripción:

El proceso permite realizar y/o coordinar las acciones necesarias para disciplinar a un trabajador con amonestaciones o sanciones. •

Flujo Básico:

1. El Jefe de Unidad evalúa un incidente que involucra a un trabajador. 2. Si el trabajador sólo amerita una amonestación. 2.1 El Jefe de Unidad amonesta verbalmente al trabajador y naliza el proceso. 3. Si el trabajador amerita una sanción: 3.1 El Jefe de Unidad comunica el motivo y el incidente mediante informe al Jefe de RRHH, sugiriendo la sanción que se podría aplicar. 4. El Jefe de RRHH evalúa 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 según corresponda, conversa con el trabajador.



7. De la evaluación, si la falta no es grave: 7.1. El Jefe de Unidad genera una Carta de Amonestación. 7.2. El Jefe de Unidad entrega la amonestación 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 Amonestación entregada al trabajador y registra la sanción. 8. Si la falta es grave: 8.1. El Jefe de RRHH informa a la Gerencia de Administración y recomienda la sanción correspondiente. 8.2. El Gerente de Administración 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 Administración ratica o modica la sanción propuesta por el Área de RRHH. 8.4. El Jefe de RRHH comunica al Área de Tecnología de Información para que se tomen las medidas necesarias con el acceso que tiene el trabajador a los sistemas de información. 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 suspensión y registra la sanción. 8.7. Si la decisión fue una suspensión 8.7.1. El Jefe de RRHH genera la Carta de Suspensión al trabajador. 8.7.2. El Jefe de RRHH entrega la Carta al trabajador con copia al Ministerio de Trabajo y Promoción del Empleo en caso sea necesario, de acuerdo a las políticas de personal. 8.7.3. El Trabajador recibe y rmar el cargo de recepción de la Carta de Suspensión. 8.7.4. El Asistente de RRHH registra la información de suspensión y archiva el cargo por la entrega de la Carta de Suspensión al trabajador. 8.8. Si la decisión fue un Cese por despido: 8.8.1. El Jefe de RRHH procede con el despido del trabajador (Ver Proceso de Cese por Despido).



Flujos Alternativos

No aplica. Para estructurar el Modelo de casos de Uso del Negocio y Modelo de Análisis ver las guras 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 gura 3. En el Modelo de Análisis del Negocio crear las carpetas: Trabajadores del negocio, Entidades del Negocio y realizaciones de casos de Uso del Negocio. Ver la gura No. 4. En la carpeta realizaciones CUN hacer el Diagrama de Actividades, para el proceso Medidas Disciplinados, como se muestra en la gura 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 identicados 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 guras 6. Luego haremos el diagrama de caso de uso del sistema, como se muestra en la gura 7.

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



Figura No 2 – Estructura del Modelo de Análisis del Negocio (MAN).

Figura No. 3. DCUN – MEDIDAS DISCIPLINARIAS



Figura No. 4 TRABAJADORES DEL NEGOCIO



S IA R A N I L P I C S I D S A D I D E M – S E D A D I IV T C A E D A M A R G IA D . 5 . o N a r u g i F



Figura No. 6. Estructura MCU

Figura No. 7. DCU – Medidas Disciplinarias



2. Modelo de Casos de Uso sin trazabilidad del Modelo del Negocio: Si nosotros describimos un proceso sin utilizar la plantilla de Especicación de Caso de Uso, lo veríamos así. Lo ideal es tener la plantilla y hacer su diagrama de actividades, para poder identicar claramente los actores y casos de uso del sistema.

PROCESO: “Selección de Personal” Para el reclutamiento y selección el Gerente de un área, se ha solicitado personal al Jefe de Recursos Humanos (RRHH), especicando el perl del cargo. El Jefe de RRHH revisa la solicitud y determina si la cantidad de personal está contemplado en el presente año. Si no lo está, lo envía al Gerente de Administración para su aprobación. Luego, revisa y determinar si el personal de la empresa puede formar parte de la selección para cubrir la vacante. Elabora un comunicado, con el cronograma del proceso de Selección y sus requisitos y lo envía por escrito o correo al Asistente Social. El Asistente Social convoca al concurso, utilizando los siguientes mecanismos: página web y aviso en el periódico o en las bolsas de trabajo de las universidades. Luego, recepciona el currículo vitae de los postulantes y registra aquello que tienen el perl solicitado. Por último, confecciona la relación de candidatos preseleccionados y lo remite al Jefe de RRHH. El Jefe de RRHH revisa la relación y autoriza la entrega al Comité de Evaluación. El Comité de Evaluación elabora la prueba de conocimientos, la cual es tomada por el Asistente de Recursos Humanos. Luego el Comité calica las pruebas y determina la relación de candidatos aptos. El Asistente Social comunica vía telefónica a los candidatos aptos para la evaluación psicológica respectiva. El psicólogo los evalúa y envía un informe al Jefe de RRHH con el resultado de los candidatos nalistas. El Jefe de RRHH consolida los resultados de las evaluaciones, verica 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 Selección y la suscribe. Por último, el Jefe de RRHH comunica a los postulantes los resultados nales. Una vez seleccionado los candidatos, se da inicio al proceso de contratación e inducción de personal. El Asistente Social entrega la carpeta de bienvenida al personal nuevo o personal promovido al nuevo cargo. •

Si se trata de una contratación a plazo indeterminado:


Ingeniería de Sistemas I El Jefe de RRHH genera un memorando de Plazo Indeterminado de Trabajo y lo envía a la Gerencia de Administración. El Gerente de Administración rma el memorando y lo envía 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 envía a la Gerencia de Administración. El Gerente de Administración rma el Contrato y el Asistente Social envía tres (3) copias de Contrato de Trabajo al Ministerio de Trabajo y Promoción del Empleo. El Tutor o Jefe inmediato elabora, revisa y aprueba el Plan de Inducción en coordinación con el Jefe de RRHH. Prepara la carpeta de Inducción con el código de ética, reglamento interno, MOF, manual de políticas y reglamentos y/o manuales (según el cargo). El proceso de Inducción se realiza en dos (2) etapas. Primero se capacita todo lo relacionado a la empresa y después las funciones del cargo ocupado. El Trabajador inicia el trabajo de campo, que consiste en la aplicación práctica de lo aprendido con la supervisión del tutor, el que evalúa y presenta un informe indicando el resultado de la inducción. El Gerente de área evalúa el informe y presenta un informe al Jefe de RRHH. El Jefe de RRHH evalúa el informe y entrega al Asistente para su archivo. Luego, comunica al trabajador los resultados de la inducción. Si es favorable el informe, se emite un nuevo contrato, sino se emite la liquidación de benecios 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 gura No. 8. En la carpeta realizaciones CUN no se hará el Diagrama de Actividades, para el proceso Capacitación 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 guras 9 y 10. Se recomienda trabajar con paquetes para cada subsistema.



L A N O S R E P E D N IÓ C C E L E S – N U C D . 8 . o N a r u ig F



l) a i c i In ( l a n o s r e P e d n ó i c c le e S – U C D – 9 . o N a r u g i F



) o d a r tu c u r t s (e l a n o s r e P e d n ó i c c e l e S – U C D – 0 1 . o N a r u g i F


Ingeniería de Sistemas I Finalmente documentamos los artefactos creados para este proceso en el rational, como se detalla a continuación. •

Identicación y documentación 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 Selección de Personal; y la Inducción y Contratación de los mismos. c. Asistente Social.- Personal del área de RRHH que apoya en el Proceso de Reclutamiento y Selección. d. Evaluador Psicológico.- Personal encargado de la evaluación Psicológica de los Postulantes. e. Postulante.- Usuario que cumple el perl y cargo y solicita ser considerado Postulante en el proceso de selección. f. Comité Evaluador.- Personas encargadas de tomar la prueba de conocimientos y entrevistas a los postulantes. •

Identicación y documentación de casos de Uso

Proceso de Reclutamiento y selección de Personal

a. Solicitar Personal.- Permite a cualquier Gerente de Área solicitar personal según el cargo y perl. b. Consultar Cuadro de asignación de Personal.- Permite al Jefe de RRHH vericar el Plan Anual de Contratación de Personal para c/u de las áreas de la empresa. c. Elaborar Cronograma – Selección.- Permite elaborar el cronograma para el proceso de selección, indicando los requisitos para el Postulante. d. Consolidad Resultados de Evaluaciones.- Permite resumir el resultado de las evaluaciones que tienen los postulantes. e. Vericar Referencias Personales.- Permite al Personal de RRHH vericar información 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 (perl), además de listar los candidatos pre-seleccionados.


Ingeniería 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 después de la Prueba de Conocimientos o Entrevista. j. Registrar Evaluación Psicológica.- Permite al Psicólogo registrar la evaluación y listar los candidatos nalistas para la Entrevista Personal. k. Enviar CV (Web).- Permite a una persona enviar su CV, para ser aceptado como postulante. Proceso de Inducción y Contratación:

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 Liquidación.- Permite al Jefe de RRHH emitir la liquidación de benecios 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.




3 CAPÍTULO 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 utilización de los casos de uso es una forma adecuada de crear este modelo.

Requerimientos: • Es una condición o capacidad a la que la aplicación o el sistema (siendo construido). •

Un requerimiento de software o aplicación puede ser denido 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 poseída por un sistema o componente del sistema para satisfacer un contrato, especicación, estándar, u otra documentación formal.

•

Naturaleza de la Especicación de Requisitos de Software. Se deben especicar los siguientes aspectos: a. b. c. d. e.

Funcionalidad Interfaz Externa Rendimiento Atributos Restricciones de diseño

•

Ambiente de la Especicación de Requisitos. Debe de estar descrita de tal manera que no describa aspectos del área de diseño o de implementación.

•

Características de los Requisitos. Los requisitos descritos deben ser: a. Completos b. Implementación Independiente c. Consistente y no Ambiguo d. e. f. g.

•

Preciso Vericable Que pueda ser leído Modicable

Aprobación del Cliente o patrocinador. Todos los requistos descritos deben contar con ella. Un punto importante a tener en cuenta es la “evolución” de los mismos y proveer mecanismos que permitan la Evolución de la Especicación de Requisitos, e incluir requisitos del Proyecto en la Especicación de Requisitos.


Ingeniería de Sistemas I Requisitos tales como: a. Costo b. Fecha de Entrega c. Criterios de Validación y Vericación

Requerimientos, que representan: • • • • •

•

Los requerimientos de usuarios representan el conjunto completo de resultados a ser obtenidos utilizando la aplicación o sistema. Los requerimientos de la aplicación deben mostrar todo lo que la aplicación o sistema debe hacer, más todas las restricciones sobre funcionalidad. Los requerimientos forman un modelo completo, representando la aplicación o sistema total a algún nivel de abstracción. Si un producto no es lo que el cliente o los usuarios quieren entonces la calidad de la construcción 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 están involucrados, incluyendo los clientes. El primer y básico rol de los requerimientos es por lo tanto la comunicación.

Buena Especicación de Requerimientos:

Un resultado primario de esta administración es la Especicación de Requerimientos, la cual dene y documenta en forma completa el comportamiento externo del sistema a ser construido. Caracterizándose por: • • • • • •

Denidos sin ambigüedad Son completos Tienen consistencia Especica el srcen Evita detalles de diseño Están enumerados

Benecios de una Buena Administración de Requerimientos

• • • •

Mejor control de proyectos complejos Mejora en la calidad del software y en la satisfacción del cliente Reducción en los retrasos y en los costos del proyecto Mejora en la comunicación del equipo

•

Facilita la conformidad con estándares y regulaciones

Los Problemas de la Administración de Requerimientos • • • • •

No son siempre obvios y tienen muchas fuentes. No son siempre fáciles de expresar en palabras. Hay muchos tipos diferentes a distintos niveles de detalle. El número puede llegar a ser inmanejable. Están relacionados a otros en una variedad de formas.


Ingeniería 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 administración 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. Pequeños reducciones en el número de errores de requerimientos rinden grandes dividendos al evitar costos de re-trabajo y días de retraso.

Captura de requisitos: • •

Los requerimientos pueden ser adecuadamente capturados y comunicados a través de Casos de Uso Los Casos de Uso son importantes instrumentos de planicación

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


Ingeniería de Sistemas I sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc. Ejemplo - Sistema de Biblioteca 1. El usuario deberá tener la posibilidad de buscar referencias bibliográcas 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 almacén de documentos. 3. A cada pedido se le deberá asignar un identicador único que el usuario podrá copiar al área de almacenamiento permanente de la cuenta. 2. Requerimientos No Funcionales •

• •

Son aquellos requerimientos que no se reeren directamente a las funciones especícas que entrega el sistema, sino a las propiedades emergentes de éste como la abilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, denen las restricciones del sistema, como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en las interfaces del sistema. Sin embargo, estos requerimientos no siempre se reeren al sistema de software a desarrollar

Ejemplos: Análisis de la especicación de Requerimientos

• • •

El sistema de biblioteca puede almacenar documentos en diferentes formatos y la intención de este requerimiento es que los visores para todos estos formatos estén disponibles. Sin embargo, el requerimiento es ambiguo puesto que no clarica que los visores para cada formato deban ser provistos. Un desarrollador bajo la presión del tiempo sencillamente podría proporcionar un visor de texto y armar que se ha cumplido el requerimiento.


Ingeniería de Sistemas I MÉTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO FUNCIONALES

Identicación de Requerimientos y Reglas del Negocio

• • •

Para identicar los requerimientos correctos del negocio primero debemos de comprender como funciona, es decir cuales son las reglas del negocio. Mientras más 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 través de un mapeo de la situación actual utilizando a un alto nivel: a. b. c. d. e. f.

El Diagrama de descomposición funcional o mapeo de procesos. Las cadenas de responsabilidad para la atención de los requerimientos Los Diagramas de Actividad Los Diagramas de Colaboración Los Diagramas de Interacción de Roles Casos de Uso del Negocio

MATRIZ DE CONSISTENCIA: Se trata de un instrumento sumamente útil para estudiar la relación causa-efecto que debe existir entre el propósito buscado por un proyecto, los resultados especícos que harán posible el cumplimiento del propósito y las actividades que subyacen y anteceden al cumplimiento de los objetivos anteriores. La matriz permite identicar varios resultados a la vez, los cuales deben guardar una relación de causalidad con el propósito. Si no se puede demostrar fehacientemente


Ingeniería de Sistemas I esa relación en forma directa, es posible que el resultado que se está planteando obtener con el proyecto no va a incidir con fuerza en el propósito y por lo tanto tampoco hay garantía de que llegue a cumplirse. En este caso, de llegarse a esa conclusión y estando ya denido el propósito, 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 relación causa-efecto con más de un resultado a la vez, pero esto es un valor agregado. Lo primero que debe hacerse es determinar, según cada resultado especicado en la matriz, cuáles son las actividades necesarias y que directamente le van a afectar en una relación causa-efecto. Cuando se halla determinado la validez de esa relación, se puede pasar a identicar a que otros resultados va a contribuir a lograr dicha actividad en forma directa, es decir también como un factor de causa-efecto. Sin embargo, es posible hacer una diferenciación con puntajes asignados al grado de inuencia directa que logrará una actividad sobre uno o más resultados, entendiéndose que el valor más 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 relación causa-efecto por una misma actividad, identicándose así la importancia de una actividad por la cantidad de resultados a los que va a beneciar. Hay que tener en cuenta que difícilmente un resultado esperado es srcinado por un solo elemento activo, requiriéndose uno o más factores complementarios. Es decir, varias variables son generalmente las causantes de lograr un buen resultado, o de generar un problema.

Descripción de Actores del Sistema Se le llama Actor a toda entidad externa al sistema que guarda una relación con este y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también 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 deniciones de rol, por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso nal. Ejemplo de matriz de descripción de actores:


Ingeniería de Sistemas I ACTOR

ASIGNADOA: Gerente general de la empresa

Gerente

Administración

Jefe de coordinación

Atención al cliente

Administración de los procesos nales de los Servicios. Se encarga del orden de los trabajos y equipos.

Recepcionista

RESPONSABILIDAD Responsable de la producción 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 día. Responsable en recepcionar y coordinar los servicios para efectuarlos a un día determinado.

En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especíco. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, preriendo en su lugar un lenguaje más cercano al usuario nal. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. Ejemplo:

Nro. C_01

CasodeUso Registrar vendedor DTV

C_02

Registrarcliente

C_03

Registrar detalle del servicio

C_04

Registrar Génesis

C_05

Registrarservicio

vendedor

Descripción Se registra cuando es nuevo. Se registra cuando es nuevo. Se registra dirección, teléfonos, tipo de servicio, etc. Se registra elGENESIS, código de la empresa cuando el servicio es por GARANTIA propia de la empresa. Se graba toda información brindada por el cliente.



C_06

Coordinar servicio con cliente

C_07

Actualizar datos del cliente

C_08

Asignarequipo

Se registra la información brindada por el cliente. Se actualizan los datos de la extranet corregidos por el propio cliente. Se asigna el equipo creado según el día.

Integración de los Casos de Uso y de Actores El Lenguaje de Modelado Unicado dene una notación gráca para representar casos de uso llamada modelo de casos de uso. UML no dene estándares para que el formato casos de uso, y así mucha gente no entiende que esta notación gráca dene la naturaleza de un caso de uso; sin embargo una notación gráca 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 están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. Ejemplo de Integración de los Casos de Uso y de Actores:


Ingeniería de Sistemas I Matriz de Caso de Uso y Requerimiento Funcional

MODELO DE CASO DE USO Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se reere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. – – – – – – – – –

Diagrama de Contexto que delimita al Sistema de información. Consolida los múltiples Casos de Uso. Se puede optar por gracar de forma que se destaque: Los CU desde una visión funcional del negocio. (Podrían convertirse en SubSistemas). Los CU utilizados por un Actor Incluir breve descripción Incluir todos los actores El Glosario de Términos nos sirve para darle consistencia a todo el modelo Podemos agrupar los CU en Paquetes en múltiples jerarquías .

Actor: •

Un actor es un agente, alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo.

•

Un actor es algo con comportamiento, como una persona (identicada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una gura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.



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 descripción de la secuencia de interacciones que se producen entre un actor y elExpresa sistema,una cuando actor usa el para llevar cabo una tarea especíca. unidadel coherente desistema funcionalidad, y se arepresenta 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 reejar la tarea especíca 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. Simplicar el CU srcinal b. Fácil entendimiento y mantenimiento c. Reutilizar el comportamiento d. Compartir entre los CU



Relaciones

Figura No. 1. Relaciones entre casos de uso

2. Relación <> • •

Dependencia entre 2 CU. CUB depende del CUI CUI ocurre obligatoriamente en el CUB. Al CUB le interesa el resultado del CUI

•• •

Se comportamiento común CU yen simplica CU de complejo CUIextrae es ABSTRACTO, es decir sólodel ocurre el contexto otro No puede ser iniciado de forma independiente por un Actor.

Figura No. 2. Relación Include

CU: Retirar Dinero Flujo Básico 1. El sistema incluye “Identicar Cliente” 2. El sistema muestra opciones 3. El Cliente selecciona “Retirar Dinero”

CU: Identicar Cliente

Flujo Básico 1. Insertar tarjeta 2. Validad tarjeta 3. Ingresa PIN 4. Verica PIN

Flujos Alternativos 89 PROGRAMA DE COMPUTACIÓN E INFORMÁTICA- IDAT


A1. No es válida la tarjeta A2. Mal el PIN

3. Relación <> • • •

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 simplica un CU complejo CUE es ABSTRACTO En ocasiones puede ser iniciado de forma independiente por un Actor.

Figura No. 3. Relación Extend

CU: Retirar Efectivo •

Flujo Básico 1. 2. 3. 4. 5. 6. 7. 8.

El ATM (sistema) incluye “Identicar Cliente” El ATM muestra opciones El Cliente selecciona “Retirar Efectivo” El Cliente ingresa cuenta y monto El ATM envía transacción al Consorcio del Banco El ATM recibe información El ATM muestra opciones El ATM dispensa billetes

9. El ATM tarjeta y el CU naliza. 10.El ATM devuelve imprime ella Voucher Puntos de extensión:

En el punto 7 del FB, si el Cliente selecciona Moneda el CU se extiende al CU “Retirar Moneda”.

CU: Retirar Moneda


Ingeniería de Sistemas I Breve Descripción Este CU es extensión del CU “Retirar Efectivo”. •

Flujo Básico 1. 2. 3. 4.

•

El Cliente ingresa el Tipo y número de monedas el ATM calcula el total del retiro y solicita conrmación El Cliente acepta El ATM dispensa las monedas y el CU naliza.

Flujos Alternativos A1. No existen Monedas

4. Relación <> entre Casos de Uso: • • •

Relación 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. Relación Generalization – Casos de Uso

Comprobar Contraseña: •

Validación de contraseña

Scanear Retina: •

Validación de puntos de retina

5. Relación <> entre Actores •

Actores con característica comunes.



Figura No. 5. Relación Generalization – Actores

ESPECIFICACIÓN DE CASO DE USO No existe estándar UML para una especicación de caso de uso, sin embargo una plantilla para una especicación sencilla de caso de uso utilizada comúnmente contiene la siguiente información: -

Nombre del caso de uso. Breve descripción. Actores implicados en el caso de uso Flujo de eventos Pre-Condiciones Post-Condiciones Puntos de extensión Requisitos especiales Prototipos

EJEMPLO DE ESPECIFICACIÓN DE LOS CASOS DE USO DEL SISTEMA Especicación de Caso de Uso: Listar Pedidos:

1. Breve Descripción: El caso de uso permite administrar los pedidos de mercancías al almacén. La atención a los pedidos se realiza mientras se encuentren en estado “No Atendidos” o “En Atención”.

2. Flujo de Eventos: Evento disparador.- El caso de uso comienza cuando el Técnico de Almacén (TA) selecciona la opción Lista de Pedidos en la interfaz principal del sistema. 92 PROGRAMA DE COMPUTACIÓN E INFORMÁTICA- IDAT


2.1. Flujo Básico

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 Atención”, “Listos para Envío” y “Enviados”. Las listas contienen los datos: código, fecha de elaboración y fecha llegada al almacén. Incluye las opciones: Atender, Consultar, Cancelar o Salir. 3. El TA selecciona un pedido de la lista de pedidos “No atendidos” o “En Atención”. 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: código y nombre, los Datos del pedido: el código del pedido, fecha de llegada al almacén, fecha de atención, dirección de envío y la Lista de productos que contiene la orden: código del artículo, descripción, cantidad solicitada, cantidad asignada, stock real, stock disponible, stock asignado. Muestra las opciones Guardar, Pasar a Envíos, Incidencias y Salir. 2. El TA almacén selecciona una línea de pedido (producto) para editarla. Para cada línea de pedido el TA puede cambiar la cantidad asignada del stock disponible en el almacén. 3. El sistema comprueba si hay stock suciente en el almacén y reserva el stock del almacén. 4. Si el TA decide modicar otra línea de pedido, vuelve al punto 2.



5. Si el TA selecciona Guardar. El sistema guarda la orden de pedido en estado “En Atención”, muestra mensaje “Pedido en atención” y cierra la interfaz ATENDER PEDIDO. 6. Si el TA selecciona Pasar a Envíos. El sistema guarda la orden de pedido en estado “Listo para Envío”, muestra mensaje “Listo para envío” 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 conrmación “¿Está seguro de No guardar los datos?” El TA conrma El sistema no almacena la información 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 sólo para lectura y la opción Salir. 2. El TA inspecciona los datos y al nalizar 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 conrmación “¿Esta seguro que desea eliminar la orden?” 2. El TA conrma la cancelación 3. El sistema cancela el pedido eliminándolo de las listas de atención. 2.5. Flujos Alternativos:

En el punto 3 del SF Atender Pedido, si el stock disponible queda en cantidad negativa, el sistema muestra el mensaje “Stock en el Límite”. El ujo continúa en el punto 2. 3. Requerimientos Especiales: El caso de uso debe estar disponible a través de Internet, previo logeo del usuario.


Ingeniería de Sistemas I Precondiciones: 1. El TA se haya logeado en el sistema. 2. Los pedidos y productos estén disponibles en el sistema. 5. Poscondiciones: 1. El pedido queda registrado en el sistema en la lista de “Pedidos en Atención”. 2. El pedido queda registrado en el sistema en la lista de “Listos para envío”. 3. El pedido queda cancelado en el sistema. 6. Puntos de Extensión: 1. Caso de Uso Registrar Incidencia, en el paso 7.1. del SF Atender Pedido. 7. Prototipo: 7.1. Listar Pedidos (Flujo Básico)


Ingeniería de Sistemas I 7.2. Atender un Pedido (Subujo):

Especicación de Caso de Uso: Buscar Usuario

1. Breve Descripción El sistema permitirá realizar la búsqueda del usuario. 2. Flujo de Eventos 2.1. Flujo Básico

1. El sistema busca al usuario. 2. El sistema muestra el código y nombre del usuario en la interfaz del caso de uso que lo invoco y el caso de uso naliza. 2.2. Flujos alternativos

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 naliza el caso de uso.


Ingeniería de Sistemas I PRIORIZACIÓN 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 económicos y de negocio.

•

Se necesita presentar el resultado del trabajo para su aprobación al Gerente del Proyecto.

•

Importante para planear el desarrollo incremental.

•

CU Críticos: •

•

CU Secundarios: • •

•

Sirven de apoyo a los casos de uso críticos. Tienen un impacto más modesto sobre la arquitectura, pero deben implementarse pronto porque responden a requerimientos de interés para los usuarios.

CU Auxiliares: • •

•

Más importantes para los usuarios porque cubren las principales tareas o funciones que el sistema ha de realizar. Denen la arquitectura básica.

No son claves para la arquitectura. Completan casos de uso críticos o secundarios.

CU Opcionales: •

Responden a funcionalidades que pueden o no estar en la aplicación, y que no son imprescindibles en las primeras versiones.

Descripción de los requerimientos funcionales y no funcionales. Requerimientos Funcionales: Nro. RF01 RF02 RF03 RF04

Descripción El sistema mostrará reportes diversos según los requerimientos del usuario. Gestión administrativa y clínica de la historia del usuario Registrará la obtención de citas de forma segura y rápida. Registrará los exámenes clínicos de los pacientes.

Prioridad Media Alta Alta Alta


Ingeniería de Sistemas I RF05 RF06 RF07 RF08 RF09 RF10 RF11

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

Media Media Media Media Alta Media Media

Requerimientos No funcionales: Nro. RF01 RF02 RF03 RF04 RF05 RF06 RF07 RF08 RF09 RF10 RF11

Descripción 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 versión de Windows Xp o posterior. El sistema debe de ser conable, realizando procesos seguros. Se deben de tener en cuenta las licencias al momento de la implantación de software. El sistema debe ser accesible al usuario que interactúe con el. La documentación proporcionada sobre el uso del software debe ser clara y concisa. La interfaz de usuario debe adecuarse a los requerimientos del usuario, mostrando grácos en los procesos que lo requieran. El sistema debe soportar la cantidad de usuarios concurrentes. El sistema debe ser accesible a posibles modicaciones futuras en su estructura. Ellenguaje deprogramación será C#

Prioridad Alta Media Baja Alta

Alta Baja Media Alta Media Media


Ingeniería de Sistemas I RESOLUCIÓN DE EJERCICIOS Descripción de los actores del sistema

Nro.

CasodeUso

CU001

Registrar pago cita

CU002

Registrar pago farmacia

CU003

Actualizar historial clínico

CU004

Consultar horario

CU005

Consular HC

CU006

Consultar stock

CU007 CU008

Registrar disponibilidad Registrar orden de análisis

Descripción 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 exámenes son registrados en este documento. Aquí se encuentra registrados los horarios de los médicos y especialidades. Si el historial clínico existe se procede a realizar el proceso siguiente en el escenario donde se encuentre, caso contrario se creará el historial clínico tomando los datos iníciales del paciente. Realiza una búsqueda del producto en la Base de Datos, en caso de que no existiera el sistema emitirá un mensaje. Para la creación de los horarios del personal. Caso de uso generado por el Doctor luego de haber analizado al paciente. Se verica la existencia de la cita en el día y horario establecido. Tratamiento que dará al conocer el medico luego de culminar la cita.

CU009

Consultar cita

CU010

Registrar diagnostico

CU011

Seleccionar tratamiento

CU012

Generar cronograma de pago

CU013 CU014

Aperturar HC Registrar paciente

CU015

Registrar análisis

CU016

Consultar orden de análisis

Los exámenes clínicos

CU017

Generar horario

Se generan los horarios disponibles para cada personal dentro de la clínica.

Tratamiento a realizar al paciente. Si el pago se realiza con tarjeta de crédito, entonces se genera el número 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 análisis.



: s e r o t c a y o s u e d s o s a c s o l e d n ó i c a r g e t n I


Ingeniería de Sistemas I Especicación de los casos de usos

Caso de uso: Generar Horario Código- Nombre Descripción Actores Requerimientos Funcional

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 clínica, cabe mencionar a: Doctores, Enfermeras, Cajeros, y Exámenes Clínicos. Jefe de Personal RF05 - Registrar y Consultar horario del personal mediante la interfaz web interna.

Referencias Especicación

Flujo Básico: 1. El caso de uso comienza cuando el Jefe de Personal solicita “Registrar Horario” en el Menú Personal. 2. El sistema muestra la interfaz “Congurar Horarios” con los siguientes campos: • Datos del Doctor: Especialidad, Listado de Doctores. • Datos del Turno: Fecha, Horarios de turno. 3. El sistema carga automáticamente: Datos de la Especialidad, Listado de Doctores, Turnos a asignar y listado de consultorios. 4. El sistema emite el caso de uso: “Vericar 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 botón para añadirlos a la lista denominada grupo de fechas. 9. El Jefe de Personal, selecciona la fecha y pulsa en el botón <>. 10.El Sistema muestra en un recuadro, el listado de consultorios clasicados por colores de acuerdo a su disponibilidad.


Ingeniería 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 botón <> 14. El sistema emite un mensaje indicado el estado de registro (registro añadido, no se pudo añadir el registro). Flujo Alternativo (Errores, excepciones, situaciones anormales)

Si en el punto 10 no se encuentran consultorios disponibles, el caso de uso naliza.

Requerimientos Especiales Pre-Condiciones 1. Usuario logeado en el sistema. 2. Lista de Especialidades, Doctores, Turnos y Consultorios disponibles.

Post-Condiciones Puntos de Extensión

Caso de uso: Registrar pago cita Código- Nombre Descripción Actores

Requerimientos Funcional

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 clínica, cabe mencionar a: Doctores, Enfermeras, Cajeros, y Exámenes Clínicos. Cajero Cita RF02 - Gestión administrativa y clínica de la historia del usuario RF03 - Registrará la obtención de citas de forma segura y rápida. 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.

Referencia Especicación


Ingeniería de Sistemas I Flujo Básico: 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 automáticamente: 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 botón <>. 9. El sistema incluye el caso de uso “Consulta horario especialidad”. 10. El sistema muestra la opción nueva cita y ver detalle en caso exista registro con los datos especicados anteriormente. 11. El sistema muestra el listado de citas generadas en la fecha indicada y doctor correspondiente. 12. El Cajero_Cita pulsa sobre la opción <>. 13. El Sistema muestra el recuadro: Búsqueda de Paciente. 14.El Cajero_Cita pulsa con el Link “Nueva Cita”. 15. El sistema muestra el cuadro de búsqueda de paciente. 16. El Cajero_Cita ingresa los el criterio de búsqueda indicado, 17. El Cajero_Cita pulsa en el botón buscar. 18. El sistema incluye el caso de uso Consultar historial clínico. 19. El sistema muestra el resultado de dicha búsqueda. 20. El Cajero_Cita selecciona los datos del paciente a registrar. 21. El Cajero_Cita pulsa en el botón <>. 22. El Sistema oculta el recuadro mostrado anteriormente. 23. El Cajero_Cita pulsa sobre el botón Generar Doc. Venta. 24. El sistema muestra la interfaz Documento de Venta. 25. El sistema carga automáticamente 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 según el tipo de documento. 29. El Cajero_Cita pulsa en el botón 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 naliza.

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 Extensión 103 PROGRAMA DE COMPUTACIÓN E INFORMÁTICA- IDAT


CASOS PROPUESTOS CASO : “FARMACIA BYC” La farmacia BYC en los últimos años ha aumentado el número de sucursales y de usuarios, lo que ha llevado a la necesidad de contar con un Sistema Información que le permita controlar las compras y ventas de cada sucursal. Cada sucursal cuenta con un almacén propio en donde puede consultar el stock de sus productos así como almacenarlos cuando estos son adquiridos. El Químico Farmacéutico podrá en el sistema registrar las órdenes de compra de forma directa sin cotización o consultado alguna cotización realizada anteriormente. Una orden de compra contiene los datos de un sólo laboratorio, y de los fármacos que pertenece a ese laboratorio y un fármaco tiene atributos: código, nombre comercial, unidad medida de presentación, unidad mínima de dispensación, valor última adquisición, descuento. El Recepcionista puede ingresar en el sistema las órdenes de ingreso de fármacos por cada orden de compra. El comprobante del proveedor es por cada ingreso y debe reejar 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 crédito sólo 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 fármacos, 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 fármacos. 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 almacén se debe controlar mediante un Kárdex, el cual es consultado por el Químico Farmacéutico.

CASO: “BIBLIOTECA El SABIO” La Biblioteca “El Sabio” del Perú desea realizar un sistema para efectuar el control de préstamos de los libros y cubículos a sus diferentes usuarios. Los libros son prestados a través de una forma denominada Solicitud de Préstamo a los diferentes usuarios, de tal manera que el usuario puede realizar su solicitud vía intranet o en una PC de la biblioteca. De la solicitud de préstamo se almacena el número de la misma, la fecha de solicitud y datos de los usuarios y libros. El sistema debe vericar 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 atención a la solicitud de préstamo y entregar el libro solicitado.



Los usuarios pueden ser de dos tipos: alumnos y profesores. Los profesores pueden solicitar hasta 5 libros y los alumnos máximo 2. La reserva de los cubículos es registrada sólo por los alumnos en donde deben indicar fecha reserva, su capacidad y cantidad de equipos con que cuenta. Los pedidos de los cubículos se efectúan a través de la Internet generándose un número único para su identicación, siendo registrado por los usuarios. También el sistema debe vericar disponibilidad de cubículos. De los pedidos de cubículos se registra la fecha del préstamo, el turno solicitado y su correspondiente aprobación que debe ser realizada por el auxiliar de biblioteca. El jefe de biblioteca también puede realizar las funciones del bibliotecario pero además 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 académico 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 sanción, fecha inicio, fecha término. Las sanciones se aplican en el momento en que el bibliotecario registra la devolución del libro.



BIBLIOGRAFÍA LIBROS: •

Modelamiento de Sistemas con UML – (Alberto Tejeda).

•

Análisis y Diseño orientado a objetos con UML y el Proceso Unicado (Stephen R. Schach).

•

El Proceso Unicado de Desarrollo de Software – (Ivar Jacobson, Grady Booch y James Rumbaugh).

•

Ingeniería del Software - Un Enfoque Practico -(R.S. Pressmam) – Sexta Edición.

•

Análisis y Diseño Orientado a Objetos de Sistemas - (Simon Bennett, Steve Mc Robb y Ray) – Tercera Edición.

•

Análisis 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


3ero Manual IngenieSistemasI

Recommend Documents