erimientos de los proyectos de las asignaturas de Ingeniera De Software y Arquitectura de Soft

DOCUMENTO DE VISIN
VANESA CAROLINA LOAIZA CARVAJAL
LAURA CATALINA ZORRO JIMNEZ

HISTORIAL DE CAMBIOS
FECHA

VERSI
ON

DESCRIPCION

RESPONSABLE

21/09/2010

1.0

Organizacin del Vanesa Carolina Loaiza,

Documento
Laura Catalina Zorro
Secciones 1

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, Vanesa Carolina Loaiza,

10
Laura Catalina Zorro

04/10/2010

1.4

Ultimas
correcciones

Vanesa Carolina Loaiza,

Laura Catalina Zorro

Tabla 1: Historial de cambios

TABLA CONTENIDO
HISTORIAL DE CAMBIOS...................................................................................... 2
TABLA CONTENIDO.............................................................................................. 3
INDICE DE TABLAS.............................................................................................. 6
1. INTRODUCCION............................................................................................. 7
1.1.
1.2.
1.3.
1.4.
2.

POSICIONAMIENTO...................................................................................... 10
2.1.
2.2.
2.3.

3.

Propsito................................................................................................ 7
Alcance................................................................................................... 7
Definiciones, acrnimos y abreviaciones................................................7
Referencias............................................................................................. 8

Oportunidad de Negocio.......................................................................10
Planteamiento del Problema.................................................................10
Enunciado de posicin del problema....................................................11

DESCRIPCION DE USUARIOS Y STAKEHOLDERS..........................................13

3.1.
3.2.
3.3.
3.4.
3.5.

Datos demogrficos del Mercado.........................................................13

Resumen de Stakeholders....................................................................13
Resumen de usuario.............................................................................14
Ambiente de usuario............................................................................ 15
Perfil de los Stakeholders.....................................................................15

3.5.1.
3.5.2.
3.6.

Perfiles de usuario................................................................................ 16

3.6.1.
3.6.2.
3.6.3.
3.6.4.
3.7.
3.8.
4.

Director del Proyecto......................................................................15

Grupo de Trabajo............................................................................16

Profesores de Ingeniera de Software.............................................16

Profesores de Arquitectura de Software.........................................17
Estudiantes de Ingeniera de Software...........................................17
Estudiantes de Arquitectura de Software.......................................18

Necesidades de los Usuarios................................................................18

Alternativas y Competencias................................................................20

DESCRIPCION DEL PRODUCTO....................................................................21

4.1.
4.2.

Perspectiva del producto......................................................................21

Resumen de Capacidades....................................................................21

4.3.

Suposiciones y Dependencias..............................................................22

4.3.1.
4.3.2.
4.4.
5.

Suposiciones.................................................................................. 22
Dependencias................................................................................23

Licencias e instalacin..........................................................................24

CARACTERISTICAS DEL PRODUCTO............................................................25

5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
5.7.
5.8.
5.9.
5.10.

6.
7.

Definicin de Atributos.........................................................................25
Clasificacin de Requerimientos...........................................................25
Priorizacin de Requerimientos............................................................26
Administracin y Control del Cambio....................................................26
Almacenamiento de Requerimientos Rechazados................................26
Localizacin de Requerimientos...........................................................26
Trazabilidad de Requerimientos............................................................27
Verificacin y Validacin de Requerimientos.......................................27
Visualizacin de los Requerimientos.....................................................27
Generacin de Reportes....................................................................28

RESTRICCIONES.......................................................................................... 29
RANGOS DE CALIDAD..................................................................................30
7.1.
7.2.
7.3.
7.4.
7.5.

8.
9.

Eficiencia.............................................................................................. 30
Usabilidad............................................................................................. 30
Portabilidad.......................................................................................... 30
Funcionalidad....................................................................................... 31
Mantenibilidad...................................................................................... 31

PRECEDENCIA Y PRIORIDAD........................................................................32
OTROS REQUERIMIENTOS DEL PRODUCTO.................................................34
9.1.
9.2.
9.3.
9.4.

10.

Estndares aplicados............................................................................34
Requerimientos del Sistema.................................................................34
Requerimientos de Desempeo............................................................35
Requerimientos del entorno.................................................................35
REQUERIMIENTOS DE DOCUMENTACION.................................................36

10.1.
10.2.
10.3.
10.4.

Manual de Usuario.............................................................................36
Ayuda en lnea...................................................................................36
Guas de instalacin, configuracin y Archivos Read me...................36
Etiquetado y empaquetamiento........................................................37

INDICE DE TABLAS
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA

