propuesta para trabajo de grado - …pegasus.javeriana.edu.co/~cis1410is08/final/memoria... ·...

CIS1410IS08HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA DE

SOFTWARE DE LA PONTIFICIA UNIVERSIDAD JAVERIANA.

CARLOS DAVID DUARTE ALFONSO

PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.

2014

Ingeniería de Sistemas ISTAR – CIS1410IS08

CIS1410IS08HERRAMIENTA 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:

Carlos David Duarte Alfonso

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE

SISTEMAS

Director

Ing. Miguel Eduardo Torres Moreno, MSc.

Jurados del Trabajo de Grado

Ing. Jaime Andrés Pavlich-Mariscal, PhD.

Ing. Javier Francisco López Parra, MSc.

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~CIS1410IS08/


CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.

JUNIO, 2014

Página 2

http://pegasus.javeriana.edu.co/~CIS1410IS08/

Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica


CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnífico

Jorge Humberto Peláez Piedrahita S.J.

Decano Académico Facultad de Ingeniería

Ingeniero Jorge Luis Sánchez Téllez

Decano del Medio Universitario Facultad de Ingeniería

Padre Antonio José Sarmiento S.J.

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Director Departamento de Ingeniería de Sistemas

Ingeniero Rafael Andrés González Rivera

Página 3

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


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 4


AGRADECIMIENTOS

Primero que todo quiero agradecer a Dios, ya que sin Él nada sería posible. Luego quiero

agradecer a mi padre y mi madre, por el gran esfuerzo que hicieron a lo largo de toda mi

carrera, por su apoyo incondicional en todo momento, porque gracias a ellos puede estudiar y

lograr terminar esta etapa tan importante en mi vida, también quiero agradecer a mi hermano,

que siempre estuvo presente para darme consejos y ánimos en los momentos difíciles. Quiero

agradecer al ingeniero Miguel Torres, que estuvo presente durante todo este proceso, y ha

sido una ayuda constante, gracias por sus enseñanzas, consejos y correcciones a lo largo del

semestre.

Página 5



Contenido

INTRODUCCIÓN.....................................................................................................12

I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO............................13

1. OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES..........................................131.1. Descripción del contexto........................................................................................131.2. Pregunta de investigación......................................................................................141.3. Justificación............................................................................................................151.4. Impacto Esperado...................................................................................................161.5. Descripción del Proyecto.......................................................................................171.6. Objetivo general.....................................................................................................171.7. Objetivos específicos..............................................................................................171.8. Fases Metodológicas o conjunto de objetivos específicos.....................................181.9. Fase de exploración................................................................................................181.10. Fase de desarrollo ágil........................................................................................191.11. Método que se propuso para satisfacer cada fase metodológica........................21

II - MARCO TEÓRICO............................................................................................23

2. MARCO CONCEPTUAL......................................................................................232.1. ¿Qué es la ingeniería de requerimientos?..............................................................232.2. ¿Qué es el desarrollo de requerimientos?..............................................................242.3. ¿Qué es la administración de requerimientos?......................................................272.4. Buenas prácticas para la administración de requerimientos.................................282.5. Prácticas de gestión de requerimientos..................................................................302.6. Herramientas de administración de requerimientos..............................................342.7. Gestión de riesgos..................................................................................................36

III – DESARROLLO DEL TRABAJO....................................................................393.1. Fase de exploración................................................................................................393.2. Fase de desarrollo..................................................................................................43

IV - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS.............................51

4. RESULTADOS....................................................................................................514.1. Línea base de requerimientos.................................................................................524.2. Problemas en los requerimientos...........................................................................534.3. Proceso control de cambios...................................................................................544.4. Gestión de riesgos..................................................................................................554.5. Matriz de trazabilidad............................................................................................56

Página 6


V – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS....57

5.1. CONCLUSIONES.................................................................................................58

5.2. RECOMENDACIONES.........................................................................................58

5.3. TRABAJOS FUTUROS.........................................................................................58

VI - POST-MORTEM...............................................................................................60

6.1. METODOLOGÍA PROPUESTA VS. METODOLOGÍA REALMENTE UTILIZADA........60

6.2. ACTIVIDADES PROPUESTAS VS. ACTIVIDADES REALIZADAS............................60

6.3. EFECTIVIDAD EN LA ESTIMACIÓN DE TIEMPOS DEL PROYECTO........................60

6.4. COSTO ESTIMADO VS. COSTO REAL DEL PROYECTO........................................62

6.5. EFECTIVIDAD EN LA ESTIMACIÓN Y MITIGACIÓN DE LOS RIESGOS DEL PROYECTO.....................................................................................................................63

VII - REFERENCIAS Y BIBLIOGRAFÍA.............................................................64

7. REFERENCIAS...................................................................................................64

VIII - ANEXOS..........................................................................................................67

ANEXO 1. SOFTWARE PROJECT MANAGEMENT PLAN.................................................67

ANEXO 2. DOCUMENTO DE CASOS DE USO..................................................................67

ANEXO 3. SOFTWARE REQUIREMENTS SPECIFICATION................................................67

ANEXO 4. DOCUMENTACIÓN REQUERIMIENTOS..........................................................67

ANEXO 5. DOCUMENTO DE DISEÑO..............................................................................67

ANEXO 6. DOCUMENTO DE PRUEBAS...........................................................................67

ANEXO 7. CARTA DE APROBACIÓN..............................................................................67

ANEXO 8. PROPUESTA TRABAJO DE GRADO.................................................................67

ANEXO 9. DIAGRAMA CASOS DE USO...........................................................................67

ANEXO 10. DIAGRAMA DE CLASES..............................................................................67

ANEXO 11. DIAGRAMA ENTIDAD RELACIÓN................................................................67

ANEXO 12. MANUAL DE USUARIO...............................................................................67

Página 7



ABSTRACT

With the continuous growth of the IT project development and software applications

available today, it is necessary to properly manage requirements, because in a globalized and

connected world, the factors of quality, cost, time and maintenance are essential for the

success of a software project. The following undergraduate work presents new development

version of the "Easy requirement Management Tool", to which we have added new

functionalities for managing requirements and risk management thereof, for the purpose of

assisting in this critical process.

Página 8


RESUMEN

El continuo crecimiento del desarrollo de proyectos y aplicaciones de software que hay en la

actualidad, es necesario llevar una adecuada gestión de los requerimientos, ya que en un

mundo tan globalizado y conectado, los factores de calidad, costos, tiempo y mantenimiento

son esenciales para el éxito de un proyecto. El siguiente trabajo de grado consistió en el

desarrollo de la nueva versión de la herramienta “Easy requirement Management Tool”, la

cual le hemos añadido nuevas funcionalidades para la administración de los requerimientos y

la gestión de riesgos de los mismos, con el propósito de ayudar en este proceso crítico.

Página 9



RESUMEN EJECUTIVO

Los requerimientos son la parte esencial de todo proyecto de software, ya que estos definen

las necesidades de los clientes y como el sistema debe ser implementado para satisfacer di -

chas necesidades, pero también determina elementos tan esenciales como el alcance y los

objetivos del proyecto, el presupuesto, los tiempos de entrega, la calidad del producto final,

entre otros aspectos importantes. Como hemos visto los requerimientos son el soporte princi-

pal de todo un proyecto, por lo cual es importante llevar un adecuado manejo de estos a lo

largo de todo su desarrollo, ya que estos determinan el éxito de un proyecto. Este proceso de

manejar los requerimientos se le conoce como la administración de requerimientos y consiste

en diferentes actividades como las son: definición de líneas base, control de cambios, relacio -

nes y dependencias que existen entre los requerimientos, seguimiento del estado de los reque-

rimientos, trazabilidad de requerimientos entre otras.

En la actualidad existen gran variedad de herramientas que permiten la administración de

requerimientos en un proyecto de software, las cuales ofrecen una gran cantidad de funciona-

lidades, pero a la vez tienen el inconveniente de tener un costo de licencias muy altas, por lo

cual solo un grupo de grandes compañías pueden acceder a estas. Este proceso de la adminis-

tración de requerimientos se vuelve crítico y tedioso cuando se tiene que realizar a través de

documentos y otros tipos de archivos, ya que no se puede tener un control adecuado sobre

cada uno de estos, y esto genera una gran cantidad de problemas como por ejemplo la incon-

sistencia entre documentos, no se tiene control sobre quien puede modificar los archivos, no

se lleva un historial de cambios que permita conocer la evolución de los requerimientos a lo

largo del ciclo de vida, la probabilidad de algunos requerimientos estén duplicados o sean

innecesarios es muy alta, debido a que no están almacenados en un repositorio central, que

permita gestionar estos inconvenientes.

Este proceso de la administración de requerimientos se lleva a cabo en las materias de Inge-

niería de Software y Arquitectura de Software de la Pontificia Universidad Javeriana, como

parte de la formación de los estudiantes de pregrado de la carrera de ingeniería de sistemas,

los cuales tienen que desarrollar un proyecto a lo largo del semestre, el cual consiste en obte-

Página 10


ner, documentar, priorizar y desarrollar los requerimientos, con el propósito de entregar un

prototipo funcional que cumpla con las necesidades de los clientes y sea de calidad.

Este trabajo de grado consistió en la continuación del desarrollo de la herramienta para la

administración de requerimientos ERMT, la cual fue desarrollada por dos estudiantes de inge-

niería de sistemas de la Pontificia Universidad Javeriana. Se decidió continuar con el desarro-

llo de esta herramienta, debido a que este proceso es bastante crítico dentro de la elaboración

de los proyectos en estas materias y también porque había funcionalidades que le faltaban a

ERMT complementar este proceso.

Estas funcionalidades se obtuvieron mediante la investigación de herramientas para la admi-

nistración de requerimientos, lecturas acerca de la administración de requerimientos, estánda-

res de calidad y un análisis de la herramienta ERMT. Posteriormente se modificó la arquitec-

tura de ERMT para que pudiera soportar las nuevas funcionalidades las cuales se muestran a

continuación:

Línea base de requerimientos

Problemas en los requerimientos

Proceso control de cambios

Gestión de riesgos

Matriz de trazabilidad

Estas funcionalidades se irán explicando en detalle a lo largo de este documento, además

