propuesta para trabajo de grado - trabajos de grado de …diagrama de gantt.pdf: archivo ... soporta...

Propuesta para Trabajo de Grado - <Aplicación Práctica>

PROPUESTA PARA TRABAJO DE GRADOTÍTULO

Herramienta para la administración de requerimientos de los proyectos de las asignaturasde Ingeniería y Arquitectura de Software de la Pontificia Universidad Javeriana.

MODALIDAD

Aplicación Práctica.

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 Univer-sidad Javeriana.

ESTUDIANTE(S)

Vanesa Carolina Loaiza Carvajal __________________________________________Documento Celular Teléfono fijo Correo Javerianocc. 1014202067

3124222184 4418239 [email protected]

Laura Catalina Zorro Jiménez _____________________________________Documento Celular Teléfono fijo Correo Javerianocc. 1018417059

3103299645 2588900 [email protected]

DIRECTOR

Ing. Miguel Eduardo Torres Moreno __________________________________Documen-to

Celular Teléfono fijo

Correo Javeriano Empresa donde trabaja y cargo

cc. 79789331

3112311935 3208320 ext 5316

[email protected];

Pontificia Universidad Javeriana; Profesor Depar-tamento de Sistemas

Página 1 Preparado por el Grupo Investigación Istar- Versión 1.05 – 01/04/2010

mailto:[email protected]





Contenido

1. OPORTUNIDAD O PROBLEMÁTICA......................................................................4

1.1 DESCRIPCIÓN DEL CONTEXTO..........................................................................41.2 FORMULACIÓN.................................................................................................51.3 JUSTIFICACIÓN..................................................................................................51.4 IMPACTO ESPERADO DEL PROYECTO.....................................................................7

2. DESCRIPCIÓN DEL PROYECTO..............................................................................8

2.1 OBJETIVO GENERAL................................................................................................82.2 OBJETIVOS ESPECÍFICOS.........................................................................................82.3 ENTREGABLES O RESULTADOS ESPERADOS...........................................................8

3. PROCESO............................................................................................................9

3.1 IDENTIFICAR...........................................................................................................93.2 ELABORAR - DISEÑAR............................................................................................93.3 DESARROLLAR Y VERIFICAR..................................................................................10

4. GESTION DEL PROCESO.....................................................................................11

4.1. ESTIMACIÓN DE LA DURACIÓN DEL PROYECTO (ELABORACIÓN DEL CRONOGRAMA)................................................................................................................................... 114.2. ESTIMACIÓN DEL COSTO DEL PROYECTO (PRESUPUESTO)..................................114.3. ESTIMACIÓN DE LOS RIESGOS DEL PROYECTO (ANÁLISIS DE RIESGOS)...............11

5. MARCO TEÓRICO / ESTADO DEL ARTE...............................................................16

5.1. TRABAJOS IMPORTANTES EN EL ÁREA................................................................165.1.1. DOORS....................................................................................................................165.1.2. RATIONAL REQUISITEPRO......................................................................................16

5.2. FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO......................175.3. DOFA DE LAS HERRAMIENTAS TECNOLÓGICAS EXISTENTES ACTUALMENTE Y QUE INTENTAN RESOLVER EL PROBLEMA..........................................................................18

5.3.1. DEBILIDADES..........................................................................................................185.3.2. FORTALEZAS...........................................................................................................18



5.3.3. OPORTUNIDADES...................................................................................................185.3.4. AMENAZAS.............................................................................................................19

5.4. MARCO INSTITUCIONAL......................................................................................19

6. REFERENCIAS....................................................................................................20

6.1 REFERENCIAS........................................................................................................206.2 BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO......21



1. OPORTUNIDAD O PROBLEMÁTICA

1.1 DESCRIPCIÓN DEL CONTEXTO

