PROPUESTA PARA TRABAJO DE GRADO

Ingeniería de Sistemas PROPUESTA PARA TRABAJO DE GRADO TÍTULO Herramienta para la administración de requerimientos de los proyectos de las asignaturas de ingeniería y arquitectura de software de la pontificia universidad javeriana. MODALIDAD Aplicación practica OBJETIVO GENERAL Diseñar e implementar nuevas funcionalidades en la herramienta ERMT, que ayuden a la administración de los requerimientos y la gestión de riesgos de los mismos, en el proyecto para las materias de ingeniería y arquitectura de software de la pontificia universidad javeriana. ESTUDIANTE Carlos David Duarte Alfonso Documento Celular Teléfono fijo Correo Javeriano cc. 1032439158 DIRECTOR 317 3381469 3690873 carlos.duarte@javeriana.edu.co Ing. Miguel Eduardo Torres Moreno Msc. Documento Celular Teléfono fijo Correo Javeriano Empresa donde trabaja y cargo 3208320 ext 5316 metorres@javeriana.edu.co Pontificia Universidad Javeriana; Profesor Departamento de Sistemas Tabla 1 Propuesta trabajo de grado 5/28/2014

Contenido 1 OPORTUNIDAD O PROBLEMÁTICA...3 1.1 DESCRIPCIÓN DE LA OPORTUNIDAD O PROBLEMÁTICA...3 1.2 FORMULACIÓN...3 1.3 JUSTIFICACIÓN...4 1.4 IMPACTO ESPERADO DEL PROYECTO...4 1.4.1 Corto Plazo... 4 1.4.2 Mediano Plazo... 4 1.4.3 Largo Plazo... 4 2 DESCRIPCIÓN DEL PROYECTO...5 2.1 OBJETIVO GENERAL...5 2.2 OBJETIVOS ESPECÍFICOS...5 2.3 ENTREGABLES O RESULTADOS ESPERADOS...5 3 PROCESO...7 3.1 FASE METODOLÓGICA 1...7 3.1.1 Metodología... 7 3.1.2 Actividades... 7 3.1.3 Entregables... 8 3.2 FASE METODOLÓGICA 2...8 3.2.1 Metodología... 8 3.2.2 Actividades... 8 3.2.3 Ejecución de la iteración (Sprint)... 9 3.2.4 Demostración de requerimientos completados (Sprint Review)... 9 3.2.5 Lista de tareas de la iteración (Sprint Backlog)... 9 3.2.6 Entregables... 9 4 GESTIÓN DEL PROYECTO...11 4.1 ESTIMACIÓN DE LA DURACIÓN DEL PROYECTO (ELABORACIÓN DEL CRONOGRAMA)11 4.2 ESTIMACIÓN DEL COSTO DEL PROYECTO (PRESUPUESTO)...13 4.3 ESTIMACIÓN DE LOS RIESGOS DEL PROYECTO (ANÁLISIS DE RIESGOS)...14 5 MARCO TEÓRICO / ESTADO DEL ARTE...16 5.1 TRABAJOS IMPORTANTES EN EL ÁREA...16 5.2 DOFA DE LAS HERRAMIENTAS TECNOLÓGICAS EXISTENTES ACTUALMENTE Y QUE INTENTAN RESOLVER EL PROBLEMA...19 5.2.1 Debilidades... 19 5.2.2 Fortalezas... 19 5.2.3 Oportunidades... 19 5.2.4 Amenazas... 20 Página 1

5.3 FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO...20 5.3.1 Gestión de riesgos... 20 5.3.2 Gestión de requerimientos... 21 5.4 MARCO INSTITUCIONAL...21 5.5 GLOSARIO...21 6 REFERENCIAS Y BIBLIOGRAFÍA...23 6.1 REFERENCIAS...23 6.2 BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO...24 Tabla de Ilustraciones Tabla 1 Propuesta trabajo de grado... 1 Tabla 2 Cronograma... 12 Tabla 3 Presupuesto... 13 Tabla 4 Control de riesgos... 15 Página 2

