Autorizada la entrega del proyecto del alumno. Javier Losa Muñoz EL DIRECTOR DE PROYECTO. Fernando Gómez González. Firmado: Fecha: 22/06/2006

Transcripción

1 Autorizada la entrega del proyecto del alumno Javier Losa Muñoz EL DIRECTOR DE PROYECTO Fernando Gómez González Firmado: Fecha: 22/06/2006 Vº Bº del Coordinador de Proyectos Eduardo Alcalde Lancharro Firmado: Fecha: 29/06/2006

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA DESARROLLO DE MODELOS METODOLÓGICOS DE GESTIÓN DE PROYECTOS AUTOR: JAVIER LOSA MUÑOZ MADRID, JUNIO de 2006

3 Agradecimientos Mucha gente ha conseguido con su apoyo y comprensión que este proyecto salga adelante. Han sido muchos los cafés perdidos, las conversaciones aplazadas y los momentos en que no se veía salida; por ello, esto tiene una parte de todos ellos: Mi familia, que supo estar ahí en los malos momentos. Marta, que siempre tenía palabras de ánimo cuando todo parecía desmoronarse. Mis amigos, increíbles en todos los aspectos. Fernando Gómez, mi director, que nunca dudó de que esto fuera posible. I

4 Resumen Este proyecto ha sido realizado para facilitar la gestión de proyectos en el ámbito del desarrollo de aplicaciones software. Existen una gran cantidad de actividades dentro de la gestión de proyectos y muchas de ellas no son resueltas de forma satisfactoria por las herramientas actuales. El Project Management Institute (PMI), líder en el desarrollo de estándares dentro de la gestión de proyectos, define una serie de áreas de conocimiento en las que se deben ejecutar un conjunto de buenas prácticas que son abordadas por la aplicación desarrollada en este proyecto: Gestión de la integración, cuya función es coordinar todos los procesos del proyecto. Gestión del alcance, que engloba las actividades necesarias para la finalización exitosa del desarrollo. Gestión de la duración, para conseguir completar el proyecto en el tiempo planificado. Gestión del coste, enfocada a la estimación, planificación y control de los distintos costes del proyecto. Gestión de los recursos humanos, destinada a planificar las personas necesarias para la finalización del proyecto. Gestión de riesgos, orientada a la identificación, análisis, planificación y gestión de los mismos. II

5 El uso del modelo COCOMO II para la correcta estimación de los costes y la duración de los proyectos proporciona al director y jefe de proyecto la posibilidad de conocer, en fases tempranas del desarrollo, una aproximación del tiempo de desarrollo, así como de los costes. Siguiendo las pautas del PMI, la aplicación desarrollada en este proyecto proporciona a los directores y jefes de proyecto la posibilidad de conocer de forma rápida la evolución económica de los diferentes proyectos a su cargo. Asimismo, y gracias a la posibilidad de enviar estos datos a un dispositivo móvil, como una PDA (Personal Digital Assistant), la herramienta permite disponer de esta información en cualquier momento y lugar. En lo que respecta a la gestión de riesgos se ha hecho uso de una categorización jerarquizada de los mismos denominada Risk Breakdown Structure (RBS), que permite una fácil identificación y gestión de los mismos, así como un mayor control sobre su evolución. El uso de una metodología formal de desarrollo de software proporciona una visión clara de las fases que debe seguir un proyecto para culminar de forma exitosa, así como de las relaciones y dependencias entre ellas. La aplicación desarrollada, a través de su integración con la herramienta líder del área de la gestión de proyectos, Microsoft Project, consigue la creación de proyectos, con las fases específicas y sus dependencias, según las diferentes metodologías de desarrollo de software más usadas en la actualidad. La creación de las III

6 fases del ciclo de vida del proyecto se realiza en el momento en que el director crea uno nuevo en la herramienta, reduciendo considerablemente el tiempo dedicado a esta tarea. Entre las metodologías de desarrollo soportadas por la herramienta se encuentran la clásica en cascada, el modelo en V, la incremental, la metodología en espiral, la síntesis automatizada, el modelo RAD (Rapid Application Developement), la orientada a objetos y el modelo prototipado. La aplicación ha sido desarrollada bajo la plataforma Visual Studio.NET 2005, concretamente con el lenguaje Visual C#, y siguiendo una metodología orientada a objetos. Se ha hecho uso del lenguaje de modelado UML para las diferentes fases del ciclo de vida de la aplicación. Así pues, se ha conseguido una herramienta amigable, intuitiva y fácil de usar que proporciona a los diferentes miembros del equipo de proyecto la posibilidad de abordar los desarrollos software de un modo estructurado y teniendo en cuenta las actividades propias de la gestión de proyectos. IV

7 Abstract This project has been developed to facilitate project management inside the software development field. There are a great number of activities that need to be carried out to manage a project correctly, and most of them cannot be done using the actual project management software. Project Management Institute (PMI) defines a number of knowledge areas in which a set of good practices need to be execute. These knowledge areas and good practices are tackled by the developed application: integration management coordinates all the project processes; scope management includes all the necessary activities to successfully finish the project; time management tries to complete the project within the planned period of time; cost management focuses on the estimation, planning and control of the different costs of the project; human resource management plans the number and type of people necessary to successfully complete the project; risk management identifies, analyses, plans and manages the possible risks encountered throughout the project. COCOMO II model is used to achieve a correct estimation of both cost and duration of the project, providing the director and program manager with the opportunity of knowing, in early stages of the project, an accurate estimation of the development time and cost. V

8 The possibility of gaining knowledge, in a rapid way, of the economic evolution of the different projects is also supplied to the director and program manager. In addition, they can send this information to a mobile device, such as a Pocket PC (Personal Computer), allowing them to have it at their disposal, no matter place and time. The Risk Breakdown Structure (RBS) has been used to identify and categorize the project risks. This structure provides the project team with a hierarchical classification of the different risks, allowing them to focus on the most important ones. The usage of a formal methodology to develop the software lets the project team gain a clear vision of the phases that a project needs to follow to succeed. The developed application, through its integration with the leader project management software, Microsoft Project, allows the creation of projects, with specific phases and their dependencies, according to the different methodologies of software development that are in use nowadays. Visual Studio.NET 2005 has been used to develop the application. Visual C# was the programming language, and UML (Unified Modeling Language) was utilized for the different phases of the application life cycle. VI

9 Therefore, the application provides the team members with the possibility to create software in an organized manner and taking into account the activities that belong to the project management field. VII

10 Índice 0. Introducción Proceso de gestión de proyectos Grupos de procesos de la gestión de proyectos Inicio...12 Planificación...15 Ejecución...23 Monitorización y Control...24 Cierre Metodologías de desarrollo de software...28 Modelo Lineal o en Cascada...29 Modelo en V...31 Modelo Incremental o Evolutivo...33 Modelo en Espiral...35 Modelo de Síntesis Automatizada...37 Rapid Application Development (RAD)...39 Modelo Orientado a Objetos...42 Modelo Prototipado Metodología orientada a objetos UML (Unified Modeling Language) Patrones de diseño...52 Patrón MVC (Modelo Vista Controlador)...53 Patrón DAO (Data Access Object) Fases del ciclo de vida de la aplicación...55 VIII

11 6.1 Análisis de Requisitos Modelo de Dominio Diagrama de Casos de Uso Descripción detallada de los casos de uso...70 Casos de uso del Director de Proyecto...71 Casos de uso del Jefe de Proyecto...93 Casos de uso del Analista y Programador Diseño del Sistema Arquitectura Física Diagrama de la Arquitectura Diseño Detallado Modelo Dinámico Detallado Modelo Estructural Detallado Diseño de la base de datos Manual de usuario Conclusiones Bibliografía Anexo A: Plantilla Project Charter Anexo B: Plantilla Scope Statement Anexo C: Requisitos de ejecución Anexo D: Planificación Temporal Anexo E: Valoración Económica IX

12 0. Introducción Las organizaciones dedicadas al desarrollo de software carecen, en numerosas ocasiones, de una aplicación que les permita, de una forma sencilla, planificar los proyectos que acometen según las diferentes metodologías existentes. Muchas de ellas, además, no realizan una correcta gestión de los procesos necesarios para realizar una buena gestión de sus proyectos. Ambos factores (uso de una metodología formal y de procesos para la gestión de proyectos) son dos aspectos claros de éxito en la realización de proyectos de sistemas de información. Un alto porcentaje de los proyectos que no consiguen satisfacer los objetivos que se proponen en su nacimiento, en cualquiera de sus tres aspectos fundamentales (coste, duración y calidad), lo realizan por no hacer uso de una metodología formal o de unos procesos que guíen al equipo del proyecto en la gestión del proyecto. Otro factor importante que motivó el desarrollo de este proyecto fue la falta de una adecuada gestión de los riesgos que pueden aparecer a lo largo de la vida de un proyecto. Una correcta gestión de riesgos no provoca la desaparición de éstos, pero otorga al equipo de proyecto una valiosa herramienta para poder hacer frente a los imprevistos que puedan surgir en un momento dado. Además, en numerosas ocasiones, las estimaciones en cuanto a duración y coste se realizan de una forma superficial, produciéndose unas desviaciones 1

13 considerables en un gran número de proyectos. Para poder mejorar este aspecto, la herramienta hace uso de la metodología COCOMO II, pudiendo estimar la duración de un proyecto de una manera más realista. Existen numerosas herramientas destinadas a la gestión de proyectos. Como ejemplos se pueden citar Super Project de Computer Associates, que aunque ya no se comercializa sigue siendo usada por algunas organizaciones; Micro Planner Manager y Primavera Project Planner. A pesar de que estas herramientas proporcionan una gran funcionalidad, el líder indiscutible del mercado sigue siendo Microsoft Project. La aplicación proporciona al usuario una integración con esta herramienta líder, creando de forma automática un proyecto en esta aplicación en base a los parámetros introducidos por el director de proyecto. Además, el proyecto proporciona una serie de funcionalidades relacionadas con las buenas prácticas descritas por el Project Management Institute: Gestión de la integración: trata de coordinar los diferentes procesos de las distintas áreas de conocimiento. Se debe crear una visión común, consolidar e integrar acciones que son importantes para el éxito del proyecto. Esto se intenta conseguir con la elaboración del Project Charter, elaboración del Scope Statement y elaboración del Plan de Proyecto. 2

14 Gestión del alcance: este área de conocimiento trata de conseguir que el proyecto posea las actividades necesarias para que el proyecto concluya de una forma exitosa. Para ello es necesario que se realice una correcta planificación del alcance (tanto en duración, como en costes y calidad) así como un control exhaustivo de su evolución. La aplicación crea de forma automática la Estructura de División de Tareas (EDT) necesaria para que se conozca en todo momento qué actividades deben realizarse. Gestión de la duración: debe incluir los procesos necesarios para que se pueda completar el proyecto a tiempo. La aplicación. proporciona de forma automática una serie de actividades para conseguirlo: Definición de actividades, Secuenciación de actividades, Estimación de los recursos y Estimación de la duración. Gestión del coste: este área de conocimiento trata de conseguir una planificación y estimación adecuada de los costes, así como un control de la evolución de los mismos. El proyecto realiza una estimación de los costes de cada fase, así como la del proyecto en su conjunto. Asimismo, permite introducir los costes reales de cada fase, presentando al usuario la desviación respecto a lo 3

15 planificado para que se puedan tomar acciones correctoras. Otra característica importante es la posibilidad de enviar a una PDA los informes de costes de un determinado director de proyecto. Estos informes contienen el importe de venta de cada proyecto, su coste previsto hasta la fecha y el coste real en el que se ha incurrido hasta el momento. De esta manera, el director de proyecto puede disponer de datos fiables sobre la evolución de los proyectos bajo su dirección en cualquier instante. Gestión de los recursos humanos: la aplicación permite realizar una planificación de los recursos humanos del proyecto. Se pueden asignar diferentes personas a las diversas fases, asignándoles tanto un porcentaje de dedicación al proyecto como un porcentaje de participación de una fase determinada. Además, cada persona tiene una tasa estándar y una tasa de horas extra, permitiendo realizar a su vez una planificación y seguimiento de los costes de los recursos humanos. Gestión de los riesgos: se debe hacer una identificación temprana de los riesgos de un proyecto para, posteriormente, planificar su gestión y analizarlos. La aplicación ofrece la posibilidad de identificar los riesgos del proyecto según unas categorías, realizando un análisis cualitativo en base a dos propiedades de 4

16 los mismos: probabilidad de ocurrencia e impacto en caso de tener lugar. Cabe destacar que existen áreas que no quedan cubiertas por la aplicación, como la realización de informes o un plan de comunicación adecuado. Estos puntos son cubiertos por Microsoft Project, una vez se ha creado el fichero del proyecto, o bien por otros procesos de la organización. 5

17 1. Proceso de gestión de proyectos La gestión de proyectos es un área ampliamente estudiada y tratada en todos los ámbitos de la ingeniería. En lo que corresponde a la ingeniería del software, la existencia de la institución Project Management Institute, en adelante PMI, marca un referente imprescindible a nivel mundial. Esta institución ha publicado una serie de buenos principios constatados en lo que a gestión de proyectos se refiere. Estas buenas prácticas, materializadas en el PMBOK (Project Management Book of Knowledge), son a la vez guía y referente para cualquier organización que acometa proyectos de ingeniería de software como práctica habitual. De todos modos, cada proyecto es diferente, y será responsabilidad del equipo concreto el adaptar estos conocimientos para obtener el mejor resultado (tanto en calidad, como coste y tiempo) en el desarrollo de cada proyecto. Un proyecto se puede definir como un esfuerzo temporal para crear un servicio, resultado o producto único. Si aplicamos esta definición a la ingeniería del software, el producto será normalmente una aplicación software. El hecho de que un proyecto sea temporal significa que éste tiene tanto un principio como un final. Esto no implica que su duración sea corta, sino limitada. Cualquier proyecto, pues, tiene una elaboración progresiva. Esto significa desarrollar en pasos y continuar con incrementos. 6

