INDICE 1 INTRODUCCION. 4

Transcripción

1 INDICE INDICE 1 INTRODUCCION. 4 CAPITULO 1 METODOLOGÌAS MODERNAS PARA EL DESARROLLO DE SOFTWARE SPI (Software Process Improvement) 7 SPS (Software Process Personal) UML (Unified Modelling Language) Cascada Iterativa CAPITULO 2 RATIONAL UNIFIED PROCESS (RUP) CONCEPTOS Y FILOSOFÌA Generalidades. 21 El desarrollo Iterativo 22 Ingeniería de Requerimientos Iteraciones RUP 28 Arquitectura de Componentes.. 29 La Calidad del Software 29 CAPITULO 3 AL INTERIOR DE RATIONAL UNIFIED PROCESS (RUP) ESQUEMA DETALLADO Dimensiones del RUP Fase de Concepción.. 35 Fase de Elaboración.. 35 Fase de Construcción 36 1

2 Fase de Transición 36 Work Flows. 36 Modelamiento del Negocio.. 39 Ampliación de Requerimientos.. 40 Análisis Preliminar.. 40 Análisis Detallado 41 Revisión de Requisitos 41 Especificaciones.. 42 Diseño Arquitectónico 43 Casos de Uso.. 43 Diagrama de Clases 47 Diagrama de Objetos.. 52 Diagrama de Comportamiento 53 Diagrama de Interacción. 62 Diagrama de Implementación 66 Entidad /Relación Normalización 77 Interfaces de Entrada /Salida. 90 Construcción Base de Datos 94 Objetos de Base de Datos.. 96 Prueba de objetos.. 97 Entrega de Proyectos 107 WorkFlow de Colaboración. 107 Configuración y Administración de Cambios. 108 Administración del Proyecto 109 Medioambiente 109 CAPITULO 4 DESCRIPCION DE CASOS DE ESTUDIO USANDO RUP Plan de Desarrollo de Software 110 Detalle del modelo. 136 Análisis de Resultados

3 CONCLUSIONES RECOMENDACIONES. 150 BIBLIOGRAFIA

4 INTRODUCCIÓN El Proceso Racional Unificado o RUP (Rational Unified Process), es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. RUP es en realidad un refinamiento realizado por Rational Software del más genérico Proceso Unificado. Sus principales características son: Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software como: Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña 4

5 una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso). El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al terminar cada ciclo, cada uno de estos se divide en fases que finalizan con un hito donde se debe tomar una decisión importante: Inicio se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos Construcción: se concentra en la elaboración de un producto totalmente operativo y eficiente y el manual de usuario Transición: se implementa el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados. En el capitulo 1 abordaré el tema de las nuevas metodologías para el desarrollo de software, las mismas que garantizan un excelente producto, reducción de tiempo y costos. En el capitulo 2 describo de una manera breve las características, conceptos y filosofía del RUP, es decir lo más general del esta metodología. En el capitulo 3 detallo las dimensiones y fases del RUP, la utilización de Lenguaje de Modelado Unificado, y sobre Wolkflows o grupos de trabajo. 5

6 CAPITULO 1 METODOLOGÌAS MODERNAS PARA EL DESARROLLO DE SOFTWARE Métodos con Orientación a los Objetos SPI (Software Process Improvement) SPS (Personal Software Process) UML (Unified Modelling Language) Cascada iterativa 1. Metodologías Modernas para el Desarrollo de Software 1.1. Métodos con Orientación a los Objetos (OO) Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los lenguajes de programación, además se viene aplicando en el análisis y diseño con mucho éxito, al igual que en las bases de datos. Es que para hacer una buena programación orientada a objetos hay que desarrollar todo el sistema aplicando esta tecnología, de ahí la importancia del análisis y el diseño orientado a objetos. La programación orientada a objetos es una de las formas más populares de programar y viene teniendo gran acogida en el desarrollo de proyectos de software desde los últimos años. 6

7 Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a objetos, también se necesitará realizar un análisis y diseño orientado a objetos. El modelamiento visual es la clave para realizar el análisis orientado a objetos (OO). Desde los inicios del desarrollo de software OO han existido diferentes metodologías para hacer esto del modelamiento, pero sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML) puso fin a la guerra de metodologías. Según los mismos diseñadores del lenguaje UML, éste tiene como fin modelar cualquier tipo de sistemas (no solamente de software) usando los conceptos de la orientación a objetos; además este lenguaje debe ser entendible para los humanos y máquinas. El UML consta de todos los elementos y diagramas que permiten modelar los sistemas en base al paradigma orientado a objetos. Los modelos orientados a objetos cuando se construyen en forma correcta, son fáciles de comunicar, cambiar, expandir, validar y verificar. Este modelamiento en UML es flexible al cambio y permite crear componentes plenamente reutilizables Software Process Improvement A continuación se describe la base conceptual y fundamental para el desarrollo de un marco enfocado a la mejora de procesos software que combina las técnicas de estimación tradicionales con la utilización extensiva de modelos dinámicos de simulación como herramienta para 7

8 asesorar en el proceso de evolución entre los diferentes niveles de madurez propuestos por el modelo de referencia Modelo de Capacidad y Madurez (CMM) Simulación del Proceso de Desarrollo de Software Modelo de Simulación.- es un modelo computacional, consistente en la abstracción o representación simplificada de un sistema dinámico complejo Modelo de Simulación del Proceso Software.- se centra en determinados aspectos o procesos del desarrollo, mantenimiento o evolución de la producción de software. A continuación se indican las razones principales para la simulación del proceso software: Gestión Estratégica. La simulación puede ayudar a resolver un amplio rango de cuestiones relacionadas con la gestión estratégica. Los modelos de simulación recogen el comportamiento de la organización en una serie de parámetros que se instancian a valores diferentes según la cuestión que se trate de resolver. Los directores de proyectos pueden comparar los resultados de los diferentes escenarios simulados obteniendo un conocimiento extra que les ayude en la toma de decisiones. 8

9 Planificación La simulación del proceso software se puede aplicar tanto en la planificación inicial del proyecto como en las sucesivas planificaciones o modificaciones que se realicen conforme el proyecto progresa. Control y Gestión Operacional La simulación también puede proporcionar un soporte efectivo para las actividades de control y gestión operacional de los proyectos software. La simulación también puede favorecer el estudio de las consecuencias de un cambio en las prioridades del proyecto, en las necesidades de contratación o en la planificación inicial. Mejora del Proceso y Cambio Tecnológico. La simulación puede facilitar el proceso de toma de decisiones en el ámbito de la mejora del proceso ya que permite predecir el impacto potencial de un cambio en el proceso antes de que éste se haga efectivo en la práctica. Comprensión El propio proceso de construcción de un modelo de simulación permite ampliar el conocimiento que se tiene acerca de la organización y de sus procesos de desarrollo, ya que resulta necesario conocer y comprender correctamente los lazos de realimentación, sus efectos y los retrasos existentes en el proceso, entre otros aspectos, para que el modelo sea preciso. 9

10 Formación y Aprendizaje La simulación es un medio para que el personal pueda practicar o aprender gestión de proyectos. Un entorno de entrenamiento basado en simulación permite aprender los resultados más probables de las decisiones de gestión más frecuentes y que, a menudo, resultan incorrectas como, por ejemplo, adelantar excesivamente la etapa de codificación, eliminar las revisiones o reducir el esfuerzo asignado a las actividades de prueba. El entrenamiento basado en la simulación también ayuda a los directores de proyectos a aceptar resultados muy diferentes a los que esperaban cuando tomaron la decisión Desarrollo del Dynamic Integrated Framework for Software Process Improvement (DIFSPI) La utilización de la simulación para la mejora de procesos dentro del modelo CMM no es una idea nueva, de hecho ya propone al modelo CMM como un marco incremental excelente para la obtención de experiencia a través de la simulación de proyectos. Una de las características definitorias del empleo de modelos dinámicos en cualquier área de la ingeniería es que sea cual fuere el modelo, éste requiere satisfacer un determinado nivel de calidad o fiabilidad antes de poder ser utilizado en la práctica. De hecho, la potencia y versatilidad de los sistemas de simulación actuales facilitan en gran medida la construcción de modelos dinámicos que pueden llegar a ser realmente complejos. Sin embargo, si la 10

11 organización no dispone de la suficiente información para inicializar y definir los parámetros y funciones que gobiernan la evolución del comportamiento del modelo, éste resultará inútil. La Figura 1.1 muestra las relaciones existentes entre el nivel de madurez de una organización, la utilización de modelos dinámicos y las ventajas derivadas. Por ello, para utilizar un modelo dinámico en estos niveles será necesario definir, en primer lugar, los procesos generales de los proyectos software y las métricas requeridas para estos procesos. El proceso de diseño del modelo dinámico aporta una gran ayuda en este momento. Los datos resultantes de la simulación de un modelo dinámico pueden utilizarse en la realización de predicciones sobre la evolución del proyecto. Los modelos dinámicos favorecen la 11

12 comprensión de esta naturaleza integrada de la gestión de proyectos al describirla a través de sus procesos, estructuras e interrelaciones principales. Desde un punto de vista general, podría decirse que los proyectos se componen de procesos que pertenecen a una de las siguientes categorías principales: Proceso de Gestión de Proyectos. Esta categoría recoge a todos aquellos procesos relacionados con la descripción, organización, control y dirección del proyecto. Proceso Software o de Ingeniería. En ambos niveles, la utilización de modelos dinámicos para simular los procesos reales y para la definición y construcción de bases de datos históricas será la característica predominante. Se puede observar los procesos que componen un proyecto en la Figura

13 Utilización de la Simulación en los Diferentes Niveles de Madurez El modelo CMM proporciona un marco de trabajo incremental excelente para ganar experiencia a través de la simulación. El desarrollo de un modelo de simulación puede resultar una tarea relativamente fácil; no así validarlo con datos reales. Las organizaciones que utilicen un modelo dinámico de simulación deben poseer la información suficiente que permita validar sus procesos simulados. A continuación, se describe la aplicación de los modelos dinámicos de simulación a cada uno de los niveles del modelo CMM. Nivel 1 En este nivel es del todo recomendable introducir la idea del proceso de software como una entidad dinámica cuyo comportamiento está gobernado por lazos de realimentación. Resulta muy útil colocar a los directores de proyectos en entornos de simulación que les permitan llevar a cabo experimentos y practicar juegos de simulación. De esta manera, se pretende que el director tome contacto con los entornos de simulación y con la potencialidad y ventajas del empleo de este tipo de modelos. Nivel 2 Conforme se progresa hacia el nivel 2, las organizaciones pueden comenzar a diseñar modelos de sus procesos y examinar algunas de las propiedades de sus comportamientos. 13

14 En concreto, se pueden desarrollar modelos de gestión de proyectos muy generales (sin un alto nivel de detalle) que permitan simular aspectos tales como la planificación, el seguimiento y supervisión del proyecto. Nivel 3 Las organizaciones del nivel 3 aplican un énfasis especial sobre la ingeniería del producto, la definición formal de los procesos de ingeniería y la instrumentación de estos procesos. Ya que los procesos de ingeniería conducen muchos de los procesos de gestión, la simulación precisa del nivel de ingeniería resultará en una precisión mejorada en el nivel de gestión. El nivel 3 también otorga una gran importancia a la definición, mantenimiento y reutilización de procesos en una organización. Nivel 4 Los modelos de los niveles 3 y 4 no difieren significativamente en su nivel de detalle o instrumentación. En el nivel 4, el objetivo es operar los procesos dentro de límites de rendimiento cuantitativo. Nivel 5 Es posible comparar la salida de la simulación del cambio en un proceso, con la salida real de ese proceso sin modificar. Existe también una importante conexión entre la simulación, el flujo de trabajo y las métricas. Por tanto, la simulación soporta el flujo de trabajo apuntando al lugar donde éste debe ser 14

15 instrumentado, mientras que el flujo de trabajo proporciona los datos que permiten validar la simulación Personal Software Process El Proceso Personal de Software (PSP) se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo, Administración de configuraciones y Administración de requerimientos. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual. Los siguientes son los niveles y las Key Process Areas (KPAs) que se manejan en cada uno: Nivel 1 - Inicial: o o Seguimiento y control de proyectos Planeación de los proyectos Nivel 2 - Repetible: o o o o o Revisión entre colegas. Ingeniería del producto de software. Manejo integrado del software. Definición del proceso de software. Foco del proceso de software. Nivel 3 - Definido: o Control de calidad. 15