estas permitieron cumplir con los objetivos específicos del trabajo de grado ya que se logró

adherir a ERMT estas nuevas características sin afectar a las que ya existían, se logró verifi -

car que las nuevas funcionalidades se ejecutaran correctamente mediante la ejecución de

pruebas funcionales.

Página 11



INTRODUCCIÓN

El presente documento describe el proceso que se llevó a cabo durante el desarrollo de la

versión 2.0 de ERMT, y en particular para describir el proceso de análisis, diseño y desarrollo

de las nuevas funcionalidades para la herramienta de software “Easy Requirement

Management Tool”, la cual permite la administración de requerimientos en un proyecto de

software, para las materias de Ingeniería de Software y Arquitectura de Software de la

Pontificia Universidad Javeriana. [1] En esta nueva versión de “Easy Requirement

Management Tool”, se le denominará como “ERMT 2.0” y la herramienta que ya existía se le

denominara como “ERMT 1.0”, para temimos de simplicidad y definir claramente las

diferencias entre una versión y la otra.

Para la adición de las nuevas funcionalidades se realizó un análisis previo a “ERMT 1.0”, el

cual consistió en conocer que funcionalidades básicas que tenía, luego se realizó un estudio

de diferentes herramientas de administración de requerimientos existentes, donde se

determinaban sus funcionalidades y por último se realizó una investigación sobre la

ingeniería de requerimientos, que permitió confrontar junto con la información previa y poder

así determinar las nuevas funcionalidades que se le agregarían a “ERMT 2.0”.

Página 12


I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO

1. Oportunidad, Problemática, Antecedentes

1.1. Descripción del contexto

En la actualidad los proyectos de tecnología de la información (TI), tan solo el 32% tienen

éxito, es decir, el software final cumple con los tiempos de entrega, costos, y entrega de los

requerimientos establecidos desde el principio de su ejecución. Un 44% de los proyectos de

TI presentaron diferentes deficiencias, como por ejemplo: retrasos, sobrecostos, baja calidad,

entre otros, y el 24% restante de los proyectos TI fracasaron, es decir, se canceló antes del

tiempo establecido o el software nunca se utilizó. Estas son algunas de las estadísticas que

presentó la compañía “The Standish Group” en su último y más reciente informe “CHAOS”,

acerca sobre el fracaso de los proyectos en el sector de las tecnologías de la información. [8]

Este informe indica cuales fueron las principales causas del fracaso en los proyectos TI, los

cuales se muestra a continuación:

Causa Porcentaje

Requerimientos incompletos 13.1

Falta de involucramiento de usuarios 12.4

Falta de recursos 10.6

Expectativas no realistas 9.9

Falta de soporte ejecutivo 9.3

Cambios de requerimientos 8.7

Falta de planificación 8.1

Desaparición de la necesidad 7.5

Falta de administración de TI 6.2

Falta de conocimiento de la tecnología 4.3

Otros 9.9

Página 13



Tabla 1 Principales causas del fracaso

Las causas marcadas en negrilla, indican que los integrantes del proyecto no tenían claro los

requerimientos de los clientes o no fueron debidamente gestionados y por ende el alcance de

estos, no fue el apropiado. Analizando estos resultados, se puede concluir que cerca de la

mitad de los factores asociados al éxito de un proyecto o producto de software se relaciona

directa o indirectamente con los requerimientos.

Ahora bien, estos problemas en los requerimientos no son nuevos, son puntos críticos dentro

de las organizaciones a lo largo de las últimas décadas [5], además en la actualidad se ven

reflejados diariamente en el momento de comprender, documentar y gestionar los

requerimientos del producto. Esta situación genera a su vez que los requerimientos sean

incompletos, mal especificados, sean volátiles y el proceso de cambios sea informal. Todos

estos problemas ya mencionados, acarrean que el grupo de trabajo no comprenda los

objetivos de negocio y son las principales razones para que muchos de los proyectos TI no

tengan éxito, igualmente estos inconvenientes en estas actividades representan entre el 40% y

50% de todos los defectos que se encuentran en un producto de software [5].

Los requerimientos son la base esencial de un proyecto de software, y gestionarlos de

manera adecuada y precisa son elementos clave dentro del grupo de trabajo, ya que en estos

se definen varios factores que son muy importantes, como por ejemplo: la definición de los

grupos de interés (clientes, usuarios, proveedores, entre otros), presupuesto, tiempo, calidad,

costos y los más importante, lo que el sistema debe hacer para satisfacer esas necesidades.

[12]

1.2. Pregunta de investigación

¿Cómo puede una herramienta de administración de requerimientos, permitir la gestión y el

manejo de los riesgos en los requerimientos de un proyecto de ingeniería de software y

arquitectura de software de la Pontificia Universidad Javeriana?

Página 14


1.3. Justificación

La administración de requerimientos son todas aquellas actividades que son necesarias para

mantener el valor de los requerimientos a un alto nivel después de que se obtuvieron y

documentaron [11]. Este proceso consiste en uno de los procesos más críticos e importantes a

lo largo de todo el ciclo de vida del software en un proyecto TI, es por esta razón que es

primordial llevar a cabo una adecuada administración en los requerimientos, ya que si no hay

una rigurosidad o buenas practicas, el proyecto tendrá más probabilidad de fracasar, como se

mencionaba anteriormente en la descripción del contexto.

En la actualidad existen gran variedad de herramientas para la administración de

requerimientos en el mercado [9], pero sus costos de licencia son muy altos, además la

funcionalidades que maneja este tipo de software son para las necesidades empresariales y no

académicas, por lo cual el uso de estas herramientas es bastante compleja para los usuarios

finales, y estas son algunas de las razones que los estudiantes no pueden acceder a estas,

además no se justifica adquirir un software tan costoso y robusto cuando el proyecto se

realiza en cuatro meses aproximadamente. Otro problema que se enfrentan los estudiantes de

ingeniería de sistemas de la pontificia universidad javeriana en el momento que desarrollan

sus proyectos de ingeniería y arquitectura de software, es precisamente el proceso de la

gestión de los requerimientos a lo largo del semestre, debido a que no es posible adquirir

alguna herramienta del mercado para este fin y las actividades relacionadas a esta, se

convierten en un cuello de botella, ya que estas tareas relacionadas a este proceso, se llevan a

cabo en documentos de Word o Excel, los cuales en un momento dado no son apropiados por

la gran cantidad de documentos que se generan durante todo este proceso, además la

consistencia entre estos no es la adecuada y esto puede generar ambigüedad en el momento

del desarrollo del producto final.

Luego de comprender el contexto que se enfrentan los estudiantes, fue necesario continuar

con el desarrollo de la herramienta “Easy Requirement Management Tool” con el objetivo de

agregarle nuevas funcionalidades que permitan complementar y fortalecer el análisis que se

realiza, debido a que si no se realiza una adecuada gestión de los requerimientos, la

Página 15



probabilidad de no tener éxito en un proyecto aumenta considerablemente generando así

retrasos, sobrecostos, disminución de la calidad y cambios inesperados.

Además este trabajo de grado pretendió aportar en el desarrollo científico y tecnológico que

necesita el país como parte de la misión que tiene la pontificia universidad javeriana para la

sociedad.

1.4. Impacto Esperado

1.4.1. Corto plazo

El impacto a corto plazo esperado de este trabajo de grado es que los estudiantes de

ingeniería y arquitectura de software de la pontificia universidad javeriana, puedan utilizar

ERMT como una herramienta que les permita gestionar los requerimientos de manera

adecuada en sus correspondientes proyectos, sin la necesidad de adquirir un software

empresarial, además de involucrar a los estudiantes en un ambiente más práctico y eficiente.

1.4.2. Mediano plazo

El impacto a mediano plazo para este trabajo de grado, es que instituciones educativas ajenas

a la pontificia universidad javeriana, puedan brindarles a los estudiantes de ingeniería de

sistemas o carreras similares la herramienta ERMT, la cual les permita la gestión de los

requerimientos en sus respectivos proyectos de software que realicen a lo largo de sus

carreras y además se puedan compartir experiencias acerca del uso de este prototipo entre

estudiantes de diferentes universidades.

1.4.3. Largo plazo

El impacto a largo plazo para este trabajo de grado, es que ERMT pueda utilizarse en un

entorno empresarial, es decir, en PYMES que su razón social sea el desarrollo de software y

que les permita la gestión de los requerimientos en un proyecto de TI.

Página 16


1.5. Descripción del Proyecto

1.5.1. Visión global

Este trabajo de grado consintió básicamente con la continuación del desarrollo de una

herramienta de administración de requerimientos “Easy Requirement Management Tool” y

fue desarrollada previamente por estudiantes de la carrera de ingeniería de sistemas de la

pontificia universidad javeriana [1]. Para esta nueva versión de ERMT, se agregaron nuevas

funcionalidades que permiten la gestión y el manejo de los riesgos en los requerimientos de

un proyecto se software, las cuales se explicaran en detalle cada una de estas a lo largo de

este documento.

1.6. Objetivo general

Diseñar e implementar nuevas funcionalidades en la herramienta ERMT, que ayuden a la

administración de los requerimientos y la gestión de riesgos de los mismos, en el proyecto

para las materias de ingeniería y arquitectura de software de la pontificia universidad

javeriana.

1.7. Objetivos específicos

Los objetivos específicos de este trabajo de grado son los siguientes:

Investigar y analizar las herramientas existentes en el mercado, además de los

estándares de calidad de requerimientos, que permita conocer las funcionalidades

mínimas que debe tener ERMT.

Modificar la arquitectura existente, que permita a ERMT soportar las nuevas

funcionalidades de administración y gestión de los riesgos para los requerimientos.

Implementar las nuevas funcionalidades propuestas de acuerdo a la modificación del

diseño arquitectónico de ERMT.

Realizar las pruebas de usabilidad a ERMT.

Página 17



1.8. Fases Metodológicas o conjunto de objetivos específicos

Para la realización de este trabajo de grado, se escogieron dos fases metodologías distintas,

que principalmente permitieron cumplir el objetivo general y los objetivos específicos

propuestos anteriormente. La primera fase metodológica consistió en una exploración y la

segunda fase metodológica en la ejecución del modelo de desarrollo ágil SCRUM [10], las