18 La gestión de proyectos podría definirse como la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para conseguir satisfacer los requisitos del mismo. Como su definición indica, la gestión de proyectos está a medio camino entre el arte y la ciencia. Los mejores gestores de proyectos poseen también las habilidades de un líder: visión, creatividad, relaciones interpersonales, etc. En el ámbito de la gestión de sistemas, además, se deben tener en cuenta ciertos aspectos diferenciadores. La industria de los sistemas de la información está en continuo cambio, por lo que los aspectos tecnológicos de un proyecto pueden llegar a estar obsoletos en el momento de su finalización, cuando en la planificación del proyecto eran considerados como tecnología muy actual. Sin embargo, estos aspectos son cada vez más tenidos en cuenta por las organizaciones que abordan proyectos de este tipo; es necesario recordar que no son los únicos aspectos a tener en cuenta, ya que igualmente importantes son los aspectos organizativos de la empresa donde se desarrolla el proyecto, así como los aspectos de negocio que afectarán a su evolución. Otra característica muy importante en el desarrollo de un proyecto dentro del ámbito de los sistemas de información es el concepto de participantes (stakeholders). Los participantes son aquellas personas, unidades organizativas u organizaciones que forman parte del proyecto con su esfuerzo, recursos o fondos. Además se verán impactados por el resultado del proyecto, y tienen la posibilidad de tomar decisiones que afectan al mismo. Un proyecto 7

19 debe satisfacer las expectativas de los participantes, por lo que la identificación temprana de los mismos, así como de sus expectativas, es primordial para el éxito del proyecto. Además, la influencia que los participantes ejercen sobre el proyecto es muy alta en las primeras fases, reduciéndose ésta a medida que avanza el proyecto; sin embargo, a medida que su influencia se va reduciendo, aumentan los costes de realizar cambios en el proyecto, sobre todo en lo que a requisitos se refiere. Entre los principales participantes se encuentran el director de proyecto, el jefe de proyecto, el equipo de proyecto, los gestores funcionales, los patrocinadores y los clientes o usuarios. Muchos proyectos de desarrollo de software han fracasado debido a que los clientes del producto no han sabido o querido adaptarse a la herramienta desarrollada, o bien porque el proyecto no ha recibido el suficiente apoyo desde la organización. La implicación de la dirección y la participación de los usuarios finales son dos de los diez factores más determinantes para que un proyecto tenga éxito según el grupo The 8

20 Standish Group [STAN01]. Otros factores importantes para la consecución de un proyecto son: una clara visión de los objetivos de negocio, una infraestructura estándar de software, unos requisitos firmes a lo largo del proyecto o el uso de una metodología formal. Este último es uno de los puntos que el proyecto trata de proporcionar para facilitar la gestión de proyectos a los directores y jefes de proyecto. La siguiente figura muestra la relación existente entre los distintos participantes. Proyecto Director De de Proyecto Jefe De de Proyecto Equipo de Gestión del Proyecto Equipo de Proyecto Usuarios o Clientes del Proyecto 9

21 1.1 Grupos de procesos de la gestión de proyectos El proceso de gestión de proyectos del PMI proporciona un marco con unos pasos claros y una serie de técnicas para facilitar la gestión de proyectos. Existen cinco grupos de procesos definidos: inicio, planificación, ejecución, seguimiento y control (también llamado monitorización y control) y finalización. Planificación Ejecución Finalización Inicio Seguimiento y Control Cada uno de estos procesos posee una serie de entradas y unas salidas determinadas, convirtiéndose la salida de un proceso en la entrada de otros. El proceso de inicio define y autoriza el proyecto; la planificación trata de refinar los objetivos y planear las acciones para conseguirlos; la ejecución integra a personas y recursos para poder llevar a cabo el plan; con los procesos de monitorización y control se mide regularmente el progreso del proyecto para detectar variaciones en el plan y tomar medidas correctoras; por su parte, los procesos de cierre consiguen la aceptación formal del producto o servicio y consiguen una finalización ordenada del proyecto. 10

22 Inicio Planificación Monitorización y Control Ejecución Cierre Los procesos de la gestión de proyectos se presentan como elementos discretos con interfaces bien definidas. Sin embargo, en la práctica, estos grupos pueden tener solapamientos e interactuar de formas muy diversas. Un proyecto se puede gestionar de múltiples maneras, y los grupos de procesos son simplemente unas guías para aplicar una correcta gestión a lo largo de un proyecto. Los integrantes del equipo de proyecto serán los que deberán determinar qué procesos serán usados, por quién y con qué rigor se seguirán las recomendaciones propuestas por el PMI [PMI_04]. 11

23 Inicio Consta de los procesos que facilitan la autorización formal para iniciar un nuevo proyecto (o bien una fase del mismo). Este es el momento de describir claramente cuáles son los objetivos del proyecto, incluyendo las razones por las que un proyecto determinado es la mejor solución para satisfacer unos requisitos concretos. La documentación asociada a este grupo de procesos incluye el alcance del proyecto, una primera definición de los entregables, una estimación de la duración del mismo y una previsión de los recursos necesarios para llevarlo a cabo. Muchas organizaciones poseen herramientas para que cada uno de los proyectos que desarrollan sea consistente con su estrategia a largo plazo (por ejemplo con el uso de un Balanced Scoredcard). Las relaciones entre el proyecto y la estrategia definen las responsabilidades dentro de la organización. En las ocasiones en las que el proyecto tenga una complejidad importante se hace recomendable dividir éste en diferentes fases desde el inicio del mismo. También puede ser un buen hábito revisar los procesos de este grupo al inicio de cada fase del proyecto, para no perder de vista los objetivos de negocio que dieron lugar a la realización del proyecto, y permitir cambios en el proyecto si estos objetivos han cambiado o desaparecido. Existen dos procesos principales dentro de este grupo: elaborar el Project Charter y elaborar el Scope Statement preliminar. 12

24 Elaborar el Project Charter: el objetivo principal de este proceso es autorizar el inicio del proyecto (o una de sus fases). Se documentan las necesidades, oportunidades o problemas del negocio y el nuevo producto o servicio que intentará satisfacer esos requisitos. Las razones para iniciar un nuevo proyecto son muy variadas: nueva demanda en el mercado, una necesidad del negocio, una petición del cliente, un nuevo avance tecnológico, un requisito legal o una necesidad social pueden ser algunas de ellas. Con la elaboración de este documento se comunica al resto de la organización la existencia del proyecto, además de convertirse en una herramienta que puede servirle al jefe de proyecto para conseguir la autoridad necesaria para utilizar los recursos de la organización. Elaborar el Scope Statement preliminar: este proceso trata de definir de manera más concreta el propósito del proyecto, su alcance, los entregables y las restricciones. El alcance intenta plasmar los límites del proyecto, describiendo las principales actividades del mismo. Los entregables reflejan los productos, servicios o resultados que va a producir el proyecto. En este punto el interés se centra fundamentalmente en los entregables finales del proyecto. Por su parte, las restricciones abordan los límites económicos, temporales y estructurales que el proyecto posee. También puede ser interesante incluir el nombre de los 13

25 participantes, sus roles y una matriz de responsabilidad. El Scope Statement deberá ser revisado durante la vida del proyecto, modificándolo cuando alguno de sus puntos varíe. En los anexos A y B se pueden consultar unas posibles plantillas para la elaboración de estos documentos. 14

26 Planificación Este grupo de procesos ayuda a obtener información de muy diversas fuentes para poder desarrollar de forma correcta el plan del proyecto. También es en esta etapa donde se refina el alcance, se definen los costes y se realiza una planificación de las actividades a realizar. Debido a la naturaleza multidimensional de los proyectos, se producirá una retroalimentación que puede provocar cambios en las planificaciones previstas en esta etapa. A medida que se va descubriendo nueva información, las dependencias, requisitos, riesgos y oportunidades irán tomando una forma más definida que permita su gestión. En la planificación del proyecto se debería involucrar a todos los participantes importantes. La creación de un entorno apropiado para la correcta contribución de los participantes es una tarea fundamental que puede ayudar en gran medida al éxito del proyecto. Los procesos más importantes en relación con el proyecto desarrollado se detallan a continuación: Elaborar la EDT: Una EDT (Estructura de División del Trabajo) es la descomposición de un proyecto en un conjunto de tareas manejables. Es más conocida como Work Breakdown Structure (WBS) debido al origen anglosajón del concepto. Con esta 15

27 división conseguimos una visión más detallada del alcance del proyecto, permitiendo unas estimaciones más realistas en lo que se refiere a tiempo y coste, unas asignaciones más claras del trabajo a los miembros del equipo y una monitorización del progreso del proyecto más sencilla. Posee una estructura jerárquica, siendo el nodo raíz el proyecto a realizar. A medida que descendemos por la jerarquía, el detalle de las tareas se hace mayor. Además, existen dos tipos de tareas: por un lado tenemos las tareas resumen, que simplemente dan una visión de más alto nivel de las tareas que pertenecen a ella; por su parte, los paquetes de trabajo son las tareas que ejecutamos y no se descomponen más; estas últimas deben planificarse, estimarse y recibir un seguimiento. Para la elaboración de las EDT generadas por el proyecto se ha seguido la técnica denominada top-down. Esta técnica propone un primer nivel de descomposición, para el cual han sido usados los grupos de procesos del proceso de gestión de proyectos. Con ello se asegura que se contemplan las tareas relacionadas con la gestión de proyectos. En el segundo paso de esta técnica, se parte del primer nivel de jerarquía, y se realiza una descomposición en sucesivos niveles. En el proyecto, las tareas relacionadas con el grupo de procesos de ejecución se ha subdividido en función de la naturaleza de la metodología de desarrollo de software que se seguirá en el proyecto concreto. Por su parte, las tareas relacionadas con el resto de grupos de 16

28 procesos poseen siempre las mismas tareas predeterminadas, ya que se intenta realizar una gestión de proyectos uniforme a todo tipo de proyectos. Definición de actividades: este proceso es necesario para identificar las actividades que son necesarias realizar a lo largo del proyecto. Son creadas por el proyecto automáticamente, en función de la metodología usada para el desarrollo del proyecto. Crear la secuencia de actividades: trata de crear las dependencias entre las diferentes actividades del proyecto. Estas dependencias también son realizadas automáticamente por la aplicación, en función de la metodología escogida. Estimación de recursos de las actividades: en este proceso se estiman el tipo y la cantidad de recursos para la realización exitosa del proyecto. La aplicación permite al usuario introducir recursos humanos y materiales. Además, en el caso de los recursos humanos, se permite introducir un porcentaje de participación en el proyecto. La mayoría de las organizaciones abordan varios proyectos al mismo tiempo, por lo que cabe la posibilidad de que una persona reparta su tiempo en varios proyectos, asignando un porcentaje de ese tiempo a cada uno de ellos. 17

29 Estimación de la duración de las actividades: este proceso es necesario para realizar una estimación de la duración de las actividades del proyecto. La aplicación permite al usuario introducir tanto la fecha inicial estimada para el proyecto como la fecha de finalización estimada. A continuación, la aplicación calcula el tiempo estimado de duración según la aproximación Early Design del modelo COCOMO II [BAIK98]. Esta aproximación tiene una cierta incertidumbre, ya que se desarrolla en las primeras fases del proyecto y el conocimiento de los recursos y tiempos está sujeto a gran incertidumbre. Para realizar la aproximación, se presenta al usuario una pantalla de ayuda a la estimación, donde éste puede introducir los factores de escala (que tratan de tener en cuenta las economías y deseconomías de escala) y los multiplicadores de esfuerzo. COCOMO II es uno de los modelos de estimación más usados en la actualidad para el cálculo del esfuerzo necesario para acometer un proyecto. Es un modelo empírico, propuesto por Barry Boehm, que hace uso de la experiencia de muchos proyectos. Supone una evolución de COCOMO-81, que fue desarrollado suponiendo un modelo de ciclo de vida en cascada. Una vez calculado el tiempo total estimado para el proyecto, la aplicación distribuye este tiempo entre los cinco grupos de procesos de la gestión de proyectos: la fase de inicio obtendrá un 5% del tiempo, la de planificación un 15%, la de ejecución un 75% y la de cierre otro 5%. La fase de 18

30 monitorización y control abordará la práctica totalidad del proyecto, ya que es necesaria en todo momento. Estimación del coste: esta actividad trata de aproximar los costes de los recursos necesarios para la realización del proyecto. La aplicación permite al jefe de proyecto asociar tanto personas como recursos materiales a cada una de las fases. Cada persona tiene asociada una tasa estándar ( /h) y una tasa de horas extra. Además, los recursos materiales que lo requieran también poseen un coste por hora. Usando estas tasas y la duración de las fases a las que están asociados, la aplicación realiza un cálculo del coste previsto del proyecto. A medida que se van cerrando las diferentes fases, es posible introducir el coste real y por lo tanto observar la desviación con respecto a lo previsto en un primer momento. 19

31 Planificación de los recursos humanos: este proceso determina los roles y responsabilidades de las personas que forman parte del proyecto. Estas personas podrán pertenecen a la organización de forma permanente, o bien ser contratadas para alguna fase concreta del desarrollo. La aplicación permite asignar, al crear el proyecto, personas a un proyecto de forma general. Cada persona tendrá asociado un rol (jefe de proyecto, analista, programador) y un porcentaje de dedicación general al proyecto dentro de su tiempo total. Una vez el proyecto existe, se podrá concretar en qué fase o fases trabajará esa persona, pudiendo asignar, a su vez, un porcentaje de dedicación a cada actividad. Identificación y análisis de riesgos: un riesgo puede considerarse como un evento o circunstancia incierta que puede tener un efecto negativo sobre los objetivos del proyecto. Este proceso consiste en determinar qué riesgos pueden afectar al proyecto, y trata de documentar sus características. Esto ayuda a entender los riesgos de forma clara y a realizar una gestión de los mismos más efectiva. La identificación de riesgos debe ser un proceso iterativo, ya que a lo largo del desarrollo del proyecto pueden surgir nuevos riesgos que será necesario identificar, analizar y gestionar, por lo que en la etapa de monitorización y control también existe un proceso relacionado con los riesgos. La identificación de riesgos requiere la participación del equipo de proyecto, así como la de los participantes más 20