1: HISTORIAL DE CAMBIOS....................................................................................2
2: DEFINICIONES, ACRNIMOS Y ABREVIACIONES..............................................................7
3: PROBLEMA...............................................................................................10
4: DEFINICIN DEL PROBLEMA...............................................................................11
5: RESUMEN DE STAKEHOLDERS.............................................................................13
6: RESUMEN DE USUARIOS..................................................................................14
7: STAKEHOLDER - DIRECTOR DE PROYECTO.................................................................15
8: STAKEHOLDER - ENCARGADO DE PRUEBAS................................................................15
9: USUARIO PROFESORES INGENIERA DE SOFTWARE.......................................................16
10: USUARIO PROFESORES ARQUITECTURA DE SOFTWARE..................................................16
11: USUARIO ESTUDIANTE DE INGENIERA DE SOFTWARE...................................................17
12: USUARIO ESTUDIANTE DE ARQUITECTURA DE SOFTWARE...............................................17
13: NECESIDADES DE LOS USUARIOS.........................................................................19
14: RESUMEN DE CAPACIDADES..............................................................................21
15: RANGO DE CALIDAD - EFICIENCIA.......................................................................29
16: RANGO DE CALIDAD - USABILIDAD......................................................................29
17: RANGO DE CALIDAD - PORTABILIDAD....................................................................30
18: RANGO DE CALIDAD - FUNCIONALIDAD..................................................................30
19: RANGO DE CALIDAD - MANTANIBILIDAD..................................................................30

1. INTRODUCCION
1.1. Propsito
Este documento se realiza con el fin de dar una visin general a todas las personas que
se encuentran involucradas con los servicios que debe prestar la herramienta de
administracin de requerimientos.
Dentro del documento de visin se presenta una especificacin de la funcin de cada uno
de los stakeholders del proyecto identificando sus necesidades. Tambin se pretende
mostrar una descripcin general de las diferentes caractersticas y restricciones que debe
tener la herramienta.

1.2. Alcance
El presente documento describe de manera global las caractersticas a tener en cuenta
en la herramienta para la administracin de requerimientos de los proyectos de las
asignaturas de IS y AS de la Pontificia Universidad Javeriana. Dentro de estas
caractersticas se encuentran los lineamientos esenciales para la generacin de los
documentos conocidos como Software Requirements Specification (SRS) [5] y Software
Architecture Design (SAD) [6].

1.3. Definiciones, acrnimos 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

Ingeniera de Software

PUJ

Pontificia Universidad Javeriana

SAD

Documento de diseo Arquitectnico [6].

SRS

Hace referencia a las siglas del documento conocido

como Especificacin de requerimientos de software, el
cual se encarga de describir cuales son las
funcionalidades del software y como se espera que
este las desempee [5].