1 Oportunidad o Problemática 1.1 Descripción de la Oportunidad o Problemática Los requerimientos son una especificación de lo que debe ser implementado. Estos son descripciones de cómo el sistema se debe comportar, de las propiedades y atributos del mismo. Deben ser una restricción del proceso de desarrollo del sistema. [1] Ya definido lo que significa un requerimiento, es importante conocer los inconvenientes que existen alrededor de este tema, empezando que en la actualidad aún es común ver problemas con la gestión de requerimientos en un proyecto de software y que en últimas circunstancias determina el éxito o no del producto.[4] Debido a que no se realiza un manejo adecuado sobre los procesos de comprender y controlar los cambios de los requerimientos, esto genera así una gran cantidad de inconvenientes como: retrasos, baja calidad, inconsistencias, cambios, entre otros, que influyen sobre el producto final [2]. Es por esta razón, que es necesario afrontar este problema mediante una herramienta de software que ayude a mitigar o disminuir los índices de esta mala gestión de los requerimientos en este tipo de proyectos. Esta mala gestión de los requerimientos ya mencionada, también se ve reflejada en un ambiente educativo, más específicamente en las materias de ingeniería y arquitectura de software de la pontificia universidad javeriana, ya que los estudiantes de estas asignaturas deben desarrollar a lo largo del semestre un software que cumpla con los requisitos pedidos de los stakeholders y afrontando los problemas ya mencionados, pero con el valor agregado que los estudiantes no cuentan a disposición de una herramienta de este estilo que les permita afrontar de una mejor manera los requerimientos de sus proyectos. [6] 1.2 Formulación Cómo puede una herramienta de administración de requerimientos, permitir la gestión y el manejo de los riesgos en los requerimientos de un proyecto de ingeniería de software y arquitectura de software de la Pontificia Universidad Javeriana? Página 3

1.3 Justificación Hoy en día existen gran variedad herramientas para la administración de requerimientos en el mercado, pero sus costos de licencia son muy altos, además la funcionalidades que maneja son para las necesidades empresariales y no académicas, es por esta razón que los estudiantes no pueden acceder a estas, además no se justifica adquirir un software tan costoso cuando el proyecto se realiza en cuatro meses aproximadamente [12]. Luego de comprender el contexto que se enfrentan los estudiantes, es necesario continuar con el desarrollo de esta herramienta y agregarle nuevas funcionalidades que permitan complementar el análisis que se realiza, debido a que si no se realiza una adecuada gestión de los requerimientos, la probabilidad de no tener éxito en un proyecto aumenta considerablemente generando así retrasos, sobrecostos, disminución de la calidad y cambios inesperados. Además este trabajo de grado pretende aportar en el desarrollo científico y tecnológico que necesita el país como parte de la misión que tiene la pontificia universidad javeriana para la sociedad. 1.4 Impacto Esperado del Proyecto 1.4.1 Corto Plazo El impacto a corto plazo esperado de este trabajo de grado es que los estudiantes de ingeniería y arquitectura de software puedan utilizar ERMT como una herramienta que les permita el manejo de los requerimientos en sus proyectos, sin la necesidad de adquirir software empresarial. 1.4.2 Mediano Plazo El impacto a mediano plazo para este trabajo de grado, es que instituciones educativas ajenas a la javeriana, puedan brindarles a los estudiantes ERMT, que les permita el manejo de los requerimientos en sus respectivos proyectos. 1.4.3 Largo Plazo El impacto a largo plazo para este trabajo de grado, es que ERMT pueda utilizarse en un entorno empresarial, es decir, en empresas que desarrollen software, que les permita el manejo de los requerimientos. Página 4