32 importantes, ya que pueden aportar información muy valiosa para el proceso. El PMBOK propone una serie de técnicas que ayudan en la identificación y análisis de los riesgos; sin embargo, sus resultados suelen ser listas de riesgos que en muchas ocasiones no ayudan al equipo de proyecto a la hora de saber en qué riesgos deben centrar la atención. Por ello, la aplicación propone una serie de categorías para cada riesgo, permitiendo así una mejor estructuración de los riesgos del proyecto. Se consigue una estructura de división de riesgos, conocida como RBS (Risk Breakdown Structure). Análogamente a lo que ocurría con la EDT (o WBS) los riesgos se presentan de una forma ordenada y estructurada que facilita la comprensión, comunicación y gestión de los mismos [HILL02]. Análisis cualitativo de los riesgos: en este punto se incluyen los métodos para priorizar los riesgos previamente identificados. Una forma muy directa de mejorar el rendimiento del proyecto es centrarse en los riesgos que posean una prioridad alta. Para poder realizar esta priorización, la aplicación otorga al usuario la posibilidad de introducir la probabilidad de que el riesgo se materialice y el impacto sobre los objetivos del proyecto si el riesgo tiene lugar. Además, se permite introducir una descripción del riesgo, así como información sobre el estado del mismo, para poder realizar un seguimiento de la evolución del mismo. 21

33 Elaboración y aprobación del plan de proyecto: este proceso contiene las acciones necesarias para definir, integrar y coordinar todos los planes específicos en un gran plan de proyecto. Este plan define cómo el proyecto es ejecutado, monitorizado y controlado, y cerrado. Normalmente incluirá los procesos seleccionados por el equipo de proyecto, el nivel de detalle de cada uno de ellos, las herramientas y técnicas que se emplearán para ejecutarlos, cómo se ejecutará el trabajo para lograr alcanzar los objetivos del proyecto, cómo se realizará la monitorización y control de los cambios, la metodología usada para el desarrollo del software del proyecto, etc. 22

34 Ejecución El grupo de procesos de ejecución variará en función de la metodología de desarrollo de software empleada en el proyecto. Sus procesos serán los usados para conseguir completar el trabajo definido en el plan de proyecto, y así satisfacer los requisitos y objetivos del proyecto. Es muy importante una buena coordinación de las personas y los recursos materiales, así como integrar y llevar a cabo las actividades del proyecto de acuerdo con el plan de proyecto elaborado en la etapa de planificación. Es posible que durante la ejecución se tengan que revisar algunos aspectos planificados, como la duración de las actividades, productividad de los recursos o los riesgos identificados. La aplicación variará las actividades de esta fase en función de la metodología usada. Cada una de las actividades podrá tener asociado un entregable, que tendrá la posibilidad de ser consultado por los miembros del equipo de proyecto. En el capítulo dedicado a las metodologías de desarrollo de software se proporciona una descripción más detallada de cada una de estas metodologías y de las fases y actividades que forman parte de ellas. 23

35 Monitorización y Control Este grupo de procesos tiene como objetivo realizar un seguimiento de los procesos del proyecto ejecutados, para permitir una correcta identificación de los problemas que puedan surgir y así realizar acciones correctivas. El seguimiento debe realizarse de una forma continua en todos los esfuerzos realizados para la realización del proyecto. El equipo de proyecto, y en especial el director y el jefe de proyecto, juegan un papel muy importante para una correcta monitorización de las actividades acometidas. Algunas de las tareas que se deberían realizar pueden ser automatizadas, aunque muchas de ellas requerirán de la buena labor del jefe o del director de proyecto para saber dónde pueden aparecer problemas, y por tanto es imprescindible su trabajo para poder desarrollar las tareas de este grupo de procesos. La aplicación ofrece una ayuda para poder hacer el seguimiento del proyecto en los siguientes procesos: Control de costes: el director de proyecto tiene la posibilidad de crear un gráfico de todos los proyectos en los que participa para pasarlo a su PDA o dispositivo móvil. Esto permitirá al director tener constancia de la evolución de cada uno de sus proyectos de una forma rápida, 24

36 actualizada e intuitiva, pudiendo hacer uso de esa información en cualquier momento y lugar. En estos gráficos se representa, por cada proyecto, el importe de venta del mismo, el coste estimado y el coste real hasta ese momento. Esta información de costes también puede ser consultada en los detalles de cada proyecto, donde se usan diferentes colores en función de si la variación del coste real con respecto al planificado es negativa (rojo) o positiva (verde). El coste estimado del proyecto se calcula tanto para el conjunto total como para cada una de las fases. Esto se realiza teniendo en cuenta los recursos (tanto humanos como materiales) asignados a cada fase, su coste, su porcentaje de dedicación y la duración de la fase en cuestión. En lo que concierne al coste real, el jefe de proyecto tiene la posibilidad de introducirlo cada vez que de por finalizada una de las fases del proyecto. Gestión del equipo de proyecto: este proceso trata de realizar un seguimiento de la productividad del equipo de proyecto, resolver los posibles conflictos, coordinar cambios, etc. Muchas de estas actividades no son candidatas a incorporarse a un proceso automatizado (no tendría mucho sentido resolver los conflictos que puedan tener lugar con una herramienta software), pero la aplicación permite añadir nuevos miembros al equipo de proyecto o bien sacar del equipo a alguno de los integrantes. En lo que respecta al 25

37 seguimiento de la productividad, el jefe de proyecto lo podrá realizar a través del fichero de Microsoft Project generado por la aplicación. Seguimiento y control de riesgos: este proceso trata de identificar y analizar los nuevos riesgos que puedan surgir a lo largo del desarrollo del proyecto, así como realizar un control sobre los riesgos identificados en las fases iniciales del proyecto. La aplicación permite conocer el estado de todos los riesgos identificados en cualquier momento, proporcionando la posibilidad de modificar el impacto o el estado de éstos, así como añadir nuevos riesgos que no fueron identificados anteriormente. El equipo de proyecto debe tener en cuenta estos riesgos para poder actuar en consecuencia si alguno de ellos realmente tiene lugar. Estar preparado ante estos acontecimientos proporciona una mayor agilidad y flexibilidad al proyecto, y evita situaciones de incertidumbre que pudieran provocar retrasos al proyecto. 26

38 Cierre Este grupo de procesos tiene como función cerrar el proyecto formalmente. Al cerrar el proyecto se deben finalizar todas las actividades acometidas a lo largo de todos los grupos de procesos. Es necesario comunicar de forma clara al cliente del proyecto las razones por las cuales el proyecto finaliza (ya sea debido a la consecución de los objetivos establecidos, o por su cancelación), para que el cliente apruebe la decisión y el proyecto pueda ser concluido de forma oficial. Muchas organizaciones también requerirán una finalización administrativa del proyecto, proporcionando al área funcional correspondiente de la empresa los datos necesarios para contabilizar las actividades desarrolladas por el proyecto. 27

39 2. Metodologías de desarrollo de software A día de hoy existen una gran variedad de metodologías a la hora de abordar un proyecto de desarrollo de software. El proyecto trata de proporcionar un modelo para cada una de las metodologías más importantes de la actualidad. Todas las fases de cada una de las metodologías que se detallan a continuación son creadas automáticamente por la aplicación, y están encuadradas dentro del grupo de procesos de ejecución, definido por el PMI en el PMBOK [PMI_04]. Para más información se puede acudir al capítulo correspondiente al proceso de gestión de proyectos. 28

40 Modelo Lineal o en Cascada Las primeras aplicaciones informáticas se desarrollaron según los procedimientos que posteriormente llegarían a constituir el modelo lineal. Este modelo, en sus diferentes versiones, ha sido un estándar de facto en la industria hasta la aparición de nuevas necesidades, y por consiguiente, de nuevas formas de abordar el desarrollo de un sistema. Existen numerosas versiones de este modelo (Yourdon, Method1, MÉTRICA, SSADM, etc.) pero todas tienen unas características comunes: existen un conjunto de fases secuenciadas en el tiempo, y a la finalización de una fase se comienza la siguiente tomando como datos de entrada los resultados de la anterior. En cada una de las fases se introduce más detalle hasta conseguir el código ejecutable [BARR01]. Este enfoque tiene una serie de ventajas, aunque también inconvenientes. Entre sus puntos fuertes cabe destacar su gran rendimiento en proyectos de gestión de tamaño grande y mediano. Además, ha sido, y posiblemente es, la metodología más usada para la construcción de sistemas de información, por lo que los desarrolladores conocen bien todas sus fases y existe una gran cantidad de documentación disponible. Sin embargo, y esto es cada vez más importante, deja de lado ciertos ámbitos de gestión que lo hacen perder fuerza frente a sus competidores. Si se sigue este modelo, el usuario no ve resultados hasta que el proyecto está en una fase avanzada. Esto trae consigo ciertos 29

41 inconvenientes, ya que si no se han analizado correctamente las necesidades y los requisitos del usuario (algo que normalmente es realmente complicado conseguir en el inicio del proyecto), éste puede darse cuenta en una fase excesivamente avanzada para la fácil reconstrucción del proyecto [LEON96]. El proyecto aborda esta metodología en cuatro fases principales: definición (identificación de necesidades), análisis (análisis de requisitos, diseño de arquitectura técnica), diseño (diseño externo, diseño interno), construcción (programación, pruebas del sistema, implantación) y mantenimiento. Definición Análisis Diseño Construcción 30

42 Modelo en V El modelo en V surgió como una variación de la metodología lineal, aunque asociando pruebas a cada una de las fases, y estableciendo métodos para validar cada fase (conformidad). El mayor problema reside en la capacidad que se pueda tener para asegurar la conformidad mediante pruebas sobre el código. Este modelo, sin embargo, es muy recomendable en desarrollos donde los requisitos tengan una importancia vital, ya que el mismo modelo exige una serie de pruebas que permiten descubrir los posibles fallos del desarrollo. Por este motivo, muchos desarrollos en tiempo real o para sistemas empotrados se realizan siguiendo esta metodología [LEON96]. Un sistema en tiempo real puede definirse como aquel sistema donde la corrección de su comportamiento no sólo depende de los resultados lógicos de los cálculos que realiza, sino también del momento físico en el que estos resultados son producidos. Un desarrollo en tiempo real requiere un enfoque algo diferente con respecto al usado en desarrollos para sistemas de gestión. El tiempo es una variable absolutamente importante [LAPL04]. Los sistemas en tiempo real se pueden clasificar en dos grandes grupos: por un lado tenemos los sistemas soft, que son aquellos donde la operación del sistema se ve degradada si los resultados no son producidos de acuerdo con unas restricciones temporales; por su parte, los sistemas hard son aquellos donde su operación es incorrecta si los resultados no satisfacen los requisitos 31

43 temporales. Estos últimos suelen encontrarse en entornos donde el tiempo es vital, y pueden requerir de una programación en lenguaje ensamblador para poder actuar de forma extremadamente rápida [KOPE97]. Estos sistemas, además, pueden requerir de un modelado en W, en lugar de en V, que incluye una fase de simulación además de las fases dedicadas a las pruebas. Se pueden encontrar una gran cantidad de redes para desarrollos en tiempo real, como CAN (Controller Area Network) [ISO_03], LonWorks [ECHE99], TTP (Time-Triggered Protocol) [TTAG02] o WorldFip [IEC_03]. En estos sistemas también cobra una importancia notable el sistema operativo elegido. Para este tipo de desarrollos es muy conveniente que el sistema operativo elegido cumpla con los requisitos impuestos por el estándar de IEEE POSIX Análisis Requisitos Usuario Conformidad Pruebas de Aceptación Análisis Requisitos Sistema Conformidad Pruebas del Sistema Diseño Preliminar Conformidad Pruebas de Integración Diseño Detallado Conformidad Pruebas Modulares Codificación 32

44 Modelo Incremental o Evolutivo Uno de los problemas que presentaba el modelo lineal era el hecho de no ver los resultados del desarrollo hasta que éste se encontraba en una fase muy avanzada, dificultando así el cambio. El modelo incremental, por el contrario, evita este inconveniente con la posibilidad de obtener prototipos ejecutables intermedios. Para ello, se parte de una base estable de requisitos, que pueden ir aumentando en las siguientes fases, provocando la evolución del sistema en cada fase. Un prototipo es una descripción del sistema desde un determinado punto de vista; además, como no son prototipos totales, no es necesario que cubran todo el sistema, sino las partes que se desean analizar en un momento dado. Los prototipos son ejecutables, para que se puedan validar por parte del cliente y el equipo experimentando sobre él. En el modelo incremental los prototipos no están orientados a implementar una parte del sistema final, sino razonar sobre modelos lógicos que no han sido implementados aún. El uso de este modelo suele orientarse a sistemas complejos, y suelen usar entornos gráficos para autoexplicar su funcionalidad, reduciendo así la documentación. Esas herramientas gráficas son precisamente, a su vez, la principal restricción del modelo, ya que pueden impedir unas medidas fiables sobre su rendimiento. 33

45 Como otras características de este modelo se puede citar la mayor participación por parte de los usuarios, la dificultad para poder obtener un coste total, la dificultad para aplicarlo a sistemas transaccionales que suelen estar integrados y funcionar como un todo, y la importancia de partir de una base estable de requisitos iniciales, que será muy costosa de cambiar si el equipo de proyecto se ve obligado a ello. Análisis Requisitos Sistema Análisis Requisitos Software Análisis Requisitos Software Análisis Requisitos Software Diseño Diseño Diseño Codificación Codificación Codificación 34

46 Modelo en Espiral En los años 80 Barry W. Boehm propuso este modelo para poder suplir de forma satisfactoria las carencias del modelo lineal [BOEH88]. El propio autor fue depurando el modelo durante varios años mientras lo aplicaba a grandes proyectos para el gobierno de los Estados Unidos. Este modelo se desarrolla según cuatro etapas básicas: planificación, desarrollo, evaluación y selección de alternativas. El desarrollo pasa por una serie de ciclos donde se va avanzando en el conocimiento del sistema. Una vez eliminadas las incertidumbres de la espiral, se procede a un desarrollo convencional en la última etapa. Con este modelo se trata de asegurar que los aspectos más críticos sean realizados antes. Se recomienda el desarrollo de prototipos desechables, así como una correcta identificación y gestión de riesgos. Los ciclos iniciales del modelo tienen como objetivo asegurar la correcta comprensión del sistema, y sólo se llega a implementar cuando se ha conseguido eliminar los riesgos. 35

47 Cualquiera de los ciclos del modelo comienza con la identificación de los objetivos de la parte del producto que se elabora en ese momento, las alternativas posibles para poder desarrollar esa parte del producto y las restricciones impuestas por la aplicación de las alternativas. El siguiente paso consiste en evaluar las alternativas en relación con los objetivos y las restricciones. Así se consiguen evaluar los riesgos y permite tomar acciones para su correcta gestión. Posteriormente se realiza el desarrollo de un prototipo, que si consigue resolver todos los riesgos identificados, dará paso a un modelo clásico para la finalización el desarrollo. Si, por su parte, no todos los riesgos han sido resueltos, se procederá a realizar un ciclo más hasta conseguir eliminar estos riesgos. 36

