Un estudio de mapeo de la ingeniera de requisitos en el desarrollo de software

gil

Proceso tradicional de ingeniera de requisitos

Es una secuencia de actividades, la iteracin entra estas actividades es posible si es necesario.

1. Elicitacin de requisitos: Donde la informacin inicial sobre los requisitos y el contexto son
obtenidas.
2. Analisis de requisitos: La informacin obtenida es analisada para crear un entendimiento de
los requisitos.
3. Especificacin de requisitos: Donde la comprensin de los requisitos se convierte en
especificaciones precisas del comportamiento del sistema. La construccin real del sistema
de software basado en las especificaciones se considera fuera del alcance del proceso de RE
4. Validacin de requisitos: Apoya las otras tres actividades identificando y corrigiendo errores
en los requisitos.
5. Priorizacin de requisitos: Apoya la elicitacin de requisitos y analisis identificando los
requisitos mas valiosos.
6. Validacin del sistema: Valida la salida de la construccin del software comparndola con
los requisitos.

Ingenieria de requisitos en Desarrollo de Software Agil

SCRUM, Programacin extrema(XP) y sus derivados son los mas populares y relevantes en la
actualidad.
En SCRUM una sola persona en el rol de product owner (PO) es responsable de la elicitacin y
priorizacin de requisitos.

Los requisitos en SCRUM residen en el product backlog, que es una lista priorizada de todos los
items de trabajo imaginados para el software, que tambien puede incluir mejoras tecnicas.
Los items de trabajo en el product backlog son llamados backlog items.

Solo el product owner puede agregar nuevos iems a el backlog. El product owner trabaja con un
equipo de desarrollo de 5 a 9 desarrolladores de software multifuncionales.

El PO y el equipo de desarrollo realizan anlisis de requisitos, especificacin de requisitos y

validacin de requisitos de manera informal y en colaboracin.
En el inicio de cada iteracin de desarrollo de dos a cuatro semanas, basndose en el desempeo
anterior del equipo de desarrollo, el PO y el equipo de desarrollo deciden qu elementos del backlog
se implementan durante la iteracin. Al final de la iteracin, la validacin del sistema la realiza el
PO, quien revisa el comportamiento del nuevo sistema.

Extreme Programming (XP) se concentra en la construccin de software y hay poca gua para la
ingeniera de requisitos. Los actores en XP son un cliente en el sitio y un equipo de tres a veinte
desarrolladores. La principal prctica de ingenieria de requisitos en XP es el juego de planificacin,
que comienza con un cliente en el sitio escribiendo los requisitos. Posteriormente, el cliente en el
sitio y los desarrolladores deciden cules de los requisitos se deben implementar durante la
siguiente iteracin de desarrollo de dos semanas. Los requisitos implementados tambin son
validados por el cliente en el sitio.

Revisin bibliogrfica y estudios de mapeo de desarrollo de software gil

El tema ms revisado ha sido la usabilidad o el diseo centrado en el usuario (UCD) en el contexto

ASD.

Resultados

2.- Beneficios del enfoque RE gil

1. Menores gastos de proceso.

2. Mejor entendimiento de los requisitos.
3. Reduccin de la asignacin, reduce la tendencia de sobre asignar recursos de desarrollo.
4. Respuesta al cambio.
5. Validacin y envo rpido.
6. Mejora de las relaciones con los clientes

3. Problemas y soluciones relacionados al enfoque RE gil