2 Descripción del Proyecto La idea de este trabajo de grado consiste en continuar con el desarrollo de una herramienta de administración de requerimientos que ya existe y fue desarrollada previamente por estudiantes de la carrera de ingeniería de sistemas de la pontificia universidad javeriana [6]. Para esto es necesario complementar el análisis que se realiza a los requerimientos, ya que la herramienta ERMT (Easy Requirements Management Tool) solo se enfoca en la priorización de requerimientos dejando a un lado otras funcionalidades (Análisis de calidad, Análisis de viabilidad, Análisis de riesgos y gestión) que permitirían un mejor análisis sobre estos. 2.1 Objetivo general Diseñar e implementar nuevas funcionalidades en la herramienta ERMT, que ayuden a la administración de los requerimientos y la gestión de riesgos de los mismos, en el proyecto para las materias de ingeniería y arquitectura de software de la pontificia universidad javeriana. 2.2 Objetivos específicos Investigar y analizar las herramientas existentes en el mercado, además de los estándares de calidad de requerimientos, que permita conocer las funcionalidades mínimas que debe tener ERMT. Modificar la arquitectura existente, que permita a ERMT soportar las nuevas funcionalidades de administración y gestión de los riesgos para los requerimientos. Implementar las nuevas funcionalidades propuestas de acuerdo a la modificación del diseño arquitectónico de ERMT. Realizar las pruebas de usabilidad a ERMT. 2.3 Entregables o Resultados Esperados A continuación se muestran los entregables que se van a entregar, basándose en el tipo de trabajo de grado que se va a entregar: Memoria Plan de Gestión de Proyectos de Software (SPMP) Documento de especificación de requerimientos (SRS). Documento de Descripción de la arquitectura (SDD). Herramienta de software funcional. Página 5

Manuales de Usuario. Reporte de pruebas de software. Página 6

3 Proceso Para la realización de este trabajo de grado, se va a escoger dos fases metodologías que permitirán cumplir los objetivos propuestos anteriormente. La primera fase metodológica consiste en una exploración y la segunda fase metodológica es la ejecución de SCRUM [7]. 3.1 Fase Metodológica 1 La primera fase metodológica consiste en una exploración debido a que el primer objetivo específico tiene como propósito realizar un estudio y un análisis acerca de ERMT, además que permitirá conocer más en detalle la problemática que se quiere afrontar, realizando así una investigación más completa. 3.1.1 Metodología La metodología a usar en esta fase, es la de realizar un estudio exploratorio sobre las herramientas existentes en el mercado, la herramienta ERMT y realizar un análisis detallado de los estándares de calidad de requerimientos. 3.1.2 Actividades Las actividades a realizar en esta fase con las siguientes: Investigar la mayor cantidad de herramientas para la administración de requerimientos que existen en el mercado. Conocer y entender las características y funcionalidades que ofrecen estas herramientas. Comparar las funcionalidades de ERMT frente a las herramientas existentes en el mercado. Investigar y analizar los diferentes estándares de calidad de requerimientos, para determinar que funcionalidades se le pueden agregar a la herramienta. Definir qué funcionalidades le hacen falta a ERMT para complementarla, además que estén dentro del alcance y sirvan para un entorno educativo. Elaboración del marco teórico del tema. Página 7

Conocer y entender la arquitectura que tiene ERMT. 3.1.3 Entregables Luego de realizar las actividades relacionadas con esta fase, se espera como resultado el documento de plan de gestión de proyectos de software y las nuevas adiciones para ERMT. 3.2 Fase Metodológica 2 La segunda fase metodológica consiste en la ejecución de la metodología SCRUM, que permitirá abarcar los restantes objetivos específicos, donde se modificará la arquitectura existente, y esta a su vez soporte las nuevas funcionalidades que se van a implementar, realizando sus respectivas pruebas de usabilidad del producto. 3.2.1 Metodología La metodología a usar en esta fase metodológica es SCRUM, ya que esta permite realizar una gestión en el desarrollo del software, además está basada en un proceso iterativo e incremental, acoplándose de manera correcta a las actividades propuestas para esta fase ya que una actividad posterior depende de las actividades anteriores. 3.2.2 Actividades Las actividades a realizar en esta fase con las siguientes: Elaboración de los casos de uso. Realizar la especificación de requerimientos. Elaborar el Documento de Requerimientos de Software (SRS). Elaboración de la arquitectura del sistema. Elaboración del diseño por componentes del sistema. Elaboración del Documento de Diseño del Sistema (SDD). Desarrollo e implementación de las nuevas funcionalidades. Realizar las pruebas de usabilidad. Página 8