48 Modelo de Síntesis Automatizada Este modelo permite generar automáticamente el código de la aplicación partiendo de una especificación detallada de los requisitos del sistema. Es necesario el uso de requisitos formales de especificación, para que la tecnología usada pueda comprender correctamente los requisitos y generar una implementación a partir de los mismos. Una vez capturada la especificación, ésta se va refinando para conseguir poder introducir más detalles [BARR01]. El enfoque de este modelo presenta una serie de ventajas: se produce un gran incremento de la confianza en el diseño, se facilita el mantenimiento (se realiza sobre la propia especificación) y la evolución del sistema, y se permite una documentación del sistema más completa y precisa. Sin embargo, aún hoy no es posible generar todo el código con estas herramientas, por lo que se debe seguir acudiendo a la programación convencional; además, se requiere una formación diferente del equipo de proyecto, que normalmente estará habituado a las técnicas clásicas de desarrollo. 37

49 Necesidades informales Captura de la especificación Especificación inicial Refinamiento de la especificación Especificación refinada Catálogo de especificaciones Síntesis automática Código Catálogo de componentes La síntesis automatizada es muy usada en la elaboración de sistemas de tiempo real, ya que estos sistemas poseen unos requisitos temporales muy estrictos. Al traducir estos requisitos a un lenguaje formal, el equipo de proyecto se obliga a especificarlos de una forma muy precisa, evitando los riesgos que el poco detalle de los mismos puede traer consigo. 38

50 Rapid Application Development (RAD) Esta metodología nació para realizar un desarrollo más rápido en comparación con el resto de metodologías. Sus objetivos buscan aumentar la productividad, reducir los costes de desarrollo y aumentar la calidad del sistema. Nació de la necesidad de obtener sistemas a una velocidad mayor. La industria exige resultados visibles cada vez más rápido, por lo que algunas de las metodologías clásicas no podían responder a estos requisitos. Sin embargo, no todos los proyectos pueden ser realizados según esta metodología, ya que si se necesita satisfacer unos requisitos muy exigentes, esta metodología no será la más adecuada. Esta metodología posee una lista de tareas y una estructura de división de tareas que están orientadas a la construcción del sistema en un tiempo pequeño. De todos modos, la mayor diferencia de RAD con respecto al resto de metodologías consiste en una serie de técnicas para optimizar la velocidad de desarrollo. La primera de ellas es el uso del prototipado: crear un resultado visible tan pronto como sea posible, y posteriormente refinarlo. El refinamiento se basa en los comentarios del cliente. También hace el uso de la iteración, que está muy unida a los prototipos. Por último, se hace uso de técnicas que se centren en los entregables: se puede cambiar el alcance, pero no los entregables ni su fecha de entrega. 39

51 Planificación de requisitos Diseño de usuario Construcción rápida Transición La primera fase de esta metodología tiene como objetivos establecer un conocimiento general de los problemas del negocio que motivan el desarrollo del sistema, familiarizarse con sistemas existentes que pueden ser parecidos al que se va a desarrollar e identificar las funciones de negocio que serán soportadas por la aplicación. En la segunda fase se desarrolla la estructura del sistema, distinguiendo entre los procesos manuales y automatizados que realizará el sistema, se obtienen las pantallas de los procedimientos automatizados del sistema más importantes, se selecciona el enfoque de construcción apropiado para el sistema y se prepara un plan de trabajo que defina los pasos necesarios para la transición del sistema, el esfuerzo requerido para llevarlos acabo y un calendario que indique cuándo se deben completar esos pasos. Durante la construcción rápida se completa un diseño detallado del sistema propuesto, se crea y prueba el software, se genera un sistema que opere en un nivel aceptable de rendimiento, se prepara la documentación necesaria para la operación del sistema y se dan los pasos necesarios para preparar el paso del sistema a producción. 40

52 Por último, durante la etapa de transición, se instala el sistema en producción, intentando no interferir con la actividad normal del negocio, se maximiza la efectividad del sistema y se identifican las posibles mejoras futuras. 41

53 Modelo Orientado a Objetos La metodología orientada a objetos tiene su base en un modelo incremental. Sin embargo, debido a su gran aceptación en los desarrollos actuales, y sus peculiares características para modelar el mundo, merece una mención aparte. Una explicación detallada de esta metodología se puede encontrar en los diferentes capítulos del proyecto, ya que ha sido la metodología usada en su desarrollo. 42

54 Modelo Prototipado Este modelo se basa en la construcción de prototipos (implementación parcial pero concreta del diseño de un sistema). Se actúa sobre todas las etapas del proceso de desarrollo para ir modelando y ajustando el sistema a las necesidades del usuario, que evaluará cada uno de los prototipos que se le presenten. Estos prototipos cuentan con ficheros de datos reales, e incluso pueden llevar parte de programación para presentarle ciertas funciones al cliente de la aplicación. Los prototipos desarrollados pueden ser de dos tipos fundamentales. Por un lado tenemos los prototipos verticales, donde se presta atención a una parte pequeña del sistema pero prácticamente en su forma final (este tipo es importante si la especificación de los requisitos no establece claramente qué es lo que se desea sobre un aspecto concreto). Por su parte, los prototipos horizontales tienen como objetivo dar una visión global del sistema sin entrar en los detalles concretos (se usa cuando se busca conocer la estructura general de la relación entre el usuario y el sistema a desarrollar). Ambos prototipos son complementarios, por lo que podrán ser usados en un mismo desarrollo. 43

55 3. Metodología orientada a objetos Se ha decidido abordar el desarrollo del proyecto según una metodología orientada a objetos. Este tipo de metodología promueve la reutilización futura de sus componentes, así como la reducción en los posibles futuros cambios y el mantenimiento del sistema. Las técnicas de orientación a objetos surgieron a principios de los años 80, suponiendo un gran cambio con respecto a las anteriores metodologías estructuradas. En este nuevo enfoque, conjuntos de datos y operaciones sobre los mismos se agrupan (encapsulan) en entidades llamadas objetos que pueden comunicarse entre sí a través de los llamados servicios (métodos) que cada uno de los objetos ofrece al resto. Otra característica importante es que los datos de cada objeto están ocultos al resto de los objetos con los que interactúa, siendo accesibles únicamente desde el interior del propio objeto al que pertenecen. Esto puede hacer pensar que esos datos nunca serán accesibles desde el exterior, aunque no es exactamente así. Si un objeto requiere información de los datos de otro objeto, deberá solicitar ese conocimiento a través de uno de los servicios proporcionados por el objeto dueño de los datos requeridos, evitando así la interacción entre el objeto solicitante y los datos del otro objeto. 44

56 Con este nuevo enfoque se daba un paso más para acercar la vida real al desarrollo de software, ya que las entidades reales (ya sean físicas o lógicas) pueden verse claramente reflejadas dentro del sistema informático. Objeto Otra de las grandes ventajas que traen consigo las metodologías orientadas a objetos es que los usuarios de los servicios de un objeto (otros objetos) no conocen los detalles de cómo es el objeto, sino que pueden acceder a él conociendo únicamente los servicios que ofrece y cómo deben solicitarse esos servicios. Existe una gran cantidad de trabajos que hablan sobre la orientación a objetos, y por lo tanto una gran variedad de opiniones y técnicas para llevarla a cabo, aunque la mayoría de estas opiniones coinciden en una serie de pilares en los que la orientación a objetos sustenta su gran capacidad de abordar diferentes problemas: 45

57 Abstracción: es la capacidad de un objeto de cumplir sus funciones, independientemente del contexto en el que se encuentre el mismo. Esto permite que, durante el análisis, se puedan tratar únicamente los conceptos del dominio del problema, sin tener que tomar decisiones de diseño o incluso de implementación antes de tiempo. De esta forma se consiguen posponer los detalles de la programación hasta la fase final de la elaboración del código. Encapsulamiento: también llamado ocultamiento de información, permite separar los aspectos exteriores del objeto (servicios que proporciona a otros objetos) de los detalles internos de la implementación del mismo. Con esto se consigue dar un salto cualitativo en lo que respecta a la facilidad de realizar cambios en la aplicación, ya que se reducen de forma casi total los efectos secundarios que la introducción o el cambio de una funcionalidad pudieran traer consigo. Polimorfismo: aporta la posibilidad de tener diferentes implementaciones de una misma operación. Cada objeto puede ofrecer un determinado servicio de forma totalmente distinta, aunque si un objeto solicita los servicios a ambos, no notará la diferencia, ya que esa diferencia sólo es visible en la implementación. 46

58 Herencia: este mecanismo permite compartir una estructura común entre diferentes clases (que no son más que la generalización de un objeto) a las que se les denomina subclases. Este mecanismo aporta una gran claridad, tanto a nivel de código como a nivel conceptual. La herencia obtiene una potencia aún mayor cuando es combinada con el polimorfismo, la abstracción y el encapsulamiento. 47

59 4. UML (Unified Modeling Language) El lenguaje unificado de modelado o UML es el heredero de los distintos métodos de análisis y diseño orientados a objetos existentes a finales de los años 80. Con el nacimiento de este lenguaje se unificaron los métodos de Booch y OMT (Object Modeling Technique) que se habían desarrollado independientemente y convertido en los métodos más usados por los seguidores de la orientación a objetos. Existieron varios motivos para unificar los distintos métodos en un solo lenguaje de modelado [BARR01]: Eliminar diferencias innecesarias entre los distintos métodos de orientación a objetos. Unificar la semántica y notaciones, aportando así un estándar al mercado. Mejorar los métodos anteriores, aportando nuevos aspectos que no eran resueltos en ninguno de ellos. Desde el nacimiento de la versión 0.9 en junio de 1996, UML ha evolucionado, encontrándose ahora en su versión 2.0 (julio 2005). 48

60 UML posee una serie de vistas, donde cada una de ellas es una proyección del sistema completo, además de hacer hincapié en un aspecto concreto del sistema. Cada vista se describe con una serie de diagramas, no existiendo una separación estricta, sino que un diagrama puede formar parte de diferentes vistas. Las vistas son [OMG_05]: Vista de casos de uso: muestra la funcionalidad del sistema vista desde la perspectiva de actores externos. Es descrita por los diagramas de casos de uso y los diagramas de actividad, siendo la vista central que dirige el desarrollo del resto de vistas. Vista lógica: muestra cómo la funcionalidad del sistema es diseñada. Hace uso de diagramas de clases y objetos para representar la estructura estática. El comportamiento dinámico viene representado por diagramas de estado, de secuencia de colaboración y de actividad. 49

61 Vista de componentes: muestra la organización de los componentes del código y sus dependencias. Se representa con los diagramas de componentes (o paquetes). Vista de concurrencia: trata los problemas de la comunicación y la sincronización en un sistema concurrente. Es descrita por los diagramas de estado, de secuencia, de colaboración, de actividad, de despliegue y de componentes. Vista de despliegue: muestra el despliegue de la aplicación en la arquitectura física donde entrará en funcionamiento. Es representada con los diagramas de despliegue. Vista lógica Vista de componentes Vista de casos de uso Vista de despliegue Vista de concurrencia 50

62 La aplicación hace uso de algunos de los diagramas UML mencionados anteriormente, explicándose su significado, símbolos y objetivos que persiguen a medida que se describen las diferentes fases del modelo de ciclo de vida que se ha seguido en el desarrollo de la aplicación. 51

63 5. Patrones de diseño Los patrones de diseño son soluciones para problemas de diseño en el software que se suelen presentar de forma recurrente en el desarrollo de una aplicación real. Los patrones de diseño ayudan al diseño y la interacción de los objetos, proporcionando una solución elegante y reusable para problemas típicos de desarrollo. Con los patrones de diseño conseguimos identificar, abstraer y nombrar los aspectos esenciales de una estructura de diseño (clases e instancias que participan, relaciones entre ellas y las colaboraciones y distribuciones de responsabilidad). Los patrones de diseño se pueden clasificar en [BUSC96]: Arquitectura: expresan la estructura fundamental de la organización de un sistema, proporcionando un conjunto de subsistemas predefinidos, especificando sus propiedades y relaciones. Diseño: resuelven problemas específicos de diseño a nivel de subsistema o componente. Idioms: son patrones de bajo nivel, específicos de cada lenguaje de programación. Describen cómo implementar ciertos aspectos de un problema usando las características del lenguaje específico. 52

64 Patrón MVC (Modelo Vista Controlador) Este patrón, de tipo arquitectura, se introdujo por primera vez en el entorno de programación Smalltalk 80. Surgió porque el interfaz de usuario está especialmente sujeto a cambios: al extender la funcionalidad de una aplicación se deben modificar las partes del interfaz afectadas, diferentes clientes requieren la misma funcionalidad pero deben acceder a ella de distinta forma, la misma información necesita ser mostrada de varias maneras, etc. MVC divide una aplicación interactiva en tres componentes. El modelo encapsula la funcionalidad y los datos del núcleo de la aplicación. Las vistas muestran información al usuario. Los controladores manejan la información introducida por el usuario. Solicitud de estado Vista Solicita el estado al modelo. Presenta el modelo. Envía acciones del usuario Modelo Representa los datos de la aplicación. Expone servicios genéricos para consultar y actualizar el estado. Actualización Notifica cambios de estado. del estado Notifica cambios Acciones del Controlador usuario Define el comportamiento de la aplicación. Selección Mapea acciones del usuario a actualizaciones del modelo. Selecciona la siguiente vista. 53

65 Patrón DAO (Data Access Object) El patrón DAO surge debido al problema existente cuando las aplicaciones acceden a datos residentes en almacenes permanentes. El código de conectividad y acceso es complejo, y es deseable separarlo de la lógica del negocio. Los objetos de tipo DAO gestionan la conectividad con el almacén, exponen una interfaz más simple a sus clientes, que son los componentes del negocio, y actúan como adaptadores entre el componente y la fuente de datos. Con este patrón se consigue una gran transparencia: los objetos de negocio pueden hacer uso de la fuente de datos sin necesidad de conocer los detalles de su implementación. Además, facilita la migración a diferentes implementaciones de bases de datos, simplifica el código de los objetos de negocio y centraliza todo el acceso a datos en un nivel separado. Nivel DAO Nivel de Negocio 54