cuales se van a explicar en detalle en las siguientes secciones.

1.9. Fase de exploración

La primera fase metodológica consistió en una exploración e investigación, debido a que el

primer objetivo específico tenía como propósito realizar un estudio y un análisis acerca de

ERMT 1.0, además esta fase permitió conocer más en detalle la problemática que se quiere

afrontar, realizando así una investigación más completa.

La metodología a usar en esta fase, fue la de realizar un estudio exploratorio sobre las

herramientas de administración de requerimientos existentes en el mercado, la herramienta

ERMT y realizar un análisis detallado de los estándares de calidad de requerimientos.

1.9.1. Actividades

Las actividades que se realizaron en esta fase de exploración fueron las siguientes:

Características de ERMT 1.0: Esta primera actividad consistió en realizar un

análisis general a esta herramienta, para lo cual se identificaron las características y

funcionalidades que ofrece este software.

Investigación de herramientas: Esta actividad consistió en investigar e identificar la

mayor cantidad de herramientas para la administración de requerimientos que existen

en el mercado, ya sean comerciales o académicas.

Página 18


Características de las herramientas: Esta actividad consistió en conocer y entender

las características y funcionalidades que ofrecen estas herramientas, luego de la

investigación previa.

Comparación de herramientas: Esta actividad comprendió en comparar las

funcionalidades de ERMT frente a las herramientas existentes en el mercado.

Estándares de calidad: Esta actividad consistió en investigar y analizar los

diferentes estándares de calidad de requerimientos, para lo cual se pudo determinar

que funcionalidades se le pudieron agregar a la herramienta.

Nuevas funcionalidades: La última tarea de esta primera fase consistió en definir

qué funcionalidades le hacían falta a ERMT para complementarla, además que

estuvieran dentro del alcance y sirvieran para un entorno educativo.

1.10. Fase de desarrollo ágil

Esta segunda fase metodológica consistió en la ejecución de la metodología SCRUM, que

permitió ejecutar los restantes objetivos específicos, donde se modificó la arquitectura

existente de ERMT 1.0, y esta a su vez soporta las nuevas funcionalidades que se

implementaron, realizando sus respectivas pruebas de usabilidad del producto para su

correspondiente validación.

Esta metodología permitió realizar una gestión en el desarrollo del software, además se basó

en un proceso iterativo e incremental, acoplándose de manera correcta a las actividades

propuestas para esta fase, ya que una actividad posterior depende de las actividades

anteriores. Cada actividad fue revisada por el director de trabajo de grado con el fin de

mantener la consistencia entre cada iteración.

1.10.1. Actividades

Las actividades que se realizaron en esta fase de desarrollo ágil fueron las siguientes:

Página 19



Elaboración documento SPMP: Esta actividad tenía como propósito de elaborar el

documento que permitía gestionar, definir el cronograma de trabajo, las actividades y

procesos que se llevan a lo largo de todo el proyecto.

Elaboración casos de uso: Esta actividad consistió en la ejecución de las tareas

relacionadas con la elaboración de los nuevos casos de uso, desde lecturas previas del

tema, hasta la elaboración de los correspondientes casos de uso y documentación.

Elaboración diccionario de datos.

Documentación de requerimientos: Esta actividad consistió en la obtención,

definición y documentación de los requerimientos funcionales y no funcionales del

prototipo.

Elaboración documento SRS: Esta actividad tiene como propósito la definición,

análisis y especificación de los nuevos requerimientos funcionales y no funcionales

de ERMT 2.0

Elaboración documento externo SDD: Esta actividad consistía de realizar el

documento de diseño de software, la arquitectura de la aplicación con base a los

requerimientos previamente establecidos, además de la descripción detallada del

diseño del software.

Desarrollo e implementación de las nuevas funcionalidades.

Realizar las pruebas de usabilidad.

Elaboración manual de usuario: Esta actividad tenía como propósito realizar el

documento que se encarga de especificar, y cómo se va a utilizar la aplicación,

Página 20


permitiendo a los diferentes usuarios tener una interacción adecuada con la

herramienta.

Elaboración memoria de trabajo de grado: Esta actividad tenía como propósito

elaborar el documento que contiene el marco teórico, objetivos generales, objetivos

específicos, resultados y conclusiones del trabajo de grado desarrollado a lo largo del

semestre.

Elaboración de página web de trabajo de grado.

1.11. Método que se propuso para satisfacer cada fase metodológica

En este capítulo se explica y se detalla los métodos que se usaron para cumplir las fases

metodológicas propuestas en el trabajo de grado.

1.11.1. Fase de exploraciónLos métodos que se usaron en esta fase fueron los siguientes:

Obtención y localización de bibliografía: Esta actividad consistió en la búsqueda

bibliográfica sobre ingeniería de requerimientos, herramientas para la administración

de requerimientos y estándares de calidad, con lo cual se pudo establecer la base

teórica.

Análisis y organización de la bibliografía: Luego de la búsqueda bibliográfica, se

analizó y organizo mediante resúmenes, temas y orden cronológico, para mejorar la

obtención de información.

1.11.2. Fase de desarrollo ágilLos métodos que se usaron en esta fase fueron los siguientes:

Página 21



Ejecución de la iteración (Sprint): Cada vez que se finalizó una actividad

propuesta, fue necesario que se llevara una reunión con el director del trabajo de

grado, para poder evaluar cada una de estas actividades ya realizadas, para luego

realizar las correcciones necesarias. Por lo general estas reuniones se realizaban cada

15 días.

Demostración de requerimientos completados (Sprint Review): Esta actividad

que ofrece SCRUM, permitía realizar una entrega informal de los requerimientos ya

terminados en una actividad al cliente, que en este contexto es el director del trabajo

de grado, el cual le permitía conocer si realmente se están entendido lo que el cliente

quiere, además de realizar mejoras en esta entrega si es necesario y si cumple con sus

expectativas.

Lista de tareas de la iteración (Sprint Backlog): Esta lista de tareas permitía

visualizar el estado actual de las actividades programadas en cada iteración, la cual

permitía realizar una trazabilidad a cada una de estas, pata conocer si se han tenido

problemas, retrasos, avance del proyecto y el esfuerzo en horas para la realización de

cada una de las tareas.

Página 22


II - MARCO TEÓRICO

2. Marco Conceptual

2.1. ¿Qué es la ingeniería de requerimientos?El marco conceptual de este trabajo de grado, se fundamenta principalmente en los procesos

que comprende la ingeniería de requerimientos, para lo cual es importante precisar esta

definición. La ingeniería de requerimientos es una rama de la ingeniería de sistemas, la cual

se encarga de obtener, desarrollar, trazar, analizar, clasificar, comunicar y gestionar los

requerimientos que definen el sistema en los niveles sucesivos de abstracción [12].

Esta definición donde se enumeran varias actividades, las cuales se consideran importantes

dentro de la ingeniería de requerimientos, en la actualidad hay algunas de estas actividades

que son consideradas como parte de otra disciplina, por ejemplo el de pruebas o verificación

del sistema, estas deben ser cualidades necesarias que deben tener los requerimientos para

permitir que sean verificados posteriormente, inclusive la propia actividad de verificación es

otra disciplina [12]. Hay otros autores que se refieren a todo este conjunto de actividades

como solo gestión de requerimientos, o también como un subconjunto del amplio dominio del

análisis de negocios [5], en este trabajo de grado se tomará la primera definición para el

desarrollo del marco conceptual.

Es importante dividir los procesos de la ingeniería de requerimientos en dos subconjuntos, el

primer subconjunto se le denomina “Desarrollo de requerimientos” y el segundo subconjunto

se le denomina como “Administración de requerimientos”, ya que estas actividades se

llevaran a cabo dependiendo del ciclo de vida en diferentes momentos del proyecto y en

diversos grados de profundidad o detalle [5]. La figura 1 muestra en detalle cómo se

descomponen los procesos de la ingeniería de requerimientos, la cual fue tomada de (K. E.

Wiegers and J. Beatty, Software requirements):

Página 23



Figura 1 Subdisciplinas de la ingeniería de requerimientos

En los siguientes capítulos, se explicará en detalle cada una de estas subdisciplinas que

componen la ingeniería de requerimientos con sus correspondientes actividades.

2.2. ¿Qué es el desarrollo de requerimientos?El objetivo del desarrollo de requerimientos es de identificar, acordar y registrar un conjunto

de requerimientos funcionales y características del producto que van a permitir alcanzar los

objetivos del proyecto previamente establecidos [15].

El desarrollo de requerimientos como se muestra en la figura 1, se subdivide en: obtención,

análisis, especificación y validación. Estas subdisciplinas abarcan todas las actividades

involucradas con la exploración, evaluación, documentación, y la confirmación de los

requerimientos de un producto. A continuación se explican en detalle [5].

2.2.1. ObtenciónLa primera subdisciplina del desarrollo de requerimientos, implica las actividades que son

necesarias para entender y obtener las necesidades de los clientes [11], para estas actividades

se utilizan diferentes herramientas como: entrevistas, talleres, análisis de documentos,

creación de prototipos, entre otras [5]. Sus actividades principales son:

Página 24


Identificar las diferentes clases de usuario y stakeholders que puedan estar

involucrados en el producto.

Comprender las tareas del usuario, las metas y objetivos de negocio en las que estas

tareas se alinean.

Aprender sobre el entorno en el que se utilizará el nuevo producto.

Trabajar con personas que representan a cada clase de usuario para comprender sus

necesidades funcionales y sobre sus expectativas de calidad.

2.2.2. AnálisisLa segunda subdisciplina del desarrollo de requerimientos es el análisis, que incluye la

creación de múltiples puntos de vista de los requerimientos, como prototipos, modelos

gráficos de análisis y pruebas. Otros aspectos importantes en el análisis de requerimientos

incluyen prioridades de negociación, búsqueda de requerimientos faltantes, y la evaluación de

la viabilidad técnica, el riesgo y los modos de fallo [15]. Este análisis permite una

comprensión más detallada y precisa de los requerimientos que forman parte del proyecto.

Sus actividades principales son:

El análisis de la información recibida de los usuarios para poder distinguir sus

objetivos de trabajo, los requerimientos funcionales, las expectativas de calidad,

reglas de negocio, entre otros.