Analizar los resultados de las pruebas de usabilidad. Elaboración manual de usuario. Elaboración de memoria final del trabajo de grado. Elaboración de página web de trabajo de grado. Para llevar de manera oportuna la metodología SCRUM es necesario llevar a cabo las siguientes actividades: 3.2.3 Ejecución de la iteración (Sprint) Cada vez que finalice una actividad propuesta, es necesario que se lleve una reunión con el director del trabajo de grado, para poder evaluar cada una de estas actividades ya realizadas, para luego realizar las correcciones necesarias. 3.2.4 Demostración de requerimientos completados (Sprint Review) Esta actividad que ofrece SCRUM, permite realizar una entrega informal de los requerimientos ya terminados en una actividad al cliente, que en este contexto es el director del trabajo de grado, la cual permitirá conocer si realmente se están entendido lo que el cliente quiere, además de realizar mejoras en esta entrega si es necesario y si cumple con sus expectativas. 3.2.5 Lista de tareas de la iteración (Sprint Backlog) Esta lista de tareas permite visualizar el estado actual de las actividades programadas en cada iteración, la cual permitirá realizar una trazabilidad a estas, conocer si se han tenido problemas, retrasos, avance del proyecto y el esfuerzo en horas para la realización de cada una de las tareas. 3.2.6 Entregables Luego de realizar las actividades relacionadas con esta fase, se espera como resultado: El documento de requerimientos de software. Documento de diseño del sistema. Resultados pruebas de usabilidad. Manual de usuario. Memoria final. Página 9

Software funcional. Página web del trabajo de grado. Página 10

4 Gestión del Proyecto 4.1 Estimación de la duración del Proyecto (Elaboración del Cronograma) Para el desarrollo de la totalidad del trabajo de grado se dispone de 17 semanas desde que comienza el periodo que comprende el primer semestre de 2014 hasta que termina el mismo. Durante todo el tiempo comprendido en el periodo mencionado anteriormente. Cronograma Semana Actividad Duración (Horas) 1 Investigar la mayor cantidad de herramientas para la administración de requerimientos que existen en el mercado. 1 Conocer y entender las características y funcionalidades que ofrecen estas herramientas. 2 Comparar las funcionalidades de ERMT frente a las herramientas existentes en el mercado. 2 Investigar y analizar los diferentes estándares de calidad de requerimientos, para determinar que funcionalidades se le pueden agregar a la herramienta. 3 Definir qué funcionalidades le hacen falta a ERMT para complementarla, además que estén dentro del alcance y sirvan para un entorno educativo. 4 Elaboración del marco teórico del tema. 30 5 Conocer y entender la arquitectura que tiene ERMT. 15 15 25 18 22 15 Página 11

6 Elaboración documento SPMP 30 6 Elaboración de los casos de uso. 25 7 Realizar la especificación de requerimientos. 8 Elaborar el Documento de Requerimientos de Software (SRS). 9 Elaboración de la arquitectura del sistema. 35 10 Elaboración del diseño por componentes del sistema. 11 Elaboración del Documento de Diseño del Sistema (SDD). 12 Desarrollo e implementación de las nuevas funcionalidades. 12 Realizar las pruebas de usabilidad. 45 13 Analizar los resultados de las pruebas de usabilidad. 14 Elaboración manual de usuario. 25 15 Elaboración de memoria final del trabajo de grado. 16 Elaboración de página web de trabajo de grado. 20 30 30 25 60 20 30 30 Total 545 Tabla 2 Cronograma Página 12

4.2 Estimación del costo del Proyecto (Presupuesto) A continuación se muestra la matriz de costos del proyecto: Presupuesto Ítem Cantidad Costo por Unidad Total Recurso ingeniero de sistemas Recurso director de trabajo de grado Computador personal del ingeniero Costo de créditos por concepto de matricula Otros costos (buses, almuerzos, servicios) 545 Horas $ 30.000 $ 16.350.000 40 $ 75.000 $3.000.000 Horas 1 Portátil $2.000.000 $2.000.000 4 Créditos $ 401.000 $1.604.000 6 Meses $ 320.000 $ 1.920.000 Total $ 24.874.000 Tabla 3 Presupuesto Página 13

