Entregable 1 INGENIERÍA DEL SOFTWARE II Pablo Azaña Sánchez Alicia García Yébenes Javier Matas de Haro Roberto Pozuelo Domínguez José Carlos Rodríguez del Salado
EQUIPO FÍSICO El equipo físico de la empresa consta de todas las máquinas y dispositivos que son necesarios para llevar a cabo las tareas. Se compone de: 5 ordenadores personales 5 teléfonos móviles personales 1 impresora-escáner-copiadora-fax Características del equipo físico: Ordenador: Toshiba Satellite A660 Sistema Operativo: Windows Home Premium 64 bits Teléfono: Cada empleado cuenta con uno personal Impresora. Escáner. Copiadora: HP Deskjet F2200 All-in-One SISTEMAS DE GESTIÓN DE BASES DE DATOS En nuestra empresa se utilizará el sistema de gestión de las bases de datos Google Cloud SQL. Google dispone de una base de datos relacional en la nube que es muy similar a MySQL. Esta base de datos es Google Cloud SQL que permite manejar, mantener y administrar las bases de datos de los proyectos. Esta funcionalidad es bastante simple y se integra perfectamente con Google App Engine. Los datos se replican sincronizadamente en todos los dispositivos, ofrece una alta fiabilidad y disponibilidad. Además se pueden importar y exportar las bases de datos MySQL a la nube y utilizarlos con App Engine. Se utilizará JDBC para conectarnos desde nuestra aplicación. Google Cloud SQL está disponible en fase beta y de prueba, y de forma gratuita. SISTEMA DE COMUNICACIÓN El sistema de comunicación de la empresa se realizará a través de Google Groups, un servicio que ofrece Google y que soporta grupos de discusión sobre una gran variedad de temas. Es un servicio gratuito, aunque para ello hay que tener una cuenta de Gmail (servicio de mensajería de Google) y se puede participar en los grupos a través de la propia interfaz de Google Groups o mediante correo electrónico. Nuestra empresa tiene un grupo creado con este servicio. Es un grupo privado al que solo pueden acceder los 5 empleados de la empresa, y con el que además se comparten documentos, carpetas y archivos relacionados con los proyectos que se llevan a cabo. Se crean nuevos temas de discusión cada vez que alguno de los empleados quiere compartir alguna noticia o información relacionada con la empresa o los proyectos, y a través del correo electrónico se recibe la información nueva que se ha publicado en el grupo. 1
Con este sistema, los empleados están al día en cuestión de los temas relacionados con la empresa y los proyectos, y también es el medio de comunicación para establecer la fecha de las reuniones que se efectúan semanalmente. CLOUD COMPUTING Cloud Computing (o Computación en la nube) es un paradigma que permite ofrecer servicios de computación a través de Internet. Esto permite a los usuarios acceder a estos servicios sin conocimientos en la gestión de los recursos que usan. Algunos de los beneficios del Cloud Computing son: Integración sencilla y rápida con otras aplicaciones. Prestación de servicios a nivel mundial. Menor inversión inicial al ser el proveedor de contenidos el encargado de la instalación y mantenimiento hardware. Implementación más rápida y con menos riesgos. PROVEEDORES DE CLOUD COMPUTING - Amazon Elastic Compute Cloud Amazon Elastic Compute Cloud (Amazon EC2) es un servicio web que proporciona capacidad informática con tamaño modificable en la nube. Está diseñado para facilitar a los desarrolladores recursos informáticos escalables y basados en web. 2 Entre sus principales características encontramos: Aumento o reducción de la capacidad según las necesidades del usuario. Control total de las instancias. Tiene acceso de usuario raíz a todas ellas, y puede interactuar con ellas como con cualquier otra máquina. Tiene la opción de varios tipos de instancias, sistemas operativos y paquetes de software. Diseño pensado para la interacción con otros productos Amazon. - Google App Engine Google App Engine te permite ejecutar tus aplicaciones web en la infraestructura de Google. Sus características son: Admite aplicaciones escritas en varios lenguajes de programación (Java, Python). Controlas la cantidad máxima de recursos que consume tu aplicación. Puedes empezar a utilizar App Engine de forma totalmente gratuita. Otros proveedores importantes de Cloud Computing son IBM, Windows... Nuestra elección para el desarrollo de la práctica será Google App Engine. Esta decisión se debe principalmente a que nos permitirá empezar con ella de forma gratuita y a la posibilidad de trabajar con un lenguaje de programación como Java, que es el lenguaje escogido para el desarrollo de la práctica. Además, el grupo posee una ligera experiencia en la utilización de Google App Engine así como en los distintos servicios que Google ofrece. Como veremos mas adelante, estos servicios son
los que mas se van a utilizar, y por tanto, la parte de Cloud Computing podrá adaptarse mejor a la metodología de trabajo del grupo. EQUIPO LÓGICO Herramientas de implementación: Eclipse Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para el desarrollo software. Su funcionamiento se basa en módulos (plug-in) para proporcionar toda su funcionalidad. Asimismo, a través de "plugins" libremente disponibles es posible añadir control de versiones con Subversion e integración con Hibernate. Debido a todas estas características y a la experiencia de trabajo del grupo, utilizaremos la aplicación Eclipse para la implementación. La posibilidad de integrar plug-ins en la plataforma Eclipse ayudará durante el desarrollo de la práctica, como por ejemplo, uso de repositorios directamente desde el entorno de eclipse, utilización del lenguaje Java, y otras posibles necesidades futuras. Herramientas de gestión de proyectos Debido a la elección de Scrum como metodología ágil para el proyecto, hemos escogido la herramienta Pivotal Tracker para la gestión del mismo. Es una herramienta gratuita que se utilizará mediante navegador a través de Internet. Esto permitirá al equipo de trabajo una flexibilidad importante. Además, es capaz de guardar un histórico de nuestras acciones que podrá ser exportado e importado en formato CSV. Herramientas CASE Visual Paradigm es una herramienta UML profesional que soporta el ciclo de vida completo del desarrollo de software: análisis y diseño orientados a objetos, construcción, pruebas y despliegue. Permite dibujar todos los tipos de diagramas de clases, código inverso, generar código desde diagramas y generar documentación. Permite interoperabilidad con Eclipse. Repositorio Utilizaremos un repositorio para el control de versiones y obtener una mayor flexibilidad a la hora de trabajar sobre el proyecto. El repositorio que utilizaremos será el proporcionado por Google debido a la experiencia del grupo de trabajo en él y a la fácil integración con el entorno de desarrollo eclipse. Red interna de la empresa La empresa contará con una red local interna con acceso a Internet. A su vez, ésta se dividirá en dos subredes para aumentar la seguridad de acceso a determinados datos. En la figura 1 se puede ver el esquema de la red interna de nuestra empresa. 3
Figura 1 La empresa tendrá una red propia, 168.93.24.0/24, que mediante subnetting se dividirá en dos subredes, una subred para la directiva de la empresa, que tendrá acceso a un servidor de base de datos mysql en el que se guardará toda la información referente a la empresa (proyectos, empleados, contabilidad...). Además, contaremos con otra subred mayor preparada para los programadores de la empresa. Como ya hemos comentado, la empresa contará con otro servidor svn que sirva para el control y el buen funcionamiento del desarrollo software. Será el proporcionado por Google Code. METODOLOGÍAS ÁGILES DE DESARROLLO Para la realización de esta práctica nos hemos decantado por utilizar metodologías agiles de desarrollo software, en nuestro caso scrum. Scrum es un marco de trabajo que se basado en un proceso iterativo e incremental. Es un modelo de referencia en el que se definen distintos roles y prácticas. Los roles principales relativos al proceso de scrum son: Scrum master. No es el líder del grupo, sino que simplemente es el encargado de que se cumplan las reglas, y de que el equipo no se distraiga por ninguna influencia externa. Hace de escudo. Product owner. Es el encargado de hablar por el cliente. Se asegura de que el equipo trabaje correctamente desde el punto de vista de la empresa. Scrum team. Es el grupo de trabajo, los que tienen la responsabilidad de entregar el trabajo. Todos los roles definidos anteriormente se corresponden con un grupo denominado cerdos. También existe otro grupo denominado gallinas que aunque no son parte del proceso de scrum hay que tener en cuenta. Estos otros roles son los del usuario, los Stakeholders (clientes, proveedores, inversores) y los managers. 4
Figura 2 Como se ha planteado antes, se basa en un proceso iterativo e incremental. Esto se consigue mediante los denominados sprint. Durante cada sprint, el equipo crea un incremento de software potencialmente entregable, o lo que es lo mismo, utilizable. El software realizado en cada sprint se corresponde con una serie de requisitos, que se encuentran en el Product backlog. En el Product backlog se encuentran todos los requisitos de alto nivel, priorizados, que definen el trabajo a realizar. Los requisitos que van a formar parte de cada sprint se determinan en la reunión de sprint planning. En ella es el product owner el que especifica los requisitos que desea en dicho sprint, y el scrum team decide qué cantidad de trabajo se compromete a realizar. Una vez decididos los requisitos del sprint, estos no pueden cambiar durante el sprint, se encuentran congelados. Los sprint duran entre una y cuatro semanas. En nuestro caso serán de dos semanas. Además dentro de cada sprint hay daily scrums. Esto es, que cada día del sprint se harán reuniones entre los componentes del scrum team para conocer el estado del proyecto. Nosotros optaremos por hacer las reuniones cada dos días, por diferencias de horario. Figura 3 5
El scrum tiene unas guías específicas: La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (en nuestro caso llevar colgando una gallina de plástico del cuello). Todos son bienvenidos, pero sólo los "cerdos" pueden hablar. La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo. Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta). La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días. Gracias a este proceso de desarrollo (que se puede ver en las figuras 2 y 3), podemos involucrar antes al equipo de pruebas lo antes posible. De esta forma, se facilitará la posibilidad de detectar y solucionar a tiempo todos los posibles errores y se podrá analizar la usabilidad en cada momento para ir mejorándola continuamente. REQUISITOS DE OPERACIÓN Y SEGURIDAD Para el correcto funcionamiento de la empresa sobre la que se va a trabajar, es necesario definir los procedimientos de seguridad y operación necesarios para no comprometer el correcto funcionamiento del sistema. Para ello, en primer lugar, todo empleado de la empresa debe tener para sí mismo un usuario y una contraseña para poder acceder a los equipos informáticos de la empresa y que pueda tener sus datos guardados en un equipo. Para que no haya problemas, está prohibido que el usuario tenga en un post-it en su puesto de trabajo con sus datos privados para acceder al sistema, con el fin de que no haya problemas a la hora de que alguien acceda a su cuenta, de modo que a cada usuario, se le otorgará de una ficha con sus datos. Esta ficha será entregada a cada usuario una vez al mes, con el fin de que se produzca un cambio de usuario y contraseña para proteger la seguridad de los datos. Será necesario que todo miembro del equipo tenga una carga similar de trabajo a la de sus compañeros, con el fin de que no haya problemas en franjas horarias para realizar estos trabajos, y nadie se quede descolgado. Con este fin, uno de los miembros del equipo deberá actuar como coordinador. Este miembro deberá ir almacenando la información necesaria para cada una de las reuniones de modo que pueda coordinarlas y poder repartir el trabajo de acuerdo a lo que él crea conveniente. Cada miembro del equipo, cada día de trabajo, deberá realizar una copia de seguridad de todos los cambios que haya realizado en su mismo equipo, pero aparte de esto, el equipo deberá trabajar con un repositorio siguiendo distintas normas: En primer lugar, cada miembro del equipo antes de empezar a trabajar, deberá descargarse del repositorio todos los archivos que hayan sido subidos por otros miembros. Acto seguido, cada usuario deberá empezar a realizar su trabajo. Es completamente necesario que dos usuarios no estén realizando la misma tarea, debido a que disminuye la productividad de la empresa, también pueden haber conflictos a la hora de subir estos archivos al repositorio. 6
Cuando un usuario acabe un apartado de sus tareas a realizar, deberá subirla al repositorio. En este instante, deberá de nuevo descargarse todos los archivos que estén subidos por si hubiera conflictos. Si no se produjera ningún conflicto, el usuario deberá subir su archivo. Es necesario que el archivo funcione correctamente, porque si se produjera algún fallo en él, podría expandir el fallo al resto de sus compañeros y producirse un desavance importante a la hora de la realización de un determinado proyecto. Aparte de que haya una copia de seguridad diaria y conjunta para todos los miembros del equipo en el repositorio, es necesario que cada uno de los miembros se cree una copia de seguridad aparte en cada uno de sus puestos de trabajo o algún otro método de almacenamiento externo. Además, el coordinador del equipo deberá también tener una copia de seguridad de los avances del sistema. Es necesario que todas las herramientas informáticas que se vayan a utilizar estén en su última versión, para ello, cada miembro del equipo deberá estar al tanto de los últimos cambios en las versiones de los diferentes programas que estén utilizando. Si llegara a producirse una catástrofe y muchos de los últimos cambios se hayan perdido, uno de los miembros del equipo(a poder ser, el último que haya subido un archivo al repositorio, ya que pudiera ser que haya sido el culpable de tal catástrofe al subir un archivo dañado), deberá encargarse de borrar todos los archivos que no funcionen correctamente del repositorio y deberá coger una de las copias de seguridad de días anteriores y actualizar el repositorio con esa versión del proyecto. Si llegara el caso de que uno de los miembros de la empresa se diera de baja y hubiera que buscar un sustituto para ese día, para que no hubiera problemas a la hora de entender el código de la aplicación, en una de las primeras reuniones, se planificará, debatirá y redactará entre todos los miembros del grupo un manual de estilo de programación, es decir, que todos los miembros sigan las mismas pautas y reglas para que no haya problemas a la hora de entender correctamente el funcionamiento de la aplicación. Llegado el caso de que uno de los miembros fuera más avanzado que el resto y acabara su parte antes que el resto, este deberá mantener una reunión con el coordinador del equipo, y debido a los avances que tengan los otros miembros del trabajo, empezará a realizar el trabajo nuevo que le toque a él o ayudará a terminar a tiempo al miembro que pudiera ir más lentamente en su tarea, siempre y cuando se crea que no fuera capaz de llegar a la fecha de entrega de su parte del proyecto. ESTRUCTURA ORGANIZATIVA DE LA EMPRESA Para una mejor mecánica de trabajo en la realización del proyecto, dos de los miembros del trabajo se encargarán de la parte del análisis y el diseño de la práctica. Estos dos empleados deberán detallar correctamente todos los puntos a seguir para que todos los trabajadores puedan llevar una programación ordenada y no haya problemas en una posible incorporación de un usuario nuevo a la realización del proyecto, de modo que todo siga una misma pauta dentro de la empresa. Los otros tres miembros del grupo de trabajo se encargarán de desarrollar la implementación del mismo, con la única diferencia de que uno de ellos se encargará de coordinar el trabajo de todos. Este miembro realizará a diario un control sobre los avances de cada uno de los 7
programadores, y asignará trabajo nuevo a cada uno de ellos. Además, será encargado de que el trabajo asignado sea realizado en el tiempo asignado y nadie se exceda del tiempo de la entrega. Otro de estos programadores se encargará del control de seguridad de los datos, de modo que será aquel que lleve al día todo el tema de las copias de seguridad que se ha comentado anteriormente. El último de los programadores, a diario, echará un vistazo al análisis y el diseño que han realizado sus compañeros de proyecto y les comentará posibles incoherencias que hayan sido realizadas a la hora de realizarlo. Todos estos cargos se irán turnando entre todos los miembros del equipo, de modo que todos trabajen de todo y todos sepan de todo. ROLES EN EL DESARROLLO SOFTWARE El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse en grupo. Además, esta actividad requiere de distintas capacidades, las que no se encuentran todas en una sola persona. Por ello, se hace necesario formar el grupo de desarrollo con las personas que cubran todas las capacidades requeridas. Por ello, es que cada persona debe tener un rol dentro del grupo, que viene dado por su experiencia y capacidades personales. Administrador de proyecto Es la persona que administra y controla los recursos asignados a un proyecto, con el propósito de que se cumplan correctamente los planes definidos. Algunos de los objetivos de un administrador de proyecto son los siguientes: 1. Tener el producto a tiempo, bajo presupuesto y con los requisitos de calidad definidos. 2. Terminar el proyecto con los recursos asignados. 3. Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus integrantes a cumplir sus objetivos particulares. Al final, se cumplirá el objetivo general. 4. Cumplir con las expectativas del cliente. El administrador de proyecto debe relacionarse con todo el equipo de trabajo. Para ello, debe darle apoyo con lo siguiente: Una carta de organización de todo el proyecto, un plan de trabajo general, estimaciones de horas-hombre de cada actividad. Analista Análisis se refiere a la habilidad de poder estudiar un problema de una complejidad determinada, descomponiendo el problema en subproblemas de menor complejidad. De esa forma, la solución del problema completo se obtiene como la suma de las soluciones de los subproblemas de menor complejidad. Por tanto, el analista debe transformar los requisitos de usuario en requisitos de software, y producir el documento de requisitos de software. A continuación se menciona algunas de las actividades a realizar por los analistas, las que forman parte de su plan de trabajo: 1. Preparar un documento con preguntas a realizar al cliente durante las entrevistas. 8
2. Determinar las fechas de reunión con el cliente. 3. Generar un documento de especificación de requisitos de usuario en base a los acuerdos alcanzados en la primera reunión. 4. Estudiar la metodología de diseño. 5. Generar los diagramas de arquitectura y revisarlos con los diseñadores. 6. Construir el documento de requisitos de software. Diseñadores Es el encargado de generar el diseño del sistema. Entre sus funciones está: 1. Generar el diseño arquitectónico y diseño detallado del sistema, basándose en los requisitos. 2. Generar el documento de diseño arquitectónico de software (DDA), y mantenerlo actualizado durante el proyecto. 3. Velar porque el producto final se ajuste al diseño realizado (funciones de téster). El plan de trabajo de los diseñadores incluye las siguientes actividades para el diseño del sistema: 1.Organizar el sistema en subsistemas. 2. Asignar los subsistemas a procesos y tareas. 3. Identificar recursos globales y determinar mecanismos de acceso. Programadores Los programadores deben convertir la especificación del sistema en código fuente ejecutable utilizando uno o más lenguajes de programación, así como herramientas de software de apoyo a la programación. Uno de los principales objetivos de los programadores durante su trabajo debe ser la de reducir la complejidad del software. El plan de trabajo de los programadores debe contener, al menos, las siguientes actividades: 1. Explorar los diferentes ambientes de desarrollo. 2. Explorar los diferentes lenguajes disponibles para el ambiente y las diferentes herramientas de desarrollo. 3. Elegir el estilo de programación. 4. Codificar y depurar. 5. Escribir la documentación técnica. Téster El téster es el encargado de asegurar la calidad de cada uno de los productos (documentos, prototipos, etc). Entre sus tareas están: 1. Construir y aplicar los planes de prueba unitarios, de módulo, de sistema, y aceptación parcial, manteniéndolos actualizados durante el proyecto. 2. Velar por la completitud, y exactitud (no ambigüedades) de todos los documentos del proyecto. 3. Velar por la calidad del producto final (cumplimiento de los requisitos). El plan de trabajo del téster debe incluir, al menos, las siguientes actividades: 1. Participar en la revisión de los requisitos del sistema. 2. Construir un plan de testeo. 3. Ejecutar los tests de bajo, medio y alto nivel. 4. Construir la documentación del proceso de tests. 9
Para la realización de ésta práctica los roles irán rotundo entre los distintos miembros del grupo de modo que todos seamos todo. Se han de considerar los siguientes salarios: Administrador de proyecto: 100 euros/hora Analista; 90 euros/hora Diseñador: 60 euros/hora Programador 45 euros/hora Téster: 35 euros/hora PROCESO UNIFICADO DE DESARROLLO El Proceso Unificado de Desarrollo (PUD) se define como Conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software, más concretamente se define como Marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, de diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. Sus características principales son: Dirigida por casos de uso que sirven para representar conceptualmente un requisito funcional que se desea implementar en el sistema. Centrada en la arquitectura. Es iterativa. El desarrollo del producto software se divide en un conjunto de iteraciones que producen incrementos en la funcionalidad del sistema software que se está desarrollando. Es incremental. FASES DE UN DESARROLLO BASADO EN PUD La aplicación del PUD a un proyecto software implica la realización de un conjunto de ciclos que representan la vida del sistema a desarrollar. Consta de cuatro fases: Fase de inicio: consiste en dar una primera visión aproximada del producto a desarrollar. Durante esta fase se determinará la viabilidad del proyecto, se describirán brevemente los requisitos identificados en el producto que se pretende desarrollar. Implica: hacer un modelo de casos de uso en donde se describen los requisitos funcionales identificados; una descripción de posibles riesgos que puedan afectar al desarrollo; un plan de iteraciones que describa lo que se hará en la fase de elaboración. Como se detallará más adelante no se creará un plan prefijado de iteraciones sino la llamada Pila de Producto. Fase de elaboración: se compone de una o dos iteraciones en las que se procede a detallar los requisitos identificados en la fase de inicio. Se elige el núcleo de la arquitectura y se terminan de identificar la mayoría de los requisitos del sistema obteniendo un listado de requisitos funcionales detallados y más cercanos a los requisitos reales. Lo que se debe obtener en esta fase es una visión del sistema centrada en la arquitectura en la que se hayan establecido las capas software que se van a implementar junto con los paquetes y subsistemas que aparecerán en dicho producto. Implica: un modelo de casos de uso en donde se detallen con más detalle los casos de uso identificados en la fase de inicio y se incorporen nuevos 10
requisitos que no se tuvieron en cuenta; un modelo de diseño que estará compuesto por los diagramas de clases y diagramas de interacción; un modelo de datos que estará formado por el conjunto de esquemas que representan las estrategias de persistencia y un documento de la arquitectura que contiene las ideas principales del diseño de la arquitectura. Fase de Construcción: esta fase se corresponde con la codificación de los requisitos identificados. Esta fase contiene una cantidad de iteraciones muy variable y obtenemos como resultado final el código y los componentes software necesarios. Implica: un modelo de diseño en donde se termine de detallar el diseño de la aplicación; un modelo de implementación formado por un conjunto de diagramas de componentes en donde puedan agruparse las clases con funciones cooperativas; un modelo de pruebas que estará formado por un conjunto de diseños de casos de prueba; un modelo de despliegue que represente la forma en que se van a ejecutar los componentes representados en el modelo de componentes y un modelo de distribución en donde se muestre de forma abstracta el funcionamiento físico del sistema. Fase de transición: al final de esta fase deberá obtenerse el producto ejecutable con los manuales y demás elementos necesarios para su puesta en marcha. Implica: un modelo de implementación con los pequeños cambios que hayan tenido que hacerse en la implementación con relación a la fase anterior; un modelo de despliegue y un modelo de distribución. DISCIPLINAS QUE ATRAVIESAN LAS ITERACIONES Las fases anteriores se componen de una o más iteraciones y cada una de esas iteraciones atraviesan un conjunto de disciplinas. Las más importantes se reducen a: requisitos, análisis, diseño, implementación y pruebas. A continuación se procede a detallar cada una de ellas. Disciplina de requisitos Se realiza mayoritariamente en las fases de inicio y elaboración y se corresponde con la identificación de los requisitos funcionales del sistema. Disciplina de Análisis Se realiza mayoritariamente en la fase de elaboración y se corresponde con una especificación más detalla de los Casos de Uso definidos en la disciplina de requisitos. 11
Disciplina de Diseño Afecta principalmente a las fases de elaboración y construcción. Su propósito es modelas el sistema y su arquitectura para que soporte los requisitos tanto funcionales como no funcionales. Disciplina de implementación Afecta en su mayor parte a la fase de Construcción de tal modo que la mayoría de iteraciones de esta fase se centrarán en su mayor parte en esta disciplina. Disciplina de pruebas Afecta a todas las fases en las que durante sus iteraciones se haya realizado implementación de código aunque su mayor peso recae en las fases de construcción y transición. El objetivo de esta disciplina es planificar las pruebas necesarias para cada iteración. Esta disciplina nos proporciona el Modelo de Pruebas en donde se represente qué tipo de pruebas y sobre qué ítems se realizarán. PUD y SCRUM Los proyectos de desarrollo de productos software basados en el Proceso Unificado de Desarrollo pueden beneficiarse de los principios de Scrum añadiendo al PUD una mayor capacidad de cooperación entre los miembros del equipo y una mejor adaptabilidad a los cambios produciendo productos de calidad más competitivos. Las cuatro fases de un proyecto PUD (Comienzo, Elaboración, Construcción y Transición) definen el ciclo de vida de un producto software en base al proceso de ingeniería del software. Los principios de Scrum pueden ser aplicados durante el ciclo de vida completo del proyecto pero donde más visiblemente se observa su efecto es en las fases de Elaboración y Construcción ya que las Reuniones de Planificación de Sprint, las reuniones diarias y las Revisiones de los Sprint suponen instrumentos muy potentes. 12