16 o Administración cuantitativa del proyecto. Nivel 4 - Controlado: o o o Administración de los cambios del proceso. Administración del cambio tecnológico. Prevención de defectos. El PSP tiene varias fases: PSP0: Proceso Base. PSP0.1: Complementos al proceso base. PSP1 y PSP1.1: Planeación personal. PSP2 y PSP2.1: Control de calidad personal Lenguaje de Modela do Unificado (UML) Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir. UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo. 16

17 Comportamiento Dinámico Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto y la forma como interactúa con el resto del mundo y la otra es por los patrones de comunicación de un conjunto de objetos conectados, es decir la forma en que interactúan entre sí. La visión de la interacción de los objetos se representa con los enlaces entre objetos junto con el flujo de mensajes y los enlaces entre ellos Construcciones de Implementación Los modelos UML tienen significado para el análisis lógico y para la implementación física. Un componente es una parte física reemplazable de un sistema y es capaz de responder a las peticiones descritas por un conjunto de interfaces. Un nodo es un recurso computacional que define una localización durante la ejecución de un sistema. Puede contener componentes y objetos Organización del Modelo La información del modelo debe ser dividida en piezas coherentes, para que los equipos puedan trabajar en las diferentes partes de forma concurrente. El conocimiento humano requiere que se organice el contenido del modelo en paquetes de tamaño modesto. Los paquetes son unidades organizativas, jerárquicas y de propósito general de los modelos de UML. Pueden usarse para almacenamiento, control de acceso, gestión de la configuración y construcción de bibliotecas que contengan fragmentos de código reutilizable. 17

18 Mecanismos de Extensión UML tiene una limitada capacidad de extensión pero que es suficiente para la mayoría de las extensiones que requiere el día a día sin la necesidad de un cambio en el lenguaje básico. Un estereotipo es una nueva clase de elemento de modelado con la misma estructura que un elemento existente pero con restricciones adicionales Críticas a UML A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. No se puede usar UML para señalar que un objeto es persistente, o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado Modelo Cascada Iterativa y Creciente El Desarrollo Iterativo y Creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema. 18

19 El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso. Los pasos claves en el proceso es comenzar con una implementación simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo esté implementado. En cada iteración, se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema. El proceso en sí mismo consiste de: Etapa de Inicialización Se crea una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una solución lo suficientemente simple para ser comprendida e implementada fácilmente. Para guiar el proceso de iteración, una lista de control de proyecto se crea, y esta lista contiene un historial de todas las tareas que necesitan ser realizadas. Incluye cosas como nueva funcionalidades para ser implementadas, y áreas de rediseño de la solución ya existente. Esta lista de control se revisa periódica y constantemente como resultado de la fase de análisis. Etapa de Iteración Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de proyecto, y el análisis de la versión más reciente del 19

20 sistema. La meta del diseño e implementación de cualquier iteración es ser simple, directa y modular, para poder soportar el rediseño de la etapa o como una tarea añadida a la lista de control de proyecto. El código puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis de una iteración se basa en la retroalimentación del usuario y en el análisis de las funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). 20

21 CAPITULO 2 RATIONAL UNIFIED PROCESS (RUP) Generalidades El desarrollo Iterativo Ingeniería de Requerimientos Métodos de Aproximaciones sucesivas Iteraciones RUP La Calidad del Software 1. Proceso unificado de desarrollo de software (rup) 1.1. Generalidades El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso) Características Principales Tiene una forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software 21

22 RUP provee a cada miembro del equipo de las guías de proceso, plantillas y mentores de herramientas necesarios para que el tema completo tome ventaja de, entre otras, las siguientes mejores prácticas: Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software 1.2. El desarrollo Iterativo El RUP es un proceso de desarrollo de software dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. RUP pretende implementar las mejores prácticas en ingeniería de software, con el objetivo de asegurar la producción de software de calidad, dentro de plazos y presupuestos predecibles El desarrollo iterativo Permite una comprensión creciente de los requerimientos, a la vez que se va haciendo crecer el sistema. RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero. Así se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente. RUP divide el proceso de desarrollo en ciclos, donde se obtiene un producto al final de cada ciclo. Cada ciclo se divide en cuatro Fases: 22

23 Concepción, Elaboración, Construcción, y Transición. Cada fase concluye con un hito bien definido donde deben tomarse ciertas decisiones. Estas fases se puede observar en la Figura Ingeniería de Requerimientos La Ingeniería de Requerimientos y sus Principales Actividades Qué son requerimientos? Es una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. 23

24 Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc Características de los requerimientos. Las características de un requerimiento son sus propiedades principales. Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fácil de leer y entender. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación Dificultades para Definir los Requerimientos Los requerimientos no son obvios y vienen de muchas fuentes. 24

25 Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difícil de manejar. Nunca son iguales. Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto Importancia de la Ingeniería de Requerimientos: Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son: Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.). 25

26 Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto Personal involucrado en la Ingeniería de Requerimientos Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Los roles más importantes pueden clasificarse como sigue: Usuario final: Son las personas que usarán el sistema desarrollado. Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema. Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente. 26

27 Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos, entre otros Técnicas y Herramientas Utilizadas en la Ingeniería de Requerimientos Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él. Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del usuario y soluciones potenciales. Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. A esta técnica se le conoce también como torbellino de ideas, tormenta de ideas, desencadenamiento de ideas, movilización verbal, bombardeo de ideas, sacudidas de cerebros, promoción de ideas, tormenta cerebral, avalancha de ideas, tempestad en el cerebro y tempestad de ideas, entre otras. 27

28 2.4. Iteraciones RUP En función de la cada vez mayor complejidad solicitada para los sistemas de software, ya no es posible trabajar secuencialmente, es decir definir primero el problema completo, luego diseñar toda la solución, construir el software y finalmente, testear el producto; ahora es necesario un enfoque iterativo, que permita una comprensión creciente del problema a través de refinamientos sucesivos, llegando a una solución efectiva luego de múltiples iteraciones acotadas en complejidad. RUP utiliza y soporta este enfoque iterativo que ayuda a atacar los riesgos mediante la producción de releases ejecutables progresivos y frecuentes que permiten la opinión e involucramiento del usuario. A través de las iteraciones que generan releases ejecutables, se logra detectar en forma temprana los desajustes e inconsistencias entre los requerimientos, el diseño, el desarrollo y la implementación del sistema, manteniendo al team de desarrollo focalizado en producir resultados. Un proceso iterativo incremental debería analizar el impacto de cada nuevo cambio para no destruir lo anterior completamente, sino modificarlo ligeramente para extenderlo al mínimo costo. Este es el proceso que usa el RUP y similares. 28

29 Un proceso incremental no iterativo sería implantar primero un módulo, luego el siguiente; y cada módulo nuevo agrega nueva funcionalidad pero cada uno se construye en una fase y se cierra Arquitectura de Componentes El proceso de software debe focalizarse en el desarrollo temprano de una arquitectura robusta ejecutable, antes de comprometer recursos para el desarrollo en gran escala. RUP describe como diseñar una arquitectura flexible, que se acomode a los cambios, comprensible intuitivamente y promueve una más efectiva reutilización de software. Soporta el desarrollo de software basado en componentes, módulos no triviales que completan una función clara. RUP provee un enfoque sistemático para definir una arquitectura utilizando componentes nuevos y preexistentes La Calidad del Software Que es la calidad del software? La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para 29

30 ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación. La calidad del software puede medirse después de elaborado el producto. Como obtener un software de calidad? La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software. La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación. 30

31 Como controlar la calidad del software? Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que usted no puede controlar lo que no se puede medir. El software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad de acuerdo con los estándares establecidos para el desarrollo del software. 31

32 CAPITULO 3 AL INTERIOR DE RATIONAL UNIFIED PROCESS (RUP) ESQUEMA DETALLADO Dimensiones de RUP Fases Concepción ( Inception) Elaboración Construcción Transición Work Flows WorkFlow de Proceso Modelamiento del negocio Requerimientos Ampliación de requerimientos Análisis Análisis preliminar Análisis detallado Revisión de requisitos Especificaciones Diseño Arquitectónico Casos de uso Clases Objetos Comportamiento Estados Actividad Interacción Secuencia Colaboración Implementación Componentes Despliegue Datos Entidad / Relación Normalización Interfaces de E/S Construcción BDD Objetos Prueba de objetos Enlace de Objetos Formularios e interfaces Reportes Test (prueba) 32

33 Entrega Modular De integración WorkFlow de Colaboración Configuración y Administración de cambios Administración del Proyecto Medioambiente 3. Al Interior de Rational Unified Process (rup) Esquema Detallado 3.1. Dimensiones de RUP RUP provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. El Proceso Unificado tiene dos dimensiones: Un Eje Horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento Un Eje Vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza. La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos. 33

34 La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles Fases del RUP El proceso iterativo de RUP se organiza en fases, cada fase se concluye con una piedra de milla principal (ver Figura 3.1). Es importante resaltar que la inclusión de piedras de millas o puntos de revisión, es sumamente importante y en estos puntos se revisan los requerimientos establecidos para cada fase, basados en los controles de calidad. De esta manera, si un producto o proceso no pasa el punto de revisión de calidad, se rediseña o se cancela, evitando así, los problemas de coste extra y de productos de mala calidad, que no satisfacen los requerimientos establecidos a nivel educativo, comunicacional, técnico y de diseño gráfico. Los puntos de revisión están basados a su vez en cuestionarios elaborados a 34

35 partir de métricas establecidas producto de la experiencia y de la investigación. A continuación se presentan los objetivos de cada fase, junto con una tabla comparativa especificando las actividades que se agregaron para el desarrollo de software educativo según la metodología de RUP Fase de Comienzo o Inicio Está principalmente dirigida al entendimiento de los requerimientos y determinar el alcance del esfuerzo de desarrollo. Se define la idea, la visión y el alcance del proyecto. Esta fase incluye la fase de análisis y diseño. Se incluye un análisis de las necesidades educativas y del entorno educativo, así como el diseño instruccional del proyecto. En este plan creativo se integra el trabajo de diseñadores gráficos, analistas de sistemas y docentes especialistas en el área. Esta fase se culmina con los objetivos del ciclo de vida Fase de Elaboración Planificar las actividades necesarias y los recursos requeridos, especificando las características y el diseño de la arquitectura del software. Esta fase culmina con la arquitectura del ciclo de vida. 35

36 Fase de Construcción Desarrollar el producto y evolucionar la visión; la arquitectura y los planes hasta que el producto en una primera versión esté listo para ser enviado a la comunidad de usuarios. Esta fase culmina con la capacidad inicial de operación Fase de Transición Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío, entrenamiento, soporte y mantenimiento del producto hasta que el cliente esté satisfecho. Esta fase culmina con la versión de producto, la cual a su vez concluye el ciclo Work Flows Definición Workflow, entendido como el flujo de procesos administrativos o de negocio, es el conjunto de actividades o tareas realizadas en secuencia o en paralelo por dos o más miembros de un equipo de trabajo para lograr un objetivo común siguiendo unas reglas de negocio preestablecidas. Si una sola persona realiza la tarea, no realiza workflow. Como su nombre lo sugiere, una actividad es workflow si "fluye" de un individuo a otro. Si un proceso no sigue unas reglas y ruta preestablecidas, no se trata de workflow, sino de un proceso de colaboración. 36

37 Tipos de Workflow Una vez posicionado el workflow dentro de la categoría más amplia de soluciones de groupware, se presentan los diversos tipos de aplicaciones de workflow, se segmentará el mercadeo de workflow y las diferentes categorías de producto. Existen tres tipos diferentes de aplicaciones de workflow: Workflow de Producción Workflow Colaborativo Workflow Administrativo Workflow de Producción En las aplicaciones de workflow de producción, el workflow es la tarea principal de los participantes. Dicho personal puede tener actividades adicionales en su trabajo diario, pero fundamentalmente la realización de workflow. El workflow de producción suele estar circunscrito a un sólo departamento, la escalabilidad, o capacidad de "crecer" no es importante Workflow Colaborativo Involucra procesos estructurados o semi-estructurados que permiten a varias personas participar en un grupo de trabajo, ejemplos de ello lo constituyen el diseño arquitectónico o ingenieril, generación de informes, producción de material publicitario, revisión de documentos legales, etc. Por tanto, las 37