66 6. Fases del ciclo de vida de la aplicación Para el desarrollo de la aplicación se ha seguido una metodología orientada a objetos, con ayuda del lenguaje UML, y siguiendo una serie de fases para su ejecución: Análisis de Requisitos Esta etapa trata de analizar el problema que se plantea, para tener una visión global del mismo y de la solución que se aportará. Se cubrirán las siguientes actividades: Descripción inicial del dominio del problema, representando los conceptos, sus propiedades y las relaciones entre los más importantes del dominio de la aplicación. Especificación de requerimientos funcionales con el usuario, en términos de casos de uso. Discusión y validación de requerimientos. Descripción detallada de cada caso de uso, señalando la funcionalidad por defecto (escenario primario), las posibles variantes (extensiones) y los posibles errores. Definición de un borrador de la interfaz del sistema al usuario, que muestre cómo se plasmarían los distintos casos de uso. 55

67 Diseño del Sistema En esta etapa se dividirá el sistema en varios módulos (si los requisitos y el tamaño así lo exigen) y se definirá la forma de comunicación con las aplicaciones externas ya existentes con los cuales va a interactuar el sistema. Se obtendrá como producto la arquitectura del sistema y la versión inicial de los diagramas de ejecución. Diseño Detallado Esta fase trata de obtener el modelo funcional y dinámico del sistema, ajustando y refinando el diseño del sistema y los requisitos del mismo al ambiente de implementación. Además, se creará el modelo de control, así como la interfaz de la aplicación. Codificación y Pruebas En esta etapa se pasará de las clases de diseño a las clases de implementación, teniendo en cuenta que la relación no tiene porqué ser de uno a uno. En esta etapa también se diseñarán de forma concreta las bases de datos que darán soporte permanente a los datos necesarios para el buen funcionamiento del sistema. Asimismo, se desarrollará el código tratando de que éste sea lo más limpio y legible posible. Una vez terminada la codificación se realizan dos tipos de pruebas: 56

68 Unitarias: se prueban módulos por separado, haciendo revisiones de código cuando sea necesario. De módulos y del sistema: se pasan una serie de casos de prueba, además de especificar el procedimiento de instalación de la aplicación. 57

69 6.1 Análisis de Requisitos Modelo de Dominio Un modelo de dominio (también llamado modelo del mundo) es un diagrama de clases UML que trata de reflejar los conceptos del problema, sus propiedades y las relaciones entre ellos. El objetivo principal de un modelo de dominio es proporcionar a los analistas y desarrolladores una visión conceptual del problema, una forma de entender con qué se enfrentan. Está realizado desde una perspectiva conceptual, esto es, no se usa para solucionar el problema, sino para entender el mismo y poseer una herramienta que sirva como base para abordar la resolución posterior del problema. En el modelo de dominio, cada clase representa un concepto identificado del dominio del problema. Los atributos de las clases tratan de representar las propiedades de esos conceptos. Por su parte, las asociaciones entre las clases muestran relaciones conceptuales existentes entre los distintos conceptos. Además, el diagrama también contiene una serie de comentarios que tratan de aclarar algún concepto. Otro mecanismo utilizado es el de la generalización, que se representa como una flecha en lugar de una línea, usada ésta por las asociaciones. 58

70 59 Desarrollo de Modelos

71 Glosario de Clases El glosario de clases trata de explicar los conceptos representados en el diagrama anterior. Cliente Es cualquier entidad para la cual se desarrolla un proyecto, o bien recibe una oferta de proyecto futuro. Un cliente puede recibir varias ofertas de proyecto al mismo tiempo, así como estar recibiendo los servicios de la organización en varios proyectos en un momento dado. Documentación Asociada Un proyecto suele contener una serie de documentos asociados al mismo, como puede ser un estándar determinado, que ayudan a tener un mejor conocimiento del mismo. Proyecto Un proyecto de desarrollo de software consiste en el uso de hardware, software y/o redes de comunicación para poder crear un producto o servicio. Existe una gran diversidad en cuanto a tamaños y tipos, aunque todos tienen en común el hecho de que son finitos en el tiempo, con un inicio y una finalización definidos. Además, dispondrán de una serie de recursos y se desarrollarán según una determinada metodología. Cabe destacar que un proyecto, al estar realizado dentro de una organización determinada, no es independiente de ésta, sino que sirve a los propósitos de la 60

72 misma. Se deberán contemplar los aspectos tecnológicos, organizativos y de negocio necesarios para poder situar un proyecto correctamente dentro del contexto determinado de una organización. Oferta Una oferta de proyecto representa un proyecto potencial. Las organizaciones suelen realizar ofertas para las distintas necesidades de sus clientes. Una oferta, si es aprobada, podrá dar lugar a un proyecto. Además, notificará el uso de una serie de recursos necesarios para su posible desarrollo. Recurso Un recurso es cualquier elemento disponible para resolver una necesidad o poder llevar a cabo una tarea determinada. En el contexto del proyecto, son interesantes dos tipos diferenciados de recursos. Recurso Humano Es cualquier persona que hace uso de sus conocimientos técnicos y su experiencia para llevar a cabo una serie de tareas. Recurso Material Representa cualquier recurso no humano (ya sean máquinas, capital o cualquier otro tipo de recurso) que es necesario para poder solventar alguna necesidad dentro del proyecto. 61

73 Tareas Una tarea representa cualquier trabajo que debe hacerse en un tiempo limitado. Algunas tareas tendrán una restricción temporal más fuerte que otras, dependiendo de cómo afecten al desarrollo del proyecto en su conjunto. Además, existen ciertas tareas que no poseen duración: son los llamados hitos, que tienen como objetivo fundamental ayudar en la gestión del proyecto, facilitando su monitorización y control. Actividades Un conjunto de tareas relacionadas normalmente forman parte de una actividad. Estas actividades suelen estar en un orden determinado, y sólo tienen sentido si poseen alguna tarea. Fases Así como las tareas se agrupan en actividades, las actividades pueden formar parte de una fase determinada. Cada fase representa una parte importante de un proyecto, se encuentran en un orden determinado, y suelen tener relacionado un entregable que puede ser usado por otras fases del proyecto. Entregable Representa el producto obtenido al finalizar una fase determinada. Es importante realizar un control sobre los entregables de cada fase, ya que éstos pueden ser necesarios para el correcto desarrollo de una fase posterior del 62

74 proyecto, con el consiguiente retraso en la consecución de los objetivos si los entregables no son visibles a tiempo. Metodología Una metodología de desarrollo de software trata de definir qué hay que hacer y en qué orden, cómo deben realizarse las tareas y con qué herramientas pueden llevarse a cabo. No todos los sistemas se desarrollan de la misma manera, sino que suelen seguir un determinado ciclo de vida, pasando su desarrollo por diferentes etapas. Existen numerosos paradigmas de ciclo de vida: secuencial, en espiral, prototipado, modelado en V, orientado a objetos, etc. 63

75 6.1.2 Diagrama de Casos de Uso Muestra gráficamente los casos de uso del sistema, las relaciones entre ellos y los actores que participan en ellos. Un actor es un rol abstracto (puede ser una persona, organización o sistema), que es externo al sistema y además interactúa con él. En su término más simple el término actor se refiere al usuario, cuando éste desempeña un papel determinado de cara al sistema. Los actores son los que llevan a cabo los casos de uso, y no existe un número máximo de casos de uso para un determinado actor, así como también es posible que un caso de uso sea realizado por varios actores. Se llama actor primario a aquel actor que inicia la interacción con el sistema para conseguir algún objetivo. El sistema responde, pero siempre protegiendo los intereses del resto de actores y del sistema. Además, diferentes secuencias de comportamiento (también llamados escenarios) pueden tener lugar, dependiendo de las condiciones particulares que rodean a las peticiones de los actores. Un caso de uso trata de capturar un contrato de un actor determinado acerca de su comportamiento. Responde al objetivo de un actor con respecto al sistema. Para clarificar el concepto, consideremos el procesador de textos usado para escribir este documento. Un ejemplo de caso de uso podría ser poner parte del texto en cursiva. Vemos que este caso de uso tiene ciertas propiedades: 64

76 Se capta una función visible para el actor. No posee un tamaño predefinido. Es una unidad funcional con sentido para el actor. Un escenario puede representar una forma alternativa de conseguir el objetivo, una situación de error que es recuperada y se consigue el objetivo, o bien una situación de error que no es posible recuperar y el objetivo es abandonado. Los casos de uso que se describen a continuación representan los requisitos funcionales del sistema desarrollado por el proyecto. Se han dividido según el actor primario que inicia el caso de uso. 65

77 Director de Proyecto 66

78 Jefe de Proyecto 67

79 Analista 68

80 Programador 69

81 6.1.3 Descripción detallada de los casos de uso A continuación se presenta una descripción completa de cada uno de los casos de uso presentados en el diagrama anterior. Para cada caso de uso se describen una serie de características: Nombre del caso de uso: es el objetivo del actor primario con respecto al sistema. Actor primario: actor cuyo objetivo da nombre al caso de uso. Normalmente también será el que lo inicie, aunque no es obligatorio. Además, suele participar en el caso de uso intercambiando información con el sistema. Actores secundarios: cualquier otro actor que participe en el caso de uso, ayudando al sistema a conseguir el objetivo del actor primario. Trigger: evento que inicia el caso de uso. Normalmente un caso de uso será iniciado por el actor primario, aunque existen dos ocasiones en las que esto puede no cumplirse: en procesos periódicos y cuando algún otro actor inicie el caso de uso en nombre de otro actor del sistema. Precondiciones: circunstancia que debe ser verificada por el sistema antes de que se inicie el caso de uso. No se comprobará posteriormente durante el transcurso del caso de uso. En la mayoría de las ocasiones una precondición implicará que otro caso de uso ha tenido lugar anteriormente. 70

82 Casos de uso del Director de Proyecto Consultar proyectos asociados Actor Primario: Director De Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a 1. Descripción de Datos: Información del director de proyecto: La información del director de proyecto se compone de los datos personales del director de proyecto (NIF, nombre, nombre de usuario, y teléfono) así como de los proyectos existentes a su cargo. 71

83 Dar de alta un proyecto Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto. 3. El director introduce los datos generales del proyecto. 4. El sistema muestra una lista con los tipos de metodologías de desarrollo de software. 5. El director de proyecto selecciona una metodología para crear automáticamente las fases principales y añade la información complementaria al proyecto. 6. El sistema comprueba que el proyecto no está registrado y le da de alta. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a 1. 6a. El proyecto ya está registrado. 1. Finaliza el caso de uso. 1-5a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 72

84 3a. Los datos generales del proyecto no son correctos. 1. El sistema informa del error y se vuelve a 1. Descripción de Datos: Datos generales del proyecto: Los datos generales del proyecto son el nombre del cliente, los objetivos del proyecto, una descripción del mismo, la fecha de inicio y final prevista y el importe de venta. Tipos de metodologías de desarrollo de software: La información de cada proyecto dependerá del tipo de metodología usada para su desarrollo. Existen distintos tipos de metodologías, cada una de ellas con una serie de fases asociadas (las fases propias de la gestión de proyectos son comunes a todas las metodologías): Lineal: Identificación de necesidades, análisis de requisitos, diseño de arquitectura técnica, diseño externo, diseño interno, programación, pruebas del sistema, implantación y mantenimiento. Modelo en V: Análisis de requisitos del sistema, análisis de requisitos software, diseño preliminar, diseño detallado, codificación, pruebas 73

85 unitarias, pruebas de componentes, integración software, pruebas del sistema e integración del sistema. Incremental: Análisis de requisitos del sistema, análisis de requisitos del software, diseño e implementación. Prototipado: Recolección y refinamiento de requisitos, diseño rápido, construcción del prototipo, evaluación del prototipo por el cliente, refinamiento del prototipo y producto de ingeniería. Síntesis Automatizada: Obtención de necesidades informales, captura de la especificación, especificación inicial, refinamiento de la especificación, uso de catálogo de especificaciones, especificación refinada, síntesis automática, uso de catálogo de componentes, obtención de código. Espiral: Análisis de requisitos y planificación del proyecto, Análisis de riesgo basado en los requisitos iniciales, prototipo inicial del software, simulación de prototipo inicial, concepto de operación, plan de requisitos y plan de ciclo de vida, evaluación del cliente, análisis de riesgos basado en la reacción del cliente, prototipo de siguiente nivel, simulación del prototipo de siguiente nivel, requisitos de software, validación de los requisitos, plan de desarrollo, evaluación del cliente, análisis de riesgos, prototipo de siguiente nivel, simulación del prototipo, diseño del producto software, verificación y validación del diseño, plan de integración y 74

86 pruebas, análisis de riesgos, prototipo operativo, simulación del prototipo operativo, diseño detallado, codificación, pruebas unitarias, integración, pruebas de aceptación e implantación. RAD (Rapid Application Development): Investigación de la situación actual, definición de requisitos, aprobación de requisitos, modelo detallado del área del sistema, diseño inicial del sistema, refinamiento del diseño del sistema, preparación de la estrategia de implantación, aprobación del diseño del sistema, preparación, construcción del sistema, generación de datos de prueba y documentos del sistema, preparación de la transición, verificación de la construcción del sistema, entrenamiento de la conducta del usuario, conversión de datos, instalación del sistema en producción y aceptación de la instalación. Orientada a Objetos: Identificación de casos de uso, construcción del modelo de dominio, descripción detallada de los casos de uso, diseño de la interfaz de usuario, diseño de la arquitectura lógica, modelo dinámico detallado, modelo estructural detallado, diseño de la base de datos, creación del entorno de desarrollo, implementación y pruebas unitarias y pruebas de usuario. 75

87 Información complementaria al proyecto: La información complementaria de un proyecto consiste en sus riesgos iniciales, la documentación asociada al mismo, así como los recursos iniciales (tanto humanos como materiales) necesarios para su realización y el porcentaje de dedicación de cada recurso humano. 76

88 Crear una oferta de proyecto Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto. 3. El director introduce los datos generales de la oferta de proyecto. 4. El sistema muestra una lista con los tipos de metodologías de desarrollo de software. 5. El director de proyecto selecciona una metodología para crear automáticamente las fases principales y añade la información complementaria a la oferta de proyecto. 6. El sistema comprueba que el proyecto no está registrado y le da de alta. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a 1. 6a. El proyecto ya está registrado. 1. Finaliza el caso de uso. 1-5a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 77