Tabla 2: Definiciones, acrnimos 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%208301998%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].
Brey, G. Escobar, G. El Rol del Arquitecto de Software. [Presentacin en Internet]
Universidad Tecnolgica 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 Visin. [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 Otlora, Julin Tenjo. Sistema FarmaCop (Visin)
NixSolutions. Febrero 20 de 2010.

[10].
Carlos Jaramillo Ortiz, Juan Gabriel Riveros, Vctor Hugo Villalobos, Laura Catalina
Zorro. Sistema suVISA (Visin). RACCOON Inc. Septiembre 29 de 2009.

[11].
Ivn Felipe Camero, Andrs Camilo Galvis, Juan Felipe Gonzlez. Sistema e-K 2M
(Visin). 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 Wont Do:
Requirements Engineering Key Practices. [Artculo 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

2. POSICIONAMIENTO
2.1. Oportunidad de Negocio
En el ao 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 administracin de requerimientos, las razones son:

Escasa comunicacin con el Cliente.

Claridad en los objetivos del proyecto.

Continuos Cambios en los requerimientos y en sus especificaciones, los cuales

derivan en prdida de control y monitoreo sobre estos

Poca participacin de los usuarios finales.

Requerimientos incompletos, al igual que sus especificaciones. [2]

Desafortunadamente esta situacin no solo se ve en el mbito profesional, tambin en el

mbito acadmico. 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 formacin acadmica
y en especial mientras se cursan las asignaturas de IS y AS se d un especial enfoque
sobre la administracin 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 administracin y uso de
los requerimientos.

Afectados

Los estudiantes y profesores de las

asignaturas de IS y AS de la Pontificia

10

Universidad Javeriana.
Impacto del problema

Una solucin adecuada sera

El esfuerzo que deben realizar los

estudiantes
para
construir
el
documento de especificacin en tan
poco
tiempo,
tiene
varias
implicaciones dentro de las cuales se
encuentran:
- El proceso de trazabilidad no
cuenta con todos los elementos
para sustentar el estado de
implementacin del proyecto en
la ltima entrega.
-

Los cambios generan diferentes

conflictos, ya que muchas veces
no son informados.

La definicin de los tipos de

requerimientos que se van a
especificar dentro del
documento SRS, no siempre es
la adecuada.

La investigacin 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

priorizacin, la trazabilidad y la
verificacin se estn
desarrollando sin que los
estudiantes comprendan a
cabalidad el por qu y los
beneficios que estas actividades
conllevan dentro del proyecto.

Optimizar el proceso de administracin

11

de requerimientos teniendo en cuenta:

-

Habilidad
para
definir
los
atributos que debe tener el
requerimiento.

Establecer la priorizacin de los

requerimientos.

Mejorar
el
trazabilidad
requerimientos.

Utilizar
un
mtodo
de
visualizacin de requerimientos,
ya sea un reporte escrito o un
grfico, que permita identificar
el orden de precedencia y la
prioridad de los requerimientos.

proceso
de

de
los

Tabla 3: Problema

2.3. Enunciado de posicin del problema

Para

Quienes

nombre herramienta

Los
estudiantes
que
necesitan
optimizar
el
proceso
de
administracin de requerimientos en
los proyectos de las asignaturas de IS
y AS.
-

Los estudiantes y profesores de

la asignatura IS.

Estudiantes y profesores de la
asignatura AS.

Es una herramienta que permite la

optimizacin
del
proceso
de
administracin de software.

12

Que

Permite la definicin de los atributos

que debe contener un requerimiento,
as
como
los
procesos
de
administracin
del
cambio,
trazabilidad,
visualizacin
de
requerimientos
y
realizacin
de
reportes sobre los requerimientos.
Adems debe permitir que se realice
un
seguimiento
al
estado
de
implementacin del proyecto.

El producto

Permitir
administrar
los
requerimientos
de
un
proyecto,
teniendo en cuenta los procesos de
administracin
del
cambio,
trazabilidad
y
visualizacin
de
requerimientos.
Tambin facilitar la generacin de
informes o reportes pertinentes, para
la administracin del proyecto en
general, por ejemplo los reportes de
estado del proyecto basados en los
requerimientos.
Tabla 4: Definicin del problema

13

3. DESCRIPCION DE USUARIOS Y STAKEHOLDERS

3.1. Datos demogrficos del Mercado
Los estudiantes de las asignaturas de IS y AS de la Pontificia Universidad Javeriana, segn
los profesores encargados (ver documento de Anlisis de entrevista), han ido mejorando
semestre a semestre la especificacin 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 autnoma (ver documento de
Anlisis 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 administracin de requerimientos no recibe la misma atencin que la el
proceso de especificacin, debido al tiempo que se dispone. Por lo tanto, hoy en da se
piensa en agilizar ese proceso, con el fin de realizar una correcta administracin y no solo
quedarse en la especificacin.

3.2. Resumen de Stakeholders

Nombre
Director de Proyecto

Grupo de trabajo

Descripcin
Es el encargado de
guiar el proceso de
Software
desde
su
concepcin hasta su
implementacin
(en
este caso).

Encargado de realizar
el
proceso
de
Ingeniera de software
para lograr elaborar la
herramienta
de

Responsabilidades

Revisar los diferentes

entregables
para
asegurar la calidad de
la investigacin y de
los
diferentes
documentos

Sugerir
posibles
correcciones
los
entregables
para
realizar
una
retroalimentacin
de
los mismos.

Realizar el proceso de
recoleccin
de
requerimientos,
a
travs de entrevistas y
encuestas.

14

administracin
requerimientos

de

Realizar un anlisis
detallado
de
las
necesidades con su
respectiva
especificacin.

Elaborar el diseo con

base en los resultados
obtenidos del anlisis
del sistema.

Implementar
la
herramienta teniendo
en cuenta el diseo
realizado.

Asegurar
la
funcionalidad
del
producto,
realizando
pruebas unitarias y de
integracin.

Tabla 5: Resumen de Stakeholders

3.3. Resumen de usuario

Nombre

Descripcin

Profesores
de Persona que realiza revisiones sobre los diferentes
Ingeniera de Software documentos del proyecto entre ellos el SRS del
proyecto que se est realizando y retroalimentacin
sobre ellos. Su interaccin con la herramienta se
limita a la revisin de los diferentes reportes
generados por parte de los estudiantes.
Adems sern los encargados de promover esta
herramienta entre los estudiantes para agilizar el
proceso de administracin y as concientizarlos sobre
la importancia de realizar este proceso.
Profesores
Arquitectura
Software

de Persona que realiza revisiones sobre los diferentes

de documentos del proyecto, en el ltimo ao han
omitido la revisin del documento SRS. Su interaccin
15

con la herramienta ser limita a la revisin de los

diferentes reportes.
Adems sern los encargados de promover esta
herramienta entre los estudiantes para agilizar el
proceso de administracin y as concientizarlos sobre
la importancia de realizar este proceso.
Estudiantes
de Persona que realiza la especificacin
de
Ingeniera de Software 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
seccin 5. CARACTERISTICAS DEL PRODUCTO), sern
utilizadas por l. En esta asignatura el estudiante
debe darle ms importancia a los requerimientos
funcionales.
Estudiantes
Arquitectura
Software

de Persona que realiza la especificacin

de
de requerimientos en las 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
seccin 5. CARACTERISTICAS DEL PRODUCTO), sern
utilizadas por l. En esta asignatura el estudiante
debe darle ms importancia a los requerimientos no
funcionales.
Tabla 6: Resumen de Usuarios

3.4. Ambiente de usuario

La mayora de los estudiantes, durante la elaboracin de un proyecto, utilizan diferentes
herramientas para realizar los distintos artefactos a entregar. En la fase de especificacin
de requerimientos, la herramienta ms comn son las tablas realizadas en Microsoft Word
y Microsoft Excel las cuales ayudan a organizar los requerimientos y as mantenerlos
agrupados segn como estn clasificados, priorizados relacionados con respecto a otros
requerimientos o artefactos del proyecto.
16

Dentro de un grupo de proyecto, todos los integrantes deberan tener interaccin con la
especificacin de requerimientos, ya que brinda una visin detallada sobre
las
funcionalidades del proyecto. Es por esto que esta interaccin se debe mantener con el
uso de la herramienta, por lo tanto el nmero de personas que interactuaran con esta es
muy reducido y vara 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 administracin de requerimientos. Este periodo de tiempo se divide entre la
especificacin y la actualizacin de los diferentes atributos de los requerimientos.
Con la herramienta se pretende disminuir el tiempo invertido en la administracin, de
esta forma se logra que el estudiante pueda realizar una buena administracin y pueda
invertir ms tiempo a las dems fases de desarrollo del proyecto.

3.5. Perfil de los Stakeholders

3.5.1.

Director del Proyecto

Representante

Ing. Miguel Eduardo Torres

Descripcin

Ver seccin 3.2. Resumen de Stakeholders

Tipo

Profesional con experiencia en gestin de trabajos de

grado y proyectos a nivel acadmico.

Responsabilidade
s

Ver seccin 3.2. Resumen de Stakeholders

Criterios de xito

Satisfaccin por parte de los usuarios del sistema una

vez lanzado el producto debido a su
buen
funcionamiento.

Participacin

Aprobacin
de
cronograma,
retroalimentacin
a
entregables y sugerencias de bibliografa y temas a
tratar.
Tabla 7: Stakeholder - Director de Proyecto

17

3.5.2.

Grupo de Trabajo

Representante

Laura Catalina Zorro y Carolina Loaiza Carvajal

Descripcin

Ver seccin 3.2. Resumen de Stakeholders

Tipo

Estudiantes con conocimiento en los diferentes procesos

de ingeniera de software, procesos de ingeniera de
requerimientos y administracin de requerimientos.

Responsabilidade
s

Ver seccin 3.2. Resumen de Stakeholders

Criterios de xito

Encontrar la mayor cantidad de defectos importantes en

los mdulos que ya fueron desarrollados tan temprano
como sea posible

Participacin

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 Ingeniera de Software

Representante

Ing. Miguel Eduardo Torres.

Descripcin

Ver seccin 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
identificacin,
priorizacin,
control
de
cambios,
trazabilidad y validacin y verificacin de los
requerimientos.

18

Participacin

Proporciona tiempo para la entrevista y as da a conocer

su opinin respecto al producto, desde la asignatura.
Tabla 9: Usuario Profesores Ingeniera de Software

3.6.2.

Profesores de Arquitectura de Software

Representante

Ing. Jamir Antonio vila.

Descripcin

Ver seccin 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.

Participacin

Proporciona tiempo para la entrevista y as da a conocer

su opinin respecto al producto, desde la asignatura.
Tabla 10: Usuario Profesores Arquitectura de Software

3.6.3.

Estudiantes de Ingeniera de Software

Representante

Estudiantes que han cursado IS en semestres anteriores

al perodo 2010 3

Descripcin

Ver seccin 3.3. Resumen de usuario

Tipo

Estudiantes con conocimiento sobre cmo realizar una

especificacin de requerimientos y su administracin,
segn la Ingeniera de software tradicional.

Criterios de xito

Los estudiantes pueden integrar la herramienta a su

proceso de desarrollo de software, en especial en la
especificacin de requerimientos, lo cual permite agilizar
la administracin de estos.
19

Participacin

Proporciona informacin sobre sus necesidades respecto

al proceso de administracin de requerimientos a travs
de encuestas.
Tabla 11: Usuario Estudiante de Ingeniera de Software

3.6.4.

Estudiantes de Arquitectura de Software

Representante

Estudiantes que han cursado AS en semestres anteriores

al perodo 2010 3

Descripcin

Ver seccin 3.3. Resumen de usuario

Tipo

Estudiantes con conocimiento sobre cmo realizar una

especificacin de requerimientos y su administracin,
segn la Ingeniera 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.

Participacin

Proporciona informacin sobre sus necesidades respecto

al proceso de administracin de requerimientos a travs
de encuestas.
Tabla 12: Usuario Estudiante de Arquitectura de Software

3.7. Necesidades de los Usuarios

Usuario

Priorid
ad

Profesores de Alta
la asignatura
de Ingeniera
de Software

Necesidad

Solucin
actual

Solucin
Propuesta

Concientizar a
los
estudiantes
de
la
importancia
de
realizar
procesos
como
la

Flexibilidad en
la
exigencia
de
algunos
procesos
concernientes
a
la
administracin
de

Proponer
la
herramienta
de
administracin de
requerimientos
para
su
uso
dentro
del
desarrollo
del
proyecto de la
20

administraci
n
de
requerimiento
s, pero debido
al tiempo que
se
tiene
actualmente
es
casi
imposible
exigir
al
estudiante la
completa
realizacin de
estos
procesos.

requerimiento
s, como lo son
la
administracin
del
cambio,
debido a que
el tiempo de
desarrollo es
reducido, y el
almacenamien
to
de
requerimiento
s rechazados.

asignatura
y
revisar
los
reportes
correspondientes
o que sean del
inters
del
profesor,
con
relacin
a
los
requerimientos.

Profesores de Alta
la asignatura
de
Arquitectura
de Software

La
especificacin
de
los
requerimiento
s 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
realizacin de
ellos.

Una herramienta
de administracin
de requerimientos
la cual agilice el
proceso.

Estudiantes
Alta
de
la
asignatura de
Ingeniera
Software

Agilizar
el
proceso
de
administraci
n
de
requerimiento

Los
estudiantes
deben disear
una plantilla,
ya
sea
en

Con ayuda de la
herramienta
se
pueden
agilizar
procesos
de
actualizacin
y
21

Estudiantes
Alta
de
la
asignatura de
Arquitectura
de Software.

s para poder
realizarlo con
calidad y ver
su
utilidad
dentro
del
proceso
de
desarrollo de
software.

Word
o
en
Excel
en
donde
se
almacena
la
informacin
correspondien
te
a
cada
requerimiento,
proceso
que
se
torna
complejo
al
momento de
realizar
una
actualizacin o
eliminacin,
ya
que
se
debe
buscar
en todos los
artefactos en
donde
se
encuentre
el
requerimiento.

visualizacin
de
requerimientos,
facilitando as la
toma
de
decisiones.
Adems,
la
administracin de
requerimientos se
ejecutara
a
travs de todo el
proyecto y no solo
en la fase de
anlisis.

Agilizar
el
proceso
de
administraci
n
de
requerimiento
s.

El proceso que
se realiza es
igual al que
realizan
los
estudiantes de
la asignatura
de Ingeniera
de Software.

Por medio de la
herramienta,
se
podrn agilizar los
procesos de la
administracin de
requerimientos
como
la
priorizacin,
control
de
cambios
y la
trazabilidad
de
requerimientos.

Tabla 13: Necesidades de los usuarios

22

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 disear 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 definicin del requerimiento hasta el
diseo del componente dentro del sistema, permitiendo as mayor eficacia en el proceso
de trazabilidad del requerimiento, sin embargo existen diferentes caractersticas que
impiden realizar una administracin de requerimientos completa, para profundizar en las
caractersticas de esta herramienta ver documento de herramienta Enterprise Architect.
Dentro del mercado existen herramientas libres y con licencia para la administracin de
requerimientos, las que se obtienen con licencia es una opcin considerada poco
probable, debido al precio alto que exigen y las herramientas libres que existen poseen
algunas de las caractersticas deseables dentro del curso sin embargo el cdigo no es
abierto por lo tanto es difcil adaptarlo al proceso que siguen las asignaturas, para mayor
profundidad sobre este tema ver seccin Herramientas en el documento Marco Terico.

23

4. DESCRIPCION DEL PRODUCTO

Esta seccin contiene una descripcin simple del producto, cules sern 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 administracin de requerimientos que se lleva a cabo dentro de los
proyectos designados para desarrollar a travs del perodo acadmico. EL objetivo
consiste generar reportes con la informacin que est relacionada con la especificacin
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
Definicin de atributos

Beneficio para el cliente

Permite al usuario la definicin de atributos que
quiere manejar para los requerimientos, durante
el proyecto.

Clasificacin
requerimientos

de Permite al usuario agrupar los requerimientos,

segn su tipo para as poder administrarlos de la
mejor forma.

Priorizacin
requerimientos

de Permite al usuario ordenar los requerimientos

para saber la importancia de un requerimiento
frente a otro, ayudando as a la planeacin de
las fases posteriores.

Administracin
cambio

del Ayuda al usuario a saber los cambios realizados

anteriormente y su justificacin.

Almacenamiento
requerimientos

de Permite al usuario saber y dar a conocer que

requerimientos no alcanzarn a ser cumplidos
24

rechazados

de acuerdo
realizada.

la

priorizacin

previamente

Localizacin
requerimientos

de Permite al usuario saber si el requerimiento esta

en los artefactos del proyecto.

Trazabilidad
requerimientos

de Permite al usuario realizar un seguimiento de los

requerimientos desde su origen hasta su
validacin dentro del proyecto. Adems permite
que el usuario verifique y actualice el estado de
implementacin del proyecto.

Validacin y Verificacin Apoya el proceso de evaluacin de

de requerimientos
requerimientos y su especificacin para
asegurar que el diseo sea consistente con
especificacin y no tener inconvenientes en
etapas posteriores.
Visualizacin
requerimientos

los
as
su
las

de Permite generar un grafo de requerimientos,

para que los usuarios puedan tomar decisiones
sobre estos, ya que permite identificar de
manera grafica rutas criticas, priorizacin y
orden de implementacin de los requerimientos.

Generacin de reportes

Permite al usuario generar diferentes reportes de

los resultados del anlisis de requerimientos
realizado hasta el momento.
Tabla 14: Resumen de capacidades

4.3. Suposiciones y Dependencias

4.3.1.

Suposiciones

Dentro de la elaboracin del proyecto en las asignaturas, los estudiantes deben

realizar la especificacin de requerimientos.

Los requerimientos son verificados sintcticamente por los estudiantes,

teniendo en cuenta las recomendaciones descritas por algunos autores, como

25

por ejemplo Ian Alexander, quien propone ciertas preguntas que se deben
realizar para verificar si los requerimientos son correctos [3].

El proceso de administracin de requerimientos requiere de una investigacin

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 investigacin.

La herramienta solo proveer informes a cerca de los requerimientos

especificados para la seccin 3 del documento SRS, es por esto que los
estudiantes deben realizar las dems secciones de este.

La taxonoma utilizada dentro de la especificacin de requerimientos ser la

descrita en el documento Marco Terico.

Los estudiantes deben seleccionar en la herramienta, los atributos de los

requerimientos a utilizar dentro del documento de especificacin.

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 administracin de requerimientos los estudiantes deben

realizar la investigacin correspondiente, para contar con las bases acadmicas
necesarias para comprender el porqu se est realizando.

Los estudiantes que utilicen la herramienta, deben realizar la recoleccin de

requerimientos, como actividad previa al uso de esta.

Los estudiantes antes de realizar las actividades disponibles dentro de la

herramienta debern identificar y especificar los casos de uso del proyecto.
26

Para elaborar la localizacin y posteriormente la trazabilidad, los estudiantes

deben definir con antelacin los dems artefactos de software involucrados en
el desarrollo del proyecto.

Antes de almacenar un requerimiento que ha sido rechazado, se debe realizar

la priorizacin de requerimientos.

Para priorizar requerimientos, los estudiantes deben seleccionar uno de los dos
mtodos que estarn disponibles en la herramienta. (Mtodo de Wiegers y AHP
ver Documento Marco Teorico seccin 2.5.1.2. Priorizacin)

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 mquinas que se utilizan en los

laboratorios de sistemas de la Pontificia Universidad Javeriana.

4.4. Licencias e instalacin

Ya que la herramienta se desarrollar con el fin de apoyar el proceso de administracin
de requerimientos de las asignaturas de IS y AS, no se considerar establecer un valor
econmico para su utilizacin, por lo que esta herramienta se considera de orden
acadmico y se utilizar en las asignaturas ya mencionadas de la Pontificia Universidad
Javeriana.
En cuanto a la instalacin de la herramienta, esta se debe encontrar disponible para ser
descargada va Internet.

27

5. CARACTERISTICAS DEL PRODUCTO

5.1. Definicin de Atributos
La herramienta debe permitir que los usuarios definan cuales sern los atributos con los
que debe contar el requerimiento dentro de la especificacin, 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
caractersticas mnimas del proceso de administracin de requerimientos [12].

5.2. Clasificacin 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 descripcin de lo que se va a
implementar, los servicios que prestar el producto y cul es la forma y con qu
caractersticas 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.

Requerimientos No Funcionales.

Requerimientos del Producto.

Requerimientos de Funcionalidad.

Requerimientos de Fiabilidad.

Requerimientos de Usabilidad.

28

Requerimientos de Eficiencia.

Requerimientos de Portabilidad.

Requerimientos de Mantenibilidad.

Requerimientos Organizacionales.

Requerimiento de Entrega

Requerimiento de Estndares

Requerimientos Externos.

Para mayor informacin acerca de los tipos de requerimientos, consultar el documento

Marco terico seccin 2.2. Qu tipos de requerimientos existen?.

5.3. Priorizacin de Requerimientos

Dentro del anlisis de requerimientos, una actividad que se tiene en cuenta para
organizar el cronograma de las fases posteriores, como la implementacin, es la
priorizacin de requerimientos, ya que esta permite organizarlos.
Despus de realizar este proceso de priorizacin, los requerimientos resultan organizados
segn la importancia del requerimiento dentro del proyecto. Proporcionar esa
clasificacin de requerimientos, despus del un anlisis, es til para los grupos de
proyecto, ya que se puede utilizar tomar decisiones acerca de que se debe implementar
primero, adems de permitir que se realice un monitoreo constante del estado del
proyecto.

5.4. Administracin 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 acadmicos, el requerimiento puede ser interpretado de
diferentes maneras, lo cual genera confusiones dentro de los equipos de desarrollo.

29

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. Localizacin de Requerimientos

La localizacin de requerimientos, es una actividad del proceso de administracin de
requerimientos, que permite asegurar que todos los requerimientos se encuentran
asignados a cada componente subsistema en el diseo, ya sea Hardware o Software,
lo cual es la parte inicial de un proceso de verificacin y validacin de los requerimientos
definidos hasta el momento. Adicional a lo anterior, la localizacin est bastante
relacionada con la trazabilidad, ya que a travs de sta actividad es posible realizarla.
Por lo tanto, la herramienta debe facilitar la asignacin y bsqueda 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 definicin de casos de uso,
manuales de usuario, componentes de cdigo, etc), le debe permitir a los usuarios
generar la trazabilidad, tanto hacia adelante como hacia atrs, de los requerimientos,
debido a que la trazabilidad, como actividad fundamental de la administracin de
requerimientos es utilizada para:

Verificar, validar y demostrar a los clientes que todos los requerimientos han sido

implementados.
Afirmar cul es el estado de implementacin del proyecto y cuales requerimientos

no han sido implementados.

Permite realizar los cambios que sean necesarios sobre el proyecto, sin generar
conflictos. (Para ms informacin consultar el documento Marco Terico seccin
2.5.2.1. Trazabilidad).

30

5.8. Verificacin y Validacin de Requerimientos

La verificacin y validacin 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 verificacin de los
requerimientos para asegurar que la especificacin sea una clara descripcin de lo que el
sistema debe tener y que la existencia de cada uno de ellos es justificable dentro del
proyecto.

5.9. Visualizacin de los Requerimientos

La herramienta debe permitir al usuario visualizar los requerimientos desde otra
perspectiva, en este caso desde una grfica. La herramienta debe permitir la creacin 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 algn
cambio u orden en los requerimientos establecidos.

5.10.

Generacin de Reportes

La herramienta debe permitir al usuario, la generacin de reportes ya que es una forma

ms fcil de mostrar al cliente el resultado de los anlisis realizados hasta el momento.
Estos reportes pueden contener:

Los atributos de los requerimientos.

Trazabilidad y localizacin.
Tabla ordenada de los requerimientos

Requerimientos).
Grafico de los