38 características esenciales de workflow colaborativo son las siguientes: El "documento" y el "proceso" son claves. Es importante para la aplicación preservar la integridad tanto del documento como del proceso. El workflow colaborativo debe ser muy flexible ya que el trabajo creativo puede tomar rumbos inesperados. Las soluciones de workflow colaborativo suelen estar centradas en el "documento" Workflow Administrativo Involucra procesos administrativos tales como ordenes de compra, hojas de tiempos y movimientos, reportes de gastos, cambios de ordenes, reportes de calidad y muchas otras actividades que traspasan las barreras departamentales e inclusive de la empresa misma. Los atributos de una buena herramienta son: Existen un gran número de procesos administrativos en cada organización, por ello la solución debe ser capaz de manejar muchos procesos diferentes. El workflow administrativo es diferente para cada organización y también cambia con frecuencia; de ahí la gran importancia de poder cambiar los procesos fácilmente. 38

39 El workflow administrativo está destinado a cada escritorio y se prevé que será el segmento más grande del mercado del workflow Modelamiento del Negocio Identificar el área correcta para cambiar y mejorar es un objetivo supremo para el éxito total de una organización. Los peligros de poner en marcha el mejoramiento de un proceso del negocio, sin tener un claro entendimiento de cómo impactarán estos cambios a la empresa, pueden ser sustanciales. Por tanto, son necesarias herramientas que ayuden a los gerentes a entender fácilmente sus procesos de negocio y cómo afectarán las modificaciones de esos procesos a la compañía en su conjunto. El método de Modelamiento del negocio es una técnica para modelar procesos del negocio. Los modelos del negocio proporcionan maneras de expresar procesos del negocio o estrategias en términos de actividades económicas y comportamiento colaborativo, así que permiten entender mejor los procesos del negocio y a los participantes de estos procesos. Los modelos son provechosos para documentar, comprender y comunicar la complejidad. Documentando procesos del negocio desde varias perspectivas, los modelos del negocio pueden ayudan a los gerentes a entender su entorno Modelamiento de Negocios e Investigación Operacional La simulación de negocios ha crecido a partir de la investigación de operaciones de los años 50 s. Con la llegada de computadoras, cada vez 39

40 más baratas y de gran potencia, y el software de uso cada vez más sencillo, ahora las técnicas de modelamiento de negocios permiten que incluso gerentes no técnicos prueben y diseñen varias opciones o panoramas, para ayudarse en la toma de decisiones. Otro factor que ha contribuido al incremento del uso del método de modelamiento de negocios, es el aumento de la velocidad del cambio en los negocio. No hay suficiente tiempo de probar productos nuevos en la realidad, y corregir errores, una vez que estos se han producido, es a menudo extremadamente costoso Ampliación de Requerimientos Análisis Análisis Preliminar El primer problema que se presenta es la captura de los requisitos del usuario. Para empezar, necesitamos recoger los requisitos de los usuarios o clientes de una manera sistemática y organizada. Para ello precisamos de unas directrices o líneas guía, ya que en general los usuarios expresan los requerimientos de la aplicación de forma muy variable, tanto en la forma como en el contenido. Nos interesa pues sistematizar la captura, con el fin de hacer los requisitos manejables y analizables. 40

41 Análisis Detallado Una vez conseguidos los requisitos, pasamos a la fase de análisis. En ella, lo que haremos es analizar los requisitos obtenidos de los usuarios con el fin de comprenderlos, y a partir de ellos desarrollar una especificación de la aplicación, que deberá ser completa y consistente, y deberá estar expresada de una manera al menos semi formal, no simplemente textual. En este proceso, encontraremos habitualmente gran cantidad de problemas en los requisitos, áreas no especificadas, requisitos contradictorios, y afirmaciones (aparentemente) vagas e irrelevantes. Eso nos llevará de vuelta a los usuarios con el fin de mejorar la calidad de los requisitos: pero debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y el porqué Revisión de Requisitos Para un sistema del que se sabe bien lo que se espera de él, y con relativa estabilidad de los requisitos durante el desarrollo, resultaría más apropiado un modelo de gestión formal que uno ágil, pero siempre que se lleve a cabo una de las partes más difíciles los requisitos. Muchas veces se eligen ciclos de desarrollo iterativo sobre prototipado, no por la incertidumbre del sistema, sino para eludir las tareas de la ingeniería formal de requisitos. 41

42 Los requisitos suelen ser asignatura pendiente en muchos proyectos de software. Obtenerlo, analizarlos y especificarlos sin ambigüedades ni omisiones, de forma que resulten verificables y cuantificablemente medibles no es fácil. Y si no resulta fácil con los requisitos funcionales, cuando se trata de requisitos de seguridad, el terreno se vuelve aún más difícil Especificaciones Escribir una especificación es un gran modo de fijar todas esas molestas decisiones de diseño, grandes y pequeñas, que quedan disimuladas si no tienes una especificación. Incluso las decisiones de poca entidad pueden quedar fijadas por una especificación. Por ejemplo, si estáis construyendo un sitio web en el que la gente se puede dar de alta, todos podéis estar de acuerdo en que, si un usuario pierde su contraseña, se la enviaréis por . Magnífico. Pero no es suficiente para escribir el código. Para escribir el código, necesitas saber las palabras precisas que irán en el . En la mayoría de las empresas, a los programadores no se les confían palabras que un usuario pudiera llegar a ver (y por buenas razones, la mayor parte de las veces). Por tanto, es probable que alguien de marketing o relaciones públicas o que haya estudiado filología sea requerido para que defina el texto preciso del mensaje. 42

43 Diseño Arquitectónico Casos de uso Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje. No pertenece estrictamente al enfoque orientado a objeto, es una técnica para captura de requisitos. Los Casos de Uso son descripciones de la funcionalidad del sistema; y están basados en el lenguaje natural, es decir, es accesible por los usuarios Actores Principales: personas que usan el sistema. Secundarios: personas que mantienen o administran el sistema. Material Externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados. Otros Sistemas: sistemas con los que el sistema interactúa. La misma persona física puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempeñado. Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario. Los casos de uso intervienen durante 43

44 todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso. Un escenario es una instancia de un caso de uso. En la Figura 3.2 se puede observar un ejemplo de caso de uso, con sus diferentes actores. 44

45 UML Define Cuatro Tipos de Relación en los Diagramas de Casos de Uso Comunicación: indica la comunicación entre el actor y el caso de uso. Inclusión: una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino. «include» reemplazó al denominado «uses» Extensión: el Caso de Uso origen extiende el comportamiento del Caso de Uso destino. «extend» Herencia: el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía. En la Figura 3.3 se puede observar las relaciones en los diagramas de Caso de Uso. 45

46 Parámetros para la Construcción de un Caso de Uso Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a cada Caso de Uso. Preguntas clave: Cuáles son las tareas del actor? Qué información crea, guarda, modifica, destruye o lee el actor? Debe el actor notificar al sistema los cambios externos? Debe el sistema informar al actor de los cambios internos? La Descripción del Caso de Uso Comprende El inicio: cuándo y qué actor lo produce? El fin: cuándo se produce y qué valor devuelve? La interacción actor-caso de uso: qué mensajes intercambian ambos? Objetivo del caso de uso: qué lleva a cabo o intenta? Cronología y origen de las interacciones Repeticiones de comportamiento: qué operaciones son iteradas? Situaciones opcionales: qué ejecuciones alternativas se presentan en el caso de uso? 46

47 Diagrama de Clases El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones. En la figura 3.1, de puede observar el diagrama de clases Mecanismos de Abstracción: Clasificación / Instanciación Composición / Descomposición Agrupación / Individualización 47

48 Especialización / Generalización La clasificación es uno de los mecanismos de abstracción más utilizados. La clase define el ámbito de definición de un conjunto de objetos, y cada objeto pertenece a una clase, Los objetos se crean por instanciación de las clases. Cada clase se representa en un rectángulo con tres compartimientos: nombre de la clase atributos de la clase operaciones de la clase Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que son: (-) Privado: es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++) (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original. (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación) 48

49 Relaciones entre Clases Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relación son: Asociación y Agregación (vista como un caso particular de asociación) Generalización/Especialización. Las relaciones de Agregación y Generalización forman jerarquías de clases Asociación La asociación expresa una conexión bi direccional entre objetos. Una asociación es una abstracción de la relación existente en los enlaces entre los objetos. Puede determinarse por la especificación de multiplicidad (mínima...máxima) Uno y sólo uno 0..1 Cero o uno M..N Desde M hasta N (enteros naturales) Cero o muchos 0..* Cero o muchos 1..* Uno o muchos (al menos uno) 49

50 Agregación: La agregación representa una relación parte_de entre objetos. En UML se proporciona una escasa caracterización de la agregación. Esta relación puede ser caracterizada con precisión determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes. Una agregación se podría caracterizar según: Puede el objeto parte comunicarse directamente con objetos externos al objeto agregado? No => inclusiva Si => no inclusiva Puede cambiar La composición del objeto agregado? Si => dinámica No => estática Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la abstracción de una parte del dominio. Un Diagrama de Objetos representa una situación concreta del dominio. Las clases abstractas no son instanciadas. 50

51 Generalización Permite gestionar la complejidad mediante un ordenamiento taxonómico de clases, se obtiene usando los mecanismos de abstracción de Generalización y/o Especialización. La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general. Los nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada. Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre están disponibles en sus clases hijas. La Generalización y Especialización son equivalentes en cuanto al resultado: la jerarquía y herencia establecidas. Generalización y Especialización no son operaciones reflexivas ni simétricas pero sí transitivas. La especialización es una técnica muy eficaz para la extensión y reutilización. La noción de clase está próxima a la de conjunto. Dada una clase, podemos ver el conjunto relativo a las instancias que posee o bien relativo a las propiedades de la clase. Generalización y especialización expresan relaciones de inclusión entre conjuntos 51

52 Diagrama de Objetos Objeto es una entidad discreta con límites bien definidos y con identidad, es una unidad atómica que encapsula estado y comportamiento. La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento. El Objeto es reconocido también como una instancia de la clase a la cual pertenece. La encapsulación presenta tres ventajas básicas: Se protegen los datos de accesos indebidos El acoplamiento entre las clases se disminuye Favorece la modularidad y el mantenimiento Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de un determinado instante de tiempo que posee un valor específico (Un objeto puede caracterizar una entidad física -coche-) y como un poseedor de identidad que tiene distintos valores a lo largo del tiempo. Cada objeto posee su propia identidad exclusiva y se puede hacer referencia a él mediante una denominación exclusiva que permite accederle. El Modelado de Objetos permite representar el ciclo de vida de los objetos a través de sus interacciones. En UML, un objeto se representa por un rectángulo con un nombre subrayado como se puede ver en la Figura

53 La regla general para la notación de instancias consiste en utilizar el mismo símbolo geométrico que el descriptor. En la instancia se muestran los posibles valores pero las propiedades compartidas sólo se ponen de manifiesto en el descriptor. La notación canónica es un rectángulo con tres compartimientos. En el primero va el nombre del objeto, en el segundo sus atributos y en el tercero sus operaciones. Este último puede ser omitido si así se prefiere Diagrama de Comportamiento Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro. 53

54 Estos diagramas son útiles sólo para los objetos con un comportamiento significativo. Cada objeto está en un estado en cierto instante. El estado está caracterizado parcialmente por los valores algunos de los atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento Diagrama de Estado Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente) Eventos Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas: Condición que toma el valor de verdadero o falso Recepción de una señal de otro objeto en el modelo Recepción de un mensaje Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular 54

55 El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase que lo nombre Envío de Mensajes Además de mostrar y transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje Transición Simple Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una línea sólida entre dos estados, que puede venir acompañada de un texto Transición Interna Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado. 55

56 Acciones: Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento Generalización de Estados: Podemos reducir la complejidad de estos diagramas usando la generalización de estados. Distinguimos así entre super estado y sub estados. Un estado puede contener varios sub estados disjuntos. Los subestados heredan las variables de estado y las transiciones externas. La agregación de estados es la composición de un estado a partir de varios estados independientes. La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto Subestados 56