89 3a. Los datos generales del proyecto no son correctos. 1. El sistema informa del error y se vuelve a 1. Descripción de Datos: Datos generales de la oferta de proyecto: Los datos generales de la oferta de proyecto son el nombre del cliente, los objetivos del futuro proyecto, una descripción del mismo, la fecha de inicio y final prevista y el importe previsto de venta. Información complementaria de la oferta de proyecto: La información complementaria de una oferta de proyecto consiste en sus riesgos iniciales, la documentación asociada a la misma, así como los recursos iniciales (tanto humanos como materiales) necesarios para su realización y el porcentaje de dedicación de cada recurso humano. 78

90 Consultar detalles de un proyecto asociado Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: Existe al menos un proyecto asociado al director de proyecto. Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director selecciona uno de sus proyectos. 4. El sistema muestra los detalles del proyecto seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a 1. 79

91 Descripción de Datos: Detalles del proyecto: Los detalles de un proyecto muestran información sobre su identificador, su nombre, el cliente, el director del proyecto, el coste previsto hasta la fecha, el coste real hasta la fecha, la metodología a usar, sus objetivos, su descripción, la fecha de inicio prevista, la fecha de finalización prevista, la fecha de inicio real y la fecha de finalización real. 80

92 Consultar entregables de un proyecto Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director selecciona uno de sus proyectos. 4. El sistema muestra una lista con los entregables del proyecto. 5. El director de proyecto selecciona uno de los entregables. 6. El sistema muestra la información del entregable seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El director no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 5a. No existe ningún entregable disponible. 1. El sistema informa de la situación y finaliza el caso de uso. 81

93 Descripción de Datos: Entregables del proyecto: Cada proyecto posee una serie de entregables asociados a las distintas fases de su ciclo de vida que podrán ser consultados. Cada ciclo de vida posee unas características propias que hacen que sus entregables difieran de los existentes en el resto de ciclos de vida. Información del entregable: La información del entregable consiste en la fase y el proyecto al que está asociado, el responsable del entregable, una descripción del mismo, así como la posibilidad de abrir el documento. 82

94 Consultar recursos humanos de un proyecto Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director selecciona uno de sus proyectos. 4. El sistema muestra una lista de los recursos humanos del proyecto. 5. El director de proyecto selecciona uno de los recursos humanos. 6. El sistema muestra información del recurso humano seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El director no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 4a. No existe ningún recurso humano asociado al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 83

95 Descripción de Datos: Información del recurso humano: La información del recurso humano consiste en sus datos personales (nombre, apellidos, NIF, cargo, teléfono y ), su tasa estándar, su tasa de horas extra y el porcentaje de dedicación al proyecto. 84

96 Consultar recursos materiales de un proyecto Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director selecciona uno de sus proyectos. 4. El sistema muestra una lista de los recursos materiales del proyecto. 5. El director de proyecto selecciona uno de los recursos materiales. 6. El sistema muestra información del recurso material seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El director no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 4a. No existe ningún recurso material asociado al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 85

97 Descripción de Datos: Información del recurso material: La información del recurso material consiste en su nombre, una descripción del mismo y su coste hora si éste es aplicable. 86

98 Consultar documentación asociada a un proyecto Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director selecciona uno de sus proyectos. 4. El sistema muestra una lista con los documentos asociados al proyecto. 5. El director de proyecto selecciona uno de los documentos. 6. El sistema abre el documento seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El director no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 4a. No existe documentación asociada al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 87

99 Descripción de Datos: Documentos asociados al proyecto: En numerosas ocasiones, un proyecto lleva asociada una serie de documentos externos a él, pero necesarios para el buen desarrollo del mismo. 88

100 Modificar un proyecto Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director selecciona uno de sus proyectos. 4. El sistema muestra los detalles del proyecto. 5. El director de proyecto modifica los datos. 6. El sistema actualiza el proyecto. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El director no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 89

101 Eliminar un proyecto Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director selecciona uno de sus proyectos. 4. El sistema pide confirmación al director. 5. El director confirma la operación. 6. El sistema elimina el proyecto. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 90

102 Pasar proyectos a PDA Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: - Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director introduce la ruta donde quiere guardar el fichero. 4. El sistema crea el fichero e informa al director. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 91

103 Crear fichero MsProject Actor Primario: Director de Proyecto Actores Secundarios: - Trigger: Iniciado por el director de proyecto Precondiciones: El proyecto está dado de alta en el sistema. Escenario Primario: 1. El director de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del director de proyecto y los proyectos asociados actuales. 3. El director introduce la ruta donde desea guardar el fichero. 4. El sistema genera el fichero, lo añade como documentación asociada al proyecto e informa al director. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El director del proyecto cancela la operación. 1. Finaliza el caso de uso. 92

104 Casos de uso del Jefe de Proyecto Consultar proyectos asociados Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: - Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a 1. Descripción de Datos: Información del jefe de proyecto: La información del jefe de proyecto se compone de los datos personales del jefe de proyecto (NIF, nombre, nombre de usuario, y teléfono) así como de los proyectos existentes a su cargo. 93

105 Consultar detalles de un proyecto asociado Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: Existe al menos un proyecto asociado al jefe de proyecto. Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. 3. El jefe selecciona uno de sus proyectos. 4. El sistema muestra los detalles del proyecto seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a 1. 94

106 Descripción de Datos: Detalles del proyecto: Los detalles de un proyecto muestran información sobre su identificador, su nombre, el cliente, el director del proyecto, el coste previsto hasta la fecha, el coste real hasta la fecha, la metodología a usar, sus objetivos, su descripción, la fecha de inicio prevista, la fecha de finalización prevista, la fecha de inicio real y la fecha de finalización real. 95

107 Consultar entregables de un proyecto Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: - Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. 3. El jefe selecciona uno de sus proyectos. 4. El sistema muestra una lista con los entregables del proyecto. 5. El jefe de proyecto selecciona uno de los entregables. 6. El sistema muestra la información del entregable seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El jefe del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El jefe no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 5a. No existe ningún entregable disponible. 1. El sistema informa de la situación y finaliza el caso de uso. 96

108 Descripción de Datos: Entregables del proyecto: Cada proyecto posee una serie de entregables asociados a las distintas fases de su ciclo de vida que podrán ser consultados. Cada ciclo de vida posee unas características propias que hacen que sus entregables difieran de los existentes en el resto de ciclos de vida. Información del entregable: La información del entregable consiste en la fase y el proyecto al que está asociado, el responsable del entregable, una descripción del mismo, así como la posibilidad de abrir el documento. 97

109 Consultar recursos humanos de un proyecto Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: - Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. 3. El jefe selecciona uno de sus proyectos. 4. El sistema muestra una lista de los recursos humanos del proyecto. 5. El jefe de proyecto selecciona uno de los recursos humanos. 6. El sistema muestra información del recurso humano seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El jefe del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El jefe no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 4a. No existe ningún recurso humano asociado al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 98

110 Descripción de Datos: Información del recurso humano: La información del recurso humano consiste en sus datos personales (nombre, apellidos, NIF, cargo, teléfono y ), su tasa estándar, su tasa de horas extra y el porcentaje de dedicación al proyecto. 99

111 Consultar recursos materiales de un proyecto Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: - Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. 3. El jefe selecciona uno de sus proyectos. 4. El sistema muestra una lista de los recursos materiales del proyecto. 5. El jefe de proyecto selecciona uno de los recursos materiales. 6. El sistema muestra información del recurso material seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El jefe del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El jefe no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 4a. No existe ningún recurso material asociado al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 100

112 Descripción de Datos: Información del recurso material: La información del recurso material consiste en su nombre, una descripción del mismo y su coste hora si éste es aplicable. 101

113 Consultar documentación asociada a un proyecto Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: - Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. 3. El jefe selecciona uno de sus proyectos. 4. El sistema muestra una lista con los documentos asociados al proyecto. 5. El jefe de proyecto selecciona uno de los documentos. 6. El sistema abre el documento seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El jefe del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El jefe no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 102

114 4a. No existe documentación asociada al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. Descripción de Datos: Documentos asociados al proyecto: En numerosas ocasiones, un proyecto lleva asociada una serie de documentos externos a él, pero necesarios para el buen desarrollo del mismo. 103

115 Modificar un proyecto Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: - Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. 3. El jefe selecciona uno de sus proyectos. 4. El sistema muestra los detalles del proyecto. 5. El jefe de proyecto modifica los datos. 6. El sistema actualiza el proyecto. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El jefe del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El jefe no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 104

116 Asignar recursos a tareas Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: - Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. 3. El jefe selecciona uno de sus proyectos. 4. El sistema muestra las tareas y los recursos del proyecto. 5. El jefe de proyecto selecciona una tarea, un recurso y el porcentaje de dedicación del mismo a la tarea. 6. El sistema actualiza el proyecto. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El jefe del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El jefe no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 105

117 Cerrar fase de un proyecto Actor Primario: Jefe de Proyecto Actores Secundarios: - Trigger: Iniciado por el jefe de proyecto Precondiciones: - Escenario Primario: 1. El jefe de proyecto introduce su usuario y contraseña. 2. El sistema muestra información del jefe de proyecto y los proyectos asociados actuales. 3. El jefe selecciona uno de sus proyectos. 4. El sistema muestra las fases del proyecto. 5. El jefe de proyecto selecciona una fase e introduce el coste real de la misma. 6. El sistema actualiza el proyecto. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El jefe del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El jefe no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 106

118 Casos de uso del Analista y Programador Consultar proyectos asociados Actor Primario: Analista o Programador del Proyecto Actores Secundarios: - Trigger: Iniciado por el analista del proyecto Precondiciones: - Escenario Primario: 1. El analista del proyecto introduce su usuario y contraseña. 2. El sistema muestra información del analista del proyecto y los proyectos asociados actuales. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a 1. Descripción de Datos: Información del analista del proyecto: La información del analista del proyecto se compone de los datos personales del analista del proyecto (NIF, nombre, nombre de usuario, y teléfono) así como de los proyectos existentes a su cargo. 107

119 Consultar detalles de un proyecto asociado Actor Primario: Analista o Programador del Proyecto Actores Secundarios: - Trigger: Iniciado por el analista del proyecto Precondiciones: Existe al menos un proyecto asociado al analista del proyecto. Escenario Primario: 1. El analista del proyecto introduce su usuario y contraseña. 2. El sistema muestra información del analista del proyecto y los proyectos asociados actuales. 3. El analista selecciona uno de sus proyectos. 4. El sistema muestra los detalles del proyecto seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a

120 Descripción de Datos: Detalles del proyecto: Los detalles de un proyecto muestran información sobre su identificador, su nombre, el cliente, el director del proyecto, el coste previsto hasta la fecha, el coste real hasta la fecha, la metodología a usar, sus objetivos, su descripción, la fecha de inicio prevista, la fecha de finalización prevista, la fecha de inicio real y la fecha de finalización real. 109

121 Consultar entregables de un proyecto Actor Primario: Analista o Programador del Proyecto Actores Secundarios: - Trigger: Iniciado por el analista del proyecto Precondiciones: - Escenario Primario: 1. El analista del proyecto introduce su usuario y contraseña. 2. El sistema muestra información del analista del proyecto y los proyectos asociados actuales. 3. El analista selecciona uno de sus proyectos. 4. El sistema muestra una lista con los entregables del proyecto. 5. El analista del proyecto selecciona uno de los entregables. 6. El sistema muestra la información del entregable seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El analista del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El analista no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 5a. No existe ningún entregable disponible. 1. El sistema informa de la situación y finaliza el caso de uso. 110

122 Descripción de Datos: Entregables del proyecto: Cada proyecto posee una serie de entregables asociados a las distintas fases de su ciclo de vida que podrán ser consultados. Cada ciclo de vida posee unas características propias que hacen que sus entregables difieran de los existentes en el resto de ciclos de vida. Información del entregable: La información del entregable consiste en la fase y el proyecto al que está asociado, el responsable del entregable, una descripción del mismo, así como la posibilidad de abrir el documento. 111

123 Consultar recursos materiales de un proyecto Actor Primario: Analista o Programador del Proyecto Actores Secundarios: - Trigger: Iniciado por el analista del proyecto Precondiciones: - Escenario Primario: 1. El analista del proyecto introduce su usuario y contraseña. 2. El sistema muestra información del analista del proyecto y los proyectos asociados actuales. 3. El analista selecciona uno de sus proyectos. 4. El sistema muestra una lista de los recursos materiales del proyecto. 5. El analista del proyecto selecciona uno de los recursos materiales. 6. El sistema muestra información del recurso material seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El analista del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El analista no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 4a. No existe ningún recurso material asociado al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 112

124 Descripción de Datos: Información del recurso material: La información del recurso material consiste en su nombre, una descripción del mismo y su coste hora si éste es aplicable. 113

125 Consultar documentación asociada a un proyecto Actor Primario: Analista o Programador del Proyecto Actores Secundarios: - Trigger: Iniciado por el analista del proyecto Precondiciones: - Escenario Primario: 1. El analista del proyecto introduce su usuario y contraseña. 2. El sistema muestra información del analista del proyecto y los proyectos asociados actuales. 3. El analista selecciona uno de sus proyectos. 4. El sistema muestra una lista con los documentos asociados al proyecto. 5. El analista del proyecto selecciona uno de los documentos. 6. El sistema abre el documento seleccionado. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El analista del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El analista no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 114

126 4a. No existe documentación asociada al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. Descripción de Datos: Documentos asociados al proyecto: En numerosas ocasiones, un proyecto lleva asociada una serie de documentos externos a él, pero necesarios para el buen desarrollo del mismo. 115

127 Asociar entregable a una fase Actor Primario: Analista o Programador del Proyecto Actores Secundarios: - Trigger: Iniciado por el analista del proyecto Precondiciones: - Escenario Primario: 1. El analista del proyecto introduce su usuario y contraseña. 2. El sistema muestra información del analista del proyecto y los proyectos asociados actuales. 3. El analista selecciona uno de sus proyectos. 4. El sistema muestra una lista con las fases del proyecto 5. El analista selecciona la ruta del entregable. 6. El sistema asocia el entregable a la fase y actualiza el proyecto. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El analista del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El analista no está asociado a ningún proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. 116