4.3 Estimación de los riesgos del Proyecto (Análisis de riesgos) A continuación se muestra la matriz de control de riesgos, donde se confronta los posibles riesgos que pueden ocurrir en el transcurso del desarrollo del trabajo de grado y como se van a mitigar dado el caso que ocurran. Control de Riesgos Riesgos Técnicas de Mitigación Definición del alcance equivocada Tiempo Insuficiente Problemas Personales Requisito de Ingles Entregar documentos y prototipos Reuniones previas con el director o con otros profesores especialistas en la materia, que puedan dar una aproximación del alcance, además definir muy cada alcance de los requerimientos. Calcular muy bien los tiempos en que se va a ejecutar cada actividad, para ello hay que definir muy bien el cronograma e ir supervisando periódicamente las fechas establecidas. Separar lo más posible los problemas personales con el trabajo de grado, para que esto no influya en los tiempos establecidos ni en la calidad del trabajo. Realizar los créditos faltantes, mediante cursos intensivos y cursos vacacionales dentro de la universidad, que permitan cumplir con el requisito. Para ello es importante realizar listas de chequeo antes de cada entrega Página 14

sin revisión final No entender la arquitectura existente Imposibilidad de realizar pruebas de usuario Falla del equipo por parte del estudiante, además reuniones previas con el director. Leer muy detalladamente el manual de usuario, dado el caso en que no se pueda comprender algún componente de ERMT, enviar correos electrónicos a las estudiantes que desarrollaron la herramienta y reuniones con el director. Es importante realizar las pruebas de usuario, para esto es primordial incentivar a los estudiantes para la utilización de ERMT en sus proyectos de ingeniería y arquitectura de software. Realizar periódicamente revisiones técnicas al equipo, además de realizar un back-up sobre toda la información referente al trabajo de grado. Tabla 4 Control de riesgos Página 15

5 Marco Teórico / Estado del Arte 5.1 Trabajos Importantes en el área En el mercado actualmente existen gran variedad de herramientas para la administración de los requerimientos en un proyecto de software, pero este tipo de software se enfoca primordialmente en un entorno empresarial. A continuación se muestran dos herramientas muy conocidas en el mercado y con sus respectivas funcionalidades y que son usadas frecuentemente en la realización de proyectos de software: La primera herramienta es Rational Doors de IBM. Estas son sus funcionalidades y características [8]: Gestión de requerimientos Gestiona los documentos de requerimientos mediante un repositorio central desde el que trabajan todos los usuarios. Proporciona acceso a las funciones completas de edición, configuración, análisis y creación de informes a través de un cliente de escritorio. Admite el formato de intercambio de requerimientos (RIF), que permite a los proveedores y a los colaboradores en desarrollo contribuir en los documentos, secciones o atributos de requerimientos que pueden remontarse a los requerimientos centrales. Registra y muestra texto de requerimientos, gráficos, tablas, atributos de requerimientos, barras de cambio y enlaces de rastreabilidad, entre otros. Rastreabilidad Permite arrastrar y soltar elementos para vincular un requerimiento a un elemento de diseño, a un caso de prueba o a otro requerimiento. Permite seleccionar los requerimientos de una lista o especificar números de requerimientos como atributos y que Rational DOORS haga los enlaces en su lugar. Proporciona informes completos de rastreabilidad en una única vista para ayudar a priorizar el trabajo de desarrollo de forma eficiente y a prever el tiempo de entrega. Página 16

Da soporte a enlaces externos que permiten que los requerimientos se asocien directamente a la información de fuera del dominio de Rational DOORS. Escalabilidad Ofrece una jerarquía de tipo explorador con varios niveles de carpetas y proyectos para la navegación simple, sin importar cuanto crezca la base de datos. Incluye vistas configurables y documentos compartibles, que permite a los usuarios trabajar de forma simultánea para generar un único documento. Test Tracking Toolkit Le permite crear enlaces desde requerimientos a pruebas. Define casos de prueba, registros y compara ejecuciones de pruebas. Garantiza que los casos de prueba cubran todos los requerimientos. Integraciones Se integra con software de gestión de cambios de Rational para el control de cambios de requerimientos y para la gestión de flujo de trabajo de requerimientos. Se integra con otras soluciones de Rational, incluidas IBM Rational Quality Manager, IBM Rational Rhapsody e IBM Rational Focal Point, entre otras. Se integra con HP QualityCenter para obtener visibilidad de los requerimientos y crear casos de prueba para la rastreabilidad y la generación de informes de estado sobre el cubrimiento de los requerimientos por parte de los casos de prueba. Se integra con Microsoft Team Foundation Server (TFS) para permitir equipos de desarrollo que utilizan Microsoft Visual Studio para crear y mantener la rastreabilidad entre los requerimientos de Rational DOORS y TFS Work Items en Visual Studio. Página 17