Descomponer los requerimientos de alto nivel en un nivel apropiado de detalle.

La comprensión de la importancia relativa de los atributos de calidad.

Negociar las prioridades de ejecución.

La asignación de requerimientos a los componentes de software, definidos en la

arquitectura del sistema.

Identificar las carencias en los requerimientos o requerimientos innecesarios en

relación con el alcance definido en el proyecto.

Página 25



2.2.3. EspecificaciónEsta tercera subdisciplina del desarrollo de requerimientos implica el registro de los distintos

tipos de información de los requerimientos en formas que faciliten la comunicación entre los

interesados en el proyecto [5]. Para ello la información de los requerimientos se debe

representar y almacenar de una manera persistente y organizada, como en una herramienta de

gestión de requerimientos. Su actividad principal es:

Entender y recoger las necesidades de los clientes en requerimientos escritos y

esquemas adecuados para la comprensión, revisión y el uso por parte de sus

audiencias previstas.

2.2.4. Validación

Esta última subdisciplina del desarrollo de requerimientos, asegura que los requerimientos

obtenidos son correctos, van a satisfacer las necesidades del cliente, y tienen todas las carac-

terísticas de los requerimientos de alta calidad [15], además esta validación confirma que ese

conjunto de requerimientos es el correcto y posteriormente permita a los desarrolladores crear

una solución que satisfaga los objetivos del negocio [5]. Sus actividades principales son:

Repasar los requerimientos ya documentados para corregir algún problema antes de

que el grupo de desarrolle los acepte.

El desarrollo de las pruebas y criterios de aceptación, permite confirmar si el produc-

to en función cumple con los requerimientos para satisfacer las necesidades de los

clientes y lograr los objetivos de negocio.

La iteración es la clave del éxito en el desarrollo de los requerimientos [5], ya que al ejecutar

estas cuatro subdisciplinas, permiten refinar los requerimientos de alto nivel, a una mayor

precisión y detalle, con el propósito de minimizar la incertidumbre del proyecto de software.

2.3. ¿Qué es la administración de requerimientos?El propósito central de la administración de requerimientos, es la gestión de los cambios en

un conjunto de requerimientos previamente acordados, que se han propuesto para una versión

específica del producto. La administración de requerimientos incluye también el seguimiento

Página 26


individual del estado de los requerimientos tanto para sus orígenes, cómo hacia adelante en

elementos de diseño, módulos de código y pruebas de seguimiento [11]. Las actividades de

administración de requerimientos son las siguientes [5]:

Definición de una línea base de requerimientos, que es una instantánea en el tiempo

que representa un conjunto acordado, revisado y aprobado de los requerimientos

funcionales y no funcionales y sirve como base para un mayor desarrollo.

Evaluación del impacto que tienen los cambios propuestos a los requerimientos y la

incorporación de los cambios aprobados en el proyecto de una manera controlada.

Mantener los planes del proyecto actual a medida que los requerimientos

evolucionan.

La negociación de nuevos compromisos sobre la base de la estimación del impacto de

los cambios en los requerimientos.

Definición de las relaciones y dependencias que existen entre los requerimientos.

Seguimiento individual a cada requerimiento con sus correspondientes diseños,

código fuente y pruebas.

Seguimiento del estado de los requerimientos y las actividades de cambios en todo el

proyecto.

El objetivo de la administración de requerimientos es de prever y adaptarse a los cambios

reales que siempre se puede esperar con el fin de minimizar su impacto perjudicial en el

proyecto [5].

La administración de requerimientos es necesario para garantizar un alto nivel de calidad y el

valor de los requerimientos existentes en un proyecto, es tal su importancia que se han

establecido una serie de buenas prácticas que van a permitir afrontar estas actividades ya

mencionadas [12].

Si el proyecto está siguiendo un ciclo de vida de desarrollo secuencial, o uno de los diversos

ciclos de vida ágiles, o cualquier otro enfoque, la gestión de requerimientos es una actividad

esencial. La administración de requerimientos contribuye a garantizar que el esfuerzo que se

invierte en el desarrollo de los requerimientos no se malgaste. La administración de

requerimientos eficaz reduce la diferencia de expectativas al mantener todas las partes

Página 27



interesadas del proyecto informados sobre el estado actual de los requerimientos a lo largo

del proceso de desarrollo. Permite conocer hacia dónde va el proyecto [15].

2.4. Buenas prácticas para la administración de requerimientosLa administración de requerimientos abarca prácticas que permiten al equipo de trabajo

establecer cómo se van a manejar los requerimientos luego de definirlos. Estas prácticas

incluyen el control de versiones y la línea base, control de cambios, el estado de los

requerimientos y el rastreo de requerimientos a otros elementos del sistema [6]. La

administración de requerimientos se llevará a cabo a lo largo de la duración del proyecto a un

bajo nivel de intensidad [5]. A continuación se muestran y detallan las buenas prácticas:

Establecer un proceso de control de cambios: El proceso de cambios debe definir

cómo se proponen los cambios de requerimientos, para luego analizarlos y

resolverlos. Administrar todos los cambios propuestos a través de este proceso [5].

Realizar un análisis de los efectos del cambio: Evaluar cada cambio de los

requisitos propuestos para evaluar el efecto que tendrá en el proyecto. Utilizar una

matriz de trazabilidad para identificar los demás requerimientos, elementos de

diseño, código fuente y las pruebas que podría necesitar modificar. Identificar las

tareas necesarias para implementar el cambio y estimar el esfuerzo necesario para

llevar a cabo estas tareas [5].

Establecer una línea base y control de versiones para el conjunto de

requerimientos: Una línea base define un conjunto de requerimientos acordados

normalmente para un lanzamiento o iteración especifica. Después de definir una línea

base de requerimientos, los cambios deben hacerse solo a través del proceso de

control de cambios del proyecto. Dar a cada versión de la especificación de

requerimientos un identificador único para evitar confusión entre los proyectos y

líneas base y entre las versiones anteriores y actuales [5].

Mantener un historial de cambios: Conservar un historial de los cambios realizados

a cada requerimiento individual. A veces es necesario volver a una versión anterior

Página 28


de un requerimiento o quiere saber cómo el requerimiento llegó a estar en su forma

actual. Es importante anotar las fechas las fechas en que se modificaron los

requerimientos, los cambios que se hicieron, quien realizó el cambio, y por qué [5].

Seguimiento del estado de los requerimientos: Crear un repositorio con un registro

para cada requerimiento de cualquier tipo que afecte a la ejecución. Guardar los

atributos clave sobre cada requerimiento, incluyendo su estado (propuesto, aprobado,

implementado o verificado), para que se pueda supervisar el número de

requerimientos de cada categoría de estado en cualquier momento. El seguimiento

del estado de cada requerimiento proporciona información sobre el estado general del

proyecto debido a que se mueve a través del desarrollo y las pruebas del sistema [5].

Seguimiento de los problemas en los requerimientos: Supervisar el estado de los

problemas en los requerimientos para determinar el estado general de los

requerimientos [5].

Mantener una matriz de trazabilidad de requerimientos: Una matriz de

trazabilidad de requerimientos es útil para confirmar que todos los requerimientos se

aplican y se verifican. También es útil durante el mantenimiento, cuando un

requerimiento tiene que ser modificado. La matriz de trazabilidad de requerimientos

también puede conectarse a requerimientos funcionales con requerimientos de nivel

superior a partir de los cuales se derivaron y para otros requerimientos relacionados

[5].

Usar una herramienta de gestión de requerimientos: Las herramientas de gestión

de requerimientos comerciales permiten almacenar diferentes tipos de requerimientos

en una base de datos. Tales herramientas ayudan a implementar y automatizar

muchas de las prácticas de la gestión de requerimientos [5].

Página 29



2.5. Prácticas de gestión de requerimientos

El control de versiones de los requerimientos individuales y el conjunto de requerimientos es

una de las actividades básicas de la gestión de requerimientos [5]. La gestión de

requerimientos incluye todas las actividades que mantienen la integridad, exactitud y

actualización de los acuerdos en los requerimientos a lo largo del proyecto. Las actividades

básicas de la administración de requerimientos están en cuatro categorías principales [5]:

Control de versiones

Definición de un esquema de identificación de la versión.

Seguimiento individual a las versiones de requerimientos.

Seguimiento al conjunto de versiones de requerimientos.

Control de cambios

Proponer cambios.

Análisis del impacto.

Toma de decisiones.

Actualización de los requerimientos individuales.

Actualización del conjunto de requerimientos.

Actualización de los planes.

Medición de la volatilidad de los requerimientos.

Seguimiento del estado de los requerimientos

Definir posibles estados de los requerimientos.

Llevar un registro de cada requerimiento.

El seguimiento de la distribución del estado de todos los requerimientos.

Página 30


Trazabilidad de requerimientos

Definir enlaces a otros requerimientos.

Definir enlaces a otros elementos.

2.5.1. Control versión de requerimientosEl control de versiones comienza cuando se elabora un requerimiento o un documento para

conservar un historial de los cambios realizados. Cada versión de los requerimientos debe ser

identificada. Los cambios deben estar claramente documentados y comunicados a todos los

afectados. Asegurar de que el identificador de versión cambia cada vez que se hace una

actualización. Cada versión de un documento de requerimientos o cada requerimiento en una

herramienta debe incluir un historial de revisiones que identifica los cambios realizados, la

fecha de cada cambio, la persona que hizo el cambio y el motivo de cada cambio [5].

2.5.2. Atributos de requerimientosEstos atributos establecen un contexto y los antecedentes de cada requerimiento. Estos

valores de los atributos se pueden almacenar en un documento, hoja de cálculo o base de

datos. Los atributos de los requerimientos son los siguientes [5]:

Fecha en la que se creó el requerimiento

Número de la versión actual del requerimiento

Autor del quien escribió el requerimiento

Prioridad

Estado

Origen o fuente del requerimiento

Justificación del requerimiento

Número de publicación o iteración a la que se le asigna el requerimiento

Método de validación para su uso o criterios de aceptación

Página 31



2.5.3. Seguimiento del estado de los requerimientosEl seguimiento de los estados de requerimientos es muy importante dentro de un proyecto, ya

que permite conocer la evolución y el estado actual del requerimiento. Para ello es importante