Requerimientos).
Resultado de la verificacin y validacin realizada en los requerimientos.

requerimientos

(ver

(ver

seccin

seccin

5.9.

5.3.

Priorizacin

Visualizacin

31

de

de
los

6. RESTRICCIONES
En esta seccin se indican las diferentes restricciones que tiene el sistema a desarrollar,
entre ellas se encuentran las de diseo, 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

Tambin se debe tener en cuenta que se va a utilizar el sistema operativo Windows para
utilizar las aplicaciones anteriormente sealadas.
Adems de estas restricciones, tambin se deben considerar las suposiciones y
dependencias descritas en la seccin 4.3 Suposiciones y Dependencias.

32

7. RANGOS DE CALIDAD
7.1. Eficiencia
Indicador

Descripcin

Tiempo de Respuesta

El tiempo en el cual la herramienta

debe dar una respuesta a alguna
transaccin CRUD, no debe superar
los 10 segundos.

Utilizacin de recursos

La herramienta no debe utilizar ms

de 512 MB de Memoria Principal.
Tabla 15: Rango de calidad - Eficiencia

7.2. Usabilidad
Indicador

Descripcin

Facilidad de aprendizaje

El tiempo que se requerir para

aprender a usar la herramienta no
deber exceder las tres horas.

Facilidad de comprensin

La
herramienta
deber
ser
comprensible para todos y cada uno
de los estudiantes de tal manera que
la encuentre til dentro del proceso
de administracin de requerimientos.

Tabla 16: Rango de calidad - Usabilidad

7.3. Portabilidad
Indicador
Facilidad de Instalacin

Descripcin

La herramienta se podr
instalar
en
sistemas
operativos como Windows
XP y posteriores.

El paquete de instalacin se
33

encontrar
Internet.

Co-existencia

disponible

La herramienta debe convivir con los

sistemas instalados previamente en
los equipos.
Tabla 17: Rango de calidad - Portabilidad

7.4. Funcionalidad
Indicador

Descripcin

Compatibilidad

La herramienta debe ser compatible con

aplicacin como Microsoft Word 2007 y/o
Microsoft Excel 2007, para la generacin de
reportes.

Interoperabilidad

La herramienta debe poder establecer

comunicacin, de manera confiable, con la
base de datos que va a utilizar el sistema.
Tabla 18: Rango de calidad - Funcionalidad

7.5. Mantenibilidad
Indicador

en

Descripcin

Modificabilidad

La herramienta debe soportar la modificacin

de componentes sin afectar los dems
componentes del sistema.

Administrabilidad

La
herramienta
debe
proporcionar
interfaces
adecuadas
para
facilitar
administracin del sistema.

Estabilidad

La herramienta debe proporcionar estabilidad

durante la ejecucin del mismo, es decir, cada
vez que sea ejecutado por el usuario, ste
debe iniciar y responder a las peticiones del

las
la

34

usuario.
Tabla 19: Rango de calidad - Mantanibilidad

35

8. PRECEDENCIA Y PRIORIDAD
Despus de considerar las necesidades de los clientes (ver Seccin 3. Descripcin de
usuarios y Stakeholders) identificadas en el documento de Anlisis de entrevista y
teniendo en cuenta que todas las funcionalidades son de alta importancia, se han
ordenado estas necesidades descritas en la seccin 5, considerando un orden de
precedencia necesario para llevar a cabo el desarrollo de la herramienta.

36

Definicin de Atributos

Clasificacin de
Requerimientos

Priorizacin de
Requerimientos

Localizacin de
Requerimientos

Trazabilidad de
Requerimientos

Administracin y Control de
Cambios

Visualizacin de los
Requerimientos

Generacin de

Reportes

Validacin y Verificacin
Requerimientos

de

Almacenamiento de
Requerimientos Rechazados

Ilustracin 1. Precedencia y prioridad.

37

9. OTROS REQUERIMIENTOS DEL PRODUCTO

9.1. Estndares aplicados
En general, los estndares que sern utilizados durante el desarrollo de la herramienta
(nombre de la herramienta) son todos aquellos estndares de la IEEE relacionados con la
implementacin de software, dentro de los cuales se encuentran:

Estndar IEEE 830-1998. Recommended Practice For Software Requirements

Specifications, el cual contiene los lineamientos ptimos para realizar una

excelente especificacin de requerimientos de software [3].

Estndar IEEE 829-1998. IEEE Standard for Software Test Documentation, el cual
describe el conjunto bsico de documentos asociados a las pruebas de software

[14].
Estndar IEEE 1016-2009. IEEE Standard for Information Technology Systems
Design- Software Design Descriptions, el cual especifica los contenidos requeridos
y la organizacin de la informacin contenida

en el documento de diseo de

software (SDD) [15].

Estndar IEEE 1063-2001. IEEE Standard for Software User Documentation, El cual
provee los requerimientos mnimos de estructuracin, contenido y formato de los
documentos como manuales de usuario y

ayudas en lnea, tanto fsicos como

electrnicos.
Adems de los estndares IEEE, tambin se utilizar el estndar ISO 9126, el cual
describe seis caractersticas mnimas para la calidad de software [4].

9.2. Requerimientos del Sistema

Como se mencionaba en la seccin 4.3. Suposiciones y Dependencias, la herramienta
debe funcionar principalmente sobre los equipos de las salas de sistemas (facultad de
ingeniera de la PUJ), las caractersticas de stos equipos son:

Intel Dual Core a 2.00 GHz

38

Disco Duro de 40G

Memoria de 1GB
Resolucin en pantalla de 1024X768 Pixeles.
Sistema Operativo Windows XP

9.3. Requerimientos de Desempeo

Para cargar la herramienta, las maquinas no debern utilizar ms 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 adicin e integracin de otros mdulos al sistema, en
caso de que se desee agregar otra funcionalidad o la modificacin de alguna de ellas (ver
seccin 7.5. Mantenibilidad).

39

10.

REQUERIMIENTOS DE DOCUMENTACION

En esta seccin se presenta los diferentes mtodos de documentacin necesarios para

que el cliente pueda utilizar el sistema sin ninguna complicacin.

10.1.

Manual de Usuario

Los usuarios de la herramienta ERMT tendrn disponible un manual de usuario que estar
regido por el Estndar IEEE 1063-2001, que particularmente tendr tems adicionales
que fomentarn la investigacin por parte de los estudiantes, adems de ser un manual
para utilizar la herramienta, tendr diferentes recomendaciones sobre el proceso de
ingeniera 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 lnea

La herramienta contar, como ya se menciono en la seccin 10.1 con un manual de

usuario, el cual, adems de encontrarse en la herramienta, estar disponible en la pgina
web asignada para la distribucin de la herramienta. Adicionalmente se facilitarn lo
siguiente:

El documento conocido como Marco Terico el cual provee la base terica para el
desarrollo de la herramienta y provee informacin referente al proceso de
ingeniera de requerimientos, el cual es de vital importancia para los estudiantes

cuando realizan la especificacin de requerimientos de software.

Un documento que contenga referencias bibliogrficas sobre los procesos de
administracin

de

requerimientos,

para

que

los

estudiantes

realicen

una

investigacin ms completa.

10.3.

Guas de instalacin, configuracin y Archivos Read me

Al igual que el manual de usuario, las guas de instalacin y configuracin se encontrarn

adjuntas al producto, para que cada usuario pueda disponer de ellas en cualquier
momento. Estos documentos tendrn un formato especfico, el cual manejar diferentes
tipos de grficos para facilitar el seguimiento por parte del usuario.

40

10.4.

Etiquetado y empaquetamiento

Para el etiquetado y empaquetamiento del producto, no se tendr en cuenta ningn

estndar especfico 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 tendrn los logotipos pertenecientes al
grupo de desarrollo y al producto. [3]

41