La segunda herramienta es CaliberRm. Estas son sus funcionalidades y características [10]: Sistema de gestión de requerimientos completo: Proporciona un repositorio central seguro para gestionar los requerimientos de los proyectos a través del ciclo de vida de la aplicación, mejorando la comunicación a través de todos los participantes para establecer una visión consistente desde el principio del proyecto. Las capacidades sin par de edición aseguran que los usuarios puedan escribir requisitos usando su formato preferido incluyendo casos de uso, escenarios, storyboards, definiciones funcionales, y documentos del diseño. Procesos de gestión de requisitos personalizable: se puede modificar fácilmente para soportar procesos de gestión de requisitos particulares, asegurando que las organizaciones y los equipos conserven control y trabajen en la manera que desean trabajar. Estimación basada en los requerimientos: Las potentes capacidades de estimación basadas en los requerimientos ayudan a los gestores a planificar el alcance del proyecto, agenda, y recursos a través del ciclo de vida del desarrollo del software con gran exactitud. Enlazando el alcance del proyecto, agenda, y coste con la asignación de recursos y la gestión de riesgo, cuando una variable cambia, el impacto en otras variables se puede determinar inmediatamente. Gestión integrada del ciclo de vida de la aplicación: La trazabilidad de los requisitos a través del proceso de desarrollo resulta ser el mejor control del proyecto. La arquitectura abierta de CaliberRM permita enlazar directamente los requerimientos con una variedad de aplicaciones - tales como gestiones de configuración de software. Esto mantiene a todos los miembros del equipo enfocados y actualizados para acelerar la producción. Análisis de impacto: La visualización de la trazabilidad ayuda a los usuarios a evaluar el alcance de los cambios de requisitos. El rastro revela cómo los cambios afectan a los requisitos, tareas, pruebas y/o código de fuente, permitiendo el análisis en tiempo real. Página 18

5.2 DOFA de las Herramientas tecnológicas existentes actualmente y que intentan resolver el problema 5.2.1 Debilidades Los costos de licencia para adquirir alguna de las herramientas existentes en el mercado son muy costosas, impidiendo que las pequeñas y medianas empresas puedan acceder a este software. La integración con los diferentes componentes de una empresa puede ser bastante complicada, si esta no cuenta con una debida especificación de sus procesos de negocio. La complejidad de estas herramientas en algunos casos pueden generar inconvenientes o retrasos, debido a que se necesita capacitar a las personas que están directamente relacionadas con el manejo del software. 5.2.2 Fortalezas Las empresas que venden estas herramientas tienen una gran experiencia en el desarrollo y gestión proyectos de software, que esto a su vez da un alto grado de credibilidad y de acierto en el momento de analizar los resultados y conclusiones. Estas herramientas ofrecen una gran variedad de funcionalidades y características que las hacen ser muy completas y de gran utilidad si se utiliza de manera adecuada a las necesidades específicas. Las empresas que venden estas herramientas tienen un gran equipo de talento humano, que a menudo realizan distintas investigaciones e innovaciones sobre el producto y los servicios prestados. 5.2.3 Oportunidades Pueden tener un gran mercado potencial si pueden disminuir los cotos de licencias en sus herramientas o brindarán una solución económica que permita abarcar a las pequeñas y medianas empresas. Estas empresas pueden ofrecer un producto para un ambiente educativo que permita a los estudiantes tener una proximidad en un entorno más real, que a futuro permita a estas personas adquirir el producto empresarial o se les facilite la utilización de estas herramientas. Página 19

