UNIVERSIDAD CATOLICA ANDRES BELLO. FACULTAD DE INGENIERIA ESCUELA DE INFORMATICA Este Jurado; una vez realizado el examen del presente trabajo ha evaluado su contenido con el resultado: Dieciocho (18). JURADO EXAMINADOR REALIZADO POR Femandes Agrela Ana Karina, ‘Miranda Bouzas Carlos Manuel. TUTOR Ing. Gustavo Bonalde FECHA Febrero 2009Contenido Dedicatoria i Agradecimientos ii Indice de Figuras vi Indice de Tablas vii Sinopsis vii Cap.1 Planteamiento det Problema. 1.1 Planteamiento del Problema. 1.2 Objetivos. 4 1.2.1 Objetivo General. 4 1.2.2 Objetivos Especificos. 4 1.3 Alcanee. 6 1.4 Limitaciones. 1 1.5 Justificacién, 8 Cap. 2 Marco Referencial 2.1 Ciclo de vida de desarrollo del software. i 2.2 Objetivos de las fases del ciclo de vida de desarrollo del software, uw 2.3 Gestién de Requerimientos. 2 2.3.1 Pirdmide de Requerimientos. 4 2.3.2 Trazabilidad entre Requerimientos. 18 2.3.3 Caracteristicas de buenos Requerimientos. 16 23.4 Visién general del proceso. de gestién de Requerimientos. 7 24 Modelo de madurez de capacidades (CMM) ¢ Integracién del ‘modelo de madurez. de capacidades (CMMI). 18 2.4.1 CMMI~ Gestién de Requerimientos (REQM). 21 2.4.2 Pricticas genéricas de CMMI. 22.5 Metodologia Open UP. 23 2.5.1 Principios basicos de Open UP «4 2.5.2 Roles de Open UP 25 2.5.3 Productos de trabajo de requerimientos en Open UP 28 2.6 Herramientas CASE 3B 2.6.1 Clasificacién de herramientas CASE 4 Cap. 3 Metodologia 3.1 eXtreme Programming 36 3.1.1 {Qué es eXtreme Programming? 36 3.1.2 Prineipios de XP 36 3.1.3 Onganizacién de XP 39 3.1.4 Pricticas de XP 2 3.1.5 eXtremme Programming, y herramienta web (Requerimientos en Open UP) 44 Cap. 4 Desarrolio 4.1 Introduecién 45 4.2 teraciones 4s 4.2.1 Keracién 1 — Definicién de Plataforma y Herramientas de Desarrollo 45 4.22 leracién 2 —Diseiio del Modelo de Datos y Capa de Persistencia 48 4.2.3 eracién 3 ~Disefio y Concepeién de librerias para la capa de Presentacién 50 4.24 Iteracién 4 — Construceidn de la capa de Negocio 52 4.2.5 Iteracién 5 — WIKI, Trazabilidad, Gestién de cambio $4 4.2.6 teracién 6 — Generar documentos de Open UP en la herramienta 56 Cap. 5 Resultados 5.1 Objetivos vs resultados 57 5.1.1 Disefiar ¢ implementar una herramienta web, que permita Ja gestion de requerimientos. 375.1.2 Disefiar y construir una base de datos relacional, para centralizar los distintos tipos de requerimientos y sus atributos. 58 5.1.3 Disefiar e implementar las interfaces web necesarias para la gestin de requerimientos. 58 5.1.4 Desarrollar un médulo de administracién para la herramienta web que permita asociar a los proyectos con los usuarios. 59 5.1.5 Disefiar y desarrollar un mecanismo para la integracién de tuna herramienta software libre que gencre documentos con la herramienta de gestién de requerimientos, reflejando los requerimitentos almacenados en la base de datos. 61 5.1.6 Disefar y desarrollar un mecanismo para la integracion de una herramienta de cédigo abierto para la gestién de cambios en los requerimientos, con Ia herramienta de gestién de requerimientos. ol 5.1.7 Disefiar y desarrollar un mecanismo para la integracién de aplicaciones de Ingenieria Social que apoyen la comunicacién, colaboracién y coordinacién del equipo de trabajo, con Ia herramienta de gestién de requerimientos. a Cap. 6 Conclusiones y Recomendaciones 6.1 Objetivos vs Conclusiones 8 6.1.1 Disefiar e implementar una herramienta web, que permita Ja gestién de requerimientos, 63 6.1.2 Disefiar y construir una base de datos relacional, para centralizar los distintos tipos de requerimientos y sus atributos. 6 6.1.3 Disefiar ¢ implementar las interfaces web necesarias para la gestién de requerimientos 64 6.1.4 Desarrollar un médulo de administracién para la herramienta web que permita asociar a los proyectos con los usuarios 64 6.1.5 Disefiar y desarrollar un mecanismo para la integracién de tuna herramienta software libre que genere documentos con Ia herramienta de gestién de requerimientos, reflejando los requerimientos almacenados en la base de datos. 65 6.1.6 Disefiar y desarrollar un mecanismo para la integracién de ‘una herramienta de cédigo abierto para la gestién de cambios en los requerimientos, con la herramienta de gestién de requerimientos. 66 6.1.7 Disefiar y desarrollar un mecanismo para la integracion de aplicaciones de Ingenieria Social que apoyen la comunicacién, colaboracién y ‘coordinacién del equipo de trabajo, con la herramienta de gestién de requerimientos. 66 6.2 Recomendaciones. orReferencias Bibliograficas Apéndices ‘Apéndice A. Historias de Usuario, Apéndice B. Plantillas. Apéndice C. Componentes de Cédigo. Apéndice D. Roles en Open UP y CMMI. Apéndice E. Pruebas, Apéndice F. Modelo Entidad ~ Relacién y Diagrarmas Apéndice G. Manual de Usuario. Indice de Figuras Figura 1. Pirimide de Requerimientos Figura 2. Los cinco niveles de madurez del proceso de software. Figura 3. Areas de Open UP. Figura 4, Analista en Open UP. Figura 5. Arquitecto en Open UP. Figura 6, Desarrollador en Open UP. Figura 7. Gerente en Open UP. Figura 8. Interesados en Open UP. Figura 9. Otros en Open UP. Figura 10. Pruebas en Open UP. Figura 11, Proyecto con Extreme Programming, Figura 12. Mapa de historias de Usuario. n 112 122 123 124 15 3 R 26 7 27 7 48Indice de Tablas Tabla 1. Requerimientos y Documentos creados en cada paso. Tabla 2. Los cinco niveles del modelo CMM. ‘Tabla 3. Comparacién entre los niveles de Capacidad y Madurez. ‘Tabla 4. eXtreme Programming y la herramienta web. ‘Tabla 5. Historias de Usuario ~ Prioridad. Tabla 6. Roles y privilegios de Open UP. 18 20 a 49StMOpSIS Todo desarrollo de software tiene como objetivo la obtencién de un programa, disefiado para cubrir un conjunto de necesidades. Para lograr cumplir exitosamente este objetivo y obtener un producto de calidad, es necesario seguir as etapas del ciclo de vida del desarrollo del software, aplicando una metodologia que dictara el orden y las actividades que se deben seguir. La ingenierfa de requisitos ha sido una de las areas de Ia ingenierfa det software en la que mas esfuerzo de investigacién se ha realizado durante las diltimas décadas, y con motivo porque los errores de comprensién cometidos en esta etapa inicial de los proyectos son los mas costosos de resolver. Si no se detectan a tiempo, imptican la realizacién de actividades erréneas durante todas las fases subsiguientes, hasta llegar a las pruebas. El desarrollo de esta herramienta web como Trabajo Especial de Grado, permite una gestién de los requerimientos para desarrollos de software que se rijan bajo Metodologia Open UP, y que le permite al equipo crear y compartir sus requerimientos utilizando métodos familiares basados en documentos, potenciados por la aplicacién de las capacidades de una base de datos, tales como la trazabilidad. Los proyectos exitosos comienzan con una buena administracién de requerimientos, cuanto mas. efecti sea su ejecucién, mayor seri el resultado en calidad y satisfaccién del cliente.Capitulo I Planteamiento del Problema isin Prctiminar LI Planteamiento del Problema, 1.2 Objetivo General y Objetives Especificos. 1.3 Aleance. 1.4 Limitaciones. 1.5 Jastificactén. siguiente capitulo permite relacionar al lector con fos aspectos de Idemtiftecisn det tema,e) probleme, objetivos a ‘ateanzar,justifcocion y Jimitoctones del Trabajo Especial de Grado.Capitulo = Plantoamionte del Prablen 1.1 Planteamiento det Problema: Todo desarrollo de software tiene como objetivo la obtencién de un programa, diseftado para cubrir un conjunto de necesidades que varian dependiendo del area a la cual serd aplicado el mismo. Para lograr cumplir exitosamente este objetivo y obtener un producto de calidad, que satisfaga las necesidades de los clientes es necesario seguir las ‘tapas del ciclo de vide del desarrollo del software, aplicando una metodologia que dictard el onden y las actividades que se deben seguir. Independientemente de la metodologia elegida, en el ciclo de desarrollo del software una de las etapas mis importantes y clave pars lograr un producto exitoso, es la Definicién de Requerimientos, acompafiado de otras ctapas que complementan la obtencién de un producto de calidad La Definicién de Requerimientos es una etapa crucial en el desarrollo de software, porque si los requerimientos no se definen comectamente, no es posible construir soluciones que posean tn éxito medible. Es necesario que exista flexibilidad en la definicién de requerimientos para prevenir los cambios que puedan ocuttr, si esta Aexibilidad no se permite, el software desarrollado no cumpliri con las exigencias deseadas. En muchos casos no se hace una distincidn entre los requerimientos del cliente’, y los de los usuarios’, Los requerimientos de los clientes son necesidades que debe 1 Glee ae i i os ye mn obi Parser i a larsCapitulo 1 Planteamionto dol P satisfacer el sistema y los de los usuarios son servicios que debe prestar el sistema en orden de cumplir con dichas necesidades. Al omitir esta distincién se pierde la trazabilidad, que es la técnica utilizada para determinar el origen de los requerimientos, asi como fa flexibitidad ante requerimientos cambiantes 0 nuevos haciendo al sistema menos escalable yn js complejo para mantener [19]. Otro factor es que los requerimientos originales son almacenados en documentos que se recopilan en un repositorio, pero a medida que cambian nunca son modificados perdiendo el control y obteniendo un producto que no cumple con las necesidades del cliente, Ademiis muchas veces no existe un proceso de control de cambio definido para requerimientos 0, si se define, nunca es utilizado, o simplemente no hay forma de verificar si el sistema cumple con todos tos requerimientos. La RE? (Ingenieria de Requisitos) indica que para mantener madurez y calidad en los requerimientos, éstos deben ser documentados después de que se llega @ un consenso con los multiples interesados del sistema. La técnica para Ia obtenciéa de requerimientos debe ser utilizada segin el tipo de proyecto y los interesados en el mismo, Los repositorios deben ser actualizados a lo largo del ciclo de vida del desarrollo del proyeeto y como control final debe desarrollarse y mantenerse una matriz de trazabilidad. Muchos otros escenarios se pueden mencionar, pero la necesidad on la madurez en RE" es necesaria porque es lo correcto, porque nos permite obtener un producto que 3. RE:Regutanen Ean naan de Rois(Capitulo = Plantoamiento del Probloma ccumpla con las necesidades de los clientes y porque es la base de las etapas del ciclo de desarrollo de software. Existen muchos modelos para el andlisis de madurez en los requerimientos, por ejemplo, el modelo CMMI cuyo principio indica que la calidad de tun producto o de un sistema, se deriva en mayor parte como eonsecuencia de Ia calidad cn los procesos empleados para su desarrollo y mantenimiento (15). En consecuencia ante la importancia de una gestién eficiente de los requerimientos, en un proceso de desarrollo de software, ¢s necesaria una herramienta que permita controlar y mantener actualizado cualquier modificacién en ellos. Para ol desarrollo de software que se realiza bajo la metodologia Open UP no se dispone de una herramienta que offezca una gestién cficiente de requerimientos gue ademds los mantenga aetualizados durante todo el ciclo de vida de desarrollo de software. Por lo tanto si no se posee requerimientos bien definidos no sera posible desarrollar soluciones exitosas. {om capoity Matty oe! reganCapitulo |= Planteamiento del Problama L.2 Qbjetivo 41.21 Qbietive General: Desarrollar una herramienta web de cédigo abierto, para el apoyo de la Gestion de Requerimientos en el ciclo de vida del desarrollo de software, que cumpla con las premisas establecidas para el nivel dos (2) CMMI y para proyectos basados en metodologia Open UP. 1.2.2 Objetivos Especificos: © Disefiar e implementar una herramienta web, que permita Ia gestion de requerimientos, * Disetiar y construir una base de datos relacional, para centralizar los distintos tipos de requerimientos y sus atributos. © Disciiar ¢ implementar las interfaces web necesarias para Ia gestion de requerimientos, © Desarrollar un médulo de administracién para la herramienta web que permita asociar a los proyectos con los usuarios. * Diseiar y desarrollar un mecanismo para ta integracién de una herramienta software wre que genere documentos con la herramienta de gestion de requerimientos, reflejando los requerimientos almacenados en la base de datos.‘Capitulo [= Planteomionto del Problema Disefiar y desarrollar un mecanismo para fa integracién de una herramienta de eddigo abierto para la gestién de cambios en los requerimientos, con la herramienta de gestion de requerimientos, Diseftar y desarrollar un mecanismo para la integracién de aplicaciones de Ingenieria Social que apoyen In comunicacién, colaboracién y coordinacién del ‘equipo de trabajo, con la herramicnta de gestién de requerimientos.1.3 Alcance: Como resultado del Trabajo Especial de Grado el producto final sera una herramienta web de cédigo abierto desarrollada en lenguaje PHP, utilizando AJAX, que brindaré soporte a Ia gestion de requerimientos de proyectos de software, permitiendo Ia colaboracién de los miembros del equipo a través del modulo de administracion, que se desarrollaré basado en roles. La herramienta se conectarit a una base de datos relacional, para obtener los requerimientos que han sido definidos, los cuales se encuentran contenidos en la misma. Esta herramienta web de cédigo abierto generar la documentacién establecida por Ia etapa de definicién de requerimientos de la metodologia Open UP. Ademas permitiré dar seguimiento a las relaciones entre requerimientas funcionales y no funcionales, necesidades y ccaracteristicas detallados on los requisitos del software, manteniendo la trazabilidad entre ellos, Se establece que esta herramienta permita gestionar requerimientos segéin el nivel dos (2) de madutez establecido por el modelo CMMI, offeciendo la oportunidad de mantener los requerimientos gestionados y controlados en todo ‘momento a lo largo del desarrollo del software. Adicionalmente se integraté con otta hherramienta de software libre para la gestién de cambio sobre Jos requerimientos, ademas de integrar aplicaciones de Ingenieria Social que apoye la comunicacién, colaboracién y coordinacién del equipo de trabajo a través de notas o comentarios que se podriin agregar y ser vistos al momento de revisar los requerimientos,‘Capitulo | ~ Planteamionto del Problema 1.4 Limitaciones: Se incorporaran iinicamente aplicaciones herramicntas que cumplan de estindares abiertos 0 de software libre, # Se establece para esta herramienta la utilizacién de MySQL para la definicién de labase de datos. # Laherramienta web no permit realizar modelado UML. © El usuario debe ser eapaz de indicar a la herramienta que es tna necesidad y que es un requerimiento ‘+ Las pruebas que se le realizarin a la herramienta, serén realizadas con un caso de estudio especttico definido por los desarrolladores. ‘* Las aplicaciones de Ingenieria Social sein notas 0 comentarios sobre los requerimientos definidos.‘Captuo1= Plantoamionto det Problema 15 Justificaciin: La ingenieria de requisitos se refiere al anilisis, a la especificacién, y a la validacién de los requisitos del software, Esti extensamente reconocida dentro de la industria del software que los proyectos de la ingenieria de software son eriticamente vulnerables cuando estas actividades se realizan mal, La ingenierfa de requisitos ha sido una de las areas de la ingenieria del software en la que mis esfuerzo de investigacién se ha realizado durante las Ultimas décadas, y con motivo, porque los errores de comprensién cometidos en esta etapa inicial de los proyectos son los mas costosos de resolver. Si no se detectan a tiempo, implican la realizacién de actividades erroneas durante todas las fases subsiguientes, hasta Hegar a las pruebas. Momento en el que, a la vista de los defectos detectados en la ejecucién de los casos de prueba, se concluye gue la repeticién de las actividades cerréneas puede ser una manera de resolver Ia situacién, Como es bien conocido, el desarrollo de software ¢5 una tarea de equipo, es critieo que los miembros del equipo que van a implementar la solucién comprendan los objetivos y entregables apropiados. Ante esta situacién surge Ia siguiente interrogante Como puede un equipo entregar la solucién adecuada, si sus miembros no tienen acceso a la visién del proyecto, sus metas, especificaciones y otros requerimientos que detallan fo que la solucién final debe hacer? Los proyectos exitosos comienzan con Ingenieria de Requerimientos. CuantoCapitulo I= Planteamionte del Problema mejor sea la comunicacién y administracién de requerimientos, mayor seré la oportunidad para que los proyectos se entreguen a tiempo. Las herramicntas software pata la gestion de requisits se han convertido en la via mas eficiente para soportar la ‘automatizacion de estos procesos clave de las organizaciones que desarrollan 0 compran tecnologia, de aplicacién tanto al desarrollo de software tradicional, como el software critica. Es determinante que estas herramientas offezcan facilidades para adaptarse los procesos flexibles de especificacién de requisitos propios de los iemas de informacion (14), La ingenicria de requisitos es foco de metodologias, estindares y modelos de mejora, por ejemplo CMMI que vinculan las necesidades de los usuarios y partes interesadas, Se busea con esta herramienta mantener a los equipos de proyectos al dia gracias a Ja creacién, anilisis y gestién de los requisitos de aplicaciones y casos de uso. Se busea que cualquier cambio en tiempo real sea almacenado, La pioza clave para la definieién de los sistemas es el eorrecto conocimiento de los requerimientos, lo cual se fundamenta en amplio analisis de la solucién a implementar. Como se ha mencionado el desarrollo de software es una tarea de ‘equipo, de tal forma, es critico que todos los miembros del equipo posean un entendimiento compartido de la visién de sus proyectos, metas, especificaciones y requerimientos.Capitulo |= Plantoamionto del Problema El desarrollo de esta herramienta web que se propone como trabajo especial de ‘grado, permitird una gestién de los requerimientos para desatrollos de software que se rijan bajo Metodologia Open UP, y que le permite al equipo creat y compari sus requerimientos utilizando métodos familiares basados en documentos, potenciados por la aplicacién de las eapacidades de una base de datos, tales como la trazabilidad, Los proyectos exitosos comienzan con una buena administracién de requerimicntos, cuanto mas efectiva sea su ejecucién, mayor seri el resultado en calidad y satisfaccién del cliente.Capitulo IT Marco Referencial 211 Cleo de Vida de Desarrollo del Software. Savanna sirveeertet 22 Ohjetwos de las fases det cio de vida del desaralo | “vere Svebeeteganee Software. me 2.3 Gestiin de Requerimientos: + tar un pn 23.1 Pirie do Requerimientos. a agen de 23.2. Trazabilidad entre Requerimlentas. seaurmets 23.3 Caracteristicas de buenos Requerimientos. | + 92 234 Visién genera del proceso de gestén de inate Rqverndning + berate 24 Modelo de Madurez de eapacidades (CMM) e Integracién Seen det modelo de madurez de capactdades (CMM. 2a CMMI Gestin de Requerimientos (REQM. 242 Priticas genéricas de CMMI. + cresreaeon ga Ure 25 Metodotagia OpenuP a gain de Requrnsantos 2.5.1 Principios bistcos de OpenP sn proceso tract, ¥9 2.5.2 Roles de OpenP queestand en cigs de 2.5.3. Productos de trabajo de OpentiP les ses podemosretrocaser 26 Herramientas CASE ‘repatna atid 9 261 Clasficacion de Herramientas CASE sioner nen coalir [8]Capitulo = Marco Referencial 2.1 Ciclo de Vida de Desarrotio de Software j19): ‘Cuando se menciona el término ciclo de vida del software’, se describe el desarrollo de software, desde la fase" inicial hasta la fase final. El propésito es definir las distintas fases intermedias, que se requieren para validar el desarrollo de un sistema, es decir, para garantizar que el software cumpla los requisites y verificar los procedimientos de desarrollo, cerciorando que los métodos utilizados son apropiados. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad” del software y en los plazos de implementacién. Un cielo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables, Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, os tipos de productos intermedios que se generan, entre otros, pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologias empleadas. 2.2 Objetivos de las fases del ciclo de vida de desarrollo del software {192 Dentro de cada fase general, se pueden establecer una serie de objetivos: se de definicién (anilisis): Se construye un modelo de los requisitos. ean cn gains ctr acannon ge, mean ze me art tn pearCapitulo = Marco Roferencial Fase de diseito: A partir del modelo de anilisis se deducen las estructuras de datos, Ia estructura en la que se descompone el sistema y la interfaz de usuario. Fase de construccién (codificaciin): Se construye el sistema, La salida de esta fase es el eédigo ejecutable. Fase de pruebas y mantenimiento: Se comprucha que se cumplen criterios de correccién, calidad, asegurando que el sistema siga funcionando y adaptindose a nuevos requisitos. 2.3 Gestin de Requerimientos: Un requerimiento se define como "una condicién 0 capacidad que un sistema debe ‘cumplir” (19), Puede ser cualquiera de las siguientes: + Una capacidad que debe cumplirse, 0 que posee un sistema para satisfacer un contrato, un estindar, una especificacién u otro documento formalmente impuesto, + Una restriccién impuesta por una de las partes interesadas'. En la etapa de Definicién de Requerimientos se obtiene una descripeién de los requisitos del sistema (es decir, las condiciones 0 capacidades que el sistema debe ‘cumplir) suficientemente buena como para que pueda Hegarse a un acuerdo entre el 1 reas pray Se ene sen ae ci som ann ardCapitulo = Me cial cliente (incluyendo a los usuarios) y los desarrolladores, sobre qué debe y qué no debe hacer el sistema, El flujo de trabajo de la etapa de Requisitos consta de las siguientes ‘tapas (11]: ‘© Analizar el problema. © Andi de las necesidades de los implicados en el proceso de desarrollo, © Definir el sistema. © Gestionar el ambito del sistema. © Evaluacion, © Gestign de requisites. Algunos de los productos de desarrollo del software fundamentales que se producen ‘en la etapa de Requisitos son: ‘+ Especificacion de Requisitos, que puede ser Documento de Visién y Glosario de términos. ‘© Modelo de Casos de Uso, que incluye Especificacién de Casos de Uso, deseripcidn de actores, diagrama e informe del modelo de casos de uso. + Arquitectura Inicial, ‘+ Documento de cambios, ‘+ Informe de evaluacién.Capitulo = Marco Referencia} 2.3.1 Pirdmide de Requerimientos: Dependiendo del formato, fuente y caracteristicas comunes, los requerimientos se pueden dividir en diferentes tipos [19]: ‘© Participacién de necesidad: la exigencia de una parte interesada, © Caracteristica: un servicio prestado por el sistema, un propésito de una caracteristica es cumplir una neeesidad de interesados, + Caso de Uso: Una descripeién del comportamiento del sistema en términos de secuencias de aeciones. © Requerimientos no Funcionales: otto requisito (por lo general no funcional) que no puede ser capturados en casos de uso. © Casos de prueba: una especiticacién de prueba de los insumos, las condiciones de ejecucin y los resultados esperados. #Escenario: una secuencia especifica de acciones, con una ruta especitica a través, de un caso de uso. La pirimide de requerimientos agrupa en el nivel superior son las necesidades de los interesados. En los niveles mis bajos son las caracteristicas, casos de uso, y los requerimientos suplementarios. La principal diferencia entre las necesidades y carncteristicas esta en la fuente de la obligacién, es decir, las necesidades provienen de las partes interesadas y las caracteristicas son formuladas por los analistas del negocio, EL papel de easos de prueba consiste en comprobar si el uso de los requerimientosCapitulo = Marco Referenciat (Funcionales y no funcionales) se aplica correctamente. Los escenarios petmiten derivar casos de uso desde casos de prueba, facilitan el disefto y la implementacién de determinadas partes a través de casos de uso. uncweres cae al ‘i Figura 1. Pramide de Requerimiontos [9 2.3.2 Trazabilidad entre Requerimientos: La trazabilidad es una técnica que proporciona una relacién entre los distintos niveles de requerimientos en el sistema. Esta téenica le ayuda a determinar el origen de cualquier requisito. En la Figura 1, se ilustra cémo es la ttazabilidad de los requerimientos desde el nivel superior hasta ef inferior. Cada necesidad normalmente es mapeada con varias caracteristicas, a su ver las cardecteristicas son relacionadas con varios requerimientos, que también se relacionan con varios casos de uso. La trazabilidad desempetia varias funciones importantes: + Comprobacién de que una aplicacién cumple con todos los requisitos: Todo lo que el cliente pidid se puso en prictica, + Verificar que la aplicacién solo hace lo que se solicité: No aplicar algo que el cliente nunea solicits,Capitulo i Marco Roferenciat + Ayudar con Ia gestién del cambio: Cuando algunos de los requisitos fueron modificados, se quiere conocer que fubo cambios y cuales son para realizar los ‘nuevos casos de prueba, La trazabilidad es un elemento del proyecto que debe rastrearse a partir de otro elemento. Nos permite identificar Ja relacién Caracteristica — Requerimientos ~ Casos de Uso; cuales han sido 10s cambios suscitados a lo largo del proyecto. 2.3.3 Caracteristicas de buenos Requerimientos: Los buenos requerimientos deben tener las siguientes caracteristicas [19]: Inequivoco: Debe existir una sola manera de interpretar el requerimiento, Comprobable: Se debe verificar que la exigencia del requerimiento se aplica correctamente. Existen algunas palabras que hacen dificil que un requerimiento sea comprobable, algunas de ellas son: ‘9 Aéjetivos: Robusto, seguro, effeaz, eficiente, ampliable, flexible, mantenible, fiable, fil de usar, adecuado, © Adverbios: Rapido, seguro, de forma oportuna © Acrénimos: ete., y/ 0, PD. Coneiso: Los requerimientos no deben tener palabras o informacién innecesaria, Corregible: Se deben plantear los requerimientos de forma que se puedan ‘modificar fcilmente.f Raferencial Compresible: Deben ser redactados de forma coherente y gramiticamente corrects. Factible: Los requerimientos deben ser factibles (posibles) dentro de las limitaciones existentes tales como: tiempo, dinero y recursos. Consistente: No debe existir conflictos entre los requerimientos. Por ejemplo: Format de fechas (roma ~ mma}, Independiente: Un requerimiento no debe depender de otto requerimiento, _Atémico: La exigencia del requerimiento debe tener un tinico elemento trazable. Necesario: Un requerimiento es innecesario si ninguna de las partes interesadas lo ha solicitado. Un ejemplo, de un requerimiento que no es necesario, es aquel que ha sido afiadido asumiendo que los usuarios o el cliente lo quieren. Libre implementaeién: Los requerimientos no deben tener informacion innecesaria sobre su disefio o aplicacién, Para el usuario debe ser transparente como se almacena la informaciéa, No Redundante: Cada requerimiento debe ser expresado una sola vez y no deberia superponerse eon otro. Por ejemplo: Req fy Un calendar debe estar disponible para aya a burohici fo fecha de ‘Rey 2 El stoma debe mostrar wm pop ap cot calandario para regrareualgor ea. ‘Completo: Un requerimiento debe especificar todas las condiciones que pueden curr. 2.3.4 Visién generat del proceso de gestiin de Requerimientos:Capitulo I= Marco Referencial Una deseripeién simple del proceso de gestién de requerimientos se resume en los siguientes pasos: # Establecer un plan de gestién de requerimientos. * Obtencién de requerimientos. © Desarrollar ef documento de Visidn’ + Crear casos de uso. ‘© Disefto del Sistema. ‘A medida que se van ejecutando los pasos se va construyendo la pirimide de requerimientos (Figura 1). En la Tabla 1 se describe los tipos de requerimientos y que documentos se deben erear en cada paso. ‘Oberon de Reqaeranetos cen Desai doe de Vi Carers Ver Tier Cae de Ue Tannese eT Spe CT Dist eS Dagens a cae aoe Dasa OE “TaD T: RaquaTantos 7 Docimantow Gada en Gada paso [7]. 24 Modelo de madure; de capacidades (CMM) ¢ Integracién del modelo de madurez de capacidades (CMMI): EI modelo més importante en La actualidad para la evaluacién de la madurez de los procesos de desarrollo, es el modelo de madurez de capacidades (CMM, CapabiliMaturity Model) del Instituto de Ingenieria de Software (SEI). CMM tiene como objetivo evaluar los procesos en sus niveles de madurez ¢ identficar los niveles que una ‘organizacion debe formar para establecer una cultura de excelencia en Ia ingenieria de software. Los modelos CMM se generan gracias a la experiencia coleetiva de los proyectos mas exitosos de software, En particular, CMM es un marco de trabajo que especifica guias para las organizaciones de software que quieren incrementar su ccapacidad de procesos, considerando los siguientes puntos: + ldentificar fortalezas y debilidades en la organizacién, + Ponderar los riesgos de seleccionar entre diferentes contratos y monitorear los mmismos. + Entender las actividades necesarias para planear ¢ implementar los procesos de software + Ayudar a definir ¢ implementar procesos de software en Ia organizacién @ través de una guia, Los procesos se evalian mediante distintos niveles de madurez como se muestra en la tabla? y figura 2. Existe una extension del modelo basico de madurez, Ia integracién, del modelo de madurez de capacidades (CMMI, Capability Maturity Model Integration), cl cual tiene como objetivo integrar los diferentes dominios donde se ha aplicado CMM, mds allé de s6lo el desarrollo de software [18]. CMMI proporeiona a las organizaciones elementos esenciales para que posean procesos eficaces. CMMI se puede utilizar para guiar la mejora de todo un proceso, a través de un proyecto, una division o de toda unaCapitulo i= Marco Referencial recootenon gE Figura 2 Los cinco niveles da madurez dl proceso. software [8], Tr ro Taal) Poa Frain, Toca ona nminsrion igre So proses y abut 1 heramicnasspliadas Tapa | Secememen pas | EMR we EY wae ARE GHC We Gea Te csubleyunoivalrpebie de | savas awd mods yeas einen de stare 2 como esate De Sa ATE | EIST Ge SIS ORNS Ee IC TRO a rowresemayaryconiras, | Sener In cad y oso de fs purims, yuna base de do de proces. ilar y manner ov date del gris, Cals Is cde ‘ela deca prac eforura leads, Tina | Mas wnicalencn | Appar esol atone datos dl proms Ua Tov Sor atid jr con medias | para antiary mosis pocs 4 comprensia process ‘Grams | Majors won aren nazar Cosi mejor onan Foe 5 cle y caidas, "THEIR Loe cngo nveles dal rodels CHM TT organizacién, CMMI ayuda a integrar funciones tradicionalmente separadas de una organizacién, establecer objetivos de mejora en los procesos, prioridades, sieve de orientacién ea los procesos de calidad y establecer un punto de referen para evaluartuto larco Referencial los procesos actuales, CMMI busca ayudar la mejora de los procesos, recopilando las mejores précticas, organiza y da prioridad a las actividades. Un punto a destacar es que el modelo CMMI no es un proceso; un modelo CMMI describe las earacteristicas de cficacia en los procesos [17] CMMI también mantiene los 5 niveles de capacidad y de madurez [2]: Teams Dea 7 Tae aa Tails aR + Co Spina ‘Tabla Comparacion ene Tos rvelos de Capac y Maauree. “Mis informacion det médelo CMMI puede verse en el Apéndice D.2. 2.4.1 CMMI— Gestin de Requerimientos (REOM) {161: El propésito de la gestién de requerimientos, es el manejo de todos los requisitos del proyecto, identificar las incoherencias entre ellos y el plan de trabajo. Se debe manejar todos los requerimientos generados en el proyecto tanto técnicos como no ‘gcnicos. CMMI en la gestién de requerimientos (REQM) nos indica lo siguiente: Los requerimientos son gestionados y las inconsistencias son identificadas. a. Comprender los requerimientos, b, Compromiso por parte de los participantes del proyecto.Capitulo = Marco Referencial ‘¢. Gestionar los eambios de los requerimientos a lo largo del proyecto. d, Mantener la trazabilidad bidireccional entre los requerimientos. €. Identficar inconsistencia entre los requerimientos y el plan de trabajo. 2.4.2 Préeticas genéricas de CMMI 161: CMMI proporeiona unas pricticas genéricas que pueden ser utilizadas en cualquier érea de proceso: ‘+ Establecer y mantener una politica de planificacién y ejecucién de los procesos, dentro de la organizacién. ‘© Establecer y mantener un plan para la ejecucién de cada proceso. ‘«Proporeionar los recursos adecuados para el desarrollo de proyectos, procesos y prestacion de servicios. * Entrenar ef equipo de trabajo para que apoyen el desarrollo y soporte las necesidades segiin como sea necesari «Asignar niveles de control para productos de trabajo dentro de los procesos. ‘© Identificar e implicar las partes interesadas en los procesos, ‘© Monitorear y controlar los procesos de manera que se cumpla lo establecido en el plan de trabajo y tener medidas comectivas, ‘+ Evaluar los procesos por sus objetivos, deseripeién, estindares y procedimientos. + Examinar el estado, actividad, resultado de cada proceso con el mayor nivel de gestion y resolver cualquier problema. © Establecer y mantener una descripcién definida para cada proceso.Capitulo l= Marco Referencial ‘= Recoger los resultados de los procesos, los productos de trabajo, los resultados de las mediciones, informacion de apoyo al desarrollo de los productos, actividades de apoyo, todo para un uso futuro dentro de los procesos de la organizacién, Se debe tomar las mejores pricticas, para ser empleadas en ‘procesos futuro 2.5 Metodologia Open UP js}: ‘Open UP es una metodologia de desarrollo de software, de cédigo abierto diseftado para pequefios equipos organizados, tomando una apraximacién digit” del desarrollo, Ademis es iterativa, Minima, Completa, y Extensible!’ Govonte Anatiets Arguitecto. Pruchas Figura 3 Areas de Open UP (8) Se valora la colaboracién y el aporte de las partes interesadas sobre los 1 Ain sg: Ene UP op nae ag nea gh pts Eleni mu wissen ‘Seiad ae Piosisadsbem Bertake osc ~~Capitulo = Marco Referencial entregables. Open UP esti organizado dentro de cuatro freas principales de conteni Comunicacién y Colaboracién, Intencién, Solucién y Administracién, 2.5.1 Principios bisicos de Open UP [81: © Colaboracti6n: Para alinear los intereses y un entendimiento compartido, Se debe desarrollar précticas colaborativas que fomenten un ambiente de equipo saludable, Buenas pricticas colaborativas, eneuadran tos. intereses de los participantes del proyecto y les ayuda a desarrollar un entendimiiento compartido del proyecto. «Balance: Para conirontar las prioridades (necesidades y costos técnicos) Desarrollar una solucién que maximice los beneficios para los interesados y cumpla con las restricciones planteadas en el proyecto, © Enfoque: Articular la arquitectura para facilitar la colaboracion técnica, reducir los riesgos, minimizar excesos y trabajo extra, Enunciar las decisiones téenicas cesenciales a través de una arquitectura creciente, = Evolucién: idir ol proyecto en iteraciones eortas, enmarcadas en el tiempo para demostrar valor incremental, reducir riesgos!?, demostrar resultados. obtener retroalimentacién temprana y continua de los clientes. © mg ma it otc i ea enh ono eeCapitul = Marco Referencial 2.5.2 Roles de Open UP {3}: «© Analista: Las personas en este rol representan al cliente y los usuatios finales involucrados, obteniendo informacién desde los interesados para entender el problema a ser resuelto; capturar y ajustar las prioridades para los requerimicntes es su funeién, Figuta 4 Anata en Open UP| ‘© Arquitecto: Este rol es el responsable de disedar la arquitectura del software, la ‘cual incluye tomar las principales decisiones téenicas que condicionan globalmente el disefio y la implementacién del proyecto. Lidera o coordina el disefio téenico del sistema y tiene la responsabilidad general de manejar las principales decisiones técnicas, expresadas en laarquitectura del software. Esto tipicamente inclaye identificar y documentar los aspecios arquitecturalmente significativos del sistema, incluyendo vistas ‘de requerimientos, diseito, implementacién y despliegue. Este rol es también responsable de razonar sobre estas decisiones, equilibrando las preocupaciones de los interesados, reduciendo los riesgos téenicos y asegurindose que las decisiones son comunicadas eficazmente, validadas y acatadas. Ademés esti estrechamente involuerado con el Gerente para conformar y organizar el equipo encargado de la arquitectura y planear el proyecto.Capitulo = Marco Referencia! ‘Bock ce Nanas 6 ergaree Figura 5 Aruiteto en Open UP [8 ‘+ Desarrollador: Las personas en este rol son responsables por desarrollar una parte del sistema, incluyendo el disefio, para que se ajuste a la arquitectura, posiblemente prototipar la interfaz de usuario y entonces implementar, hacer pruebas unitarias © integrar los componentes que son parte de las funciones de éste rol. > > Figura 6. Desarolador en Open UP (8. © Gerente: Lidera la planeacién del proyecto, coordina interacciones con los interesados y conserva el equipo enfocado en aleanzar los objetivos del proyecto. > BS > rocvumman SOS renee Gerentsen Open UP (8). Figur Este rol: (© Aplica conocimientos de gestién, competencias, herramientas y técnicas a un “amplio rango de tareas, con el propésito de aleanzat los resultados deseados para unCapitulo = Marco Referencial proyecto en un tiempo oportuno. © Es responsable del resultado del proyecto y la aceptacién del producto por parte del cliente. ‘©. Es responsable por la evaluacién de los tiesgos del proyecto y por comtrolar estos riesgos a través de estrategias que los mitiguen. © Interesado Este rol representa grupos de interés cuyas necesidades deben ser satisfechas por el proyecto. Esto es un rol que podria ser desempefiado por cualquiera que esté (0 potencialmente estar) materialmente afectado por el resultado del proyecto, a Figura Ineresados en Open UP (8) * Otros: Cualquiera en un equipo puede cumplir este rol para llevar a cabo tareas generale, 8 wet a Figura. Otcos en Open UP (8) ‘© Pruebas: Este rol es responsable de las actividades principales del estuerzo de las pruebas. Estas actividades incluyen identificar, definir, implementar y dirigir las pruebas necesarias, como también verificar y analizar los resultados. = => Figura 10, Prucbas en Open UP (8). ‘Ver mas informacién de los roles en la metodologia Open Up en el Apéndice D.1.‘Capitulo = Marco Referencial 2.5.3 Productos de wabajo (artefactos) de requerimientos en Open UP {812 ‘+ Glosario: Este artefacto define términos importantes usados por el proyecto. Estos términos son las bases para una colaboracién efectiva con los interesados y otros miembros del equipo. © Objetivo: Proporcionar un vocabulario comin aceptado por todos los interesados. Este puede ayudar a las personas desde diferentes grupos funcionales a alcanzar un entendimiento mutuo del sistema. La meta no es registrar todos los términos posibles, sino Unicamente aquellos que son inciertos, ambiguos 0 requieren elaboracién. (© Descripeién principal: El Glosario le ayuda a evitar errores conceptuales al mnar dos recursos esenciales: propor * Una ubicacién central para consultar los términos y abreviaciones que son nuevas para los miembros del equipo de desarrollo, + Las definiciones de términos que son usados en forma especitfica dentro del dominio del proyecto. Las definiciones para los términos del Glosario provienen de varias fuentes, tales como documentos de requisitos, especificaciones y discusiones con interesados y expertos en el dominio del negocio. En algunos proyectos que no incluyen modelos del negocio, el Glosario es uno de los principales artefacto para capturar informacién sobreCapitulo = Marco Referencial el dominio de neg del proyecto, Este artefacto puede ser actualizado en cualquier ‘momento, por cualquier rol, cuando nuevos térmiinos sean identificados. Los errores conceptuales acerca del significado de datos de elementos conllevan al fracaso de muchos proyectos. Algunos de estos empiezan a set obvios tinicamente en las fuses posteriores a las prueba del sistema y puede ser extremadamente costoso coregirlos. ‘+ Requerimientos del Sistema: Este artefacto captura requisitos generales del sistema, incluyendo requisitos sobre atributos de calidad y requisites funcionales slobales. © Deseripeién principal: Las Caracteristicas, Requerimientas y Casos de Uso, juntos, definen los requisitos del sistema, Los Casos de Uso describen el comportamiento de los requerimientos, La meta de este producto de trabajo es asegurarse que todos os tipos de requisitos ‘estin cubiertas, lo cual reduce el riesgo de no considerar alguna faceta importante del sistema, Los requisitos son globales e influencian los Mecanismos de Arquitectura que se erearan, asi como guiar el desarrollo de los fundamentos del sistema. Estos requisitos son frecuentemente los elementos de mayor costo, porque éstos determinan las opciones arquiteeténicas. Ademés, si no se eaptura los requisitos globales del sistema en un lugar central, pero los repite a través de los Casos de Uso, el resultado seri mas ‘mantenimiento y mas opciones de cometer errores.larco Referencial ‘Ver plata de requerieentos ne endl BE + Especificacién de Casos de Uso: Este artefacto captura la secuencia de acciones que un sistema realiza y produce un resultado observable de valor a su interaccién con el mismo. © Objetivo: EI propésito principal de los Casos de Uso es capturar el comportamiento requerido del sistema desde la perspectiva del usuario final, para aleanzar una o més metas. Diferentes usuarios se benefician en diferente forma, por ejemplo: + Los Clientes los usan para deseribir, 0 al menos para aprobar, 1a descripeién del comportamiento del sistema, = Los Usuarios Potenciales los usan para entender el comportamiento del sistema, * Los Arquiteetos tos usan para identificar la fianeionalidad arquitecténicamente significativa. + Los Desarrolladores usan éstos para entender los comportamientos requeridos del sistema de tal manera que puedan identificar clases desde el flujo de eventos. + Los de pruebas usan éstos como una base para identificar un subconjunto de los Casos de Prucba requeridos. + Los Gerentes lo usan para planear y evaluat el trabajo en cada iteracién,Capitulo = Marco Referencial © Los Eseritores Técnicos lo usan para entender Ie secuencia del ‘comportamiento del sistema, para escribir la documentacién, © Opciones de representacién: Decidir la extensién de los Casos de Uso que se pueden elaborar: + {Describir Gnicamente flujos principales? + qDescribir inicamente los Casos de Uso mas importantes? ‘+ :Describir completamente las precondiciones y pos condiciones? = qDescribir escenarios primero, y luego elevar el nivel de abstraccién describiendo los flujos de los Casos de Uso? Algunos proyectos aplican Casos de Uso informalmente para ayudar a descubrir los requisitos, documentar y gestionar estos requisites en otra forma tal como unas historias de usuario. La forma como se presente los Casos de Uso podria depender del tamafio del proyecto, la experiencia del equipo, el conjunto de herramientas y las relaciones con el cliente. Ver plana de ecient de cso de wae Ap ‘+ Modelo de Casos de Uso: Este arteftcto eapturs en un modelo las funciones del sistema y su entomo, sirve como un contrato entre el cliente y los desarrolladores. © Objetivo: Este artefacto presenta un panorama de la intencién de ‘comportamiento del sistema. Es la base para el acuerdo entre las partes interesadas y‘el equipo del proyecto con respecto a la funcionalidad del sistema. También ayuda a orientar las diversas tareas en el ciclo de vida de desarrollo de software. © Opciones de representacién: Este artefucto sirve part apoyar las necesidades del equipo del proyecto. Las opciones de representacién incluye: informes y diagramas de modelado UML, las representaciones grificas ereadas con herramientas de dibujo, los dibujos en pizarras. La mayoria de la informacién del modelo de casos de uso es capturada a partir de la especiticacién de easos de u * Vision: Este artefacto contiene la definicién de ta mirada de los interesados del producto a desarrollar, especificado en términos de las necesidades y caracteristicas claves de los interesados. Este contiene una vista general de los requisites principales previstos para sistema, © Objetivo: Este artefacto prove alto nivel, algunas veces contractual, la base para los requisitos técnicos més detallados que son visibles para los interesados. Caprura la esencia del sistema describiendo los requisitos de alto nivel y las restricciones de diseflo que dan al lector una apreciacién global det sistema, desde una perspectiva de requisitos funcionales. Sirve como entrada para el proceso de aprobacién del proyecto, comunica los "Qué y Por qué” fundamentales del proyecto, proporciona un plan frente al ‘cual todas las decisiones futuras deberin ser confrontadas. © Deseripeién principal: Este artefacto proporciona una visién completa del sistema de sofware en desarrollo y sirve como soporte del contrato entre los clientesCapitulo t= a anciat y la organizacién de desarrollo, Cada proyecto necesita una fuente para capturat todas, las expectativas de los interesados. Este artefacto es escrito desde 1a perspectiva de los clientes, enfocado en las caracteristicas esenciales del sistema y niveles aceptables de calidad, El artefacto deberia incluir una descripeién de qué caracteristicas serin incluidas, como también cuales de estas se han considerado pero no se han incluido. Si no se usa este artefacto, hay un alto riesgo de que los interesados y-el equipo de desarrolladores tengan diferentes, cexpectativas. Esto podria llevar a la cancelacién del proyecto. Se debe enmarcar este ariefacto como requisito para las necesidades en el proyecto. Generalmente es buena prictica conservar este artefacto, tan breve como se pueda y tan pronto como sea posible centregar este a los interesados, hacer este fieil de leer y de comprender para los interesadas. ‘er pantie Vine Ape 2.6 Herramientas CASE (61: Una herramienta CASE” se puede definir como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de sofiware y desarrolladores, durante algunos pasos del Ciclo de Vida de desarrollo de un Software, La realizacién de un nuevo software requiere que las tareas sean organizadas ¥ "CASE: Compr de Sa rg itn po mei a gh Stanroo Referencial Capitulo completadas en forma correcta y eficiente. Las herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinacién de los eventos, que nocesitan ser mejorados en el ciclo de desarrollo de software. Estas herramientas pueden proveer muchos beneficios en todas las etapas det proceso de desarrollo de software, algunas de ellas son: ‘+ Vetificar el uso de todos los elementos en el sistema disefiado, ‘+ Automatizar el dibujo de diagramas, ‘+ Ayudar en la documentacién del sistema, '* Ayudar en la ereacién de relaciones en la Base de Datos, © Generar estructuras de cédigo, La principal veataja de la utilizacién de una herramienta CASE, es la mejora de la calidad de los desarrollos realizados y, en segundo término, cl aumento de la productividad, Para conseguir estos dos objetivos es conveniente contar con una organizacién y una metodologia de trabajo, ademis de la propia herramienta, La mejora de calidad se consigue reduciendo sustancialmente muchos de los problemas de andlisis y fio, inherentes a los proyectos de mediano y gran tamatio (logica del diseio, coherencia, consolidacién, ete.). La mejora de productividad se consigue a través de Ia automatizacién de determinadas tareas, como la generacién de ‘cédigo y la reutilizacién de objetos 0 médulos. 2.6.1 Clasificacién de herramiemtas CASE:Capitulo = Marco Referenciat No existe una tinica clasificacién de herramientas CASE y, en ocasiones, es ificil incluirlas en una clase determinada, Podrian clasificarse atendiendo a: ‘= Las plataformas que soportan. ‘© Las fases del ciclo de vida del desarrollo de sistemas que cubren. * La.arquitectura de las aplicaciones que produeen. ‘© Su funcionalidad. Las herramientas CASE, se pueden agrupar de la forma siguiente: 1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarean todas las fases del cielo de vida del desarrollo de sistemas. Son lamadas también CASE workbench, 2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) © front-end: orientadas a la automatizacién y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: analisis y diseft, 3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) © back-end: dirigidas alas ultimas fases del desarrollo, construccién ¢ implantacién, 4, Juegos de herramientas 0 Tools-Case, son el tipo mis simple de herramientas CASE, Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarian las herramientas de reingenieria, orientadas a la fase de mantenimiento,Capitulo TT Metodolagia in Prclminar 3.1 eXtreme Programming (XP) au B12 a13 bit as 208 es eXtreme Programming? Princpios de XP. Organizacion de x? Prdctcas de XP extremme Programming y herramienta ‘web (Requerimientos en Open UP) ‘amor mercado cuenta conn etodtois ue entripuyen 3 etzardo todo procesode Destro de Steve, ferrets amp gaa ermetadologasenin gules que hansido sounds cone ‘Wetolgis Ais? endo una dose recreates yee 2 [ecrore Progaming), ‘esi melons un ake trade colbert cnt prt una mons ania eas se productos slucanes frst)3.1 eXtreme Programming (XP): 3.1.1 Qué es eXtreme Programming? Extreme Programming es una diseiplina de desarrollo de software basada en los valores de la simplicidad, la comunica Ja retroalimentacién y coraje, Todo el equipo trabaja en presencia de simples précticas, con suficiente informacién para ver donde ‘estin y ajustar las pricticas a su situacién Ginica (13) Tiene como objetivo reducir el riesgo en el cielo de vida del software mediante ‘arupos de desarrollo pequefios. Considera que la mejor manera de tratar la falta de requisitos estables en un sistema, es mediante la agilidad de un grupo pequeno de desarrollo, Aunque XP define varias prieticas a seguir, quizas la mis representativa del proceso de XP es la programacién en pares (pair programming) [18] 3.1.2 Principios de XP © Comunicacién: XP hace hincapié en Ia comunicacién cara a cara, en lugar de otros tipos de comunicacin, tales como documentos. XP da valor a fos documentos, pero valoriza mucho mis la comunicacién personal. Para facilitar la comunicacién, los equipos XP: © Utilizan un vocabulario comin o metifora del sistema. © Trabajan muy cerca unos de otros, en un espacio abiert, © Integran el cédigo continuamente (© Trabajan en estrecha colaboracién con los profesionales de la empresa,Capitulo lt = Metodoloaie preferiblemente en el mismo ambiente fisico © Se programa en parejas. © Poscen ef eédigo colectivamente. (© Planean ¢ informan frecuentemente el estatus del proyecto al cliente. ‘* Simplicidad: XP supone que es mejor hacer una cosa sencilla hoy, que hacer una cosa complicada que nunca seri usada, Esta es una filosofia que impregna todo en un proyecto XP, Si algo no se necesita ahora, no se hace hoy. Por ejemplo: © No escribir cualquier documento, hasta que haya una necesidad inmediata y significativa. © No tomar ningin instrumento a menos que exista un beneficio tangible y verificable, Para mantener la sencillez del software y Ia estructura del equipo, los equipos XP realizan: (© {Cuil es la cosa mas ficil en la que se puede trabajar? © Simplificacién y mejora constante del disefio a través de la re-factorizacién, Kent Beck (“padre de XP”) offece las siguientes normas para un diseflo simple: © Se debe gastar en todas las pruebas. © No debe existir eédigo duplicado.Capitulo I= Metodotogie © Expresar todas las ideas que el autor quiere expresar. ‘© Reducir al minimo las clases y métodos. ‘© Retroalimentacién (feedback): La retroalimentacién es de diferentes escalas en XP. En el nivel mas alto, el cliente puede ver el progreso del equipo y del sistema a través de entregas ejecutables cada dos semanas. Esta informacién continua permite al cliente guiar el proyecto al éxito. Esto permite obtener comentarios concretos sobre el ‘estado del sistema, que esti constituido por piezas de funcionalidad que son ejecutables cn repetidas ocasiones, por las pruebas de aceptacién automiética, Estas pruebas permiten prevenir el desarrollo del sistema de nuevo. El nivel de la programacién, los desarrolladores deben escribir pruebas unitarias sobre toda la légica del sistema, para obtener informacién inmediata y conereta, que les informe si el cddigo que se esta haciendo, es justo lo que se quiere escribir. Los equipos de XP pueden: (© Desarrollar en pequeias iteraciones. (© Reunir los requisitos y caracteristicas en las historias que encajan en una ineracién, ‘© Eseribir pequefas unidades para asegurar que el eédigo generado, en las tareas funciona correctamente. © Escribir prucbas para asegurarse de que las historias fiuncionen comrectamente.Capitulo it = Matodoloala (© Supervisar el progreso y mantener la comunicacién frecuente con los clientes. © Coraje: Tal vez un mejor nombre para este principio es la confianza al trabajo, Jos miembros de un equipo de XP deben tener el valor de confar en Tos demés, en los clientes, en sus pricticas y en si mismos. Los miembros del equipo de XP saben que pueden: (© Detenerse cuando estan cansados. (© Permitir que todas las decisiones sean tomadas por el cliente, (© Solicitar a los clientes reducir el alcance de una historia, (© Solicitar ayuda a sus compafieros o clientes. © Disefar y aplicar slo to necesario para hoy. (© Hacer cambios para mejorar la funcionalidad o la estructura del codigo. (© Concertar el disefio y actualizacién del eédigo existente, cuando el ho se muestra insuficiente © Cambiar el e6digo no escrito, © Cambiar el proceso cuando no funciona. 3.113 Organizacién de XP La metodologia XP esté organizada en los siguientes apartados;Capitulo il Metodolonta © Las Historias de Usuario: Esta téenica se utiliza para especificar los requisitos del software, Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caracteristicas que el sistema debe poseer, sean requisitos funcionales 0 no funcionales. El tratamiento de las historias de usuario es muy dinimico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarlas en unas semanas [12}. © Roles XP: En eXireme Programming existe una clara division entre las atribuciones del cliente y las del desarrollador, ambos estén en el mismo equipo pero toman diferentes decisiones. ‘Se pueden resumir las decisiones de cada uno de ellos de la siguiente forma: © El cliente decide alcance, prioridad, composicién de las entregas para hhacerlas utiles y listas para la produceidn, por diimo la fecha en que éstas, centregas deben hacerse. © Los programadores en cambio deben estimar el tiempo para agregar nuevas caraeteristicas, deben explicar las consecuencias téenicas 0 posibles opciones para cumplir con algiin objetivo, sin embargo el cliente tienen la decisién final. Por iiltimo es labor de los programadores establecer el esquema de trabajo del equipo y la planificacién de cadaCapitulo l= Metodotonia + Proceso: El ciclo de desarrollo consiste en: © Elcliente define el valor de negocio 2 implementar, © El programador estima el esfuerzo necesario para su implementacién, co El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. © El programador construye ese valor de negocio, © Vuelve al paso 1. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden, Esta metodologia nos dice, que no se debe presionar al programador a realizar mis trabajo que el estimado, ya que se perder calidad en el software o no se cumplirin los plazos. De la misma forma el cliente tiene la obligacién de mangjar el émbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracién. Las fases de XP consiste en: © Planificaci © Disefo.Capitulo Ml = Metodoloaia © Desarrollo. © Pruebas. 3.1.4 Prévticas de XP © Planificacién: Hay una comunicacién frecuente el cliente y los programadores. EL equipo téenico realiza una estimacién del esfuerzo requerido para ta implementacién 4e las historias de usuario y los clientes deciden sobre el Ambito y tiempo de las entregas de cada iteracién. + Eniregas pequefias: Producit ripidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema, Esta versién ya constituye un resultado de valor para el negocio. Una entrega no deberfa tardar mis 3 meses © Meréfora: El sistema es definido mediante una metéfora © un conjunto de metiforas compartidas por el cliente y el equipo de desarrollo. Una metifora es una historia compartida que deseribe eémo deberia funcionar el sistema. + Diseito simple: Se debe diseBar Ia solucién més simple que pueda funcionar y set implementada en un momento determinado del proyecto. © Pruebas: La produccién de cédigo esti dirigida por las pruebas. Estas son establecidas por el cliente antes de escribirse el e6digo y son ejecutadas constantemente ante cada modifieacién del sistema. © Refactorizactén (Refaetoring): Es una actividad constante de reesteuetutacionCapitulo eto el e6digo con el objetivo de remover duplicacién de eédigo, mejorar su legibilidad, simplificarlo y hacerlo mis flexible para facilitar los posteriores cambios. Se mejora la ‘estructura interna del eddigo sin alterar su comportamiento externo. « Programacién en parejas: Toda la produccién de eddigo debe realizarse con trabajo en parejas de programadores. Cualquier programador puede cambiar cualquier parte del cédigo en cualquier moment. # Integracién continua: Cada pieza de cédigo es integrada en el sistema una ver (que esté lista. Asi, el sistema puede llegar a ser integrado y construido varias veces en un mismo di © Cliente in-situ: El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Este es uno de los principales factores de éxito del proyecto XP. EL cliente conduce constantemente el trabajo hacia lo que aportaré mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociads, © Estindares de programaci XP enfatiza que la comunicacién de los programadores es a través del cédigo, con lo cual es indispensable que se sigan ciertos estindares de programacién para mantener el cédigo legible. Proyecto en XPCapitulo il = Metodotoata 3.1.5 eXtreme Programming y herramienta web (Requerimientos en Open UP): ‘Tomando en cuenta toda la informacién suministrada sobre_metodologia XP, es necesario just car su uso en este trabajo especial de grado, un resumen se ve reflejado en la Tabla 4, en donde se describen las actividades y productos obtenidos: seg ae Th eee churn eo deal. Tisai de Creo ‘Aigo de pode eds was Poorer hts de stra Pain de seu uti. 2 Ophoces Panes 1 Reramenta de dena 7 Apeaste Gt pane Ge areca we | = Diagranar de Clsee SStaponsis Se cise (cue) ge Dito ‘Soman a rami, Dear 7 Reason + Cia Tae te a + Eikaacia Ge peter freeman pas] > Pasha asses erica el corete incoamieno le emmien. "TBE akrame Programming ya hevvamventa wa Las metodologias pesadas basadas en el proceso unificado generan excesiva documentacién lo eual resta tiempo para la codificacién de la solucién final. XP pe cenfocarse en lo que debe hacer la herramienta ¢ integrar de una manera ripida eédigo funcional a la misma, adicionalmente permite visualizar los resultados mis expoditamente, Otro aspecto importante es que XP facilita el levantamiento de informacién a través de la utilizacién de historias de usuario y permite su evolucion siendo posible agregar muevos requerimientos, refinar el disefio sin afectar los plazos de entrega. Por iltimo la ejecucién de un plan de pricbas garantiza la estabilidad de la aplicacién final, redueiendo el margen de errores y la aplicacion de pruebas de calidad ueDesarrollo 4.1 Introduccion, 4.2 Meraciones. 421 422 423 424 425 426 Enel presente capitulo se daa conocer a actor las iteraciones necesarias para fl desarcole de este Trabajo ‘especial de (eracidn 1 ~ Definicton de Plataforma y Herramientas Iteracién 1 ~ Defin taforma y t eee sie Desarrolto. IReracén 2 Diseno det Madeto de Datos y Capa de Persistencia, Iteracién 3 Diseno y Concepcién de lbreras para la capa de Presentacién. IReraciin 4 ~ Construecién de la Capa de Negocio. Ievacién 5 ~ WIKI ~ Trazabilidad y Gestién de Cambio. ‘heractén 6 Generar documentos de Open UP en ta herramienta.4.1 Intvoduccin El proceso de construccién de la heramienta web para la gestion de requerimientos fue dividido en seis (6) iteraciones. El proceso de ejecucién para cada iteracién comprende las cuatro (4) fases (Planificacidn, Disefo, Desarrollo y Pruebas) de la metodologia aplicada para el desarrollo de éste Trabajo Especial de Grado, 4.2 Heraciones 4.21 Ieraciin 1 - Definicién de Plataforma y Herramientas de Desarrollo: ‘+ Planificacién: El] punto inicial del desarrollo de la herramienta web, fue la elaboracién de historias de usuario (Apéndice 4), tal como lo indica la metodologia de desarrollo XP. Para cumplir con los objetivos planteados en la creaciin de ésta hherramicnta, fue necesario indagar sobre herramientas que cumplan con estindares de ccédigo abierto, como un procesador de texto y gestion de cambio, Otro factor importante fue establecer la estructura y construccién de ls herramicata web siguiendo un patrin de arquitectura de software, ‘+ Diseflo: El punto de arranque en esta fase, fue la elaboracion de historias de usuario que deseriben las funcfonalidades de la herramienta. Las historias de usuario no son mis que la deseripeién del sistema desde ef punto de vista det usuario! y fueron construidas tomando como formato una plantilla de XP para historias de usuario (Ver 14 eserplonpropoctanads por Kant Sec (iCapitulo IV= Desarrotio Apéndice B.4). La eleccién del procesador de texto fue otra actividad importante, varias suites ofiméticas fueron comparadas (OpenOffice, EasyOffice, Ssuite Office), Open Office Writer fue el elegido para ser integrado con la herramienta web, a través del uso de librerias y mecanismos de conexién.La eleccién de OpenOffice Writer como procesador de texto se debe a que forma parte del conjunto de aplicaciones libres del la si ofimética OpenOffice, esté desarrollado por Sun Microsystems, ademas es ‘multiplataforma, soporta el formato propietario doc (Microsoft Office), posee un formato native XML, puede exportar a ficheros PDF sin necesidad de programas intermedios. La libreria utilizada para exportar informacién desde una aplicacién desarrollada bajo lenguaje PHP, a OpenOffice Writer es conocida como ODF; esta libreria. genera un archivo XML, permitiendo exportar la informacién a OpenOffice. La libreria también hace uso de la extensién ZIP de PHP. La herramienta de gestion de cambio de requerimientos elegida fue GCRS (Gestién de Cambio en Requerimientos de Software); la cleccién de ésta herramienta para Ia gestién de cambio, se debe a que cumple con estindares abiertos, esta desarrollada en lenguaje PHP y se acopla a otras hrorramicntas web a las que presta servieio adapténdose al modelo de base datos de la herramienta propietaria, Toda la arquitectura de la herramienta se Hevé a cabo mediante la utilizacion de un patron de arquitectura como lo es MVC (Modelo Vista Controlador) MVC separa los datos de una aplicacién, la interfaz de usuario, y la légica de control en. tres componentes distintos, En este desarrollo la Vista son todas las piiginas HTML" y ‘S.TML: Lange 8 Maen eno, 8 leans macac redornara pr laconic de pigs abCapitulo = Desarrolio cl eédiga que provee de datos dinémicos a cada pagina; el Modelo es el Sistema de Gestidn de Base de Datos y la Légica de negocio; y el Controlador es el responsable de recibir los eventos de entrada desde la vista. Segin lo establecido por la metodologia de desarrollo, los requerimientos del sistema, deben ser expresados en historias de usuario, Otro punto a destacar fue la utilizacién de herramientas CASE, para elaborar el modelo centidad- relacién de la base de datos que soporta la herramienta web. © Desarrollo: El objetivo en esta fase fue construir las historias de usuarios, que conforman Ia base para el desarrollo de la herramienta (Ver Apéndice A). Ademés se elabord el modelo entidad-relacién (Ver Apéndice F.1); también se realiz6 un diseto general de las interfaces de usuario (Ver Apéndice F.2). © Pruebas: Todas las pruebas realizadas en las iteraciones, se basaron en el proceso de V & V (Verificacién y Validacién), la verificacién a través de la inspeccién se ocupa del anilisis de representaciones estiticas del sistema para describir el problema, La validacion nos ayuda a determinar sil sistema cumple con los requerimientos, es decir, intenta determinar la correspondencia entre la realidad y las especificaciones. El plan de pruebas puede ser visto en el Apéndice E. EI mapa de historia de usuario, permite visualizar todo el sistema, es decir, representa al producto como un todo. En el mapa se deben ubicar las grandes historias de usuario (actividades) y las historias mas pequefias que las complementan (tareas). A continuacién ¢l mapa de Historias de Usuario para el desarrollo de la herramienta web:(a rtsitacerte aan FE tres ae ero Figura 12, Mapa de historias de Usuario 4.2.2 [teracién 2 Diseito del Modeto de Datos v Capa de Persistencia: © Planificacién: EI desarrollo de ta berramienta se inicié por la asignacién de prioridad en las historias de usuario, posteriormente se cred la Base de Datos que es la encargada de gestionar los datos y hace posible que esta se convierta en informacién, con la ayuda de Ia capa de persistencia, Se utliz6 el patron de disefio DAO (Data Access Object) para encapsular la interaccién de la herramienta con la base de datos, © Disefio: Para persist los datos, la herramienta web debe interactuar con la base de datos. El cémo internctiia no debe ser asunto de la capa de légica de negocio, ya que para eso existe la capa de persistencia, que es la eneargada de interactuar con la base de datos, Por medio del patron DAO (Data Access Object) es posible definit mediante un ccontrato las operaciones que deben ser ejecutadas en cada una de las entidades de la© base de datos, por Jo general dentro de estas operaciones se incluyen los usos CRUD (Create, Read, Update y Delete). Ver diagrama de clases en el Apéndice F.3 + Desarrollo: El objetivo de esta fase fue la asignacién de prioridades @ las historias de usuario. Otra actividad dentro de esta fase fue la creaci6n de la base de datos cn el mangjador MySQL versién 5.0; la base de datos esté constituida por catorce (14) tablas relacionadas, ademés se desarrolld la capa de persistencia para la interaccién herramienta ~ base de datos. Un extract de esta capa puede observarse en el Apéndice Gi ‘A continuacién se presenta un breve resumen de Ia asignacién de prioridad en Ins historias de usuario: Tarr eo Grae Pate 3 ‘omar Te sr Te a coat Corman Regret egret Saar Tm or Saar Femi a Tia Teta a Canal Pagacter os Miia Poe a ara Pa a os Taaed 7 as ae va a no ee Tete 3 Messrs as —] Fegan ] Ni seit eon Tae 7 Reece Tor a 3 “Tabla, Historias de Usuario - iorCapitulo ‘© Pruebas: Las pruebas ejecutadas, consta de prucbas funcionales aplicadas desde la herramienta para probar el funcionamiento de la capa de persistencia. Wer Apéndice E 4.2.3 Iteraciéy 3 ~ Disefto y Concepcién de librerias para la capa de Presentacién: * Planificacién: EI propésito de esta iterncién, es producir un conjunto de componentes de eédigo que permitan facilitar el desarrollo de una capa de presentacién mas usable, que pueda ser asimilada de mejor forme por el usuario. Estos componentes, estén basados en Javascript los cuales integran dentro de sus funcionalidades ‘comportamiento basado en AJAX" permitiendo crear una interfaz de usuario mas utitizable e interactiva © Disefio: Una forma posible de realizar cambios sobre las piginas web, sin necesidad de recargarlas, permitiendo interactividad y velocidad, es a través de la utilizacién de AJAX, que no es mis que una téenica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente”, es decir, en el navegador de Los usvarios mientras se mantiene 1a comunicacién asinerona con el servidor en segundo plano. En su mayoria la herramienta cuenta con las ventajas oftecidas por AJAX y Javascript, para el manejo de ta informacion. Gran parte del proceso de desarrollo se centra en el concepto de usabilidad’*, tratando de evitar ct te idesordenes visuales, evitar el uso excesivo de grificos, textos en movimiento, decoraciones excesivas que solo evan a la distraccién del usuario, Ia herramienta cuenta con un arbol que agrupa todos los elementos creados en un proyecto por el equipo de trabajo (usuarios), de esta manera se offece a los usuarios una lista detallada de todo lo creado, ademas permite aeceder a todos estos elementos de forma sencilla y ripida, Gracias a las ventajas offecidas por AIAX, las paginas creadas permiten realizar modificaciones inmediatas sin necesidad de ser recargadas nuevamente, Con la utilizacién del componente Javascript se busca validar en el cliente la informacién introducida por los usuarios, antes de ser enviada al servidor, con la intencién de reducir el trafico en la red y el tiempo de respuesta al usuario (Ver interfaces Apéndice G). ‘+ Desarrollo: La primera actividad fue la creacién de una funcién para crear el objeto XML HTTP Request que conforma la base para utilizar AJAX, Seguidamente se crearon finciones encargadas de manejar el cambio de estatus del objeto XML HTTP Request, asi como el envio de informacién manera asinerona, Ver extracto en el Apéndice C.2. Otra actividad fue el desarrollo de funciones en Javascript, para validar los datos enviados por los usuarios, a través de Los formularios que se encuentra en las interfaces de la herramienta, porque es mis répido validar en el cliente, que ir hasta el servidor, con esto se puede reducir el tréfico de red, sin embargo estas validaciones también son aplicadas en el servidor, la principal razén de esta accidn es prevenir que aiin cuando el usuario desactive la ejecuciéin de cédigo Javaseript en el navegador, la herramienta pueda procesar las acciones de forma correcta validando los datos enviadosCapitulo IV = Desarrollo a fin de evitar inconsistencias en los mismos. Un aspecto importante a destacar sobre Ia libreria, es la compatibilidad Cross-Browser, esta compatibilidad es necesaria debido a la naturaleza intrinseea de los navegadores, los cuales son construidos por diferentes ‘empresas y no en todos los casos respetan los estindares establecidos en lenguajes rales como: HTML, CSS (Hojas de estilo en cascada) 0 Javascript, algunas veces las interpretaciones pueden ser distinias por parte de estas empresas de desarrollo creando nuevas funcionalidades y decidiendo cuales soportan, Ademis a medida que los navegadores evolucionan, también sus especificaciones mejoran, por lo que las distintas, versiones del mismo software de exploracién web, también pueden mostrar las paginas ‘de manera distinta entre si. Es por ello que se deben crear piginas web que se vean igual en todos los navegadores, a este tipo de solucién se le conoce como Cross-Browser. ‘© Pruebas: En esta fase se ejecutaron pruebas funcionales sobre los componentes de AJAX creadas. Se comprobé la compatibilidad de dichas funciones en los navegadores mis conocides (FIREFOX - iExplorer). Ademis se validé el correcto desempefio de las funciones de Javascript para validar los datos en los formularios de la herramienta, Ver Apéndice E 4.24 lteraciin 4 Construccién de la Capa de Negocio: * Planificacién: EI objetivo de esta iteracién, es producir un eonjunto de eédigo que permita facilitar el desarrollo de la capa de negocio. Se disetié y desartollé los _médulos de gestidn de los elementos de la herramienta, tales como proyectos, usuarios, 19. crete Grows: doar pas won qu saver sractameni gis on cuba megaCapitulo V— Desarrollo paquetes, caracteristicas, requerimientos, casos de uso, términos. Estos médulos permiten funcionalidades basicas tales como creacién, modificacién, supresion y consulta. ‘+ Diseito: Segin el pattén MVC el modelo no solamente es Ia capa de persistencia sino también los servicios de la ligica de negocio, es devir, las clases que definen el contrat de operaciones que soportaran las historias de usuario o fumcionalidades principales de la herramienta (Ver diagrama de arguitectura Apéndice F4). Durante ‘esta iteracién se definié el contrato inicial con las fuuncionalidades que debian ser soportadas en esta iteracién, Desarrollo: El objetivo de esta fase de la iteracién, fue el desarrollo inicial de la capa de negocio de la herramienta, es deci, la creacién de los servicios que contienen ta funcionalidades bisicas requeridas, como creacién, modificacién, consulta, supresién, validacién de usuarios, consultas por criterios especificos, entre otras; también se definieron las interfaces necesarias para hacer cumplir la fimcionalidad de dichas operaciones. Estas interfaces 0 comtratos de programacién como también suelen denominarse tienen como objetivo desacoplar el disefo de la capa del modelo a fin de poder introducir cambios en las clases que implementan estas interfaces sin afectar las capas superiores como el Controlador y la Vista. Un fragmento de estas interfaces y clases desarrolladas pueden observarse en el Apéndice C.5. Pruebas: Para verificar el correeto funcionamiento de las clases e interfaces creadas se ejecutaron pruebas funcionales a fin de validar la vertical completa, ver Apéndice E.4.2.5 Itevacién ~ WIKI, Trazabilidad y Gestiin de Cambio: © Planificacién: En esta oportunidad el propésito de Ia iteracién es la ereacién de ‘una aplicacién de Ingenieria Social que apoye la comunicacidn y colaboracion entre los miembros del equipo de trabajo, Otro objetivo es generar en la herramienta una matriz, de trazabilidad, para que el equipo de trabajo (usuarios), observe Ia relacién entre los niveles de requerimientos de un proyecto, Otto punto importante ¢s lograr Ia integracién de Ia herramienta web con la herramienta de gestién de cambios de requerimientos GCRS, para permitir a los usuarios observar los cambios realizados en los elementos que conforman el proyecto. ‘© Diseio: En esta oportunidad ta aplicacién de Ingenieria Social, se ha denominado WIKI, que no es mis que permitir a los miembros del equipo una comunicacién dentro de Ia herramienta, basado en la generacién de comentatios sobre las caracteristicas, requerimientos y casos de uso. La trazabilidad es una técnica que propotciona una relacién entre los distintos niveles de requerimientos en la herramienta, Esta técnica le ayuda a determinar el origen de cualquier requisito. En la herramienta ‘web la trazabilidad, es representada a través de una matriz, donde se indica al usuario si hhan ocurrido cambios 0 modificaciones no aprobadas, en alguno de los niveles de requerimientos. Ademés de mosirar los cambios ea Ia matriz de trazabilidad, éstos pueden observarse en Ia herramienta de gestién de cambio en requerimientos de software GCRS, a través de Ia integracién con la herramienta web. GCRS lista todas las modificaciones realizadas en los requerimientos de un proyecto y los usuarios queCapitulo W— Desarrollo cefectuaron tales cambios, ‘+ Desarrollo: El objetivo de esta fase fue a creacién de un conjunto de componentes de e6digo, que permita fluir la informacién entre la capa de presentacién, la capa de negocio y la capa de persistencia; con el fin de permitir la generacién de comentarios sobre caracterist sas, requerimientos, casos de uso y generar wna matriz de trazabilidad. Para lograr la creacién de la matriz de trazabilidad, también fue necesario desarrollar un conjunto importante de componentes de eddigo, que lograra a través de la capa de persistencia extraer la relacién entre los distintos de niveles de requerimientos, vuna_vez extraido tales datos, otros componentes fueron construidos en la capa de negocio a fin de transformar esos datos en informacién Iégica y entendible para el usuario, Una vez que se obtuvo la informacién se Ilevé a la capa de presentacién para que el usuario pueda observar las relaciones entre requerimientos y observar cuales presentan alguna modificacién no aprobada. El componente de AJAX desartollado para la herramienta, también fue ulilizado en esta iteracién, para hacer Ja generacion de comentarios mis dinamica y ripida, asi como también para Ia aprobacién de cambios sobre Ia matriz de trazabilidad. Para lograr la integracién entre la herramienta web y GERS fue necesario el desarrollo de un importante conjunto de componentes de cédigo, fa fin de permitir a GCRS interactuar con la capa de persistencia desarrollada para la herramienta web y poder generar el historial de cambios realizados en los niveles de requerimientos ereados. ‘+ Pruebas: En esta fase de la iteracién fueron ejecutas pruebas funeionales, para(Capitulo V= Dosarretio comprobar el fancionamiento de los componentes creadas y detectar algiin error, que afecte el correcto funcionamiento de la herramienta, Ver Apéndice E 4.26 Iteracién 6 — Generar documentos de Open UP en la herramienta: + Planificacién: En esta oportunidad el objetivo es la generacién de documentos o artefuctos de la metodologia Open UP, desde la herramienta web. Tales documentos son la Visién del proyecto, Requerimientos del sistema, Glosario. Estos documentos ereados 4 través de la herramienta deben ser “wansferidos” a um procesador de texto de cédigo abierto. + Disefio: En esta oportunidad Ia iteracion esta basada en la construceién de un ‘mecanismo de integracién entre la herramienta web desarrollada y la libreria ODF, que en conjunto con la extension ZIP de PHP, permite a través de la ereacién de un archivo XML, generar un documento en OpenOftice Writer desde una aplicacién desarrollada en lenguaje PHP. Ver extracto de la libreria ODF y del mecanismo de integraciéa en el Apéndice C.6y C7. ‘+ Desarrollo: Esta fase se basa en la construccién de componentes de cddigo que permitan a través de la interaccién con la capa de persistencia extraer los datos, y por el meeanismo de integracién desarrollado, enviarlos a la libretla ODF y ésta a su ver pueda generar un archivo XML que es interpretado por el procesador de texto, ‘+ Pruebas: Como en otras iteraciones, esta fase se basa en la ejecucién de pruchas funcionales para verificar la completa vertical de la herramienta. Ver Apéndice ECapitulo V Resultados * Oiitin Prctininar 5.1 Objetivos vs Resultados. 5:11 Disrtar implementa una heraminta web, que pomita rs lagen de rears. stnmate 5.12 Diseiar y construir una base de datos relacional, para see contatizar ts diosa de equerinontas yas ae a. vend 5.1.3. Disefar e implementar las interfaces web necesarias para ia | Menger” destin de reuarmients ooh S14 Desarrllar un maul de adminstracin parol ames Feraienta web que pormitaasotar als proyectos conense ‘com los usuarios. on 5.15 Diseflar y desarrollar un mecanismo para ta integracién de una herramienta software libre que genere documentos con a herramieta de gestn de requerimiens rflejando los requerimientos almacenados en ta base de datas. 5.1.6 Diseliar y desarvoliar un mecanismo pant ta integracion de una herramienta de céidigo ablerio para la gestiin de cambios on tos requerimientas, con la herramienta de gestidn de requerimientos 5.1.7 Diseftar y desarvallar un mecanismo pare ta integracion de ‘aplicactones de Ingenieria Social que apoyen la comunicacién, colaboracin y coordinacién del equipo de trabajo, con Ja herramionta de gestion de requerimientos.Capitulo V=Resultados 511 Objetvos vs Resultados: SibI Disefiar ¢ implementar una herramienta web, que permita la gestién de requerimiemos: Este objetivo no es més que la herramicnta web en su totalidad, La herramienta esti disefiada para permitir a los usuarios la gestion de requerimientos de un proyecto basado en metodologia Open UP; ademas posee un mecanismo de integracién con el procesador de texto OpenOffice Writer, a fin de poder exportar la documentacién generada (Vision del Proyecto, Requerimientos del sistema, Glosario) desde la herramienta que es necesaria para cualquier proyecto de Open UP. Igualmente esta integrada con la herramienta de gestién de eambio GCRS, Permitiendo a los usuarios observar los cambios generados. La hetramienta esté soportada por una base de datos relacional, donde se almacenan los datos de los distintos niveles de requerimientos y sus respectivas atributos, Ademas otro punto importante que debe mantenerse en la gestion de requerimientos, es la trazabilidad, para proporcionar la relacién entre los distintos niveles de requerimientos de un proyecto; la herramienta refleja la trazabilidad entre requerimientos, a través de una matriz, que permite a los usuarios comprobar gue se cumplen con todos los requisitos del proyecto, verificar que se han creado los requerimientos necesarios para cumplir las necesidades del cliente y ayudar con la gestidn de cambio dentro del proyecto, mostrando cuales requisites fueron modificados no poseen aprobacién. La herramienta fue desarrollada en PHP version 5.2.6 y la base de datos que la soporta esta creada bajo el manejador MySQL versisn $.0.51b; tambiénse desarrollaron componentes de AJAX y Javascript para lograr una herramienta interactiva y con mayor velocidad. 5.1.2_Diseftar y construir una base de datos relacional, para centralizar los distintos tipos de requerimientos y sus atributos: Para cumplir con este objetivo fue ereado un modelo entidad ~ relacién con ayuda de herramientas CASE, con el fin de reflejar todas las entidades, relaciones y restricciones necesarias para soportar la gestién de requerimientos segiin las normas que cstablece la metodologia Open UP. El modelo de datos disefiado para soportar la gestién de requerimientos, fue normalizado hasta la tercera forma normal, es deeir, que todos los, atributos son atémicos, existen claves primaria, no hay dependencias parciales, ningin atributo forma parte de ninguna clave porque dependen directamente y no tansitivamente de la clave primaria, Ademds fueron ereados indices, que nos ayuda a obtener datos de las “tablas” creadas en forma mis répida, porque sin un indice el manejador de base de datos debe leer a través de todas los registros de las tablas para localizar Ia informacién deseada; con la utilizacién de indices, el mangjador de base de datos puede entonces dirigirse primero a los registros indexados agilizando la busqueda, La base de datos creada que soporta la herramienta est constituida por eatorce (14) tablas relacionadas, en MySQL. versién 5.0.51b (Modelo dp. F y script en el Ap. C.8). 5.1.3 Diseftar ¢ implementar las_interfaces web necesarias para la gestién de requcrimientos:Capitulo V-Resultades Este objetivo fue alcanzado con Ia creacién de todas las paginas web que conforman la herramienta de gestién de requerimientos, para esto se hizo uso del lenguaje HTML que permite definir la estructura y seméntica del contenido y de CSS (Hojas de estilo en cascada) que define la presentacién (colores, fixentes, fondos, tamaiio de fuentes, etc.) , Estas interfaces web (péginas web) permiten al usuario trabajar con la hhorramienta para gestionar todos los niveles de requerimientos(caracteristicas, requerimiento y casos de uso) de forma interactiva y ripida, mediante cl componente desarrollado de AJAX, que permiten actualizar fragmento de una pagina sin recargarla completamente; también se utilia6 el componente de Javascript que permite hacer validaciones directamente en el cliente, sin necesidad de Megar hasta el servidor, permitiendo de esta manera reducir el tréfico en Ia red y tiempo de ejecucién, Las piginas fueron desarrolladas manteniendo un estindar de disefto a través de los estilos CSS. Ademis fue verificada la compatibilidad Cross-Browser para todas las piiginas creadas. 5.4 Desarrollar un médulo de administracién para la herramienta web que permita asociar a los proyectos con los usuarios: Este objetivo fue alcanzado mediante el desarrollo de un componente de eédigo, que permite asociar a los usuarios registrados en la herramienta web con los proyectos cereados, segiin los roles de trabajo de la metodologia Open UP. Este componente permite validar el acceso y los privilegios de los usuarios en la herramienta, segin el rol ‘ocupado en el proyecto. La asociacién usuario-proyecto puede efectuarse al erear unCapitulo V Resultados rmuevo proyecto 0 al gestionar uno existente. Ademas se permite incluir o excluir usuarios al equipo de trabajo, como también modificar el rol que ocupan dentro det proyecto. A continuacién un resumen de los roles y artefactos que puede modificar: 2 ee Der 7 ior Ra Tr Dare van ae ‘joy nest dear + inenemam ‘eat Raermen Bitsy ii ncn 2 tlesd eet dea, 2 bynneter areca oe 7 Ta a 7 ae Fa Taipei Taiaroaas epee eperon Spry Igor lone, ‘Taba & Rates y prilegias de Open UFCapitulo V-Resultados 5.15 Diseiar y desarrollar un mecanismo para la imegracién de una herramienta software libre que genere documentos con_la_herramienta_de_gestiin de requerimientos, reflejando los requerimientos almacenados en la base de datos: Este objetivo fue aleanzado con Ia ereacién de un componente de cédigo, que permite integrar la herramienta web con el procesador de texto OpenOffice Writer, Este componente hace uso de la libreria ODF y de unas plantillas creadas en Open Office Writer para generar los documentos. Este componente extrac Ia informacién necesaria (datos, nombre de 1a plantilla ereada en OpenOffice Writer) del modelo de datos para crear el documento por medio de la liberia ODF la cual erea un documento XML con la informacion necesaria para que pueda ser interpretado por OpenOffice Writer para su ‘manipulacién 5.1.6 Disefiar y desarrollar un mecanismo para la integraciin de vienta de cddigo abjerto para la gestién de cartbios en los requerimientos, con la herramienta de gestién. imientos: Este objetivo fue aleanzado con la ereacién de un componente de eédigo, que permite integrar Ia herramienta web con la herramienta de gestién de cambios en requerimientos de software GCRS. Este componente extrae la informacién necesaria a través de la capa de persistencia para que GCRS genere una lista con todos los cambios realizados en los distintos niveles de requerimientos, los usuarios que efectuaron éstos, cambios y la fecha de modificacién, también brinda a los usuarios la oportunidad depitulo V-Resultados aprobar dichos cambios. La lista generada ésta organizada por los proyectos creados desde la herramienta web. S.L7 Disetur y desarroliar un mecanivmo para la integracién de aplicaciones de Ingenie ycial_ que apoyen ta comunicacién, colaboracit inacién del eauipo de trabajo, con la herramienta de gestién de requerimientos: Este objetivo pudo ser aleanzado mediante el desarrollo de componentes de cédigo y paginas web. Estas paginas desarrolladas con el uso de HTML, CCS (hojas de estilo en cascada), ATAX y Javascript, permite a los usuarios crear comentarios en ‘cualquier nivel de requerimiento, Con estos comentarios se offece al equipo del proyecto tun mecanismo para realizar todo tipo de observaciones, adems de establecer un medio de comunicacién, colaboracién y coordinacién durante el ciclo de vida del proyecto, La metifora de estos comentarios se basa en dos ideas principales: rapidez y colaboracién, Rapidez puesto que es sencillo generar el comentario y Colaboracién porque los usuarios intercambian mensajes que les permitan aclarar dudas sobre cualquier requerimiento segiin su nivel. El equipo del proyecto puede acceder a los comentarios a través de su nivel de requerimiento, donde son mostrados con su deseripeién y usuario que lo ores.Capitulo VT Conclusiones y Recomendaciones iin Preltninar 6.2 Objetivos vs Resultados. 6.1.1 DiseRar e tmplementar una herramienta web, que permita la gest de rquermients, m= 6:42 Diver ycnsiuiruna base de datos relacona, para sl oresente cuniraizar ts stints tis de requerimienosy sus mle arias, ‘ec r 61.3 Disenar e implementar las interfaces web necesarias para la -conelusiones ‘gestin de requcriientas, nian 6.4 Deserollar un mda de adinsacion par a freoer herramienta web ave permita aso a as proyectos im com lo usuarios tipi 6.1.5 Diehary desaroltar un mecantsmo para ta tcgraciin | S28 i una herraenta sofware He que goneredocurentos crit con la hervamienta de gestidn de requerimientas, ae refejand os requerimientasalmacenadosen ta based 7 des 6.1.6 Disefar y desarrollar un mecanismo para la integraciin de wna hherramienta de céidigo abierto para ta gestién de cambios en tos requerimientas, con la herramtenta de gestion de requerimientas. 6.1.7 Disenar y desarroliar un mecanismo para la integracién de aplicaciones de Ingenieria Social que apoyen la comunicacién, coluboracién y coardinacién det equipo de trabajo, con Ia herramienta de gestion de requerimientos. 6.2 Recomendaciones.Capitulo Vi=Conctusiones y Recomendaciones 6.1 Objerivos vs Conelusiones: 6.1.1 Disehar ¢ implementar una herramienta web, que permita la gestiin de requerimientos: Independientemente de la metodologia que se elija para el desarrollo de un proyecto de software, la etapa mas importante es la definicién de requerimientos, ya que ésta determina en gran parte las necesidades que el sistema debe cumplir. Sin embargo durante el desarrollo del proyecto, estos requerimi os pueden ir cambiando para adaptarse a las necesidades de los usuarios, por esta razén fue creada una herramienta ‘web que permite gestionar todos los requerimientos de un proyecto durante el ciclo de vida de su desarrollo bajo metodologia Open UP. Ademis de la gestién de requerimientos, éta herramienta permite al equipo del proyecto observar la trazabilidad centre los niveles de requerimientos, los cambios efectuados a través de una herramienta de gestién de cambios en requerimientos, generar los documentos exigidos por la metodologia y permite Ia colaboracién a través de comentarios entre los miembros del ‘equipo, ayudando a la toma de decisiones dentro del proyecto. Debido a que es una hherramienta web el equipo de trabajo posee Ia oportunidad de interactuar a través de la red, teniendo una visidn general de todos los niveles de requerimientos dentro de un proyecto, ya que trabajan sobre una base de datos eentralizada, evitando ambigtiedades y redundancias de informacion, 6.1.2 Disefiar y construir una base de datos relacional, para centralizar los distintostala Vi -Conelusio ne tipos de requerimientos y sus atributos La creacién de una base de datos relacional le otorga flexibilidad a los datos almacenados, de forma tal, que éstos puedan utilizarse con distintos fines, ya que al estar todos los datos integrados se puede extraer informacién adicional sobre los mismos. ‘Ademés se reduce el riesgo de que se presenten inconsistencias, porque si un dato esté almacenado wna vez cualquier actualizaciin se debe realizar sélo una vez y esti disponible para todos los usuarios inmediatamente. Una ventaja en la creacién de la base de datos relacional, es que ésta mantiene la validez y consistencia en los datos almacenados, mediante restricciones o reglas que no se pueden violar y pueden ser aplicadas tanto a los datos como a las relaciones. Asimismo los usuarios pueden acceder simultineamente a la misma informacién, sin que el acceso interfiera entre ellos. 6.1.3 Disefiar e implememar las interfaces web necesarias para la gestiin de requerimientos: Las interfaces web contienen elementos que permiten una comunicacién activa ‘entre los usuarios y la informacién almacenada en la base de datos, La creacién de estas jerfuces web permite a los usuarios acceder de forma interactiva a la informacién, ya que no es necesario recargar las paginas para responder a cada una de las acciones gjecutadas, esto es posible gracias a Ia uilizacién de una téenica de desarrollo web como AJAX que utiliza una combinacion de varias tecnologias, 6.14 Desarrollar un médulo de administracién para la herramienta web que permitaCapitulo Vi-Conctusiones y Recomendaciones asociar a los proyectos con [os usuarios: Un aspecto importante de cualquier sistema de gestién es la seguridad de la informacién que se maneja, esa seguridad se puede garantizar a partir de la concesién de permisos para controlar que usuarios deben tener acceso a parte o a toda la informacion ¥ quiénes no. La creacién de éste modulo, permite ta asociacién usuarios ~ proyectos basado en los roles de Ia metodologia Open UP, para determinar que acciones pueden los usuarios llevar a cabo dentro de la herramienta. 6.1.5 Disenar y desarrollar un mecanismo para la integracit ina herramiema Software libre que genere documemos con la herramienta_de_gestiin de requerimientos, reflejando los requerimientos almacenados en Ia base de datos: Los documentos que se deben generar en la metodologia Open UP forman parte del conjunto de artefactos © entregables a la hora de consirur un sistema, Los antefactos correspondientes a la gestién de requerimientos no son mis que productos tangibles que ayudan a la descripeién de funciones, arquitectura y disefio del sistema. Debido a que son productos tangibles se debe permitir a los usuarios generar éstos artefactos desde la herramienta web, esto es posible con la integracién de la herramienta y el procesador de texto OpenOifice Writer, integracién que se logré con el uso de libretias, extensiones del lenguaje de desarrollo (ODF, ZIP - PHP) y con archivos XME que permiten la flexibilidad necesaria para la generacién de documentos entre la herramienta y el procesador de textoCapitulo Vi -Conclusiones y Recomendaciones 6.1.6 Disehar y desarvollar un mecanismo para la integracién de una herramienta de cédigo abierto para la gestién de cambios en los requerimientos, con la herramienta de gestién de requerimientas: EI cambio es inevitable cuando se construye un software, los requerimientos forman parte de la base en el desarrollo de un sistema y también pueden cambiar, la gestién de cambio en tos requ 0s es muy importante porque permite identificar, controlar, auditar ¢ informar al equipo de trabajo las modificaciones que invariablemente pueden ocurrir durante el proceso de desarrollo del software. Un proceso de gestién de cambio de requerimientos proporciona un rastreo completo y preciso de todos los cambios que son pertinentes al proyecto, 6.1.7 Diseiar y desarrollar un mecanismo para la integracién de aplicaciones de Ingenieria Social que apoven la comunicacién, colaboraciin y coordinacién del equipo de trabajo, con la herramicma de gestién de requerimientos: La comunicacién dentro de un proyecto es de vital importaneia, a fin de ‘mantener acuerdos y toma de decisiones durante su ejecueién. La ereaeién de un medio para la comunicacion dentro de la herramienta web, offece la libertad a los usuarios a ‘través de una interfaz simple, de realizar comentarios y expresar opiniones o dudas sobre cada uno de los niveles de requerimientos dentro del proyecto.Capitulo Vi-Conciusiones y Recomendaciones 6.2 Recomendaciones: En esta seccién se presenta algunas mejoras que pueden realizarse a la herramicnta ‘web desarrollada como Trabajo Especial de Grado: ‘© Implementar un médulo que permita a Ios usuarios realizar modelado UML (Unified Modeling Language) dentro de la herramicnta. © Integrar Ia berramienta web con una hetramienta de cédigo abierto para pruebas de software, permitiendo definir casos de prueba para cada uno de los niveles de requerimientos creados a partir de la herramienta web. ‘© Integrar la herramienta web con una herramienta de eédigo abierto para el control de versiones que permita regresar a estados anteriores (deshacer cambios) en los distintos niveles de requerimientos. © Disciiar y desarvollar un mecanismo para que la herramienta sea configurable ¥ pueda trabajar con mancjadores distintos a MySQL. ‘© Utilizar grificos interactivos en los casos que sean adecuados a fin de mejorar a usabilidad de la herramienta © Permitir que la herramienta gestione requerimientos para metodologias distintas a Open UP. ‘© Incluir un médulo en Ja herramienta web que permita configurar el idioma ex las interfaces, datos almacenados y artefactos generados,Incluir un médulo en la herramienta web que permita asignar cuentas de correo electrinico a los usuarios registrados, con el fin de recibir notificaciones cada vez que ocurra un cambio en cualquier nivel de requerimientos,Referencias Bibliogrdficas fine. ‘A continuacién se presenta al lector todos los textos, documentos, paginas web y lugares de interés que permitieron obtener parte de los ‘conocimientos e informacién necesaria para desarrollo de éste Trabajo Especial de Grado.Referencias Bibliogriticas [1] Beck, K. (2000). Extreme Programming Explained: Embrace Change. Estados Unidos de América. Addison-Wesley. [2] CMU (Camegie Mellon University). SEI (Software Engineering Institute) (2006). CMMI for Development, Versién 1.2 CMMI-DEV CMU/SEL. [En linea] Disponible en: hanJ/vww sei cmy.edu/publications/documents [Mayo 2008]. [3] Deek, F; MeHugh, J; Eljarabi O. (2005) Strategic Software Engineering, Estados Unidos de América: Auerbach Publications. Taylor & Francis Group. [4] Extreme Programming: A gentle introduction, [En linea}. Disponible en: hupy/www.extremeprogramming.or 5] Galitz W. (2007). The Essential Guide to User Interface Design An Introduction to GUI Design Principles and Techniques. Estados Unidos de América: Wiley Publishing, Inc [6] Herramientas CASE. Instituto Nacional de estadistica ¢ informatica Pert (1999). [En linea) Disponible en: http://www innovavirtualorg 17] Intemational Institute of Business Analysis. (En linea] Disponible en: htepu/www.theiiba.org [8] Introduction to Open UP. [En linea] Disponible en: hitp:/epfeclipse.orw/openun! {9] Introduction to XP. [En linea]. Disponible en: htip:/epf-eclipse.ora’xp!Referencias Bibtoariticas [10] 180 9000:2000. (En linea} Disponible en: hitpv/vww.iso.org [11] Jacobson, L., Booch, G., Rumbaugh, J (2000). £1 Proceso unificado de desarrollo de software, Madrid: Addison Wesley. [12] Jorge Ferrer Zarzuela. Metodologias Agiles, (En linea). Disponible en: |hitp:/libresoft.es [13] Jefities, R. (2001). {Qué es eXtreme Programming? [En linea] Disponible en: ‘hutpy/avww.xprogramming.com [14] Leffingwell, Dean. Managing Software Requirement. Addison Wesley [15} Palacios, J. (2006). Sinopsis del modelo CMMI, [Ba linea]. Disponible en: http://www navegapolis.net [16] Richter, K (2008), CMMI for Acquisition (CMMI — ACQ) Version 1.2 CMUISEL. [En linea) Disponible en: hitp/Avww.sei,emu.edtvpublications/documents [Mayo 2008] 117] SEI. What is CMMI”, [En linea}. Disponible en; http/svww.sei.cmu.edulemmid [18] Weitzenfeld, A (2005) Ingenieria de Software Orientada a Objetos con UML, JAVA ¢ INTERNET. México: Thomson [19] Zielezynski, P., Ph. D (2007). Requirements Management. Estados Ut Education,Apéndices QVisiin Prebiminar Apéndice A, Historias de Usuario Apéndice B, Plantilas, Bl. Documento de Vision. B.2, Documentos de Requerimiontos del sistema. A continuacién B3. Cases de Uso. se presenta al [Be Historias de Usuario. lesion informacion Apéndice C. Componentes de Céidigo. vinculada al CL Componentes para la capa de persistencia. Sesurrolicde este Trabajo C2, AMLHt@pRequest. Especial de Grado. Como C3.AAX ae plantilias Cot JAVASCRIPT, utlizadas, algunos C5, Componentes para la capa de Negocio, ponents para Ta apa ie NG aspectos de C8. ODF. diseno, pruebas, documentacién. C7. Mecanismo de integracién PHP - OpenOffice Writer C8 Seript de la Base de Datos. Apéndice D. Roles en Open UP y CMMI Dil. Roles on Open UP. 1.2. Integracion det modelo de madurez de capactdades (CMM, Apéndice E. Pruebas, Apéndice F. Modelo Entidad ~ Retacion. Apéndice G. Manual de Usuario.Apéndice A — Historias de Usuario: Nimero: | ‘Usuario: Eguipo proyecto ‘Modificacin de Historia Nimero: Prioridad en Negoen: Alta Puntos Fatimado (Atta Media Baja) ‘Riesgo en Desarrollo: Alle Puntos Reales (Alto Medio/ Bajo) Desripeiin Se ntedusen los datos de usuario (nombre, usuario, coorasla, pregunta y respuesta seer). Se debe ‘adr i informacn y enviar abuse de dios, pars rare reir del usr ‘Observaciones: ‘Némeroe2 ‘Nombre: Crear Proyecto “Usuario: Equipo proyecto “Modificacin de Historia Namerar Prioridad en Negocio: Alta Pontos Hatiadose (Sita Media Baja) lesgo en Desarrollo: Alls Puntos Reales: {(slto! Medios Bajo) Deserpe Se debe ingresar a la heramienta(previamente reaizar aucnicacin de usuario) solictar nombre y escripein dl proyecto, ademas se debe cloyir los usuarios que formaran el equipo del proyeco Indicando su rol dono del mismo, La hewamienta debe reisatIa informacion ola base de diss, y ‘be crear los pugucteshiscos de proyest (Vision y Carteterisea, Requerimicnos dl Sistema, Cass eso, lostnoy Wit) _ “Observacions: Pomiti asigiar usr al proyato co la isa pagina web, Poseriormentseargar tod Ja informacin bien de proyest.‘Ndmero: 3 ‘Nombre: Crear Carterisicae ‘Usuario: Equipo proves ‘Modiicacin de Historia Nomero: Prioridad en Neyoeio: Alia Panton Eximadane (Alta/ Media Baja) ‘iesgo en Desarrollo: Ale Panton Reales (Alt! Medi Bajo) eseripcion: Se debe ingresar« ls herramienta (prevismente reine autentcaciin de usuaro) en un proyet ‘eka Crear Carceristc, granada la informacion necesara (nombre, deseipeia, tp, paauete de Ubieacién, orien, estas, riesgo, esabilidad, difcultad, prioridd,iterciones plniiewss, steacén Sota, peo contact, alguna solicit de jor, deft, obsolta)yropsta la earacterstica eno ropes y pagusteseleceonado, ‘Observaciones: EI paguete por delecto dande se almacenarl las casterisieas de-un proyecto seri en Visi y (Caruetrscs sin embargo pucde ser almacenado ca oo paquete cad pore usuario previaments- EL tipo de carctersica sen (Funcional, Usablidad, Fiabilidad, Rendimiento, Restrceiin de. disso, Resuerimienlo de aplieeisn, Requerimient Sica, Requrimicats de imerfar, Sopore). Hl arigen (Cienes, Socios, Competencis, Ustaro Final, Help Bes) El extatus (Aprobad,incorporado, Vala, Proyecto, Rlesgo (Calendario (Alto), Calendario (Medio), Calendario (Bajo), Teenologit (Alta) “Tecnologia (Meso), Teesologia (Bao). Estabilidad, difcatady priovidad (Ala, Media, Baja) 2 aaa 4 ‘Nombre: Crear el ‘Usuario: Eauipo proyecto “Moaifcalin de Historia Nama Prioridad en Negocio: Alta (Al / Media aja) ‘iesgo en Desarrollo: Ale ‘Ako/ Media Bajo) Deseripein: Se debe ingress a a heramiena(previamens realizar autenicaidn de usuario) en un proyecto, AL Solisitar Crear Requeimienos, ingest toda I informacion necesaria (nombre, deepen, ipo, page de ubieseibn, carcteistea ovger, slau, riesgo, estbildad, dicultad, prioridad, teracones Pluniiadas, eractbn acta, persona contacto alguna solicit de majors defeeo,obsoeto) y registrar 1 roquericnto et el proyeiay paquets selesionad ‘Opservacionest El paquste por defecto donde se almacenari los roqerimienos de wn proyecto seri en Requriients del sistema; sin erbarpo puede ser alracenao en oo poguete creado pu l usuario peviameme EL tipo de requerimientos son (Funcional y No Funcional. Fl origen (Se debe lstar tod ls earacteristens fered en el proyecio), Riesgo (Calendario (Alto), Calendao (Medio), Calendario (Bajo), Tecnologia (to), Teenologi (Medio), Tesologia (Bajo) Estabilidad, aiieultad y riordad (Alia, Media 3).Apéndices - Apéndice ‘Nombre: Crear Caso de Uso Prioridad en Negocio: Alta Puntos Fstimadost (sla Media/ Baja) Rlesgo en Desarrolor Aa Puntos Reales: Alto / Meo Bajo) Deserielin: Se debe ingressr a ls heranient (povimente realizar sutencacin de wsaro) ex un proyecto, Al ‘olieiae Crear Casos de Uso, ingresir toda ta informacin necesria (nombre, descrieién actores, pre ondicionss, pst condiciones, Fuj hisico de events, sub Mus, requeimintos especiales, escomiios claves), pagucte de ubicacon, requermicoto igen, esas, ego, eslabiidad, diultad, prordad, “teracionesplanificada, iractn deta, persona conta) y regatar el cao de en ol proyecto y uote slecionao. ‘Observaciones: El paquets por dels donde se almacenad os casos de uso de un proyecto sord eo ‘Caso de Uso sit embargo puce sr almacenalo en obo paquets crea por el uaa previament, Los Mujos, sub Majo, escenaros claves deden poder cease dininicamaie. Estabilidad, difeutad y prlordad (Ata, Ndi Ba, eS ‘Nombre: Cres Tero ‘Modifeacin de Historia Nimo Prioridad en Negocio: Media Puntos atmadane (Atta Media Baja) ‘Riesgo en Desarrollo: Medio Puntos Reales (Alto Medio Bajo) Deseripeién Se debe ingresar a la enamienta(presiamente realizar auentcacién de usvrio) en un proyecto, Al solietae Crear Témino, ingresar toda a informacion necesria (nombre, deveripesa, pagiste de bicacin reztrar el trmino en el proyetoy pagut scleseionado, ‘Observactones: El paguete por deteeto donde e aimacenuri los trminos dl proyecto ser eo Glosro; sin mbugo puede ser alnacenado en ox paguete read por el usuario previaments Oqqge os ance ‘Nombre: Crear Contentarin Usuarios Fauipo proyecto Modem de Historia Namen Priordad en Negocior Alia Pasion Evins Alta / Mes / Ba) ‘Resgo en Desurolio; Ao Parton Reales (Slta/ Medio! Bajo) Deseripeiin Se debs ingresar ala heranicnta (peviamente realizar auticacion de usuario) ex un proyecto, Al Solita Crear Comentario, seleccions a earctestica,equeimientoo caso de uso a cometary, ingresi ‘a informacion pertnent (titulo y crtenari) yautomaticamentedeban ser amaccnaos ono proyect, col pagus Wiki son su lasifee (carters, requermieno, ce 0). ‘Observicones:‘Nombre: Cres Pagute anos Enimados Puntos Reals (sito Medio Bajo) Deseripeion: Se debe ingresar« ls lemamiena(orevamimte celzarsuteeacién de usuario) ex un proyecto, Al soliciar Crear Paguess, nares ods [animacion ncesara (oombre, descripeon), re)strar el pate shel pect, ‘Observacion a Usuario Equipe poyeso ‘Modifcaciin de Historia Nimaro= Prioridad en Negocio: Alte Pontos Estimadon (Atta Media Baja) ‘Riesgo en Desarrollo: Ala Pontos Reales! (Alto Medio / Bajo) fi Deseripelim ‘Sernroducen los datos ds usvario (proyecto, nombre de usuario y clave) Se debe realizar una bisgueds tla base de dats, para validar los datos introduids, y de er corecos, buscar ods la informacion ds proyecto permit el acceso. ison incrrevts enviar un mensje de notieaein de error. ‘Nombre: Crear issn, Mdifieaein de istoria Nimeroe Prioridad en Negocio: Alto Puntos Eamadane (Alta / Media / Baja) ‘Resgo en Desarrolioy A Panton Reais (Alt! Medio Bajo) Deseripsién: Peril al usuario wear & documonio de visiba el prayeslo reisrando Togs Ta Informacién del proyecto inroduecién, el problema, el product, involuerado) ae deben Ist tods as carnctrscas y requrmientos dl proves [eens Cs caeteiny eines ia EiseniaNimero: 1 ‘Nombre: Consular Caracteisticas ‘auario: Fquipo proyecto ‘Moudifieacon de Historia Nimer Prioridad en Negoeo: Media Pentos Estimadr (Alta Media Baa) ‘Risgo en Desarollo: Meio Pantor Reales (Alto Medio Bajo) Deseripcin: star todas ls craters y pet l usuario eealzar la medifcain de a informacin bisica de niques de forma pid yefiienle ene oor tempo posible 0 poder supe el proyecto ‘Onservaciones: Ai imimir ina caracterisica se ube eiinar dos los requeinientos asoctados a lay toda i invormacién rlacionada, ‘Nombre: Consult Requsimicnos Prioridad en Negocio: Media Pantor Estar (Sita Media Baja) Rlesgo en Desarrollo Nido Pontos Re (sito! Medio Bajo) _sualguier de forms rigid y elem on omen empo pos surimiras dl proyeto ‘Observaciones: Ai eliminir un requentieno se debe eliminar todos los cass de uso asocadas 8 ly toda informacion flacionada Nimero: 13 "Nombre: Consular C3808 de so Unvaries Equipo proyenta ‘Moudlfeaciin de Historia Nimerr Prioridad en Negoeio: Media Puntos Extnadane (Aka / Media Bafa) ‘Resgo en Desarrollo; Meio Puntos Reales List todas fos casos de soy parmitir al suai realizar la modifeaién de i informasin bisa de piers deforma ipa y efclente en el meno et ia ies dt ‘Observaciones: Al iminar un Caso de usa se debe elminsr ted lo informacin 0 elementos asia aAvéndices — Apéndice A Numero: 14 ‘Nombre: Cousular Teno Usuarios Equipo pea ‘Mosfcacon de Historia Namero= Prioridad en Negoeio: Media Pantos Hatimados: (Alta / Media Bala) ‘Resgo en Desarrollo Mio Puntos Reales (alto Medio Bajo) co List cds lo mines erendos en un royssto de forma rid ‘Observaciones: efiiene Tsk de Usa ‘Namero: 15 ‘Nombre: Eline Comentino ‘Usuario: Equipo proyecto ‘Mediicacin de Historia Nero: Prioridad en Negoeo: Media anios Estados Ata / Medina) ‘Riesgo en Desarrollo Medio ‘Pantos Reales (stto/ Medi aj) Deseripcion: Lint todo os comentarios y penta ususro elimina oe comentarios creado por 6 ‘Observaciones: El usuario sole puede elimina sus cometros, cc eamemenns =" perv eemmemm| ‘Unuari: Equipo propeao ‘Modificacin de Historia Nomero: Prioridad en Negocio: Media (Aiea Media Bs) Riesgo en Desarrollo: aio ‘Aito/ Medio Bajo) Ramee Taabnded Crateien-Keveristie Usuario: Egupopaeo Modicacin de Historia Nmerar Frioridad ex Rept Ala (es Mesias) Rigo en DesraleAls (its sted a) Desipele Penni a wtorio vein a tabled eae os casein equsimisey, cule ‘moses gue ne pce em elon debe serra om ina de mess. peiton tua spb lox canoe Otearcin Se debe represenar ls tazabilidad a waves de una maizAvéndices — Apéndice ‘Nimero: 15 ‘Nombre: Madiise Vision {Usuarlo:Eauipo proves ‘Medifgacion de Historia Namero: Prioridad en Negocio: Medi (Alta Mela Baja) ‘esgo en Desarrollo Medio (Sito Mealo Bajo) Deseripei Permit a usuario modifcar el documento de viséa del proyeco en cuslguier momento dese la haramicata we Usuario: Equipo payeio ‘Modifieacin de Historia Némero= Prioridad en Neguelo: Media Puntos Estimadose ‘Alta / Media Baja) ‘Reso en Desarrollo? Sicdio Puntos Reales (Alto Medio / Bajo) Deseripeo emir al usuario realizar la medicaid de i informacin bisica de cualquiera de forma ripide y sficente ent minor tiempo posible, a trvés de una lista genera, Tambicn se debe permit wodiiae toda informacion aves de una consulta persoalizada. ‘Opservactanes: Mostar toda la informusin dela suratersuea oo Tos campos del lerlario, una vez sunric ela la open de modifier. ‘Nombre: Modiicar Requeimientos ‘Usuarios Equipo progeaa Msifieacisn de storia Nimeror Prioridad en Negocio: Nicdia Puntos Estima (Alta! Media Baja) ‘Resgo en Desarrollo: Mio Puntos Reales (Alto Medios Hao) Deseripeé Permit a usuario rauliar la modifcucidn de la ingormacién bisiea de cualquier de forma epida y ficients en el menor tiempo posible, a través de ns lista general. Tambiln se debe perme moaliear {dal informacion a waves de usa consulta persaalizada ‘Observactones: Mostar toda a informacion del requcrmicno ep fos caripos dl ormulai, un Vez 6) sua ej lope de moda,snd Medificr Casos de Uso ‘Nimere: 21 ‘om ‘Usuario: Equipo proves, “Moaificaein de Historia Namaros Prioridad en Negocio: Meda Puntos Estimadane (Alta Media Baja) Rlexgo en Desarval {Alto/ Medio Bajo) Deseripes Permit al usuario realizar la modifcaion de (a informacinbisica de cuslauicr deforma ripida y fcente en el mieior demo posible, a waves dean Ista general. También se debe permite odiicat {oa a nformacton ata de una consul persed ‘Observaciones: Mostar tous a informacin del caso de wo alos sarpos del formlarioy waa =z e sesuaro eli a open de media Puntos Reales ‘Usuario: Equipo pope “Modificain de Historia Name Prioridad en Negocio: Media anion Esimadose (a Media Baja) iesgo en Desarrollo edo ‘Puntos Raters ‘Sito! Medio Bajo) Deseripein| Poni al usuario liza le modifenién dea informasia bsica de cuaigle nino de forma rida 1 ficients on el menor tempo posible, a avés de una lista general, Tumba se debe permitir modiicar toda a informacion a ras de una coms persnalizads. ‘Observaciones: Mostar la descipion dl trmino eno easpo del formula, una ver el suas elja a pein de modifier AEN Namero: 25, ‘Nombre: Modifica Paguee Usuario: Fauipe poyeso Mosfeacin de Historia Nimero= Priordad 7 Puntos Estima (ts | Mes Ba [Reso en Desarrollo Nadia Puntos Reales (Alta) Medio Bajo Deseripeibn Pent al usuario realizar ls meilicackin de I infrmasin bisiex de los paquctescreados por alls dent de un proyecto Si i ‘Observaclones: oswar fz GesoripeGn del Wri el canpo dal Tamlaio, una ver el wsuaro alfa Jw opcon de modifies. No se debe perm la modiicaién de pagutes eeados por defecte demu de uo proyecto (Visi y Crscteriicas, Requermientos del Sitea, Casos de Uso), fico AApindices — Apéndice A ‘ame: 24 Nombre! Tesi Rogucrimientss Cass Uo ‘Usuario Modifeacien de Haters Nias Prneiad ex Noocts: AS ‘Puntos Einar (lt din) ‘leg em Dsara: Ai Panta Reales (le Meda Bs) Deseripeie Perit suo vere bari ewe Ios tqueientsy cso de wo, cng rain que se ls dab se json tr de waa, permed ali pons cans ‘Observacons: Se debe ese I abled en ‘Namero: 25 ‘Nombre: Dos. Visin ‘Usuario: Eauipo proves ‘Modificacin de storia Nomeror PHoridad en Negocios Miia Puntos Estado (Atta Medi Baja) Riesgo en Desarrollo: Meio Pantor Reales {Alto Medi Bajo) Dscripcion: Peni al usuario export el documento de visién a una hermits de ciigo abiento para crear ‘Observacioncs: Namen: 26 ‘Nombre: Crea documon de Reguriienos det Sistem “Usuario: Equipo proves Mosifiecion de Historia Nome Prioridad en Negocio: Altz Puntos tia Puntos Reales (ito Medio aj), Descriptio Parmit al usuario crear el document de rajueienos del sistema reistando la infrmacién necesua (introduce, roqurimiemton caida, strive, rel, imiacone, lees, documentacin) se deben ‘Observacones: Los foquerimionis del sitema = dab sur automat Historia de Unis ‘Nombre Eiminar Carters ‘Usuario: Equipo proyecto “Meulifcacién de Mistorta Nimeroz Prioridad en Negocios Masi Panos Eta Panos Reale Deseripeiin: Liste tos ls caractrstcasy peril wari cimina as caractristieas de un proyecto (Observaciones: AI clininar ane cactus se debe eminar os Is requires sioeados lay tla informa resionala, Se date ocr corimasin al yuna asd imma uns craters.Apéndices — Apéndice £ ‘Nimero: 28 ‘Nombre: Eliminar Reguerinienos Usuarios Equipo proyecto Mouifecisn de Historia Nameror ioridad en Negocio: Media Panios Estimadose {Alka / Media /Bajs) Rigsgo en Desarroli: Meo Puntos Rear {Alto Medio Bajo) Deseripein: Lista todos los requrimienosy pent al wuaro elimina supimils del proyeat. ‘Observaciones: Al climinar un requerimieno se debe climinartados los casos de uso asocados 0 toda’ lz informacién relssionada, Se debe soliciar confrmacion al usar aes de climinae uh requir, Namero: 29 ‘Nombre: Eminae Caos de Uso ‘Usuario: Eauipo proyecto ‘Maslifieaiin de Historia Name Teraelén Asgnada Prioridad en Negocio: Niedia Puntos Estados (le! Media Baja) lesgo en Desarrollo Neda Pantoy Reales (Alt! Medio Bajo) Deseripein Listar tas lon casos de so iminarios de nar un caso de uso se debe supimi oda a informacion y elementos Faulonads ig confreién al usuario anus de elimina. CA ‘Namera: 30, ‘Nombre Himinar Termin | Usuario Equipo proyesi Moulifieacidn de Historia Nimerom Prioridad en Negocio: Media Puntos Esinados (Alt! Med Baja) ‘iesgo en Desarro {Alto Medio Bajo) Deseripei starts los rminosy permite a usuario eiminarlos dl proyet, ‘Observaciones: A elimina un imino se debe slit confinnacion al urs anes realizar In ace, Wiedio Puntos Reale Name: Einar Pi ‘Moudlfieacin de Historia Niimeroz Prioridad en Negocio: Mia anos Estados (Ala Media Baja) Riesgo en Desarrollo: Meio unto ele (Alto Medio B Deseripsi |_Permir imina os paguetes creas por os usuarios. ‘Observaciones: Al climinar un paquee se debe solicit confrnacion af wuaro anes earl acsi0ny climinar odo ls elementos qe eottiens,Avénio ‘Numer! 32 ‘Nombre: Ose loans Usanre: Equa r= Moding de Hnteri NES Prvedad em Negocio Mais {ata Mea Boj) gp ea Desa aio (Ato Mea Ba) Des Pest sur Yer tas os mins rete el royce y ode xt dace deel em era eg bene, Numero: 33 ‘Nombrer Modifier documento de Requerimients del Sistem. ‘Unvaria: Equipo proyecta ‘Modificacin de Historia Nimero:Tteraciin Asignada 1 Prioridad en Negocio: Media Puntos Extimados (Alta Media Baja) iesgo en Desarrollo Medio Puntos Reales: (3! Medio Bajo) ‘Deseripeion: Permiura los usaris wodicar a dosumisio de rquarinisies dl Sistem peanesioie al pays. Observacione ae ‘Usuario: Equipo peyeata Moslfcacon de Historia Némero= Terai Asignad 1 Prioridad en Negoeo: Media Puntos Estados: | cata’ Media aja) ‘Riesgo en Desarrollo: Maio Pantor Reales: (Aalto Medio Bajo) Descripcion: Permit al usuario expontr el documento de requsrinients del sistema a una herumients de edgy bir para rear docunenio (Obrervacones ‘Némero: 35 "Nombre: Heramisna de Gestion de Raguerimieos ‘Usuario: Equipo pC “Medificacin de Historia Nameraz Tien Asignada 1 = Prioridad en Negocio: Mess untor Estimades: (ita Media Baja), Riesgo en Desarrollo: Maio Puntos Reales: (Alto/ Medio Bajo) Descripcion: ‘amir lo usar cbuvar ls cambios avd de ushers eee sbiera inert a heriata der, Se dts ero caron en rar enn sits coset pee. ‘Obrervacones:Avéndlces — Apsndice & 36 bre: Dos. spcieaion Scans G2 uo Coase ui prea Modifies de Historia Nimaroz Parad eh Negicin: Metis Ponto Emad: (ts Medi Daj) isan en Desarralie: dis Panter Reales {Sa Melt Bj) | Perit al usu verb eect de cao de wo y poder expres 4 an document J texo en una hemiens de suigp ier |Avéndices - Avéndies B Apéndice B— Plantiltas B.1 Documento de Visién (8: Nace ge Five dserigcin pore presse! ieee PTT S| Fs a ee Tes WT ARTTOTRT Pasi dl products [Propane ramen prc a al nie psc del prt ya sin eet Mere Te Tray Reser aT nacaTaad ve Tappa, Te gia OG] Earn a Tr pple Fens wT TB TD Pa fone prasc? Fa aera oT oe eee serpin de os nvoleralon Resume deo oemdos Toe Tepe Topsabia [Ramis Oe Tas pares | [ORGS Rea Te pare | asa Rav Tas apostate ae parc ect) Abies Una {Dette anon de nj de ern Resende Prato Corea Trane Tacs Pa ae rad Tens Paintiont ema [8] eit del Py eguetiicnos Regus aa Fred Tea Pane ado TSE + Ussiia lice: 2 Soper Ines del Ser TResimon gon sob as roe gue deo sor pond por pcan, Prtcoler, pro eens ii,» Secavamane de mede ve et are sr earldom cn ts reverie dee nif} Inter de Unto [Rome port sb as ear de ar deve oo tana, La tin de a echo derbi Specie taper ies tres dear Aare y Arete (ina dserpton di soc el eras. a pcan de ete ae le, a colores ge deen tale grad eral pat uve) Dino y Navesnin: Rsramc gens ela a pol. CConerenca: Paciolan de Us: (Resumen sobre cs deers gpaecr atomidcanete pa as wars ls doo os pale qe os ‘oro con permite Innis con sistema xeros 6on pits eerie eset {Compote el irs de srr algincanponete entilnds de ose pliacino capone que ‘tn cacraandn pars las boa rs del bac apa, pe or oe be ‘erat nee de Hare (Defi as werfces dare gue vn oe soporte or el rj, iclnendo even gk, ‘Areca eas, of compara expra, yas cmc Inerices de Cormac [Desc rece de tomioines «aro ssomar a capitines ter came rate de dre lel {Reporter de oni rema raceme).Avéndices - Apéndion § Regis dal Neco ‘haps gu di Har deo empresa Las lat dl nego soa mom repens coms norma ke pode Regis Linon dl St. ‘Leena des eum essen efit ec de cuter concede Bec resend a oro reese ade xe eke poret savers. ‘reo, seas de aor Desobr cxaiuer cumple ng nsceran: reacts pranise, avr de conv poner, wordmat, ‘mors gona as cts relia amplinia depot bras). ‘Norms apis Documsntiib a Sim Oey avn dee srt eek de aro, stems ea, pda brs aman, te, Denar gun se eb ‘raponaie dele documentaB.3 Casos de Uso [8]: Casos de Uso Deseriptin ‘Breve dscipié det eas de wo Actors Nombre Astor > Preconliiones “pre-sondicidn > lajo Bisco de Eventos 1. Paso > ies 3 Pao PostcondiconesBd Historias de Usuario: Pacer evary Num Nombre: Usuario: Modificacién de Historia Numer Prioridad en Negocio: Puntos Estimados: (Alta / Media / Baja) Riesgo en Desarrollo: Puntos Real {Alto Medio / Bajo) Deseripcién: Observaciones:fnlude_onceassconenion php") Include ones east operacion hp" lass caracteristica extends operasion ‘ private Suomi; private Seseripcion; private Seoexion privat Spaqute, private Spriondad private Stoo private Sestatus; private Sestabildad; private Siew: private Siterciomactal: private Sitercion private Sorgen: private Seotaty: pevate solid; ava efecto: private Sobsolew: private Stila: public Sid; public Susi, function construct) t ir (fane_nam ang)Anéndices — Apéndics 1 Sthie nombre fine_got_ are): Siis>descipcion = fine get ag); Sis >paqute = fone got arg) ‘this >proncad = fume. ge aat3) Siistpo~ fe ee are); Sthis estan = ne gt ag} Sts >diiutad=fane get ant); Stbis>estailidad ~ ime get a; Sthisrisa fave get a8) Stenson ine ge rt) Sihisorian = fme_ gt srt Sthiseomacto= fine. got at): Sthiscsoiitad fine go a2) Sih >deeew = ine. get a9) Stviscvoeto= fine gst art 4); Sihis tenia fine. ge arts: } Sthis>aonexion = new couesion();} Fanesion dering) [this meonexion Seema): Fuesion re) ‘ Sthis>quen(INSERT INTO. CARACTERISTICA (ID PAQUETE, NOMBRE CARACTERISTICA DESCRIPCION_CARACTERISTICAPRIO RIDAD_CARACTERISTICA,TIPO CARACTERISTICA ESTATUS CARA CTERISTICA DIFICULTAD CARACTERISTICAESTABILIDAD_CARA. CCTERISTICARIESGO_CARACTERISTICAPLAN ITER_CARACTERIST ICAITERACION ACTUALORIGEN CARACTERISTICA,CONTACTO__ (CARACTERISTICA SOLICITUD, CARACTERISTICA DEFECTO. CARA CTERISTICAOBSOLETO CARACTERISTICA) VALUES (Sth Ppaquele, _‘Sthis>nombre Sthis>descrpeionSthis->prord, thi >lpo. Sis >estaus'Sthis-difelta Sts os dad. hs reg Sthi-teracionSthi-~eraclonactuaShi->organ Shi contain Sthis slid Sthis>defet'Sthis>obsoleto). |Apéndices — Apendice ¢ Aunetion sonsutiaSproyeto} Sselect= “SELECT * FROM CARACTERISTICA C, PAQUETE PA"; Swhge "WHERE PAID PROYECTO = Sproyeco) AND PAID PAQUETE = c1D_PaQueTe™ in(stisid t Swhete.=" AND C.ID_CARACTERISTICA ~ Sthie>id Swhere AND C1D_PAQUETE = Sthis>paquete" , t(Sthis>nombee =") ' Switere =" AND C NOMBRE. CARACTERISTICA LIKE "4Sthis>nombet ' {€(Sthis descrpcion ‘ Swhse =" AND C.DESCRIPCION CARACTERISTICA LIKE %4Sthis- esergcion a", ) {sts >paquete =") t Swhere =" AND CID_PAQUETE = Sthis>paguste™, Seal Sih gery Ses Shee iF this omursows(Se)> 0) tur Sel che setum lse;Apindices — Apéndice ¢ fimetion mod bast) session_start Sthis usu _ SESSION. usu Sihis>query("UPDATE CARACTERISTICA SET [D_PAQUETE™= Sthis>paquete, PRIORIDAD_CARACTERISTICA. shi ronda, ESTATUS_CARACTERISTICA ~'Shis=est, DIFICULTAD CARACTERISTICA = Sthis dieu, ESTABILIDAD_CARACTERISTICA = Siis->esabid, CONTACTO. CARACTERISTICA = this vont (WHERE ID_CARACTERISTICA ~ Sthie> Sthis>quen("INSERT INTO CAMBIO (ID_CARACTERISTICA, DESCRIPCION CAMB, ESTATUS.CAMBIO, ID_USUARIO) VALUES (Sts, Se modifies ls earaceristies Poe Aprobu ‘thie >) fusion modifica cart) t session_start); Sthisous = $_SESSIONTg usuario; Sthis->query*UPDATE CARACTERISTICA SET ID PAQUETE = Sibi paguae’,Anindices — Apéns NOMBRE_CARACTERISTICA = Sthis nombre, DESCRIPCION.CARACTERISTICA = Sihis->dscripcio’ PRIORIDAD_CARACTERISTICA = Stipa ‘TIPO_CARACTERISTICA ~ Sistine ESTATUS_CARACTERISTICA ~'thisc>estans, DIFICULTAD_CARACTERISTICA = Sthis>dieutad ESTABLLIDAD CARACTERISTICA ~'Sihis->asubildd, RIESGO_CARACTERISTICA ~ Sthisriesn, PLAN ITER CARACTERISTICA - Sihisieracion ITERACION ACTUAL ~"Sthis>terionseua ORIGEN _CARACTERISTICA ~'Shis=orgs, ‘CONTACTO_CARACTERISTICA this contact, SOLICITUD_CARACTERISTICA~'Sthis solicit’, DEFECTO. CARACTERISTICA = Sthis defies, OBSOLETO_CARACTERISTICA ~'Sthis>obsoleto! WHERE 1D _CARACTERISTICA = ‘Sthisid") Sthisquen(CINSERT INTO CAMBIO (1D_CARACTERISTICA, DESCRIPCION CAMBIO. ESTATUS. CAMBIO, ID. USUARIO) val (thsi, Se modifies la carsteristis";Por Aprobar’ Sts usu) Function elimina Sidearaterstica) Sihis>quenDELETE FROM CARACTERISTICA WHERE (D_CARACTERISTICA = ‘Sidearcterisios") Fiction cimiocaracteristictSi)Avéndices - Apéndice ¢ Srelt = fthis>quen(CSELECT * FROM CAMBIO WHERE ID_CARACTERISTICA = Sid! AND ESTATUS. CAMBIO ~"Por Apeobar”) if(StisonumRowstSeesul)> 0} ‘Seow = Sis >FethAreay(Sesul); tur Sr Jae eum ise: Simetion modeamibiocaracteristic( Side) See = Sis quen("UPDATE CAMBIO SET ESTATUS CAMBIO = ‘Aprobado! WHERE 1D CAMBIO ~'side"), C2XMLHapRequest Sutin este XMILHtp Request) ir(window AsiveXObject) t ‘tur new ActiveXObjoo" Microsoft XML HTTP") cls if window. XML Hip equ) ‘Avindices = Apéndice ¢ rem new XMLHupeguest) : G3AUAX finn creteXML pos) §—ittwindow Aaivexobee {ema AcivXObjet Nicos MEAT ok if window XML pResusst) { retumnew XMMLHUpReguesfs Funeton lamarasineronocu, id contenedor) 1 sarpagina roqueria=fiie arpapm_equerida~ereeXMLHupRequss igin_egucrid nent ttestange-Fncton) { corempasia(pging rusia eonteaor) | agim_ equi open GET wt) ase ssoueria send 1 function carpe pain regu i sontensor 1 iipagineroquerida ey Stte—1) ¢ document giElemencBy did conenedor)innetTML = “iv lign~eent? style= wih: 100%; hg 100%<>", 1 ‘itipsgina requria readySite—) {- itpagina requerid staus-200) |MocumentgtFlemeny1_eontenetor inner TNL = pagin_esurida esponscText ’ se ilipuginsresusrids satis —=108) | i comenedorinnerHTMI. ~ "La dircesion mo exist";Apindices - Agéndico ¢ chee {i sontnedoinmer{TML.="Eror "paging requrdastans; } 3 faction envianat(_pogina,valorget,vlorpost ap) (sje ereatex aL tepeqst) itvalerpost——") {sscopen(POST*,_papina*?+valorpost teh; } cise | slcopen"GET",_paginat™?valorget, tes} sjxonreadystaechange-function() | eugsrpayinlajas caps} itelorpos!=") | sjacsaequesHeaden "Content-Type", “applicationls.aww-forn-ulencode sjaxsendalorposd; lke | alxsendfouly |) faction togple(capa) {document getElement espa) style dsplay =~'none)) { document gelemenBylaopa yep clse {document getEleentByldcaps) syle dispiy "one's $$ function arosar patti contender, numer) ‘ar nnd ~ document sreatlemen iv" todo ierHITML = "civ d=" + numero + texares fame~campo" * numero " ke" + numero +” cob=00% rownn'2>~texurex—spun>~span clase~'celda StleWwidictomsosd piso-la>pan case eld’ stem wid 104 dbora” + ume "re ~javascrgt: barr past” + humans"): numer )>eiminare epan>ingut ks? + mera" pe-hidder value! >= >" sar seal = document gtslementBsldid_contanadon: {actual eitdNodes ena ) | actu iner FEM don otET ML) cic { octuappendChidtnogo:} 4 Aum bora psf names) | varbonar= document etEement8ynumeo}: somarpaenNode emoreChilbanar: | fiction agregar st paso(pads, hijo) | sar aod = documented sodostnesHIML = “div ide” + padre 2°" + hijo +" elas etext? + pad #1" hijo + Paso + padre +." + hijo + textaren mamesampo” + padre +7" + hijo +" ist + padre 9." hijo + * cols N00%8 rows-2™span>apan law~coldt sive widdsIDW>Hle geome sate) — fale) how new O4FExceton( Nothing o pase «heck that the conten le corey Forme) 1 Simp ~tempnarinl, unigid)) "0 cop temas, tp); Sthisompite Step: pub Functen setVars(Skoy valu, Seneode te) t if stepos(Sthi->eontentXm, selfsDELIMITER_LEFT Shey sol'sDELIMITER RIGHT) — fas) Uhr ew OU ception ar Sky Ht und i the acumen t Sale = Sencodeutis_ensodsinkopeiachantSalu) encod Svat) Sihisvarsset:DELIMOTER, LEFT. Shey, se:DELIMITER RIGHT] ~ Svale: rtm Sis , publi Fanci stlmage(Ske, Svale) Silename = sutotsrehSvalu, Sse subareas, 1 Sire = G@psiagesia ley iF ieee) | throw new Odeon nvidia t Us Sid, Ship) = Sins Swidih = se:PIXEL_TO CM, Shoght = sefoPINEL,TO_CMK, Sul = -var), Sis >evntentXinl) 1 ble fetion mergeSegmen{Seprent Sseymnt) ‘ It aray_ey_ extent petName), tis >segrenis) | Atyow new OUFExeeptionSseament getName) cannot be psd, has it bean st yet): ' String = Ssewnent> getName) Seep = Betexeg( 11 BEGINS Sting. ‘SIL “ENDS! Soring . "s= \estexep>aism! Sthise>comentXml = prey replactSre,Ssegment>getXmiPacsed),Sthis>eontentXn retum thst ) public function primar) { return pin vars, ru). pre te ) bli Finction toString) t retum Shs cotentXls ’ publi uncon prinDeclardSegmens()return pre, prin timpledearay_keysSthissegments) ru) fpr; ’ public fction segment Segment) ‘flamay_key_exist(Ssepment, Shis>segments) | ‘stum Sts segment| segment: Steg = "#1 SABEGINsSsegments-\}eVeetp>.*} tents *'[~ itapeeg_mateySrep, boty deeodeSthis-eonentXml, $m) throw new O4FEXCeont "Sacer seems nt Fund inthe dome) Sthse>seament Sseumen] = new SeameatSsamen, Sa ‘sum this >segmentSsepment) : bli fieton save ToD Sie =) ‘ if Sie ul is singh) | Sihis6leopentSthis apie, ZIPARCHIVE:CREATE), Sthis> sal conysthis “epi, Sil) Jobe sthis> saves ) private funetion_savet ‘ Sihis> parsed it Sthis>fileaddFromStingl coment x, SthiscomemtXal)( ‘row new Oa xception Error during fl expr’)foreach Stis>images a SmageKey => SiageValu) ( Sthis>fle>la(SimageKey, Pictures. SimapeVaue: } Sis leet ae wo bug on windows CLL sometimes ) publi finetion exper AsAtacheet) ‘ Sihis-fle ope Shs amps, Z1PARCHIVE:CREATE: Sih sve ‘(headers senSename Sine) { now new Oden heads ead set (Sima at Slionun ) teader Comet ype: ina 29; ‘sade *Contet-Diposton: tachment; lene" mani)" eadlathis ene , C7 Mecanismo de Integraciin PHP

numRows(Srea2}0)| Spm Sodt=setSegmentoombres, Sorig~ Sodt>setSepmentore, Spr = Soat>seiSepmentri)s ‘estat = SodfvetSepment et Si ~ Sout>setSagmentii Se = SodFosesSagmene: Ses = So>setSeuet Spano = Sod etme pee Spo ~Sod>setSeamemp: "dese ~ ode serSegment(es): ‘while (Sowa ~ Ssonexion->Fetshray( Stes) | Some = Stow? (NOMBRE. CARACTERISTICA' Sprionidl » Srow2{ PRIORIDAD_CARACTERISTICA’ Sextus ~ Srow2(ESTATUS CARACTERISTICA Sie ~Srow2(/DIFICULTAD, CARACTERISTICA; Sestabilidad~frow2[ESTABILIDAD_CARACTERISTICA Sco ~Srow2{'RIESGO_CARACTERISTICA\ Spersona = frow2CONTACTO.CARACTERISTICA: Stipee=Srow2(TIPO_CARACTERISTICAT: Sorgen ~ Som2'ORIGEN_CARACTERISTICA' ‘Somb->seVithSoorbre)Sovig>setVa'e, Saigon, Soro setVart' Srirdad Sestt>seVar Sets); Si setVan' diay Sestdb-seVar', Sst StiesveiVan Sie SpesosetVar'pe’, Spasons Sto setVa Sti; Somberg Sorig-> merges Spriomerae): Sest>merseos Sait >meas Sesubomerae) Sriesomered Spenoomerasdy Sti meres: 1 Sot >mergeSegmen(Snonb): Someone ore Sod >meraeSepmen( Spi: ‘Sodt>mergeSepment festa; Somer $i; ‘SoatomergeSeginent Sata) Sodt>mergeSepment fries) Soat>mergeSeament Spero; Sod >mergeSeemeni tipo} ‘Sod>xetVarmombrey $nambrep: Sodt>exportAstacodile)s >Apéndioes - Apéndice ¢ GS Script de la Base de Datos: DROP DATABASE IF EXISTS “asi (CREATE DATABASE "sis (CHARACTER SET ‘stn! COLLATE Taint swedish USE esis * 1 Srvtue for the actor table * DROP TABLE IF EXISTS ‘ator: (CREATE TABLE “str ¢ ID_ACTOR' ing IT) NOT NULL auto_increment, NOMBRE ACTOR’ varchart30) defislt NULL, PRIMARY KEY (‘ID ACTOR) ) ENGINE=IomoDB DEFAULT CHARSET-latin!; 4 Sireture for the "proyeets" wie a DROP TABLE IF EXISTS ‘proyecto’ (CREATE TABLE proyecto'( ID_PROVECTO' in 1) NOT NULL auto ineremen, ‘NOMBRE_PROYECTO: varchaq33) NOTNULL, DESCRIPCION PROYECTO’ varchar 50) default NULL, PRIMARY KEY (ID PROYECTO} )ENGINE=InnoDE DEFAULT CHARSET=latin ruta for he paguete’ table DROP TABLE IF EXISTS "paquets (CREATE TABLE ‘paquets ID_PAQUETE" inc) NOT NULL auto_increment ID_PROVECTO' init!) defau NUL, NOMBRE: PAQUETE wasiar(35) NOT NULL, IMAGEN varchar 50) default NULL, [DESCRIPCION_PAQUETE® text, INFO PAQUETE: varcha(0) default NULL, PRIMARY KEY (1D PAQUETE ), KEY "FK_FORMADO' (1D PROYECTO"), CONSTRAINT 'FK_FORMADO' FOREIGN KEY (ID PROYECTO") REFERENCES ‘proyecto’ (1D_PROVECTO") ON DELETE SET NULL ON UPDATE CASCADE, ) ENGINE~ingoDB DEFAULT CHARSET-iatnl;indices - Apéndice ¢ Stoeue for he saractrse! table DROP TABLE IF EXISTS ‘careers; (CREATE TABLE ‘cancers’ ( “ID_CARACTERISTICA’ int!) NOT NULL suit incroment, WD_PAQUETE® ini) defult NULL, “NOMBRE. CARACTERISTICA’ varchar35) NOT NULL, DESCRIPCION_CARACTERISTICA' tex, PRIORIDAD_CARACTERISTICA’ varchai(20) default NULL, “TIPO_CARACTERISTICA’ varchar default NULL, [ESTATUS.CARACTERISTICA’ varehar25) detoult NULL, DIFICULTAD_CARACTERISTICA.varehan20 default NULL, ESTABILIDAD_CARACTERISTICA’ varcsr(20) default NULL, RIESGO CARACTERISTICA varchar(20) default NULL, PLAN ITER CARACTERISTICA’ in) default NULL, ITERACION_ ACTUAL’ int) default NULL, ORIGEN_CARACTERISTICA. varchar30) dealt NULL, CONTACTO, CARACTERISTICA”vatharS0) default NULL, SSOLICITUD_CARACTERISTICN text, DEFECTO. CARACTERISTICA’ text, ‘OBSOLETO.CARACTERISTICA’char2) defait NULL, DRIMARY KEY (1D_CARACTERISTICA ), KEY 'FK_RELATIONSHIP 4° CID PAQUETE’), CONSTRAINT FK RELATIONSHIP 4” FOREIGN KEY (1D_PAQUETE) REFERENCES ‘paquets (1D_PAQUETE") ON DELETE SET NULL ON UPDATE CASCADE J ENGINE=InnoDB DEFAULT CHARSET=ltinl; * 2 Site fr the requerimieno" able * DROP TABLE IF EXISTS ‘equeriniento’; CREATE TABLE ‘requerimi( ID_REQUERIMIENTO™ in(1) NOT NULL auto. jnerement, ID_PAQUETE® in( 11) default NULL, ID_CARACTERISTICA’ int) default NULL, [NOMBRE REQUERIMIENTO: vrchirt 10) dete NULL, DESCRIPCION REQUERIMIENTO" text, ‘TIPO_REQUERIMIENTO: warcar20) default NULL, "RIORIDAD REQUERIMIENTO'varchar(2) default NULL, STATUS. REQUERIMIENTO varehar(20) default NULL, DDIFICULTAD REQUERIMIENTO’ varcha20) default NULL, “ESTABILIDAD REQUERIMIENTO varchar(20) default NULL, "RIESGO. REQUERIMIENTO' varchar(20)detslt NULL, ‘NOMBRECONTACTO_REQUERIMIENTO? varchar) default NULL, “TTERACION PLAN_REQUERIMIENTO! in20) defult NULL, “TTERACION ACTUAL REQUERIMIENTO™in(20) default NULL, °SOLICITUD REQUERINUENTO' text, DEFECTO REQUERIMIENTO' text, “OBSOLETO_REQUERIMIENTO' text, °PRIORIDAD_INTER_REQUERIMIENTO™ text, PRIMARY KEY (ID_REQUERIMIENTO KEY FR RELATIONSHIP (1D PAQUETE’), KEY FRELATIONSHIP-7' (1D_CARACTERISTICA’)Apingices — Apéndice ¢ CONSTRAINT ‘requriniento 0° FOREIGN KEY (1D_PAQUETE') REFERENCES ‘pagusts' (‘ID PAQUETE’) (ON DELETE CASCADE ON UPDATE SET NULL, CONSTRAINT ‘requrinienlok1” FOREIGN KEY (1D_CARACTERISTICA') REFERENCES ‘earscterisca (CID_CARACTERISTICA’) ON DELETE CASCADE ON UPDATE SET NULL. ) ENGINE-InioDB DEFAULT CHARSET-latin, * 1 Siete forthe sato_de_ws0" able: DROP TABLE IF EXISTS ‘caso deus CREATE TABLE “aso de_ uso’ ( ID_CU im) NOT NULL auto_increment, ID"PAQUETE? in} dealt NOLL, ID_REQUERIMIENTO" in) dela NULL, ‘NOMBRE_CUvarcay(S0) default NULL, PREC CU" text, POST CU tex, DDESCRIPCION CU" text, PRIORIDAD_CL varcar(20) default NULL, ESTATUS CU" srchar20)defiult NULL, SDIFICULTAD. CU" vsrehan20) defuit NULL, ESTABILIDAD_ CU’ varehar20) dfuuk NULL, IRIESGO_CU’varchan20) dau NULL, ‘OBSOLETO CU" vachar20) default NULL, ‘ARQUITECTURA’ varchar(20) defslt NULL, PRIMARY KEY (1D CU), KEY 'FK_RELATIONSHIP 6° CD PAQUETE KEY 'FRRELATIONSHIP-€ (ID-REQUERIMIENTO), CONSTRAINT FI RELATIONSHIP 6° FOREIGN KEY (ID_PAQUETE") REFERENCES "paguot (1D_PAQUETE') ON DELETE SET NULL ON UPDATE CASCADE, (CONSTRAINT. FK_RELATIONSHIP_8' FOREIGN KEY (1D_REQUERIMIENTO') REFERENCES "equerimiente’ (1D. REQUERIMIENTO) ON DELETE SET NULL ON UPDATE CASCADE ) ENGINE= InnoDB DEFAULT CHARSET-Iatin|s ' Strate fo the actor abe é DROP TABLE IF EXISTS “ator ow (CREATE TABLE ‘ator eu'( D_CU ing) default NULL, D_ACTOR’ ink) default NULL, KEY ID.CU'TID CU, KEY ID_ACTOR’(1D_ ACTOR), (CONSTRAINT ‘actor ek’ FOREIGN KEY (1D_CL") REFERENCES ‘easo_de_uso'(ID_CU')ON DELETE. CASCADE, ‘CONSTRAINT “autor ou_fkI’ FOREIGN KEY (1D_ACTOR') REFERENCES ‘aco’ (1D_ACTOR') ON DELETE CASCADE )ENGINE™lnnoDB D) “ f Suture forthe "usuario table * FAULT CHARSETslailAvénai li DROP TABLE IF EXISTS ‘usuario’, CREATE TABLE ‘usuario “ID_USUARIO' int!) NOT NULL auto jacrement, "NOMBRE. USUARIO" vaehar5) NOT NULL, “CLAVE USUARIO’ varhar(32) NOT NUL, SPREGUNTA S'archar 5) NOT NULL. SRESPUESTAS*varchar(15) NOT NULL, “LOGIN USUARIO" yarchar20) NOT NULL, PRIMARY KEY (‘ID_USUARIO', UNIQUE KEY 'NOMBRE_USUAMIO" (NOMBRE USUARIO}, ) ENGINE-IneDB DEFAULT CHARSET-iatol; ‘ # Sewtue forthe "cambio! table: * DROP TABLE IF EXISTS ‘cambio's ‘CREATE TABLE ‘cambio’ ( “ID _CAMBIO® in) NOT NULL auonerement “ID_REQUERIMIENTO" in) faut NULL, SID“CU" int) default NULL, “ID-CARACTERISTICA’in(i) deaultNULL, SDESCRIPCION CAMBIO txt, SESTATUS CAMBIO" varchur(20) default NULL, MD _USUARIO’ int) default NULL, PRIMARY KEY ('ID_ CAMBIO), KEV iD REQUERIMENTO.(19_REQUERIMIENTO), KEY "DCU" (1D CU"), KEY (_CARACTERISTICA’ (D_CARACTERISTICA’), KEY “(D-USUARIO' (1D_USUARIO), CONSTRAINT ‘cambio Ne FOREIGN KEY (1D_REQUERIMIENTO') REFERENCES ‘requests (C1D_REQUERIMIENTO") ON DELETE SET NULL ON UPDATE SET NULL, CONSTRAINT ‘eum. kl FOREIGN KEY (ID_CU| REFERENCES ‘cao de_uso"C1D_CU') ON DELETE SET NULL ON UPDATE SET NULL, (CONSTRAINT ‘cambio 2" FOREIGN KEY (1D_CARACTERISTICA') REFERENCES ‘caacteristca™ (1D_CARACTERISTICA'} ON DELETE SET NULL ON UPDATE SET NULL, CONSTRAINT ‘cambio ho" FOREIGN KEY (1D_USUARIO') REFERENCES ‘usuario’ (1D USUARIO) ON DELETE SET NULL ON UPDATE SET NULL ) ENGINE InvoDB DEFAULT CHARSET-Iatint ‘ # Sieeture fr the comentario’ table + DROP TABLE IF EXISTS ‘comcntto's (CREATE TABLE "comentario “Ip. COMENTARIO' init!) NOT NULL aut inerement, "NOMBRE COMENTARIO’ varear(}00) default NULL, °DESCRIPCION COMENTARIO" varchar) delauk NULL, WD_CU in) defelt NULL, “D_REQUERIMIENTO int) default NULL, > CARACTERISTICA’ in} default NULL, 1D_USUARIO" ini) defile NULL PRIMARY KEY (1D_COMENTARIO"Avéndices = Apéndice KEY "DD cU‘CID cv, KEY ID REQUERIMIENTO’ (1D REQUERIMIENTO'), KEY "ID_CARACTERISTICA’CID_CARACTERISTICA’), KEY “ID-USUARIO' (1D_USUARIO), CONSTRAINT ‘comenari.° FOREIGN KEY (1D_CU') REFES DELETE SET NULL ON UPDATE CASCADE, CONSTRAINT comentario kl’ FOREIGN KEY (1D_REQUERIMIENTO ) REFERENCES ‘requrimients (1D_REQUERIMIENTO } ON DELETE SET NULL, ON UPDATE CASCADE, CONSTRAINT ‘comentario 2’ FOREIGN KEY (ID _CARACTERISTICA) REFERENCES "esractrsicn (ID_CARACTERISTICA’) ON DELETE SET NULL ON UPDATE CASCADE, CONSTRAINT comentario_3° FOREIGN KEY (1D USUARIO") REFERENCES ‘usuario’ ON DELETE SET NULL ON UPDATE CASCADI )ENGINE=lnnoDB DEFAULT CHARSET=tainl; '‘caso_de_uso' (1D CU'VON ID_USUARIO} * 1 Suture (or the “Bocumnento 64" able ¥ DROP TABLE IF EXISTS "documento (CREATE TABLE ‘document e9°( 1D_DOC REQ" inl) NOT ULL auto_increment DDESCRIPCION DOC REQ" text, 'USABILIDAD DOC REQ' text, FIABILIDAD DOC REQ’ text, "RENDIMIENTO. DOC REQ" text, "SOPORTE_DOC REQ" text “INTERFAZ DOC REQ! text, “INTER. USU_DOC_REO" text, “VISION DOC REQ’ tex, °DISENO_DOC REQ text, ‘COHERENCIA DOC REQ" text, “PERSONALIZACION_DOC_REQ’ text, INTER EXT_DOC_REQ' text °SOFTWARE_INTER_DOC_REQ tx, HARDWARE INTER DOC REQ' tex, “COMUNICACION INTER BOC REQ' text, REGLA. NEGOCIO DOC REQ" tex, 'REGLA. CLASES DOC REQ’ text, SLIMITACIGN DOC REQ’ text, LICENCIA_DOC_REQ' text SURIDICO DOC REQ’ text STANDARDS. DOC_REQ' text, DOCUMENTO_DOC REQ’ text, "WD PAQUETE” imi) defalt NULL, PRIMARY KEY (1D DOC REQ’), KRY ID_PAQUETE’ (1D PAQUETE’, CONSTRAINT ‘dseumenteq_K FOREIGN KEY (ID_PAQUETE?) REFERENCES “puauste €1D_PAQUETE") ON DELETE SET NULL ON UPDATE CASCADE. )V ENGINE noDB DEFAULT CHARSET taint: ‘ 1 Stet forthe Naje! tble + * DROP TABLE IF EXISTS 'fujo_ox's(CREATE TABLE “ajc ( “ID FLUIO' ay!) NOT NULL auto increment, NOMBRE FLU3O" varchar 10) dealt NULL, ‘DESCRIPCION FLUJO" varchar 000) defislt NULL, “TIPO_ FLUJO" varchar 100) default NULL, DCU in) dtiale NULL, “ID-FLUO_FK" in) deta NULL, PRIMARY REY (ID_FLUIO', KEY "DD CU'CID CU") KEY ID FLUJO FK' (1D FLUIO FEC), CONSTRAINT fujo_cu fe FOREIGN KEY (1D CU’) REFERENCES “ewo_de_ vs! (1D_CU') ON DELETE CASCADE ON UPDATE CASCADE, ‘CONSTRAINT fnjo_cu Tk" FOREIGN KEY (ID_FILUIO_FK") REFERENCES “sj_! (1D_FLUIO}) ON DELETE CASCADE ON LPDATE CASCADE ) ENGINE™lnneD8 DEFAULT CHARSET-Iatin; “ 1 Sista forthe “oso able: + DROP TABLE IF EXISTS “slosario': ‘CREATE TABLE “gosri’( “ID_GLOSARIO® f(T} NOT NULL suo incroment, "NOMBRE GLOSARIO’ yarchar$0) defi NULL, °DESCRIPCION GLOSARIO’ varehas(S00) defini NULL, 1D. PAQUETE: in) default NULL, PRIMARY KEY ('ID_GLOSARIO’) KEY "ID PAQUETE'T1D_PAQUETE’), ‘CONSTRAINT loscio Ne FOREIGN KEY (1D_PAQUETE') REFERENCES ‘paguew’(ID_PAQUETE’) ON DELETE SET NULL ON UPDATE CASCADE )VENGINE*(na0D8 DEFAULT CHARSET aint: ‘ "Stu for he usuario. proyecto” able: ‘ DROP TABLE I EXISTS "usuario royeet's (CREATE TABLE "usuario proyecto! ( “ID USUARIO’ im) default NULL, “ID"PROYECTO™ int) defauit NULL, ROL varchai(!8) NOT NULL, KEY "FICINVOLUCRA' (1D PROYECTO"), KEY 'FK PARTICIPA’ (1D USUARIO), CONSTRAINT "FK_INVOLUCRA’ FOREIGN KEY (1D PROYECTO’) REFERENCES ‘peoyect’ (1D PROYECTO’) ON DELETE SET NULL ON UPDATE CASCADE, CONSTRAINT FK_ PARTICIPA” FOREIGN KEY (1D_USUARIO") REFERENCES usuario’ (1D_USUARIO') ‘ON DELETE SBT NULL ON UPDATE CASCADE ) ENGINE=InpoDB DEFAULT CHARSET=lainl; ' Stu for the visio table # DROP TABLE IF EXISTS ‘vision’:Avindices - Apéndice C (CREATE TABLE ‘vision’ ( D_VISION' int) NOT NULL aut ineremen, ‘DESCRIPCION VISION’ ext, “PRO_VISION’ text, °ARECTA VISION’ tex, SIMPACTO VISION’ text, *SOLUCION VISION tex, “PARA_VISION text (QUIEN VISION’ txt NOMBRE_PRO_VISION' text, B80_VISION' text, “DIFERENCIA VISION’ tex, NUESTRO PRO. VISION text, INTER NOM_VISION' text, INTER_DES, VISION’ xt, “INTERCRES VISION’ tex, ‘USU_AMBIENTE_ VISION’ text, HD_PAQUETE? i(11) detule NULL. PRIMARY KEY ('ID_VISION’), KEY "ID_PAQUETE (1D _PAQUETE’), CONSTRAINT ‘Vision Ne FOREIGN KEY (1D_PAQUETE’) REFERENCES ‘paquste’ (1D PAQUETE) ) ENGINE=InoD8 DEFAULT CHARSET=IatiAvéndices - Apéndice D D.I Roles en. © Analista: © Habilidades: Un analista necesita los siguientes conocimientos, competencias y habilidades: © Experticia en identificar, entender problemas y oportunidades. © Habilidad para articular las necesidades asociadas con los principales problemas a resolver u oportunidad para ser realizados, © Habilidad para colaborar efectivamente con otros miembros del grupo a través de sesiones de trabajo colaborativo, sesiones JAD y otras téenicas. ‘© Buenas competencias comunicativas, verbales y de escritura © Conocimiento del negocio, dominio de la tecnologia o habilidad para absorber y ‘entender ripidamente tal informacién, = Propuesta de asignacién: Este rol puede ser asignado en las siguientes formas: © En equipos dgiles pequeiios, este rol es frecuentemente compartido entre varios miembros del equipo que también desempefian otros roles.Apéndices Apéndice 0 © Uno o més miembros del equipo desempefian este rol exclusivamente, Esta alternativa es cominmente adoptada cuando los requerimientos son complejos 0 diffciles de eapturar. (© Uno 0 més miembros del equipo desarrollan este rol y el rol de Tester (pruebas). Fsta es una buena opcién para grupos de prueba pequeflos 0 con recursos restringidos. © Arquitecto: © Habil Los arquitectos deben ser personas polifacéticas, con madurez, vision y una sélida experiencia que les permita abordar temas ripidamente, hacer juicios criticos y académicos con informacién incompleta. Mas especificamente las personas deben poseer esta combinacién de estas capacidades: (© Experiencia en dominios, tanto de problemas como de ingenieria de software, con evidencia de una completa comprensién de los requisitos para resolver el problema y una patticipacién activa en el desarrollo del software, Si hay un equipo, esta experiencia puede estar representada en diferentes miembros del grupo, pero al menos, tuna persona debe poder mantener fa visién global del proyecto © Habilidad de Liderazgo para motivar y mantener el impetu del esfuerzo técnico de los diferentes equipos y tomar decisiones crticas bajo presién, ademés deApindices = Apéndice D hacer que estas decisiones se mantengan, Para ser efectivo, este rol debe tener la ‘autoridad para tomar decisiones técnicas, ‘© Exeelentes competencias comunicativas para inspirar confianza, persuadir, motivar y guiar, Este rol no se puede dirigit por decreto, sino tinicamente por el consenso del resto del grupo de proyecto. Para ser efectivo, esta persona debe ganar el respeto de los miembros del grupo, el gerente, el cliente y la comunidad de usuarios, asi como del equipo de direccién, ‘© Disposicién proactiva y orientado a metas con un enfoque implacable hacia los resultados. Esta persona es la fortaleza en la direccién téenica dentro del proyecto, no un visionario o sofador. La carrera de un arquitecto exitoso ¢s una larga serie de decisiones sub éptimas tomadas en Ia incertidumbre y bajo presién, Solamente los que puedan cenfocarse en hacer lo que necesita hacer tendran éxito. Desde un punto de vista de especializacién, este rol también necesita mostrar habilidades tanto en el disefo como en la implementacién, Sin embargo, desde la perspectiva del disefio, el arquitecto eficaz exhibe tipicamente estos rasgos: + Tiende a generalizar y no a especiticar, es quien conoce muchas tecnologias a ‘un alto nivel, en lugar de unas pocas teenologias a nivel detallado. + Toma las decisiones téenieas mis amplias, en lugar de demostrar profundos conocimientos y experiencia, asi como competeneias de liderazgo y comunicacién,‘© Propuesta de asignacién: La persona que ocupa este rol, debe estar involuctado en el proyecto desde el inicio hasta el final, Para pequefios proyectos, una sola persona podria actuar tanto como arquitecto como gerente. Sin embargo, si es posible, es mejor que estos roles sean desempeitados por personas diferentes para asegurar que el tiempo invertido en un rol no cause negligencia en el otro rol. Si se adopta esta alternativa de roles separados, ambos individuos deben asegurarse de trabajar de manera muy cereana, © Desarrollador: © Habilidades: Un desarrollador debe tener la habilidad necesario para ejecutar las siguientes tareas: © Definir y crear soluciones técnicas con la tecnologia del proyecto, (© Entender y adaptarse a la arquitectura. © Wdentificar y eonstruir casos de prueba que cubran el comportamiento requerido de los componentes tecnicos (© Comunivar las decisiones a los miembros del equipo. Adicionalmente, crea un modelo visual del sistema, este rol necesita la habilidad para representar el disefio en Unified Modeling Language (UML). + Propuesta de asignacién:Apéndices ~ Apéndice 0 En equipos agiles pequetios, este rol es frecuentemente compartido entre varios miembros del equipo que también desempeitan otros roles. Adin en el equipo mas pequeito, miltiples individuos deben trabajar juntos para crear la solucién técnica, Una persona desemperiando este rol, puede tener competencias especificas en un dea técnica en particular, pero también debe tener un amplio entendimiento de todas las tecnologias involucradas en el proyecto, y estar capacitado para trabajar con otros miembros del equipo téenico, © Gerente: ‘© Habilidades: Una persona que desempena este rol necesita las siguientes habilidades: © Bueno en la presentacién, facilitacién, comunicacién y negociacion. (© Capacidades para conformar equipos y liderarlos. © A través de su experiencia en el cielo de vida del desarrollo de software, ensefia, guia y da soporte a otros miembros del equipo. © Eficiencia en la resolueién de contflictos y Ia aplicacién de tenicas para resolver problemas, ‘+ Propuesta de asignacidn: Este rol es fiecuentemente asumido por una sola persona. Este rol es dificil de compartir con otros, pero podria no consumir toda la disponibilidad de una persona. © Interesados:© Actividades adicionales que realiza: ‘9 Analizar los requerimientos de arquitectura, ‘© Evaluar resultados, © Crear easos de prueba. © Definir Visién. © Disefiar la solucién, © Detallar los requerimientos. © Desarrollar la arquitectura © Buscar y analizar requerimientos. © Implementar la solucién, © Manejo de iteracién. © Planificacién de iteracién. © Plan de proyecto. © Otros: Este rol permite a cualquiera en un equipo, desempefar tareas generales como: © Acceder a artefactos en el sistema de control de configuracién para desarrollarios y mantenerlos (© Someter solicitudes de cambios en el proyecto © Participar en evaluaciones y revisiones © Pruebas:Avéndices Este rol es principalmente responsable por las siguientes tareas: © Went ar las prucbas que se requiere llevar a cabo, (© Identificar el acercamiento mas apropiado para implementar una prueba dada. (© Implementar pruebas individuales. © Preparar y ejecutar las pruebas. (© Registrar resultados y verificar que las pruebas hayan sido ejecutadas, (© Anilisis y recuperacién de etrores de gjecucion, (© Comunicar los resultados de las pruebas al equipo. © Habilidades: Una persona para este rol debe tener las siguientes habilidades: © Conocimiento de tendencias de pruebas y téenicas. © Habilidades para el diagndstico y solucién de problemas. © Conocimiento del sistema 0 aplicacién que esti. siendo probada (deseable), © Conoeimiento de redes y arquitectura de sistemas (deseable). Donde se requiere automatizar pruebas, se requiere estas cualidades adicionales: 9 Entrenamiento en el uso apropiado de herramientas de automatizacién de pruebas,© Experiencia usando herramientas de automatizacion de pruebas. © Habilidades de programacién. © Habilidades en depuracién y diagnéstico, Nota: El requerimiento de habilidades especiticas, vatia dependiendo del tipo de pruebas que se esta dirigiendo, Por ejemplo, las habilidades necesarias para tener éxito, en el uso de sistemas eargados con herramientas de automatizacién de pruebas, son diferentes de aquellas necesarias para la automatizacion de pruebas de sistemas funcionales, ‘+ Propuesta de asignacién: Este rol puede ser asignado en las siguientes formas: (© Asignar uno 0 més miembros del personal de prucbas para desempefiar este rol. Esto es una aproximacién bastante frecuente y es particularmente itil en equipos poquetios, como también para grupos de cualquier tama, donde el equipo esti conformado por un grupo expetimentado de probadores 0 de un nivel de habilidades telativamente equivalente © Asignar uno 0 mas miembros del personal de pruebas para desempetiar linicamente este rol. Esto funciona bien en grupos grandes. Es tambien itil para separar responsabilidades cuando alguno del personal de prucbas tiene més experiencia en la automatizacién de pruebas que ottos miembros del grupo. © Asignar uno 0 mas miembros del grupo, que estin ya desempeniando otro rol en el proyecto, para ser responsable por la prueba de alguna parte de las capacidades delApéndices — Apéndi sistema, El miembro del equipo tendré que tener Las habilidades apropiadas para la prueba. ‘+ Nivel de Capacidad 0. Incompleto: Un proceso “incompleto” es un proceso que ro esti bien realizado o se encuentta realizado parcialmente. ‘+ Nivel de Capacidad 1, Realizado: El nivel | se caracteriza por tener “procesos realizados”, Esto implica que el proceso satisface los objetivos. ‘* Nivel de Capacidad 2, Gestionado: Este nivel se caracteriza por tener “procesos gestionados”. Ademés de cumplir con el nivel 1, pose una “infraestructura de apoyo” para el proceso. Se debe planificar y ejecutar los procesos segiin sus politicas, se debe involucrar a las partes interesadas, el proceso debe ser controlade, monitoreado y revisado, + Nivel de Capacidad 3. Definido: Este nivel consiste en tener “procesos definidos”. Un proceso definido es gestionado (nivel de capacidad 2), son procesos que se adaptan a las directrices de la organizacién y contribuyen con los, productos de trabajo, las medidas y con otras mejoras. + Nivel de Capacidad 4, Gestionado cuantitativamente: Se caracteriza por tener procesos “gestionados cuantitativamente”, Estos procesos son _definidos (capacidad 3) y ademis son controlados mediante estadisticas y otras técnicas ccuantitativas,Apia pn Nivel de Capacidad 5. Optimizacién: Se caracteriza por “procesos de optimizacién”, Estos procesos son cuantitativamente gestionados (capacidad 4), y se basan en la compresién de las causas de variaciones en los procesos. Posce tun enfoque de mejora continua, mejoras incrementales ¢ innovadoras, Nivel de Madurez 1. Inicial: Los procesos tienden a ser eaéticos, la organizacién no suele proporeionar un entomo estable para apoyar los procesos. Nivel de Madurez 2. Gestionado: En este nivel los procesos se planifican y se ejecutan bajo una politica, son controlados, supervisados, revisados y evaliian el ccumplimicato en la deseripcién de sus procesos. El nivel 2 contribuye a tgarantizar que las buenas pricticas adquiridas en la organizacién, se mantengan en momentos de crisis. Nivel de Madurez 3. Definido: Los procesos estin bien caracterizados y comprendides; se describen normas, procedimientos, herramientas y métodos. Estos procesos estindares se utilizan para establecer la coherencia en toda la organizacién. Se establecen proyectos definidos por los procesos, Nivel de Madurez 4, Gestionado cusntitativamente: La organizacién y los proyectos tienen objetivos de calidad, rendimiento y gestion de procesos. Nivel de Madurez 5. Optimizacién: La organizacién mejora continuamente sus procesos, con innovacién a través de mejoras tecnolégicas. Existe revision continua de objetivos y de la gestién de procesos.| lh a Doo. Ly hk i HEE | a sea on fee ee i i i i | tid 2] a] lila | wid ait iil Bal od H i i } MT Z F a 3 7 t Ilha | he AGE | ith | iis | ile | ith ih allie | fills Uae | aallbasts | salty saltbltial fh | fi 1 i = . . : 2 . e . . . yi tt] 4 tof i} it i | z i i i at | ht PLitd ed tila i i 1 a i f : 5 5 Hoe | 3 a 3 a i i 5 FT I i rf if ii filamh] TEL] i) Wy 74 Tha i i a i He AG i i : i : iji tl | de [he td HALA i | Llalagta tale tatatalatalatal adalat etait tt a t f * 5; A hi Ly | ail | th i { i i Rt | | aT ‘ re ; i iit pot tt L ietrbe peel Mitt? ils ateCaso de estudio: Proyecto Imatours. indices — Apéndice F Deseripeién: Este proyecto esta basado en la creacidn de un sistema para la gestién administrativa de Ia agencia de viajes TMATOURS C.A. El sistema debe ser web y debe permitir toda Ia gestién administrativa de la agencia de viajes, ademas se debe realizar un médulo extra, es decir, una pagina web que permita a los usuarios tegistrarse, realizar compras y reservaciones a través de internet. de precios (Alto) Forde fechas seginel Cliente ‘probade “Ala ‘Alla Calendavio “Aakana Perez Restiesion ‘deDisehoCancelar a Cliente | Als] Tncorporado | Media ‘Media| Calendario] Lic. Bemardo | Funcional ‘compra de (Medio) Serpa ‘boletos Cancslar hovel | Cliente | Aa ‘Aprobade ale ‘Tila | Calendario | Lie. Julian | Fancional ovchicule (Medio) | Colmenares ‘reservacion de hotel o ehicalos Compra de [Cliente | Atte Tiprabade “Alla “Ala | Calendario” | Lie Julian | Funcional | Fl usuario boletos (Alto) | Colmenares podra comprar boletos y seleceionar su ‘ucsto en el avin Uaarios Tie “proba ‘Ai ‘Aa | Calendario | Sra Rosa | Fancional | Gestionar de (Alto) | Hemindez ‘usuarios dea través dela webApéndices — Apéndice F Nombre Cy fad | Estabilidad Comparacién de Calendario ‘| Lic. Julién | Funcional vuelos precios (Alto) Colmenare s ‘Formato de For.de fechas Media Aprobado Alta Alta Calendario | Adriana’ No fechas segtin el browser (Medio) Pérez | Funcional Caneelar | Cancelar la compra Alta’ ‘Validado Alta’ Alta ‘Calendario Lic. Funcional compra de boletos (Medio) | Bemardo Serpa y i | Caneelar Cancelar hotel o Media Aprobado Alta Alta Calendario Lic. Funcional i reserva vehiculo (Medio) | Bernardo j Serpa \ ‘Orden de | Comparacion de ‘Alta | Aprobado | Alta ‘Alta | Calendario | Lic. Julian | Funcional ‘vuelos precios (Bajo) | Colmenare 8 Boletos ‘Compra de boletos Media Incorporado Alta Alta Calendario | Lic. Julién | Funcional (Medio) | Colmenare 8 Visualizacié | For.de fechas Baja ‘Aprobado | Alta ‘Alta | Tecnologia | Lic. Julian | Funcional nde segin el browser (Bajo) | Colmenare calendario s Formato de | Comparacion de’ Media Aprobado Alta Alta Calendario Lic. Funcional vuelos precios (Alto) Bernardo Serpa Crear Usuarios ‘Alta | Validado | Alta ‘Alia | Calendario | Lic. Julidn | Funcional | usuarios (Alto) | Colmenare L sApéndices —Apéndice F Casos de Uso: i EEE Priridad ese Consultar Precios Precios de vuelos Alta Calendario (Alto) Reservar vuelo Boletos Alta ‘Aprobado Calendario (Aito) ‘Registrar Usuario Crear usuarios ‘Alta Validado Calendario (Medio) Especificaciin de Caso de Uso Consultar Precios: Nombre: Consultar Precios ipcién: Los usuarios al realizar una reservacién pueden listar los precios de su vuelo con diferentes acropuertos cercanos (Salida y Hegada) Actores: + Viajero. + Sistema, + Administador Precondicién: Estar registrado en la pagina webApéndices — Apéndice F PasoL:El wajero seleeciona la open dsl meni” Compare en acropuerts ereanos” PasotiEl sistema debe mostrar na lista con los seropuertos que se encuentren a menos de 100 mills ‘Paso: El viajero selesiona las seropuerto ser considerades Sib Paso3.1:81vajero puede regresar el mend anterior ‘Paso sistema reali la hdsqueda de preios,horaros, vuclos con las opcones de viajero PasoS:El viajero seleeciona su mejor opelén 1 Paso6sSigue caso de uso RESERVAR VUELO Post Condicién: Bl usuario queda en la pagina Caso de Uso Reservar Vuelo: Nombre: Reservar vuelo Descripcién: Reserva de vuelos por parte de los usuarios puede elegir el aeropuerto de llegada, aeropuerto de salida, fecha, hora Actor + Viajeros.Apéndices - Apéndice F + Personal de la Agencia, + Sistema, Precondicién: El administrador debe iniciar sesién en el sistema, los viajeros deben acceder a la pagina web. ‘Pasol:Viajero entra en la URL de la agencla 'Paso2: Sistema muestra la pégina de inicio. Pasod:El vigjero debe scleecionar una opcién en el meng indicando aeropuertos de sada y Hegada, horarin, fecha, n° de pasajeros Sub Paso3.1:Caso de uso CONSULTAR PRECIOS Pasod: Viajero seleeciona "Buscar vuelos". Pas TE satema de muestra los vuclos de sala ordenados pr precio. Sub PasoS.t: El vajero cambia la clasiiasin dels vulos Sub PasoS.2: El sistema presenta los vuelos ordenads por un determina crterio, Paso6: Bl Viner sleecona an vuelo. ‘Paso: El sistema muestra vuelos de fda y vuelta, ‘Pasof: El viajroselecsion un vue de regreso. ‘Pass Hl tema muestra los detalles del vue, Paso0:E1 viajero confirma el vuclo‘Pasolt: El viajero debe indicar ef nombre de de usuario y contrasefa para continu ‘con la compra del boleto, ‘Sub Paso11.1:EI viajero seleecio "Nuevo Usuario" 1s011.2:E1 viajero debe indicar nombre de usuario, nombre, apelido, contrasedia, c-mil,direccién,teléfonos Sub Pasot! EI sistema verifica que la direccin de correo es iniea y debe tomarse como TD de usuario Pasol sistema muestra los asientos lsponibles, «El viajero scleeciona ls asientos, ‘Pasolt El vigjero proporciona informacidn de la tarjeta de crédito y la direcciin de facturacién, ‘Paso1S: El sistema proporciona un nimero de confirmactén. Post Condicién: Registro del vuelo Caso de Uso Crear Usuario: Nombre: Crear Usuatio Descripcion: Registrar usuario Actores: + Viajeros© Administrador + Sistema Precondicién: Ingresar ata pagina web ‘Paso2:EI sistema muestra un ment de apelones ‘Paso3:El usuario sleceiona del meno REGISTRARSE ‘Sub Paso3.1:H1 sistema muestra formulario indicado ‘Sub Paso3.2:K1 usuario introduce los datos Post Condicisn: Bl usuario puede realizar reservas y comprasindices = E.2 Diseno general de las interfaces:Barra de Herramientas Sar ee cer | An Ss Informacién del Proyecto ©) ere ernine w@ Crear Paquete \ rea Crear Comentario ae J Crear Caracteristica ef Administrar Cuenta RB Cerrar Sesion & Crear Requerimiento A Herramienta de Gestién de Cambio Crear Caso de Uso&a Crear Cuenta Proyecto; [—_] | a Entrar Olvido su Clave? a q Descargar la Herramienta\ Proyecto ‘ {@ Visién y Caracteristicas © Glosario ! ; Ly Térmi ~ Documento de Vision +B, Termings --. Caracteristicas r a “=> Caracteristica 1 (7 Comentarios ~~ 4 Caracteristicas +>. 4 Caracteristica 2 fA Requerimientos ‘@ Requerimientos del Sistema '-44% Documento de Requerimientos & Requerimientos / 5° Trazabilidad fa Requerimiento 1 £3 Requerimiento 2 ..-}8) Casos de Uso '@ Casos de Uso F -\ Casos de Uso ‘© Trazabilidad LES Caso de Uso 1Pantalla Principal Barra de Herramientas Cada elemento representa un wo 2 = La Barra de Herramientas se mantiene fija, el Arbol de Requerimientos se refresca cuando alguna tarea asi lo demanda y el Area de Trabajo varia segtin la actividad que se este realizando.Gestion del Proyecto Nombre del proyecto: El Nombre Modificar Descripcién del proyecto: La descripcién Nombre del proyecto: El Nombre La descripcion Guardar J Descripcién del proyecto: eae Die Cancelar El elemento azul es visible para el usuario mientras que el blanco se encuentra invisible, si se presiona el link de modificar ambos elementos cambian su visibilidad y el usuario solo ve el formulario, si se presiona cancelar vuelve a su estado inicial.Gestion del Equipo de Proyecto Bs 8 & Agregar Integrante Nombre del Integrante Rol en el Proyecto gah Nombre del Integrante Rol en el Proyecto | ®, a & Interesado Gerente Arquitecto Analista Desarrollador Pruebas Otros O Nombre del Integrante O° O° Oo oO oO oOo Guardar Cancelar Los links de agregar integrante y cancelar cambian la visibilidad de los elementos.Consulta de Proyecto Gestion de Proyecto ; : Gestion del Equipo de Proyecto Ambos elementos se recargan en forma independiente en caso de que el usuario realice alguna modificacion. Esta interfaz se carga en el Area de TrabajoCrear Elementos de los diferentes niveles de Requerimientos * Atributo: |_| ia ld« Paquete: Paauete por defecto \ atibuto:[ | Atributo: [racer cues} Atributo: Hols Guardar } [Lista de paquetes_Y| Los elementos con * son obligatorios. La distribucién de los campos varia para los diferentes niveles. Al presionar en paquete por defecto este cambia por una casilla de seleccidn que contiene los paguetes en los que se puede almacenar. Esta interfaz se carga en el Area de Trabajo Atributo: Atributo: Atributo: HUI Atributo:Consultar Elementos de los diferentes niveles de Requerimientos _— Atributo Atributo Atributo Atributo x Nombre (LW CW Cw Cd a ; Cada requerimiento genera un par de elementos, al hacer click sobre el nombre cambia la visibilidad, esta interfaz se carga en el pa, Area de trabajo y permite a los usuarios modificar la informacién principal de los requerimientos asi como eliminarlos. Cada par de elementos funciona por separado. (FA Enviar Resultado Resultado ResultadoModificar Elementos de los diferentes niveles de Requerimientos atibuto: [valor | * atibuto:| | [] | fx Paquete: eaauete atibuto:[ | atributo: | {If } Modificar } [Lista de paquetes_ “Y Esta interfaz permite a los usuarios cambiar cualquier valor de los requerimientos asi como eliminarlos. Se carga en el Area de Trabajo. j Atributo:Documentos A Enviar a OpenOffice joe | ll Hi ; Atributo: j beat pape fo Nombre Prioridad Iteraciones Req Alta 5 Guardar | Los atributos varian segun el nivel de Requerimiento. Esta interfaz Requerimientos: se carga en el Area de Trabajo.a j Caracteristicas Caracteristica 4 Caracteristica 2 Titulo: —Ssi Guardar | Titulo Autor 96 Contenido del comentarioTrazabilidad Nivel de requerimiento 1 - |Ni |N1 |Ni |N1 |N1 Nivel de Requerimiento 2 N2 = N2 N2 Yd N2 a Existe relacién Bebb Requerimiento padre presenta cambio Requerimiento hijo presenta cambio Ambos Requerimientos presentan cambioGestion de Cambio Proyecto | _ Caracteristicas | Nombre 9° Estatus Usuario Tipo Fecha @ Requerimientos 4 Nombre 9 | Estatus Usuario Tipo Fecha Ss Casos de Uso Nombre 6 Estatus Usuario Tipo Fecha @_ Contrae o expande la lista del cambio segUin sea el caso.Ed Diagrama de Arquitectura: Herramienta Web ‘Capa de Presentacién sdetnegoco Caps de Acceso a Datos Registros de la Base de DatosAvéndicas ~ Avéndice G Manual de Usuario: act 1, Seleccionar e} Proyecto, Ingresar agin Frees Taare Ra - 3. Ingresar clave an Enea sorb suciaar Nuevo Provecto Lo nc eee crcl 1. Ingresar nombre — del proyecto 2. Breve deseripeién. Ss 3. Elegir el equipo sel proyecto, eae ta 8 soa Kaa Fans Apla . © Cals Mane! red Buz * Eta ee 2 (eee Informaciin bisica det ProyectoElementos det Provecto: 1. login osclementos del proyecto ENN que desea gestions. esas 2 Aguisetistanlascarecteristins, |” SYST en ‘euerimietos, casos d uso, < cherstne térino, comentarios, ocumeno oy gga visi, documents de requermientos “= rmen ease el sistema y tazabilidad Sequermersoe 1, Seleccionae News Carocterisica de la barra de meni superior Ingresar los campos obligatorios nombre, deseripeidn, tipo, estarus,priordad, riesgo, origen. Iteracionesplanificadas, ubicacin.or sndice 3. Noes obligatorio completa el resto de los campos que proporcionainformacién eomplementaria sobre la caracteristics. [eae] A, Seleccionar Nuevo Raguerimiento dela barra de mend superior. 2. Ingresar la informacién obligatoria del requerimiento nombre, descripciin, ipo, caracteristica lorigen,priordad, estat, riesgo, teraciones planificadas, ubicacion 13. Si desea comple el resto dela informacidn del requesimiento, Nuown Caso de Uso: a ee a IL. Seleccione la opeién de Nuevo Caso de Uso de la barra de meni superior.del easo de use nombre, deseripetin, requerimionto a, aetores,wbieacion. Sc a HOD Degrees: Tabi ee rnd 20Anéndices — Apéndice debol: ESE 2 Proyucas, 1, Todo Tos elementos del proyecto © Gh vida y Corecerstens ‘se organizan por paquetes en el irbol. FF doasrento de Veen , coracterstcas Estudiantes ‘Si desea realizarse una modificacién spcets se cualquier elemento solo basta con = #4 Recwerinientos del Sstema seleecionarto del arbol. |T Docsmento de Requerimientos G, Requermientos (2 Teezabindad 3. Eldocumento de visién y el documento, Gi regeter Arno ‘de requerimientos del sistema se ab camssde uso erga oe rsricvo pasion o emus G. casos de uso (2 Trazabitdad 1S Ingressr alum 2D) Gosaro @ eas “Be LcaBlarios ID wie 4 Corectersteas ES Recuermientos 1S Cesns deUso Comentarios: Enaactes Bealaacanrae ‘pemacsiums 1, Selecionar WIK/ dl ibel, 2. Selistaranvdas ls caratrsticas,requerimiemas y caso de uso del proyecto, 3 Debe slecionar sobre cul elemento desea realizar el comentario 4. A continuacin se mostarin los comentarios que hay sobre ess elementos y a ops de sereear une nuevo,Avéndices — Apéndioe @ jan sobre el contenido del paquete solo debe presionar ef nombre del el Arbol. én earacteristicas, requerimienios trminos que posea el paquete. descripeién o nombre del paquete solo debe presionar el icone Modificar & cién correspondiente. Documenta de Visién en el paquete Vision y Caractertiieas en el dnbol, Ia informacin necesaria de la Visin del ProyectaAvéndices - Apéndice @ Documenta de Requerinientos det Sistema: DDebe selecionar Documento de Requerimientas en el paquete Reguerimientos de! Sistema en cl comeecsme Fee leachedde Cave: 1. Debe pulsarel enlace ¢Obidé su clave? ES 2. Debe ingresar el nombre de usuario 3. Ingrese la nueva clavey confine, =a mesa1s — Apéndice G Teazabiidad: A, Para observar Ia trazabilidad entre los distintos niveles de requerimientos, sélo debe presionar el claetazabilidad en dbo 2, Semostaran ls relaions y los cambios efetuadosensualguler nivel derequeriients. 3, Para aprobar el cambio solo debe presionar el icono y eonfirmar Ia sprobacién. i