visiÓn - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~cis1010is05/documentos... · web...
TRANSCRIPT
Herramienta para la administración de requerimientos de los proyectos de las asignaturas de Ingeniería De Software y Arquitectura de Software de la Pontificia Universidad Javeriana.
DOCUMENTO DE VISIÓN
VANESA CAROLINA LOAIZA CARVAJALLAURA CATALINA ZORRO JIMÉNEZ
HISTORIAL DE CAMBIOS
FECHA VERSION
DESCRIPCION RESPONSABLE
21/09/2010 1.0 Organización del Documento Secciones 1
Vanesa Carolina Loaiza, Laura Catalina Zorro
22/09/2010 1.1 Secciones 2,3,4 Vanesa Carolina Loaiza, Laura Catalina Zorro
23/09/2010 1.2 Secciones 6,7,9 Vanesa Carolina Loaiza, Laura Catalina Zorro
24/09/2010 1.3 Secciones 5, 8, 10 Vanesa Carolina Loaiza, Laura Catalina Zorro
04/10/2010 1.4 Ultimas correcciones
Vanesa Carolina Loaiza, Laura Catalina Zorro
Tabla 1: Historial de cambios
2
TABLA CONTENIDO
HISTORIAL DE CAMBIOS.....................................................................................................................2TABLA CONTENIDO............................................................................................................................3INDICE DE TABLAS..............................................................................................................................61. INTRODUCCION..........................................................................................................................7
1.1. Propósito............................................................................................................................71.2. Alcance...............................................................................................................................71.3. Definiciones, acrónimos y abreviaciones............................................................................71.4. Referencias.........................................................................................................................8
2. POSICIONAMIENTO..................................................................................................................10
2.1. Oportunidad de Negocio..................................................................................................102.2. Planteamiento del Problema............................................................................................102.3. Enunciado de posición del problema................................................................................11
3. DESCRIPCION DE USUARIOS Y STAKEHOLDERS........................................................................13
3.1. Datos demográficos del Mercado.....................................................................................133.2. Resumen de Stakeholders................................................................................................133.3. Resumen de usuario.........................................................................................................143.4. Ambiente de usuario........................................................................................................153.5. Perfil de los Stakeholders.................................................................................................15
3.5.1. Director del Proyecto................................................................................................153.5.2. Grupo de Trabajo......................................................................................................16
3.6. Perfiles de usuario............................................................................................................16
3.6.1. Profesores de Ingeniería de Software.......................................................................163.6.2. Profesores de Arquitectura de Software..................................................................173.6.3. Estudiantes de Ingeniería de Software.....................................................................173.6.4. Estudiantes de Arquitectura de Software.................................................................18
3.7. Necesidades de los Usuarios............................................................................................183.8. Alternativas y Competencias............................................................................................20
4. DESCRIPCION DEL PRODUCTO..................................................................................................21
4.1. Perspectiva del producto..................................................................................................214.2. Resumen de Capacidades.................................................................................................21
3
4.3. Suposiciones y Dependencias...........................................................................................22
4.3.1. Suposiciones.............................................................................................................224.3.2. Dependencias...........................................................................................................23
4.4. Licencias e instalación......................................................................................................24
5. CARACTERISTICAS DEL PRODUCTO...........................................................................................25
5.1. Definición de Atributos.....................................................................................................255.2. Clasificación de Requerimientos.......................................................................................255.3. Priorización de Requerimientos.......................................................................................265.4. Administración y Control del Cambio...............................................................................265.5. Almacenamiento de Requerimientos Rechazados...........................................................265.6. Localización de Requerimientos.......................................................................................265.7. Trazabilidad de Requerimientos.......................................................................................275.8. Verificación y Validación de Requerimientos..................................................................275.9. Visualización de los Requerimientos................................................................................275.10. Generación de Reportes...............................................................................................28
6. RESTRICCIONES........................................................................................................................297. RANGOS DE CALIDAD...............................................................................................................30
7.1. Eficiencia..........................................................................................................................307.2. Usabilidad.........................................................................................................................307.3. Portabilidad......................................................................................................................307.4. Funcionalidad...................................................................................................................317.5. Mantenibilidad.................................................................................................................31
8. PRECEDENCIA Y PRIORIDAD.....................................................................................................329. OTROS REQUERIMIENTOS DEL PRODUCTO..............................................................................34
9.1. Estándares aplicados........................................................................................................349.2. Requerimientos del Sistema.............................................................................................349.3. Requerimientos de Desempeño.......................................................................................359.4. Requerimientos del entorno............................................................................................35
10. REQUERIMIENTOS DE DOCUMENTACION............................................................................36
10.1. Manual de Usuario.......................................................................................................3610.2. Ayuda en línea..............................................................................................................3610.3. Guías de instalación, configuración y Archivos Read me..............................................3610.4. Etiquetado y empaquetamiento...................................................................................37
4
INDICE DE TABLAS
TABLA 1: HISTORIAL DE CAMBIOS...........................................................................................2TABLA 2: DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES..............................................................7TABLA 3: PROBLEMA..........................................................................................................10TABLA 4: DEFINICIÓN DEL PROBLEMA....................................................................................11TABLA 5: RESUMEN DE STAKEHOLDERS.................................................................................13TABLA 6: RESUMEN DE USUARIOS........................................................................................14TABLA 7: STAKEHOLDER - DIRECTOR DE PROYECTO.................................................................15TABLA 8: STAKEHOLDER - ENCARGADO DE PRUEBAS................................................................15TABLA 9: USUARIO – PROFESORES INGENIERÍA DE SOFTWARE....................................................16TABLA 10: USUARIO – PROFESORES ARQUITECTURA DE SOFTWARE.............................................16TABLA 11: USUARIO – ESTUDIANTE DE INGENIERÍA DE SOFTWARE..............................................17TABLA 12: USUARIO – ESTUDIANTE DE ARQUITECTURA DE SOFTWARE.........................................17TABLA 13: NECESIDADES DE LOS USUARIOS...........................................................................19TABLA 14: RESUMEN DE CAPACIDADES..................................................................................21TABLA 15: RANGO DE CALIDAD - EFICIENCIA..........................................................................29TABLA 16: RANGO DE CALIDAD - USABILIDAD.........................................................................29TABLA 17: RANGO DE CALIDAD - PORTABILIDAD......................................................................30TABLA 18: RANGO DE CALIDAD - FUNCIONALIDAD...................................................................30TABLA 19: RANGO DE CALIDAD - MANTANIBILIDAD..................................................................30
5
1. INTRODUCCION
1.1. Propósito
Este documento se realiza con el fin de dar una visión general a todas las personas que se encuentran involucradas con los servicios que debe prestar la herramienta de administración de requerimientos.
Dentro del documento de visión se presenta una especificación de la función de cada uno de los stakeholders del proyecto identificando sus necesidades. También se pretende mostrar una descripción general de las diferentes características y restricciones que debe tener la herramienta.
1.2. Alcance
El presente documento describe de manera global las características a tener en cuenta en la herramienta para la administración de requerimientos de los proyectos de las asignaturas de IS y AS de la Pontificia Universidad Javeriana. Dentro de estas características se encuentran los lineamientos esenciales para la generación de los documentos conocidos como Software Requirements Specification (SRS) [5] y Software Architecture Design (SAD) [6].
1.3. Definiciones, acrónimos y abreviaciones
CONCEPTO DESCRIPCION
AS Arquitectura de Software
CRUD Hace referencia a las cuatro acciones que se realizan sobre una base de datos o herramientas en general. Las acciones son:
- Crear- Leer- Actualizar- Borrar
IS Ingeniería de Software
PUJ Pontificia Universidad Javeriana
6
SAD Documento de diseño Arquitectónico [6].
SRS Hace referencia a las siglas del documento conocido como Especificación de requerimientos de software, el cual se encarga de describir cuales son las funcionalidades del software y como se espera que este las desempeñe [5].
Tabla 2: Definiciones, acrónimos y abreviaciones
1.4. Referencias
[1]. Wiegers K, SOFTWARE REQUIREMENTS. Second edition. Microsoft Press ©; 2003.
[2]. The Standish Group. CHAOS summary report [Homepage en internet]. Disponible en: http://www.projectsmart.co.uk/docs/chaos-report.pdf. [Última Fecha de Consulta: Septiembre 23 de 2010]
[3]. IEEE Recommended Practice for Software Requirements Specifications. [Documento en internet]. Disponible en www.kybele.etsii.urjc.es/docencia/IS4/extra/IEEE%20830-1998%20%5BENG%5D.pdf [Última fecha de consuta: Septiembre 23 de 2010]
[4]. ISO 9126. [Documento en Internet] Disponible en: http://www.cis.gsu.edu/~ghubona/cis8300/ISO9126.pdf [Ultima consulta: Septiembre 23 de 2010].
[5]. SearchSoftwareQuality.com Definitions. Software Requirements Specification. [Homepage en Internet]. Disponible en: http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci1243658,00.html. [Última Fecha de Consulta: Septiembre 23 de 2010]
[6]. The Aspect-Oriented Software Architecture Design Portal. Introduction. [Homepage en Internet]. Disponible en: http://trese.cs.utwente.nl/taosad/. [Última Fecha de Consulta: Septiembre 23 de 2010]
7
[7]. Brey, G. Escobar, G. El Rol del Arquitecto de Software. [Presentación en Internet] Universidad Tecnológica Nacional, Argentina. 2005. Disponible en: http://apit.wdfiles.com/local--files/start/06_apit_rol_del_arquitecto.pdf [Fecha de última consulta: 22 de septiembre de 2010].
[8]. Plantilla del documento de Visión. [Documento en Internet]. Disponible en: http://sophia.javeriana.edu.co/~cbustaca/Arquitectura%20Software/Proyectos/Plantillas/1Vision/rup_vision.htm [Fecha de última consulta: 23 de septiembre de 2010].
[9]. Carolina Loaiza, Adrian Otálora, Julián Tenjo. Sistema FarmaCop (Visión) NixSolutions. Febrero 20 de 2010.
[10]. Carlos Jaramillo Ortiz, Juan Gabriel Riveros, Víctor Hugo Villalobos, Laura Catalina Zorro. Sistema suVISA (Visión). RACCOON Inc. Septiembre 29 de 2009.
[11]. Iván Felipe Camero, Andrés Camilo Galvis, Juan Felipe González. Sistema e-K2M (Visión). Solidware. Abril 5 de 2009.
[12]. The Land Software Engineering Centre. Requirements Attributes [Documento en Internet]. 2010. Disponible en: http://www.lsec.dnd.ca/qsd_current_version/sw_eng/di/reqpro_attributes.htm [Ultima fecha de consulta: Septiembre 01 de 2010]
[13]. Wiegers K. When Telepathy Won’t Do: Requirements Engineering Key Practices. [Artículo en Internet]. Disponible en: http://www.processimpact.com/articles/telepathy.html. [Última fecha de consulta: Agosto 15 de 2010]
[14]. IEEE Standard for Software Test Documentation. [Documento en Internet]. Disponible en: http://standards.ieee.org/reading/ieee/std_public/description/se/index.html. [Última fecha de consulta: Octubre 1 de 2010]
[15]. IEEE Standard for Information Technology –Systems Design- Software Design Descriptions.[Documento en Internet]. Disponible en: http://standards.ieee.org/reading/ieee/std_public/description/se/index.html
8
2. POSICIONAMIENTO
2.1. Oportunidad de Negocio
En el año 2009, el Standish Group [2] publicó las diez principales razones por las cuales los proyecto de software no tienen éxito, dentro de éstas existen cinco que se encuentran estrechamente relacionadas con la administración de requerimientos, las razones son:
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]
Desafortunadamente esta situación no solo se ve en el ámbito profesional, también en el ámbito académico. Un ejemplo de esto se refleja en asignaturas como la IS o AS de la PUJ. Por tal motivo, se considera de vital importancia que durante la formación académica y en especial mientras se cursan las asignaturas de IS y AS se dé un especial enfoque sobre la administración de requerimientos.
2.2. Planteamiento del Problema
El Problema Dentro de las asignaturas de IS y AS, no se cuenta con una herramienta, que le permita a los estudiantes gestionar el proceso de administración y uso de los requerimientos.
Afectados Los estudiantes y profesores de las asignaturas de IS y AS de la Pontificia Universidad Javeriana.
Impacto del problema El esfuerzo que deben realizar los estudiantes para construir el documento de especificación en tan poco tiempo, tiene varias implicaciones dentro de las cuales se encuentran:
9
- El proceso de trazabilidad no cuenta con todos los elementos para sustentar el estado de implementación del proyecto en la última entrega.
- Los cambios generan diferentes conflictos, ya que muchas veces no son informados.
- La definición de los tipos de requerimientos que se van a especificar dentro del documento SRS, no siempre es la adecuada.
- La investigación que se realiza es muy superficial y algunas de las actividades que se deben desarrollar en el SRS no se realizan con el debido conocimiento.
- Los procesos como la priorización, la trazabilidad y la verificación se están desarrollando sin que los estudiantes comprendan a cabalidad el por qué y los beneficios que estas actividades conllevan dentro del proyecto.
Una solución adecuada sería Optimizar el proceso de administración de requerimientos teniendo en cuenta:
- Habilidad para definir los atributos que debe tener el requerimiento.
- Establecer la priorización de los requerimientos.
- Mejorar el proceso de trazabilidad de los requerimientos.
- Utilizar un método de visualización de requerimientos, ya sea un reporte escrito o un gráfico, que permita identificar el orden de precedencia y la prioridad de los requerimientos.
Tabla 3: Problema
10
2.3. Enunciado de posición del problema
Para Los estudiantes que necesitan optimizar el proceso de administración de requerimientos en los proyectos de las asignaturas de IS y AS.
Quienes - Los estudiantes y profesores de la asignatura IS.
- Estudiantes y profesores de la asignatura AS.
“nombre herramienta” Es una herramienta que permite la optimización del proceso de administración de software.
Que Permite la definición de los atributos que debe contener un requerimiento, así como los procesos de administración del cambio, trazabilidad, visualización de requerimientos y realización de reportes sobre los requerimientos.
Además debe permitir que se realice un seguimiento al estado de implementación del proyecto.
El producto Permitirá administrar los requerimientos de un proyecto, teniendo en cuenta los procesos de administración del cambio, trazabilidad y visualización de requerimientos.
También facilitará la generación de informes o reportes pertinentes, para la administración del proyecto en general, por ejemplo los reportes de estado del proyecto basados en los requerimientos.
Tabla 4: Definición del problema
11
3. DESCRIPCION DE USUARIOS Y STAKEHOLDERS
3.1. Datos demográficos del Mercado
Los estudiantes de las asignaturas de IS y AS de la Pontificia Universidad Javeriana, según los profesores encargados (ver documento de Análisis de entrevista), han ido mejorando semestre a semestre la especificación de requerimientos que deben realizar en los respectivos proyectos, tanto así que en la asignatura de AS no exigen el documento y asumen que los estudiantes deben realizarla de manera autónoma (ver documento de Análisis de entrevista del Profesor de Arquitectura de Software). Mientras que en la asignatura de IS la exigencia de los diferentes documentos se incrementa cada semestre, sin embargo la administración de requerimientos no recibe la misma atención que la el proceso de especificación, debido al tiempo que se dispone. Por lo tanto, hoy en día se piensa en agilizar ese proceso, con el fin de realizar una correcta administración y no solo quedarse en la especificación.
3.2. Resumen de Stakeholders
Nombre Descripción Responsabilidades
Director de Proyecto Es el encargado de guiar el proceso de Software desde su concepción hasta su implementación (en este caso).
Revisar los diferentes entregables para asegurar la calidad de la investigación y de los diferentes documentos
Sugerir posibles correcciones los entregables para realizar una retroalimentación de los mismos.
Grupo de trabajo Encargado de realizar el proceso de Ingeniería de software para lograr elaborar la herramienta de administración de requerimientos
Realizar el proceso de recolección de requerimientos, a través de entrevistas y encuestas.
Realizar un análisis detallado de las necesidades con su respectiva especificación.
Elaborar el diseño con base en los resultados obtenidos del análisis del sistema.
12
Implementar la herramienta teniendo en cuenta el diseño realizado.
Asegurar la funcionalidad del producto, realizando pruebas unitarias y de integración.
Tabla 5: Resumen de Stakeholders
3.3. Resumen de usuario
Nombre Descripción
Profesores de Ingeniería de Software
Persona que realiza revisiones sobre los diferentes documentos del proyecto entre ellos el SRS del proyecto que se está realizando y retroalimentación sobre ellos. Su interacción con la herramienta se limita a la revisión de los diferentes reportes generados por parte de los estudiantes.
Además serán los encargados de promover esta herramienta entre los estudiantes para agilizar el proceso de administración y así concientizarlos sobre la importancia de realizar este proceso.
Profesores de Arquitectura de Software
Persona que realiza revisiones sobre los diferentes documentos del proyecto, en el último año han omitido la revisión del documento SRS. Su interacción con la herramienta ser limita a la revisión de los diferentes reportes.
Además serán los encargados de promover esta herramienta entre los estudiantes para agilizar el proceso de administración y así concientizarlos sobre la importancia de realizar este proceso.
Estudiantes de Ingeniería de Software
Persona que realiza la especificación de requerimientos en las asignaturas de IS para el proyecto que se desarrolla durante el semestre, el cual es exigido por parte de los profesores.
Dentro del sistema se considera el principal usuario, porque la todas las funcionalidades definidas (ver sección 5. CARACTERISTICAS DEL PRODUCTO), serán utilizadas por él. En esta asignatura el estudiante debe darle más importancia a los requerimientos funcionales.
Estudiantes de Arquitectura Persona que realiza la especificación de requerimientos en las
13
de Software asignaturas de AS para el proyecto que se desarrolla durante el semestre.
Dentro del sistema se considera el principal usuario, porque la todas las funcionalidades definidas (ver sección 5. CARACTERISTICAS DEL PRODUCTO), serán utilizadas por él. En esta asignatura el estudiante debe darle más importancia a los requerimientos no funcionales.
Tabla 6: Resumen de Usuarios
3.4. Ambiente de usuario
La mayoría de los estudiantes, durante la elaboración de un proyecto, utilizan diferentes herramientas para realizar los distintos artefactos a entregar. En la fase de especificación de requerimientos, la herramienta más común son las tablas realizadas en Microsoft Word y Microsoft Excel las cuales ayudan a organizar los requerimientos y así mantenerlos agrupados según como estén clasificados, priorizados ó relacionados con respecto a otros requerimientos o artefactos del proyecto.
Dentro de un grupo de proyecto, todos los integrantes deberían tener interacción con la especificación de requerimientos, ya que brinda una visión detallada sobre las funcionalidades del proyecto. Es por esto que esta interacción se debe mantener con el uso de la herramienta, por lo tanto el número de personas que interactuaran con esta es muy reducido y varía desde 7 hasta 2 ó 3, dependiendo de la asignatura, ya sea IS o AS.
Actualmente los usuarios cuentan con un tiempo aproximado de tres meses para realizar la administración de requerimientos. Este periodo de tiempo se divide entre la especificación y la actualización de los diferentes atributos de los requerimientos.
Con la herramienta se pretende disminuir el tiempo invertido en la administración, de esta forma se logra que el estudiante pueda realizar una buena administración y pueda invertir más tiempo a las demás fases de desarrollo del proyecto.
3.5. Perfil de los Stakeholders
3.5.1. Director del Proyecto
Representante Ing. Miguel Eduardo Torres
14
Descripción Ver sección 3.2. Resumen de Stakeholders
Tipo Profesional con experiencia en gestión de trabajos de grado y proyectos a nivel académico.
Responsabilidades Ver sección 3.2. Resumen de Stakeholders
Criterios de éxito Satisfacción por parte de los usuarios del sistema una vez lanzado el producto debido a su buen funcionamiento.
Participación Aprobación de cronograma, retroalimentación a entregables y sugerencias de bibliografía y temas a tratar.
Tabla 7: Stakeholder - Director de Proyecto
3.5.2. Grupo de Trabajo
Representante Laura Catalina Zorro y Carolina Loaiza Carvajal
Descripción Ver sección 3.2. Resumen de Stakeholders
Tipo Estudiantes con conocimiento en los diferentes procesos de ingeniería de software, procesos de ingeniería de requerimientos y administración de requerimientos.
Responsabilidades Ver sección 3.2. Resumen de Stakeholders
Criterios de éxito Encontrar la mayor cantidad de defectos importantes en los módulos que ya fueron desarrollados tan temprano como sea posible
Participación Realiza planes y ejecutar las verificaciones y validaciones al trabajo de los desarrolladores.
Tabla 8: Stakeholder - Encargado de pruebas
3.6. Perfiles de usuario
3.6.1. Profesores de Ingeniería de Software
Representante Ing. Miguel Eduardo Torres.
15
Descripción Ver sección 3.3. Resumen de usuario.
Tipo Profesor de IS, asignatura en la cual se implantará la herramienta.
Criterios de éxito El producto que se entrega se adapta a las necesidades de la asignatura, es decir agiliza los procesos de identificación, priorización, control de cambios, trazabilidad y validación y verificación de los requerimientos.
Participación Proporciona tiempo para la entrevista y así da a conocer su opinión respecto al producto, desde la asignatura. Tabla 9: Usuario – Profesores Ingeniería de Software
3.6.2. Profesores de Arquitectura de Software
Representante Ing. Jamir Antonio Ávila.
Descripción Ver sección 3.3. Resumen de usuario.
Tipo Profesor de AS, asignatura en la cual se implantará la herramienta.
Criterios de éxito El producto que se entrega se adapta a las necesidades de la asignatura, el cual podrá ser aplicado para agilizar algunos procesos dentro del desarrollo de los proyectos.
Participación Proporciona tiempo para la entrevista y así da a conocer su opinión respecto al producto, desde la asignatura.
Tabla 10: Usuario – Profesores Arquitectura de Software
3.6.3. Estudiantes de Ingeniería de Software
Representante Estudiantes que han cursado IS en semestres anteriores al período 2010 – 3
Descripción Ver sección 3.3. Resumen de usuario
Tipo Estudiantes con conocimiento sobre cómo realizar una especificación de requerimientos y su administración, según la Ingeniería de software
16
tradicional.
Criterios de éxito Los estudiantes pueden integrar la herramienta a su proceso de desarrollo de software, en especial en la especificación de requerimientos, lo cual permite agilizar la administración de estos.
Participación Proporciona información sobre sus necesidades respecto al proceso de administración de requerimientos a través de encuestas.
Tabla 11: Usuario – Estudiante de Ingeniería de Software
3.6.4. Estudiantes de Arquitectura de Software
Representante Estudiantes que han cursado AS en semestres anteriores al período 2010 – 3
Descripción Ver sección 3.3. Resumen de usuario
Tipo Estudiantes con conocimiento sobre cómo realizar una especificación de requerimientos y su administración, según la Ingeniería de Software de software tradicional.
Criterios de éxito Los estudiantes pueden integrar la herramienta a su proceso de desarrollo de software, utilizando el criterio clave de la asignatura, el enfoque a los requerimientos no funcionales.
Participación Proporciona información sobre sus necesidades respecto al proceso de administración de requerimientos a través de encuestas.
Tabla 12: Usuario – Estudiante de Arquitectura de Software
3.7. Necesidades de los Usuarios
Usuario Prioridad Necesidad Solución actual Solución Propuesta
Profesores de la asignatura de Ingeniería de Software
Alta Concientizar a los estudiantes de la importancia de realizar procesos como la administración de requerimientos,
Flexibilidad en la exigencia de algunos procesos concernientes a la administración de requerimientos, como lo son la
Proponer la herramienta de administración de requerimientos para su uso dentro del desarrollo del proyecto de la
17
pero debido al tiempo que se tiene actualmente es casi imposible exigir al estudiante la completa realización de estos procesos.
administración del cambio, debido a que el tiempo de desarrollo es reducido, y el almacenamiento de requerimientos rechazados.
asignatura y revisar los reportes correspondientes o que sean del interés del profesor, con relación a los requerimientos.
Profesores de la asignatura de Arquitectura de Software
Alta La especificación de los requerimientos se realiza en un tiempo muy reducido, debido a que es necesario desarrollar otros artefactos que cuentan con mayor importancia dentro del curso como el documento SAD.
Flexibilidad en la exigencia de estos procesos, hasta el punto de omitirlo, dando por hecho la realización de ellos.
Una herramienta de administración de requerimientos la cual agilice el proceso.
Estudiantes de la asignatura de Ingeniería Software
Alta Agilizar el proceso de administración de requerimientos para poder realizarlo con calidad y ver su utilidad dentro del proceso de desarrollo de software.
Los estudiantes deben diseñar una plantilla, ya sea en Word o en Excel en donde se almacena la información correspondiente a cada requerimiento, proceso que se torna complejo al momento de realizar una actualización o eliminación, ya que se debe buscar en todos
Con ayuda de la herramienta se pueden agilizar procesos de actualización y visualización de requerimientos, facilitando así la toma de decisiones. Además, la administración de requerimientos se ejecutaría a través de todo el proyecto y no solo en la fase de análisis.
18
los artefactos en donde se encuentre el requerimiento.
Estudiantes de la asignatura de Arquitectura de Software.
Alta Agilizar el proceso de administración de requerimientos.
El proceso que se realiza es igual al que realizan los estudiantes de la asignatura de Ingeniería de Software.
Por medio de la herramienta, se podrán agilizar los procesos de la administración de requerimientos como la priorización, control de cambios y la trazabilidad de requerimientos.
Tabla 13: Necesidades de los usuarios
3.8. Alternativas y Competencias
En los últimos semestres, los estudiantes de las asignaturas de IS y AS, han utilizado diferentes herramientas para manipular los requerimientos definidos dentro del proyecto, un ejemplo es Microsoft Office Word y Microsoft Office Excel la cual permite organizarlos en diferentes tablas e ir actualizando, donde cada grupo puede diseñar la plantilla a su gusto, estas herramientas son las mas utilizadas dentro de los grupos de IS y AS. Otra herramienta que pocos estudiantes suelen usar es Enterprise Architect, la cual es de gran utilidad ya que realiza un seguimiento desde la definición del requerimiento hasta el diseño del componente dentro del sistema, permitiendo así mayor eficacia en el proceso de trazabilidad del requerimiento, sin embargo existen diferentes características que impiden realizar una administración de requerimientos completa, para profundizar en las características de esta herramienta ver documento de herramienta Enterprise Architect.
Dentro del mercado existen herramientas libres y con licencia para la administración de requerimientos, las que se obtienen con licencia es una opción considerada poco probable, debido al precio alto que exigen y las herramientas libres que existen poseen algunas de las características deseables dentro del curso sin embargo el código no es abierto por lo tanto es difícil adaptarlo al proceso que siguen las asignaturas, para mayor profundidad sobre este tema ver sección Herramientas en el documento Marco Teórico.
19
4. DESCRIPCION DEL PRODUCTO
Esta sección contiene una descripción simple del producto, cuáles serán sus funcionalidades, las suposiciones y dependencias que se deben tener en cuenta a la hora de utilizar la herramienta y las licencias que se deben adquirir para su correcto funcionamiento.
4.1. Perspectiva del producto
ERMT es un software que le permite a los estudiantes de las asignaturas de IS y AS, agilizar el proceso de administración de requerimientos que se lleva a cabo dentro de los proyectos designados para desarrollar a través del período académico. EL objetivo consiste generar reportes con la información que está relacionada con la especificación de requerimientos y permitirle a los grupos de proyecto tomar decisiones con base a los requerimientos definidos, analizados, agrupados y priorizados.
4.2. Resumen de Capacidades
Capacidad Beneficio para el cliente
Definición de atributos Permite al usuario la definición de atributos que quiere manejar para los requerimientos, durante el proyecto.
Clasificación de requerimientos Permite al usuario agrupar los requerimientos, según su tipo para así poder administrarlos de la mejor forma.
Priorización de requerimientos Permite al usuario ordenar los requerimientos para saber la importancia de un requerimiento frente a otro, ayudando así a la planeación de las fases posteriores.
Administración del cambio Ayuda al usuario a saber los cambios realizados anteriormente y su justificación.
Almacenamiento de requerimientos rechazados
Permite al usuario saber y dar a conocer que requerimientos no alcanzarán a ser cumplidos de acuerdo a la priorización previamente realizada.
Localización de requerimientos Permite al usuario saber si el requerimiento esta en los artefactos del proyecto.
20
Trazabilidad de requerimientos Permite al usuario realizar un seguimiento de los requerimientos desde su origen hasta su validación dentro del proyecto. Además permite que el usuario verifique y actualice el estado de implementación del proyecto.
Validación y Verificación de requerimientos
Apoya el proceso de evaluación de los requerimientos y su especificación para así asegurar que el diseño sea consistente con su especificación y no tener inconvenientes en las etapas posteriores.
Visualización de requerimientos Permite generar un grafo de requerimientos, para que los usuarios puedan tomar decisiones sobre estos, ya que permite identificar de manera grafica rutas criticas, priorización y orden de implementación de los requerimientos.
Generación de reportes Permite al usuario generar diferentes reportes de los resultados del análisis de requerimientos realizado hasta el momento.Tabla 14: Resumen de capacidades
4.3. Suposiciones y Dependencias
4.3.1. Suposiciones
Dentro de la elaboración del proyecto en las asignaturas, los estudiantes deben
realizar la especificación de requerimientos.
Los requerimientos son verificados sintácticamente por los estudiantes, teniendo en
cuenta las recomendaciones descritas por algunos autores, como por ejemplo Ian
Alexander, quien propone ciertas preguntas que se deben realizar para verificar si los
requerimientos son correctos [3].
El proceso de administración de requerimientos requiere de una investigación
exhaustiva por parte del estudiante, por lo tanto la herramienta solo es un artefacto
por medio del cual el estudiante podrá agilizar el proceso y no será la base de su
investigación.
La herramienta solo proveerá informes a cerca de los requerimientos especificados
para la sección 3 del documento SRS, es por esto que los estudiantes deben realizar las
demás secciones de este.
21
La taxonomía utilizada dentro de la especificación de requerimientos será la descrita
en el documento “Marco Teórico”.
Los estudiantes deben seleccionar en la herramienta, los atributos de los
requerimientos a utilizar dentro del documento de especificación.
El proceso de control de cambios, solo estará asociado a las razones por las cuales se
cambia un requerimiento, y no va a contar con un historial de versiones que registre
uno a uno los cambios realizados sobre el requerimiento.
4.3.2. Dependencias
Antes de realizar la administración de requerimientos los estudiantes deben realizar
la investigación correspondiente, para contar con las bases académicas necesarias
para comprender el porqué se está realizando.
Los estudiantes que utilicen la herramienta, deben realizar la recolección de
requerimientos, como actividad previa al uso de esta.
Los estudiantes antes de realizar las actividades disponibles dentro de la herramienta
deberán identificar y especificar los casos de uso del proyecto.
Para elaborar la localización y posteriormente la trazabilidad, los estudiantes deben
definir con antelación los demás artefactos de software involucrados en el desarrollo
del proyecto.
Antes de almacenar un requerimiento que ha sido rechazado, se debe realizar la
priorización de requerimientos.
Para priorizar requerimientos, los estudiantes deben seleccionar uno de los dos
métodos que estarán disponibles en la herramienta. (Método de Wiegers y AHP ver
Documento Marco Teorico sección 2.5.1.2. Priorización)
El tiempo de respuesta de la herramienta (nombre de la herramienta) está ligado al
sistema operativo donde se encuentre instalada.
La herramienta debe funcionar en las máquinas que se utilizan en los laboratorios de
sistemas de la Pontificia Universidad Javeriana.
22
4.4. Licencias e instalación
Ya que la herramienta se desarrollará con el fin de apoyar el proceso de administración de requerimientos de las asignaturas de IS y AS, no se considerará establecer un valor económico para su utilización, por lo que esta herramienta se considera de orden académico y se utilizará en las asignaturas ya mencionadas de la Pontificia Universidad Javeriana.
En cuanto a la instalación de la herramienta, esta se debe encontrar disponible para ser descargada vía Internet.
23
5. CARACTERISTICAS DEL PRODUCTO
5.1. Definición de Atributos
La herramienta debe permitir que los usuarios definan cuales serán los atributos con los que debe contar el requerimiento dentro de la especificación, debido a que estos atributos permiten rastrear el estado de los requerimientos en cualquier etapa del proyecto. Se dice que la herramienta facilitara que el usuario defina cuales son los atributos adecuados dentro de su proyecto, ya que existen requerimientos que debido a su simplicidad, bajo riesgo respecto al cambio ó baja prioridad no necesitan de todos los atributos disponibles en la herramienta, pero si de un conjunto que permita cumplir las características mínimas del proceso de administración de requerimientos [12].
5.2. Clasificación de Requerimientos
La herramienta debe permitir que los usuarios seleccionen el tipo de requerimientos que van a ser especificados, ya que estos permiten realizar la descripción de lo que se va a implementar, los servicios que prestará el producto y cuál es la forma y con qué características se debe desarrollar el producto.
Dentro de los tipos de requerimientos disponibles en la herramienta se encontraran:
- Requerimientos de Negocio.- Requerimientos de Usuario.- Requerimientos de Sistema.
o Requerimientos Funcionales.o Requerimientos No Funcionales.
Requerimientos del Producto. Requerimientos de Funcionalidad. Requerimientos de Fiabilidad. Requerimientos de Usabilidad. Requerimientos de Eficiencia. Requerimientos de Portabilidad. Requerimientos de Mantenibilidad.
Requerimientos Organizacionales. Requerimiento de Entrega Requerimiento de Estándares
Requerimientos Externos.
24
Para mayor información acerca de los tipos de requerimientos, consultar el documento Marco teórico sección 2.2. ¿Qué tipos de requerimientos existen?.
5.3. Priorización de Requerimientos
Dentro del análisis de requerimientos, una actividad que se tiene en cuenta para organizar el cronograma de las fases posteriores, como la implementación, es la priorización de requerimientos, ya que esta permite organizarlos.
Después de realizar este proceso de priorización, los requerimientos resultan organizados según la importancia del requerimiento dentro del proyecto. Proporcionar esa clasificación de requerimientos, después del un análisis, es útil para los grupos de proyecto, ya que se puede utilizar tomar decisiones acerca de que se debe implementar primero, además de permitir que se realice un monitoreo constante del estado del proyecto.
5.4. Administración y Control del Cambio
Debido a que los requerimientos dentro de un proyecto de desarrollo de software cambian, es necesario que la herramienta almacene las razones por las cuales un requerimiento fue modificado, ya sea porque el requerimiento no fue especificado de manera clara, o porque no cumple con el alcance del proyecto, o como suele ocurrir dentro de los proyectos académicos, el requerimiento puede ser interpretado de diferentes maneras, lo cual genera confusiones dentro de los equipos de desarrollo.
5.5. Almacenamiento de Requerimientos Rechazados
Por diferentes motivos, dentro de las especificaciones de software, existen requerimientos a los cuales se les asignan prioridades muy bajas, ya que son requerimientos que no se encuentran dentro del alcance del proyecto, ó por razones de tiempo no pueden ser implementados, es por esto que la herramienta debe cambiar el estado de estos requerimientos por un estado definido como “Rechazado”.
5.6. Localización de Requerimientos
La localización de requerimientos, es una actividad del proceso de administración de requerimientos, que permite asegurar que todos los requerimientos se encuentran asignados a cada componente ó subsistema en el diseño, ya sea Hardware o Software, lo cual es la parte inicial de un proceso de verificación y validación de los requerimientos definidos hasta el momento. Adicional a lo anterior, la localización está bastante relacionada con la trazabilidad, ya que a través de ésta actividad es posible realizarla. Por lo tanto, la herramienta debe facilitar la
25
asignación y búsqueda de los requerimientos frente a otros componentes y subsistemas del proyecto.
5.7. Trazabilidad de Requerimientos
La herramienta, teniendo en cuenta que los usuarios ya han definido los artefactos necesarios para realizar esta actividad (entre estos la definición de casos de uso, manuales de usuario, componentes de código, etc), le debe permitir a los usuarios generar la trazabilidad, tanto hacia adelante como hacia atrás, de los requerimientos, debido a que la trazabilidad, como actividad fundamental de la administración de requerimientos es utilizada para:
Verificar, validar y demostrar a los clientes que todos los requerimientos han sido
implementados.
Afirmar cuál es el estado de implementación del proyecto y cuales requerimientos no han
sido implementados.
Permite realizar los cambios que sean necesarios sobre el proyecto, sin generar conflictos.
(Para más información consultar el documento Marco Teórico sección 2.5.2.1.
Trazabilidad).
5.8. Verificación y Validación de Requerimientos
La verificación y validación de requerimientos es un proceso que permite evaluar la exactitud, completitud y consistencia [11] de los requerimientos definidos hasta el momento. La herramienta debe brindar un apoyo al proceso de verificación de los requerimientos para asegurar que la especificación sea una clara descripción de lo que el sistema debe tener y que la existencia de cada uno de ellos es justificable dentro del proyecto.
5.9. Visualización de los Requerimientos
La herramienta debe permitir al usuario visualizar los requerimientos desde otra perspectiva, en este caso desde una gráfica. La herramienta debe permitir la creación de un grafo de requerimientos que describa las relaciones y dependencias que existen entre ellos y así brindar al usuario un criterio adicional para la toma de decisiones, sobre algún cambio u orden en los requerimientos establecidos.
26
5.10. Generación de Reportes
La herramienta debe permitir al usuario, la generación de reportes ya que es una forma más fácil de mostrar al cliente el resultado de los análisis realizados hasta el momento. Estos reportes pueden contener:
Los atributos de los requerimientos.
Trazabilidad y localización.
Tabla ordenada de los requerimientos (ver sección 5.3. Priorización de Requerimientos).
Grafico de los requerimientos (ver sección 5.9. Visualización de los Requerimientos).
Resultado de la verificación y validación realizada en los requerimientos.
27
6. RESTRICCIONES
En esta sección se indican las diferentes restricciones que tiene el sistema a desarrollar, entre ellas se encuentran las de diseño, de dependencia ó externas.
Para llevar a cabo el desarrollo de la herramienta ERMT es necesario tener en cuenta las siguientes aplicaciones, ya que se tiene previo conocimiento sobre ellas y las licencias se encuentran disponibles dentro de la Pontificia Universidad Javeriana.
Enterprise Architect 7.1
Microsoft Office 2007
Netbeans 6.9.1
También se debe tener en cuenta que se va a utilizar el sistema operativo Windows para utilizar las aplicaciones anteriormente señaladas.
Además de estas restricciones, también se deben considerar las suposiciones y dependencias descritas en la sección 4.3 Suposiciones y Dependencias.
28
7. RANGOS DE CALIDAD
7.1. Eficiencia
Indicador Descripción
Tiempo de Respuesta El tiempo en el cual la herramienta debe dar una respuesta a alguna transacción CRUD, no debe superar los 10 segundos.
Utilización de recursos La herramienta no debe utilizar más de 512 MB de Memoria Principal.
Tabla 15: Rango de calidad - Eficiencia
7.2. Usabilidad
Indicador Descripción
Facilidad de aprendizaje El tiempo que se requerirá para aprender a usar la herramienta no deberá exceder las tres horas.
Facilidad de comprensión La herramienta deberá ser comprensible para todos y cada uno de los estudiantes de tal manera que la encuentre útil dentro del proceso de administración de requerimientos.
Tabla 16: Rango de calidad - Usabilidad
7.3. Portabilidad
Indicador Descripción
Facilidad de Instalación La herramienta se podrá instalar en sistemas operativos como Windows XP y posteriores.
El paquete de instalación se encontrará disponible en Internet.
29
Co-existencia La herramienta debe convivir con los sistemas instalados previamente en los equipos.
Tabla 17: Rango de calidad - Portabilidad
7.4. Funcionalidad
Indicador Descripción
Compatibilidad La herramienta debe ser compatible con aplicación como Microsoft Word 2007 y/o Microsoft Excel 2007, para la generación de reportes.
Interoperabilidad La herramienta debe poder establecer comunicación, de manera confiable, con la base de datos que va a utilizar el sistema.
Tabla 18: Rango de calidad - Funcionalidad
7.5. Mantenibilidad
Indicador Descripción
Modificabilidad La herramienta debe soportar la modificación de componentes sin afectar los demás componentes del sistema.
Administrabilidad La herramienta debe proporcionar las interfaces adecuadas para facilitar la administración del sistema.
Estabilidad La herramienta debe proporcionar estabilidad durante la ejecución del mismo, es decir, cada vez que sea ejecutado por el usuario, éste debe iniciar y responder a las peticiones del usuario.
Tabla 19: Rango de calidad - Mantanibilidad
30
8. PRECEDENCIA Y PRIORIDAD
Después de considerar las necesidades de los clientes (ver Sección 3. Descripción de usuarios y Stakeholders) identificadas en el documento de Análisis de entrevista y teniendo en cuenta que todas las funcionalidades son de alta importancia, se han ordenado estas necesidades descritas en la sección 5, considerando un orden de precedencia necesario para llevar a cabo el desarrollo de la herramienta.
31
Ilustración 1. Precedencia y prioridad.
Definición de Atributos
Clasificación de Requerimientos
Priorización de Requerimientos
Localización de Requerimientos
Trazabilidad de Requerimientos
Administración y Control de Cambios
Visualización de los Requerimientos
Generación de Reportes
Validación y Verificación de Requerimientos
Almacenamiento de Requerimientos
Rechazados
32
9. OTROS REQUERIMIENTOS DEL PRODUCTO
9.1. Estándares aplicados
En general, los estándares que serán utilizados durante el desarrollo de la herramienta (nombre de la herramienta) son todos aquellos estándares de la IEEE relacionados con la implementación de software, dentro de los cuales se encuentran:
Estándar IEEE 830-1998. Recommended Practice For Software Requirements
Specifications, el cual contiene los lineamientos óptimos para realizar una excelente
especificación de requerimientos de software [3].
Estándar IEEE 829-1998. IEEE Standard for Software Test Documentation, el cual describe
el conjunto básico de documentos asociados a las pruebas de software [14].
Estándar IEEE 1016™-2009. IEEE Standard for Information Technology –Systems Design-
Software Design Descriptions, el cual especifica los contenidos requeridos y la
organización de la información contenida en el documento de diseño de software (SDD)
[15].
Estándar IEEE 1063-2001. IEEE Standard for Software User Documentation, El cual provee
los requerimientos mínimos de estructuración, contenido y formato de los documentos
como manuales de usuario y ayudas en línea, tanto físicos como electrónicos.
Además de los estándares IEEE, también se utilizará el estándar ISO 9126, el cual describe seis características mínimas para la calidad de software [4].
9.2. Requerimientos del Sistema
Como se mencionaba en la sección 4.3. Suposiciones y Dependencias, la herramienta debe funcionar principalmente sobre los equipos de las salas de sistemas (facultad de ingeniería de la PUJ), las características de éstos equipos son:
Intel Dual Core a 2.00 GHz
Disco Duro de 40G
Memoria de 1GB
33
Resolución en pantalla de 1024X768 Pixeles.
Sistema Operativo Windows XP
9.3. Requerimientos de Desempeño
Para cargar la herramienta, las maquinas no deberán utilizar más de 512 Mb de Memoria
principal.
El tiempo de respuesta para una solicitud, no debe ser superior a 10 segundos.
9.4. Requerimientos del entorno
La herramienta debe soportar la adición e integración de otros módulos al sistema, en caso de que se desee agregar otra funcionalidad o la modificación de alguna de ellas (ver sección 7.5. Mantenibilidad).
34
10.REQUERIMIENTOS DE DOCUMENTACION
En esta sección se presenta los diferentes métodos de documentación necesarios para que el cliente pueda utilizar el sistema sin ninguna complicación.
10.1. Manual de Usuario
Los usuarios de la herramienta ERMT tendrán disponible un manual de usuario que estará regido por el Estándar IEEE 1063-2001, que particularmente tendrá ítems adicionales que fomentarán la investigación por parte de los estudiantes, además de ser un manual para utilizar la herramienta, tendrá diferentes recomendaciones sobre el proceso de ingeniería de requerimientos para concientizar al estudiante del significado de cada uno de los procesos a seguir, este se encontrará adjunto a la herramienta.
10.2. Ayuda en línea
La herramienta contará, como ya se menciono en la sección 10.1 con un manual de usuario, el cual, además de encontrarse en la herramienta, estará disponible en la página web asignada para la distribución de la herramienta. Adicionalmente se facilitarán lo siguiente:
El documento conocido como “Marco Teórico” el cual provee la base teórica para el
desarrollo de la herramienta y provee información referente al proceso de ingeniería de
requerimientos, el cual es de vital importancia para los estudiantes cuando realizan la
especificación de requerimientos de software.
Un documento que contenga referencias bibliográficas sobre los procesos de
administración de requerimientos, para que los estudiantes realicen una investigación más
completa.
10.3. Guías de instalación, configuración y Archivos Read me
Al igual que el manual de usuario, las guías de instalación y configuración se encontrarán adjuntas al producto, para que cada usuario pueda disponer de ellas en cualquier momento. Estos documentos tendrán un formato específico, el cual manejará diferentes tipos de gráficos para facilitar el seguimiento por parte del usuario.
35
10.4. Etiquetado y empaquetamiento
Para el etiquetado y empaquetamiento del producto, no se tendrá en cuenta ningún estándar específico ya que la herramienta no será comercializada, ya que será de licencia libre y estará disponible en SourceForge, sin embargo los documentos referentes al desarrollo del sistema y al producto como tal tendrán los logotipos pertenecientes al grupo de desarrollo y al producto. [3]
36