abarcar todos los requerimientos dentro de alguna de estas categorías [5] [7]:

Propuesto: El requerimiento ha sido solicitado por una fuente autorizada.

Redactado: La versión inicial del requerimiento ha sido escrita.

Aprobado: El requerimiento ha sido analizado, su impacto en el proyecto estimado y

se ha asignado a la línea base para una versión específica. Las principales partes

interesadas han acordado incorporar el requerimiento y el grupo de desarrollo de

software se ha comprometido a implementarlo.

Implementado: El código que implementa el requerimiento ha sido diseñado y

escrito. El requerimiento se ha localizado al diseño pertinente y elementos de código.

El software que implementa el requerimiento ya está listo para ser probado, evaluado

u otra verificación que sea necesaria.

Verificado: El requerimiento ha cumplido sus criterios de aceptación, lo que

significa el correcto funcionamiento del requerimiento implementado y ha sido

confirmado. El requerimiento se ha remontado a las pruebas pertinentes. Actualmente

se considera completo.

Diferido: Un requerimiento aprobado está ahora previsto para la ejecución en una

versión posterior.

Eliminado: Un requerimiento ha sido retirado de la línea base. Es importante dar una

explicación de por qué y quien tomó la decisión de eliminarlo.

Rechazado: Se propuso el requerimiento, pero nunca fue aprobado y no está previsto

para su implementación en cualquier próximo lanzamiento. Incluir una explicación

de por qué y quien tomó la decisión de rechazarlo.

2.5.4. Seguimiento de los problemas en los requerimientos

Algunos de los beneficios del uso de una herramienta de seguimiento de problemas son:

Página 32


Cuestiones de múltiples opiniones de requerimientos se recogen de modo que ningún

tema se pierda nunca.

El gerente del proyecto puede ver fácilmente el estado actual de todos los problemas.

El historial de la discusión en torno a un tema puede ser retenido.

El equipo puede comenzar el desarrollo temprano con un conjunto de problemas

abiertos en lugar de tener que esperar hasta que el SRS esté completo.

La categorización de los problemas puede determinar qué secciones de requerimientos aún

necesitan trabajo. Casi todos los defectos registrados tempranamente en un proyecto tienen

que ver con las cuestiones de requerimientos, como pedir aclaraciones sobre un

requerimiento, las decisiones de alcance, las preguntas sobre la viabilidad del desarrollo y las

tareas pendientes en los propios requerimientos [7].

Los problemas más comunes con los requerimientos son los siguientes [5]:

Preguntas sobre requerimientos: Hay algo que no se entiende o decidir acerca de

un requerimiento.

Falla de un requerimiento: Los desarrolladores descubren un requerimiento perdido

durante el diseño o implementación.

Requerimiento incorrecto: Un requerimiento que estaba mal. Debe ser corregido o

eliminado.

Pregunta de implementación: Como lo desarrolladores implementan los

requerimientos, tienen preguntas acerca de cómo debería funcionar algo o sobre

alternativas de diseño.

Requerimientos duplicados: Se descubren dos o más requerimientos equivalentes.

Eliminar todos menos uno de ellos.

Requerimientos innecesarios: Un requerimiento simplemente no se necesita más.

2.6. Herramientas de administración de requerimientosComo se mostraba en los capítulos anteriores, una buena práctica para la administración de

requerimientos en un proyecto, es la de utilizar una herramienta que ayude en este proceso

Página 33



critico ya que si se utiliza un enfoque basado en la elaboración de documentos por cada una

de las actividades ya mencionadas tanto para el desarrollo, como para la administración de

requerimientos se tienen muchas numerosas limitaciones, entre ellas las siguientes [5] [20]:

Es difícil mantener los documentos actualizados y sincronizados.

Comunicar los cambios a todos los miembros del equipo afectados es un proceso

manual.

No es fácil de almacenar información complementaria acerca de los atributos de cada

requerimiento.

Es difícil definir los vínculos entre los requerimientos y otros elementos del sistema.

El seguimiento de la situación de los requerimientos individuales y todo el conjunto

de requerimientos es engorroso.

La identificación de requerimientos desaparecidos, duplicados e innecesarios es

difícil.

Las herramientas de administración de requerimientos ayudan a manejar los cambios de los

requerimientos, el estado y el seguimiento a los requerimientos a otras prestaciones del

proyecto [20].

El proyecto debe definir uno o varias líneas base de requerimientos, cada uno identificado en

un conjunto especifico de requerimientos destinados a un lanzamiento o iteración particular.

Las herramientas también mantienen un historial de los cambios hechos a cada requerimiento.

Se puede grabar la razón detrás de cada decisión de cambio y volver a una versión anterior de

un requerimiento en caso de necesidad [5]. Algunas herramientas contienen un sistema de

cambio propuesto que vincula las solicitudes de cambio directamente a los requerimientos

afectados.

A continuación se muestran algunas características que debe tener una herramienta para la

administración de requerimientos [5]:

Almacén de atributos de requerimientos

Página 34


Se debe guardar varios atributos descriptivos para cada requerimiento, todos los que trabajan

en el proyecto deben ser capaces de ver los atributos, y se les permitirá actualizar los valores

de los atributos. Las herramientas deben generar varios atributos definidos por el sistema,

como la fecha en que un requerimiento fue creado y número de versión actual y que permitan

definir atributos adicionales de distintos tipos de datos.

Facilitar el análisis del impacto

Las herramientas permiten el rastreo de requerimientos, ya que permite definir los vínculos

entre los diferentes tipos de requerimientos, entre los requerimientos de los distintos

subsistemas y entre las necesidades individuales y los componentes con el sistema (diseños,

módulos de código, pruebas y documentación del usuario). Estos vínculos ayudan a analizar

el impacto que tiene un cambio propuesto en un requerimiento especifico tendrá en otros

elementos del sistema. El seguimiento de cada requerimiento funcional debe establecer su

origen o requerimiento padre para establecer de donde viene.

Identificar los requerimientos faltantes y extraños

La funcionalidad de seguimiento ayuda a los interesados a identificar los requerimientos

faltantes, como los requerimientos de los usuarios que no tienen los requerimientos

funcionales. Del mismo modo, pueden revelar requerimientos que no se remontan a un origen

razonable, planteando la cuestión de si esos requerimientos son necesarios.

Seguimiento del estado de los requerimientos

Recopilación de requerimientos en una base de datos permite saber cuántos requerimientos se

han especificado en el producto. El seguimiento del estado de cada requerimiento durante el

desarrollo apoya el seguimiento del estado general del proyecto.

Reutilización de requerimientos

El almacenamiento de los requerimientos en una base de datos facilita la reutilización de ellos

en varios proyectos o sub proyectos. Los requerimientos que se ajustan de forma lógica en

varias partes de la descripción del producto se pueden almacenar una vez y se hace referencia

siempre que sea necesario, para evitar la duplicación de requerimientos.

Página 35



Seguimiento de los problemas en los requerimientos

Algunas herramientas tienen la funcionalidad para el seguimiento de los problemas en los

requerimientos y una vinculación de cada tema a sus requerimientos relacionados. Como se

resuelven los problemas, es fácil determinar si se deben actualizar los requerimientos.

También es importante encontrar rápidamente una historia del problema y su solución. El

seguimiento de los problemas en una herramienta permite informar automáticamente sobre el

estado de los problemas [5].

2.7. Gestión de riesgosLa gestión de riesgos, aunque no está considerada como una práctica dentro del proceso de

administración de requerimientos, es importante asociarla y trabajar en paralelo al proceso del

seguimiento de los problemas en los requerimientos y el control de los cambios ya que esta

práctica permite tratar un problema antes de que se convierta en una crisis, ya que esto

aumenta las probabilidades de éxito del proyecto y reduce las consecuencias financieras o de

otra índole de los riesgos que no se pueden evitar [3]. También consiste en la aplicación de

herramientas y procedimientos para contener los riesgos del proyecto dentro de los límites

aceptables. Proporciona un enfoque estándar para identificar los factores de riesgo y de

documentos, evaluar su gravedad potencial, y proponer estrategias para la mitigación de los

mismos.

La preparación para la gestión de riesgos en los requerimientos implica dos pasos principales

[17] [18]:

Identificar los tipos de riesgos: La idea de gestión de los riesgos en los requerimientos no es

nueva, pero los modelos tradicionales se han convertido en demasiados simplistas.

Investigaciones recientes sugieren que los proyectos de TI de hoy en día, se enfrentan a tres

tipos distintos de riesgos en los requerimientos [17]:

Identidad: Los riesgos de identidad son aquellos que a menudo conducen a considerables

brechas de comunicación entre los desarrolladores y los usuarios, además la distancia física,

conceptual y cultural que hay entre los implicados. Un alto riesgo en esta área se produce

cuando no se sabe o no se pueden identificar requerimientos clave. [17]

Página 36


Volatilidad: Durante la mayoría de proyectos de TI, los requerimientos cambian como: las

partes interesadas a aprender más acerca de la solución o condiciones internas o externas para

el cambio de uso del sistema de TI. Riesgos de volatilidad son expresiones que indican la

estabilidad del requerimiento. Los riesgos altos indican que los requerimientos pueden

cambiar fácilmente. [17]

Complejidad: Los riesgos de complejidad, reflejan cómo se conceptualizan y se estructuran

los requerimientos, los riesgos altos indican que es difícil de entender, especificar y

comunicar los requerimientos. [17]

Técnicas de mitigación de los riesgos: La segunda etapa de preparación es la de organizar

una caja de herramientas adecuadas para la resolución de los riesgos. Algunas técnicas de

mitigación ya se definieron para el proyecto, pero hay que evaluar qué tan bien se aplican a

los diferentes tipos de riesgo. Por lo cual se han categorizado técnicas disponibles de acuerdo

al propósito del proyecto. [17]

Descubrimiento: Estas técnicas centradas en el cliente ayudan a identificar o predecir las

necesidades del cliente, haciendo hincapié en la identificación y la comprensión inicial de las

necesidades, incluyendo aquellas que son esenciales a los usuarios. [17]

Priorización: Esta técnica permite establecer que requerimientos tienen un mayor riesgo de

no poder ser desarrollados o cuales son más críticos para satisfacer las necesidades de los

usuarios. [17]