5.2.4 Amenazas Las herramientas proporcionadas son altamente productivas y beneficiosas en un proyecto de software siempre y cuando las personas que usan directamente el software definan de manera correcta los requerimientos y la herramienta en su conjunto. 5.3 Fundamentos y conceptos relevantes para el proyecto 5.3.1 Gestión de riesgos La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con llevar a cabo la planificación de la gestión, la identificación, el análisis, la planificación de respuesta a los riesgos, así como su monitoreo y control en un proyecto. Los objetivos de la Gestión de los Riesgos del Proyecto son aumentar la probabilidad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos negativos para el proyecto. Los procesos de gestión de los riesgos de un proyecto, son los siguientes: Planificar la Gestión de Riesgos: Es el proceso por el cual se define cómo realizar las actividades de gestión de los riesgos para un proyecto. Identificar los Riesgos: Es el proceso por el cual se determinan los riesgos que pueden afectar el proyecto y se documentan sus características. Realizar el Análisis Cualitativo de Riesgos: Es el proceso que consiste en priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos. Realizar el Análisis Cuantitativo de Riesgos: Es el proceso que consiste en analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto. Planificar la Respuesta a los Riesgos: Es el proceso por el cual se desarrollan opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Monitorear y Controlar los Riesgos: Es el proceso por el cual se implementan planes de respuesta a los riesgos, se rastrean los riesgos identificados, se monitorean los riesgos residuales, se identifican nuevos riesgos y se evalúa la efectividad del proceso contra riesgos a través del proyecto [13]. Página 20

5.3.2 Gestión de requerimientos Definición La gestión de requerimientos es el conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requerimientos y sus cambios en cualquier momento. Es decir, la gestión de requerimientos consiste en gestionar los cambios de los requerimientos, las relaciones entre ellos, las dependencias entre la especificación de requerimientos y otros documentos producidos por el proceso de desarrollo de software. De esta forma se asegura la consistencia entre los requerimientos y el sistema construido. Por lo tanto, los objetivos principales del proceso de gestión de requisitos serán: Gestionar la recogida de requerimientos Obtener la aprobación de los participantes del proyecto Gestionar los cambios (trazabilidad) La gestión de requisitos es un proceso que se desarrolla a lo largo de toda la vida del producto [14]. 5.4 Marco Institucional Pontificia Universidad Javeriana, Bogotá, Colombia Facultad de ingeniería Departamento ingeniería de sistemas Director trabajo de grado: Ing. Miguel Eduardo Torres Moreno Msc. Proyecto de grado a cargo del estudiante: Carlos David Duarte Alfonso Ingeniería de sistemas Semestre 10 5.5 Glosario Scrum: Scrum es un framework de desarrollo ágil de software. El trabajo es estructurado en ciclos de trabajo llamados sprintes, iteraciones de trabajo con una duración típica de dos a cuatro semanas. Durante cada sprint, los equipos eligen de una lista de requerimientos de cliente priorizados, llamados historias de usuarios, para que las características que sean desarrolladas Página 21

primero sean las de mayor valor para el cliente. Al final de cada sprint, se entrega un producto potencialmente distribuible. [7] Análisis DOFA: Es ayudar a una organización a encontrar sus factores estratégicos críticos, para una vez identificados, usarlos y apoyar en ellos los cambios organizacionales: consolidando las fortalezas, minimizando las debilidades, aprovechando las ventajas de las oportunidades, y eliminando o reduciendo las amenazas. [5] Stakeholders: Son todas aquellas personas que se ven afectadas por el desarrollo y/o despliegue del proyecto. [1] Página 22

6 Referencias y Bibliografía La norma que se usó para la realización de la bibliografía y las referencias en el trabajo de grado es la IEEE, ya que la he usado en el transcurso de la carrera en diferentes trabajos presentados. 6.1 Referencias [1] Ingeniería del Software, IAN SOMMERVILLE, Séptima edición, 2005, pag 105-126. [2] H. F. Hofmann, Requirements Engineering: A Situated Discovery Process. Deutscher Universitats Verlag. [3] J. M. Carrillo de Gea, J. Nicolás, J. L. Fernández Alemán, A. Toval, C. Ebert, and A. Vizcaíno, Requirements engineering tools: Capabilities, survey and assessment, Information and Software Technology, vol. 54, no. 10, pp. 1142 1157, Oct. 2012. [4] The Curious Case of the CHAOS Report 2009. [Online]. Available: http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report- 2009.html. [5] Análisis DAFO. [Online]. Available: http://www.guiadelacalidad.com/modelo-efqm/analisis-dafo. [6] ERMT. [Online]. Available: http://pegasus.javeriana.edu.co/~cis1010is05/index.html. [7] Scrum Alliance - What Is Scrum? [Online]. Available: http://www.scrumalliance.org/pages/what_is_scrum. [8] IBM - Rational DOORS - Spain. [Online]. Available: http://www- 142.ibm.com/software/products/es/es/ratidoor/. [9] IBM - Rational RequisitePro - Spain. [Online]. Available: http://www- 142.ibm.com/software/products/es/es/reqpro/. [10] IT TOOLS LTDA. - Caliber RM. [Online]. Available: http://www.ittoolsltda.com/productos/16-borland/29-caliber-rm. [11] Visure Requirements Tool -Complete Feature List - Visure Solutions. [Online]. Available: http://www.visuresolutions.com/visure-requirements-toolcomplete-feature-list. [12] Systems and software engineering Developing user documentation in an agile environment, ISO/IEC/IEEE 26515 First edition 2011-12-01; Corrected version 2012-03-15, pp. 1 36, 15. Página 23