57 Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior Transacción Compleja Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado Transición a Estados Anidados Una transición de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad) Transiciones Temporizadas Las esperas son actividades que tienen asociada cierta duración. La actividad de espera se interrumpe cuando el evento esperado tiene lugar. 57

58 Este evento desencadena una transición que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado. Todo lo expuesto anteriormente se puede observar en la Figura

59 Diagrama de Actividades El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de las acciones y usado para especificar: Un método Un caso de uso Un proceso de negocio (Workflow) Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una operación. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Los grafos de actividades se muestran en diagramas de actividades. Las actividades se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad. Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. Los parámetros de entrada y salida de una acción se pueden mostrar usando las relaciones de flujo que conectan la acción y un estado de flujo de objeto. Un grafo de actividades contiene estados de actividad que representa la ejecución de una secuencia en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En 59

60 vez de esperar un evento, como en un estado de espera normal, un estado de actividad espera la terminación de su cómputo. Cuando la actividad termina, entonces la ejecución procede al siguiente estado de actividad dentro del diagrama. una transición de terminación es activada en un diagrama de actividades cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explícitos, peor pueden ser abortados por transiciones en estados que los incluyen. Un grafo de actividades puede contener también estados de acción, que son similares a los de actividad pero son atómicos y no permiten transiciones mientras están activos. Los estados de acción se deben utilizar para las operaciones cortas de mantenimiento. Un diagrama de actividades puede contener bifurcaciones, así como divisiones de control en hilos concurrentes. los hilos concurrentes representan actividades que se pueden realizar concurrentemente por los diversos objetos o personas. La concurrencia se representa a partir de la agregación, en la cual cada objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultáneamente o en cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que permite el control de concurrencia además del control secuencial, esto se puede observar en l a Figura

61 Un estado de actividad se representa como una caja con los extremos redondeados que contiene una descripción de actividad. Las transacciones simples de terminación se muestran como flechas. Las ramas se muestran como condiciones de guarda en transiciones o como diamantes con múltiples flechas de salida etiquetadas. Una división o una unión de control se representan con múltiples flechas que entran o salen de la barra gruesa de sincronización. 61

62 Cuando es necesario incluir eventos externos, la recepción de un evento se puede mostrar como un disparador en una transición, o como un símbolo especial que denota la espera de una señal. A menudo es útil organizar las actividades en un modelo según su responsabilidad. Esta clase de asignación puede mostrarse organizando las actividades en regiones distintas separadas por líneas en el diagrama. Debido a su aspecto, esto es conocido como Calles. Un diagrama de actividades puede mostrar el flujo de objetos como valores. Para un valor de salida, se dibuja una flecha con línea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja una flecha con línea discontinua desde el objeto a una actividad Diagramas de Interacción La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripción de un objeto, que desempeña un determinado papel dentro de una interacción, distinto de los otros objetos de la misma clase. Esta visión proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de control a través de muchos objetos. La vista de interacción se exhibe en dos 62

63 diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos individuales y centrados en objetos cooperantes. Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interacción muestran cómo se comunican los objetos en una interacción. Existen dos tipos de diagramas de interacción: el Diagrama de Colaboración y el Diagrama de Secuencia Diagrama de Secuencia El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las interacciones, muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. El Diagrama de Colaboración ofrece una mejor visión espacial mostrando los enlaces de comunicación entre objetos, muestra las relaciones entre objetos y son mejores para comprender todos los efectos que tiene un objeto y para el diseño de procedimientos. El diagrama de Colaboración puede obtenerse automáticamente a partir del correspondiente diagrama de Secuencia (o viceversa), como se puede ver en la Figura

64 Características Muestra la secuencia de mensajes entre objetos durante un escenario concreto Cada objeto viene dado por una barra vertical El tiempo transcurre de arriba abajo Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua Diagrama de Colaboración Es una descripción de una colección de objetos que interactúan para implementar un cierto comportamiento dentro de un 64

65 contexto. Describe una sociedad de objetos cooperantes unidos para realizar un cierto propósito. Una colaboración contiene ranuras que son rellenadas por los objetos y enlaces en tiempo de ejecución. Una ranura de colaboración se llama Rol porque describe el propósito de un objeto o un enlace dentro de la colaboración. Un rol clasificador representa una descripción de los objetos que pueden participar en una ejecución de la colaboración, un rol de asociación representa una descripción de los enlaces que pueden participar en una ejecución de colaboración. Un rol de clasificador es una asociación que está limitada por tomar parte en la colaboración. Las relaciones entre roles de clasificador y asociación dentro de una colaboración sólo tienen sentido en ese contexto. En general fuera de ese contexto no se aplican las mismas relaciones. Una Colaboración tiene un aspecto estructural y un aspecto de comportamiento. El aspecto estructural es similar a una vista estática: contiene un conjunto de roles y relaciones que definen el contexto para su comportamiento. El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados a los roles. Tal conjunto de mensajes en una colaboración se llama Interacción. Una colaboración puede incluir una o más interacciones, como se puede observar en la Figura

66 Diagrama de Implementación Diagramas de Componentes Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones. Muestran las opciones de realización incluyendo código fuente, binario y ejecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente. Un diagrama de componentes representa las dependencias entre componentes software, incluyendo componentes de código fuente, componentes del código binario, y componentes ejecutables. Un módulo de software se puede representar como componente. Algunos componentes existen en tiempo de 66

67 compilación, algunos en tiempo de enlace y algunos en tiempo de ejecución, otros en varias de éstas. Un componente de sólo compilación es aquel que es significativo únicamente en tiempo de compilación. Un componente ejecutable es un programa ejecutable. Un diagrama de componentes tiene sólo una versión con descriptores, no tiene versión con instancias. Para mostrar las instancias de los componentes se debe usar un diagrama de despliegue. Un diagrama de componentes muestra clasificadores de componentes, las clases definidas en ellos, y las relaciones entre ellas. Los clasificadores de componentes también se pueden anidar dentro de otros clasificadores de componentes para mostrar relaciones de definición. Un diagrama que contiene clasificadores de componentes y de nodo se puede utilizar para mostrar las dependencias del compilador, que se representa como flechas con líneas discontinuas (dependencias) de un componente cliente a un componente proveedor del que depende. Los tipos de dependencias son específicos del lenguaje y se pueden representar como estereotipos de las dependencias. El diagrama también puede usarse para mostrar interfaces y las dependencias de llamada entre componentes, usando flechas con 67

68 líneas discontinuas desde los componentes a las interfaces de otros componentes. El diagrama de componente hace parte de la vista física de un sistema, la cual modela la estructura de implementación de la aplicación por sí misma, su organización en componentes y su despliegue en nodos de ejecución. Esta vista proporciona la oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos. La vista de implementación se representa con los diagramas de componentes como se puede observar en la Figura

69 Diagramas de Despliegue Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instacias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como un computador, un dispositivo o memoria. Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos. Las instancias de los nodos pueden contener instancias de ejecución, como instancias de componentes y objetos. El modelo puede mostrar dependencias entre las instancias y sus interfaces, y también modelar la migración de entidades entre nodos u otros contenedores, como se puede observar en la Figura

70 Datos Entidad / Relación El diagrama de entidad-relación (también conocido como DER, o diagrama E-R) es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema. Para el analista, el DER representa un gran beneficio, porque enfatiza las relaciones entre almacenes de datos en el DFD que de otra forma se hubiera visto sólo en la especificación de procesos. Por ejemplo, un DER típico se muestra en la Figura Cada una de las cajas rectangulares corresponden a un almacén de datos 70

71 en DFD y puede verse que hay relaciones que normalmente no se aprecian en un DFD. Hay cuatro componentes principales en un diagrama de entidadrelación: 1. Tipos de objetos. 2. Relaciones. 3. Indicadores asociativos de tipo de objeto. 4. Indicadores de supertipo/subtipo Tipos de Objetos El tipo de objeto se representa en un diagrama de entidadrelación por medio de una caja rectangular. Representa una colección de objetos (cosas) del mundo real cuyos miembros individuales o instancias tienen las siguientes características: 71

72 Cada una puede identificarse de manera única por algún medio. Por ejemplo, si se tiene un tipo de objeto conocido como cliente, debemos ser capaces de distinguir uno de otro (tal vez por un número de cuenta, por su apellido, o por su número de Seguro Social). Cada uno juega un papel necesario en el sistema que se construye, es decir, para que el tipo de objeto sea legítimo, debe poder decirse que el sistema no puede operar sin tener acceso a esos miembros. Cada uno puede describirse por uno o más datos. Es decir, un cliente puede describirse por medio de datos tales como nombre, domicilio, límite de crédito y número telefónico. El objeto es algo material del mundo real, y el tipo de objeto es su representación en el sistema. Sin embargo, un objeto pudiera ser algo no material: por ejemplo, horarios, planes, estándares, estrategias y mapas. Una persona (o cualquier cosa material) pudiera ser diversos tipos de objetos distintos en distintos modelos de datos, o incluso en un mismo modelo. Juan Pérez, por ejemplo puede ser empleado en un modelo de datos y cliente en otro. También pudiera ser empleado y cliente dentro del mismo modelo. 72

73 Relaciones Una relación representa un conjunto de conexiones entre objetos, y se representa por medio de un rombo. La Figura 3.13 muestra una relación sencilla, que pudiera existir entre dos o más objetos. Cada instancia de la relación representa una asociación entre cero o más ocurrencias de un objeto y cero o más ocurrencias del otro. Así, en la figura 4.2.3, la relación etiquetada como compras puede contener las siguientes instancias individuales: Instancia 1: el cliente 1 compra el artículo 1 Instancia 2: el cliente 2 compra los artículos 2 y 3. Instancia 3: el cliente 3 no compra ningún artículo. La relación representa algo que debe ser recordado por el sistema: algo que no pudo haberse calculado ni derivado mecánicamente. Así, el modelo de datos de la figura indica que existe alguna razón relacionada con el usuario para recordar el hecho de que el cliente 1 compra el artículo 1, etc. Y también indica que no existe nada priori que hubiera permitido determinar que el cliente 1 compró el artículo 1 y nada más. 73

74 Notación Alternativa para Relaciones El diagrama E-R son multidireccionales, esto es, puede leerse siguiendo cualquier dirección. Y no muestran cardinalidad, es decir, no muestran el número de objetos que participan en la relación. Una notación alternativa utilizada por algunos analistas muestra tanto la cardinalidad como la ordinalidad Indicadores Asociativos de Tipo de Objeto El indicador asociativo de tipo de objeto representa algo que funciona como objeto y como relación. Por ejemplo, un cliente que adquiere un artículo. En donde la relación de compra no hace más que asociar un cliente con uno o más artículos. Pero suponga que existen datos que deseamos recordar acerca de cada instancia de una compra (por ejemplo a qué hora del día se hizo). Dónde se podría almacenar dicha información? "Hora del día" no es un atributo de cliente, ni de artículo. Más bien, se asocia "Hora del día" con la compra misma, y esto se muestra en un diagrama como el que ilustra la Figura

75 Nótese que compra ahora se escribe dentro de una caja rectangular conectada por medio de líneas dirigidas, a un rombo de relación sin nombre. Esto pretende indicar que compra funciona como: Un tipo de objeto, algo acerca de lo cual se desea almacenar información. En este caso la hora en la cual se realizó la compra y el descuento, que se dio al cliente. Una relación que conecta los dos tipos de objetos cliente y artículo. Lo que significa aquí es que cliente y artículo se mantienen solo. Existirían con o sin la compra Indicadores de Subtipo/Supertipo Los tipos de objetos de subtipo/supertipo consisten en tipos de objeto de una o más subcategorías, conectados por una relación. La Figura 3.15 muestra un subtipo /supertipo típico: la categoría general es empleado y las subcategorias son empleados asalariados y empleados por horas. Nótese que los subtipos se conectan al supertipo por medio de una relación sin nombre. Note también que el supertipo se conecta con una línea que contiene una barra. 75