Experimentación: Esta técnica permite en ayudar a evaluar y estabilizar los requerimientos a

través de la experimentación y la retroalimentación del usuario final. La idea básica es

construir un prototipo, registrar los comentarios, e iterativamente mejorar la solución hasta

que se ha alcanzado un nivel satisfactorio de aceptación del usuario. [17]

Página 37



Especificación: Esta técnica se basa en la abstracción de los requerimientos mediante texto o

representación gráfica (modelo entidad – relación, diagrama casos de uso, entre otros).

Página 38


III – DESARROLLO DEL TRABAJO

En este capítulo se explica cómo fue el desarrollo del trabajo de grado, el cual se realizó

mediante dos grandes fases metodológicas como se explicó anteriormente, la primera fase

consistió en una exploración de las funcionalidades que proveen las herramientas para la

administración de requerimientos y la segunda fase en el desarrollo de la aplicación ERMT

2.0, las cuales se explicaran en detalle a los largo de este capítulo.

3.1. Fase de exploración

Esta fase de exploración, consistió en realizar un estudio sobre las funcionalidades de ERMT

1.0, luego el estudio de algunas herramientas de administración de requerimientos existentes

en el mercado y por ultimo lecturas de material bibliográfico acerca de la ingeniería de reque-

rimientos.

3.1.1. Investigación herramienta Easy Requirement Management Tool

La primera parte de la fase de exploración, consistió en comprender las características gene -

rales de ERMT 1.0, para lo cual se realizaron las siguientes actividades:

1. Estudio de los casos de uso.

2. Lectura del manual de usuario.

3. Ejecutar la aplicación mediante un proyecto de prueba.

4. Entender y comprender las funcionalidades generales de ERMT.

5. Entender y comprender la arquitectura de ERMT.

6. Conocer las limitaciones y restricciones de ERMT (lenguaje de programación, persis-

tencia de los datos, restricciones de diseño, entre otros).

ERMT 1.0: “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” [1], y sus características principales son las siguientes:

Almacenamiento y Consulta de requerimientos.

Generación de reportes en Excel.

Página 39



Generación de grafos de implementación.

Generación de reportes del estado de cada requerimiento y del estado del proyecto en

general.

Importación de archivos csv.

Priorización de requerimientos.

Localización de archivos mediante la trazabilidad.

Relación entre requerimientos.

Definición de tipos de requerimientos.

Listas de V&V.

Luego de llevar a cabo estas actividades ya mencionadas, el siguiente paso consistió en inves-

tigar cuales herramientas ya existen en el mercado, con lo cual se pudo establecer de manera

precisa que funcionalidades se le podían agregar.

3.1.2. Investigación de herramientas para la administración de requerimientos

La segunda parte de la fase de exploración consistió en buscar en el mercado que herramien-

tas para la administración de requerimientos existen en la actualidad y con base a estas, cono-

cer sus características principales. A continuación se nombran las herramientas consultadas

con sus correspondientes funcionalidades:

CaliberRm: Es un software empresarial de administración de requisitos, que garantiza que

las aplicaciones satisfagan las necesidades del usuario final [21], y sus características

principales son:

Identificación de requerimientos.

Definición de atributos de requerimientos.

Control de cambios.

Trazabilidad.

Visualización de requerimientos.

Asignación de requerimientos

Documentación de requerimientos [22].

Página 40


Enterprise Architect: Es una herramienta que se utiliza en el desarrollo de software

mediante el diseño UML, que permite la administración de requerimientos, diseño, pruebas y

mantenimiento del software [23], y sus características principales son:

Definición de requerimientos.

Estado de los requerimientos.

Trazabilidad de requerimientos.

Líneas base de requerimientos.

RequisitePro: Es una herramienta de administración de requerimientos que puede ser

utilizada para administrar los requerimientos de los proyectos, el cual promueve la

comunicación y colaboración entre los miembros del equipo de trabajo [24], y sus

características principales son:

Priorización de requerimientos.

Generación de reportes.

Definición de requerimientos.

Cambios en los requerimientos.

Trazabilidad.

Definición de casos de uso y clases.

Historial de cambios.

TopTeam Analyst: Es una herramienta cliente-servidor que pertenece a la suite de

herramientas de apoyo al ciclo de vida de los proyectos, la cual se encarga de la

administración de requerimientos [25], y sus características principales son:

Trazabilidad.

Control de cambios.

Generación de reportes.

Definición de casos de uso.

Página 41



Luego de realizar un estudio de estas cuatro herramientas para la administración de

requerimientos, se pudo establecer que funcionalidades le hacían falta a ERMT 1.0 y cuáles

de estas funcionalidades son las más comunes dentro de esas herramientas.

3.1.3. Obtención y recolección bibliográfica

La última parte de la fase de exploración, consistió en investigar las principales actividades,

procesos y buenas prácticas para la administración de requerimientos, la cual permitió obte-

ner que características debía tener una herramienta para la administración de requerimientos.

Luego de realizar estas tres actividades, se cruzó esta información y se establecieron las nue-

vas funcionalidades de ERMT, las cuales se muestran a continuación:

Línea base de requerimientos: Esta funcionalidad permite crear, consultar y

eliminar un conjunto de requerimientos acordados normalmente para un lanzamiento

o iteración especifica.

Problemas en los requerimientos: Esta funcionalidad permite asociar, editar,

eliminar y generar reportes del estado de los problemas en los requerimientos del

proyecto, para determinar el estado general de los requerimientos.

Proceso control de cambios: Esta funcionalidad permite gestionar las versiones de

un requerimiento, además tiene un historial de revisiones que identifica los cambios

realizados, la fecha de cada cambio, la persona que hizo el cambio y el motivo de

cada cambio.

Gestión de riesgos: Esta funcionalidad permite identificar el riesgo de cada

requerimiento del proyecto y determinar su nivel de prioridad (alta, baja), mediante

estos tres tipos de riesgos:

o Identidad: El riesgo alto en esta categoría, indica que no se sabe o no se

puede identificar los requerimientos clave.

o Volatilidad: El riesgo alto en esta categoría, indica que los requerimientos

pueden cambiar fácilmente.

o Complejidad: El riesgo alto en esta categoría, indica que los requerimientos

son difíciles de entender y especificar.

Página 42


Posteriormente la herramienta, mediante las combinaciones de estos tres tipos de

riesgos, le indica al usuario el nivel de prioridad (alta, media, baja) que debe la

técnica de mitigación recomendable para mitigar el riesgo:

o Descubrimiento: Esta técnica ayuda a identificar o predecir los

requerimientos del cliente, mediante la comprensión inicial de sus

necesidades.

o Priorización: Esta técnica permite establecer que requerimientos tiene

mayor riesgo de no poder ser desarrollados.

o Experimentación: Esta técnica permite al usuario a evaluar y estabilizar los

requerimientos a través de la experimentación y la retroalimentación con el

usuario final.

o Especificación: Esta técnica se basa en la abstracción de los requerimientos

mediante texto o representación gráfica.

Matriz de trazabilidad: Esta funcionalidad permite generar una matriz de

trazabilidad, la cual contiene el origen de los requerimientos del proyecto, mediante

la relación con los casos de uso.

3.2. Fase de desarrollo

Luego de que se definieran las nuevas funcionalidades, esta fase consistió en el desarrollo de

estas, para lo cual, el primer paso consistió en definir los casos de uso, luego se definieron los

requerimientos funcionales y no funcionales, posteriormente se agregaron nuevos componen-

tes a la arquitectura y por ultimo las pruebas que se le hicieron al prototipo.

3.2.1. Casos de uso

Mediante la elaboración, obtención y documentación de los casos de uso, se pudo establecer

los siguientes aspectos relevantes:

La lista de casos de uso.

Los usuarios que van a interactuar directamente con la herramienta.

Los privilegios que tienen los usuarios.

Página 43



Cuales casos de uso que existían en ERMT 1.0, podrían ser reutilizados.

A continuación se muestran los casos de uso para ERMT 2.0:

ID CASO DE USO CASO DE USO

CU 001 Crear línea base de requerimientos

CU 002 Crear control de versiones a los requerimientos

CU 003 Crear control de cambios

CU 004 Asignar problema a un requerimiento

CU 005 Editar problema a un requerimiento

CU 006 Eliminar problema a un requerimiento

CU 007 Generar reporte de los problemas en los requerimientos

CU 008 Crear matriz de trazabilidad

CU 009 Identificar tipo de riesgo

CU 010 Generar técnica de mitigación

Figure 2 Lista casos de uso

En la figura 3 se muestra el diagrama de casos de uso para ERMT 2.0:

Página 44


Figura 3 Diagrama casos de uso

Para ver el análisis de actores, documentación de casos de uso ver Anexo 2. Documento Ca-

sos de Uso. Para ver el diagrama Anexo 9. Diagrama casos de uso.

3.2.2. Requerimientos funcionales y no funcionales

Mediante la elaboración, obtención y documentación de los requerimientos funcionales y no

funcionales se pudo establecer lo que realmente el sistema debía hacer, para ello se tomó en

cuenta los casos de uso que previamente fueron definidos. Para ver en detalle la especifica-

ción de los requerimientos ver Anexo 3. Software Requirements Specification.

A continuación se muestran los requerimientos funcionales de ERMT 2.0:

ID REQUERIMIENTO REQUERIMIENTO

REQ 001 El sistema debe permitir crear una línea base de requerimientos.

REQ 002 El sistema debe permitir consultar las líneas base de requerimientos.

Página 45



REQ 003 El sistema debe permitir eliminar una línea base de requerimientos.

REQ 004 El sistema debe permitir asociar un problema a un requerimiento.

REQ 005 El sistema debe permitir editar un problema a un requerimiento.

REQ 006 El sistema debe permitir eliminar un problema a un requerimiento.

REQ 007 El sistema debe permitir generar un reporte de problemas en los requerimientos.

REQ 008 El sistema debe permitir modificar un requerimiento.

REQ 009 El sistema debe permitir consultar el historial de cambios en los requerimientos.

REQ 010 El sistema debe permitir generar una matriz de trazabilidad de casos de usos relacionados.

REQ 011 El sistema debe permitir asociar un riesgo a un requerimiento.

REQ 012 El sistema debe permitir editar un riesgo a un requerimiento.