Para el desarrollo de una aplicación de software existen varias etapas las cuales permiten que este desarrollo sea o no exitoso. Dentro de estas etapas se encuentra la especificación y administra-ción de requerimientos (que se encuentra detallada en la sección 1.3 Justificación de este docu-mento), las cuales permiten saber cuáles son las necesidades, que los clientes y usuarios finales, esperan de la aplicación. Del mismo modo los requerimientos permiten:

- Realizar una estimación precisa del avance del proyecto - Asegurar la calidad del software [1].

Pero a pesar de que los requerimientos son considerados la base del desarrollo de software, du-rante la construcción, no se le da la importancia necesaria y esto se ve reflejado en las estadísticas publicadas por el Standish group[2] 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.

Dentro de las causas por las cuales los proyectos de software fracasan se encuentran las siguien-tes:

- Escasa comunicación con el Cliente. - Claridad en los objetivos del proyecto.- Continuos Cambios en los requerimientos y en sus especificaciones, los cuales derivan en

pérdida de control y monitoreo sobre estos- Poca participación de los usuarios finales. - Requerimientos incompletos, al igual que sus especificaciones. [2]

Estas razones fueron reveladas por el Standish Group[2], las cuales están estrechamente relacio-nadas con la administración de requerimientos, y que permiten relacionar el fracaso de los proyec -tos de software directamente con la administración de requerimientos. Desafortunadamente esta situación no solo se ve en el ámbito profesional, en el ámbito académico también se ve reflejado en asignaturas como la Ingeniería de Software o Arquitectura de Software, por esto que se consi-dera de vital importancia que durante la formación académica y en especial mientras se cursan las



asignaturas de Ingeniería de Software y Arquitectura de Software se dé un especial enfoque sobre la administración de requerimientos.

1.2 FORMULACIÓN

¿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 jave-riana?

1.3 JUSTIFICACIÓN

La administración de requerimientos es un proceso que se desarrolla dentro de la ingeniería de requerimientos [16], pues ésta se define como el conjunto de actividades que garantizan que la información de los requerimientos este siempre al día y que pueda ser accedida por todo el perso-nal del proyecto que puedan beneficiarse de ella. Estas actividades se describen a continuación:

- Especificación de requerimientos: según el SWEBOK “la producción de un documento, o a su equivalente electrónico, que puede estar sistemáticamente repasado, evaluado, y apro-bado”[15]

- Priorización: Cuando las expectativas del cliente son altas, el tiempo es corto y los recur-sos limitados se necesita tener la seguridad de que el producto tenga las funcionalidades esenciales [14], por lo tanto se necesita establecer los requerimientos críticos, lo cual per-mite realizar acciones como: tomar decisiones con los usuarios a cerca de los requerimien-tos que son claves en el sistema, plantear los requerimientos a implementar en cada una de las iteraciones del desarrollo, realizar la estimación de la satisfacción del cliente, mane-jar el proceso de negociación para así resolver los desacuerdos entre los Stakeholders, establecer la importancia de cada requerimiento para proveer el mejor valor de este al menor costo, entre otros.

- Trazabilidad: Hace referencia a las características de un sistema en donde los requeri-mientos se encuentran relacionados con sus fuentes (el origen de cada requerimiento) y con los artefactos que son creados durante el desarrollo del ciclo de vida del software, con base en dichos requerimientos [3], de manera que se pueda comprobar que los requeri -mientos se entendieron desde el comienzo y que el producto cumple con cada uno de estos para satisfacer las necesidades del cliente.

- Análisis del impacto del cambio: lo cual permite identificar las posibles consecuencias que tiene el realizar un cambio sobre un requerimiento y que se necesita modificar para aco-



plar el desarrollo, antes de que el cambio ocurra. Para esto se utilizan los resultados de los procesos anteriormente explicados como la priorización[14] y trazabilidad

- Incluir al cliente: permite que el cliente esté al tanto del desarrollo del proyecto y cumpli-miento de las necesidades que el describió durante la recolección de los requerimientos.

