pegasus.javeriana.edu.copegasus.javeriana.edu.co/.../memoria/memoria.docx · web viewel trabajo...

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



CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.

Enero, 2011

Página i




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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


- 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


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


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


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


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


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


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


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


- 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


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


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


- 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Ilustració13: Pruebas - Grafo Generado 3

Página 66


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


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


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


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


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


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


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


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


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


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


[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


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


[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


[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


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


[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


[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


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

pegasus.javeriana.edu.copegasus.javeriana.edu.co/.../memoria/memoria.docx · web viewel trabajo...

Documents