128 Asociar documentación a un proyecto Actor Primario: Analista o Programador del Proyecto Actores Secundarios: - Trigger: Iniciado por el analista del proyecto Precondiciones: - Escenario Primario: 1. El analista del proyecto introduce su usuario y contraseña. 2. El sistema muestra información del analista del proyecto y los proyectos asociados actuales. 3. El analista selecciona uno de sus proyectos. 4. El sistema muestra una lista con los documentos asociados al proyecto. 5. El analista del proyecto introduce la ruta donde se encuentra el documento a asociar. 6. El sistema asocia la documentación y actualiza el proyecto. Extensiones: 1a. El usuario no existe. 1. El sistema informa del error y se vuelve a a. El analista del proyecto cancela la operación. 1. Finaliza el caso de uso. 3a. El analista no está asociado a ningún proyecto. 1 El sistema informa de la situación y finaliza el caso de uso. 117

129 4a. No existe documentación asociada al proyecto. 1. El sistema informa de la situación y finaliza el caso de uso. Descripción de Datos: Documentos asociados al proyecto: En numerosas ocasiones, un proyecto lleva asociada una serie de documentos externos a él, pero necesarios para el buen desarrollo del mismo. 118

130 6.2 Diseño del Sistema Arquitectura Física Se ha realizado el desarrollo de la aplicación sobre el lenguaje Visual C# de la plataforma Microsoft Visual Studio.NET Este entorno de programación permite el fácil diseño de aplicaciones para el sistema operativo Windows, permitiendo un sencillo diseño del interfaz de usuario gracias a la gran colección de controles visuales disponibles. Otra de las grandes ventajas es la facilidad para estructurar y reorganizar el código, proporcionando una gran cantidad de herramientas que permiten la incorporación de nuevos módulos al sistema, así como una gran reusabilidad de componentes. La versión usada para el desarrollo ha sido Visual C# 2005 Express Edition. Asimismo, es en estos momentos, y a la espera de la apertura del código interno de Microsoft Office, la mejor herramienta para poder interactuar con productos como Microsoft Project y Microsoft Excel. 119

131 Además, la aplicación permite la apertura de ficheros de distintos productos, que pueden contener información importante para la aplicación: Adobe Acrobat (.pdf). Microsoft Office (Word, Power Point, Excel, Access, Project). Microsoft Outlook (.eml). Archivos de texto (.txt). Archivos de Internet (.html,.htm). 120

132 6.2.2 Diagrama de la Arquitectura Un diagrama de la arquitectura es un diagrama de paquetes UML que refleja los subsistemas (paquetes) en que se divide el sistema y las relaciones y dependencias que se dan entre ellos. En un modelo UML, cada clase pertenece a un único paquete. A su vez, un paquete puede pertenecer a otro paquete, pudiéndose crear una estructura jerárquica donde los paquetes del nivel más alto se dividen en subpaquetes que podrán también tener sus propios subpaquetes. Un diagrama de paquetes muestra los paquetes del sistema y las dependencias entre éstos. Las dependencias entre distintos paquetes tratan de representar las dependencias entre sus contenidos. Así, si una clase del paquete A tiene una dependencia con una clase del paquete B, los paquetes a las que ambas pertenecen también la poseerán. En proyectos de tamaño considerable, es muy recomendable poseer una estructura clara de paquetes, así como una visión global de las dependencias entre ellos. Este diagrama puede ser usado como una herramienta que nos ayude a mantener una visión y un control de alto nivel del sistema en su totalidad. Los paquetes pueden poseer un estereotipo que indica el tipo de paquete que es. Lo normal es que los paquetes sean partes del sistema, y por lo tanto llevarán el estereotipo <<subsystem>> encima del nombre del paquete. 121

133 Descripción de los subsistemas El sistema se divide en cinco paquetes, siendo cada uno de ellos un subsistema de la aplicación total: paquete Dominio, paquete IU paquete Servicios, paquete Dao y paquete WindowsApplication. El paquete WindowsApplication representa los controles gráficos, el paquete IU es la capa de interacción entre el interfaz y el resto del sistema, el paquete Servicios corresponde al nivel de negocio y el paquete Dao al nivel de integración. Se observa una relación secuencial entre los paquetes. Esto es debido a que normalmente el usuario únicamente interrelacionará con el primer paquete: WindowsApplication, que enviará la petición al paquete IU para poder tratar la orden del usuario. Hasta ese punto el sistema conocerá qué desea el usuario hacer, pero para poder saber cómo hacerlo, interactúa con el paquete Servicios, que posee la lógica del negocio de la aplicación. Es posible que la petición del usuario provoque un acceso a un repositorio de datos permanente. Para este acceso se hace uso del paquete Dao, que será el único que tenga acceso a los datos. El paquete Dominio, por su parte, representa los objetos y entidades que hay en el sistema. Cualquier paquete tiene acceso a él para poder realizar sus funciones correctamente. 122

134 6.3 Diseño Detallado Modelo Dinámico Detallado El lenguaje de modelado UML proporciona los llamados diagramas de interacción para poder describir cómo un conjunto de objetos colabora de un modo determinado. Existen diversos diagramas dentro de esta categoría, siendo el más utilizado el diagrama de secuencia. El propósito principal de este tipo de diagramas es mostrar la interacción entre objetos en el orden temporal en el que esas interacciones tienen lugar. Normalmente cada diagrama de secuencia representa el comportamiento del escenario principal de un caso de uso. El diagrama muestra una serie de objetos y mensajes que son transmitidos entre estos objetos dentro del caso de uso. Cada uno de los participantes del diagrama posee una línea de vida que está representada de forma vertical en el diagrama. Esta línea de vida representa el paso del tiempo, comenzando en la parte superior y transcurriendo hacia abajo. El eje principal representa los diferentes objetos, no teniendo importancia el orden de éstos. Toda línea de vida posee una barra de activación que muestra cuándo el objeto está activo en la interacción o está bloqueado esperando el retorno de una subrutina. 123

135 Los objetos del diagrama intercambian mensajes entre sí. Estos mensajes pueden ser de varios tipos: Invocación de una operación. Envío de una señal. Creación de un objeto. Destrucción de un objeto. Retorno de un valor. Objetos participantes Tiempo Invocación de operación Mensaje de creación Barra de activación Retorno de valor Línea de vida Para mejor comprensión de los diagramas de secuencia, éstos se acompañan de una captura de la pantalla desde la cual pueden ser invocados. 124

136 Diagramas de Secuencia consultarproyectosasociados [1] [2] [3] [4] [5] [9] [8] [6] [7] 125

137 Consultar Detalles Proyecto [1] Modificar Proyecto Seleccionado [2] 126

138 Eliminar Proyecto Seleccionado [3] Consultar Entregables Proyecto [4] 127

139 Consultar Recursos Humanos Proyecto [5] Consultar Recursos Materiales Proyecto [6] 128

140 Consultar Documentación Proyecto [7] Actualizar Lista de Proyectos [8] 129

141 Pasar a PDA [9] 130

142 daraltaproyecto verinformacioncomplementaria crearmsproject crearoferta Ver Información Complementaria 131

143 Dar de Alta Proyecto 132

144 Crear MsProject 133

145 Crear Oferta 134

146 verinformacioncomplementaria [3] [2] [1] [9] [8] [7] [6] [5] [4] forward forward Añadir Riesgo [1] 135

147 Eliminar Riesgo [2] Modificar Riesgo [3] 136

148 Añadir Documentación [4] Eliminar Documentación [5] 137

149 Añadir Recursos Materiales [6] Eliminar Recursos Materiales [7] 138

150 Añadir Recursos Humanos [8] Eliminar Recursos Humanos [9] 139

151 buscarcliente actualizarproyecto verinformacioncomplementaria forward Buscar Cliente 140

152 Actualizar Proyecto 141

153 abrirdocumentacion Abrir Documentación 142

154 forward añadirparticipacion Añadir Participación 143

155 forward añadiruso Añadir Uso 144

156 modificarproyecto asignarrecursos cerrarfase Modificar Proyecto 145

157 Asignar Recursos 146

158 Cerrar Fase 147

159 asignarrecurso forward actualizarrecursos Asignar Recurso 148

160 Actualizar Recursos 149

161 buscarentregable actualizarcoste forward confirmarcierrefase Actualizar Coste 150

162 Buscar Entregable 151

163 Confirmar Cierre Fase 152

164 forward asociarentregable Asociar Entregable 153

165 6.3.2 Modelo Estructural Detallado Este modelo muestra los detalles de cada uno de los paquetes anteriormente mostrados. Para cada paquete se detallan las diferentes clases que contiene y su visibilidad, representando a su vez las relaciones entre ellas. Asimismo, se especifica para cada clase el conjunto de sus métodos. Para cada método, además del nombre, se relacionan los atributos necesarios para su ejecución, así como el tipo de los mismos. Otra propiedad que se muestra es el tipo de retorno de cada método. 154

166 Paquete Dao 155

167 Paquete Servicios 156

168 157 Desarrollo de Modelos

169 Paquete IU 158

170 159 Desarrollo de Modelos

171 Paquete WindowsApplication 160

172 161 Desarrollo de Modelos

173 Paquete Dominio 162

174 163 Desarrollo de Modelos

175 6.3.3 Diseño de la base de datos La aplicación cuenta con una base de datos donde se almacena información necesaria para el correcto funcionamiento del sistema. El entorno de desarrollo de la base de datos es Microsoft Access 2002 con el Service Pack 3. De todos modos, el formato de acceso por defecto es el de Microsoft Access 2000, permitiendo así la compatibilidad del acceso a datos desde la versión del año 2000 hacia delante. La conexión a la base de datos, desde la aplicación, se realiza mediante la tecnología ADO.NET. ADO.NET supone la evolución de ADO (ActiveX Data Object), estándar creado en Windows para facilitar el acceso y la gestión de datos utilizando diferentes fuentes. ADO.NET proporciona una arquitectura de datos desconectada, esto es, se realiza una conexión y los datos son almacenados en la caché local. Sólo existen conexiones para acceder a los datos y modificarlos, mientras que todo el manejo de los mismos se hace en local. Esta tecnología de acceso a datos se basa fundamentalmente en la clase DataSet. Esta clase permite el acceso a datos de múltiples maneras, usando una gran variedad de objetos que conseguirán llevar los datos desde el gestor hasta la aplicación y viceversa. La siguiente figura muestra el esquema de la aplicación para el acceso a datos: 164

176 Aplicación DataAdapter Base de Datos DBCommand DBConnection Fill Update DataSet Manejo de datos La base de datos a la que se accede a través de esta tecnología está estructurada en una serie de tablas, que se detallan a continuación: Proyecto: contiene la información relativa a los proyectos de la organización. Riesgo: almacena los datos necesarios de los riesgos de cada proyecto. Metodología: posee la información de las diferentes metodologías que puede tener un proyecto. Fase: indica cada una de las fases de las diferentes metodologías. Entregable: contiene la información de los entregables de las diferentes fases de un proyecto. Cliente: almacena los datos de los clientes de la organización. 165

177 Documentación asociada: posee la información necesaria para gestionar los documentos asociados a un proyecto. Recursos Humanos: contiene la información de las personas de la organización que pueden formar parte de un proyecto. Participación: une a una persona con un proyecto determinado. Recursos Materiales: almacena los datos de los recursos materiales de la organización que pueden ser usados en un proyecto. Uso: une a un recurso material con un proyecto. Las diferentes tablas están relacionadas para mantener la integridad referencial entre las mismas. De este modo, la clave primaria de una tabla será clave extranjera en otra u otras, siendo clave primaria una o más columnas que no permiten valores nulos. La tabla Documentación Asociada posee una relación con la tabla Proyecto a través del campo proyecto. Cada documento debe tener un proyecto asociado, coincidiendo el valor con el valor del campo Identificador de la tabla donde se almacenan los proyectos. Un proyecto dado puede tener muchos documentos asociados. Un proyecto siempre poseerá un campo cliente que está relacionado con la tabla Cliente. Un proyecto no tiene sentido sin un cliente para el que se desarrolle. El valor de la tabla Proyecto debe coincidir con el valor del campo CIF de la tabla de los clientes. 166

178 Si un proyecto posee riesgos, éstos se asocian al proyecto a través del campo proyecto de la tabla Riesgo, que debe coincidir con el Identificador de la tabla Proyecto. Evidentemente, un proyecto puede no tener riesgos, o tener muchos de ellos. Un proyecto también puede tener muchos valores de la tabla Uso asociados. Esta tabla posee un campo para el identificador del proyecto, identificador_proyecto, que deberá ser igual que el campo Identificador del proyecto con el que está asociado. La tabla Uso, además, posee un campo denominado identificador_recurso, que debe coincidir con el valor del campo identificador de la tabla de los recursos materiales, y que hace que estas dos tablas posean una relación entre ellas. Un recurso material, como es lógico puede formar parte de diferentes registros de la tabla Uso, pero un registro determinado de esa tabla sólo podrá estar asociado a un recurso material. Algo similar ocurre con las tablas Participación, Recursos Humanos y Proyecto. Un proyecto puede tener muchas participaciones, relacionados por el campo proyecto de la tabla Participación. A su vez, esta tabla contiene una columna para el usuario, cuyo valor debe coincidir con el campo denominado del mismo modo en la tabla de los recursos humanos. Siempre existirá una metodología asociada a un proyecto. Esta metodología está representada en la tabla Proyecto a través del campo Metodología, que 167

179 debe coincidir con el campo Identificador de la tabla Metodología. Un proyecto sólo posee una metodología, mientras que una metodología puede estar presente en muchos proyectos. Una metodología, a su vez, posee una serie de fases. Cada registro de la tabla Fase posee una columna denominada Metodología que la asocia con la metodología a la que pertenece. Una fase sólo es de una metodología, mientras que una metodología puede contener muchas fases. Además, las fases pueden tener entregables asociados. El campo Fase de la tabla Entregable debe coincidir con el identificador de la tabla que contiene las diferentes fases. Un entregable, a su vez, puede poseer un responsable. Este responsable está representado por un registro de la tabla Participación. Así los campos Responsable y Proyecto de un determinado registro de la tabla Entregable deben tener asociados un registro de la tabla Participación que posea los mismos valores en las columnas de Usuario y Proyecto respectivamente. La siguiente figura muestra de forma gráfica las relaciones descritas dentro de la base de datos. 168

180 169 Desarrollo de Modelos

