pegasus.javeriana.edu.copegasus.javeriana.edu.co/.../memoria/memoria.docx · web viewel trabajo...
TRANSCRIPT
CIS1010IS05HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS
DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA DE SOFTWARE DE LA PONTIFICIA UNIVERSIDAD
JAVERIANA.
http://pegasus.javeriana.edu.co/~CIS1010IS05/
VANESA CAROLINA LOAIZA CARVAJALLAURA CATALINA ZORRO JIMÉNEZ
PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.
2011
Memoria de Trabajo de Grado - ISTAR
CIS1010IS05HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA DE
SOFTWARE DE LA PONTIFICIA UNIVERSIDAD JAVERIANA.
Autor(es):
Vanesa Carolina Loaiza CarvajalLaura Catalina Zorro Jiménez
MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE SISTEMAS
Director
Miguel Eduardo Torres Moreno
Jurados del Trabajo de Grado
María Mercedes Corral
Jaime Andrés Pavlich Mariscal
Vanesa Carolina Loaiza Carvajal
Laura Catalina Zorro Jiménez
Página web del Trabajo de Grado
http://pegasus.javeriana.edu.co/~CIS1010IS05/
PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.
Enero, 2011
Página i
Memoria de Trabajo de Grado - ISTAR
PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
Rector Magnífico
Joaquín Emilio Sánchez García S.J.
Decano Académico Facultad de Ingeniería
Ingeniero Francisco Javier Rebolledo Muñoz
Decano del Medio Universitario Facultad de Ingeniería
Padre Sergio Bernal Restrepo S.J.
Directora de la Carrera de Ingeniería de Sistemas
Ingeniero Luis Carlos Díaz Chaparro
Director Departamento de Ingeniería de Sistemas
Ingeniero César Julio Bustacara Medina
Página ii
Memoria de Trabajo de Grado - ISTAR
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de
grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no
contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar
la verdad y la Justicia”
Página iii
Memoria de Trabajo de Grado - ISTAR
AGRADECIMIENTOS
Agradecemos a nuestro director, el Ingeniero Miguel Eduardo Torres Moreno por permitirnos
realizar este proyecto, por su paciencia, consejos, regaños y apoyo durante todo este proceso.
A Laura, por la paciencia que me tuvo en algunos momentos críticos, además gracias por el gran equipo
que tuvimos en aquellas noches largas, y también por su apoyo y dedicación a este proyecto. A mis
padres, porque sin ellos no podría haber estudiado, por brindarme su apoyo incondicional, su amor y
paciencia en los momentos de debilidad. A mi prima y hermanos, que me acompañaron y me brindaron
un poco de alegría. A mis amigos, que me apoyaron y que hacían que recuperara la confianza para seguir
adelante.
VANESA CAROLINA LOAIZA CARVAJAL.
A Carolina, por los buenos momentos que pasamos desarrollando el proyecto, sobre todo en esas largas
trasnochadas. A mi madre Gloria Stella, por su apoyo incondicional, por creer en mí, por darme la
oportunidad de vivir y de cumplir este sueño y sobre todo por soportarme en esta etapa tan difícil. A mis
amigos, que aunque sin notarlo lograron dibujar una sonrisa en mí hasta en los peores momentos.
LAURA CATALINA ZORRO JIMÉNEZ
Página iv
Memoria de Trabajo de Grado - ISTAR
CONTENIDO
I. DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO...............................................................12
1. Oportunidad, Problemática, Antecedentes.......................................................................................12
1.1. Descripción del contexto..........................................................................................................12
1.2. Problema a Resolver.................................................................................................................13
1.3. Justificación..............................................................................................................................13
1.4. Impacto Esperado.....................................................................................................................15
II. Descripción del Proyecto......................................................................................................................16
1. Visión global.....................................................................................................................................16
2. Objetivo General...............................................................................................................................16
3. Fases Metodológicas.........................................................................................................................16
4. Método Propuesto.............................................................................................................................17
4.1. Identificar..................................................................................................................................17
4.2. Elaborar - diseñar......................................................................................................................17
4.3. Desarrollar y verificar...............................................................................................................18
III. POST-MORTEM..............................................................................................................................19
1. Metodología propuesta vs. Metodología realmente utilizada...........................................................19
2. Actividades propuestas vs. Actividades realizadas..........................................................................19
3. Efectividad en la estimación de tiempos del proyecto......................................................................20
4. Costo estimado vs. Costo real del proyecto......................................................................................21
5. Efectividad en la estimación y mitigación de los riesgos del proyecto............................................22
IV. MARCO TEORICO.........................................................................................................................23
1. ¿QUÉ ES UN REQUERIMIENTO?................................................................................................23
2. ¿QUÉ TIPO DE REQUERIMIENTOS EXISTEN?.........................................................................24
Página v
Memoria de Trabajo de Grado - ISTAR
3. ¿QUÉ ES LA INGENIERÍA DE REQUERIMIENTOS?................................................................25
3.1. Recolección...............................................................................................................................26
3.2. Análisis.....................................................................................................................................27
3.3. Especificación...........................................................................................................................27
3.4. Verificación..............................................................................................................................29
4. ¿QUÉ ES LA ADMINISTRACIÓN DE REQUERIMIENTOS?....................................................29
4.1. El Proceso de Administración de Requerimientos...................................................................30
4.2. Beneficios de la administración de requerimientos..................................................................49
4.3. HERRAMIENTAS...................................................................................................................52
V. DESARROLLO DEL TRABAJO........................................................................................................55
1. Fase Investigativa.............................................................................................................................55
1.1. Investigación de herramientas para la administración de requerimientos................................55
1.2. Investigación de los procesos de la administración de requerimientos....................................56
1.3. Entrevistas y encuestas.............................................................................................................56
2. Fase de Elaboración..........................................................................................................................57
2.1. Fase de recolección...................................................................................................................57
2.2. Fase de Especificación y Análisis.............................................................................................57
2.3. Fase de Diseño..........................................................................................................................57
2.4. Fase de Implementación...........................................................................................................58
2.5. Fase de Pruebas.........................................................................................................................60
VI. RESULTADOS Y REFLEXION SOBRE LOS MISMOS..............................................................62
1. Easy Requierement Management Tool.............................................................................................62
2. Resultados de las Pruebas.................................................................................................................63
2.1. Características del caso de estudio...........................................................................................63
Página vi
Memoria de Trabajo de Grado - ISTAR
2.2. Resultados obtenidos................................................................................................................64
3. Reporte de pruebas...........................................................................................................................73
VII. CONCLUSIONES Y TRABAJOS FUTUROS................................................................................74
1. Conclusiones.....................................................................................................................................74
2. Trabajos Futuros...............................................................................................................................75
VIII. REFERENCIAS Y BIBLIOGRAFIA..............................................................................................77
IX. ANEXOS..........................................................................................................................................83
1. Anexo 1: Documento de Visión.......................................................................................................83
2. Anexo 2: Documento de Especificación de Requerimientos...........................................................83
3. Anexo 3: Documento de Diseño.......................................................................................................83
4. Anexo 4: Marco Teórico...................................................................................................................83
5. Anexo 5: Documento de Pruebas.....................................................................................................83
6. Anexo 6: Presupuestos......................................................................................................................83
7. Anexo 7:Entrevista...........................................................................................................................83
8. Anexo 8: Documento de casos de uso..............................................................................................83
Página vii
Memoria de Trabajo de Grado - ISTAR
ABSTRACT
According to statistics release by The Standish Group [7] in 2009, the successful development of software
projects, has been reduced to 32%, and the most frequent causes are related to the way in which
requirements are being handled. However, this situation not only occurs in the professional field but also
academically, but also academically. On the other hand, at the universities the software engineering
process allows the opportunity to develop a tool to improve the requirements management process
RESUMEN
El éxito del desarrollo de proyectos de software, se ha reducido a un 32% según las estadísticas reveladas
por el Standish Group [7] en el año 2009, y las causas más frecuentes están relacionadas con la forma en
la que se están manejando los requerimientos, sin embargo esta situación no solo se presenta en el ámbito
profesional sino también en el académico. Por otra parte, viendo la evolución del proceso de ingeniería de
software que se está llevando a cabo en las asignaturas de IS y AS, se encuentra una oportunidad para el
desarrollo de una herramienta que mejore y agilice el proceso de administración de requerimientos
Página viii
Memoria de Trabajo de Grado - ISTAR
RESUMEN EJECUTIVO
En los proyectos de desarrollo de software, el proceso de ingeniería de requerimientos se divide en dos
grandes grupos de actividades, uno denominado “Desarrollo de Requerimientos”, el cual tiene como fin
realizar los procesos de recolección, análisis, especificación, y verificación; y otro llamado
“Administración de Requerimientos” cuyo objetivo principal consiste en administrar los cambios que
surgen en los requerimientos, realizar el control de versiones y administrar la trazabilidad.
Estos dos grandes procesos representan una parte fundamental en el éxito del desarrollo de proyectos de
software, ya que en las estadísticas reveladas por el Standish Group [7] en el año 2009, dentro de las
causas más frecuentes por las cuales los proyectos no consiguen alcanzar sus objetivos, se encuentran:
Los continuos cambios en los requerimientos y en sus especificaciones, los cuales derivan en
pérdida de control y monitoreo sobre estos.
La escasa comunicación con el cliente.
Una planeación inadecuada
Incomprensión
Poca participación de los usuarios finales
Especificaciones de requerimientos incompletas.
Esta situación no solo se percibe en la vida profesional, también se ve reflejada en el ámbito académico,
en los proyectos de las asignaturas como Ingeniería de Software y Arquitectura de Software. Debido a
esto, se realizó un estudio con el objetivo de encontrar una manera diferente de realizar la administración
de requerimientos, y así poder mejorar el proceso; gracias a esto surgieron diferentes alternativas por parte
del mercado donde se encontraron herramientas libres y con licencia, que le permiten a los usuarios
desarrollar un proceso de administración de requerimientos, pero debido a las exigencias de las
asignaturas, las herramientas con licencia, están fuera del alcance de los estudiantes, mientras que las
herramientas gratuitas no ofrecen todos los procedimientos requeridos en los proyectos.
Para solucionar esta situación, se propuso implementar una herramienta que soporte los procesos de la
administración de requerimientos que son requeridos por los proyectos de las asignaturas anteriormente
mencionadas.
Página ix
Memoria de Trabajo de Grado - ISTAR
Es por esto que el presente documento tiene como fin presentar los objetivos, metodología y resultados
obtenidos del trabajo de grado titulado: “Herramienta para la administración de requerimientos de los
proyectos de las asignaturas de Ingeniería de Software y Arquitectura de software de la pontificia
universidad javeriana”, el cual tiene como objetivo general Diseñar e implementar una herramienta de
administración de requerimientos, que ayude en el proceso de construcción de software para las
asignaturas de Ingeniería de Software y Arquitectura de Software de la carrera de Ingeniería de Sistemas
de la Pontificia Universidad Javeriana.
Para el desarrollo de la herramienta, la metodología que se utilizó en la primera fase fue una metodología
exploratoria con la cual se pretendía obtener toda la base teórica para poder realizar las funcionalidades de
una herramienta de administración de requerimientos; además en esta fase se realizaron las entrevistas y
encuestas tanto a profesores como estudiantes para adquirir la información que permitiera realizar el
proceso de levantamiento y especificación de requerimientos. También se llevó a cabo el análisis de
algunas de las herramientas existentes en el mercado, para identificar las características deseables para la
herramienta. Para las siguientes etapas, la metodología seleccionada fue SCRUM debido a que es una
metodología iterativa [56].
En cuanto a las pruebas de software, el caso de estudio utilizado, es la misma herramienta, es decir los
requerimientos con los que se realizaron las pruebas, son los requerimientos especificados para la
implementación de la herramienta ERMT. Los resultados de estas pruebas fueron satisfactorios.
Página x
Memoria de Trabajo de Grado - ISTAR
INTRODUCCIÓN
Dentro del proceso de formación académica de los estudiantes de ingeniería de sistemas de la Pontificia
Universidad Javeriana, se encuentra el desarrollo de proyectos de software en las asignaturas de
Ingeniería de Software y Arquitectura de Software, en los cuales los estudiantes deben realizar entre otros,
el proceso de administración de requerimientos, el cual les proporciona las herramientas necesarias para
llevar a cabo un desarrollo exitoso.
Por tal motivo, se propone la implementación de una herramienta que permita optimizar el proceso de
administración de los requerimientos de software en los proyectos de las asignaturas anteriormente
mencionadas, con el fin de agilizar este proceso y de esta forma permitir que el estudiante se apropie y
aplique los diferentes conceptos involucrados en este proceso.
Página 11
Memoria de Trabajo de Grado - ISTAR
I. DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO
1. Oportunidad, Problemática, Antecedentes
1.1. Descripción del contexto
Para el desarrollo de una aplicación de software existen varias etapas las cuales permiten que este proceso
sea o no exitoso. Dentro de estas etapas se encuentran la especificación y administración de
requerimientos, las cuales permiten conocer las necesidades que los clientes y usuarios finales esperan de
la aplicación. Del mismo modo, los requerimientos le permiten a los analistas realizar una estimación,
sobre el estado real del proyecto.
Además, es posible realizar el aseguramiento de la calidad del software ya que los requerimientos, que se
conocen como No Funcionales permiten describir cuales son los atributos de calidad que demanda el
cliente dentro del software a desarrollar.
Sin embargo, durante la construcción de software, no se le da la importancia necesaria a los
requerimientos y esto se ve reflejado en las estadísticas publicadas por el Standish group [49] en el 2009,
las cuales muestran que la tasa de éxito de los proyectos ha disminuido a través de los años hasta situarse
en un 32%, donde el éxito se refiere a la entrega a tiempo, de acuerdo con el presupuesto inicial y con
todas las funcionalidades que el cliente está esperando.
Las causas de estos fracasos han perdurado, pues no existe una diferencia considerable en las razones por
las cuales fracasaban los proyectos hace quince años y las que se presentan hoy en día [49].Dentro de
estas razones existen varias que están directamente relacionadas con los requerimientos, como lo son, la
escasa comunicación con el cliente, la claridad de los objetivos, los continuos cambios sobre los
requerimientos y sus respectivas especificaciones (que derivan en una pérdida de control y monitoreo
sobre estos) y la falta de planeación [49], las cuales influyen de manera negativa en la calidad de los
requerimientos lo cual afecta su administración el proyecto en general.
Es por esto que se considera de vital importancia que durante la formación académica de los Ingenieros de
Sistemas y en especial durante el curso de materias como ingeniería y arquitectura de software se dé un
especial enfoque sobre este tema.
Página 12
Memoria de Trabajo de Grado - ISTAR
1.2. Problema a Resolver
Con base en el contexto, la situación descrita es similar a la que se presenta en los proyectos desarrollados
por los estudiantes de las asignaturas de Ingeniería de Software y Arquitectura de Software de la Pontificia
Universidad Javeriana, donde el éxito total de los proyectos no llega a un porcentaje muy alto. Es por esto
que se presenta el siguiente interrogante: ¿Cómo mejorar el proceso de administración de requerimientos
en los proyectos que se llevan a cabo en las asignaturas de ingeniería y arquitectura de software de la
Pontificia Universidad javeriana?
1.3. Justificación
En primera instancia, es necesario tener en cuenta en qué consiste el proceso de administración de
requerimientos, el cual hacer referencia a diferentes tipos de acciones sobre los requerimientos, dentro de
las cuales se encuentran:
Especificación de requerimientos: Consiste en formalizar la descripción de las necesidades que
el usuario ha descrito. Dentro de estas se incluyen funcionalidades, capacidades y restricciones del
sistema [55].
Priorización: establece cuales son los requerimientos críticos, lo cual permite realizar acciones
como: tomar decisiones, plantear los requerimientos a implementar en cada una de las iteraciones
del desarrollo, realizar la estimación de la satisfacción del cliente, manejar el proceso de
negociación para así resolver los desacuerdos entre los Stakeholders [54], entre otros (ver Anexo
4: Marco Teórico).
Trazabilidad: hace referencia a la habilidad de definir, capturar y seguir la vida de un
requerimiento, es decir el grado en el cual se puede establecer una relación entre el requerimiento
y su origen, y el requerimiento y los artefactos generados al implementarlo[50]. Por medio de este
proceso, es posible comprobar que las necesidades descritas fueron realizadas a cabalidad y
cumplen con las expectativas del cliente.
Análisis del impacto del cambio: permite identificar las posibles consecuencias que tiene el
realizar un cambio sobre un requerimiento y que se necesita modificar para acoplar el desarrollo,
antes de que el cambio ocurra.
Incluir al cliente: permite que el cliente esté al tanto del desarrollo del proyecto y cumplimiento
de las necesidades que describió durante la recolección de los requerimientos.
Página 13
Memoria de Trabajo de Grado - ISTAR
Estimación de tiempo: Teniendo en cuenta la dificultad, la trazabilidad, la priorización y otros
atributos que son definidos en la especificación de requerimientos se puede estimar cual es el
tiempo de desarrollo que se va a tomar para terminar el proyecto.
Medir objetivos: por medio de los requerimientos se puede llevar a cabo un control de
cumplimiento de objetivos, para así saber si el proyecto que se está desarrollando va a cumplir el
propósito por el cual está siendo desarrollado.
Toma de decisiones: A partir de los requerimientos se pueden tomar decisiones que afecten el
desarrollo del proyecto, es decir decisiones como por ejemplo, que modelo arquitectónico se va a
utilizar [51].
Se debe tener en cuenta que dicha administración se puede hacer por medio del documento de
especificación de requerimientos que se realiza en documentos planos, o se puede hacer uso de
herramientas de software que proveen funcionalidades que permiten hacer de este, un proceso mucho más
llevadero y en forma más ordenada, ya que dentro de estas se deberían poder realizar las funciones
descritas anteriormente y las siguientes [52]:
Definición y clasificación de requerimientos: es decir catalogar los requerimientos de acuerdo a
su tipo, bien sean funcionales o no funcionales (ver Anexo 4: Marco Teórico).
Versiones e historial de cambios: que en dado caso de que se haya cometido error en la
actualización de un requerimiento, se pueda volver al estado anterior de la especificación.
Almacenamiento de los atributos: donde se deben definir propiedades tales como prioridad,
costo, estado, dificultad, autores, responsables, etc., las cuales permiten realizar la especificación
del requerimiento.
Encadenamiento a otros elementos del sistema: es decir la herramienta debe permitir que se
defina la trazabilidad de cada uno de los requerimientos. [52]
Visualización: de acuerdo a la priorización definida para cada requerimiento y de acuerdo a la
precedencia de estos, se debe poder generar un gráfico en forma de grafo que le permita a los
Stakeholders del proyecto ver con más claridad cuáles son las rutas críticas de desarrollo.
De acuerdo con lo anterior se podría decir que para mejorar el proceso de administración de
requerimientos de las materias de Ingeniería de Software y Arquitectura de Software, las cuales se
imparten en la Pontificia Universidad Javeriana, se podría contar con una herramienta de software que
permita realizar las funciones anteriormente descritas.
Página 14
Memoria de Trabajo de Grado - ISTAR
1.4. Impacto Esperado
El proyecto tiene como fin beneficiar a los diferentes grupos de trabajo que se conforman en las
asignaturas de Ingeniería de Software y Arquitectura de Software, ya que por medio de la herramienta, se
puede realizar un mejor proceso de administración de requerimientos de los proyectos que se llevan a cabo
en dichas materias.
Página 15
Memoria de Trabajo de Grado - ISTAR
II. DESCRIPCIÓN DEL PROYECTO
1. Visión global
El trabajo de grado consiste, en la elaboración de una herramienta que soporte el proceso de
administración de requerimientos que se realiza en proyectos de las asignaturas de Ingeniería de Software
y Arquitectura de Software de la PUJ. Para su desarrollo se identificaron las actividades más relevantes
dentro del proceso de Ingeniería de Software que se aplica en las asignaturas involucradas y se realizó una
investigación sobre cada una de ellas. Esta información fue recolectada a través de diferentes fuentes
como los estudiantes, profesores e investigación por parte del grupo de trabajo. Luego de realizar el
proceso de recolección de requerimientos se prosigue con las demás fases del proceso de Ingeniería de
Software, el cual se ve representado en cada uno de sus entregables: Visión (ver Anexo 1: Documento de
Visión) Especificación de Requerimientos (ver Anexo 2: Documento de Especificación de
Requerimientos) Documentos Arquitectónico (ver Anexo 3: Documento de Diseño). Con la fase de
análisis y diseño realizada, se prosigue con la implementación de la herramienta y con ella el desarrollo
del manual de usuario (ver Manual de Usuario), Manual de instalación (ver Manual de Instalación) y
pruebas (ver Anexo 5: Documento de Pruebas).
2. Objetivo General
Diseñar e implementar una herramienta de administración de requerimientos, que ayude en el proceso de
construcción de software para las asignaturas de Ingeniería de Software y Arquitectura de Software de la
carrera de Ingeniería de Sistemas de la Pontificia Universidad Javeriana.
3. Fases Metodológicas
IDENTIFICAR, a través de la investigación y el análisis, las diferentes características que
poseen las herramientas de administración de requerimientos existentes en el mercado.
ELABORAR una especificación de requerimientos acorde a la información obtenida de la
investigación y las necesidades propias de los cursos de Ingeniería de Software y Arquitectura de
Software de la Pontificia Universidad Javeriana.
DISEÑAR la arquitectura de la herramienta de administración de requerimientos.
Página 16
Memoria de Trabajo de Grado - ISTAR
DESARROLLAR la implementación de acuerdo a la especificación de requerimientos y al
diseño arquitectónico de la herramienta.
VERIFICAR la funcionalidad de esta herramienta de acuerdo al documento de pruebas y las
características exigidas en los cursos de Ingeniería de Software y Arquitectura de Software de la
Pontificia Universidad Javeriana.
4. Método Propuesto
Para el desarrollo del proyecto la metodología que se propuso consta de una fase de exploración para
cumplir con el primer objetivo específico y una segunda fase que consiste en la ejecución de la
metodología conocida como SCRUM [56] para los cuatro objetivos restantes, ya que esta es iterativa,
incremental y además permite controlar los riesgos.
4.1. Identificar
Dentro de la fase de exploración se realizó la búsqueda de material bibliográfico, al igual que herramientas
de administración de requerimientos, para luego llevar a cabo un análisis de éstas, lo cual permitió
identificar las características deseadas para el proyecto. Las actividades que se realizaron para esta fase
son:
Recolectar información acerca de cuáles son las características más importantes que se deben tener en cuenta en la administración de requerimientos.
Consultar herramientas de administración de requerimientos. Análisis de dichas herramientas. Definir cuáles son las características básicas de la administración de requerimientos, que la
herramienta va a proveer.
Como resultado de estas actividades, se obtuvieron las características básicas con las que cuenta la
herramienta, lo cual permite que los usuarios realicen una administración de requerimientos adecuada.
4.2. Elaborar - diseñar
En cuanto a la metodología SCRUM, esta cuenta con “Time Boxes” [56] dentro de las cuales se
encuentran las siguientes etapas:
Realizar el levantamiento de requerimientos de la herramienta de administración. Formalizar el documento de especificación de requerimientos. Definir y formalizar el diseño arquitectónico de la aplicación, lo cual generará el documento
de Diseño [9].
Página 17
Memoria de Trabajo de Grado - ISTAR
4.3. Desarrollar y verificar
Metodología Actividad Resultado de esta actividad
SCRUM Release Planning Meeting Se espera generar el Product Backlog es decir un
documento con los requerimientos funcionales de la
herramienta [56].
Sprint Planning Meeting Ya que es la primera actividad del Sprint el resultado
de esta actividad es un documento llamado Sprint
Backlog [57]en el cual se debe describir lo siguiente:
- Plantear cuales son los requerimientos que se deben implementar para el Sprint.
- Plantear los riesgos principales.- Plantear las características y funcionalidades
que va a tener la etapa.
Daily Scrum Meeting En esta actividad se debe generar un acta en caso de
que se discutan problemas que impidan el progreso del
Sprint [57].
Sprint Review Al finalizar el Sprint se realizará una reunión para
mostrar la funcionalidad desarrollada durante el Sprint.
Se debe realizar un acta donde se registre la
retroalimentación del cliente [57].
Se debe realizar la integración de la(s) nueva(s)
funcionalidad (es) a la herramienta.
Sprint Retrospective Para esta actividad se espera como resultado un acta
que indique que experiencias pueden ayudar a agilizar
el desarrollo del Sprint y que actividades pueden
retrasarlo, esto con el fin de mejorar el desempeño del
equipo de trabajo [57].
Página 18
Memoria de Trabajo de Grado - ISTAR
III. POST-MORTEM
1. Metodología propuesta vs. Metodología realmente utilizada.
Para la implementación de la herramienta Easy Requirement Management Tool, se planteó la
metodología descrita en la sección Método Propuesto, en donde se definieron dos grandes fases. La
primera de estas consistió en una fase de exploración en donde se recolecto la información necesaria para
llevar a cabo el análisis de herramientas de administración de requerimientos. Cabe resaltar que en esta
primera fase, también se generó el marco teórico del proyecto. Por esta razón, la fase de exploración tomó
más tiempo del esperado (lo que generó un retraso el cual derivó en el establecimiento de una nueva fecha
de entrega), debido a que las fuentes bibliográficas para algunos de los procesos, así como de algunas
técnicas utilizadas en estos, son escasas.
En cuanto a la fase de Elaboración, en donde se encuentran las actividades de elaborar, diseñar,
implementar y verificar (ver Sección 4), se aplicó la metodología SCRUM de la cual se llevaron a cabo
cada una de sus actividades, a excepción del Sprint Retrospective, debido al poco tiempo disponible para
la implementación y verificación.
A pesar del retraso generado en la fase de exploración, la implementación de la herramienta ERMT, fue
exitosa.
2. Actividades propuestas vs. Actividades realizadas.
Teniendo en cuenta las actividades expuestas en el cronograma (ver Diagrama De Gantt propuesta, las
actividades generales fueron suficientes y se cumplieron a cabalidad para el desarrollo del proyecto, sin
embargo, algunas de las tareas desarrolladas dentro de algunas actividades (iteraciones de las fases de
implementación) no se realizaron de manera formal, por ejemplo los pequeños post-mortem después de
cada iteración (módulo de funcionalidades) no quedaron escritos y/o documentados, a cambio de
documentarlos se discutían entre el grupo y se tomaba una decisión que luego iba a ser informada al
Director.
Con relación a la herramienta ERMT, si existieron diferentes cambios en la fase de implementación, estos
cambios fueron registrados en las actas y en los documentos correspondientes (SRS, SAD). Sin embargo,
no se considera una falla dentro de lo propuesto y ejecutado del proyecto, ya que el grupo de trabajo
Página 19
Memoria de Trabajo de Grado - ISTAR
consideró desde un principio la existencia de cambios en los requerimientos de la herramienta y con ayuda
de la metodología escogida, se lograron manejar de manera adecuada.
3. Efectividad en la estimación de tiempos del proyecto
Con ayuda de una aplicación llamada Sprintometer, se planearon las fases, actividades y tareas con un
tiempo estimado. En la tabla se muestra lo que se tenía planeado en un principio:
Sprint Fecha de Inicio Fecha de Finalización Días trabajadosMarco teórico 26 Jul. 2010 26 Ago. 2010 25Documento Visión 02 Ago. 2010 26 Ago. 2010 19Planeación Encuesta 04 Ago. 2010 11 Ago. 2010 8Entrevista a profesores 04 Ago. 2010 18 Ago. 2010 10Documento SRS 05 Ago. 2010 08 Oct. 2010 30Documento SAD 08 Oct. 2010 15 Oct. 2010 8Atributos y Clasificación 16 Oct. 2010 20 Oct. 2010 5Administración de Cambios
21 Oct. 2010 25 Oct. 2010 6
Priorización 26 Oct. 2010 31 Oct. 2010 6Localización y Trazabilidad
01 Nov. 2010 07 Nov. 2010 8
Validación y verificación 08 Nov. 2010 12 Nov. 2010 5Visualización y Reportes 12 Nov. 2010 21 Nov. 2010 10Pruebas 20 Nov. 2010 26 Nov. 2010 7Manual de Usuario 23 Nov. 2010 26 Nov. 2010 5Ayuda en Línea 26 Nov. 2010 30 Nov. 2010 5
Tabla 1: Registro Sprintometer de la Fases Planeadas para el Proyecto
Sin embargo, la estimación de las primeras fases no fue acertada, ya que la investigación y recolección de
la información para identificar las funcionalidades de la herramienta se prolongó de 5 a 6 semanas más, lo
cual afectó el cronograma general y por lo tanto la entrega del mismo. En la Tabla 2 se muestra el
cronograma ejecutado:
Sprint Fecha de Inicio Fecha de Finalización Días trabajados
Marco teórico 26 Jul 2010 27 Sep. 2010 61Documento Visión 21 Sep. 2010 10 Oct. 2010 20Planeación Encuesta 15 Ago. 2010 25 Ago. 2010 4Entrevista a profesores 02 Sep. 2010 10 Sep. 2010 4Documento SRS 12 Oct. 2010 11 Ene. 2011 25Documento SAD 31 Oct. 2010 22 Dic. 2010 21
Página 20
Memoria de Trabajo de Grado - ISTAR
Atributos y Clasificación
16 Oct. 2010 20 Oct. 2010 5
Administración de Cambios
19 Dic. 2010 25 Dic. 2010 7
Priorización 26 Dic. 2010 02 Ene. 2011 8Localización y Trazabilidad
15 Dic. 2010 12 Ene. 2011 10
Validación y verificación
04 Ene. 2011 08 Ene. 2011 5
Visualización y Reportes 26 Nov. 2010 12 Ene. 2011 20Pruebas 15 Dic. 2010 13 Ene. 2011 30Manual de Usuario 30 Dic. 2010 14 Ene. 2011 8Ayuda en Línea 02 Ene. 2011 12 Ene. 2011 2
Tabla 2: Registro Sprintometer de la Fases Ejecutadas del Proyecto
Como se puede observar el desfase obtenido en la primera etapa, afecta las demás actividades,
prolongando así la entrega del proyecto. Sin embargo, la diferencia entre la estimación y la ejecución de
las demás actividades no es considerable, ya que existen unos actividades que se sobrepasan el tiempo
estimado, pero existen otras que son desarrolladas en menor tiempo, obteniendo así un equilibrio, un
ejemplo de eso son los requerimientos involucrados con la actividad Visualización y Reportes, donde el
tiempo estimado para la generación del grafo era cerca de una semana, similar a los reportes, sin embargo
la generación del grafo tuvo un tiempo de 3 días para su implementación y pruebas, así que este tiempo
fue reasignado a la generación de reportes en Excel.
4. Costo estimado vs. Costo real del proyecto
La diferencia entre el costo estimado y el costo real del proyecto no es significativa, a pesar de tener un
incremento en el presupuesto estimado, debido a la prolongación del proyecto en 6 semanas. El valor total
del presupuesto estimado era de $18.884.689, el cual incluye costos de personal, equipos y servicios
(entre los más importantes). Actualmente, con el proyecto terminado y con los costos incluidos de las seis
semanas adicionales, el costo real del proyecto es: $19.771.308 (para ver en detalle los presupuestos
Estimado y Real, ir Anexo 6: Presupuestos).
Existe una diferencia de $886.619, este incremento se atribuye a la prolongación de la entrega del
proyecto en 6 semanas más, afectando así los costos de servicios y personal de 4 meses a 5,5 meses. Sin
embargo, también hubo reducción de costos, de esta forma la diferencia en el presupuesto no se vuelve
significativa. Esta reducción de costos se debe a dos factores: el no uso de los computadores de la
Universidad, ya que el 94% del trabajo se realizó en los computadores propios y el valor del servicio
Página 21
Memoria de Trabajo de Grado - ISTAR
técnico en caso de daño, ya que solo se presentó daño en uno de los equipos de los integrantes, por esta
razón el costo de estos factores disminuye.
5. Efectividad en la estimación y mitigación de los riesgos del proyecto.
La estimación de los riesgos hecha en la propuesta de Trabajo de Grado fue acertada, ya que los
problemas con mayor probabilidad e impacto se relacionaban con el manejo del tiempo (para mayor
información de la estimación de los riesgos ver Estimación de riesgos de la propuestaError: Reference
source not found). Sin embargo, a pesar de que se reprogramaron las actividades para cumplir con la fecha
límite, el retraso era considerable y la estrategia propuesta no fue suficiente para mitigar este riesgo. Los
tiempos fueron redefinidos para cumplir con la nueva fecha límite.
Otro problema que se presentó fue el daño de uno de los equipos donde se encontraba el proyecto, sin
embargo gracias a que se tenía la información del proyecto en diferentes lugares, la solución que se
implementó, permitió arreglar el problema de manera rápida sin afectar el cronograma de trabajo.
Página 22
Memoria de Trabajo de Grado - ISTAR
IV. MARCO TEORICO
En esta sección se presenta parte de la información recolectada sobre los procesos de ingeniería de
requerimientos y de administración de requerimientos, algunas técnicas representativas. A partir de la
información obtenida en este documento, son obtenidas las diferentes funcionalidades de la herramienta
ERMT.
Empieza con una breve introducción al tema de requerimientos, seguido de la explicación sobre la
Ingeniería de requerimientos y su relación con la administración, luego explica algunos de los procesos de
administración de requerimientos y la descripción de algunas técnicas. Finalmente se encuentra un análisis
comparativo entre las herramientas investigadas
1. ¿QUÉ ES UN REQUERIMIENTO?
A través de los años se han expuesto diferentes definiciones de la palabra requerimiento dentro del campo
de la ingeniería de software, mostrando de esta forma que el concepto ha ido evolucionando, a
continuación se presentan algunas de ellas:
Según Karl E. Wiegers, en la industria del software existe un problema y es la falta de definiciones que
describan aspectos del trabajo de los ingenieros que sean comunes para todos [1], por lo tanto no existe
una definición universal de que es un requerimiento. En este caso se utilizará la definición dada por
Sommerville la cual especifica que los requerimientos son la descripción de lo que debería ser
implementado [1], de los servicios proporcionados [2] y de cómo debería comportarse el sistema que va a
ser desarrollado.
Otra definición es que presenta Ralph R. Young, en su libro “The Requirements Engineering Handbook”,
el cual menciona que un requerimiento “es un atributo necesario dentro de un sistema, una declaración que
identifica la capacidad, característica o factor de calidad de un sistema para que tenga valor y utilidad a un
cliente o usuario” [4], complementando esta definición se menciona que el requerimiento es la base de
todo el trabajo de desarrollo que sigue después de esta fase.
Los autores ya mencionados indican, que no solo son necesidades de usuario las que se deben documentar
sino que también se deben tener en cuenta las políticas organizacionales, el gobierno y los estándares del
sector en el que se desempeñan.
Página 23
Memoria de Trabajo de Grado - ISTAR
2. ¿QUÉ TIPO DE REQUERIMIENTOS EXISTEN?
Para realizar la descripción de lo que se va a implementar, los servicios que prestará el producto y como
este debe desarrollarse, es necesario que el analista de requerimientos defina cuales son los tipos de
requerimientos que se van a utilizar en el proyecto, con el fin de evitar que se presenten confusiones [4],
debido a que los requerimientos se pueden clasificar en diferentes tipos dependiendo de la característica
que se quiere describir con estos.
Existen diferentes maneras de clasificar los requerimientos, pues depende del ámbito donde se desarrolle
el proyecto, de hecho en algunas ocasiones los grupos de proyecto crean su propia clasificación con base a
las clasificaciones estándar que proponen varios autores como Ralph R. Young ó Aybüke Aurum y Claes
Wohlin [5]. Una forma de clasificarlos, que está basada en las clasificaciones dadas por autores como Karl
Wiegers, Ian Sommerville, Martin Glinz y “The Guide to the Business Analysis Body of Knowledge”. La
clasificación se muestra en la Ilustración 1.
Ilustración 1. Clasificación de Requerimientos. Basado en [4] [24] [37] [38] [39] [2].
Página 24
Requerimientos de NegocioRequerimientos de UsuarioRequerimientos de SistemaRequerimientos No FuncionalesRequerimientos del ProductoFuncionalidadFiabilidadUsabilidadEficienciaMantenibilidadPortabilidadRequerimientos OrganizacionalesRequerimientos de EntregaRequerimientos de ImplementaciónRequerimientos de EstandaresRequerimientos ExternosRequerimientos de SeguridadRequerimientos eticos.InteroperabilidadRequerimientos Funcionales
Memoria de Trabajo de Grado - ISTAR
Antes de definir los tipos de requerimientos es necesario definir que son las reglas de negocio.
Las reglas de negocio hacen referencia a las políticas, condiciones, restricciones, conocimientos,
estándares de la industria en donde se desenvuelve la compañía [6], leyes gubernamentales ó aspectos del
negocio, los cuales deben ser soportados por el sistema. Las reglas de negocio permiten identificar los
requerimientos de [2].
3. ¿QUÉ ES LA INGENIERÍA DE REQUERIMIENTOS?
La ingeniería de requerimientos es una disciplina de la ingeniería de software, la cual se refiere a todas las
actividades relacionadas con el ciclo de vida de los requerimientos de un proyecto [1]. Está compuesta por
dos grandes grupos de actividades las cuales se han denominado Desarrollo de requerimientos y
Administración de requerimientos (Ver sección Administración de requerimientos). La Ilustración 2,
muestra como se compone la ingeniería de requerimientos y cada uno de los procesos que la componen.
Ilustración 2. Ingeniería de Requerimientos [Adaptado de Establishing a Requirements Management Process [13]].
El desarrollo de requerimientos tiene como objetivo principal identificar, acordar y registrar los
requerimientos de cualquier tipo, que le permitan al sistema cumplir con los objetivos del negocio [6];
Página 25
Memoria de Trabajo de Grado - ISTAR
para esto es necesario subdividir esta categoría en Recolección (ver Recolección), Análisis (ver Análisis),
Especificación (ver Especificación) y validación (ver Verificación).
3.1. Recolección
La recolección es el proceso mediante el cual se buscan los requerimientos del proyecto [18], para lo cual
es necesario agrupar la información acerca de las necesidades de los usuarios y de ellos mismos. El fin
último de la recolección es hacer que los usuarios entiendan cuáles son sus necesidades para que estas
puedan ser transmitidas a los desarrolladores del proyecto [19]. Además de identificar las necesidades de
los usuarios, la recolección también permite identificar y establecer cuáles son los límites del nuevo
sistema [22].
Para empezar la recolección de requerimientos es necesario identificar y analizar los Stakeholders del
proyecto.
Análisis de Stakeholders
Entrevistas y Cuestionarios
Talleres
Brainstorming
3.2. Análisis
Esta etapa de la ingeniería de requerimientos tiene como fin entender las necesidades globales de los
usuarios [23], las cuales son identificadas en la etapa de recolección (ver sección Recolección), y se ven
reflejadas en los artefactos o entregables que surgen de este proceso, para así hacer una descomposición
que permita especificar dichas necesidades globales en sentencias más simples las cuales proporcionen
las bases para realizar la especificación de los requerimientos del sistema [19].
El análisis de los requerimientos puede tornarse complicado ya que las necesidades de todos los usuarios
deben ser incluidas en los requerimientos [23], lo cual puede generar conflictos si alguno de estos genera
ambigüedades con uno o más de los requerimientos especificados. Además de esto se debe tener en
cuenta que el análisis es la base de la calidad del producto final ya que es fundamental para un diseño
exitoso [29]. Es por esto que el análisis de requerimientos tiene como fin:
1. Llegar a un entendimiento entre los Stakeholders del proyecto [19].
2. Detectar y resolver los conflictos entre los requerimientos.
3. Definir los límites del software y como este va a interactuar con su entorno.
Página 26
Memoria de Trabajo de Grado - ISTAR
4. Especificar los requerimientos del sistema [28] (ver Especificación).
5. Proveer las bases para la verificación [19] (ver Verificación).
3.3. Especificación
La especificación de requerimientos se encarga de documentar detalladamente las funcionalidades,
capacidades y restricciones del sistema [30], identificadas en la recolección y el análisis. Esta
especificación se conoce con el nombre de SRS. Este documento debe describir por completo el
comportamiento del sistema, pero no debe contener condiciones de diseño, planeación, implementación y
pruebas [1]. Para esto es necesario especificar los requerimientos, tanto de negocio y usuario, como los
requerimientos del sistema, teniendo en cuenta que para que los requerimientos sean adecuados y estén
debidamente documentados, deben contar con cierto tipo de atributos, como por ejemplo la fecha de
creación, el autor, la versión y la prioridad, entre otros, los cuales se encuentran mejor detallados en la
Definir los atributos de los requerimientos.
El Especificación de requerimientos es la base para el diseño y la implementación del sistema, así como
la fuente primaria de las pruebas y la documentación. Se dice que es la base, ya que:
Los clientes necesitan saber cual es producto que va a ser entregado.
Ya que provee la descripción del sistema, el gerente del proyecto puede basarse en este para
hacer los estimados de la calendarización, esfuerzo y recursos.
Los desarrolladores del sistema pueden conocer a cabalidad el sistema que se debe
implementar.
El equipo encargado de realizar las pruebas puede saber que parte o partes del producto se
encargan de cada funcionalidad [1].
Los objetivos de realizar la especificación de los requerimientos son:
1. Asegurar que todos los Stakeholders entienden el sistema que se va a construir, de la misma
manera.
2. Garantizar que las pruebas que se definen y construyen sean las adecuadas para el sistema que se
está construyendo [30].
Para asegurar que los objetivos de la especificación de requerimientos se cumplen, es necesario tener en
cuenta las siguientes características de calidad:
Página 27
Memoria de Trabajo de Grado - ISTAR
Correcto
Completo
Factible
No-Ambiguo
Necesario
Consistente
Priorizado
Entendible
Verificable
Modificable
Trazable
Diseño Independiente
No Redundante
3.4. Verificación
El proceso de verificación consiste en evaluar la exactitud, completitud y consistencia [32] de cada uno
de los requerimientos que fueron especificados, para asegurar que el sistema que se va a construir
satisfará las necesidades y expectativas de los usuarios [33]. Además de esto, se debe generar un criterio
de verificación para la arquitectura del sistema, el cual asegure que los costos, el cronograma y los
requerimientos de rendimiento se satisfacen [29].
Con lo anterior, los objetivos de la verificación de requerimientos son:
Asegurar que la especificación de requerimientos es una clara y correcta descripción del
sistema que debe ser implementado.
Aseverar la consistencia, exactitud y completitud del documento de especificación de
requerimientos.
Confirmar que la especificación sigue un estándar [34].
Teniendo en cuenta que la verificación es un proceso, se deben tener las siguientes entradas:
El documento de especificación de requerimientos (ver Especificación de requerimientos).
Estándares organizacionales: Al igual que los conocimientos de la organización, permitirán
verificar los requerimientos [34]. Dentro de estos documentos se pueden encontrar estándares,
políticas y reglas de la organización.
Página 28
Memoria de Trabajo de Grado - ISTAR
4. ¿QUÉ ES LA ADMINISTRACIÓN DE REQUERIMIENTOS?
Como se muestra en la ilustración 2, la administración de requerimientos es una de las actividades del
proceso de ingeniería de requerimientos, cuyo objetivo principal es administrar los cambios que pueden
surgir en los requerimientos implementados en todos los lanzamientos del producto ya que en algunos
casos, cuando se hace el lanzamiento de alguna versión del sistema, puede que algunos requerimientos ya
no sean necesarios o hayan cambiado por alguna disposición del cliente o por alguna otra razón[6].
Además del control de cambios, la administración de requerimientos debe encargarse del control de
versiones, hacer seguimiento del estado de los requerimientos, realizar la trazabilidad que permita ubicar
el origen y donde se encuentra el requerimiento. Estas responsabilidades del proceso permiten asegurar la
precisión, integridad y que los requerimientos se encuentren siempre actualizados [1].
Una vez realizadas la recolección, análisis y especificación de los requerimientos es necesario empezar a
realizar las tareas de administración de requerimientos para así, aumentar las posibilidades de éxito del
proyecto ya que dentro de las causas por las cuales fracasan los proyectos de software según el estudio
chaos[7], realizado por el Standish Group, se encuentran, entre otras, la incapacidad de manejar el cambio,
Inexactitud e incomprensión de los requerimientos y la planeación inapropiada, las cuales están
estrechamente relacionadas con la administración de los requerimientos.
4.1. El Proceso de Administración de Requerimientos
Para alcanzar una gestión de requerimientos exitosa se deben realizar las actividades registradas en la
ilustración 8:
Página 29
Memoria de Trabajo de Grado - ISTAR
Ilustración 3. Proceso de Administración de requerimientos. Adaptado [1] [8].
4.1.1. Capturar
4.1.1.1. Definir los atributos de los requerimientos.
“Los requerimientos son objetos de ingeniería y deben ser organizados y rastreados como tal” [36], es
decir, los requerimientos son parte fundamental del proyecto y son herramientas poderosas, las cuales
permiten definir cuál debe ser el comportamiento del sistema [36]. Por lo tanto además de la descripción
textual de los requerimientos, cada uno de estos debería contar con ciertos atributos que permiten la
Página 30
PROCESOACTIVIDAD
Memoria de Trabajo de Grado - ISTAR
contextualización del requerimiento dentro del sistema, pues los requerimientos al igual que otros
artefactos cambian su estado y es necesario saber que cambia, como cambia, por qué cambia, quién lo
cambia entre otras cuestiones.
Los atributos de los requerimientos como bien lo dice Ian Alexander [36], sirven para rastrear el estado de
los requerimientos en cualquier etapa del proyecto, sin embargo no todos los requerimientos tienen la
misma necesidad de ser monitoreados todo el tiempo debido a su simplicidad, bajo riesgo respecto al
cambio ó baja prioridad, pero existen atributos que aplican a todos los requerimientos en general, por lo
tanto debe existir un conjunto de atributos a ser utilizados de manera general en los proyectos, para
realizar un proceso de administración que cumpla con las características mínimas [40].
Para esto, se presenta una clasificación de los atributos de los requerimientos. En primera instancia se
encuentran los atributos que describen la información del requerimiento. Por otro lado, los atributos que se
desarrollan durante el proyecto, ya sea porque dependen de otros requerimientos para obtener su valor o
porque existen otros artefactos que pertenecen a otras fases que influyen sobre él (por ejemplo,
localización, trazabilidad) y por último se encuentran los opcionales que pueden albergar una gama amplia
dependiendo de lo que el proyecto requiera [40].
Atributo Descripción
Atributos propios del requerimiento
Fecha Día, mes y año en el cual fue creado el requerimiento.
Descripción Describe el requerimiento identificado en la fase de recolección.
Versión Versión actual del requerimiento.
Autor Nombre de la persona que creó el requerimiento.
Responsable Persona que debe asegurar que el requerimiento se cumple.
Dueño Persona a la que pertenece el requerimiento o una lista de Stakeholders.
Estado Fase se encuentra el requerimiento es decir el requerimiento puede estar
propuesto, rechazado, implementado ó verificado, dependiendo de los
criterios que cada grupo tenga.
Versión línea base Numero de la versión del requerimiento, el cual pertenece a la línea base
actual.
Origen Describe las fuentes del requerimiento. (ver Recolección)
Razón Se utiliza para saber el motivo de la última revisión.
Cambios realizados Lista de los cambios realizados al requerimiento.
Página 31
Memoria de Trabajo de Grado - ISTAR
Responsable del cambio Indica el responsable de los cambios realizados en los requerimientos.
Fecha del último cambio Fecha en la cual fue modificado por última vez el requerimiento.
Atributos para el proyecto
Prioridad Importancia del requerimiento.
Requerimientos asociados Requerimientos que se relacionan con él ya sea porque pertenecen al
mismo módulo.
Subsistemas Lista de subsistemas en los que se encuentra el requerimiento.
Casos de uso asociados Casos de uso que cumplen con el requerimiento, este atributo está
relacionado con los que tratan sobre la trazabilidad vertical.
Tipo de requerimiento Según la clasificación que se maneje en el grupo, a qué grupo de
requerimientos pertenece
Volatilidad Este campo indica que tan volátil es el requerimiento. (Ver
sección2.5.1.1.1. Volatilidad en los requerimientos del Anexo 4: Marco
Teórico).
Localización Especifica el componente o subsistema donde se encuentra asignado el
requerimiento.
Riesgo Indica el nivel de riesgo que puede tener un requerimiento debido a
diferentes factores como la limitación de la herramienta de software que
se utilice, la falta de conocimiento de la herramienta, la dificultad de la
interfaz, el conjunto de habilidades en el equipo de desarrollo, la
criticidad con el incumplimiento de una obligación se propagará el
riesgo.
Dificultad Indica la dificultad para los desarrolladores implementar el
requerimiento.
Beneficio Indica el nivel de beneficio para el proyecto en general, puede ser
distribuido según diferentes criterios para mayor ampliación del tema
ver Priorización.
Trazabilidad Muestra los artefactos que permiten seguir la vida del requerimiento.
(Ver Trazabilidad)
Atributos Adicionales
Casos de prueba asignados Indica el caso de prueba asignado para validar el requerimiento en cada
Página 32
Memoria de Trabajo de Grado - ISTAR
una de las fases de desarrollo.
Responsables en cada una
de las fases
No siempre el responsable en la fase de requerimientos es el mismo en la
fase de diseño, implementación o pruebas, por lo tanto es necesario
saber quien está a cargo del requerimiento en cada una de las fases.
Método de calificación El método que se utilizará en Pruebas de aceptación para demostrar la
conformidad del producto con el requisito.
Métricas asociadas Resultados obtenidos de las métricas asociadas al método de calificación
si lo van a aplicar
Aprobación (según
estándar que se maneje)
Porcentaje del resultado que indica si cumple con los estándares de
calidad definidos en el proyecto, según las listas de chequeo aplicadas
Tabla 3: Distribución de los atributos de los requerimientos [1] [26] [40]
Sin embargo como menciona Heumann en su artículo “The five levels of requirement management
maturity” [26], no todos los requerimientos son iguales, existen requerimientos más estables que otros
(requerimientos volátiles ver sección 2.2.2.7. Requerimientos Volátiles del Anexo 4: Marco Teórico),
existen requerimientos que son más importantes que otros, razón por la cual se les presta mayor atención.
Por lo tanto, no es necesario aplicar dentro de la especificación de los requerimientos (ver Especificación)
todos los atributos descritos en la tabla 3, simplemente se pueden tomar algunos como base para modificar
y agregar nuevos atributos que sean necesarios con el fin de que se pueda considerar que un
requerimiento es completo y apropiado para el proyecto.
4.1.1.2. Priorización
La priorización es un proceso necesario dentro de la ingeniería de requerimientos, ya que un proyecto
depende de diferentes recursos como el tiempo, personal y dinero, así que es preciso entregar un producto
que contenga lo esencial [48] (funcionalidades importantes).
Para saber lo “esencial”, se requiere organizar los requerimientos de tal forma que se tenga un conjunto de
requerimientos indispensables dentro del producto [47].
Según Berander y Andrews, el proceso de priorización de requerimientos provee soporte a diferentes
actividades como: [45]
Página 33
Memoria de Trabajo de Grado - ISTAR
- Para negociar el alcance del proyecto, pues a veces esta en conflicto con algunas restricciones
como el programa, presupuesto, recursos, tiempo en el mercado, y la calidad.
- Para que los Stakeholders puedan decidir cuáles son los requerimientos básicos del sistema.
- Igualmente para hacer frente a exigencias contradictorias, es decir para enfocarse en el proceso de
negociación, y resolver los desacuerdos entre las partes interesadas (Stakeholders).
- Para equilibrar las repercusiones de los requerimientos sobre la arquitectura de software y la
evolución futura del producto y sus costos asociados.
- Para seleccionar sólo un subconjunto de los requerimientos y aún producir un sistema que
satisfacer al cliente (s).
- Para estimar las expectativas del cliente.
- Para conseguir una ventaja técnica y optimizar las oportunidades de mercado.
- Para minimizar la repetición de trabajos y atrasos en el calendario (estabilidad del plan).
- Para establecer la importancia relativa de cada requerimiento para proporcionar el mayor valor al
menor costo.
4.1.1.2.1. Criterios
Existen diferentes factores que pueden intervenir en la priorización, ya que se debe tomar en cuenta la
opinión de los Stakeholders del proyecto, por lo tanto los factores que existen son muchos dependiendo de
los objetivos y prioridades de cada Stakeholder. Para esto, diferentes autores [Berander y Andrews, Botta
y Terry] han agrupado diversos criterios útiles para establecer prioridades, que pueden tomarse en cuenta
para realizar el proceso de priorización de requerimientos. Los criterios pueden clasificarse en 4 grupos,
estos son:
Importancia
Impacto
Costo
Riesgo
Página 34
Memoria de Trabajo de Grado - ISTAR
4.1.1.2.2. Técnicas
En el momento de priorizar los requerimientos, los Stakeholders asignan un valor de importancia al
requerimiento, según el criterio, sin embargo en proyectos donde la complejidad es alta el asignar un valor
no soluciona el problema, pues el resultado a obtener no logrará satisfacer los objetivos propuestos en
principio, es decir el conjunto de requerimientos estará vagamente delimitado y no se tendrá la certeza de
que esos requerimientos merecen estar dentro de ese conjunto. Además, el hecho de que influyan
diferentes Stakeholders lo hace aún más complicado ya que podría encontrarse con resultados
contradictorios, donde no se tiene un criterio de decisión, más que escoger los de mayor puntuación. Para
evitar este tipo de problemas se han presentado diferentes técnicas de priorización de requerimientos,
desde hace varios años. En este documento se presentarán las más comunes.
Para empezar se debe mencionar que existen diferentes escalas para evaluar un requerimiento, ya que
dependiendo de la granularidad que se esté manejando, esta puede variar [48]. Las más comunes son:
Bajo, Medio y alto
Esencial, condicional y opcional
Bueno tenerlo, Objetivo, Altamente deseada y se debe lograr
Numérica (Por ejemplo 1- 5 ó del 1-10).
Dependiendo de la técnica se escoge la que mejor se adecue, pues dependiendo de la escala se puede
escoger que tan detallado resulta el análisis.
Asignación Numérica
La asignación numérica es una de las técnicas más sencillas y comunes [47]. Consiste en agrupar los
requerimientos en diferentes niveles (ver Técnicas) donde cada uno de los Stakeholders tiene que
agruparlos según su criterio. Para evitar inconvenientes, como el considerar todos los requerimientos
importantes, se debe limitar el número de requerimientos por grupo. De esta forma se tiene un conjunto de
requerimientos semi ordenados.
Priorización basada en el Valor, Costo y Riesgo
Esta técnica la propone Wiegers en su artículo “First Things First: Prioritizing Requirements” [48], el cual
menciona que se deben tener en cuenta las diferentes perspectivas de los Stakeholders para estimar las
prioridades relativas de un conjunto de requerimientos. Esta consiste en evaluar cuatro criterios, éstos
son:
Página 35
Memoria de Trabajo de Grado - ISTAR
Beneficio
Impacto negativo (Penalti)
Costo
Riesgo
Los Stakeholders asociados a esta técnica, suelen ser el director del proyecto para mediar entre las partes
implicadas, los representantes del área de desarrollo para estimar los riesgos y costos a afrontar, y los
representantes de los clientes “clave” [48] para que indiquen que beneficios e impactos negativos podrían
tener si el requerimiento esta o no dentro del producto. Luego de evaluar cada requerimiento, se deben
asignar unos pesos a cada criterio, es decir un valor de importancia a cada ítem, por ejemplo, si se
considera que el proyecto es de alto riesgo (variedad de caminos críticos, presupuesto, tiempo) se le
proporciona más valor al criterio Riesgo. Por último se aplica una fórmula sobre los valores asignados
sobre los requerimientos con respecto a cada criterio, ésta fórmula es:
Prioridad = valor%
(%costo∗pesodel costo+%riego∗peso del riesgo)
Así se obtiene un valor especifico de cada requerimiento, se organiza la tabla de mayor a menor y se
obtiene un conjunto priorizado de requerimientos.
AHP (Analytical Hierarchy Process)
Es un método para la toma de decisiones que ha sido adaptado a la priorización de requerimientos de
software [44] [47]. Este método es utilizado "por pares", ya que se usa una matriz de comparación para
calcular el valor relativo y los costos de los requerimientos entre sí. Mediante el uso de AHP, el ingeniero
de requerimientos puede confirmar la coherencia del resultado pues los errores pueden ser identificados
durante las comparaciones redundantes que se realizan. AHP posee diferentes ventajas como el evitar
errores subjetivos, además de aumentar la probabilidad de que los resultados sean confiables. El método
de ésta técnica se distribuye en cinco puntos generales [44]:
1. Revisar los requerimientos del candidato a la integridad.
2. Aplicar el método comparación por pares para evaluar el valor relativo de cada uno de los
requerimientos candidatos.
3. Aplicar el método comparación por pares para evaluar el costo relativo de los requerimientos
candidatos.
Página 36
Memoria de Trabajo de Grado - ISTAR
4. Calcular el valor relativo de cada requerimiento candidato y costo de implementación, para luego
realizar un diagrama de costo-valor.
5. Utilice el diagrama de costo-valor como un mapa para analizar los requerimientos candidatos.
4.1.2. Trazar
4.1.2.1. Localización
La localización es un procedimiento que consiste en la asignación de requerimientos de alto nivel (ver
sección 2.2.3. Requerimientos de Sistema del Anexo 4: Marco Teórico), a los subsistemas específicos. Es
necesario que durante el desarrollo se incluyan tanto, componentes de hardware y software como
productos complejos que contienen múltiples subsistemas de software [1]. La asignación se realiza
después de que los requerimientos de sistema se especifican y la arquitectura del sistema se ha definido.
La localización es necesaria para asegurar que todos los requerimientos del sistema son cumplidos por un
subsistema o componente o por un conjunto de ellos colaborando juntos [43], pues no es seguro que un
requerimientos se cumpla con solo un subsistema o componente. El handbook [46] presenta una forma de
distribuir los diferentes grupos donde pueden ser asignados los requerimientos:
- Subsistemas: grupo de funcionalidades lógicas.
- Componentes del sistema: hardware, software entrenamiento y documentación.
La fase de diseño de la arquitectura es especialmente crítica para los sistemas que incluyen tanto,
componentes de software y hardware [1]. Una etapa importante para el análisis es asignar requerimientos
de sistema a los distintos subsistemas y componentes. Los requerimientos de sistema se deben
descomponer en requerimientos funcionales y no funcionales para los diferentes subsistemas y
componentes [1]. Adicional a lo anterior la información sobre la trazabilidad permite al equipo de
desarrollo abordar cada requerimiento en el diseño.
El proceso localización ayuda a retroalimentar el proceso de análisis de requerimientos, de igual forma
que el proceso de localización es retroalimentado por el proceso de diseño [11], tal y como se muestra en
la siguiente figura.
Página 37
Memoria de Trabajo de Grado - ISTAR
Ilustración 4: Localización dentro del proceso de ingeniería. Adaptado de Eriksson, Borg y Börtsler [11]
“La localización es importante para permitir el análisis detallado de las necesidades” [9], ya que una vez
que un conjunto de requerimientos se ha asignado a un componente, las necesidades individuales pueden
surgir y ser analizadas para descubrir mas necesidades que pueden ser cubiertas por el mismo u otros
componentes, permitiendo así el descubrimientos de nuevas interacciones entre los componentes ó la
creación de otro que supla con ese requerimientos. Como se muestra en la figura 9, en grandes proyectos
la asignación estimula una nueva ronda de análisis de cada subsistema [9].
Para llevar a cabo este proceso, Wiegers [1] recomienda empezar siempre desde la parte general del
sistema, ya que así permite el surgimiento de nuevos requerimientos durante el proceso [1] [9], es
decir desde los requerimientos de negocio hasta los del sistema (ver sección Tipo de requerimiento), que
se encargan de describir la arquitectura y funcionalidad del sistema distribuida en diferentes componentes.
Como se muestra en la ilustración para obtener un buen diseño, se debe iterar con ayuda del análisis de
requerimientos, porque una de las ventajas es que se pueden encontrar puntos de ambigüedad y confusión
[1], si se encuentran muchos de esos problemas, quiere decir que los requerimientos no eran
suficientemente claros o no están detallados adecuadamente.
Adicional a lo mencionado anteriormente, otra de las ventajas de realizar el proceso de localización es
asegurar que el proceso de verificación (ver sección Verificación) pueda realizarse de la mejor manera
asegurando así que los requerimientos en su mayoría han sido comprendidos y aceptados por el cliente, y
que se encuentran dentro del sistema.
Página 38
Memoria de Trabajo de Grado - ISTAR
Por último la localización también está relacionada con el proceso de pruebas, pues como menciona
Wiegers [1], los requerimientos proveen la base para el análisis de pruebas del sistema, pues los
requerimientos deben ser probados contra lo que se especifica en los requerimientos, para esto deben ser
trazados y localizados (ver sección Trazabilidad) hasta esa fase de desarrollo. Esto se debe a que el
producto podría mostrar correctamente todas las conductas descritas en los casos de prueba basados en el
código, pero eso no quiere decir que implemente correctamente el usuario o de exigencias funcionales [1].
Incluir en los probadores de los requerimientos dentro de las inspecciones para asegurarse de que los
requerimientos son verificables (ver sección Verificación) y “pueden servir como base para las pruebas
del sistema” [1].
4.1.2.2. Trazabilidad
La trazabilidad de requerimientos se puede determinar como la habilidad de definir, capturar y seguir [35]
la vida del requerimiento hacia atrás y adelante [30], es decir es el grado en el cual se puede establecer
una relación entre el requerimiento y su origen y el requerimiento y los productos que generan al
implementarse [9], esto hace referencia al código, pruebas y documentación [10].
Existen diferentes tipos de trazabilidad:
- Trazabilidad Pre-Requerimientos: esta se refiere a la habilidad de describir y seguir la vida del
requerimiento, antes de que este sea incluido en la especificación de requerimientos[10], es decir
seguir el rastro del requerimiento desde que este es recolectado (ver Recolección) hasta el proceso
de análisis de requerimientos (ver Análisis).
- Trazabilidad Post-Requerimientos: hace referencia a la habilidad de describir y seguir la vida
del requerimiento, después de que este ha sido incluido en la especificación de requerimientos
[10]. Es decir se debe seguir el rastro del requerimiento durante la especificación (ver
Especificación) hasta los elementos de la implementación, como por ejemplo un método que haya
sido incluido dentro del código para satisfacer el requerimiento. La ilustración 9 muestra
gráficamente a que se refiere esta clasificación de la trazabilidad de los requerimientos.
Página 39
Memoria de Trabajo de Grado - ISTAR
Ilustración 5.Trazabilidad Pre-Requerimientos y Trazabilidad Post-Requerimientos. Adaptado de [10]
Además de estos dos tipos también existen los siguientes:
- Trazabilidad hacia atrás: Puede ser vertical u horizontal. Si es vertical se refiere a la habilidad
de describir las relaciones del requerimiento desde las fuentes (ver Recolección), hasta las fases
posteriores del ciclo de vida del desarrollo del sistema [30]. Si es horizontal, se refiere a la
relación que existe entre las versiones que se desarrollan a lo largo de la vida del requerimiento
[35].
- Trazabilidad hacia adelante: al igual que la trazabilidad hacia atrás, esta puede ser vertical u
horizontal. Si es vertical describe la relación que existe entre los requerimientos hasta las fases
posteriores del ciclo de vida del desarrollo del sistema es decir que los requerimientos se puedan
ubicar dentro de la implementación del sistema, en documentos como manuales de usuario, en
secciones del código. Si es horizontal, esta trazabilidad hace referencia a las versiones posteriores
del requerimiento. En la ilustración 10. Se muestra la diferencia entre estos cuatro tipos de
trazabilidad, para aclarar posibles confusiones.
Página 40
Memoria de Trabajo de Grado - ISTAR
Ilustración 6. Tipos de trazabilidad hacia adelante y hacia atrás. Tomado y adaptado de [10]
Beneficios de realizar la trazabilidad
Dentro de los beneficios identificados por Karl Wiegers [1] se encuentran:
- Se puede utilizar la trazabilidad para verificar, validar (ver Verificación) y demostrar que todos
los requerimientos han sido implementados.
- La trazabilidad permite realizar cambios de manera correcta durante el mantenimiento, ya que
teniendo una matriz de trazabilidad (ver Tabla 5) permite saber cuáles son los cambios que se
deben hacer en caso de que por ejemplo cambie un requerimiento de negocio.
- Se puede afirmar con seguridad cuál es el estado de implementación del sistema y cuáles son los
requerimientos que no han sido implementados.
- Facilita la reutilización de componentes del sistema, ya que la trazabilidad identifica los paquetes
u otras unidades de código que están relacionadas tanto con los requerimientos como con el
diseño, pruebas y otros paquetes.
Página 41
Memoria de Trabajo de Grado - ISTAR
- Cuando se presentan un resultado inesperado después de ejecutar alguna de las pruebas, se puede
ir a la matriz de trazabilidad (ver Tabla 5) para identificar cuáles son los componentes o unidades
de código que deben ser revisados.
Técnicas Utilizadas para realizar la trazabilidad
1. Matriz de trazabilidad: es una matriz de referencia cruzada [10], es decir la matriz muestra las
relaciones que se encuentran entre los elementos ubicados en las filas, como los elementos
ubicados en las columnas [8]. Esta matriz se utiliza con el fin de relacionar los requerimientos con
los productos que se generan para satisfacer estos requerimientos [41].
Fuentes del
requerimient
o
Requerimiento Elementos
de Diseño
Unidad de
Código
Casos de
prueba
Manuales
Tabla 4. Tabla de trazabilidad. Adaptado de Westfall [9].
La tabla 5 muestra un ejemplo de una tabla de trazabilidad en la cual se puede tener dos tipos de
trazabilidad, tanto la trazabilidad hacia atrás vertical como la trazabilidad hacia adelante vertical, ya que se
describe desde la fuente del requerimiento, pasando por los elementos de diseño y las unidades de código,
hasta los casos de prueba y los manuales.
Ilustración 7. Matriz de Trazabilidad. Adaptado de [10]
Página 42
Memoria de Trabajo de Grado - ISTAR
Pero no solo se pueden realizar matrices de trazabilidad como la que se muestra en la tabla 5, también se
pueden hacer matrices que muestren la relación solo entre dos elementos, como por ejemplo
requerimientos y casos de uso, como la ilustración 11.
Lista de trazabilidad: es una técnica más simple y más compacta que la matriz, en donde cada
requerimiento tiene una lista que muestra la información de trazabilidad. Estas listas en general, como se
muestra en la ilustración 12, consisten en ubicar en la primera columna los requerimientos y en la segunda
poner los requerimientos que están asociados o de los cuales depende el requerimiento de la primera
columna [10], lo cual permite más adelante crear otro tipo de gráficas que permiten una la visualización
más clara de los requerimientos, como lo son los grafos de dependencias, que se utilizan para identificar
rutas criticas y ayudar con la priorización de requerimientos(ver Priorización).
La desventaja de utilizar las listas de trazabilidad en cambio de la matriz de trazabilidad, es que no se
puede evaluar de manera inversa la relación [10].
Ilustración 8. Lista de trazabilidad. Tomado de [8]
4.1.3. Monitoreo y Reporte
4.1.3.1. Definir Políticas de Administración
Definir las políticas de administración, no es más que definir el plan de administración de requerimientos,
en el cual se describen los procedimientos y los estándares que deberían ser seguidos durante la
administración de los requerimientos. Ya que se define como el plan de administración de requerimientos
este debe incluir las personas responsables de llevar a cabo la actividades del plan [25].
Para definir las políticas de administración de requerimientos, se debe empezar por definir una lista
general, que contenga los siguientes lineamientos [8]:
1. Cuáles son los estándares que se deben seguir durante el proceso
Página 43
Memoria de Trabajo de Grado - ISTAR
2. Cómo se deben recolectar los requerimientos y cuáles son las personas involucradas en este
procedimiento.
3. Como se van a identificar cada uno de los elementos contenidos en la especificación.
4. Qué tipo de atributos son los que se consideraran al momento de especificar cada
requerimiento (ver Definir los atributos de los requerimientos.).
5. Qué tipo de atributos debe contener la especificación de requerimientos.
6. Quienes son los encargados de realizar la especificación de requerimientos.
7. Teniendo en cuenta las políticas organizacionales, como se realizará el análisis de los
requerimientos.
8. Especificar las políticas de administración de cambio de requerimientos (ver Control de
cambios).
9. Especificar quienes serán los encargados, qué tipo y que técnica de trazabilidad será utilizada
en el desarrollo del sistema. (ver Trazabilidad).
10. Definir cuál es la forma correcta de almacenar los requerimientos rechazados [27].
Una vez definida la lista de políticas (o si ya se tiene una lista general), se deben seleccionar las políticas
más adecuadas para el proceso de administración del proyecto específico.
El plan de administración de requerimientos debe incluir secciones que se encarguen de definir lo
siguiente:
- Los objetivos a cumplir en el proceso de administración de requerimientos: se debe especificar
todo, por ejemplo los objetivos que se quieren cumplir en determinado lapso de tiempo, el alcance
que tendrá el documento [25], las reglas a seguir en cualquier situación ya sea una entrevista con
el cliente o el proceso que se realiza para solicitar algún cambio, además cabe mencionar, las
herramientas y capacitaciones sobre ellas para tener un mejor desempeño en el proceso de
administración [27].
- EL proceso de recolección de requerimientos que se va a seguir [24], (ver Recolección ).
- Los estándares que se deben seguir para hacer la descripción de los requerimientos y el SRS,
como por ejemplo el estándar IEEE 830 [4].
Página 44
Memoria de Trabajo de Grado - ISTAR
- Como realizar el control de cambios[24] (Ver sección Administración del cambio): dada la
situación general de casi todos los proyectos, donde el cambio en los requerimientos es más que
inevitable, se deben definir estrategias que permitan administrar el cambio de los requerimientos,
como por ejemplo mantener un historial de cambios ó establecer un canal único para el
cambio[25], también se pueden usar herramientas que complementen esta actividad, una que
menciona Ralph Young es CCB (Change Control Boards) [27].
- Como realizar las revisiones y la validación de los requerimientos: realizar las revisiones no
requieren mucho trabajo y se obtiene un beneficio [27], el cual es el aseguramiento de la calidad
de los documentos e informes de la especificación.
- Cuál es la técnica (ya sea la matriz ó la lista) y que información [24] se utilizara para llevar a
cabo la trazabilidad (ver Trazabilidad).
- Las métricas de la administración de requerimientos: esto con el fin de conocer en qué medida
está avanzando el proyecto, por ejemplo el estado de cada requerimiento, el número de cambios
acumulado [25].
- Que excepciones en cuanto al plan se pueden realizar, en qué casos y con la autorización de quien.
Los beneficios que trae realizar un plan de administración de requerimientos son:
- El tener las políticas por escrito, permite que las personas involucradas en el desarrollo del
proyecto tengan el conocimiento de cómo se debe hacer el proceso de administración de
requerimientos, lo cual permite que se ahorre tiempo durante este proceso.
- De alguna manera permite que el grupo de desarrollo sea proactivo a cualquier eventualidad [27],
lo cual es una gran ventaja, pues todos saben que se debe hacer en caso de que se presente un
problema o retraso en el proceso.
En cuanto a los problemas que se pueden presentar, están el hecho de que se debe consultar a las personas
que están involucradas en el proceso de ingeniería de requerimientos, para modificar proponer y revisar
las políticas, con el fin de generar un entrenamiento que asegure que las personas involucradas en el
proceso conozcan y apliquen dichas políticas, lo cual puede tomar mucho tiempo.
Página 45
Memoria de Trabajo de Grado - ISTAR
4.1.3.2. Almacenar los requerimientos rechazados
Ya que los requerimientos rechazados pueden llegar a surgir nuevamente durante alguna de las etapas
posteriores a la especificación de requerimientos (ver Especificación), es indispensable contar con un
registro que permita almacenar estos requerimientos y las razones por las cuales se decidió que estos no
deberían ser implementados, esto como el fin de evitar que se deba realizar el proceso de análisis de
requerimientos (ver Análisis ) para verificar el porqué no se tuvieron en cuenta en el análisis anterior[8].
Para almacenar estos requerimientos Ian Sommerville [8] recomienda utilizar una base de datos.
4.1.4. Administración del cambio
4.1.4.1. Control de Cambios
Varios autores, como Lam ó Wiedemann, indican, “Los cambios siempre ocurren en un proyecto y en
cualquier fase” [12], para esto se debe realizar un proceso de control de cambios el cual permita al equipo
de trabajo manejar el cambio en los requerimientos de la mejor manera, evitando así cualquier
incoherencia o atraso dentro del proceso [14]. Para empezar, se deben definir los lineamientos o políticas
que se deben seguir, cuando se va a realizar un cambio en los requerimientos.
Proceso de control de cambios
El objetivo de definir un proceso de control de cambios, es poder establecer cuáles deben ser los pasos
formales a seguir cuando se desea hacer un cambio en algún requerimiento. Se deberían tener en cuenta
los siguientes pasos que permiten el control de cambios:
1. Cual debe ser el proceso para realizar la solicitud del cambio en los requerimientos: el definir un
proceso de control del cambio permite asegurar que los cambios que son propuestos son
evaluados y/o aplicados de manera consistente [8]. Para una solicitud de cambio se deben realizar
las siguientes actividades:
Llenar la plantilla de solicitud de cambios. Esta plantilla debe contener atributos como: el numero
de la solicitud, la fecha en la cual se hace la solicitud, el nombre de la persona que solicita el
cambio, descripción del problema, descripción del cambio, costo del cambio, y campos en los
cuales posteriormente se realizará la aceptación o razones por las cuales no se acepta el
cambio[21]. En la ilustración 13 se muestra un ejemplo de cuáles son los atributos a tener en
cuenta en la solicitud del cambio.
Página 46
Memoria de Trabajo de Grado - ISTAR
Ilustración 9. Posibles atributos para el control de cambios. Adaptado de [12].
Analizar la solicitud de cambio [21] y cálculo de costos [12]: después de que es realizada la
solicitud del cambio, esta se debe analizar para verificar si este cambio es válido. Se debe evaluar
cual si es o no factible, cuál es el efecto que tendrá y cuáles son los costos en los que se incurrirá
en caso de hacer la modificación en el sistema. Existen tres factores principales que pueden influir
o no en el cambio de un requerimiento[12]:
o Los resultados del análisis (en particular la incidencia en los costes y el calendario).
o La estructura técnica del sistema a desarrollar.
o Estructuras organizativas del cliente y el proveedor.
Implementación del cambio: Una vez aprobada la solicitud de cambio, estos pueden ser aplicados
sobre el sistema, es decir se debe modificar el SRS y si es necesario también el diseño, la
implementación, las pruebas y los manuales [2]. De igual forma debe quedar registrado el cambio
que se ha realizado, para informar a todo el grupo de trabajo que cambio se ha realizado dentro de
la especificación y que debe modificarse en adelante [12].
Mantener el historial de cambios: cuando se realiza el cambio es importante almacenar toda la
información pertinente al cambio.
2. Establecer un comité de control de cambios [8]: esto con el fin de asegurar que todas las
solicitudes de cambio serán evaluadas. Para establecer este comité se deben seguir los siguientes
pasos:
Página 47
Memoria de Trabajo de Grado - ISTAR
Seleccionar a los miembros: el objetivo de este paso es seleccionar a las personas correctas que se
encarguen de evaluar todos los cambios. Todos los Stakeholders pueden ser parte del comité [21].
Reuniones para evaluar los cambios: los miembros del comité deben reunirse de manera constante
para así asegurar que las solicitudes de cambios se evalúan y que son contestadas en un tiempo
determinado [21].
3. Definir como se debe notificar el cambio a los Stakeholders afectados [8]: esto con el fin de
informar los cambios que fueron aceptados e implementados a los Stakeholders que se ven
afectados por estos.
La ventaja de definir un proceso de control de cambios, es que los cambios se realizarán de manera
controlada en donde cada vez que se realice un cambio se analizara el impacto que generará en el
proyecto, y al finalizar el cambio, los Stakeholders puedan conocer cuáles fueron los cambios que se
realizaron.
Usar una base de Datos de requerimientos
Para mantener un mejor control sobre los cambios del sistema, se recomienda tener una base de datos de
requerimientos, que almacene todos sus atributos, estado y sus cambios.
Esta práctica trae beneficios como:
- Realizar búsquedas de grupos de requerimientos y mantener los enlaces de cada requerimiento,
hacia otros requerimientos.
- La base de datos funciona como un repositorio en el cual se puede trabajar de manera concurrente,
sin la posibilidad de que se presenten conflictos.[8]
- Publicar al grupo el estado de la solicitud del cambio si fue aceptado, rechazado o está pendiente
para ser evaluado. [15]
4.2. Beneficios de la administración de requerimientos
Dentro de los beneficios que de hacer una buena administración de requerimientos se encuentran:
Permite verificar que el sistema que se está construyendo, es el mismo durante toda la fase
de construcción [42].
Reusabilidad, ya que la información que se registra durante la especificación del proyecto
puede ser reutilizada en la construcción de otros [12].
Página 48
Memoria de Trabajo de Grado - ISTAR
Seguridad legal: ya que los requerimientos son prácticamente el único medio escrito
mediante el cual el cliente y el gerente del proyecto pueden comprobar que el sistema que
se entrega, es el mismo sistema que se solicito.
Da seguridad para todos los Stakeholders del proyecto ya que se puede tener una imagen
clara de que es lo que se está desarrollando, cómo y con qué [12].
La administración de requerimientos permite tener una especificación de requerimientos
clara que no se preste para malos entendidos ni confusiones [88].
Como la administración de requerimientos tiene que agregar los atributos descritos en la
Definir los atributos de los requerimientos, es muy fácil generar un reporte de avance del
proyecto de acuerdo a la información registrada en el campo de estado del requerimiento,
ya que indica el estado de implementación de cada uno [12].
Permite mantener los acuerdos sobre el alcance del proyecto, entre los desarrolladores,
usuarios y los demás Stakeholders del proyecto [88], esto además conlleva a que se genere
un sistema de alta calidad [17].
Se establecen los criterios de aceptación del sistema que será entregado [88].
Permite generar las pruebas adecuadas que verifiquen que el proyecto tiene las
funcionalidades que el cliente solicitó [12].
Se reducen las posibilidades de realizar la entrega del proyecto por fuera de la fecha límite
de entrega y se reducen los costos [20] debido a que la administración de requerimientos
permite reducir el número de errores en los requerimientos [17].
Además de los beneficios ya mencionados, también se pueden obtener los beneficios
descritos en la Trazabilidad.
4.2.1. Beneficios de Usar una herramienta de administración de requerimientos
Gracias al avance de la tecnología, se han desarrollado diferentes opciones para apoyar los procesos de
construcción de productos de todo tipo, y la construcción de software no se queda atrás. Es por esto que
existen en el mercado herramientas hechas con el propósito de soportar los procesos de administración de
requerimientos dentro del desarrollo de software. Cuando se utilizan este tipo de herramientas, son
muchos los beneficios con los que se pueden encontrar los grupos de desarrollo, dentro de los cuales se
encuentran:
Página 49
Memoria de Trabajo de Grado - ISTAR
4.2.1.1. Beneficios de Negocio
Ahorro de tiempo, ya que se automatizan muchos de los procesos de la administración de
requerimientos [16].
Disminución en los niveles de estrés del equipo de desarrollo, debido a la automatización de los
procesos de trazabilidad y control de cambios [16].
Algunas herramientas proporcionan permisos de acceso para los Stakeholders, lo cual asegura,
que los requerimientos del proyecto solo están disponibles para los Stakeholders involucrados [1].
4.2.1.2. Beneficios a nivel del proyecto
Permiten que el proceso de control de cambios se realice de manera sencilla [14], ya que
estas herramientas pueden mantener un historial de cambios para cada requerimiento, el
cual permite la comunicación del cambio a los Stakeholders y además si se quiere restaurar
algún estado anterior de algún requerimiento, se puede hacer con facilidad [1].
El análisis de impacto de un cambio (ver Administración del cambio), es más eficiente
debido a que la información que se debe utilizar para llevar a cabo este análisis se encuentra
reunida en el mismo lugar [14].
Los atributos del requerimiento se pueden guardar con mayor eficiencia, ya que los campos
de los atributos de cada requerimiento ya están listos para recibir la información [14].
Algunas herramientas le permiten que los equipos estructurar sus requerimientos, es decidir,
el equipo de desarrollo decide cuales son los atributos del requerimiento [16].
Facilitan la implementación del proceso de trazabilidad [1], en algunos casos se pueden
implementar la trazabilidad hacia adelante y hacia atrás (ver Trazabilidad), ya que muchas
de estas herramientas permiten la definición de casos de uso y componentes de diseño [14].
Muchas de estas herramientas permiten saber casi de manera instantánea cual es el estado
del proyecto en cuanto a implementación de requerimientos [1].
Permiten mejorar la colaboración entre los Stakeholders del proyecto [16].
Aseguran que el producto que se está realizando, es el producto que el cliente está
esperando [14].
4.3. HERRAMIENTAS
1. El proceso de administración de requerimientos, como se pudo observar en la sección El Proceso
de Administración de Requerimientos, está compuesto por diferentes actividades las cuales si se
realizan manualmente, requieren de tiempo para llevarlas a cabo, mientras que el uso de alguna
Página 50
Memoria de Trabajo de Grado - ISTAR
herramienta que apoye el proceso de administración puede agilizarlo y asegurar la consistencia de
los requerimientos dentro de todas las fases de desarrollo de software [26].
Al observar las ventajas de aplicar un proceso de administración de requerimientos sección Beneficios de
la administración de requerimientos, existen otras ventajas que se pueden obtener dentro del proyecto y la
administración de requerimientos si se utiliza una herramienta que agilice este proceso. Estas ventajas son
[15]:
- El apoyo a la adquisición, la especificación, agrupación y la atribución de los requerimientos.
- El apoyo a su derivación a niveles más detallados, mantenimiento y ajuste de los atributos.
- Permitir casos de prueba y los entornos de prueba que se definan y relacionen.
- Las relaciones entre los requerimientos que permitan, el diseño, realización y prueba para realizar
el seguimiento y la localización.
- Permitir el desarrollo distribuido dentro de la organización.
En el mercado, se encuentra una gran variedad de herramientas exclusivas para la administración de
requerimientos, las cuales cumplen con diferentes actividades del proceso. Según Hoffmann, existen
diferentes requerimientos para realizar una herramienta de este tipo [15], pero en este caso se utilizaron los
procesos fundamentales de la administración de requerimientos como criterios para la evaluación de las
herramientas analizadas, dichos criterios son:
- Clasificación de requerimientos:
o A la hora de realizar el proceso de recolección e identificación de requerimientos, es
importante tener en cuenta que tipo de requerimientos se están manejando para así evitar
confusiones dentro del proyecto más adelante.
o El factor a evaluar es como lo maneja la herramienta, de forma estricta o flexible.
- Atributos de los requerimientos:
o Para el proceso de especificación, (ver sección Ingeniería de requerimientos), es
importante definir la documentación de los requerimientos al principio, pues de esto
depende la continuidad del proceso durante las siguientes fases. Existen, como se
menciona en la Sección Definir los atributos de los requerimientos, atributos que no son
de utilidad y que pueden llegar a ser innecesarios hasta el punto de ser un obstáculo
Página 51
Memoria de Trabajo de Grado - ISTAR
dentro de la especificación. Por esta razón es primordial identificar que atributos se van a
usar dentro del proyecto. Al igual que el ítem anterior, lo que se quiere evaluar es qué
tanta flexibilidad tiene la herramienta respecto al manejo de los atributos dentro de la
herramienta.
- Trazabilidad:
o Es un factor importante para integrar el proceso de requerimientos al proyecto [26], pues
permite el seguimiento del requerimiento durante todo el proceso de desarrollo del
sistema [15]. El facto a evaluar es que tipo de trazabilidad realiza y como la muestra al
usuario.
- Control de cambios:
o Como se menciona al inicio del documento, dentro de un proyecto los cambios son
inevitables y más aún cuando se trata de requerimientos, por lo tanto lo que se debe hacer
es manejar los cambios de la mejor forma posible para disminuir el impacto sobre el
proyecto [15]. Lo que se quiere evaluar dentro de este ítem es como muestra al usuario los
cambios realizados en el requerimiento, si guarda un historial, informa de los cambios
hechos recientemente y si muestra los artefactos afectados por el cambio.
- Visualización de los requerimientos:
o Este requerimiento es enfocado al usuario y no hace parte del proceso de administración
de requerimientos, sin embargo se considera como un criterio de evaluación porque este
factor, de alguna forma facilita el uso de la herramienta, pues no es sencillo ver una gran
lista de requerimientos (más de 100) sin clasificar, que ver un gráfico sobre las
dependencias, relaciones o simplemente clasificaciones que tienen los requerimientos
[15].
- Factor plus:
o Como es de suponer, no todas las herramientas son iguales, existen factores adicionales
que la hacen particular. Aquí se mencionara aquel factor plus que sea considerado de
mayor utilidad para facilitar el proceso de administración de requerimientos.
Después de evaluar herramientas como Rational RequisitePro, Eterprise Architect, TopTeam Analyst y
GetherSpace las cuales son herramientas cuentan con una licencia la cual no es fácil de obtener debido a
Página 52
Memoria de Trabajo de Grado - ISTAR
los altos costos, se pudo observar que el proceso de administración de requerimientos que estas
herramientas soportan tiene falencias en algunas áreas del proceso como por ejemplo la visualización de
requerimientos, ya que se presenta la lista de requerimientos, pero esta no permite por ejemplo ubicar las
rutas criticas.
En algunas de estas herramientas también se ve que el proceso de trazabilidad solo se puede realizar con
los casos de uso, y no con los demás productos que se generan durante el desarrollo de software.
Al igual que las herramientas anteriores CaliberRM tiene una gran desventaja la cual es la licencia para la
adquisición de ésta, además de que la trazabilidad que realiza se basa solo entre los requerimientos, a
pesar de que la visualización de la tabla de trazabilidad es clara para el usuario, igualmente no existe un
grafico que permita la visualización de las dependencias entre los requerimientos.
Por otra parte, también fueron evaluadas herramientas como REM y OSRMT las cuales son herramientas
gratuitas, sin embargo al igual que las herramientas anteriores poseen falencias, por ejemplo REM no es
multiusuario y solo aplica para algunos sistemas operativos de Windows, el documento que genera y los
que se manejan durante el proceso pueden ser mejorados para orientarlos más hacia el usuario y no maneja
líneas base dentro del proceso de ingeniería de requerimientos. Al igual que REM, OSRMT no genera un
documento orientado al usuario, los documentos que genera son para uso interno del grupo y no realiza un
análisis de impacto con respecto al control de cambios.
Sin embargo, existen características que son deseables para implementarlas como la visualización de la
trazabilidad a través de una Matriz de relaciones entre las diferentes fases y los requerimientos,
visualización de jerárquica de los requerimientos, flexibilidad para personalizar el proyecto, manejo de la
localización con los documentos y manejo de dependencias entre los requerimientos.
Página 53
Memoria de Trabajo de Grado - ISTAR
V. DESARROLLO DEL TRABAJO
EL proceso que se llevó a cabo para el desarrollo del trabajo de grado, está basado en la metodología
propuesta, donde se puede determinar dos grandes fases, la primera que es investigativa y la segunda
donde se elabora la aplicación ERMT.
1. Fase Investigativa
Para el cumplimiento de los diferentes objetivos definidos en el proyecto (ver Fases Metodológicas), se
debe tener conocimiento del mercado de herramientas que cumplen con los diferentes procesos de la
administración de requerimientos. De esta forma comenzó la investigación no solo de las herramientas,
sino también de nuevas funcionalidades que puedan soportar y colaborar con el proceso de administración
de requerimientos en las asignaturas IS y AS.
Como se menciona anteriormente, la investigación parte de las herramientas disponibles en el mercado,
que de alguna forma pueden apoyar el proceso de administración de requerimientos. Estas herramientas
fueron analizadas a partir de un grupo de funcionalidades que iban surgiendo de la indagación de los
diferentes conceptos que abarca la Ingeniería de requerimientos y a su vez de los procesos que lo apoyan
(administración de requerimientos).
1.1. Investigación de herramientas para la administración de requerimientos
Para realizar el análisis de las herramientas para la administración de requerimientos, fue necesario
realizar una búsqueda de las más utilizadas en el mercado. A partir de la lista de herramientas encontradas,
se seleccionaron seis, dentro de las cuales se encuentran herramientas con licencia y gratuitas.
Posteriormente se exploró una a una cada herramienta, con el fin de conocer cuáles son las
funcionalidades que estas prestan. Además de analizar las funcionalidades de la herramienta, s
documentaron cuáles eran los aspectos positivos Y negativos, con el fin de establecer una lista con las
características deseables para ERMT.
1.2. Investigación de los procesos de la administración de requerimientos
Para la investigación de herramientas y la recolección de requerimientos por parte del cliente, era
necesario tener claro que procesos tiene la administración de requerimientos, por lo tanto en esta fase se
Página 54
Memoria de Trabajo de Grado - ISTAR
realizó una rigurosa investigación de los diferentes conceptos de la ingeniería de requerimientos y como la
administración de estos a través de diferentes actividades y técnicas puede soportar éste proceso. En este
documento, solo se presenta una parte del marco teórico, para ver el resultado completo ver Anexo 4:
Marco Teórico, en el cual se encuentra de forma detallada el proceso de Ingeniería de requerimientos y el
de administración de requerimientos. El objetivo de esta investigación, además de tener claridad en los
conceptos, era seleccionar las posibles técnicas a implementar en la herramienta, y así tener una base para
comenzar a indagar lo que el cliente y los usuarios finales quería.
1.3. Entrevistas y encuestas
En esta fase, después de tener una base teórica, el objetivo era conocer que tan útil puede ser para los
profesores, dentro del proceso pedagógico, el usar una herramienta como ERMT dentro de las asignaturas,
teniendo en cuenta el proceso de Ingeniería de Software que estaban implantando en cada una de ellas.
También, se realizaron encuestas sobre que funcionalidades serían aceptadas para los usuarios finales
(estudiantes) y que funcionalidades no.
Las entrevistas se realizaron a un profesor de cada asignatura, en representación de Ingeniería de
Software, el Profesor Miguel Eduardo Torres Moreno y en la asignatura de Arquitectura de Software, el
profesor Jamir Antonio Ávila. El resultado, de forma general fue, que los dos podrían optar por utilizar la
herramienta, pero en Ingeniería de Software se ve mayor utilidad, dado que se está en un proceso de
aprendizaje, por lo tanto se utilizaría la herramienta para la apropiación y aplicación de conceptos,
mientras que en arquitectura se sugeriría la herramienta para su uso. (Para ver en detalle las preguntas
realizadas, la entrevista y su análisis ver Anexo 7).
Las encuestas se realizaron a los estudiantes que ya han visto la asignatura de Ingeniería de Software,
debido a que tienen conocimiento del proceso y han tenido la oportunidad de aplicarlo, siguiendo el
método que hayan investigado en su momento. Como se mencionó anteriormente, el objetivo era
identificar que funcionalidades serían de mayor utilidad para la herramienta, por lo tanto se abordaron
temas como falencias en el proceso, que funcionalidades le serían de utilidad y que actividades no las
consideró necesarias. . (Para ver en detalle las preguntas realizadas y los resultados de ella, ver Anexo 7).
2. Fase de Elaboración
Para la elaboración de la herramienta, se definieron en la propuesta diferentes fases metodológicas para el
desarrollo de una aplicación, el proceso que se siguió consta de: la recolección de requerimientos (ver
Página 55
Memoria de Trabajo de Grado - ISTAR
Fase Investigativa), especificación y análisis, diseño de la herramienta, implementación, la realización de
pruebas (definido en el alcance del proyecto) y elaboración de manuales de instalación y de usuario.
2.1. Fase de recolección
Esta fase se encuentra detallada en la sección Fase Investigativa, donde se encuentra las diferentes
estrategias que se utilizaron para recolectar los requerimientos de la herramienta ERMT.
2.2. Fase de Especificación y Análisis
En esta fase de análisis, se definieron en primera instancia los casos de uso (ver Anexo 8: Documento de
casos de uso), de esta forma se definían de manera rápida los requerimientos funcionales de la
herramienta. A partir de los requerimientos definidos, se elaboró un documento de especificación de
requerimientos, además se realizó un análisis de ellos, el cual consistió en una clasificación en módulos
(definidos por el grupo) de priorización, trazabilidad y grafo de implementación (ver Anexo 2: Documento
de Especificación de Requerimientos). Estos documentos han sido actualizados, dependiendo del estado
del proyecto.
2.3. Fase de Diseño
Teniendo en cuenta la especificación de los requerimientos funcionales y no funcionales, se diseñaron los
diferentes diagramas, donde estaban definidos los componentes necesarios, para poder cumplir con cada
uno de los requerimientos establecidos en el documento SRS. Además, se establecieron las aplicaciones a
interactuar con la herramienta, teniendo en cuenta las funcionalidades a realizar.
Microsoft Excel y Microsoft Word 2007: para la generación de reportes
Graphviz: para la generación de los grafos
JFreeChart: para la generación del diagrama de estado.
MySQL: almacenamiento de los datos y manejo de ellos directamente (WorkBecnh)
Los diagramas que fueron diseñados son:
Vista Lógica: como se distribuyen y comunican los diferentes componentes de la aplicación, es
decir, distribución de paquetes.
Diagrama de clases: Conjunto de clases por cada componente incluido en la vista lógica.
Diagrama de despliegue: distribución de los componentes físicos, para que la aplicación funcione
según los requerimientos.
Página 56
Memoria de Trabajo de Grado - ISTAR
Modelo entidad relación: Distribución y relación de las diferentes tablas que se van a utilizar en la
aplicación.
Además fueron diseñadas las interfaces, para asegurar que el flujo de información este acorde con lo
escrito en el documento de diagramas de CU. (Para ver en detalle el documento de diseño, ir Anexo 3:
Documento de Diseño)
2.4. Fase de Implementación
2.4.1. Desarrollo
A partir del diseño elaborado, se comienza a implementar los diferentes módulos establecidos:
Datos
Lógica del negocio
GUI
No Funcionales
Además, la lógica de negocio fue distribuida en diferentes grupos, donde cada uno tiene un conjunto de
requerimientos que cumplen funcionalidades de un mismo componente. A continuación se muestra la
distribución de estos requerimientos:
Atributos y clasificación
Grafos y reportes
Proyecto
Localización y Trazabilidad
Priorización
Historial de cambio
V&V
Como ERMT es una aplicación transaccional, la implementación de la base de datos era prioridad, así que
ésta fue construida, teniendo en cuenta el MER diseñado en la fase anterior (ver Fase de Diseño) para así
poder trabajar en paralelo la interfaz GUI y la Lógica del negocio. Sin embargo, dado que ERMT tenía
que interactuar con otras aplicaciones y el conocimiento del grupo frente a la implementación, de los
requerimientos involucrados, no era suficiente, después de establecer la base de datos y el esqueleto de la
aplicación (diagrama de clases), se procede a la investigación sobre el uso de las aplicaciones y librerías
nuevas; las funcionalidades asociadas a estas aplicaciones son la generación de reportes, la generación de
Página 57
Memoria de Trabajo de Grado - ISTAR
los grafos y el diagrama de estado. Luego de implementar las funcionalidades descritas anteriormente, se
procede con los demás grupos de requerimientos.
La metodología usada para la fase de implementación, es la propuesta por SCRUM, donde las metas son
definidas por periodos cortos de tiempo (8 – 15 días). Estas metas consisten en proponer un conjunto de
requerimientos para implementar y al finalizar el tiempo se deben integrar al prototipo, para después
realizar pruebas de integración. Al aprobar los requerimientos implementados en la meta, se definen otros
requerimientos a ser implementados y empieza el ciclo nuevamente, si surgen problemas se deben
registrar, y se debe reasignar tiempo de la próxima iteración para solucionar los problemas. (Ver
Desarrollar y verificar).
2.4.2. Documentación del código
Durante la fase de implementación, también se avanzó con la documentación del código. El grupo de
trabajo había decidido realizar la documentación a los principales métodos es decir, no se realizó la
documentación de los métodos getters, setters, constructores e interfaces, ya que no generan ningún
cambio relevante dentro de la lógica de negocio. Esta tarea fue desempeñada a lo largo de la
implementación (paralela), ya que facilita la comunicación entre los integrantes del grupo, cuando se
quiere integrar funcionalidades.
2.4.3. Cambios durante la implementación
Los cambios en los requerimientos son inevitables [12] y se pueden presentar en cualquier fase del
proyecto y este caso no es la excepción, durante la fase de implementación surgieron varios cambios, sin
embargo no afectaron los requerimientos que dependían de los requerimientos modificados. A
continuación se muestra los cambios que se realizaron:
2.4.3.1. Requerimientos agregados
Los requerimientos que fueron agregados durante la fase de implementación fueron a solicitud del cliente
y considerando que el cambio no afectaba al sistema, se aceptaron e implementaron. Los requerimientos
agregados fueron los siguientes:
Importar archivos csv para la creación de requerimientos en el proyecto.
Creación de un formato para solicitar la ruta de acceso de diferentes aplicaciones y guardarla en la
Base de Datos, para evitar la constante solicitud de ellos.
El sistema debe abrir los archivos que se generen cuando el usuario lo requiera.
Página 58
Memoria de Trabajo de Grado - ISTAR
Modificación y eliminación de los requerimientos (este requerimiento fue agregado por el grupo
de trabajo)
o Se agregó dada la probabilidad de cambio que surge a la hora de especificar los
requerimientos, por lo tanto se le debe dar la opción al usuario para que lo pueda eliminar
o modificar.
2.4.3.2. Requerimientos Modificados
Los requerimientos fueron modificados por diferentes razones, dependiendo de la situación que surgía
durante la fase de implementación. Una de las razones más comunes era para mejorar la presentación de
las consultas al usuario, por ejemplo el reporte del estado del proyecto ó el reporte de los estados
individuales de los requerimientos. Además se modificó la distribución de los componentes físicos, ya que
en un principio se definió que la aplicación sería Stand Alone, sin embargo considerando que en un
proyecto se involucra más de una persona con la administración de requerimientos, se decidió cambiar la
arquitectura a una tipo repositorio, para que la base de datos sea accedida desde cualquier equipo que esté
dentro de la red local.
2.4.3.3. Requerimientos Rechazados
Durante la fase de implementación, surgen problemas donde en ocasiones no es posible conseguir la
solución, por lo tanto el requerimiento se rechaza, no sin antes verificar los requerimientos afectados por
esta decisión.
2.5. Fase de Pruebas
En la fase de pruebas el objetivo es determinar si el requerimiento es o no aprobado, teniendo en cuenta, la
especificación del requerimiento, y si es funcional, también se tienen en cuenta los casos de uso. Para esto
se realizó un plan de pruebas (ver Anexo 5: Documento de Pruebas), el cual se centra en cuatro tipos, pero
el registro se realizó para solo tres de ellas, las pruebas realizadas son:
Unitarias: Las unitarias no se encuentran registradas, ya que el grupo de trabajo durante la
implementación probaba inmediatamente después de realizar algún método, además los errores
que surgían, generalmente fueron capturados en las pruebas de integración, por lo tanto no había
necesidad de documentarlos
Frontera: las pruebas frontera está dirigida hacia los campos de texto, donde el usuario tiene
acceso y puede ingresar datos de cualquier tipo y tamaño, por lo tanto es necesario realizar las
pruebas sobre esos campos y comprobar si se está informando al usuario sobre el error.
Página 59
Memoria de Trabajo de Grado - ISTAR
Integración: Estas pruebas se realizaron durante la implementación, debido a la metodología que
se ha definido (ver Desarrollar y verificar), las pruebas de integración consisten en verificar las
nuevas funcionalidades agregadas a la aplicación y corregir su comportamiento si es necesario.
Sistema: Como su nombre lo indica, son pruebas dirigidas a toda la aplicación y fue dirigida
hacia la verificación de los requerimientos no funcionales mientras la aplicación es ejecutada.
Página 60
Memoria de Trabajo de Grado - ISTAR
VI. RESULTADOS Y REFLEXION SOBRE LOS MISMOS
1. Easy Requierement Management Tool
RMT es una herramienta para la administración de requerimientos, la cual puede ser utilizada por los
estudiantes de las asignaturas de Ingeniería de Software y Arquitectura de Software de la Pontificia
Universidad Javeriana, con el fin de facilitar y agilizar el proceso de administración de requerimientos.
Para la construcción de ERMT, se tuvo en cuenta el análisis de funcionalidades realizado a seis
herramientas que se encuentran en el mercado. A partir de este análisis y de las necesidades expuestas por
el cliente, surgieron las siguientes funcionalidades a ser implementadas:
Funcionalidad Descripción
Almacenamiento y Consulta de
requerimientos
Crear requerimientos y consultar la información de los atributos
asociados al proyecto.
Generación de reportes en Excel Generar los diferentes reportes en Excel, lo que permite la
facilidad de lectura de la información almacenada en el sistema.
Generación de grafos de
implementación
Generación de grafos de implementación para tener una
visualización general de los requerimientos y sus relaciones, a
través de gráficos
Generación de reportes del estado de
cada requerimientos y del estado del
proyecto en general
Generación de reportes sobre el estado actual del proyecto y sus
requerimientos, a través de gráficos.
Importación de archivos csv Carga de un archivo con información sobre el requerimiento
Priorización de requerimientos Opción par a la priorización de requerimientos, donde puede
seleccionar el método a usar en el proyecto
Página 61
Memoria de Trabajo de Grado - ISTAR
Localización de archivos mediante la
trazabilidad
Generación de reportes con vínculos a los documentos,
relacionados con la trazabilidad
Relación entre requerimientos Relación entre los requerimientos, donde puede escoger el tipo de
relación que manejan
Definición de tipos de
requerimientos
Permite la creación de los tipos de requerimientos que el usuario
desee, para poder agrupar los requerimientos.
Listas de V&V Dispone de varias listas de V&V para llevar un registro sobre lo
que lleva verificado del proyecto.Tabla 5: Funcionalidades generales de ERMT
2. Resultados de las Pruebas
Como se menciona en la Fase de Pruebas, el caso de estudio utilizado para realizar las diferentes pruebas,
son los requerimientos definidos de la herramienta ERMT. En esta sección se presentaran los resultados
obtenidos, de las pruebas de sistema que se utilizaron.
2.1. Características del caso de estudio
Para el caso de estudio ERMT, se tienen definidas las siguientes características:
102 requerimientos definidos (Funcionales y No funcionales).
8 tipos de requerimientos: donde los 102 requerimientos son distribuidos.
Atributos utilizados
o Id
o Descripción
o Trazabilidad (CU, SRS, SDD, Pruebas, Componente)
o Relaciones entre requerimientos.
o Priorización de Wiegers.
o Versión
o Fecha
o Estado
o Razón
o Autor
Página 62
Memoria de Trabajo de Grado - ISTAR
Entregables realizados (aparte del documento SRS):
o Grafo de implementación
o Plantilla de requerimientos en Excel.
2.2. Resultados obtenidos
A continuación se muestran los resultados obtenidos al aplicar las pruebas de software.
2.2.1. Generación de reportes
Para la generación de reportes se debe tener en cuenta que los requerimientos deben estar definidos en el
proyecto, y para esto se debe haber creado un proyecto y seleccionado los atributos que desee, en este
caso, los definidos en la sección anterior (ver Características del caso de estudio).
La generación del reporte general es uno de los reportes que toma tiempo, ya que tiene en cuenta los
atributos en su totalidad. A continuación se muestra el reporte obtenido en 14 Seg., por lo tanto se puede
decir, que cumple con el requerimiento, teniendo en cuenta que se está probando con el caso ERMT.
Ilustración 10: Pruebas - Reporte general
Página 63
Memoria de Trabajo de Grado - ISTAR
Como se muestra en la Ilustración 10: Pruebas - Reporte general, el reporte general está dividido según el
tipo de requerimiento, además incluye todos los atributos seleccionados con anterioridad. Dentro del
reporte están incluidos los 102 requerimientos especificados con ayuda de la herramienta.
2.2.2. Generación de grafos
Al probar esta funcionalidad, se debe tener en cuenta que los requerimientos deben estar definidos en el
proyecto, además de que deben estar relacionados entre ellos. En la siguiente Ilustración 11: Pruebas -
Generar Grafo 1 se muestra como genera un grafo de implementación:
Ilustración 11: Pruebas - Generar Grafo 1
El sistema solicita la ruta destino, para guardar el grafo generado, y al dar la ruta el grafo de
implementación se genera en 2 Seg. Como máximo, teniendo en cuenta que se está probando con el caso
de estudio ERMT. El grafo generado se muestra en la Ilustración 12: Pruebas - Grafo Generado 2
Página 64
Memoria de Trabajo de Grado - ISTAR
Ilustración 12: Pruebas - Grafo Generado 2
Para la generación del segundo grafo se accede de igual forma, solo que esta vez se escoge la opción
“generar grafo de implementación por estado” lo cual genera el siguiente grafo, ver Ilustració13: Pruebas -
Grafo Generado 3
Página 65
Memoria de Trabajo de Grado - ISTAR
El grafo muestra el orden de implementación, sin embargo a diferencia de la Ilustración 12: Pruebas -
Grafo Generado 2, este grafo muestra el estado de cada requerimiento, donde el color representa el estado
(ver en la parte superior derecha, las convenciones), sin dejar de lado la distribución de los requerimientos
(note que los requerimientos siguen agrupados según el tipo de requerimiento, que debe ser previamente
definido).
2.2.3. Priorización
Uno de los métodos que implica la realización de varios cálculos seguidos, es la priorización de Wiegers
dado que cada actualización que se realice, ya sea en un criterio, modifica el resultado de cada uno de
ellos. Por lo tanto es necesario realizar las pruebas necesarias, para saber si cumple el tiempo definido en
el requerimiento. En la Ilustración 14: Pruebas -Priorización de Wiegers, se muestra el cambio de los
valores en la priorización
Ilustración 14: Pruebas -Priorización de Wiegers 1
Página 67
Memoria de Trabajo de Grado - ISTAR
Al dar clic en modificar, el sistema debe actualizar los valores y mostrarlos en el campo prioridad, de la
pantalla Información del requerimiento. En la Ilustración 15: Pruebas - Priorización de Wiegers, se
muestra como se muestra después de haber modificado.
Ilustración 15: Pruebas - Priorización de Wiegers
2.2.4. Localización
Para la localización se debe definir los archivos involucrados, para que puedan ser accedidas desde el
reporte de trazabilidad. Para registrarlos se tiene el siguiente acceso:
Ilustración 16: Pruebas - Localización
Página 68
Memoria de Trabajo de Grado - ISTAR
Al generar el reporte de trazabilidad, se debe tener en cuenta que los valores registrados en el los campos
relacionados con la trazabilidad, deben hacer referencia a los marcadores de Microsoft Word, para que así
pueda crear un hipervínculo de manera correcta, en la imagen Ilustración 17: Pruebas - Localización -
Trazabilidad se muestra un reporte de trazabilidad con los hipervínculos generados.
Ilustración 17: Pruebas - Localización - Trazabilidad
Como se puede ver en la imagen el requerimiento 41, tiene casos de uso asociados y cada celda es un
hipervínculo al archivo donde esta exactamente descrito el caso de uso. Este proceso es generado de
manera correcta si se tienen en cuenta las siguiente precondiciones:
Deben estar definidos los archivos de localización
En cada archivo deben estar definidos los diferentes marcadores que desea utilizar
Los marcadores descritos deben ser registrados en los campos de trazabilidad según corresponda.
Página 69
Memoria de Trabajo de Grado - ISTAR
2.2.5. Cargar Ayuda
El sistema debe mostrar una tabla que le permita relacionar los diferentes requerimientos entre ellos.
Para cargar el manual de usuario de la herramienta, se debe ingresar por la barra de herramientas de
ERMT. Al seleccionar la opción de la ayuda, se despliega el siguiente documento, el cual hace referencia
al menú de usuario (Ilustración 18: Pruebas - Cargar Ayuda)
Ilustración 18: Pruebas - Cargar Ayuda
2.2.6. Informes de Error al crear Artefactos
Para crear un artefacto, es necesario tener en cuenta las restricciones descritas en el manual de usuario ya
que por ejemplo, al crear un requerimiento, si no se selecciona un tipo de requerimiento, la herramienta
desplegará un mensaje de error ya que no se pueden crear requerimientos en un proyecto si el
requerimiento no está definido en un tipo de requerimiento.
En la Ilustración 19: Pruebas - Error de Creación, se muestra uno de los mensajes de error que pueden
ocurrir cuando no se selecciona un tipo de requerimiento, por lo tanto es correcto afirmar que la
herramienta ERMT cumple con el requerimiento, teniendo en cuenta que se está ejecutando el caso de
prueba ERMT.
Página 70
Memoria de Trabajo de Grado - ISTAR
Ilustración 19: Pruebas - Error de Creación
2.2.7. Informe de Error al Modificar
Para modificar los artefactos existentes dentro de la herramienta, es necesario que estos artefactos
cumplan con las restricciones de cada tipo. Por ejemplo al modificar la información de un proyecto, el
nombre del proyecto no se puede repetir, por lo tanto se debe mostrar un mensaje de error notificándole al
usuario que no es posible modificar el proyecto (ver Ilustración 20: Pruebas - Error de Modificación).
Este requerimiento se cumple y se está probando con el caso de prueba ERMT.
Página 71
Memoria de Trabajo de Grado - ISTAR
Ilustración 20: Pruebas - Error de Modificación
3. Reporte de pruebas
El reporte de pruebas se ha realizado en dos fases, con el objetivo de corregir los errores que iban
surgiendo en esta primera fase, así en la segunda poder confirmar los que no tuvieron problemas y probar
los que no fueron aceptados.
Teniendo en cuenta lo anterior, los resultados de la primera fase fue del 65% de aprobados, mientras que
el resto de casos tuvieron problemas, se realizaron las correcciones correspondientes y en la segunda fase
se tiene cerca del 100% de casos de prueba verificados y aprobados. (Para ver el registro de pruebas ir a
Anexo 5: Documento de Pruebas)
Con respecto a las pruebas de sistema, se llevó a cabo el mismo proceso en 2 fases, sin embargo en ésta
última fase, además de verificar si las correcciones fueron de utilidad, también se verificaron los datos
aproximados para el cumplimiento de los requerimientos funcionales (tiempos de respuesta) y fueron
registrados dentro del reporte de pruebas. (Para ver el registro de pruebas ir a Anexo 5: Documento de
Pruebas).
Página 72
Memoria de Trabajo de Grado - ISTAR
VII. CONCLUSIONES Y TRABAJOS FUTUROS
1. Conclusiones
La administración de requerimientos es un proceso que facilita y ayuda al grupo de trabajo, a tomar
decisiones relacionadas con el desarrollo del proyecto, de esta forma se tiene una gestión de
requerimientos exitosa, lo cual se vería reflejado en las demás fases. Por esta razón, se decidió realizar una
herramienta que soporte el proceso de administración de requerimientos de los estudiantes de las
asignaturas de Ingeniería de Software y Arquitectura de Software.
La herramienta ERMT, resultado final de este trabajo, fue implementada siguiendo las buenas prácticas de
la de ingeniería de requerimientos. Gracias a esto los requerimientos definidos y aprobados para la
herramienta fueron implementados en su totalidad, asegurando así el éxito del proyecto.
Al finalizar el proceso de implementación de la herramienta ERMT, se llegó a las siguientes conclusiones:
- En la fase de recolección de información, es de vital importancia consultar la mayor cantidad de
fuentes, tanto bibliográficas, (las cuales permiten establecer una base de conocimientos), como de
recurso humano, ya que esto le permite al grupo de trabajo llevar a cabo una recolección de
requerimientos que abarque la totalidad del sistema.
- A pesar de que durante la elaboración del marco teórico (en la fase de recolección de
información), ocurrió un desfase con respecto a los tiempos estimados, el resultado fue más que
satisfactorio, dado que ése documento fue el principal insumo para el proceso en general, desde la
definición de requerimientos hasta la elaboración del manual de usuario (ver el Marco Teórico
completo, ir a Anexo 4: Marco Teórico).
- En la fase de implementación, la ejecución de una metodología como Scrum [56], permitió el
desarrollo e integración de funcionales de manera incremental, lo que facilito la resolución de los
conflictos que se presentaron al inicio de esta fase. Además, la metodología permite establecer
pequeñas metas de desarrollo, las cuales hacen que el desarrollador, vea los resultados a corto
plazo.
- Con respecto a los cambios, durante el proceso de implementación, se puede concluir que no se
tuvo ningún inconveniente a la hora de integrarlos al sistema, esto se debe precisamente a los
métodos que se utilizaron en la implementación e integración. Hubo problemas con algunas
Página 73
Memoria de Trabajo de Grado - ISTAR
funcionalidades como la generación de reportes en Microsoft Word y después de considerarlo con
el director se decidió rechazar ese requerimiento, ya que podría llegar afectar los tiempos
previamente definidos.
La aplicación ERMT fue utilizada en un ambiente académico para que los estudiantes puedan aplicar los
conocimientos del proceso de administración de requerimientos durante la práctica (desarrollo del
proyecto), para esto ERMT posee características propias del proceso de Ingeniería de requerimientos que
se exponen en las clases de Ingeniería de Software e Ingeniería de requerimientos de la PUJ.
ERMT proporciona funcionalidades las cuales, considerando la información recolectada y analizada en la
fase de exploración, son fundamentales a la hora de escoger y utilizar una herramienta de administración
de requerimientos.
Las funcionalidades que identifican a ERMT son:
- Generación de grafos de implementación y estado, lo cual asegura un mejor control sobre los
requerimientos de un proyecto.
- Suministra listas de verificación y validación, sencillas que generan un alto impacto sobre el
proyecto, debido a que por medio de estas se conoce si los requerimientos están correctos o
requieren de una revisión.
- Los diferentes tipos de reportes, ya que muchas herramientas generan informes, pero no tienen en
cuenta informes en los cuales se indique el estado del proyecto, ó la trazabilidad de los
requerimientos.
- ERMT proporciona dos métodos de priorización, opción que no se encuentra en las aplicaciones
analizadas previamente, dando así al usuario más herramientas para la toma de decisiones dentro
del proyecto que está desarrollando.
2. Trabajos Futuros
A partir de la elaboración de este Proyecto, surgen varios trabajos a futuro. Uno de ellos está relacionado
con las pruebas de usabilidad, dado que dentro del alcance de este Trabajo de Grado, no se había
planteado realizar pruebas con respecto al usuario final para su posterior implantación en las asignaturas
de Ingeniería de Software y Arquitectura de Software, se propone como trabajo futuro realizar las pruebas
de usuario final a ERMT (los estudiantes) y tener conocimiento sobre los resultados, frente a ésta nueva
herramienta. Adicional a esto, otro proyecto a futuro es la elaboración de un cuadernillo de notas de clase,
Página 74
Memoria de Trabajo de Grado - ISTAR
que presente el proceso actual de la ingeniería de requerimientos, el cual incluye el marco teórico sobre
los diferentes conceptos del proceso que se lleva a cabo, la construcción de ejemplos y ejercicios, que
conforman la parte práctica de este proyecto, lo cual será de utilidad para los estudiantes que cursan las
asignaturas relacionadas a éste tema.
Por último, como proyecto a mediano y largo plazo se propone la implantación de la aplicación, en
primera instancia en las asignaturas de Ingeniería de Software y Arquitectura de Software de la PUJ,
donde se desarrollan proyectos que pueden aplicar un proceso de administración de requerimientos y a
largo plazo, se propone utilizar esta herramienta en diferentes instituciones donde se aplique el proceso de
administración de requerimientos.
Página 75
Memoria de Trabajo de Grado - ISTAR
VIII. REFERENCIAS Y BIBLIOGRAFIA
[1]. Wiegers K, SOFTWARE REQUIREMENTS. Second edition. Microsoft Press ©; 2003
[2]. Sommerville I, INGENIERÍA DE SOFTWARE. Séptima Edición. Madrid, España: Pearson
Educación; 2005.
[3]. IEEE std. 830-1998. IEEE recomended practice for software requirements specifications, IEEE,
1998
[4]. Young R, THE REQUIREMENTS ENGINEERING HANDBOOK. London, United Kingdom:
Artech Hause; 2004.
[5]. Aurum A, Wohlin C. ENGINEERING AND MANAGING SOFTWARE REQUIREMENTS.
Berlín. Germany: © Springer; 2005.
[6]. Wiegers K, MORE ABOUT SOFTWARE REQUIREMENTS. Thorny issues and practical advice.
Microsoft Press ©;2006
[7]. THE STANDISH GROUP REPORT, CHAOS. [Reporte de estudio en Internet]. © The Standish
Group 1995. Disponible en: http://www.projectsmart.co.uk/docs/chaos-report.pdf
[8]. Sommerville I, Sawyer P. REQUIREMENTS ENGINEERING, A Good Practice Guide. John Wiley
& Sons Ltd. Copyright © 1997.
[9]. IEEE Computer Society. Guide to the Software Engineering Body of Knowledge (SWEBOK).
Chapter 2 software requirements. [Homepage]. Disponible en:
http://www.computer.org/portal/web/swebok/html/ch2 [Ultima fecha de consulta: 13 de septiembre
de 2010].
[10]. Hokkanen M. REQUIREMENTS TRACEABILITY. [Documento en Internet]. Disponible en:
https://oa.doria.fi/bitstream/handle/10024/35358/nbnfi-fe20011576.pdf?sequence=1
[11]. Eriksson, M. Borg, K. Börstler, J. The FAR Approach – Functional Analysis/Allocation and
Requirements Flowdown Using Use Case Realizations [Artículo en Internet]. Incose. 2006.
Disponible en: http://www8.cs.umu.se/~jubo/Papers/INCOSE06a.pdf [Ultima fecha de consulta: 13
de septiembre de 2010].
[12]. Hood C, Wiedemann S, Fichtinger S, Pautz U. Requirements Management, The Interface Between
Requirements Development and All Other Systems Engineering Processes. Oberhaching Germany.
© 2008 Springer.
Página 76
Memoria de Trabajo de Grado - ISTAR
[13]. Integrated Chipware Technical Paper. Establishing a Requirements Management Process.
[Documento en Internet] Disponible en: http://homepages.laas.fr/kader/Chpware.pdf [Fecha de
consulta: 21 de Julio de 2010].
[14]. Requirements Management School. Benefits of Requirements Management Tool. [Homepage en
Internet]. Disponible en:
http://www.productmanagementschool.com/w1/Benefits_of_Requirements_Management_Tool.
[Última Fecha de Consulta: Septiembre 11 de 2010]
[15]. Hoffmann, M. Kühn, N. Weber, M. Bittner, M. Requirement for Requirements tools. IEEE
Computer Society.
[16]. Product Management Insights. Requirements Management Tools – Overview. [Artículo en
Internet]. Disponible en:
http://www.accompa.com/product-management-blog/2009/07/30/requirements-management-tools-
overview/. [Última Fecha de Consulta: Septiembre 11 de 2010]
[17]. Davis a, Leffingwell D. Using Requirements Management to Delivery of Higher Quality
Applications. [Artículo]. Disponible en: http://citeseerx.ist.psu.edu/viewdoc/summary?
doi=10.1.1.22.3297. [Última Fecha de Consulta: septiembre 11 de 2010].
[18]. Lauesen S. Software Requirements, Styles and techniques. Primera Edición. Londres, Inglaterra:
Pearson Education, 2002.
[19]. DEPARTMENT OF THE AIR FORCE, Software Technology Support Center. Guidelines for
Successful Acquisition and Management of Software-Intensive Systems: Weapon Systems
Command and Control Systems Management Information Systems. Versión 4.0 February 2003.
[Documento en Internet]. Disponible en: http://www.stsc.hill.af.mil/resources/tech_docs/. [Última
fecha de consulta: Agosto 10 de 2010].
[20]. Requirements Management School. Benefits of Good Requirements Management Process.
[Homepage en Internet]. Disponible en:
http://www.requirementsmanagementschool.com/w1/Benefits_of_Good_Requirements_Managemen
t_Process. [Última Fecha de Consulta: Septiembre 11 de 2010]
[21]. Rational Unified Process. Activity: Establish Change Control Process. Copyright © 1987 - 2003
Rational Software Corporation. [Homepage en Internet]. Disponible en:
http://rup.hops-fp6.org/process/activity/ac_epcmp.htm. [Última Fecha de Consulta: Septiembre 10
de 2010].
Página 77
Memoria de Trabajo de Grado - ISTAR
[22]. Nuseibeh B, Easterbrook S. Requirements Engineering: A Roadmap. [Artículo en Internet].
Disponible en: http://www.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf. [Última fecha de consulta: Agosto 10
de 2010].
[23]. New York State Office for Technology. Project Management Guidebook, Release 2. [Documento
en Internet]. Disponible en: http://www.cio.ny.gov/pmmp/guidebook2/TOCandPreface.pdf. [Última
fecha de consulta: Agosto 10 de 2010].
[24]. Construction Management Guide. Create Requirements Management Plan. [Homepage en
Internet]. Disponible en: http://cmguide.org/archives/1420. [Última Fecha de Consulta: Septiembre
10 de 2010]
[25]. Ludwig Consulting Services. INTRODUCTION TO REQUIREMENTS MANAGEMENT. LLC.
copyright 2009 [Homepage en Internet]. Disponible en:
http://www.jiludwig.com/Requirements_Management.html. [Última Fecha de Consulta: Septiembre
10 de 2010]
[26]. Heumann Jim. The five levels of requirement management maturity. Requirements evangelist.
Rational Software. 2003.
[27]. Young, Ralph. Twelve Requirements Basics for Project Success. CrossTalk, the journal of defense
software engineering. Northrop Grumman Information Technology Defense Group. 2006. [Artículo
en Internet] Disponible en: http://www.stsc.hill.af.mil/crosstalk/2006/12/0612young.html [Ultima
consulta: 10 de agosto de 2010].
[28]. Connections. Requirements Analysis. [Homepage en Internet]. Disponible en:
http://cnx.org/content/m14621/latest/. [Última fecha de consulta: Agosto 14 de 2010]
[29]. Department of Defense, Systems Management College. SYSTEMS ENGINEERING
FUNDAMENTALS. [Documento en Internet]. Disponible en:
http://spacese.spacegrant.org/SEModules/Reference%20Docs/DAU_SE_Fundamentals.pdf
[30]. Leandro Antonelli, Alejandro Oliveros. Trazabilidad en la Etapa de Recolección de
Requerimientos. [Articulo en Internet]. Disponible en:
http://www.lifia.info.unlp.edu.ar/papers/2000/Antonelli2000.pdf. [Última Fecha de consulta: Agosto
31 de 2010]
% Grady J. System Requirements Analysis. Academic Press. Copyright 2006.
[31]. Gahill T, Henderson S. Requirements Development, Verification and Validation Exhibited in
Famous Failures. Systems Engineering, Vol. 8, No. 1, 2005. © 2004 Wiley Periodicals, Inc.
Página 78
Memoria de Trabajo de Grado - ISTAR
[32]. Wiegers K. When Telepathy Won’t Do:
Requirements Engineering Key Practices. [Artículo en Internet]. Disponible en:
http://www.processimpact.com/articles/telepathy.html. [Última fecha de consulta: Agosto 15 de
2010]
[33]. Sheldon F. Requirements Engineering, Chapter 4 Requirements Validation. [Presentación en
internet]. Disponible en: http://www.csm.ornl.gov/~sheldon/cs531/ch4.pdf. University of Colorado
at Colorado Springs. [Última fecha de consulta: Agosto 15 de 2010]
[34]. Pinheiro F. Chapter 5, REQUIREMENTS TRACEABILITY Universidad de de Brasilia.
[Documento en Internet]. Disponible en: http://www-di.inf.puc-rio.br/~julio/Chapter%205.pdf.
[Última Fecha de consulta: Agosto 31 de 2010]
[35]. Alexander, Ian. Writing Better Requirements. Pearson Education. Gran Bretaña. 2002.
[36]. International Institute of Business Analysis. The Guide to the Business Analysis Body of
Knowledge. Versión 2.0. [Documento en Internet]. Disponible en: www.b2ttraining.com. [Última
Fecha de Consulta: Agosto 26 de 2010].
[37]. Morris T. Revealing the ISO/IEC 9126-1 Clique Tree for Software Evaluation. [Documento en
Internet]. Disponible en: http://www.pdftop.com/ebook/iso+9126/. [Última Fecha de Consulta:
Agosto 26 de 2010].
[38]. Losavio F, Chirinos C, Lévy N, Ramdane A. Quality Characteristics for Software. [Artículo en
Internet]. Disponible en:
http://sophia.javeriana.edu.co/~cbustaca/Arquitectura%20Software/Documentos/Calidad/Articulos/
Losa2003.pdf. [Última Fecha de Consulta: Agosto 26 de 2010]
[39]. The Land Software Engineering Centre. Requirements Attributes [Documento en Internet]. 2010.
Disponible en: http://www.lsec.dnd.ca/qsd_current_version/sw_eng/di/reqpro_attributes.htm
[Ultima fecha de consulta: Septiembre 01 de 2010]
[40]. Ludwig Consulting Services. INTERVIEWING USERS—TIPS. LLC. copyright 2009 [Homepage
en Internet]. Disponible en: http://www.jiludwig.com/Interviews.html. [Última Fecha de Consulta:
Agosto 30 de 2010].
[41]. Hull E, Jackson K, Dick J. Requirements Engineering. Second Edition. 2005. Springer London.
[42]. Ortiz, Ana. SRS y calidad de requerimientos [Presentación en internet]. Pontificia Universidad
Javeriana. 2007. Disponible en:
http://sophia.javeriana.edu.co/%7Emetorres/Materias/IngReq/Documentos/CALIDAD%20DE
%20REQUERIMIENTOS.rar. [Fecha de consulta: 30 de agosto de 2010].
Página 79
Memoria de Trabajo de Grado - ISTAR
[43]. Mead, Nancy. Requierements Priorizitation Introduction [Articulo en Internet]. Software
Engineering Institute. 2006. Disponible en: https://buildsecurityin.us-cert.gov/bsi/articles/best-
practices/requirements/545-BSI.html. [Fecha de consulta: 29 de agosto de 2010].
[44]. Firesmith, D. Prioritizing Requirements. [Articulo en internet]. Software Engineering Institute.
2004. Disponible en: http://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.106.8608&rep=rep1&type=pdf. [Fecha de consulta: 28 de agosto de 2010].
[45]. Herrmann, A. Maya Daneva, M. Requirements Prioritization Based on Benefit and Cost
Prediction: An Agenda for Future Research. [Articulo]. 16th IEEE International Requirements
Engineering Conference. 2008.
[46]. Berander, P. Andrews, A. Engineering and Managing Software Requirements. [Libro en Internet].
Springer Berlín Heidelberg. 2005. Pg. 69-94. [Fecha de consulta: 28 de agosto de 2010].
[47]. Wiegers, Karl. First Things First: Prioritizing Requirements. [Articulo en internet]. 1999.
Disponible en: http://www.processimpact.com/articles/prioritizing.html. [Fecha de consulta: 27 de
agosto de 2010].
[48]. Barbacci M, Klein M, Longstaff T, Weinstock C. Quality Attributes. Diciembre 1995.
[49]. The Standish Group. CHAOS summary report [Homepage en internet]. Disponible en:
http://www1.standishgroup.com/newsroom/chaos_2009.php
[50]. Software Requirement traceability tool (Tracer). [Homepage en Internet]. Disponible en:
http://www.softreq.com/tracer/index.cfm
[51]. Ramesh B, Jarke M. Towards reference models for requirements traceability. [Articulo en
Internet]. Disponible en: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.6602. Mayo
1999.
[52]. Wiegers K. Automating Requirements Management. [Homepage En Internet]. Disponible en:
http://www.processimpact.com/articles/rm_tools.html
[53]. Withal S. Software Requirements patterns. Microsoft Press, 2007.
[54]. Firesmith, D. Prioritizing Requirements. [Articulo en internet]. Software Engineering Institute.
2004. Disponible en: http://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.106.8608&rep=rep1&type=pdf. [Fecha de consulta: 28 de agosto de 2010].
[55]. Davis A, Yourdon E, Zweig A. Requirements Management Made Easy. [Articulo en internet].
Disponible en: http://homepages.laas.fr/kader/Davis_et_al.pdf [Última Fecha de consulta: Agosto 14
de 2010]
Página 80
Memoria de Trabajo de Grado - ISTAR
[56]. Scrum.org. SCRUM. [Documento en Internet]. Disponible en:
http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit
[57]. Mountain Goat Software. Introduction to SCRUM. [Homepage en Internet]. Disponible en:
http://www.mountaingoatsoftware.com/topics/scrum
Página 81
Memoria de Trabajo de Grado - ISTAR
IX. ANEXOS
1. Anexo 1: Documento de Visión
2. Anexo 2: Documento de Especificación de Requerimientos
3. Anexo 3: Documento de Diseño
4. Anexo 4: Marco Teórico
5. Anexo 5: Documento de Pruebas
6. Anexo 6: Presupuestos
7. Anexo 7: Entrevista.
8. Anexo 8: Documento de casos de uso
9. Anexo 9: Reporte de Pruebas.
Página 82