76 Reglas para la Construcción de Diagramas de Entidad- Relación. El primer DER típicamente se creará a apartir de entrevista iniciales con el usuario, y de su conocimiento de la materia en cuanto al negocio del usuario. Después de desarrollar el primer DER, el siguiente paso es asignar los datos del sistema a los diversos tipos de objetos. Se supone, que se sabe cuales son los datos. Esto puede suceder en cualquier de tres maneras: Si el modelo del proceso (DFD) ya se ha desarrollado o se está desarrollando paralelamente al modelo de datos, entonces el diccionario de datos ya existirá. Si el modelo del proceso no se ha desarrollado o no tiene intención de desarrollar, entonces pudiera tener que empezar por entrevistar a todos los usuarios apropiados para construir una lista exhaustiva de datos y sus definiciones. Si está trabajando con un grupo de administración de datos, hay una buena probabilidad de que ya exista un diccionario de datos, que podría obtener durante el proyecto. Existe un número de situaciones en las que los refinamientos del DER llevan a la eliminación de tipos de objetos y relaciones redundantes o erróneas. Las más comunes son: Tipos de objetos que consisten en un identificador. 76

77 Tipos de objetos para los cuales existe una sola instancia. Tipos asociativos de objetos flotantes. Relaciones derivadas Normalización Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataba de manipular los datos. Por ejemplo, vea la base de datos Mi Tienda. Si almacena todos los datos en la tabla Clientes, ésta podría verse como se muestra a continuación: Clientes ID_Cliente Nombre Apellidos Nombre_Producto1 Costo_Producto1 Imagen_Producto1 Nombre_Producto2 Costo_Producto2 Imagen_Producto2 77

78 Fecha_Pedido Cantidad_Pedido Nombre_Cia_Envios La tabla se ha descrito de manera abreviada pero aun así representa la idea general. Cómo podría añadir un nuevo cliente en su tabla Clientes? Debería añadir un producto y un pedido también. Qué tal si quisiera emitir un informe de todos los productos que vende? No podría separar fácilmente los productos de los clientes con una simple instrucción SQL. Lo bello de las bases de datos relacionales, si están bien diseñadas, es que puede hacer esto fácilmente. La normalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos menos compleja agrupando cosas similares juntas. Las guías que la normalización provee crean el marco de referencia para simplificar la estructura. En la base de datos de muestra es fácil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guías de la normalización, podría crear las tablas basándose en estos grupos. El proceso de normalización tiene un nombre y una serie de reglas 78

79 para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco irá entendiendo el proceso, así como las razones para hacerlo de esta manera. A la mayoría de la gente le encantan las hojas de cálculo por la forma en la que manejan sus datos. El tiempo que le lleve reconfigurar su esquema para ajustarlo al proceso de normalización, siempre será bien invertido. Al fin y al cabo, esto le tomará menos tiempo que el que tendría que invertir, para cortar y pegar sus columnas de datos para generar el informe que quiere su jefe. Otra ventaja de la normalización de su base de datos es el consumo de espacio. Una base de datos normalizada puede ocupar menos espacio en disco que una no normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menos uso de espacio en disco Grados de Normalización Existen básicamente tres niveles de normalización: Primera Forma Normal (1NF), Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada a esa forma de normalización. Por ejemplo, supongamos que su base de datos cumple con todas las reglas del segundo nivel de normalización. 79

80 Se considera que está en la Segunda Forma Normal. No siempre es una buena idea tener una base de datos conformada en el nivel más alto de normalización. Puede llevar aun nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización Primera Forma Normal La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. Ésta es una regla muy fácil de seguir. Observe el esquema de la tabla Clientes de la base de datos. Clientes ID Cliente Nombre Apellidos Nombre_Producto1 Costo_Producto1 Imagen_Producto1 Nombre_Producto2 Costo_Producto2 80

81 Imagen_Producto2 Fecha_Pedido Cantidad_Pedido Nombre Cia Envios La tabla tiene varias columnas repetidas. Éstas se refieren principalmente a los productos. De acuerdo con la regla, debe eliminar las columnas repetidas y crearles su propia tabla. Eliminación de datos repetidos en una base de datos Clientes ID_Clientes Pedidos Nombre_Productos Nombre Costo_Producto Apellidos Imagen_Producto Direccion Numero_Pedido Fecha_Pedido Cantidad_Pedido Clave_Cia_Envios Nombre_Ci_ Envios 81

82 Ahora tiene dos tablas. Pero todavía hay un problema. No hay forma de relacionar los datos de la tabla original con los de la nueva tabla. Para hacerlo, debe añadir un campo clave a la segunda tabla de forma que se establezca la relación. Añada a la tabla Productos una clave primaria que se llame ID_Producto y añada una clave a la tabla Clientes que la relacione con la tabla Productos. El campo ID_Producto es el candidato ideal. Clientes Pedidos ID_Productos ID_Productos ID_Clientes Nombre_Productos Nombre Costo_Producto Apellidos Imagen_Producto Direccion Numero_Pedido Fecha_Pedido Cantidad_Pedido Clave_Cia_Envios 82

83 Así, se ha establecido una relación uno a varios. Ésta representa lo que la base de datos estará haciendo en la vida real. El cliente tendrá muchos productos que podrá comprar, sin importar cuántos clientes quieran comprarlos también. Además, el cliente necesitará haber pedido un producto para ser un cliente. Usted ya no está obligado a añadir un cliente cada vez que añade un nuevo producto a su inventario. Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de datos inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán columnas que representen los mismos datos. En una empresa de servicios de electricidad, había una base de datos para el control de refacciones de una planta nuclear. La tabla de su base de datos, la cual contenía los números de parte de las refacciones, tenía una columna repetida más de treinta veces. Cada vez que una nueva parte se tenía que dar de alta, se creaba una nueva columna para almacenar la información. Obviamente, el diseño de la base de datos era bastante pobre y, por lo mismo, resultaba una pesadilla para su rogramadores-administradores. La normalización ayuda a clarificar la base de datos ya organizarla en partes más pequeñas y más fáciles de entender. En lugar de tener 83

84 que entender una tabla gigantesca y monolítica que tiene muchos diferentes aspectos, usted sólo tiene que entender objetos pequeños y más tangibles, así como las relaciones que guardan con otros objetos también pequeños. No es necesario mencionar que un mejor entendimiento del funcionamiento de su base de datos conducirá aun mejor aprovechamiento de sus activos Segunda Forma Normal La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. En la base de datos de muestra, la información de pedidos está en cada uno de los registros. Sería mucho más simple utilizar únicamente el número del pedido. El resto de la información podría residir en su propia tabla. Una vez que haya organizado la información de pedidos. Eliminación de las dependencias parciales- Segunda Forma Normal Clientes Pedidos Productos ID_Productos ID_Productos ID_Producto ID_Clientes Nombre_Productos Fecha_Compra Nombre Cantidad_Pedido Costo_Producto 84

85 Apellidos Imagen_Productos Direccion Numero_Pedido Nombre_Cia_Envios De nuevo, al organizar el esquema de esta forma puede reflejar el mundo real en su base de datos. Tendría que hacer algunos cambios en sus reglas del negocio para que esto fuera aplicable, pero para ilustrar la normalización, así está bien. Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus datos están normalizados cuando todo funciona más o menos bien, parece ser un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una base de datos no normalizada que el que emplearía en una normalizada. Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las ventajas de las bases de datos relacionales. Por ejemplo, puede añadir nuevas columnas a la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo aplica para las otras tablas. Alcanzar este nivel de normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados. 85

86 Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la mayoría de los problemas de lógica. Puede insertar un registro sin un exceso de datos en la mayoría de las tablas. Observando un poco más de cerca la tabla Clientes, vemos la columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El siguiente nivel de normalización explicará cómo solucionar esto Tercera Forma Normal. La regla de la Tercera Forma Normal señala que hay que eliminar y separar cualquier dato que no sea clave. El valor de esta columna debe depender de la clave. Todos los valores deben identificarse únicamente por la clave. En la base de datos de muestra, la tabla Clientes contiene la columna Nombre_Cia_Envios, la cual no se identifica únicamente por la clave. Podría separar estos datos de la tabla y ponerlos en una tabla aparte. Eliminación de los datos que no son claves para la Tercera Forma Normal Cliente ID_cliente, ID_Producto, Numero Pedido. ID_Cia_Envios, Nombre, Apellido, Direccion Productos ID_Producto, Nombre_Producto, Costos_Productos, Foto_Producto 86

87 PedidoMaestro ID_Pedido, Fecha_Pedido, Cantidad_Pedidos PedidoDetallado ID_PedidoDetallado, ID_Pedido, Fecha_Pedido Cias_Envios ID_Cia_Envios, Nombre_Cia_Envios. Ahora todas sus tablas están en la Tercera Forma Normal. Esto le da más flexibilidad y previene errores de lógica cuando inserta o borra registros. Cada columna en la tabla está identificada de manera única por la clave, y no hay datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir. Qué tan lejos debe llevar la normalización? La siguiente decisión es qué tan lejos debe llevar la normalización? La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación depende de usted. Si su base de datos va a proveer información aun solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar sus datos hasta la 3FN sea quizá algo extremoso. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes. A veces puede ocurrir que normalizar sus datos hasta el nivel más 87

88 alto no tenga sentido. Por ejemplo, suponga que añade una columna extra para la dirección en su base de datos. Es muy normal tener dos líneas para la dirección. El esquema de la tabla podría verse como se muestra a continuación: ID_Cliente Nombre Apellidos Direccion1 De acuerdo con las reglas, si aplica la Primera Forma Normal, la columna de dirección debería sacarse de esta tabla y reemplazarse con la clave de una nueva tabla. El resultado de este esquema se nuestra a continuación: ID_Ciente Nombre ID_Direccion ID_Cliente Apellidos Direccion La base de datos ahora cumple con la Primera Forma Normal. Los clientes pueden tener más de una dirección. El problema aquí es 88

89 que usted ha complicado demasiado una idea simple, por tratar de seguir las reglas de normalización. En el ejemplo mostrado, la segunda dirección es totalmente opcional. Está ahí sólo para colectar información que pudiera utilizarse como información de contacto. No hay necesidad de partir la tabla en dos y forzar las reglas de la normalización. En esta instancia, el exceso de normalización frustra el propósito para el que se utilizan los datos. Añade, de manera innecesaria, un nivel más de complejidad. Una buena forma de determinar si está llevando demasiado lejos su normalización, es ver el número de tablas que tiene. Un número grande de tablas pudiera indicar que está normalizando demasiado. Observe su esquema. Está dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad prácticas? Éstas son el tipo de cosas que usted, el diseñador de la base de datos, necesita decidir. La experiencia y el sentido común lo pueden auxiliar para tomar la decisión correcta. La normalización no es una ciencia exacta es subjetiva. Existen seis niveles más de normalización que no se han discutido aquí. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesita. Éstas existen para hacer una 89

90 base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales Interfaces de E/S Introducción: Un sistema de información es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. El equipo computacional: el hardware necesario para que el sistema de información pueda operar. El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema. Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida de información Entrada de Información Es el proceso mediante el cual el Sistema de Información toma los datos que requiere para procesar la información. Las entradas pueden ser manuales o automáticas. Las manuales son aquellas que se proporcionan en forma directa por el usuario, mientras que las automáticas son datos o información que provienen o son tomados de otros sistemas o módulos. Esto último se denomina interfases automáticas. 90

91 Las unidades típicas de entrada de datos a las computadoras son las terminales, las cintas magnéticas, las unidades de diskette, los códigos de barras, los escáners, la voz, los monitores sensibles al tacto, el teclado y el mouse, entre otras Almacenamiento de Información El almacenamiento es una de las actividades o capacidades más importantes que tiene una computadora, ya que a través de esta propiedad el sistema puede recordar la información guardada en la sección o proceso anterior. Esta información suele ser almacenada en estructuras de información denominadas archivos. La unidad típica de almacenamiento son los discos magnéticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM) Procesamiento de Información Es la capacidad del Sistema de Información para efectuar cálculos de acuerdo con una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos introducidos recientemente en el sistema o bien con datos que están almacenados. Esta característica de los sistemas permite la transformación de datos fuente en información que puede ser utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyección financiera a partir de los datos que contiene un estado de resultados o un balance general de un año base. 91

92 Salida de Información La salida es la capacidad de un Sistema de Información para sacar la información procesada o bien datos de entrada al exterior. Las unidades típicas de salida son las impresoras, terminales, diskettes, cintas magnéticas, la voz, los graficadores y los plotters, entre otros. Es importante aclarar que la salida de un Sistema de Información puede constituir la entrada a otro Sistema de Información o módulo. En este caso, también existe una interfase automática de salida. Por ejemplo, el Sistema de Control de Clientes tiene una interfase automática de salida con el Sistema de Contabilidad, ya que genera las pólizas contables de los movimientos procesales de los clientes. A continuación se muestran las diferentes actividades que puede realizar un Sistema de Información de Control de Clientes: Actividades que realiza un Sistema de Información: Entradas: Datos generales del cliente: nombre, dirección, tipo de cliente, etc. Políticas de créditos: límite de crédito, plazo de pago, etc. Facturas (interfase automático). Pagos, depuraciones, etc. 92

