52
Tono Revista Técnic
a
de l
a
Empres
a
de Telecomunic
a
ciones de Cub
a
S.A.
E
n la actualidad un número
creciente de herramienta
s
auto-
matizadas han surgido para ayudar a
I
m
p
o
r
t
an
c
i
a
d
e
l
a
i
n
g
e
n
i
e
r
í
a
d
e
r
e
q
u
e
r
i
m
i
e
n
t
o
s
e
s
critos, a especificaciones precisas,
no ambiguas, consistentes y com-
pleta
s
del comportamiento del sistema,
Estudios realizados muestran que
más del 53 % de los proyectos de
software fracasan por no realizarse
definir y aplicar un proce
s
o de de
s
a-incluyendofunciones,interfaces,un estudio previo de requisitos.
rrollo de
s
oftware efectivo. Hoy día larendimiento y limitaciones”
2
.Otros factores como la falta de par-
economía global depende má
s
de“Un enfoque sistémico para reco-ticipación del usuario, lo
s
requeri-
si
s
temas automatizado
s
que en épo-lectar, organizar y documentar losmientos incompletos y el cambio a los
cas pa
s
ada
s
; esto ha llevado a lo
s
requerimientos del sistema; es tam-requerimientos, ocupan sitiales altos
equipos de desarrollo a enfrentar
s
ebién el proceso que establece yen los motivos de fracasos.
con una nueva década de proce
s
o
s
ymantiene acuerdos sobre los cam-¿Qué son los requerimientos? Exis-
estándares de calidad. A pe
s
ar de lo
s
bio
s
de requerimientos, entre losten múltiples definiciones para reque-
avance
s
de la tecnología, aún exi
s
tenclientes y el equipo del proyecto”
3
.rimiento, a continuación se presenta
procesos de produccione
s
informa-En todas las definiciones se destacala que aparece en el glosario de la
le
s
, parciale
s
y, en alguno
s
ca
s
o
s
, nocomo un proceso que comprendeIEEE:
confiable
s
.toda
s
las actividades para crear y man-1. Una condición o necesidad de
La Ingeniería de Requerimiento
s
tener los requerimientos de un sistemaun usuario para resolver un proble-
(IR) e
s
definida como:y cumple un papel primordial en elma o alcanzar un objetivo.
“La di
s
ciplina para de
s
arrollarproce
s
o de producción de software,2. Una condición o capacidad que
una e
s
pecificación completa, con-pue
s
enfoca un área fundamental: ladebe estar presente en un
s
istema o
sistente y no ambigua, la cual
s
er-
d
efi
n
ició
n
d
e lo
qu
e se
d
esea
p
ro
du
cir.componentes de sistema para satis-
virá como ba
s
e para acuerdo
sS
u tarea principal consiste en lafacer un contrato, estándar, especi-
comune
s
entre toda
s
la
s
parte
s
in-generación de especificaciones co-ficación u otro documento formal.
volucradas y en donde
s
e de
s
cri-rrecta
s
que describan con claridad, sin3.Una representación documentada
ben las funcione
s
que realizará elambigüedades, en forma consistente yde una condición o capacidad como
sistema”
1
.compacta, el comportamiento del sis-en 1 ó 2.
S
e dividen en f
un
cio
n
ales y
“El proce
s
o por el cual
s
e tran
s
-tema; de esta manera, pretende mini-
n
o f
un
cio
n
ales.
forman los requerimiento
s
declarado
s
mizar
s
e los problemas relacionadosF
un
cio
n
ales: condición o capaci-
por los clientes, ya
s
ean hablado
s
ocon el desarrollo de sistemas.dad de un sistema requerida por el
d
en
t
r
o
d
e
l
c
i
c
l
o
d
e
d
e
s
a
rr
o
ll
o
d
e
so
f
t
w
a
r
e
L
i
c.
C
a
ri
d
a
d
R
a
c
e
r
o
B
o
rr
e
ll
,
T
é
c.
e
n
T
e
l
e
m
á
t
i
c
a
,
G
e
r
e
n
c
i
a
d
e
S
i
s
t
e
m
a
s
I
n
f
o
r
m
á
t
i
c
o
s
,
D
ir
e
cc
i
ón
d
e
D
e
s
a
rr
o
ll
o
y
A
s
un
t
o
s
R
e
g
u
l
a
t
o
ri
o
s
(
DDA
R
)
,
E
T
E
C
S
A
c
a
ri
d
a
d
.
r
a
c
e
r
o
@
e
t
e
c
s
a
.c
u
To
n
o Revist
a
Técnic
a
de l
a
E
mpres
a
de Telecomunic
a
ciones de Cub
a
S
.A.
53
forma de software —
S
.O.
s
ervi-
dor: Window
s
NT 4.0,
S
.O. clien-
te: Windows NT 4.0,
S
oftware de
aplicación PHP, Ge
s
tor de BD
MySQL—.
C
a
r
a
c
t
e
r
í
st
i
c
a
s
de
l
o
s
r
eq
u
e
r
i
m
i
e
n
t
o
s
Las caracterí
s
tica
s
de un reque-
rimiento son su
s
propiedade
s
principale
s
. Un conjunto de re-
querimientos en estado de madu-
rez, debe presentar caracterí
s
tica
s
individualmente y en grupo. A
continuación se pre
s
entan la
s
usuario para resolver un problema o
Š
Nece
s
ario: un requerimiento es necesario si su omisión provoca
alcanzar un objetivo.una deficiencia en el sistema a construir y, además, su capacidad,
No funcionale
s
: condición o capa-características físicas o factor de calidad no pueden ser reempla-
cidad que debe po
s
eer un
s
i
s
temazado
s
por otras capacidades del producto o del proceso.
para satisfacer un contrato, un e
s
-
Š
Co
n
ciso: un requerimiento es conciso si es fácil de leer y enten-
tándar, una especificación u otroder.
S
u redacción debe ser simple y clara para aquellos que vayan a
documento formalmente impue
s
to.con
s
ultarlo en el futuro.
Son propiedades que debe tener el
Š
Completo: un requerimiento está completo si no necesita ampliar
sistema.detalle
s
en su redacción, es decir, si se proporciona la información
Š
U
s
abilidad: la interfaz de u
s
uario
s
uficiente para su comprensión.
deberá
s
er familiar a lo
s
u
s
uario
s
Š
Co
ns
iste
n
te: un requerimiento es consistente si no es contradictorio
que han utilizado otra
s
aplicacio-con otro requerimiento.
ne
s
Web o aplicacione
s
de e
s
cri-
Š
No am
b
ig
u
o: un requerimiento no es ambiguo cuando tiene una
s
ola
torio de Windows.interpretación. El lenguaje usado en su definición no debe causar
Š
Seguridad: el acce
s
o
s
e realiza-confu
s
iones al lector.
rá a través de nombre
s
de u
s
ua-
Š
Verifica
b
le: un requerimiento es verificable cuando puede ser cuan-
rio y contra
s
eña
s
, dejar huella
s
detificado de manera que permita hacer uso de los siguientes métodos de
confirmación de operacione
s
.verificación: inspección, análisis, demostración o pruebas.
Š
Desempeño y e
s
calabilidad:
S
in embargo, a pesar de ser conocidas estas características, se presen-
el
s
istema deberá
s
er fácilmen-tan dificultades en el momento de definirlos, de las cuales pueden
te adaptable a cualquier cam-
s
eñalar
s
e:
bio en el entorno de trabajo. E
s
Š
Lo
s
requerimientos no son obvios y vienen de muchas fuentes.
la capacidad del
s
i
s
tema de
Š
S
on difíciles de expresar en palabras —el lenguaje es ambiguo—.
cambiar
s
u tamaño o configu-
Š
Exi
s
ten muchos tipos de requerimientos y diferentes niveles de
ración para adaptar
s
e a la
s
cir-detalle.
cun
s
tancias cambiante
s
.
Š
La cantidad de requerimientos en un proyecto puede ser difícil de
Š
Mantenimiento y actualización:manejar.
entrega de nuevas ver
s
ione
s
del
Š
Lo
s
requerimientos nunca son iguales. Algunos son más difíciles, más
producto a bajo co
s
to para elrie
s
go
s
os, más importantes o más estables que otros.
cliente en un mínimo de tiempo.
Š
Lo
s
requerimientos están relacionados entre sí y, a la vez, se relacionan
Š
Soporte: proveer
s
oporte téc-con otras partes del proceso.
nico eficiente, por ejemplo, la
Š
Cada requerimiento tiene propiedades únicas y abarcan á
r
eas
guía de re
s
olución de proble-funcionales específicas.
ma
s
y una li
s
ta de información.
Š
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
Š
Hardware: requi
s
ito
s
de plata-
Š
S
on difíciles de cuantificar, pues cada conjunto de requerimiento
s
es
forma de hardware, por ejemplo,particular a cada proyecto.
los tipo
s
de
s
ervidore
s
.
P
ara lograr mayor claridad de este tema, se representan en la figura 1
Š
Software: requisito
s
de plata-lo
s
tipos de requerimientos a considerar.
má
s
importante
s
:
F
i
g
u
r
a
1
T
i
po
s
d
e
r
e
qu
e
ri
m
i
e
n
t
o
s
54
Tono Revista Técnic
a
de l
a
Empres
a
de Telecomunic
a
ciones de Cub
a
S.A.
Desde el punto de vi
s
ta de lo
s
recur
s
o
s
humanos, son muchas las per-sido percibido a un nivel de riesgo
sona
s
involucrada
s
en el de
s
arrollo de lo
s
requerimientos de un sistemaaceptable sin perder de vista las
y cada una tiene intere
s
e
s
diver
s
o
s
y realiza roles específicos dentro defactibilidades técnicas y económi-
la planificación del proyecto. El conocimiento de cada papel desem-cas, a la vez que se buscan resultados
peñado asegura que
s
e involucren a la
s
personas correctas en lascompletos, correctos y sin ambigüe-
diferente
s
fa
s
es del ciclo de vida, y en la
s
diferentes actividades de ladades.
IR. Lo
s
roles má
s
importante
s
a con
s
iderar son los que siguen, yEs
p
ecificació
n
: es la actividad en
aparecen en la G
PS
W v-2, vigente en ETEC
S
A:la cual se genera el documento, con
U
s
uario final:
s
on la
s
per
s
ona
s
que utilizarán el sistema desarrollado.el mismo nombre, que contiene una
Están relacionada
s
con la u
s
abilidad, di
s
ponibilidad y fiabilidad deldescripción completa de las necesi-
si
s
tema; están familiarizada
s
con lo
s
procesos específicos que debedades y funcionalidades del sistema
realizar el software, dentro de lo
s
parámetros de su ambiente laboral.que será desarrollado; describe el
Serán quiene
s
utilicen la
s
interface
s
y lo
s
manuales de usuario.alcance del sistema y la fo
r
ma como
U
s
uario líder:
s
on lo
s
individuo
s
que comprenden el ambiente delhará sus funciones, con la defini-
si
s
tema o el dominio del problema en donde será empleado el softwareción de los requerimientos funcio-
de
s
arrollado. Ello
s
proporcionan al equipo técnico los detalles ynales y los no funcionales. Definen
requerimiento
s
de la
s
interface
s
del
s
i
s
tema.todos los requerimientos de hard-
Equipo de admi
n
i
s
tració
n
y
s
o
p
orte: para proyectos que requieran unware y software, diagramas, mode-
mantenimiento eventual, e
s
ta
s
per
s
ona
s
s
on las responsables de lalos de sistemas y cualquier otra
administración de cambio
s
, de la implementación y resolución de lasinformación que sirva de
s
oporte y
anomalías. Su trabajo con
s
i
s
te en revi
s
ar y mejorar los procesos delguía para fases posteriores. Es el
producto finalizado.resultado final de las actividades de
Equipo de de
s
arrollo e im
p
leme
n
tación: son los responsables delanálisis y evaluación de requeri-
desarrollo del producto en
s
í e interactúan directamente con el cliente.mientos. Este documento resultante
Per
s
onal de
p
r
u
e
b
a
s
:
s
e encarga de elaborar y ejecutar el plan deserá utilizado como fuente básica de
pruebas para asegurar que la
s
condicione
s
presentadas por el sistemacomunicación entre los clientes,
sean la
s
adecuada
s
.
S
on quiene
s
validan
s
i los requerimientos satis-usuarios finales, analistas de sistema,
facen las nece
s
idade
s
del cliente.personal de pruebas, y todos los
Otras per
s
ona
s
que pueden e
s
tar involucradas, dependiendo de lainvolucrados en la implementación
magnitud del proyecto, pueden
s
er el líder informático, líder funcional,del sistema.
per
s
onal encargado de documentar el proyecto, los diseñadores de baseVali
d
ació
n
: permite demostrar que
de dato
s
, entre otro
s
.los requerimientos definidos en el
Actividades de la
In
ge
n
iería
d
e Re
qu
erimie
n
tos: en el proceso de IRsistema son los que realmente desea
son e
s
enciales diver
s
a
s
actividade
s
.
S
e presentarán en un orden se-el cliente. Además, revisa que no se
cuencial,
s
in embargo, en un proce
s
o de ingeniería de requerimientoshaya omitido ninguno, que no sean
efectivo, esta
s
actividade
s
s
on aplicada
s
de manera continua y en ordenambiguos, inconsistentes o redun-
variado.dantes, garantiza que todos los re-
En dependencia del tamaño del proyecto y del modelo de proceso dequerimientos presentes en el docu-
software utilizado para el ciclo de de
s
arrollo, las actividades de la IRmento de especificación cumplan
varían en número y en nombre
s
.con los estándares de calidad. No
La tabla 1 mue
s
tra alguno
s
ejemplo
s
de la
s
actividades identificadas para cadadebe confundirse la actividad de
proceso.evaluación de requerimientos con la
A pe
s
ar de la
s
diferente
s
interpretacione
s
que cada desarrollador tenga envalidación de requerimientos. La
relación con el conjunto de actividade
s
mo
s
tradas, pueden identificarse yevaluación verifica las propiedades
extraerse cinco actividade
s
principale
s
:de cada requerimiento, mientras que
Análi
s
is del
p
ro
b
lema: el objetivo de e
s
ta actividad es entender lasla validación revisa el cumplimiento
verdadera
s
nece
s
idade
s
del negocio, que
s
e comprendan los problemasde las características de la especi-
del negocio, se evalúen la
s
nece
s
idade
s
iniciales de todos los involu-ficación de requisitos.
crados en el proyecto y
s
e proponga una
s
olución de nivel elevado paraEvol
u
ció
n
: planear cambios posi-
su
s
olución.bles a los requerimientos cuando el
Evaluación y
n
egociació
n
: la diver
s
a gama de fuentes de la cual provienensistema sea desarrollado y utilizado.
lo
s
requerimiento
s
, hace nece
s
aria una evaluación de los mismos antes deLa actividad de evolución es un pro-
definir
s
i
s
on adecuado
s
para el cliente. El término a
d
ec
u
a
d
o significa que haceso externo que ocurre a lo largo
To
n
o Revist
a
Técnic
a
de l
a
E
mpres
a
de Telecomunic
a
ciones de Cub
a
S
.A.
55
del ciclo de vida del proyecto. Tener versiones de los requerimientos es
tan importante como tener versiones del código, porque evita tener
requerimiento
s
emparchados en un proyecto. Algunos de los beneficios
que proporciona el control de versiones está prevenir cambios no
autorizado
s
, guardar revi
s
iones de los documentos de requerimientos,
recuperar ver
s
ione
s
previa
s
de los documentos, administrar una estrategia
de
r
elea
s
e
s
, prevenir la modificación simultánea a los requisitos, entre
otra
s
. E
s
importante
s
eñalar que estas peticiones de cambios provienen de
mucha
s
fuente
s
, por lo tanto, deben ser enrutadas en un solo proceso con la
finalidad de evitar problema
s
y conseguir estabilidad en los requerimientos.
C
o
n
c
l
u
s
i
o
n
e
s
A pe
s
ar de
s
u importancia, al proceso de ingeniería de requerimientos, no se
le pre
s
ta la atención adecuada. Quedan muchos desafíos por ser mejorados,
como la integración de requerimientos funcionales y no funcionales, la
evaluación de e
s
pecificacione
s
alternativas, la formalización de la
S
R
S
, entre
otra
s
.
Cada actividad y técnica de la IR utilizada individualmente, ofrecerá
s
olucione
s
diferente
s
para proyectos diversos, incluso aquellos casos en los
T
a
b
l
a
1
A
ct
i
v
i
d
a
d
e
s
d
e
l
a
I
R
p
a
r
a
d
i
f
e
r
e
n
t
e
s
m
od
e
l
o
s
d
e
p
r
o
c
e
s
o
s
d
e
I
n
g
e
n
i
e
rí
a
d
e
S
o
f
t
w
a
r
e
56
Tono Revista Técnic
a
de l
a
Empres
a
de Telecomunic
a
ciones de Cub
a
S.A.
que el dominio y el área del problema son el mismo.
P
or tal razón, se considera
que, aunque no exi
s
te un modelo de proceso ideal para la IR, cada método y
técnica ofrece diferente
s
s
oluciones ante un problema.
La ingeniería de requerimientos es una actividad que involucra a clientes,
u
s
uario
s
, equipo de de
s
arrollo, jefe de proyecto, entre otros.
P
or lo tanto, el
proce
s
o de IR no depende
s
olamente de la forma como se percibe el problema,
s
ino también, del nivel de experiencia que tengan los involucrados.
Lo
s
principale
s
beneficios que se obtienen de la ingeniería de reque-
rimiento
s
e
s
tán relacionados con la gestión de las necesidades del proyecto
en forma e
s
tructurada, mejoras en la capacidad de realización de cronogramas
de proyecto
s
, a
s
í como
s
u
s
resultados, disminución de los costos y retrasos
del proyecto, mejora
s
en la calidad del software y en la comunicación entre
equipo
s
, y otro
s
.
Entregar
s
oftware de calidad, a tiempo y dentro del presupuesto, hará que
nue
s
tro
s
cliente
s
confíen y asegurará el crecimiento y la madurez de la
relación de negocio.
C
i
t
a
s
b
i
b
li
o
g
r
á
f
i
c
a
s
1
Bo
e
h
m
,
B.
W
.
G
u
i
de
li
n
e
s
f
o
r
V
e
r
if
y
i
n
g
a
n
d
V
a
li
d
a
t
i
n
g
S
o
f
t
w
a
r
e
R
e
q
u
i
r
eme
n
t
s
a
n
d
D
e
s
ig
n
S
p
e
c
ifi
c
a
t
i
o
n
s
.
E
U
R
O
I
F
I
P
’
79
,
1979
,
p
a
g
e
s
711
-
719.
D
i
s
p
o
n
i
b
l
e
e
n
:
h
tt
p
:
//www
.
i
n
fol
a
b
.
s
t
a
n
fo
r
d
.
e
d
u
/~
b
u
r
b
a
c
k
/w
a
t
e
r
_
s
l
u
i
c
e
/
s
l
u
i
c
e
6.25.97
/w
s
/
n
o
d
e
144.
h
t
m
l
.
(
Co
n
s
u
lt
a
:
a
b
r
il/
2006
)
.
2
S
o
u
t
h
w
e
ll
,
K
.
,
J
a
me
s
,
K
.
,
Cl
a
r
k
e
,
B
.
A
.
,
A
n
d
r
e
w
s
,
B
.
,
A
s
h
wo
r
t
h
,
C
.
,
N
o
rr
i
s
,
M
.
y
P
a
t
e
l
,
V
.
“
R
e
q
u
i
r
eme
n
t
s
D
e
fi
n
itio
n
a
n
d
D
e
s
i
g
n
”
,
T
h
e
S
T
A
R
T
S
G
u
i
de
,
S
e
c
o
n
d
E
d
itio
n
,
V
ol
.
1
,
N
a
tio
n
a
l
Co
m
p
u
ti
n
g
C
e
n
t
e
r
,
1987
.
D
i
s
p
o
n
i
b
l
e
e
n
:
h
tt
p
:
//www
.
i
n
f
.
p
u
c
-
r
io
.
b
r
/w
e
r
01
/
M
o
d
-
R
e
q
-
1.
pd
f
.
(
Co
n
s
u
lt
a
d
o
:
a
b
r
il/
2006
)
.
3
R
a
tio
n
a
l
S
oftw
a
r
e
Co
r
p
o
r
a
tio
n
R
a
tio
n
a
l
U
n
ifi
e
d
P
r
o
c
e
ss
.
V
e
r
s
ió
n
5
,
5
R
a
tio
n
a
l
S
oftw
a
r
e
Co
r
p
o
r
a
tio
n
.
S
oftw
a
r
e
b
a
s
a
d
o
e
n
U
M
L
.
B
i
b
li
o
g
r
a
f
í
a
H
of
m
a
nn
,
H
u
b
e
r
t.
R
e
q
u
i
r
eme
n
t
s
E
n
gi
n
ee
r
i
n
g
.
S
u
i
z
a
,
Z
u
r
i
c
h
:
I
n
s
tit
u
t
e
fo
r
I
n
fo
r
m
a
ti
c
s
,
U
n
i
v
e
r
s
it
y
of Z
u
r
i
c
h
,
1993
.
I
EEE
T
a
s
k
F
o
rc
e
o
n
R
e
q
u
i
r
eme
n
t
s
E
n
g
i
n
ee
r
i
n
g
.
D
i
s
p
o
n
i
b
l
e
e
n
:
h
tt
p
:
//www
.
s
hu
.
a
c
.
u
k
/tf
r
e
/
w
e
b
.li
n
k
s
.
h
t
m
l
(
Co
n
s
u
lt
a
:
a
b
r
il/
2006
)
L
i
s
t
a
d
e
p
u
b
li
c
a
c
io
n
e
s
d
e
un
g
r
u
p
o
d
e
I
n
g
e
n
i
e
r
í
a
d
e
S
oftw
a
r
e
.
D
i
s
p
o
n
i
b
l
e
e
n
:
h
tt
p
:
//
www.
s
oi.
c
it
y
.
a
c
.
u
k
/~
g
e
s
p
a
n
/
s
w_
g
r
o
u
p
_
p
u
b
.
h
t
m
l
(
Co
n
s
u
lt
a
:
a
b
r
il/
2006
)
O
b
e
r
g
,
R
o
g
e
r
;
P
r
o
b
a
s
c
o
,
L
e
s
l
ee
;
E
r
i
c
ss
o
n
,
M
a
r
í
a
.
A
pp
l
y
i
n
g
R
e
q
u
i
r
eme
n
t
s
M
a
n
a
g
eme
n
t
wi
t
h
U
s
e
C
a
s
e
s
.
EE
.
UU
.
:
R
a
tio
n
a
l
S
oftw
a
r
e
Co
r
p
o
r
a
tio
n
,
1998.
O
M
G
U
n
ifi
ed
M
o
de
li
n
g
L
a
n
g
u
a
g
e
S
p
e
c
ifi
c
a
t
i
o
n
.
O
b
j
e
c
t
M
a
n
a
g
eme
n
t
G
r
o
u
p
,
1999.
P
u
b
li
c
a
c
io
n
e
s
d
e
E
l
s
e
v
i
e
r
S
c
i
e
n
c
e
.
D
i
s
p
o
n
i
b
l
e
e
n
:
h
tt
p
:
//www
.
e
l
s
e
v
i
e
r
.
n
l/
(
Co
n
s
u
lt
a
:
a
b
r
il/
2006
)
.
S
a
i
e
d
i
a
n
,
H
.
y
D
a
l
e
,
R
.
R
e
q
u
i
r
eme
n
t
s
E
n
gi
n
ee
r
i
n
g
:
M
a
k
i
n
g
t
h
e
C
o
nn
e
c
t
i
o
n
B
e
t
w
ee
n
t
h
e
S
o
f
t
w
a
r
e
D
e
v
e
l
o
p
e
r
a
n
d
C
u
s
t
o
me
r
.
EE
.
UU
.
:
D
e
p
a
r
t
me
n
t of Co
m
p
u
t
e
r
S
c
i
e
n
c
e
,
U
n
i
v
e
r
s
it
y
of
N
e
b
r
a
s
k
a
,
1999
.
S
e
nn
,
J
a
me
s
A
.
A
n
á
li
s
i
s
y
d
i
s
e
ñ
o
de
s
i
s
t
em
a
s
de
i
n
f
o
r
m
a
c
i
ó
n
.
E
d
.
2
d
a
.
Colo
m
b
i
a
:
M
c
G
r
a
w
H
ill
,
1992
.
S
oftw
a
r
e
E
n
g
i
n
ee
r
i
n
g
R
e
s
o
u
rc
e
s
by
R
o
g
e
r
S.
P
r
e
ss
m
a
n
&
A
ss
o
c
i
a
t
e
s
I
n
c
.
D
i
s
p
o
n
i
b
l
e
e
n
:
h
tt
p
:
//www.
r
s
p
a
.
c
o
m
/
s
p
i/i
n
d
e
x
.
h
t
m
l
(
Co
n
s
u
lt
a
:
a
b
r
il/
2006
)