- 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: la información referente al estado del requerimiento puede ser utilizada para llevar a cabo un control de cumplimiento de objetivos [17] y 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 afec-ten el desarrollo del proyecto, es decir decisiones como por ejemplo que modelo arquitec -tónico se va a utilizar [4].

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 software que proveen funcionalidades que permiten hacer de este, un proceso mu-cho 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 [5]:

Definición y clasificación de requerimientos: es decir clasificar los requerimientos de acuerdo a su tipo, bien sean funcionales o no funcionales , esto tomando en cuenta la clasificación de los requerimientos que realiza el SWEBOK[15].Versionamiento 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 especifi -cación, además de poder realizar líneas bases para definir una nueva versión [17].Almacenamiento de los atributos: donde se deben definir cosas tales como prioridad, costo, estado, dificultad, autores, responsables, etc.Encadenamiento a otros elementos del sistema: es decir la herramienta debe permitir que se defina la trazabilidad de cada uno de los requerimientos. [5]Visualización: De acuerdo a las diferentes características de los requerimientos se puede generar una gráfico [17] 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, en este caso las caracterís -tica a tener en cuenta dentro de la herramienta serían la priorización y la trazabilidad.

Además de las características anteriores, en la actualidad, gracias a Stephen Withal[6] existen pa-trones de software que permiten realizar la especificación de requerimientos de acuerdo al tipo de requerimiento que se desea, lo cual puede facilitar la descripción de los requerimientos teniendo en cuenta más detalles, y con más claridad y precisión.



Por lo tanto se puede decir que para mejorar el proceso de administración de requerimientos de las materias de Ingeniería y Arquitectura de Software, las cuales se imparten en la Pontificia Uni-versidad Javeriana, se podría contar con una herramienta de software que permita realizar las funciones anteriormente descritas y añadiendo los tipos de patrones de requerimientos para me-jorar la especificación de estos.

1.4 IMPACTO ESPERADO DEL PROYECTO

El proyecto tiene como fin beneficiar a los diferentes grupos de trabajo conformados por estudian-tes en las asignaturas de Ingeniería de Software y Arquitectura de Software, ya que por medio de la herramienta, se podrá realizar una mejor administración de requerimientos de los proyectos que se deben llevar a cabo en dichas materias; además gracias a la herramienta, se espera apoyar el proceso de aprendizaje del estudiante, ya que se pueden ver reflejados en la práctica los con -ceptos teóricos vistos en las clases y además comprobar la utilidad que tienen las herramientas tecnológicas al momento de aprender algo nuevo.



2. DESCRIPCIÓN DEL PROYECTO

2.1 OBJETIVO GENERAL

Elaborar una herramienta de administración de requerimientos, que soporte el proceso de cons-trucción de software para las asignaturas de Ingeniería de Software y Arquitectura de Software de la carrera de Ingeniería de Sistemas en la Pontificia Universidad Javeriana.

2.2 OBJETIVOS ESPECÍFICOS

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 arquitec-tura de software de la Pontificia Universidad Javeriana.

DISEÑAR la arquitectura de la herramienta de administración de requerimientos.

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 la 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 con un caso de estudio.

2.3 ENTREGABLES O RESULTADOS ESPERADOSDocumento de Visión.Documento de especificación de requerimientos (SRS).Documento de Descripción de la arquitectura (SAD).Herramienta de software funcional.Manuales de Usuario.Reporte de pruebas de software.Memorias.



3. PROCESO

Para el desarrollo del proyecto la metodología 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 para los cuatro objetivos restantes ya que es iterativa, incremental y ade-más permite controlar los riesgos, lo cual permite un desarrollo ágil.[7]

3.1 IDENTIFICAR

Dentro de la fase de exploración se pretende realizar la búsqueda de material bibliográfico, al igual que herramientas de administración de requerimientos, para realizar un análisis, lo cual permitirá identificar así cuales son las características deseadas para el proyecto.