93 Proceso: Cálculo de antigüedad de saldos. Cálculo de intereses moratorios. Cálculo del saldo de un cliente. Almacenamiento: Movimientos del mes (pagos, depuraciones). Catálogo de clientes. Facturas. Salidas: Reporte de pagos. Estados de cuenta. Pólizas contables (interfase automática) Consultas de saldos en pantalla de una terminal Tipos y Usos de los Sistemas de Información Durante los próximos años, los Sistemas de Información cumplirán tres objetivos básicos dentro de las organizaciones: Automatización de procesos operativos. Proporcionar información que sirva de apoyo al proceso de toma de decisiones. Lograr ventajas competitivas a través de su implantación y uso. 93

94 3.3. Construcción Base de Datos Los programas de bases de datos son administradores de información que ayudan a aligerar la sobrecarga de información. Los programas de bases de datos son una aplicación: sirven para convertir los computadores en herramientas productivas. Una base de datos es una colección integrada de datos almacenados en diferentes tipos de registros. Los registros se interrelacionan por medio de relaciones propias de los datos y no mediante su ubicación física en el almacenamiento. El propósito de una base de datos es representar las relaciones entre las entidades de interés. Organizar los datos de este modo facilita la integración de las áreas dentro de la organización y simplifican las preguntas específicas, incluso las formuladas por quienes no son programadores. Tener bases de datos no elimina la necesidad de archivos en un sistema de información: Los archivos de transacciones son necesarios para capturar detalles de las actividades de la organización. Los archivos maestros también pueden requerirse en virtud de que no todos los datos necesitan residir en la base de datos. Los archivos de clasificación son esenciales cuando se deben reordenar los datos. 94

95 Las ventajas de las bases de datos computarizadas, frente a las de papel son que Facilitan: el almacenamiento de grandes cantidades de información: Conforme aumenta la masa de información, mayor será el beneficio de una base de datos. La recuperación rápida y flexible de información; la organización y reorganización de la información; la impresión y distribución de información en varias formas. Una base de datos esta formada por uno o más archivos. Un archivo es una colección de información relacionada (en este caso se trata de un archivo de datos creado por un programa de base de datos). Un archivo en una base de datos es una colección de registros. Un registro es la información relacionada con una persona, producto o suceso. Cada trozo discreto de información en un registro se denomina campo. El tipo de información que puede contener un campo está determinado por el tipo de campo: de texto, numérico, de fecha. Además de estos campos estándar puede haber campos que contengan gráficos, fotografías digitalizadas, sonidos y videos. Los campos calculados contienen fórmulas similares a las de una hoja de cálculo y exhiben valores calculados a partir de valores de otros campos numéricos. 95

96 La mayoría de las bases de datos ofrecen más de una forma de ver los datos, entre ellas: o Vistas de formulario: muestran un registro cada vez; o Vistas de lista: exhiben varios registros en listas similares a una hoja de cálculo. En ambos casos se pueden acomodar los campos sin modificar los datos subyacentes Objetos de la Base de Datos Tablas: unidades donde crearemos el conjunto de datos de nuestra base de datos. Estos datos estarán ordenados en columnas verticales. Aquí definiremos los campos y sus características. Consultas: Aquí definiremos las preguntas que formularemos a la base de datos con el fin de extraer y presentar la información resultante de diferentes formas (pantalla, impresora...) Formulario: Elemento en forma de ficha que permite la gestión de lo datos de una forma más cómoda y visiblemente más atractiva. Informe: Permite preparar los registros de la base de datos de forma personalizada para imprimirlos. 96

97 Macro: Conjunto de instrucciones que se pueden almacenar para automatizar tareas repetitivas. Módulo: Programa o conjunto de instrucciones en lenguaje Visual Basic Enlace de Objetos Es posible crear orígenes de datos a partir de cualquier objeto que expone una o más propiedades públicas. No se requieren interfaces concretas ni constructores públicos predeterminados para crear un origen de datos desde un objeto. Todas las propiedades públicas se muestran en la ventana Orígenes de datos y pueden arrastrarse a formularios para crear controles enlazados a datos Test (Prueba) Disciplina de Pruebas de Software Esta disciplina complementa a la gestión de la calidad, toda vez que tiene como propósito principal el aseguramiento y el control de la calidad del producto final, el software. Las actividades de esta disciplina se llevan a cabo a lo largo de las cuatro fases, sin embargo consideramos crítico establecer con el Cliente el alcance de las pruebas necesarias para cada proyecto, por lo que a continuación exponemos brevemente las principales formas como se puede probar un sistema, cada una de las cuales tiene un objetivo específico y una técnica que lo soporta. 97

98 Prueba de Estructura Web.- Es el tipo de prueba que se enfoca en certificar que todos los enlaces del sitio web estén conectados a la página web que le corresponde, y que no hay contenido que no pueda ser consultado de ninguna manera (contenido huérfano). Prueba de Funcionalidad.- Es el tipo de prueba que se enfoca en certificar que el funcionamiento del sistema esté acorde a lo descrito en el documento de especificaciones funcionales, esto es que provea los casos de uso que ahí se indican, y de la manera como ahí se especifica. Prueba de Seguridad Funcional.- Es el tipo de prueba que se enfoca en certificar que los datos y las funciones del sistema solo son accesibles por los actores debidamente autorizados, acorde a lo descrito en el documento de especificaciones funcionales. Prueba de Volumen Funcional.- Es el tipo de prueba que se enfoca en certificar la capacidad del sistema de manejar volúmenes de datos extremos, acorde a lo descrito en el documento de especificaciones funcionales. Prueba de Robustez.- Es el tipo de prueba que se enfoca en certificar la capacidad de resistencia a fallar que tiene el sistema, acorde a lo descrito en el documento de especificaciones técnicas. 98

99 Prueba de Estructura de Programas.- Es el tipo de prueba que se enfoca en comprobar que los programas han sido codificados de acuerdo a los estándares de programación establecidos. Prueba de Resistencia (Stress).- Es el tipo de prueba que se enfoca en comprobar cuál es el comportamiento del sistema bajo condiciones anormales, por ejemplo carencia de recursos de memoria, procesador, sistemas externos con los que interactúa y carga excesiva de trabajo. El objetivo de estas pruebas es identificar las partes débiles del sistema, de modo que se puedan establecer los planes de contingencia adecuados y se puedan presupuestar los planes de adquisición correspondientes. Prueba de Concurrencia.- Es el tipo de prueba que se enfoca en certificar la capacidad del sistema de atender múltiples solicitudes departe de los actores que acceden a un mismo recurso (un dato que esté almacenado en memoria, un conjunto de registros en base de datos o una interfaz con un dispositivo de hardware o un sistema externo). Este tipo de pruebas también reciben el nombre de pruebas de contención. Prueba de Rendimiento.- Es el tipo de prueba que se enfoca en comprobar los tiempos de respuesta del sistema en una cantidad limitada de escenarios de trabajo (a nivel de número de usuarios y 99

100 número de transacciones), bajo una configuración de hardware y software constante. Este tipo de pruebas también reciben el nombre de pruebas de carga. Los resultados de este tipo de pruebas permitirán establecer los planes de contingencia apropiados y presupuestar los planes de adquisición necesarios. Prueba de Instalación.- Es el tipo de prueba que se enfoca en certificar que el sistema está operativo y listo para ser utilizado después de ser instalado sobre la configuración de hardware y software establecida en el manual de instalación. Prueba de Vulnerabilidad.- Es el tipo de prueba que se enfoca en comprobar las vulnerabilidades del entorno de comunicaciones donde el sistema va a funcionar (la red), con la finalidad de establecer los planes de contingencia adecuados y de presupuestar los planes de adquisición correspondientes Preparación del Entorno de las Pruebas Unitarias En esta tarea se preparan todos los recursos necesarios para realizar las pruebas unitarias de cada uno de los componentes del sistema de información. Para ello, se asegura la disponibilidad del entorno y de los datos necesarios para ejecutar estas pruebas, se preparan las bibliotecas o librerías oportunas para la realización de las mismas, así como los 100

101 procedimientos manuales o automáticos necesarios, conforme a la especificación del entorno definida en el plan de pruebas. Productos o De entrada Plan de Pruebas o De salida Entorno de Pruebas Unitarias Participantes o Técnicos de Sistemas o Programadores o Tarea: Realización y Evaluación de las Pruebas Unitarias El objetivo de esta tarea es comprobar el correcto funcionamiento de los componentes del sistema de información, codificados en la actividad Generación del Código de los Componentes y Procedimientos, conforme a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas unitarias, en la actividad Especificación Técnica del Plan de Pruebas. Para cada verificación establecida, se realizan las pruebas con los casos de pruebas asociados, efectuando el correspondiente análisis y evaluación de los resultados, y generando un registro conforme a los criterios establecidos en el plan de pruebas. Seguidamente, se analizan los resultados de las pruebas unitarias, evaluándose las mismas para comprobar que los resultados son los esperados. 101

102 Productos o De entrada o Producto Software o Entorno de Pruebas Unitarias o Plan de Pruebas o De salida o Resultado y evaluación de las Pruebas Unitarias Prácticas o Pruebas Unitarias o Pruebas de Integración Participantes o Equipo del Proyecto Ejecución de las Pruebas de Integración El objetivo de las pruebas de integración es verificar si los componentes o subsistemas interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida, y se ajustan a los requisitos especificados en las verificaciones correspondientes. Esta actividad se realiza en paralelo a las actividades Generación del Código de los Componentes y Procedimientos y Ejecución de las Pruebas Unitarias Preparación del Entorno de las Pruebas de Integración 102

103 En esta tarea se disponen todos los recursos necesarios para realizar las pruebas de integración de los componentes y subsistemas que conforman el sistema de información. Productos o De entrada o Plan de Pruebas o De salida o Entorno de Pruebas de Integración Participantes o Técnicos de Sistemas o Especialistas en Comunicaciones o Equipo de Arquitectura o Equipo del Proyecto o Realización de las Pruebas de Integración El objetivo de esta tarea es verificar el correcto funcionamiento de las interfaces existentes entre los distintos componentes y subsistemas, conforme a las verificaciones establecidas para el nivel de pruebas de integración. Para cada verificación establecida, se realizan las pruebas con los casos de pruebas asociados, efectuando el correspondiente análisis e informe de los resultados de cada verificación, y generando un registro conforme a los criterios establecidos en el plan de pruebas. 103

104 Productos de Entrada o Producto Software o Entorno de Pruebas de Integración o Plan de Pruebas Productos de Salida o Resultado de las Pruebas de Integración Prácticas o Pruebas de Integración Participantes o Equipo del Proyecto Evaluación del Resultado de las Pruebas de Integración El objetivo de esta tarea es analizar los resultados de las pruebas de integración y efectuar su evaluación. - Indicar si el plan de pruebas debe volver a realizarse total o parcialmente, y si será necesario contemplar nuevos casos de prueba no considerados anteriormente. Productos de Entrada o Resultado de las Pruebas de Integración o Plan de Pruebas Productos de Salida o Evaluación del Resultado de las Pruebas de Integración Participantes o Analistas 104

105 Ejecución de las Pruebas del Sistema El objetivo de las pruebas del sistema es comprobar la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. En la realización de estas pruebas es importante comprobar la cobertura de los requisitos, dado que su incumplimiento puede comprometer la aceptación del sistema por el equipo de operación responsable de realizar las pruebas de implantación del sistema, que se llevarán a cabo en el proceso Implantación y Aceptación del Sistema Preparación del Entorno de las Pruebas del Sistema En esta tarea se preparan todos los recursos necesarios para realizar las pruebas del sistema, de acuerdo a las características del entorno establecidas en el plan de pruebas. Productos de Entrada o Plan de Pruebas (DSI 10.3) Productos de Salida o Entorno de Pruebas del Sistema Participantes o Técnicos de Sistemas o Especialistas en Comunicaciones o Equipo de Arquitectura 105