REQ 013 El sistema debe permitir generar una técnica de mitigación.

REQ 014 El sistema debe permitir consultar los riesgos en los requerimientos.

Tabla 2 Requerimientos funcionales

Para ver la documentación de los requerimientos de ERMT 2.0 ver Anexo 4. Documentación

requerimientos.

3.2.3. Decisiones de arquitectura y diseñoLos criterios que se tuvieron en cuenta para la arquitectura y diseño de ERMT 2.0, fueron los

siguientes:

Casos de uso

Requerimientos funcionales y no funcionales

Restricciones del sistema.

Página 46


Lugo de establecer los criterios de diseño se agregaron nuevos elementos solo para el vista

lógica y la vista de datos, es decir, solo se cambió la arquitectura de bajo nivel, ya que uno de

los objetivos de este trabajo de grado era no afectar las funcionalidades existentes en la

herramienta y mantener la consistencia entre ambas versiones, además de complementarlas

mediante nuevos métodos, para ello se modificó el diagrama de clases y el modelo entidad

relación, los cuales se muestra a continuación:

La figura 4 muestra el diagrama de clases identificadas con el color amarillo corresponden a

ERMT 1.0 y las clases identificadas con el color azul corresponden a ERMT 2.0. Anexo 10.

Diagrama de clases.

Figura 4 Diagrama de clases

Página 47



La figura 5 muestra el diagrama entidad relación, las tablas identificadas con el color amarillo

corresponden a ERMT 1.0 y las clases identificadas con el color azul corresponden a ERMT

2.0. Anexo 11.Diagrama entidad relación.

Página 48


Figura 5 Modelo de datos

Ver Anexo 5. Documento de diseño

Página 49



3.2.4. Pruebas funcionales

El objetivo de las pruebas funcionales, era determinar que las nuevas funcionalidades desa-

rrolladas a ERMT 2.0, se adaptaran correctamente a las funcionalidades que ya existían y

verificar que cada una de estas cumpliera con su propósito. A continuación se muestran las

pruebas realizadas a cada una de las funcionalidades:

Línea base de requerimientos: Esta prueba de funcionalidad se realizó mediante la creación,

consulta y eliminación de varias líneas base de requerimientos.

Problemas en los requerimientos: Esta prueba de funcionalidad se realizó mediante la crea-

ción, edición y eliminación de problemas en los requerimientos. También se verificó que el

reporte generado contenga toda la información correspondiente a los problemas en los reque-

rimientos.

Proceso control de cambios: Esta prueba de funcionalidad se realizó mediante la edición y

consulta del proceso de cambios en los requerimientos.

Gestión de riesgos: Esta prueba de funcionalidad se realizó mediante la creación, edición y

consulta de los riesgos asociados a los requerimientos. También se verificó que para cada

riesgo en los requerimientos se asignara su correspondiente técnica de mitigación.

Matriz de trazabilidad: Esta prueba de funcionalidad se realizó mediante la verificación del

reporte que se genera con la relación de los requerimientos frente a los casos de uso.

Para ver en más detalle las pruebas funcionales realizadas Ver Anexo 6. Documento de prue-

bas .

3.2.5. Validación prototipo

Para la validación de ERMT 2.0, se contó con la ayuda de dos expertas, las cuales realizaron

la validación del prototipo, la cual consistió en comparar la primera y la segunda versión de

ERMT, luego verificar que las nuevas funcionalidades agregadas, permitieran abarcar más

actividades de la administración de requerimientos y poder así llevar una gestión de los re-

querimientos más adecuada.

Página 50


Para ver en más detalle la validación del prototipo Ver Anexo 7. Carta de aprobación.

IV - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS

4. Resultados

Los resultados de este trabajo de grado se pueden determinar mediante la adición de nuevas

funcionalidades para la administración y gestión de los riesgos en los requerimientos, las

cuales se muestra a continuación:

Funcionalidad Descripción

Línea base de requerimientos Esta funcionalidad permite al usuario crear, consultar

y eliminar líneas base de requerimientos del proyecto.

Problemas en los requerimientos

Esta funcionalidad permite al usuario asociar, editar,

eliminar y generar un reporte de los problemas en los

requerimientos del proyecto.

Proceso control de cambios. Esta funcionalidad permite al usuario modificar y

consultar los requerimientos del proyecto a través de

este proceso.

Gestión de riesgos. Esta funcionalidad permite al usuario asignar y editar

los riesgos en los requerimientos, y el prototipo

generar la técnica de mitigación apropiada.

Matriz de trazabilidad. Esta funcionalidad permite al usuario generar una

matriz de trazabilidad de relaciones entre

requerimientos y casos de uso.

Tabla 3 Resultados

En la ilustración 1, se muestran las nuevas funcionalidades que se agregaron a esta nueva

versión de ERMT, las cuales se explican en detalle a continuación:

Página 51



Ilustración 1 Menú principal

4.1. Línea base de requerimientos

Mediante esta nueva funcionalidad, el usuario puede crear, consultar y eliminar líneas base de

requerimientos en un proyecto, la cual representa un conjunto acordado, revisado y aprobado

de los requerimientos funcionales y no funcionales y sirve como base para un mayor desarro -

llo. La consulta de líneas base permite conocer cuáles han sido las iteraciones que se han

hecho a lo largo del proyecto. La eliminación de líneas base no implica la eliminación del

conjunto de requerimientos asociados a esta línea base. En la ilustración 2 se puede visualizar

la consulta de las líneas base asociadas a un proyecto.

Página 52


Ilustración 2 Línea base de requerimientos

4.2. Problemas en los requerimientos

Mediante esta nueva funcionalidad, el usuario puede llevar un seguimiento a los problemas

que se generaron a lo largo del desarrollo del proyecto, con el objetivo de conocer el estado

actual de los requerimientos, esta funcionalidad permite generar un reporte con el historial de

todos los problemas asociados a los requerimientos y como ha sido su evolución. En este

reporte se muestran tanto los problemas solucionados como los no solucionados en los reque-

rimientos. En la ilustración 3 se puede visualizar el reporte que se genera con los problemas

asociados a un proyecto.

Página 53



Ilustración 3 Problemas en los requerimientos

4.3. Proceso control de cambios

Mediante esta nueva funcionalidad, el usuario puede modificar un requerimiento asociado del

proyecto, el cual contiene su respectiva descripción, versión, estado y responsable. La herra -

mienta almacena el historial de todos los cambios realizados a ese requerimiento específico,

para poder llevar un control de los cambios que se han hecho y poder establecer de manera

precisa quien ha realizado los cambios y como ha sido su desarrollo. En la ilustración 4 se

puede visualizar el historial de todos los cambios hechos en los requerimientos asociados a un

proyecto. La herramienta muestra primero el cambio más reciente realizado a los requeri -

mientos.

Página 54


Ilustración 4 Proceso control de cambios

4.4. Gestión de riesgos

Mediante esta nueva funcionalidad, el usuario puede asociar un riesgo a un requerimiento y la

herramienta internamente genera el correspondiente el nivel de prioridad para cada una de las

técnicas de mitigación, mediante la combinación de los ítems de Identidad, Volatilidad y

Complejidad. En la ilustración 5 se puede visualizar el riesgo asociado a los requerimientos

del proyecto con su respectivo nivel y técnica de mitigación

Página 55



Ilustración 5 Gestión de riesgos

4.5. Matriz de trazabilidad

Mediante esta nueva funcionalidad, el usuario puede generar una matriz de trazabilidad, la

cual contiene todos los requerimientos del proyecto y la relación que tienen con los casos de

uso, además permite conocer su origen y poder llevar un seguimiento individual a cada re-

querimiento con otros componentes del sistema. En la ilustración 6 se puede visualizar la

matriz de trazabilidad de los requerimientos asociados a un proyecto

Página 56


Ilustración 6 Matriz de trazabilidad

Para ver más en detalle cada funcionalidad Ver Anexo 12. Manual de usuario.

Los resultados fueron satisfactorios y los esperados, ya que se cumplieron con todos los obje-

tivos propuestos, además estas nuevas funcionalidades se complementan de manera correcta

con las que ya estaban, permitiendo que ERMT abarque más actividades relacionadas con la

administración de requerimientos.

V – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS

Página 57



5.1. Conclusiones

Mediante el desarrollo de esta nueva versión de ERMT, la incorporación de nuevas funciona-

lidades se pudo concluir lo siguiente:

Se logró desarrollar todas las nuevas funcionalidades de ERMT 2.0.

Se pudo integrar las nuevas funcionalidades propuestas a ERMT, sin afectar las que

ya estaban.

Se cumplieron todos los objetivos específicos realizados en la propuesta de trabajo de

grado. Ver Anexo 8. Propuesta trabajo de grado.

Se aprendió a trabajar mediante la guía de una metodología.

Se aprendió a realizar la planeación de un proyecto paso a paso.

5.2. Recomendaciones

Mi recomendación es identificar primeramente un problema que se desea solucionar, luego

realizar un estudio de quien o quienes ya han estudiado esa problemática en particular para

poder establecer que soluciones se han propuesto y conocer sus resultados. Luego es impor-

tante definir que otras posibles soluciones podrían existir con el fin de mejorar o arreglar el

problema encontrado, para luego poder establecer el alcance del proyecto que se desea reali-

zar.

5.3. Trabajos Futuros

Como trabajos futuros para este trabajo de grado, es la de implementar nuevas

funcionalidades que permitan el desarrollo de requerimientos en un proyecto se software, ya

que este tema hace parte de la ingeniería de requerimientos y permite complementar con las

funcionalidades que tiene ERMT para la administración de requerimientos.

Página 58


También como otro trabajo futuro, es la de utilizar ERMT en una ambiente empresarial,

mediante el desarrollo de un proyecto TI, ya que esta herramienta también permite gestionar

los requerimientos para este tipo de proyectos de software, pero es necesario que la

herramienta tenga la posibilidad de crear roles para poder establecer de una manera más

precisa, que privilegios tiene un usuario, con base a su función dentro del proyecto.

Página 59



VI - POST-MORTEM

6.1. Metodología propuesta vs. Metodología realmente utilizadaLas metodologías propuestas para este trabajo de grado fueron dos, la primera consistió en la