181 A continuación se muestra una descripción de cada una de las tablas mencionadas: Tabla Proyecto: Columna Tipo Necesario Significado Identificador VARCHAR (50) SI Identificador del proyecto Nombre VARCHAR (200) SI Nombre del proyecto Director VARCHAR (50) SI Director del proyecto Cliente VARCHAR (9) SI CIF del cliente Objetivos VARCHAR (255) NO Objetivos del proyecto Descripcion VARCHAR (255) NO Descripción del proyecto Fecha_inicio_prevista DATE NO Fecha de inicio prevista para el proyecto Fecha_fin_prevista DATE NO Fecha de finalización prevista para el proyecto Fecha_inicio_real DATE NO Fecha real de inicio del proyecto Fecha_fin_real DATE NO Fecha real de finalización del proyecto Coste_previsto_actual VARCHAR (50) NO Coste previsto del proyecto hasta la última fase finalizada Coste_real_actual VARCHAR (50) NO Coste real del proyecto hasta la última fase finalizada Metodologia INTEGER SI Metodología del proyecto Importe_venta VARCHAR (50) NO Importe de venta del proyecto Coste_previsto_total VARCHAR (50) NO Coste previsto de la totalidad del proyecto 170

182 Tabla Documentación_Asociada: Columna Tipo Necesario Significado Identificador VARCHAR (50) SI Identificador del documento Nombre VARCHAR (255) SI Nombre del documento Ruta VARCHAR (255) SI Ruta del documento Tipo VARCHAR (50) SI Tipo de fichero en el que se encuentra el documento Proyecto VARCHAR (50) SI Identificador del proyecto al que está asociado el documento Tabla Cliente: Columna Tipo Necesario Significado Nombre VARCHAR (50) SI Nombre de la empresa CIF VARCHAR (9) SI CIF de la empresa Calle VARCHAR (50) No Calle del domicilio social Numero VARCHAR (50) NO Número de la calle del domicilio social Poblacion VARCHAR (50) NO Población del domicilio social Codigo Postal INTEGER NO Código postal de la población del domicilio social Provincia VARCHAR (50) NO Provincia del domicilio social Pais VARCHAR (50) NO País del domicilio social 171

183 Tabla Recursos Materiales: Columna Tipo Necesario Significado Identificador VARCHAR (50) SI Identificador del recurso material Nombre VARCHAR (50) SI Nombre del recurso material Descripcion VARCHAR (255) No Descripción del recurso material Coste_hora LONG INTEGER NO Coste hora del recurso material Tabla uso: Columna Tipo Necesario Significado Identificador_proyecto VARCHAR (50) SI Identificador del proyecto asociado Identificador_recurso VARCHAR (50) SI Identificador del recurso material asociado 172

184 Tabla Recursos Humanos: Columna Tipo Necesario Significado Usuario VARCHAR (50) SI Identificador del recurso humano Password VARCHAR (50) SI Contraseña de acceso al sistema Cargo VARCHAR (50) SI Cargo del usuario dentro de la compañía Nombre VARCHAR (50) SI Nombre de la persona Apellidos VARCHAR (50) SI Apellidos de la persona VARCHAR (50) SI Correo electrónico de la persona Telefono INTEGER NO Número de teléfono de la persona Tasa_estandar INTEGER SI Tasa estándar por hora de la persona Tas_horas_extra INTEGER SI Tasa de horas extra de la persona Calle VARCHAR (50) NO Calle del domicilio de la persona Numero VARCHAR (50) NO Número y piso del domicilio de la persona Poblacion VARCHAR (50) NO Población del domicilio de la persona Codigo_postal INTEGER NO Código postal de la población Provincia VARCHAR (50) NO Provincia del domicilio 173

185 Tabla Participación: Columna Tipo Necesari o Significado Proyecto VARCHAR (50) SI Identificador del proyecto asociado Usuario VARCHAR (50) SI Usuario asociado Porcentaje_dedicacion INTEGER SI Porcentaje de dedicación al proyecto Fecha_inicio DATE NO Fecha en que comienza la participación en el proyecto Fecha_fin DATE NO Fecha en que finaliza la participación en el proyecto Tabla Riesgo: Columna Tipo Necesari o Significado Identificador VARCHAR (50) SI Identificador del riesgo Proyecto VARCHAR (50) SI Identificador del proyecto asociado al riesgo Nombre VARCHAR (50) SI Nombre del riesgo Nivel_1 VARCHAR (50) SI Nivel 1 del riesgo Nivel_2 VARCHAR (50) SI Nivel 2 del riesgo Descripcion VARCHAR (255) NO Descripción del riesgo Probabilidad VARCHAR (50) NO Probabilidad de ocurrencia del riesgo Impacto VARCHAR (50) NO Impacto del riesgo sobre el alcance del proyecto Estado VARCHAR (50) NO Estado del riesgo 174

186 Tabla Metodología: Columna Tipo Necesario Significado Identificador VARCHAR (50) SI Identificador de la metodología Nombre VARCHAR (50) SI Nombre de la metodología Descripcion VARCHAR (255) NO Descripción de la metodología Tabla Fase: Columna Tipo Necesario Significado Identificador VARCHAR (50) SI Identificador de la fase Nombre VARCHAR (100) SI Nombre de la fase Descripcion VARCHAR (255) NO Descripción de la fase Metodologia VARCHAR (50) SI Identificador de la metodología a la que está asociada 175

187 Tabla Entregable: Columna Tipo Necesario Significado Identificador VARCHAR (50) SI Identificador del entregable Nombre VARCHAR (255) SI Nombre del entregable Ruta VARCHAR (255) SI Ruta donde se encuentra el archivo del entregable Tipo VARCHAR (50) SI Tipo de formato que posee el archivo Responsable VARCHAR (50) SI Identificador del usuario responsable Fase VARCHAR (50) SI Identificador de la fase a la que está asociado el entregable Proyecto VARCHAR (50) SI Identificador del proyecto al que está asociado el entregable Descripcion VARCHAR (255) NO Descripción del entregable 176

188 7. Manual de usuario El objetivo de este manual es mostrar las diferentes pantallas de la aplicación y su utilización, habiéndose descrito la funcionalidad y ergonomía del sistema a lo largo de todo este documento. La primera pantalla que se muestra es de autenticación del usuario. Se deberá introducir el usuario, la contraseña y el cargo que ocupa. Si alguno de los tres datos no es correcto, se muestra una pantalla de error. Si el usuario consigue validarse correctamente le aparecerá el menú principal que corresponda, dependiendo de su cargo dentro de la organización. 177

189 Director de Proyecto La siguiente pantalla muestra el menú principal para un director de proyecto: 178

190 El director tiene acceso a una serie de funcionalidades tanto a través de los enlaces como del menú superior, así como la posibilidad de navegar entre las pestañas. 179

191 Pasar a PDA Pulsando la imagen de la PDA la aplicación creará un archivo con los gráficos de todos los proyectos del usuario que muestra el importe de venta de cada proyecto, su coste previsto y su coste real. Posteriormente, se pedirá que se seleccione una carpeta donde guardar el archivo. Se debe elegir la carpeta donde se sincronicen los archivos desde el ordenador hacia la PDA. 180

192 Si se dispone del software adecuado en la PDA (Excel Mobile, PTab Spreadsheet, etc.) se pueden visualizar los gráficos de los proyectos. En el caso de que no se disponga de un programa en la PDA que permita ver los gráficos, se puede acceder a la información en formato texto. 181

193 Consultar detalles del proyecto Para consultar los detalles se puede hacer uso del menú superior, o bien del enlace de la pantalla principal. En la siguiente pantalla se muestran los detalles del proyecto seleccionado, con una ayuda visual para ver la relación entre el coste previsto y el coste real. Si se desea ver la información complementaria, se debe pulsar en el enlace. 182

194 Esta pantalla posee la información complementaria del proyecto: riesgos, recursos humanos, recursos materiales y documentación asociada. 183

195 Consultar entregables Desde el menú principal, tras seleccionar el proyecto adecuado, se hace uso del menú superior o bien del enlace para poder consultar los entregables. 1 2 Para ver el entregable, se selecciona en primer lugar la fase a la que está asociado. La aplicación mostrará la información asociada al entregable. Si se desea abrir el entregable, se pulsa sobre el icono que marca la segunda flecha. La aplicación abrirá el entregable; los formatos de archivos soportados son: 184

196 Adobe Acrobat (.pdf). Microsoft Office (Word, Power Point, Excel, Access, Project). Microsoft Outlook (.eml). Archivos de texto (.txt). Archivos de Internet (.html,.htm). 185

197 Consultar recursos humanos del proyecto Desde el menú principal se hace uso del menú superior o bien del enlace para poder consultar los recursos humanos asociados al proyecto seleccionado. En esta pantalla se muestran los datos personales, la tasa estándar y de horas extras y el porcentaje de dedicación. Puede usarse la lista desplegable para cambiar de persona. 186

198 Consultar recursos materiales del proyecto Desde el menú principal se puede hacer uso del menú superior o bien del enlace para poder consultar los recursos materiales asociados al proyecto seleccionado. En esta pantalla se pueden consultar el nombre, la descripción y el coste del recurso material. Se puede usar la lista desplegable para cambiar de recurso. 187

199 Consultar documentación asociada al proyecto Existen dos opciones para consultar la documentación asociada al proyecto seleccionado: se puede navegar desde el menú superior, o bien pulsar el enlace señalado. Se selecciona el documento a consultar en la lista y se pulsa el botón para abrir el archivo. Los 1 2 formatos soportados son los mismos que para los entregables. 188

200 Modificar proyecto Para modificar un proyecto seleccionado se debe pulsar en el enlace o bien hacer uso del menú superior. Se podrán modificar los datos del proyecto en esta pantalla. Si se desea cambiar el cliente pero no se conoce su CIF, se puede introducir el nombre y pulsar sobre el icono de búsqueda. También se puede acceder a la información complementaria. 189

201 En la pantalla de información complementaria se pueden gestionar los riesgos, los recursos humanos, los recursos materiales y la documentación asociada del proyecto. No se debe olvidar añadir la información al proyecto cuando se finalice. 190

202 Eliminar proyecto Para eliminar un proyecto, se debe seleccionar su nombre en la lista de proyectos y pulsar sobre el enlace correspondiente. También se puede hacer desde el menú superior. Antes de eliminar el proyecto, el sistema pedirá una confirmación de la acción. 191

203 Actualizar lista de proyectos Si se desea actualizar la lista tras dar de alta un proyecto, se pulsa el botón del menú principal y la lista de proyectos queda actualizada. 192

204 Dar de alta proyecto u oferta 3 2 En la pestaña correspondiente se puede introducir la información básica del proyecto. A continuación, se debe pulsar sobre el enlace para introducir la información complementaria. Después se podrá dar de alta el proyecto o bien crear la oferta. Se puede pulsar sobre el icono de 1 MsProject para crear un archivo asociado. En la pantalla de información complementaria se pueden gestionar los riesgos, los recursos humanos, los recursos materiales y la documentación asociada del proyecto. No debe olvidarse añadir la información al proyecto cuando se finalice. 193

205 Si al intentar dar de alta no se han rellenado correctamente los campos, el sistema informará del error. Cuando el proyecto sea dado de alta con éxito también se recibirá un mensaje de confirmación. Si se desea crear el archivo de MsProject, el sistema pedirá que se introduzcan una serie de factores para aplicar el modelo Cocomo II a la estimación del proyecto. Se pulsará aceptar una vez se hayan completado. Si no se han completado alguno de los factores, el sistema informará para que se haga. 194

206 Una vez se hayan completado todos los factores el sistema pedirá la ruta donde se desea guardar el archivo de Microsoft Project creado. Además, y de forma automática, el archivo será añadido como documentación asociada al proyecto. 195

207 Jefe de Proyecto El menú principal del jefe de proyecto tiene el siguiente aspecto: 196

208 El jefe de proyecto tiene acceso a una serie de funcionalidades tanto a través de los enlaces como del menú superior, así como la posibilidad de navegar entre las pestañas. Algunas de estas funcionalidades (consultar detalles del proyecto, consultar entregables del proyecto, consultar recursos humanos y recursos materiales del proyecto y consultar documentación asociada al proyecto) son las mismas que posee el director de proyecto. Se muestran aquí las funcionalidades que difieren, mientras que las que son comunes con el director de proyecto pueden ser consultadas en el apartado dedicado a éste. 197

209 Modificar proyecto Para modificar un proyecto seleccionado se debe pulsar en el enlace o bien hacer uso del menú superior. En esta pantalla al jefe de proyecto no se le permite cambiar ni el cliente ni el director. El resto de la funcionalidad es igual que para el director de proyecto. 198

210 Asignar recursos a tareas Se debe pulsar sobre el enlace para asignar recursos del proyecto a las diferentes tareas En primer lugar, se selecciona la tarea; posteriormente se elige el recurso a asignar y su porcentaje de dedicación. Se debe pulsar el botón marcado con el número cuatro y repetir la operación tantas veces como sea necesario. No se debe olvidar actualizar el proyecto al finalizar. 199

211 Cerrar fase del proyecto Se debe pulsar el enlace para poder dar por finalizada alguna de las fases del proyecto escogido En primer lugar, se escoge una de las fases del proyecto, y se introduce el coste real que ha tenido la fase. Se pulsa sobre el icono si se desea asociar un entregable a la fase. Se añade la información y se repite la operación con todas las fases que se deseen dar por cerradas. Se actualiza el proyecto al finalizar. 200

212 Si se desea asociar un entregable el sistema mostrará 2 1 esta pantalla. Se debe seleccionar el responsable y pulsar en el icono para indicar la ruta del archivo. En la ventana de diálogo, se debe seleccionar el entregable y pulsar en el botón de Abrir. El sistema permitirá introducir una descripción del entregable seleccionado. Posteriormente, se debe pulsar en el botón para asociar el entregable a la fase. 201

213 Analista y programador Ambos roles tienen las mismas funcionalidades. Estas son las pantallas: Todas las funcionalidades de esta pantalla se encuentran descritas en apartados anteriores: consultar detalles del proyecto, consultar entregables, consultar recursos materiales y consultar documentación asociada. En esta pestaña se puede asociar un entregable a una fase del proyecto y asociar la documentación asociada. Ambas funcionalidades son iguales a las descritas anteriormente para los otros roles de acceso. 202