Dentro de las actividades a realizar para esta fase se encuentran:

Recolectar información acerca de las características más importantes que se deben tener en cuenta en la administración de requerimientos.Consultar las herramientas de administración de requerimientos.Realizar un análisis de dichas herramientas.Definir las características básicas de la administración de requerimientos, que la herra-mienta va a proveer.

Como resultado de estas actividades se espera obtener las características básicas con las cuales va a contar la herramienta, que le permitirá a los usuarios realizar una administración de requeri -mientos adecuada.

3.2 ELABORAR - DISEÑAR

En cuanto a la metodología SCRUM, esta cuenta con “Time Boxes” dentro de las cuales se encuen-tran 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 documen-to de Descripción de arquitectura.



3.3 DESARROLLAR Y VERIFICAR

Metodología Actividad Resultado de esta actividad

SCRUM Release Planning Meeting Se espera generar el Product Backlog es decir un docu-mento con los requerimientos funcionales de la herra-mienta [7].

Sprint Planning Meeting Ya que es la primera actividad del Sprint1 el resultado de esta actividad es un documento llamado Sprint Backlog [8] 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 [8].

Sprint Review Al finalizar el Sprint se realizará una reunión para mos-trar la funcionalidad desarrollada durante el Sprint. Se debe realizar un acta donde se registre la retroalimen-tación del cliente [8]. Se debe realizar la integración de la(s) nueva(s) funcio-nalidad (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 re-trasarlo, esto con el fin de mejorar el desempeño del equipo de trabajo [8].

4. GESTIÓN DEL PROCESO

1 Sprint: Es la actividad principal de Scrum, es decir cada Sprint se puede interpretar como una fase [8], cada Sprint tiene una duración máxima de 30 días.



4.1. ESTIMACIÓN DE LA DURACIÓN DEL PROYECTO (ELABORACIÓN DEL CRONOGRAMA)Remitirse a los archivos:

Tabla de actividades con recursos.xlsx: que contiene las diferentes actividades a realizar durante el proyecto

Red de proyecto.png: que contiene el diagrama de pert de cada una de las actividades, las cuales están representadas con un identificador

Diagrama de Gantt.pdf: archivo que contiene el diagrama de Gantt de cada una de las actividades distribuidas en el tiempo.

4.2. ESTIMACIÓN DEL COSTO DEL PROYECTO (PRESUPUESTO)Remitirse a los archivos:

Tabla de actividades con recursos.xlsx: que contiene los recursos asignados a cada activi-dad tanto físicos como humanos.

Plantilla presupuesto TG.xlsx: que contiene especificado los costos monetarios de cada recurso que se planea usar durante el proyecto.

4.3. ESTIMACIÓN DE LOS RIESGOS DEL PROYECTO (ANÁLISIS DE RIESGOS)Los riesgos que se van a considerar se ubican en alguna de las ramas que se definieron como más importantes para el desarrollo de este proyecto, estas ramas son:

Riesgos de proyecto: se refiere a los riesgos que pueden afectar al desarrollo del proyec-to en general, en estos encontramos los riesgos de: tiempo, equipo, relaciones con el cliente.

Riesgos técnicos: se refiere a los riesgos que están asociados con la parte técnica del proyecto, este está compuesto por los riesgos: operativos, de desarrollo (programa-ción), de documentación, y de almacenamiento.

Sin embargo los riesgos a analizar, no abarca todo el desarrollo del proyecto, ya que la metodolo-gía a usar está basada en SCRUM, por lo tanto, la definición y actualización de los riesgos que surgen se realizará en cada etapa.

a. IDENTIFICACIÓN

A continuación se encuentran los riesgos que podrían afectar de manera significativa el desarrollo del proyecto.



Riesgos de proyecto Riesgos temporales

1. El tiempo designado para el desarrollo no es suficiente.2. Mala planeación en la calendarización.

Riesgos de equipo3. Reuniones no suficientes y poco productivas.4. Inhabilidad o incapacidad durante el desarrollo por parte de un integrante

del grupo.5. Falta de respuesta en el trabajo asignado.6. Conflictos frecuentes y mal ambiente de trabajo al interior del grupo.7. Priorización errónea de las actividades a realizar por cada uno de los inte-

grantes. Riesgos de la fase de requerimientos

8. Mala definición de los requerimientos9. Mala documentación de los requerimientos

Riesgos de la fase de diseño10. Problema con alguno de los diseños 11. Conflictos con la trazabilidad y/o priorización de los requerimientos12. Falla en la documentación de algún diagrama.

Riesgos de relaciones con el Director13. Falta de comunicación con el Director14. Baja disponibilidad por parte del Director.

Riesgos técnicos Riesgos operativos

16. Falla general de los equipos17. Fallas en el sistema operativo.18. Poca o nula disponibilidad de los equipos.19. Falla de algún servidor.

Riesgos de desarrollo20. Incapacidad de la herramienta para soportar el desarrollo de un requeri-

miento.21. Problemas de compatibilidad entre los programas y sistemas operativos

seleccionados.22. Falta de entrenamiento y habilidad para el manejo de las herramientas.23. Disponibilidad nula de alguna herramienta de desarrollo necesaria.

Riesgos de documentación24. Falta de información.25. Manejo de información errada.

Riesgos de almacenamiento26. Perdida de documentación. 27. Poca o nula disponibilidad del repositorio.28. Mal control de los documentos a subir al repositorio.



b. ANÁLISIS

Una vez identificado los riesgos que se tendrán a lo largo del proyecto, se les asignara un valor de probabilidad y de impacto de acuerdo a la experiencia que se ha adquirido a través del tiempo y de la estimación. Teniendo en cuenta la probabilidad y el impacto se podrá obtener un valor de riesgo para establecer una priorización y con esto determinar la manera de mitigar los riesgos.

ANÁLISIS DE RIESGOS

Id Clasificación Probabilidad Impacto Valor de riesgo

1 El tiempo designado para el desarrollo no es suficiente. 4 4 8

2 Mala planeación en la calendarización. 4 4 8

3 Reuniones no suficientes y poco productivas. 3 3 6

4 Inhabilidad o incapacidad durante el desarrollo por parte de un integrante del grupo.

2 4 6

5 Falta de respuesta en el trabajo asignado. 3 4 7

6 Conflictos frecuentes y mal ambiente de trabajo al interior del grupo. 2 3 5

7 Priorización errónea de las actividades a realizar por cada uno de los inte-grantes.

3 4 7

8 Mala definición de los requerimientos 3 5 8

9 Mala documentación de los requerimientos 2 4 6

10

Problema con alguno de los diseños 3 4 7

11

Conflictos con la trazabilidad y/o priorización de los requerimientos 3 3 6

12

Falla en la documentación de algún diagrama. 2 3 5



13

Falta de comunicación con el Director. 2 4 6

14

Baja disponibilidad por parte del Director. 4 4 8

15

Falla general de los equipos 3 3 6

16

Fallas en el sistema operativo. 3 3 6

17

Poca o nula disponibilidad de los equipos. 2 4 6

18

Falla de algún servidor. 1 5 6

19

Incapacidad de la herramienta para soportar el desarrollo de un requeri -miento.

2 4 6

20

Problemas de compatibilidad entre los programas y sistemas operativos seleccionados.

2 4 6

21

Falta de entrenamiento y habilidad para el manejo de las herramientas. 3 4 7

22

Disponibilidad nula de alguna herramienta de desarrollo necesaria. 2 3 5

23

Falta de información. 2 4 6

24

Manejo de información errada. 3 5 8

25

Perdida de documentación. 2 4 6

26

Poca o nula disponibilidad del repositorio. 2 5 7

27

Mal control de los documentos a subir al repositorio. 1 3 4

Luego de identificar el Top ten de los riesgos se prosigue a proponer las diferentes estrategias que los minimicen.

Accion / Numero del riesgo 1 2 8 14 24 5 7 10 21 26



Redefinir los tiempos de planeación para que se pueda cumplir con las actividades propuestas

X X

Realizar iteraciones para la definición y correc-ción de cada uno de los artefactos, además si necesita cambiarse, actualizar las diferentes relaciones y dependencias de cada artefacto

X X

Consultar con el director sus posibles tiempos críticos (Exámenes, entregas de proyecto, sus-tentaciones) para así planear las reuniones de la mejor manera, el cual permita la completa ase-soría por parte de él

X

Mantener un repositorio en más de un lugar y mantenerlos actualizado

X

Compartir la información obtenida con el grupo y el director, para así tener la certeza de que es información confiable

X

Tener una herramienta online que permita el envió de recordatorios, para que cada integrante tenga más probabilidad de cumplir con el traba-jo asignado

X

Realizar la priorización de actividades en conjun-to para así tener las tareas a realizar claras.

X

En lo posible definir las herramientas a usar lo más temprano posible, así garantizar que el tiempo de aprendizaje pueda ser un poco mas largo

X

5. MARCO TEÓRICO / ESTADO DEL ARTE

5.1. TRABAJOS IMPORTANTES EN EL ÁREA



Existen tres conocidas herramientas dentro del área de administración de requerimientos, a conti-nuación se muestra una breve descripción de cada una de ellas.

5.1.1. DOORSEs una de las herramientas más conocidas para el manejo de los requerimientos, pues brinda cada uno de los servicios básicos en una administración como lo es: la inscripción de atributos ilimitados a los requerimientos, al igual que sus relaciones entre requerimientos para realizar una trazabili-dad a “varios niveles”[9] e impresión de informes sobre este tema, como señala la herramienta.

DOORS ofrece diferentes soluciones orientado a diferentes necesidades, como para empresas, para equipos, con acceso a la Web para realizar este proceso [9].

Las principales características de esta herramienta se encuentran a continuación: Interfaces intuitivas que promueven la adopción de la Gestión de Requisitos Escalabilidad para cualquier tamaño de proyecto con cualquier número de usuarios Una matriz de trazabilidad de requisitos fácil de usar, actualizada y flexible El soporte más completo para el registro, estructuración, gestión y análisis de requisitos y

su trazabilidad Integración sin precedentes con otras soluciones de Telelogic y herramientas de terceros

para tener una mejor visión de los requisitos y controlar su trazabilidad a lo largo del ciclo de vida del proceso de desarrollo [12]

5.1.2. RATIONAL REQUISITEPRO

Esta herramienta de administración de requerimientos soporta la herramienta Microsoft Word para la creación de los requerimientos. Y para tener en cuenta las métricas de los requerimientos soporta Microsoft Excel.[13]

Esta herramienta de IBM provee la opción de crear un proyecto nuevo teniendo en cuenta que metodología se quiere o se está utilizando para el desarrollo del proyecto.

Ofrece diferentes opciones al usuario:

- Plantilla RUP: que permite crear la especificación de requerimientos incluyendo los entre-gables requeridos como los tipos de documentos que componen cada uno de estos entre-gables. Los tipos de documentos que provee son: Visión, glosario, casos de uso, lista de riesgos, casos de prueba, plan de administración de requerimientos, requerimientos de Stakeholders. Los tipos de requerimientos que maneja son: Requerimientos de Stackehol-ders, reglas de negocio, casos de prueba, riesgos, mitigación de riesgos, entre otros.



- Plantilla SAP: proporciona tipos de requerimientos y documentos para recolectar, analizar y administrar los requerimientos de negocio asociados con el desarrollo SAP. Los tipos de requerimientos que soporta son: metas de negocio, requerimientos de negocio, reglas de negocio y el glosario de términos de negocio. Dentro de los documentos que trabaja son: glosario de negocio, visión, especificación de casos de uso de negocio, especificación de requerimientos no funcionales y el plan de administración de requerimientos.

- Plantilla tradicional: es para organizaciones que están acostumbradas a hacer la especifi-cación de requerimientos de manera tradicional. Incluye los documentos de visión, glosa-rio, SRS y plan de administración de requerimientos.

5.2. FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO.

Administración de requeri-mientos

“La administración de requerimientos com-prende las actividades relacionadas con la defi-nición, clasificación, asignación, seguimiento y control de los requerimientos durante todo el ciclo de vida de desarrollo de software.”.[11]

Priorización de requeri-mientos

Ver sección 1.3. JUSTIFICACIÓN

Trazabilidad de requeri-mientos

Ver sección 1.3. JUSTIFICACIÓN

Visibilidad de requerimien-tos

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 Stakehol-ders del proyecto ver con más claridad cuáles son las rutas críticas de desarrollo.

Requerimiento Un requerimiento se define como "una condi-ción o capacidad que un sistema debe cumplir".[10]Existe diferentes tipos de requerimientos y pueden clasificarse de diferentes maneras, aquí se presenta una de las más usadas:

Funcionalidad Usabilidad Fiabilidad El rendimiento Compatibilidad

Especificación de requeri- Ver sección 1.3. JUSTIFICACIÓNPágina 17 Preparado por el Grupo Investigación Istar- Versión 1.05 – 01/04/2010


mientosPatrones de requerimien-tos

5.3. DOFA DE LAS HERRAMIENTAS TECNOLÓGICAS EXISTENTES ACTUALMENTE Y QUE INTENTAN RESOLVER EL PROBLEMA.

5.3.1. DEBILIDADES La mayoría de las herramientas, requieren una licencia para su uso las cuales suelen ser

costosas, donde solo las grandes empresas pueden tener acceso Muchas de las herramientas tienen un nivel de dificultad son n complicadas de manejar A pesar de que la curva de aprendizaje puede llegar a ser muy larga, las herramientas no

brindan unos tutoriales que apoyen este proceso, haciendo más difícil y costoso imple-mentar una herramienta como estas dentro de la empresa.

Existen pocas herramientas que implementen todas las funcionalidades que una adminis-tración de requerimientos debe incluir , existen herramientas que aportan a una tarea específica como priorización o trazabilidad

5.3.2. FORTALEZAS Existen varias opciones a la hora de usarlas, como el acceso desde cualquier punto a través

de la Web, dentro de la misma compañía. Ofrecen caracterizar sus requerimientos a través de sus atributos, permitiendo adaptar la

herramienta a las reglas de negocio de cada empresa Ofrecen las funcionalidades básicas como trazabilidad, dependencias, organización en una

base de datos y control de cambios Ofrece la impresión de informes en diferentes informes, como .rtf o .doc

5.3.3. OPORTUNIDADES Pueden orientarse al sector educativo, permitiendo la apropiación de conceptos a través

de la práctica Existen diferentes funcionalidades que pueden aportar a nuestra herramienta, como la

trazabilidad, pues es una actividad común en cada una de ellas al igual que el control de cambios y la definición de unos atributos generales.

5.3.4. AMENAZAS El éxito de la administración de requerimientos depende en gran parte de la definición de

los requerimientos, si están mal definidos muy posiblemente la especificación de los re-



querimientos no sea la correcta y el tiempo invertido en el proceso de administración sea desperdiciado.

5.4. MARCO INSTITUCIONAL

Pontifica Universidad Javeriana

Departamento de Sistemas Facultad de Ingeniería Director trabajo de grado: Miguel Eduardo Torres

Proyecto de Grado a cargo de Estudiantes:

Vanesa Carolina Loaiza Carvajalo Ingeniería de Sistemaso Semestre IX

Laura Catalina Zorro Jiménez o Ingeniería de Sistemaso Semestre X

6. REFERENCIASPágina 19 Preparado por el Grupo Investigación Istar- Versión 1.05 – 01/04/2010


6.1 REFERENCIAS

[1]. Barbacci M, Klein M, Longstaff T, Weinstock C. Quality Attributes. Diciembre 1995.

[2]. The Standish Group. CHAOS summary report [Homepage en internet]. Disponible en: http://www.projectsmart.co.uk/docs/chaos-report.pdf

[3]. Software Requirement traceability tool(Tracer). [Homepage en Internet]. Disponible en: http://www.softreq.com/tracer/index.cfm

[4]. Ramesh B, Jarke M. Towards reference models for requirements traceability. [Articulo en In-ternet ]. Disponible en: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.6602 . Mayo 1999.

[5]. Wiegers K. Automating Requirements Management. [Homepage En Internet]. Disponible en: http://www.processimpact.com/articles/rm_tools.html

[6]. Withal S. Software Requirements patterns. Microsoft Press, 2007.

[7]. Scrum.org. SCRUM. [Documento en Internet]. Disponible en: http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit

[8]. Mountain Goat Software. Introduction to SCRUM. [Homepage en Internet]. Disponible en: http://www.mountaingoatsoftware.com/topics/scrum

[9] Requirements Tools. Volere [Homepage en Internet]. Disponible en: http://www.volere.co.uk/tools.htm

[10] Requirement. Rational Unified Process. [Documento en Internet] Disponible en: http://ru-p.hops-fp6.org/process/workflow/requirem/co_req.htm

[11] Requirement Management [Documento en Internet] Disponible en: http://www.se.fh-heil-bronn.de/usefulstuff/Rational%20Rose%202003%20Documentation/ReqPro%20help/pages/fra-mes2.html

[12] DOORS de Telelogic. Optimización de aplicaciones, procesos e infraestructura de software. [Homepage en Internet] Disponible en: http://www.als-es.com/home.php?location=herramientas/entorno-desarrollo/doors

[13]. Rational. The software development company. Rational RequisitePro. [Tutorial en internet]. Disponible en: http://www.se.fh-eil bronn.de/usefulstuff/Rational%20Rose%202003%



20Documentation/ReqPro%20help/tutorial.html

[14] Wiegers, Karl. First Things First: Prioritizing Requirements. [Articulo] 1999.

[15] SWEBOK en Español. Capitulo 2. Requerimientos de Software. [HomePage] Disponible en: www.swebok.org

[16] Hood, C. Wiedemann, S. Fichtinger, S. Pautz, U. Requirements Management. The interface Between requirements development and all other system Engineering process. Springer. 2008.

[17] Hoffmann, M. Kühn, N. Weber, M. Bittner, M. Requirements for Requirements Management Tools. IEEE Computer Society

6.2 BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO

Para el desarrollo del proyecto se tendrán en cuenta las referencias de la sección inmediatamente anterior y las siguientes:

[1]. Withall, S. Software Requirements Patterns. Primera Edición. Microsoft Press 2007.

[2]. Heim P, Lohmann S, Lauenroth K, Ziegler J. Graph-based Visualization of Requirements Rela-tionships.

[3]. Gotel O, M¨ader P. How to select a requirements Management Tool: Initial Steps.

[4]. Hoffmann M, Kühn N, Weber M, Bittner M. Requirements for Requirements Management Tools.

[5]. Heinonen, S. Requirements Management tool support for software engineering in collabora-tion.

[6]. Hood, C. Wiedemann, S. Fichtinger, S. Pautz, U. Requirements Management: The Interface Between Requirements Development and All Other Systems Engineering Processes. Springer, 2008.

[7] Matulevicius R. Prototype of the evaluation framework for functional requirements of RE-tools


propuesta para trabajo de grado - trabajos de grado de …diagrama de gantt.pdf: archivo ... soporta...

Documents