fase de exploración, la cual permitió recolectar bibliografía acerca de la administración de

requerimientos, luego se estudiaron diferentes herramientas para la administración de

requerimientos que existen en el mercado y luego un estudio general sobre ERMT, la cual

determinó las actividades de la primera parte del trabajo de grado.

La segunda metodología que se uso fue SCRUM, la cual consistió en el desarrollo de las

nuevas funcionalidades, aunque en esta etapa hubo atrasos en los tiempos estimados, nunca

se cambió la metodología propuesta.

En términos generarles las dos metodologías propuestas se cumplieron a cabalidad, ya que no

se modificó en ningún momento las actividades relacionadas a estas.

6.2. Actividades propuestas vs. Actividades realizadas

Las actividades propuestas frente a las actividades realizadas, fueron acorde a las que se había

presupuestado, ya que cada actividad fue planeada para abarcar de manera precisa y amplia

cada objetivo específico, por lo cual no se agregaron nuevas actividades a lo largo del desa-

rrollo del trabajo de grado.

6.3. Efectividad en la estimación de tiempos del proyecto

La efectividad en la estimación de los tiempos del proyecto frente a los tiempos reales no fue

la más precisa, ya que la diferencia entre ambas fue de 130 horas. Para medir el tiempo de las

actividades realizadas a lo largo del trabajo de grado, utilice un archivo en Excel, el cual iba

actualizando a medida que terminaba una actividad. En la tabla 3 se muestra en detalle cada

actividad realizada, comparando la duración estimada frente a la duración real:

Página 60


Cronograma

Actividad Duración estimada Duración real

Investigar la mayor cantidad de herramientas para la administración de requerimientos que existen en el mercado.

15 20

Conocer y entender las características y funcionalidades que ofrecen estas herramientas.

15 15

Comparar las funcionalidades de ERMT frente a las herramientas existentes en el mercado.

25 30

Investigar y analizar los diferentes estándares de calidad de requerimientos, para determinar que funcionalidades se le pueden agregar a la herramienta.

18 18

Definir qué funcionalidades le hacen falta a ERMT para complementarla, además que estén dentro del alcance y sirvan para un entorno educativo.

22 32

Elaboración del marco teórico del tema. 30 40

Conocer y entender la arquitectura que tiene ERMT.

15 15

Elaboración documento SPMP. 30 35

Elaboración de los casos de uso. 25 40

Realizar la especificación de requerimientos. 20 30

Elaborar el Documento de Requerimientos de Software (SRS).

30 40

Elaboración de la arquitectura del sistema. 35 40

Elaboración del diseño por componentes del sistema.

30 30

Elaboración del Documento de Diseño del Sistema (SDD).

25 25

Desarrollo e implementación de las nuevas funcionalidades.

60 80

Realizar las pruebas de usabilidad. 45 45

Analizar los resultados de las pruebas de usabilidad.

20 20

Elaboración manual de usuario. 25 25

Página 61



Elaboración de memoria final del trabajo de grado. 30 60

Elaboración de página web de trabajo de grado. 30 35

Total 545 675

Tabla 4 Cronograma

Al analizar esta tabla se puede concluir que el mayor desfase de tiempo fue en el diseño y el

desarrollo de la herramienta.

6.4. Costo estimado vs. Costo real del proyecto

La diferencia del costo estimado frente al costo real del proyecto fue de $2.600.000, ya que el

tiempo en horas para el desarrollo del trabajo de grado, fue mayor al planeado por lo que sus

costos aumentaron. En la tabla 4 se muestra en detalle el presupuesto estimado:

Presupuesto estimado

Concepto Cantidad Costo por unidad Total

Recurso ingeniero de sistemas 545 horas $ 20.000 $ 10.900.000

Recurso director de trabajo de grado

40 horas $ 75.000 $3.000.000

Computador personal del ingeniero

1 portátil $ 1.000.000 $1.000.000

Costo de créditos por concepto de matrícula.

4 créditos $ 401.000 $ 1.604.000

Otros costos (buses, almuerzos, servicios)

6 meses $ 150.000 $ 900.000

Total $ 17.404.000

Tabla 5 Presupuesto estimado

En la tabla 5 se muestra en detalle el presupuesto estimado:

Presupuesto real

Concepto Cantidad Costo por unidad Total

Recurso ingeniero de sistemas 675 horas $ 20.000 $ 13.500.000

Recurso director de trabajo de 40 horas $ 75.000 $3.000.000

Página 62


grado

Computador personal del ingeniero

1 portátil $ 1.000.000 $1.000.000

Costo de créditos por concepto de matrícula.

4 créditos $ 401.000 $ 1.604.000

Otros costos (buses, almuerzos, servicios)

6 meses $ 150.000 $ 900.000

Total $ 20.004.000

Tabla 6 Presupuesto real

6.5. Efectividad en la estimación y mitigación de los riesgos del proyectoLa efectividad en la estimación de los riesgos que se establecieron en la propuesta de trabajo

de grado fue alrededor de un 70%, ya que la mayoría de los riesgos propuestos ocurrieron y

algunos se pudieron mitigar, aunque la mitigación no fue la mejor, debido a que no puede

cumplir con el requisito de la lengua extranjera y por ende tuve que posponer el desarrollo del

trabajo de grado seis mees hasta cumplir con el nivel B2 de inglés.

La falta de tiempo fue un riesgo crítico, ya que debía manejar muy bien los tiempos entre el

trabajo, el proyecto social universitario y el desarrollo del trabajo de grado, por lo cual este

riesgo no lo había estimado en la propuesta y por ende tampoco se había establecido la

mitigación a este.

Página 63



VII - REFERENCIAS Y BIBLIOGRAFÍA

7. Referencias

[1] Vanesa Carolina Loaiza Carvajal, Laura Catalina Zorro Jiménez, “ERMT.”, 2011

[Online]. Available: http://pegasus.javeriana.edu.co/~CIS1010IS05/index.html.

[2] “Software Engineering Toolbox | Construx.” [Online]. Available:

http://www.construx.com/Resources/Techniques/Software_Engineering_Toolbox/.

[3] “Systems and Software Engineering - Life Cycle Processes - Risk Management,” Std ISO

IEC 16085 - 2006, pp. c1–36, 2006.

[4] “Systems and software engineering – Life cycle processes –Requirements

engineering,” ISO/IEC/IEEE 29148:2011(E), pp. 1–94, Dec. 2011.

[5] K. E. Wiegers and J. Beatty, Software requirements. 2013.

[6] R. R. Young, The requirements engineering handbook. Boston: Artech House, 2004.

[7] I. Sommerville, Software Engineering. Addison-Wesley, 2007.

[8] “The Curious Case of the CHAOS Report 2009.” [Online]. Available:

http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.php.

[9] A. Zainol and S. Mansoor, “An investigation of a requirements management tool

elements,” in 2011 IEEE Conference on Open Systems (ICOS), 2011, pp. 53–58.

[10] “Scrum Alliance - What Is Scrum?” [Online]. Available:

http://www.scrumalliance.org/pages/what_is_scrum.

Página 64


[11] Bargain Price, Requirements Management: The Interface Between Requirements

Development and All Other Systems Engineering Processes, 1 edition. Berlin ; London:

Springer, 2007.

[12] E. Hull, K. Jackson, and J. Dick, Requirements Engineering, Edición: 3. London ; New

York: Springer, 2010.

[13] B. Berenbach, D. Paulish, J. Kazmeier, A. Rudorfer, and & 1 more, Software & Systems

Requirements Engineering: In Practice, 1 edition. New York: McGraw-Hill Osborne Media,

2009

[14] Torres, M. 2008. Concept on Requirements Engineering. [Online]. Available:

http://sophia.javeriana.edu.co/~metorres/Materias/IngReq/Documentos/Introduccion

[15] K. Wiegers, More About Software Requirements: Thorny Issues and Practical Advice, 1

edition. Redmond, WA: Microsoft Press, 2005.

[16] “Software Engineering Body of Knowledge (SWEBOK) Home.” [Online]. Available:

http://www.computer.org/portal/web/swebok.

[17] L. Mathiassen and T. Tuunanen, “Managing Requirements Risks in IT Projects,” IT

Professional, vol. 13, no. 6, pp. 40–47, Nov. 2011.

[18] B. W. Boehm, “Software risk management: principles and practices,” IEEE Software,

vol. 8, no. 1, pp. 32–41, Jan. 1991.

[19] D. Leffingwell and D. Widrig, Managing software requirements: a use case approach.

Boston: Addison-Wesley, 2003.

[20] M. Hoffmann, N. Kuhn, M. Weber, and M. Bittner, “Requirements for requirements

management tools,” in Requirements Engineering Conference, 2004. Proceedings. 12th IEEE

International, 2004, pp. 301–308.

Página 65



[21] CaliberRM TM. Borland. A micro focus company. [Online] Disponible en:

http://www.borland.com/us/products/caliber/index.html.

[22] Borland CaliberRM. Administering and Using CaliberRM. Guía para el usuario incluida

con la versión de prueba.

[23] Apexnet, Software Factory. Enterprise Architect v 7.5. [Online]. Disponible en:

http://www.apexnet.com.ar/index.php/product/viewProducts/24/sl=0.

[24] IBM. Rational RequisitePro tutorials. Disponible en:

http://publib.boulder.ibm.com/infocenter/reqpro/v7r1m0/index.jsp?topic=/

com.ibm.reqpro.help/get_start/r_tutorials.html.

[25] Techno Solutions. TopTeam Analyst. [Online]. Disponible en:

http://www.technosolutions.com/index.html.

Página 66


VIII - ANEXOS

Anexo 1. Software Project Management Plan

Anexo 2. Documento de casos de uso

Anexo 3. Software Requirements Specification

Anexo 4. Documentación Requerimientos

Anexo 5. Documento de diseño

Anexo 6. Documento de pruebas

Anexo 7. Carta de aprobación

Anexo 8. Propuesta trabajo de grado

Anexo 9. Diagrama casos de uso

Anexo 10. Diagrama de clases

Anexo 11. Diagrama entidad relación

Anexo 12. Manual de usuario

Página 67


propuesta para trabajo de grado - …pegasus.javeriana.edu.co/~cis1410is08/final/memoria... ·...

Documents