1. Problemas con el cliente o represente del cliente. (P1): RE gil confia en la intensiva
interaccin y confianza entre desarrolladores y clientes, que puede ser dificil de lograr,
puede suceder que los clientes no estn dispuestos a gastar recursos en la constante
validacin de requisitos y la solucin del sistema, Soluciones:
1. Un ingeniero de requisitos que acompaa al cliente en el sitio puede realizar tareas
relacionadas con ER para el cliente en el sitio para reducir la carga de trabajo y los
requisitos de habilidad del cliente en el sitio.
2. La documentacin de requisitos adicionales puede ser beneficiosa en proyectos de
desarrollo giles grandes debido a la sobrecarga creada por la comunicacin cara a
cara entre el cliente o los representantes del cliente y los equipos de desarrollo.
3. Las ideas de desarrollo impulsadas por las pruebas pueden ampliarse a la obtencin y
anlisis de los requisitos y a la validacin del sistema, ya que los clientes deben
redactar los requisitos como historias.
2.
2. Insuficiencia del formato de historia de usuario. (P2): Slo los requisitos funcionales
simples visibles del cliente pueden describirse como historias bsicas de usuarios. Las
propiedades como la consistencia y la veracidad de las historias de usuarios son difciles de
validar, soluciones:
1. Estudios de entrega, que extendientes las estorias de usuario con especificaciones
funcionales.
2. Despus de la obtencin inicial de requisitos por parte de los usuarios, las historias de
usuarios deben transformarse en requisitos completos, inequvocos y verificables
utilizando el proceso tradicional de anlisis de requisitos y especificacin.
3. Dificultades en la priorizacin de requisitos. (P3): No se encontraron propuestas de
soluciones.
4. Creciente deuda tcnica. (P4): No se encontraron propuestas de soluciones.
5. Confianza en el conocimiento de los requisitos tcitos. (P5): RE requiere personas altamente
cualificadas y la rotacin de personal es problemtica ya que la mayora de los
conocimientos sobre los requisitos son tcitos. Se plante una solucin a este problema: La
documentacin de requisitos adicionales puede mitigar la prdida de conocimiento creada
por la rotacin de personal en los grandes proyectos de desarrollo gil
6. Estimaciones de esfuerzo imprecisas. (P6): No se encontraron propuestas de soluciones.

Discusin

1.- Hacia una definicin de RE gil

La definicin de RE gil ha sido difcil ya que los mtodos giles ms estudiados, la Programacin
Extrema y el Scrum, no discuten explcitamente el RE, sino que incluyen las prcticas de ER en su
descripcin general del mtodo. El enfoque adoptado por los investigadores ha sido identificar las
actividades relacionadas con los requisitos y nombrar prcticas giles de ER. Sobre la base de los
resultados.

No existe una definicin universal de RE gil. Basndonos en la sntesis de los artculos incluidos,
se propone la siguiente definicin.

En RE gil, los requerimientos son obtenidos, analizados y especificados en una colaboracin

continua y estrecha con un cliente o representante del cliente con el fin de lograr una alta
reactividad a los cambios en los requisitos y en el entorno. La reevaluacin continua de los
requisitos es vital para el xito del sistema de soluciones y la estrecha colaboracin con el cliente o
el representante del cliente es el mtodo esencial de los requisitos y la validacin del sistema.

2.- Beneficios, problemas y soluciones

Los beneficios identificados del enfoque de RE gil son similares a los beneficios que se han
pretendido crear los mtodos giles para crear en general: La falta de documentacin mejora la
eficiencia del desarrollo. La estrecha colaboracin con clientes o representantes de clientes produce
software que se adapta a las necesidades de los clientes y mejora las relaciones con los clientes. El
desarrollo iterativo y la administracin estricta del alcance crean prcticas de trabajo sostenibles. El
desarrollo es altamente reactivo al cambio y el software producido se valida rpidamente.

Muchos de los problemas identificados reflejan los beneficios propuestos. La colaboracin ideal
entre el desarrollo y los clientes o representantes de clientes puede no ser factible en entornos
complejos y grandes. Del mismo modo, cuando se desarrolla software complejo y grande, las
historias de usuarios no bastan como la nica fuente de documentacin de requisitos y la
priorizacin de los requisitos puede ser muy difcil. La rpida implementacin y liberacin de
nuevas funcionalidades puede crear expectativas insostenibles para los clientes y aumentar la deuda
tcnica.

Las soluciones propuestas a los problemas antes mencionados se han concentrado en los problemas
con los representantes de clientes o clientes (P1) y en la insuficiencia del formato de historia de
usuario (P2). La mayora de las soluciones propuestas a P1 estn relacionadas a la introduccin de
las prcticas tradicionales inspiradas en RE. Estos incluyen una funcin de ingeniera de
requerimientos tradicionales, elicitacin de requisitos explcitos y documentacin de requisitos
adicionales.

Conclusiones
Este artculo presento los resultados de un estudio de mapeo de la ingeniera de requisitos en el
desarrollo de software gil. A pesar de todo el estudio realizado todava hay considerable
incertidumbre de lo que es la ingenieria de requisitos en el desarrollo de software gil.
Los beneficios propuestos de la ingeniera de requisitos giles siguen los beneficios globales que se
pretende que tengan los mtodos giles. Muchos de los problemas identificados estaban
relacionados con el desarrollo gil de sistemas de software complejos y grandes y con ASD en
grandes organizaciones, y este tema claramente necesita ms investigacin.