106 o Equipo del Proyecto Realización de las Pruebas del Sistema El objetivo de esta tarea es comprobar la integración de todos los subsistemas y componentes del sistema de información, así como la interacción del mismo con otros sistemas de información con los que se relaciona, de acuerdo a las verificaciones establecidas para el nivel de pruebas del sistema. Para cada verificación establecida, se realizan las pruebas con los casos de pruebas asociados, efectuando el correspondiente análisis e informe de los resultados y generando un registro conforme a los criterios establecidos en el plan de pruebas. Productos de Entrada o Producto Software o Entorno de Pruebas del Sistema o Plan de Pruebas (DSI 10.3) Productos de salida o Resultado de las Pruebas del Sistema Prácticas o Pruebas del Sistema Participantes o Equipo del Proyecto Evaluación del Resultado de las Pruebas del Sistema El objetivo de esta actividad es analizar los resultados de las pruebas del sistema de información y efectuar su evaluación

107 Indicar si el plan de pruebas debe volver a realizarse total o parcialmente, y si será necesario contemplar nuevos casos de prueba no considerados anteriormente. Productos de Entrada o Resultado de las pruebas del Sistema o Plan de Pruebas Productos de Salida o Evaluación del Resultado de las Pruebas del Sistema o Participantes o Analistas o Jefe de Proyecto 3.5. Entrega de Proyecto La entrega del proyecto se realiza cuando se pone el producto en manos de los usuarios finales, 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, configuración, instalación y usabilidad del producto Workflow Colaborativo Involucra procesos estructurados o semi-estructurados que permiten a varias personas participar en un grupo de trabajo, ejemplos de ello lo constituyen el diseño arquitectónico o ingenieril, generación de informes, producción de material publicitario, revisión de documentos legales, etc. Estos procesos involucran típicamente un "documento" que hace las veces de contenedor de la información, viajando de paso en paso y en cada uno 107

108 de ellos el partícipe realiza una tarea o acción sobre el "documento". Por tanto, las características esenciales de workflow colaborativo son las siguientes: El "documento" y el "proceso" son claves. Es importante para la aplicación preservar la integridad tanto del documento como del proceso. Fundamentalmente participan "knowledge workers", por tanto está restringido a ciertos grupos "creativos" dentro de la organización. Es importante que una buena solución no sea "intrusiva" ya que el trabajo de conocimiento es un proceso mental que involucra la creatividad, la que no se desea restringir o encasillar. El workflow colaborativo debe ser muy flexible ya que el trabajo creativo puede tomar rumbos inesperados. Las soluciones de workflow colaborativo suelen estar centradas en el "documento" Administración y Configuración del Cambio Consiste en controlar los cambios y mantener la integridad de los productos que incluye el proyecto. Incluye: Identificar los elementos configurables. Restringir los cambios en los elementos configurables. Auditar los cambios hechos a estos elementos. 108

109 Definir y mantener las configuraciones de estos elementos. Los métodos, procesos y herramientas usadas para proveer la administración y configuración del cambio pueden ser consideradas como el sistema de administración de la configuración Administración de Proyectos El propósito de la Administración de Proyectos es: Proveer un marco de trabajo para administrar los proyectos intensivos de software. Proveer guías prácticas para la planeación, soporte, ejecución y monitoreo de proyectos. Proveer un marco de trabajo para la administración del riesgo Medio Ambiente Se enfoca en las actividades necesarias para configurar el proceso al proyecto. Describe las actividades requeridas para desarrollar las líneas guías de apoyo al proyecto. El propósito de las actividades de ambiente es proveer a las organizaciones de desarrollo de software del ambiente necesario (herramientas y procesos) que den soporte al equipo de desarrollo. 109

110 CAPITULO 4 DESCRIPCION DE CASOS DE ESTUDIO USANDO RUP Descripción del caso de USO Detalle del modelo Análisis de Resultados 4. Plan de Desarrollo de Software 4.1. Propósito El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria para controlar el proyecto. En él se describe el enfoque de desarrollo del software Alcance El Plan de Desarrollo del Software describe el plan global usado para el desarrollo del Sistema para Gestión de Artículos Deportivos LSI 03. El detalle de las iteraciones individuales se describe en los planes de cada iteración, documentos que se aportan en forma separada. Posteriormente, el avance del proyecto y el seguimiento en cada una de las iteraciones ocasionará el ajuste de este documento produciendo nuevas versiones actualizadas. 110

111 4.3. Vista General del Proyecto Propósito, Alcance y Objetivos Deportes LSI 03 lleva a cabo la venta al por mayor de artículos deportivos a nivel internacional. Por ello, Deportes LSI 03 considera necesario el desarrollo de un nuevo sistema de gestión de los artículos deportivos que forman parte de sus catálogos, así como las bases de datos que recogen datos tanto estadísticos, empresariales como de nóminas, plantillas de personal, etc. El proyecto debe proporcionar una propuesta para el desarrollo de todos los subsistemas implicados en la gestión de artículos deportivos y bases de datos departamentales. Estos subsistemas se pueden diferenciar en siete grandes bloques: Gestión de Ventas Gestión de Almacenes Gestión de Envíos Departamento de Recursos Humanos. Departamento de Marketing. Departamento de Logística. Contabilidad y Facturación. 111

112 Entregables del Proyecto Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo e incremental), todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo al término del proceso podríamos tener una versión definitiva y completa de cada uno de ellos Plan de Desarrollo del Software Es el presente documento Modelo de Casos de Uso del Negocio Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.). Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos específicos para este modelo Modelo de Casos de Uso El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso. 112

113 Visión Este documento define la visión del producto desde la perspectiva del cliente, especificando las necesidades y características del producto. Constituye una base de acuerdo en cuanto a los requisitos del sistema Modelo de Implementación Este modelo es una colección de componentes y los subsistemas que los contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de código fuente, y todo otro tipo de ficheros necesarios para la implantación y despliegue del sistema. (Este modelo es sólo una versión preliminar al final de la fase de Elaboración, posteriormente tiene bastante refinamiento) Casos de Prueba Estos casos de prueba son aplicados como pruebas de regresión en cada iteración. Cada caso de prueba llevará asociado un procedimiento de prueba con las instrucciones para realizar la prueba, y dependiendo del tipo de prueba dicho procedimiento podrá ser automatizable mediante un script de prueba. 113

114 Evolución del Plan de Desarrollo del Software El Plan de Desarrollo del Software se revisará semanalmente y se refinará antes del comienzo de cada iteración Organización del Proyecto Participantes en el Proyecto El resto del personal del proyecto (por la parte del la empresa adjudicataria), considerando las fases de Inicio, Elaboración y dos iteraciones de la fase de Construcción, estará formado por los siguientes puestos de trabajo y personal asociado: Jefe de Proyecto. Experiencia en metodologías de desarrollo, herramientas CASE y notaciones, en particular la notación UML y el proceso de desarrollo RUP. Analista de Sistemas. El perfil establecido es: Ingeniero en Informática con conocimientos de UML, uno de ellos al menos con experiencia en sistemas afines a la línea del proyecto Analistas - Programadores. Con experiencia en el entorno de desarrollo del proyecto, con el fin de que los prototipos puedan ser lo más cercanos posibles al producto final. Ingeniero de Software. El perfil establecido es: Ingeniero en Informática recién titulado que participará como becario en el convenio universidad-empresa, realizando labores de gestión de requisitos, gestión de configuración, 114

115 documentación y diseño de datos. Encargada de las pruebas funcionales del sistema Interfaces Externas Deportes LSI 03 definirá los participantes del proyecto que proporcionarán los requisitos del sistema, y entre ellos quiénes serán los encargados de evaluar los artefactos de acuerdo a cada subsistema y según el plan establecido. El equipo de desarrollo interactuará activamente con los participantes de Deportes LSI 03 para especificación y validación de los artefactos generados Roles y Responsabilidades Responsabilidad del Jefe de Proyecto El jefe de proyecto también establece un conjunto de prácticas que aseguran la integridad y calidad de los artefactos del proyecto. Gestión de riesgos. Planificación y control del proyecto. Responsabilidad Analista de Sistemas Captura, especificación y validación de requisitos, interactuando con el cliente y los usuarios mediante entrevistas. Elaboración del Modelo de Análisis y Diseño. Colaboración en la elaboración de las pruebas funcionales y el modelo de datos. 115

116 Responsabilidad Programador Construcción de prototipos. Colaboración en la elaboración de las pruebas funcionales, modelo de datos y en las validaciones con el usuario Responsabilidad Ingeniero de Software Gestión de requisitos, gestión de configuración y cambios, elaboración del modelo de datos, preparación de las pruebas funcionales, elaboración de la documentación. Elaborar modelos de implementación y despliegue. 4.5.Gestión del Proceso 4.6. Plan del Proyecto En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto Plan de las Fases Fase Nro. Iteraciones Duración Fase de Inicio 1 3 semanas Fase de Elaboración 1 2 semanas Fase de Construcción 2 7 semanas Fase de Transición - - Los hitos que marcan el final de cada fase. 116

117 Fase de Inicio En esta fase desarrollará los requisitos del producto desde la perspectiva del usuario, los cuales serán establecidos en el artefacto Visión. La aceptación del cliente / usuario del artefacto Visión y el Plan de Desarrollo marcan el final de esta fase Fase de Elaboración Al final de esta fase, todos los casos de uso correspondientes a requisitos que serán implementados en la primera release de la fase de Construcción deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase Fase de Construcción Se comienza la elaboración de material de apoyo al usuario. El hito que marca el fin de esta fase es la versión de la release 3.0, con la capacidad operacional parcial del producto que se haya considerado como crítica, lista para ser entregada a los usuarios para pruebas beta Fase de Transición En esta fase se prepararán dos releases para distribución, asegurando una implantación y cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios. 117

118 Calendario del Proyecto Como se ha comentado, el proceso iterativo e incremental de RUP está caracterizado por la realización en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayoría de los artefactos son generados muy tempranamente en el proyecto pero van desarrollándose en mayor o menor grado de acuerdo a la fase e iteración del proyecto. Disciplinas / Artefactos generados o modificados durante la Fase de Inicio Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos Glosario Visión Modelo de Casos de Uso Especificación de Casos de Uso Especificaciones Adicionales Análisis / Diseño Modelo de Análisis / Diseño Modelo de Datos Comienzo Semana 1 14/10 20/10 Semana 1 14/10 20/10 Semana 2 21/10 27/10 Semana 3 28/10 3/11 Semana 3 28/10 3/11 Semana 3 28/10 3/11 Semana 2 21/10 27/10 Semana 2 21/10 27/10 Aprobación Semana 3 28/10 3/11 Semana 3 28/10 3/11 Semana 3 28/10 3/11 siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase 118

119 Implementación Prototipos de Interfaces de Usuario Modelo de Implementación Pruebas Casos de Pruebas Funcionales Despliegue Modelo de Despliegue Semana 3 28/10 3/11 Semana 3 28/10 3/11 Semana 3 28/10 3/11 Semana 3 28/10 3/10 siguiente fase siguiente fase siguiente fase siguiente fase Gestión de Cambios y Configuración Durante todo el proyecto Gestión del proyecto Plan de Desarrollo del Software en su versión 1.0 y planes de las Iteraciones Semana 1 14/10 20/10 Semana 3 28/10 3/11 Ambiente Durante todo el proyecto Disciplinas / Artefactos generados o modificados durante la Fase de Elaboración Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos Glosario Visión Modelo de Casos de Uso Especificación de Casos de Uso Comienzo Semana 1 14/10 20/10 Semana 1 14/10 20/10 Semana 2 21/10 27/10 Semana 3 28/10 3/11 Semana 3 28/10 3/11 Aprobación aprobado aprobado aprobado Semana 5 11/12 17/12 Semana 5 11/12 17/12 119

120 Especificaciones Adicionales Análisis / Diseño Modelo de Análisis / Diseño Modelo de Datos Implementación Prototipos de Interfaces de Usuario Modelo de Implementación Pruebas Casos de Pruebas Funcionales Despliegue Modelo de Despliegue Semana 3 28/10 3/11 Semana 2 21/10 27/10 Semana 2 21/10 27/10 Semana 3 28/10 3/11 Semana 3 28/10 3/11 Semana 3 28/10 3/11 Semana 3 28/10 3/11 Semana 5 11/12 17/12 Revisar en cada iteración Revisar en cada iteración Revisar en cada iteración Revisar en cada iteración Revisar en cada iteración Revisar en cada iteración Gestión de Cambios y Configuración Durante todo el proyecto Gestión del proyecto Plan de Desarrollo del Software en su versión 2.0 y planes de las Iteraciones Semana 4 4/11 10/11 Revisar cada iteración en Ambiente Durante todo el proyecto 120