[13] Standards Overview Project Management Institute. [Online]. Available: http://www.pmi.org/pmbok-guide-and-standards.aspx. [14] Introducción a la gestión de requerimientos. [Online]. Available: http://www.mat.uson.mx/mireles/introgestionreq_archivos/frame.htm. 6.2 Bibliografía Propuesta para el desarrollo del Trabajo de Grado [1] H. Sugimoto and A. Ohnishi, A detecting and interpreting method of the inconsistency of software requirements specifications, in Software Engineering Conference, 1999. (APSEC 99) Proceedings. Sixth Asia Pacific, 1999, pp. 208 215. [2] H. Mei, W. Zhang, and F. Gu, A feature oriented approach to modeling and reusing requirements of software product lines, in Computer Software and Applications Conference, 2003. COMPSAC 2003. Proceedings. 27th Annual International, 2003, pp. 250 256. [3] A. Perini, A. Susi, and P. Avesani, A Machine Learning Approach to Software Requirements Prioritization, IEEE Transactions on Software Engineering, vol. PP, no. 99, p. 1, 2012. [4] R. Cerón, J. C. Dueñas, E. Serrano, and R. Capilla, A meta-model for requirements engineering in system family context for software process improvement using CMMI, in Proceedings of the 6th international conference on Product Focused Software Process Improvement, Berlin, Heidelberg, 2005, pp. 173 188. [5] R. Mojdehbakhsh, S. Subramanian, R. Vishnuvajjala, W.-T. Tsai, and L. Elliott, A process for software requirements safety analysis, in, 5th International Symposium on Software Reliability Engineering, 1994. Proceedings, 1994, pp. 45 54. [6] Withall, S. Software Requirements Patterns. Primera Edición. Microsoft Press 2007. [7]. Heim P, Lohmann S, Lauenroth K, Ziegler J. Graph-based Visualization of Requirements Relationships. [8]. Gotel O, M ader P. How to select a requirements Management Tool: Initial Steps. [9]. Hoffmann M, Kühn N, Weber M, Bittner M. Requirements for Requirements Management Tools. Página 24

[10]. Heinonen, S. Requirements Management tool support for software engineering in collaboration. [11]. Hood, C. Wiedemann, S. Fichtinger, S. Pautz, U. Requirements Management: The Interface Between Requirements Development and All Other Systems Engineering Processes. Springer, 2008. [12] Matulevicius R. Prototype of the evaluation framework for functional requirements of RE-tools. [13] M. Kamalrudin, Automated Software Tool Support for Checking the Inconsistency of Requirements, in 24th IEEE/ACM International Conference on Automated Software Engineering, 2009. ASE 09, 2009, pp. 693 697. [14] I. Hussain, O. Ormandjieva, and L. Kosseim, LASR: A tool for large scale annotation of software requirements, in 2012 IEEE Second International Workshop on Empirical Requirements Engineering (EmpiRE), 2012, pp. 57 60. [15] J. R. McCoy, NASA software tools for high-quality requirements engineering, in Software Engineering Workshop, 2001. Proceedings. 26th Annual NASA Goddard, 2001, p. 69. [16] Wiegers, Karl. First Things First: Prioritizing Requirements. [Articulo] 1999. [17] SWEBOK en Español. Capítulo 2. Requerimientos de Software. [HomePage] Disponible en: www.swebok.org Página 25