121 Seguimiento y Control del Proyecto Gestión de Requisitos Los requisitos del sistema son especificados en el artefacto Visión. Estos atributos permitirán realizar un efectivo seguimiento de cada requisito Control de Plazos El calendario del proyecto tendrá un seguimiento y evaluación semanal por el jefe de proyecto y por el Comité de Seguimiento y Control Control de Calidad Los defectos detectados en las revisiones y formalizados también en una Solicitud de Cambio tendrán un seguimiento para asegurar la conformidad respecto de la solución de dichas deficiencias Para la revisión de cada artefacto y su correspondiente garantía de calidad se utilizarán las guías de revisión y checklist (listas de verificación) incluidas en RUP Gestión de Riesgos A partir de la fase de Inicio se mantendrá una lista de riesgos asociados al proyecto y de las acciones establecidas como estrategia para mitigarlos o acciones de contingencia. Esta lista será evaluada al menos una vez en cada iteración. 121

122 Gestión de Configuración Se realizará una gestión de configuración para llevar un registro de los artefactos generados y sus versiones. También se incluirá la gestión de las Solicitudes de Cambio y de las modificaciones que éstas produzcan, informando y publicando dichos cambios para que sean accesibles a todo los participantes en el proyecto Modelado del Negocio de la Empresa de Deportes Lsi 03 A continuación se presentan los modelos definidos en RUP como modelo del negocio.también se muestran los diagramas de componentes y diagramas de despliegue del proyecto Empresa de Deporte Cada sucursal de ventas dispone de un almacén regional que suministra los pedidos de los clientes a los países que conforman una región determinada, siendo el almacén central el que abastece al resto de almacenes. El diagrama que representa los diferentes subsistemas en los que se ha dividido la empresa a nivel de abstracción es el siguiente: 122

123 Modelado del Negocio La empresa interactúa con distintos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empresa), el proveedor (persona o entidad que reabastece de productos a la empresa) y por último la empresa de transportes, que es una subcontrata encargada de servir los pedidos desde los distintos almacenes regionales a los clientes de la empresa. 123

124 4.7.Visión Propósito El propósito de éste documento es recoger, analizar y definir las necesidades de alto nivel y las características del sistema de gestión de una empresa de distribución de artículos deportivos. El documento se centra en la funcionalidad requerida por los participantes en el proyecto y los usuarios finales Alcance Dicho sistema será desarrollado por el grupo de desarrollo de software LSI 03. El sistema permitirá a los encargados de la empresa controlar todo lo relativo a la distribución de los artículos (gestión de stock, gestión de pedidos, gestión de clientes, etc.) Posicionamiento Oportunidad de Negocio Este sistema permitirá a la empresa informatizar el control de todas sus actividades (gestión de stock en cada almacén, gestión de pedidos, etc.), lo cual supondrá un acceso rápido y sencillo a los datos, gracias a interfaces gráficas sencillas y amigables. 124

125 Sentencia que define el Problema El problema de Controlar el stock existente en los distintos almacenes afecta a: Departamento de logística, departamento de contabilidad facturación, Departamento de recursos humanos, Departamento de marketing. El impacto asociado es: Almacenar toda la información referente almacenes, pedidos y órdenes de compra recibidas, y que esta información esté al instante accesible. Una solución adecuada sería: Informatizar el proceso, usando una red local con una base de datos accesible desde los distintos nodos de la red y generar interfaces amigables y sencillas con las que acceder a dicha base de datos Entorno de Usuario Los usuarios entrarán al sistema identificándose sobre un ordenador con un sistema operativo Windows 2000 y tras este paso entrarán a la parte de aplicación diseñada para cada uno según su papel en la empresa. 125

126 Representante del Área Técnica y Sistemas de Información Representante Descripción Patricio Orlando Letelier Torres Representante Global de la Empresa Deportes LSI 03. Tipo Responsabilidades Experto de Sistemas. Encargado de mostrar las necesidades de cada usuario del sistema. Además, lleva a cabo un seguimiento del desarrollo del proyecto y aprobación de los requisitos y funcionalidades del sistema Criterio de Éxito A definir por el cliente Grado participación de Revisión de requerimientos, estructura del sistema Comentarios Ninguno 126

127 4.8.Perfiles de Usuario Ingeniero de Logística. Representante Descripción Tipo Responsabilidades Logística Jefe del Departamento de Logística de la Empresa. Gurú. Responsable del Departamento de Logística, encargado de la gestión del almacén central, del aprovisionamiento del resto de almacenes y del contacto con los proveedores. Control de estadísticas para la optimización de recursos. Criterio de Éxito Grado de participación Comentarios A definir por el cliente A definir por el cliente Ninguno Jefe de Almacén Representante Descripción Tipo Responsabilidades Almacén Jefe del almacén de una región determinada. Usuario casual del sistema. Supervisor del buen funcionamiento del almacén y de gestionar las incidencias de los pedidos, ya sea tratando con otro almacén, o bien en contacto con el Ingeniero de Logística. Capacidad de toma de decisiones en cuanto a distribución de mercancías desde otro almacén y cancelación de pedidos que han sido 127

128 atendidos. Criterio de Éxito Grado de participación Comentarios A definir por el cliente A definir por el cliente Ninguno Técnico de Almacén Representante Descripción Almacén Responsable del almacén de una región determinada. Tipo Responsabilidades Usuario experto. Encargado directo del almacén, control de stocks y distribución de los productos, preparación y atención de las órdenes de pedido y solicitudes de envío al cliente. Gestión de incidencias a través del de un técnico comercial para que se ponga en contacto con el cliente, o bien por medio del jefe de almacén. Criterio de Éxito A definir por el cliente Grado participación Comentarios de A definir por el cliente Ninguno. 128

129 Representante de Ventas Representante Descripción Tipo Responsabilidades Ventas Representante de ventas de los productos Usuario experto. Responsable de ventas del producto a los clientes, mediante visitas al domicilio del cliente. Informa de las ofertas y confecciona las órdenes de pedido. También participa en las incidencias de pedidos poniéndose en contacto con el cliente para la resolución de los mismos. Puede cancelar pedidos en estado de elaboración. Criterio de Éxito A definir por el cliente Grado participación Comentarios de A definir por el cliente Ninguno Operadora Representante Descripción Tipo Responsabilidades Ventas Operadora de ventas de los productos Usuario experto. Responsable de ventas del producto a los clientes a través del teléfono. Informa de las ofertas y confecciona las órdenes de pedido. También participa en las incidencias de pedidos poniéndose en contacto con el cliente para la resolución de los mismos. 129

130 Criterio de Éxito A definir por el cliente Grado participación Comentarios de A definir por el cliente Ninguno Jefe de Ventas Representante Descripción Ventas Jefe del Departamento de Ventas de una región determinada. Tipo Responsabilidades Usuario experto. Supervisor del Departamento de Ventas, encargado de otorgar incentivos y del control de estadísticas. Criterio de Éxito A definir por el cliente Grado participación Comentarios de A definir por el cliente Ninguno Encargado de Transporte Representante Descripción Envíos Encargado de Transportes de un almacén determinado. Tipo Responsabilidades Usuario experto. Supervisor del transporte de mercancías desde el almacén hasta el domicilio de los clientes. Carga los pedidos en el camión, registra en el sistema los datos del envío y una vez entregado el pedido al 130

131 cliente, introduce el recibo de entrega en la base de datos. Criterio de Éxito A definir por el cliente Grado participación Comentarios de A definir por el cliente Ninguno Contable Representante Descripción Tipo Contabilidad / Facturación Empleado del Departamento de Contabilidad y Facturación. Usuario experto. Responsabilidades Encargado de la facturación y cobranzas, política de cobro de los clientes. Criterio de Éxito A definir por el cliente Grado participación Comentarios de A definir por el cliente Ninguno. 131

132 Empleado de Marketing Representante Descripción Tipo Responsabilidades Marketing Empleado del Departamento de Marketing. Usuario eventual. Responsable de ofertas de lanzamiento, publicidad, política de ventas y otros aspectos relacionados con el marketing. Criterio de Éxito A definir por el cliente Grado participación Comentarios de A definir por el cliente Ninguno Cliente Online Representante Descripción Tipo Responsabilidades Ventas Comprador de productos. Usuario casual. Realiza compras online y consulta del estado de pedidos como del catálogo. También puede darse de alta, darse de baja o modificar sus datos de cliente. Criterio de Éxito A definir por el cliente Grado participación Comentarios de A definir por el cliente Ninguno. 132

133 Empleado de Recursos Humanos Representante Descripción Tipo Responsabilidades Recursos Humanos Empleado del Departamento de Recursos Humanos. Usuario casual. Responsable de las entrevistas de trabajo y registra los datos de las mismas, incluyendo la gestión de una base de datos de currículos de trabajadores en potencia. También realiza la gestión de contratos y nóminas del personal. Criterio de Éxito Grado participación Comentarios de A definir por el cliente A definir por el cliente Ninguno Jefe de Recursos Humanos Representante Descripción Tipo Responsabilidades Recursos Humanos Empleado del Departamento de Recursos Humanos. Usuario casual. Responsable de la gestión de personal, es decir, gestión de contrataciones y gestión de despidos. También es responsable de la redistribución de la plantilla. Criterio de Éxito Grado participación Comentarios de A definir por el cliente A definir por el cliente Ninguno. 133

134 Descripción Global del Producto Atributos de Características Número y nombre de la característica Depart. de Recursos Humanos Depart. de Marketing Depart. de Logística Control de estadísticas de datos Gestión de Almacén Atención de órdenes de pedido Gestión de incidencias de Estado Beneficio Esfuerzo Riesgo Estabilidad Asignación Propuesta: Sí Aprobada: Sí Incorporada: No Útil Bajo Propuesta: Sí Aprobada: Sí Incorporada: Útil Bajo No Propuesta: Sí Aprobada: Sí Importante Medio Incorporada: No Propuesta: Sí Aprobada: Sí Incorporada: Útil Medio No Propuesta: Sí Aprobada: Sí Incorporada: Crítica Alto Sí Propuesta: Sí Aprobada: Sí Incorporada: Crítica Alto Sí Propuesta: Sí Útil Medio Aprobada: Sí [A definir [A definir por el por el Ninguna cliente] cliente] [A definir [A definir por el por el Ninguna cliente] cliente] [A definir [A definir por el por el Ninguna cliente] cliente] [A definir [A definir por el por el Ninguna cliente] cliente] J.A. Mocholí, [A definir [A Germán definir por el por Mira, el cliente] cliente] Miguel Mascilla y Eduardo Bueno [A definir [A definir José por el por el Antonio cliente] cliente] Mocholí [A definir [A definir por el por el Ninguna 134

135 pedido Incorporada: cliente] cliente] No Consulta de estado de los pedidos Propuesta: Sí Aprobada: Sí Incorporada: Sí Importante Medio [A definir por el cliente] [A definir por el cliente] Eduardo Bueno José Gestión Ventas de Propuesta: Sí Aprobada: Sí Incorporada: Sí Crítica Alto [A definir por el cliente] [A definir por el cliente] Antonio Mocholí, Germán Mira Miguel y Mascilla José Elaborar pedidos ofertas y Propuesta: Sí Aprobada: Sí Incorporada: Sí Útil Medio [A definir por el cliente] [A definir por el cliente] Antonio Mocholí, Germán Mira Miguel y Mascilla 135

136 4.9. Análisis / Diseño Modelo de Análisis/Diseño: Diagrama de Clases 136

137 4.10. Modelo de Datos: Modelo Relacional 137

138 4.11. Implementación Prototipos de Interfaz de Usuario Interfaz que se Presenta en la Identificación En Caso de Seleccionar Incidencia Pedido 138

139 Para Consultar los Detalles de una Incidencia 139

140 Componentes/Despliegue 140

141 Diagrama de Componentes Comunes 141

142 Diagrama de Componentes Ventas 142

143 Diagrama de Despliegue 143