Requirements Engineering for Software and Systems_chapter07 (1).pdf

Metodologías ágiles
Requisitos
Especificación y
Las metodologías ágiles se aplican a la ingeniería de software. Si bien hay elementos
de metodologías ágiles que se pueden aplicar a la ingeniería de sistemas (en particular, las
consideraciones humanas), tales metodologías generalmente se describen como livianas o
esbeltas cuando se aplican a sistemas que no son de software. Esto se debe a que las
metodologías ágiles dependen de una serie de prototipos rápidos y no desechables, un
enfoque que no es práctico en los sistemas basados en hardware. En cualquier caso, el
ingeniero que no es de software aún puede beneficiarse de este capítulo porque las
metodologías ágiles se emplean cada vez más y porque la mentalidad del ingeniero de
software ágil incluye algunas perspectivas saludables.
Las metodologías ágiles son una familia de estrategias de desarrollo de software no
tradicionales que han capturado la imaginación de muchos que desconfían de los enfoques
tradicionales cargados de procesos. Las metodologías ágiles se caracterizan por no tener
un proceso rígido, aunque este hecho no significa que las metodologías ágiles, cuando se
emplean correctamente, no sean rigurosas ni adecuadas para aplicaciones industriales, lo
son. Sin embargo, lo que característicamente falta en los enfoques ágiles son las soluciones
de "libro de cocina" que se centran en reuniones obligatorias y enfoques de desarrollo
prescritos de documentación compleja.
Capítulo 7
Introducción a Metodologías Ágiles*
*
Parte de esta sección ha sido extraída de Laplante (2006) con permiso.
179
Machine Translated by Google

Software de trabajo sobre integral
• Colaboración del cliente sobre el contrato
en bruto este trabajo hemos llegado a valorar:
documentación
•
• Responder al cambio sobre seguir un
Individuos e interacciones sobre
plan
•
Estamos descubriendo mejores formas de desarrollar
procesos y herramientas
Es decir, si bien hay valor en los elementos de la
derecha, valoramos más los elementos de la izquierda.
software haciéndolo y ayudando a otros a hacerlo.
negociación
Principios detrás del manifiesto ágil
180 ÿ Ingeniería de Requisitos para Software y Sistemas
Figura 7.1 Manifiesto para el desarrollo ágil de software. (Tomado de Beck, K.,
Extreme Programming Explained: Embrace Change, Longman Higher Education, Londres, 2000
entrega de software valioso.
El Manifiesto Ágil fue presentado por varios de los principales defensores de las metodologías ágiles para
explicar su filosofía (consulte la Figura 7.1).
fi Entregar software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con
preferencia a la escala de tiempo más corta.
cambio de ness para la ventaja competitiva del cliente.
Para comprender completamente la naturaleza de las metodologías ágiles, debemos examinar un
documento llamado Manifiesto Ágil y los principios que lo sustentan.
fi Construir proyectos en torno a personas motivadas. Dales el ambiente y
apoyo que necesitan y confiar en ellos para hacer el trabajo.
fi A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz y luego
Los signatarios del Manifiesto Ágil incluyen muchas luminarias de la práctica moderna de la ingeniería
de software, como Kent Beck, Mike Beedle, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim
Highsmith, Ron Jeffries, Brian Marick, Robert Martin, Steve Mellor y Ken Schwaber. Detrás del Manifiesto
Ágil hay un conjunto de principios. Mire los principios a continuación, notando el énfasis en aquellos aspectos
que se enfocan en la ingeniería de requisitos, que ponemos en cursiva.
fi Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.
ÿ Nuestra mayor prioridad es satisfacer al cliente a través de una atención temprana y continua.
El equipo de desarrollo es una conversación cara a cara.
fi El método más eficiente y eficaz para transmitir información hacia y dentro de un
sintoniza y ajusta su comportamiento en consecuencia.
fi Dar la bienvenida a los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles har

Los métodos ágiles son adaptativos en lugar de predictivos. Este enfoque difiere significativamente
de los modelos de proceso que enfatizan la planificación del software en gran detalle durante un largo
período de tiempo, y para los cuales los cambios significativos en la especificación de los requisitos
del software pueden ser problemáticos. Los métodos ágiles son una respuesta al problema común de
los requisitos en constante cambio que pueden atascar los enfoques de diseño iniciales más
"ceremoniales", que se centran en gran medida en la documentación al principio.
equipos (Beck 2000).
fi Las mejores arquitecturas, requisitos y diseños surgen de la autoorganización
ÿ La atención continua a la excelencia técnica y el buen diseño mejora
Los métodos ágiles también están orientados a las personas en lugar de a los procesos. Esto
significa que explícitamente intentan hacer que el desarrollo sea "divertido". Presumiblemente,
Observe cómo los principios reconocen y adoptan la noción de que los requisitos cambian a lo
largo del proceso. Además, los principios ágiles enfatizan la comunicación personal frecuente (esta
característica también es beneficiosa en la ingeniería de sistemas que no son de software). Las
características destacadas de la ingeniería de requisitos en los modelos de procesos ágiles difieren de
la cascada "tradicional" y de los modelos más modernos, como el desarrollo iterativo, evolutivo o en
espiral. Estos otros modelos favorecen una gran cantidad de trabajo inicial en el proceso de ingeniería
de requisitos y la producción, a menudo, de documentos de especificaciones de requisitos voluminosos.
agilidad.
fi El software funcional es la medida principal del progreso.
fi La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial
ÿ Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y
usuarios deberían poder mantener un ritmo constante indefinidamente.
Los métodos ágiles de desarrollo de software son un subconjunto de métodos iterativos* que se
enfocan en aceptar el cambio y enfatizan la colaboración y la entrega temprana del producto,
manteniendo la calidad. El código de trabajo se considera el verdadero artefacto del proceso de
desarrollo. Los modelos, planes y documentación son importantes y tienen su valor, pero existen solo
para respaldar el desarrollo de software funcional, en contraste con los otros enfoques ya discutidos.
Sin embargo, esto no significa que un enfoque de desarrollo ágil sea un juego de todos. Hay prácticas
y principios muy claros que los metodólogos ágiles deben adoptar.
cial “Haz lo más simple que pueda funcionar”.
*
La mayoría de la gente define las metodologías ágiles como incrementales. Pero el desarrollo incremental
implica que se planifican las características y el cronograma de cada versión entregada. En algunos casos,
las metodologías ágiles tienden a generar versiones con conjuntos de funciones y fechas de entrega que
casi siempre no son las previstas.
Especificación de requisitos y metodologías ágiles ÿ 181
Beneficios del desarrollo de software ágil

ÿ Diseño
Las metodologías ágiles incluyen Crystal, Extreme Programming, Scrum, el método de desarrollo de
sistemas dinámicos (DSDM), el desarrollo basado en funciones y la programación adaptativa, entre otras.
Veremos más de cerca dos de las metodologías ágiles más utilizadas: XP y Scrum.
fi Lograr la validación de requisitos (Inayat et al. 2015)
Señalaron que se necesitaba más investigación y evidencia empírica para fortalecer y generalizar estas
conclusiones, pero los resultados de su estudio aún apuntan fuertemente al poder de los métodos ágiles.
ÿ Codificación
Inayat et al. realizaron una revisión sistemática de estudios de proyectos de software ágiles publicados
entre 2002 y 2012. Identificaron cinco desafíos de ingeniería de requisitos tradicionales que fueron
erradicados o minimizados por las prácticas de ingeniería de requisitos que se encuentran en las
metodologías ágiles. Estos desafíos fueron:
Extreme Programming (XP)* es una de las metodologías ágiles más utilizadas.
ÿ Pruebas
esto se debe a que escribir especificaciones de requisitos de software y descripciones de diseño de software
es oneroso y, por lo tanto, debe minimizarse.
ÿ Aumentar la participación del cliente
XP promueve un conjunto de 12 prácticas básicas que ayudan a los desarrolladores a responder y
adoptar cambios inevitables. Las prácticas se pueden agrupar según cuatro prácticas
fi Cerrar la brecha de comunicación con todas las partes interesadas
XP está tradicionalmente dirigido a equipos de desarrollo más pequeños y requiere relativamente pocos
artefactos detallados. XP adopta un enfoque iterativo para sus ciclos de desarrollo. Podemos visualizar la
diferencia en el proceso entre un modelo de cascada tradicional, modelos iterativos y XP (Figura 7.2).
Mientras que un método evolutivo o iterativo aún puede tener distintas fases de análisis, diseño,
implementación y prueba de requisitos similares al método en cascada, XP trata estas actividades como
interrelacionadas y continuas.
ÿ Planificación
ÿ Reducción del desplazamiento del alcance
ÿ Reducir el tamaño y la complejidad de la documentación
áreas:
La programación extrema a veces también se escribe "Programación extrema" para resaltar el "XP".
*
Programación extrema

Melé
* Las reuniones de pie duran 10 minutos o menos, donde los participantes literalmente se ponen de pie y
dan un informe oral de las actividades del día anterior y los planes para ese día.
Figura 7.2 Comparación de los ciclos de desarrollo en cascada, iterativo y XP.
(Tomado de Beck, K., Extreme Programming Explained: Embrace Change,
Longman Higher Education, Londres, 2000.)
Las prácticas de prueba incluyen la creación de nuevos casos de prueba cada vez que se encuentra un error y
Algunas de las características de planificación distintivas de XP incluyen la celebración de reuniones diarias*,
la realización de pequeños lanzamientos frecuentes y el traslado de personas. Las prácticas de codificación incluyen
tener al cliente disponible constantemente, codificar primero los casos de prueba de unidad y emplear la
programación en pares (una estrategia de codificación única en la que dos desarrolladores trabajan juntos en el
mismo código). La eliminación de la propiedad territorial de cualquier unidad de código es otra característica de XP.
Scrum, que lleva el nombre de un punto particularmente polémico en un partido de rugby, permite la autoorganización
de los equipos fomentando la comunicación verbal entre todos los miembros del equipo y entre todas las partes
interesadas. Un principio fundamental de Scrum es que las metodologías tradicionales de desarrollo de software
basadas en planes, como el desarrollo iterativo y en cascada, se centran demasiado en el proceso y no lo suficiente
en el software. Además, mientras que el desarrollo dirigido por planes se enfoca en artefactos que no son de
software (p. ej., documentación) y procesos (p. ej., revisiones formales), Scrum enfatiza la importancia de producir
software que funcione pronto y con frecuencia. Scrum alienta
Las prácticas de diseño incluyen buscar primero las soluciones más simples, evitar demasiada planificación
para el crecimiento futuro (generalidad especulativa) y refactorizar el código (mejorar su estructura) continuamente.
tener pruebas unitarias para todo el código, posiblemente utilizando marcos como XUnit.
Diseño
Cascada
Tiempo
Iterativo PE
Implementación
Prueba
Análisis

autoorganización fomentando una comunicación de alta calidad entre todas las partes interesadas.
En este caso, está implícito que el problema no puede entenderse o definirse completamente (puede
ser un problema perverso). Y el enfoque en Scrum está en maximizar la capacidad del equipo para
responder de manera ágil a los desafíos emergentes.
Scrum presenta una acumulación viva de trabajo priorizado por hacer. La finalización de un
conjunto en gran parte fijo de elementos pendientes se produce en una serie de iteraciones o sprints
breves (aproximadamente 30 días). Cada día, se lleva a cabo una reunión breve (por ejemplo, de 15
minutos) o Scrum en la que se explica el progreso, se describe el trabajo próximo y se plantean los
impedimentos. Se produce una breve sesión de planificación al comienzo de cada sprint para definir
los elementos del registro atrasado que se completarán. Al final del sprint se realiza una breve revisión
post-mortem o retrospectiva de los latidos del corazón (Figura 7.3).
Un Scrum Master elimina obstáculos o impedimentos en cada sprint. El Scrum Master no es el
líder del equipo (ya que se autoorganizan), sino que actúa como un amortiguador de productividad
entre el equipo y cualquier influencia desestabilizadora. En algunas organizaciones, el rol del Scrum
Master puede causar confusión. Por ejemplo, si dos miembros de un equipo Scrum no están trabajando
bien juntos, un gerente sénior podría esperar que el Scrum Master solucione el problema. Arreglar la
disfunción del equipo no es el papel del Scrum Master. Los problemas de personal deben ser resueltos
por los gerentes de línea a los que reportan las partes involucradas. Este escenario ilustra la necesidad
de educación en toda la institución sobre metodologías ágiles cuando se van a emplear dichos
enfoques.
demostrado
30
minutos
diarios
reunión
equipo
pique
al final del
sprint.
dias
24
Artículos
pendientes ampliados por
reserva
reserva
la funcionalidad es
Scrum : 10–15
Producto
horas
Nuevo
(Adaptado de Schwaber, K. y Beedle, M., Agile Software Development
with SCRUM, Prentice Hall, Upper Saddle River, NJ, 2001).
Figura 7.3 El proceso de desarrollo Scrum de Boehm y Turner (2003).

Ingeniería de Requerimientos para Metodologías Ágiles
6. Desarrollo basado en pruebas
5. Prototipos
Presumiblemente, el enfoque ágil de la ingeniería de requisitos es mucho más invulnerable a
los cambios a lo largo del proceso (recuerde, "aceptar el cambio") que en la ingeniería de software
tradicional.
Los clientes están constantemente involucrados en el descubrimiento y refinamiento de
requisitos en métodos ágiles. Todos los desarrolladores de sistemas están involucrados en la
actividad de ingeniería de requisitos y cada uno puede, y debe, tener una interacción regular con
los clientes. En los enfoques tradicionales, el cliente tiene menos participación una vez que se ha
escrito y aprobado la especificación de requisitos y, por lo general, la participación no suele ser con
los desarrolladores de sistemas.
Una diferencia importante entre las metodologías tradicionales (aquí nos referimos a cascada,
evolutiva, iterativa, espiral, etc.) y ágil está en la recopilación de requisitos.
1. Comunicaciones cara a cara (sobre especificaciones escritas)
7. Revisiones y pruebas
Cao y Ramesh (2008) estudiaron 16 organizaciones de desarrollo de software que usaban XP o
Scrum (o ambos) y descubrieron siete prácticas de ingeniería de requisitos que eran ágiles por
naturaleza.
Algunas de estas prácticas se pueden encontrar en el desarrollo no ágil (por ejemplo, desarrollo
basado en pruebas y creación de prototipos), pero estas siete prácticas fueron consistentes en
todas las organizaciones estudiadas.
Los enfoques de ingeniería de requisitos para metodologías ágiles tienden a ser mucho más
informales.
3. Priorización extrema (priorización continua en lugar de una vez al principio,
De hecho, algunos defensores de las metodologías ágiles utilizan las supuestas ventajas de las
prácticas de ingeniería de requisitos ágiles como punto de venta de los métodos ágiles.
2. Ingeniería de requisitos iterativos
4. Planificación constante
En los sistemas tradicionales y la ingeniería de software, los requisitos se recopilan, analizan,
refinan, etc. en la etapa inicial del proceso. En los métodos ágiles, la ingeniería de requisitos es una
actividad continua; es decir, los requisitos se refinan y descubren con cada construcción del
sistema. Incluso en metodologías en espiral, donde se utilizan prototipos para el refinamiento de
requisitos, la ingeniería de requisitos ocurre mucho menos tarde en el proceso de desarrollo.
Otra diferencia está en el momento de las actividades de ingeniería de requisitos.
y la priorización se basa principalmente en el valor comercial)
Prácticas Generales en Metodologías Ágiles

Bajo
Alto
Bajo
Bajo
Caos
Pequeña
Nivel de habilidad del personal
Criticidad
Pedido
Dinamismo
Largo
Tamaño del equipo
Alto
Cultura
Alto
Ejemplo de aplicación de desarrollo de software ágil
Figura 7.4: Equilibrando agilidad y disciplina. (Adaptado de Boehm, B.
y Turner, R., Balancing Agility and Discipline: A Guide to the Perplexed,
Addison Wesley, Boston, 2003).
A diferencia de la especificación de requisitos de software fundamentales, el artefacto fundamental
en los métodos ágiles es una pila de requisitos en constante evolución y perfeccionamiento. Estos
requisitos son generalmente en forma de historias de usuario. En cualquier caso, estos requisitos son
generados por el cliente y priorizados: cuanto mayor sea el nivel de detalle en el requisito, mayor será
la prioridad. A medida que se descubren nuevos requisitos, se agregan a la pila y la pila se reorganiza
para preservar la priorización (Figura 7.4).
Supongamos que tuviéramos un equipo de desarrollo de cinco personas, incluido el Scrum Master.
Para simplificar, supongamos que las únicas partes interesadas son el dueño de la tienda de mascotas
(que en realidad es el cliente, ya que paga por el sistema), los clientes de la tienda, los cajeros y los
contadores. Seleccionaremos representantes de clase para la tienda.
Considere el sistema de punto de venta de la tienda de mascotas. Supongamos que quisiéramos
utilizar una metodología ágil de desarrollo de software, concretamente Scrum, para desarrollar este sistema.
No hay proscripciones para agregar, cambiar o eliminar requisitos de la lista en ningún momento
(lo que le da al cliente una gran libertad). Por supuesto, una vez que se construye el sistema, o
probablemente mientras se está construyendo, la pila de historias de usuario se puede convertir a una
especificación de requisitos de software convencional para el mantenimiento del sistema y otros
propósitos convencionales.
Veamos cómo podría ser el proceso de ingeniería de requisitos.

Después de aproximadamente 30 días, se completa el primer sprint.
6. Con base en estos comentarios, el equipo de desarrollo crea nuevas historias de usuarios y las
agrega al trabajo pendiente, modifica otras historias de usuarios según sea necesario y reorganiza
el trabajo pendiente.
2. El equipo de desarrollo analiza las historias de usuario y selecciona un subconjunto de estas;
digamos 10, para el primer sprint. Estas 10 serían las historias más "de cara al usuario", dejando
la mayor parte del procesamiento de back-end para más adelante.
5. Se presenta al panel de partes interesadas el sistema creado durante el sprint para recibir
comentarios. Estos comentarios incluirán cambios en el incremento del sistema actual, nuevas
funciones que se agregarán y, posiblemente, funciones que se omitirán.
7. El equipo de desarrollo selecciona un nuevo conjunto de historias de usuario (digamos 10) del
trabajo pendiente para el siguiente sprint de 30 días, y los pasos del proceso (C a F) se repiten
hasta que se agota el trabajo pendiente.
Esto se debe a que se están agregando nuevas historias de usuario y se están cambiando las antiguas.
3. El equipo de desarrollo vuelve a consultar con las partes interesadas para obtener más claridad
sobre estas 10 historias de usuarios antes de comenzar el desarrollo.
Se pueden realizar pruebas de aceptación adicionales, según los términos del contrato con el cliente.
Esta prueba se basaría en un conjunto de criterios desarrollados durante la negociación del contrato.
Estas pruebas de aceptación basadas en una especificación de requisitos son habituales para el
desarrollo convencional, pero atípicas para el desarrollo ágil.
clientes, cajeros y contadores. Colectivamente, llamémoslos el “panel de partes interesadas”. Ahora
considere las siguientes actividades.
4. Cada día comienza con un scrum. Los desarrolladores utilizan el diseño basado en pruebas para
derivar orgánicamente el diseño del sistema, así como los casos de prueba de unidad. El Scrum
Master facilita las comunicaciones entre el equipo de desarrollo y las distintas partes interesadas
para que las preguntas de las partes interesadas puedan responderse rápidamente.
1. El Scrum Master organiza una serie de reuniones entre el equipo de desarrollo y el cliente (el
propietario de la tienda) para obtener una comprensión básica de los requisitos, restricciones y
reglas básicas del sistema. Con base en estas discusiones, el Scrum Master organiza un conjunto
de actividades de elicitación adicionales, que posiblemente incluyan entrevistas estructuradas,
clasificación de tarjetas y grupos focales con otras partes interesadas. Se utiliza un estudio QFD
como actividad de validación (ya que es probable que haya muchos otros sistemas POS que se
puedan comparar). El objetivo de estas actividades es producir un conjunto de historias de
usuarios priorizadas (digamos alrededor de 100), incluidas las estimaciones de esfuerzo para
cada una. Pero el cliente nos ha dicho que quiere un sistema de "vanguardia", por lo que sabemos
que a medida que el sistema pasa por el desarrollo, el cliente y otras partes interesadas van a
querer una funcionalidad nueva o diferente.
Originalmente había 100 historias de usuarios, pero incluso si programamos 10 historias de usuarios
por sprint (mes), es probable que el tiempo total de desarrollo supere los 10 meses.

fi Tener una participación activa de las partes interesadas
Pero surge la pregunta, ¿cuándo se deben utilizar metodologías ágiles de desarrollo?
Scott Ambler (2007) sugiere las siguientes mejores prácticas para la ingeniería de requisitos utilizando métodos
ágiles. Muchas de las prácticas se derivan directamente de los principios del Manifiesto Ágil:
fi Modele los detalles de la “tormenta” (requisitos altamente volátiles) justo a tiempo
El uso de metodologías ágiles de software se está volviendo muy popular en la industria, al menos como lo demuestran
los datos de las encuestas. Por ejemplo, en un Forrester/Dr. En la encuesta de desarrolladores de Dobbs, el 35% de
los encuestados informaron que utilizan algún tipo de metodología ágil (West et al. 2010). Más recientemente, Kassab
et al. (2014) encontraron que el 46% de los ingenieros de software encuestados usaban una metodología ágil. También
se descubrió que los métodos ágiles eran más del doble de populares que el desarrollo en cascada dentro de los
Estados Unidos y siete veces más populares fuera de los Estados Unidos. También encontraron que el desarrollo de
software ágil se usaba con más frecuencia que la cascada en todas las regiones de los Estados Unidos, excepto en el
noreste, donde se usan casi por igual. Finalmente, la investigación encontró que los métodos ágiles se usaban con
más frecuencia que el desarrollo estilo cascada en todas las industrias excepto en finanzas, banca y seguros. Lo que
es más importante, el estudio encontró que los encuestados expresaron una mayor satisfacción con las prácticas de
ingeniería de requisitos al usar el desarrollo ágil en comparación con el desarrollo de estilo en cascada (Kassab et al.
2014).
ÿ Adopte un enfoque que priorice la amplitud
Por lo tanto, los proyectos evaluados en el círculo más interno son candidatos probables para enfoques ágiles,
los del segundo círculo (pero no en el círculo interno) son marginales y los que están fuera del segundo círculo no son
buenos candidatos para enfoques ágiles.
fi Usar modelos inclusivos (partes interesadas)
Por supuesto, Scrum Master realiza un seguimiento de la velocidad del proyecto durante cada sprint para refinar sus
estimaciones de finalización del proyecto.
Boehm y Turner sugieren que la forma de responder a la pregunta es mirar el proyecto a lo largo de un continuo de
cinco dimensiones; tamaño (en términos de cantidad de personal involucrado), criticidad del sistema, nivel de habilidad
del personal, dinamismo (cantidad anticipada de cambios en el sistema durante algún intervalo de tiempo) y cultura
organizacional (si la organización prospera en el caos o en el orden) (Boehm y Turner 2003) . En la Figura 7.4, a
medida que las características del proyecto tienden a alejarse del centro del diagrama, la probabilidad de éxito con
metodologías ágiles disminuye.
* Esta sección es una adaptación de Laplante (2006) con permiso.
¿Cuándo se recomienda Agile?*
Mejores prácticas de requisitos ágiles

Debido a que los requisitos evolucionan constantemente durante estos procesos, el creador de XP,
Kent Beck, dice que "en XP, los requisitos son un diálogo, no un documento" (Beck et al. 2001), aunque
es típico convertir la pila de historias de usuario en un software. especificación de requisitos.
La ingeniería de requisitos en XP sigue el modelo que se muestra en la Figura 7.5, donde la pila de
requisitos en el modelo de Ambler se refiere a historias de usuarios. Y en XP, las historias de usuario se
administran e implementan como código a través del “juego de planificación”.
ÿ Convierta a las partes interesadas en desarrolladores
ÿ Hazlo divertido
ÿ Obtener apoyo administrativo
Este conjunto de historias se utiliza para desarrollar el plan general del proyecto y el plan de iteraciones.
ÿ Cree requisitos independientes de la plataforma hasta cierto punto
fi Tener una interacción personal frecuente
El juego de planificación en XP toma dos formas: lanzamiento y planificación de iteraciones.
ÿ Tratar los requisitos como una pila priorizada
fi Implementar requisitos, no documentarlos
ÿ Trazabilidad de preguntas
La planificación del lanzamiento se lleva a cabo después de que se haya escrito un conjunto inicial de historias de usuario.
ÿ Expresar requisitos como características
ÿ Recuerda que cuanto más pequeño mejor
La planificación de iteraciones es un período de tiempo en el que se implementan un conjunto de
historias de usuarios y correcciones de pruebas fallidas de iteraciones anteriores. Cada iteración tiene una
duración de 1 a 3 semanas. El seguimiento de la tasa de implementación de historias de usuarios de
iteraciones anteriores (lo que se denomina velocidad del proyecto) ayuda a refinar el programa de desarrollo.
ÿ Realizar entregas frecuentes de software
Para la elicitación de requisitos, sugiere utilizar entrevistas (tanto en persona como electrónicas),
grupos focales, JAD, análisis de código heredado, observación etnográfica, análisis de dominio y tener al
cliente en el sitio en todo momento (Ambler 2007). En el resto de este capítulo, nuestra discusión se
centra en el uso de historias de usuarios para modelar los requisitos.
fi Adoptar la terminología de las partes interesadas
El conjunto también se usa para decidir el cronograma aproximado para cada historia de usuario y
proyecto general.
fi Explicar las técnicas
Ambler también sugiere el uso de artefactos como CRC, pruebas de aceptación, definiciones de
reglas comerciales, casos de cambio, diagramas de flujo de datos, interfaces de usuario, casos de uso,
prototipos, características y escenarios, diagramas de casos de uso e historias de usuarios para modelar
los requisitos (Ambler 2007). ). Estos elementos se pueden agregar al documento de especificación de
requisitos de software junto con las historias de usuario.
Ingeniería de requisitos en XP

Comience a implementar
requisitos desde aquí
Bajo
Usuario
Los requisitos pueden ser
cuentos
Más
agregado, eliminado y
reorganizado en cualquier momento
Menos
Alto
Ingeniería de requisitos en Scrum
Detalle Prioridad
Dirección
de
implementación
Figura 7.5 Proceso ágil de gestión de cambios en los requisitos. (Adaptado
de Ambler, S., Gestión de cambios de requisitos ágiles, 2007, http://
www.agilemod eling.com/essays/changeManagement.htm, último (consultado en enero de
En Scrum, la acumulación de requisitos se organiza en tres tipos: producto, lanzamiento y
sprint. El backlog del producto contiene los backlogs de la versión, y cada versión contiene el
backlog del sprint. La figura 7.6 es un diagrama de Venn que muestra la relación de contención de
los elementos pendientes.
Algunos de los estudiantes del autor también usan Scrum en los cursos. En estos casos, resulta
muy eficaz cuando hay poco tiempo para largos procesos de descubrimiento de requisitos.
El backlog del producto actúa como un repositorio de los requisitos destinados a su lanzamiento
en algún momento. Los requisitos en la cartera de productos incluyen requisitos de nivel bajo, medio
y alto.
El backlog de la versión es un conjunto priorizado de elementos extraídos del backlog del
producto. Los requisitos en la acumulación de versiones pueden evolucionar para que contengan
más detalles y estimaciones de bajo nivel.
En Scrum, la pila de requisitos que se muestra en el modelo de la Figura 7.5 es, como en XP, la
evolución de la acumulación de historias de usuarios. Y como en XP, estos requisitos se congelan
en cada iteración para la estabilidad del desarrollo. En Scrum, cada iteración toma alrededor de un mes.
Finalmente, la lista de tareas pendientes del sprint es un conjunto de requisitos de lanzamiento
que el equipo completará (totalmente codificados, probados y documentados) al final del sprint.
Estos requisitos han evolucionado a un nivel muy alto de detalle y, por lo tanto, su prioridad es alta.
Para gestionar los cambios en la pila, se otorga a una persona la autoridad final para la priorización
de requisitos (generalmente el patrocinador del producto).
Scrum ha sido adoptado en varias corporaciones importantes, con un éxito notable.

Producto
Figura 7.6 Relación de backlog entre producto, lanzamientos y sprints.
Liberación
Liberación pique
pique
pique
Escribir historias de usuario
Cada historia de usuario representa una característica deseada por el cliente. Las historias de usuario (un
término acuñado por Kent Beck) las escribe el cliente en fichas, aunque el proceso puede automatizarse a
través de wikis u otras herramientas. Los requisitos formales, los casos de uso y otros artefactos se derivan
de las historias de los usuarios por parte del equipo de ingeniería de software según sea necesario.
En la Tabla 7.1 se muestra un diseño de muestra para estos elementos en una ficha.
fi Prueba de aceptación: este es un identificador único que será el nombre de un método para probar la
historia.
Las historias de usuario son la unidad de requisitos más básica en la mayoría de las metodologías ágiles.
fi Descripción: esta es de una a tres oraciones que describen la historia.
El desarrollo de historias de usuario es un proceso "iterativo e interactivo". El equipo de desarrollo también
administra el tamaño de las historias para lograr uniformidad (p. ej., demasiado grande, dividir, demasiado
pequeño, combinar).
ÿ Título: este es un identificador corto para la historia. Un verbo en tiempo presente en voz activa es
deseable en el título.
ÿ Puntos de historia: este es el tiempo estimado para implementar la historia de usuario. Este aspecto
hace que las historias de usuario sean útiles para la estimación de esfuerzos y costos.
Una historia de usuario consta de los siguientes componentes:
Las historias iniciales de los usuarios generalmente se recopilan en pequeñas reuniones fuera del sitio.
Las historias se pueden generar a través de enfoques orientados a objetivos (p. ej., “discutamos cómo un
cliente hace una compra”) oa través de enfoques interactivos (flujo de conciencia).
fi Prioridad—esto se basa en el esquema de priorización adoptado. La prioridad se puede asignar en
función de la priorización "tradicional" de la importancia o del nivel de detalle (la mayor prioridad se
asigna al mayor detalle).

Una historia de usuario de ejemplo para un cliente que devuelve artículos en el sistema POS de la tienda de mascotas
Los desarrolladores no escriben historias de usuarios, lo hacen los usuarios. Pero las historias deben ser lo
suficientemente pequeñas como para que se puedan completar varias por iteración. Las historias deben ser independientes
(tanto como sea posible); es decir, una historia no debe hacer referencia de ida y vuelta a otras historias.
La Tabla 7.3 muestra otra historia de usuario de ejemplo que describe la detección de una amenaza a la seguridad en
el sistema de manejo de equipaje del aeropuerto.
tem se muestra en la Tabla 7.2.
Las historias de usuario deben ser comprensibles para los clientes y cada historia debe agregar valor.
Finalmente, las historias deben ser comprobables, como cualquier requisito, si no se puede probar, no es un requisito. El
equipo de desarrollo considera la capacidad de prueba de cada historia.
Finalmente, vale la pena señalar que existe una diferencia significativa entre los casos de uso y las historias de usuario.
Las historias de usuarios provienen de la perspectiva del cliente y son simples, y evitan los detalles de implementación. Los
casos de uso son más complejos y pueden incluir detalles de implementación (por ejemplo, objetos fabricados). Los clientes
no suelen escribir casos de uso (y si lo hacen, ojo, porque ahora el cliente se dedica a la “ingeniería de software”). Finalmente,
es difícil decir cuál es la equivalencia para el número de casos de uso por historia de usuario. Una historia de usuario podría
equivaler a uno o más de 20 casos de uso.
Tabla 7.3 Historia de usuario: Manejo de equipaje
Tabla 7.2 Historia de usuario: Sistema POS de tienda de mascotas
Tabla 7.1 Diseño de la historia de usuario
Examen de ingreso
Prueba de aceptación: custRetItem
Descripción
Prioridad 1
Puntos de historia: 2
Título
Prueba de aceptación: detSecThrt
Título: Artículos devueltos por el cliente
Cuando un cliente devuelve un artículo, su compra debe ser autenticada. Si la compra fue auténtica, entonces
se debe acreditar la cuenta del cliente o devolver el monto de la compra. El inventario debe actualizarse en
consecuencia.
Puntos de historia prioritarios
Puntos de historia: 3
Prioridad 1
Cuando se determina que una bolsa escaneada contiene una instancia de un artículo prohibido, la bolsa se
desviará al transportador del punto de control de seguridad. Al responsable de seguridad se le enviará un correo
electrónico indicando que se ha detectado una amenaza potencial.
Título: Detectar amenazas de seguridad

En los últimos años se han introducido varios enfoques de ingeniería de requisitos ágiles, muchos de los
cuales no son mucho más que una ingeniería de requisitos descuidada. Pero parte del trabajo reciente en esta
área también ha sido bueno. Sin embargo, para cualquier metodología de ingeniería de requisitos ágiles
"legítima" que pueda encontrar, la mayoría de las prácticas se pueden rastrear hasta el Manifiesto Ágil. Por
ejemplo, Vlaanderen et al. (2011) mostró cómo ciertas prácticas de ingeniería de requisitos de Scrum también
podrían ser para la gestión de productos de software (después de la entrega). En particular, identificaron los
ciclos de sprint, la administración de la acumulación, las reuniones diarias y la colaboración temprana y
frecuente como prácticas necesarias.
Una buena característica de la prueba de la historia es que utiliza el marco Fit para permitir a los usuarios
crear casos de prueba en las historias de forma tabular (consulte el Capítulo 8). Por lo tanto, los usuarios
especifican intuitivamente el comportamiento y las pruebas para ese comportamiento en los requisitos.
Necesitamos hacer una distinción entre ingeniería de requisitos para metodologías ágiles e ingeniería de
requisitos ágiles. La ingeniería de requisitos ágil significa, en general, cualquier enfoque de ingeniería de
requisitos ad hoc que pretenda ser más flexible que la ingeniería de requisitos tradicional. Esta definición no
debe confundirse con las prácticas específicas para la ingeniería de requisitos en metodologías ágiles como
acabamos de discutir (Sillitti y Succi 2006).
Las pruebas de historia son descripciones no técnicas del comportamiento junto con pruebas que verifican que
el comportamiento es correcto. Las pruebas de historias ayudan a “descubrir muchas piezas faltantes o
inconsistencias en una historia” (Mugridge 2008).
Para ilustrar una metodología ágil, describimos un ejemplo notable. En esta metodología llamada SDD (Story
Test-Driven Development), se incorporan muchas de las características habituales de cara al cliente de las
metodologías ágiles junto con ráfagas breves de desarrollo iterativo al estilo XP o Scrum. Sin embargo, una
diferencia en SDD es que, en lugar de las historias de usuarios convencionales, los clientes escriben o revisan
"pruebas de historias".
El Apéndice D incluye una discusión adicional de las historias de usuarios tanto en entornos ágiles como
no ágiles.
La tabla de la Figura 7.7 muestra, por ejemplo, que si un empleado trabaja 5 jornadas laborales
consecutivas de 9 horas, entonces se considera que tiene 45 horas en jornadas ordinarias y ordinarias.
Por ejemplo, para la historia de usuario de devolución del cliente en la Tabla 7.2, puede imaginar que se
necesitarán muchos más casos de uso para lidiar con las diversas situaciones que pueden surgir en la
devolución de un cliente. En las metodologías ágiles, las historias de usuario son mucho más preferidas que los casos de uso.
Por ejemplo, para un sistema de nómina típico para una empresa (como la tienda de mascotas), en la
figura 7.7 se proporciona una prueba de historia que describe cómo calcular el pago de horas extra y ordinarias
para un empleado en función de varias horas registradas.
Ingeniería de requisitos ágiles
Historia Desarrollo basado en pruebas

Procesamiento de salarios
dieciséis
0
9
0
0
9,7
Horas extraordinarias ordinarias
45
9
máx.
dieciséis
9
15
Calcular
9
9 0
2
Dentro de
9,0
8
0
45
9,9,9,9,9
común
9
40
11,7
9,9,9,9,9
10,11,12,13,14
Horas
9
0
5
Desafíos para la ingeniería de
requisitos en metodologías ágiles
Figura 7.7 Uso de una prueba de historia para mostrar cómo una empresa calcula el pago
de horas ordinarias y horas extra. (Tomado de Mugridge, R., Software, 25: 68–75, 2008.)
Williams (2004) analiza algunas de estas deficiencias.
cero horas en el pago de horas extras adeudadas. Si un trabajador trabaja 10, 11, 12,
13 y 14 horas al día en una semana, tiene derecho a 45 horas regulares y 15 horas
extra. Pero el marco de ajuste es una especificación interactiva: si ingresa diferentes
valores en la tabla que son incorrectos, se mostrarán como no válidos (consulte el Capítulo 8).
Por ejemplo, las metodologías ágiles no siempre tratan bien los requisitos no
funcionales. ¿Por qué esto es así? Una razón es que no siempre son evidentes cuando
se trata solo de la funcionalidad de requisitos (a través de historias de usuarios).
Se considera que el desarrollo SDD es complementario al desarrollo basado en
pruebas (TDD) en el sentido de que el primero se aplica al desarrollo general del sistema
(Mugridge 2008).
Por supuesto, hay desafíos en cualquier tecnología nueva, y los hay en el uso de
metodologías ágiles, particularmente con respecto a la ingeniería de requisitos.

ÿ Priorización incorrecta de requisitos
ÿ Descuidar los requisitos no funcionales
ÿ Falta de trazabilidad de requisitos
Otra deficiencia es que con metodologías ágiles, la interacción con el cliente es sólida, pero
principalmente a través de la creación de prototipos. Como hemos visto, hay otras formas de obtener
requisitos matizados y comprender las necesidades de las partes interesadas, por ejemplo, sería
deseable utilizar varias técnicas de entrevista.
ÿ Cuestiones contractuales
ÿ Documentación de requisitos mínimos
Williams sugiere enfrentar este desafío aumentando las historias de usuario con técnicas apropiadas
de descubrimiento de requisitos no funcionales, como el análisis competitivo.
Rubin y Rubin (2011) identificaron construcciones de documentación que a menudo se pasan
por alto en el desarrollo ágil de software y sugirieron formas de aliviar este problema. En particular,
señalaron que el conocimiento del dominio y la arquitectura y el diseño del sistema emergente no
se capturan adecuadamente en las prácticas tradicionales de requisitos ágiles. Sus hallazgos
implican que los documentos de requisitos ágiles deben anotarse con el conocimiento de dominio
apropiado, y los documentos de diseño y arquitectura ágil correspondientes deben anotarse con la
arquitectura y el diseño del sistema final, respectivamente.
ÿ Acuerdo del cliente
Además, con metodologías ágiles, la validación es fuerte a través de pruebas y prototipos, pero
la verificación no es tan fuerte. Williams (2004) sugiere que el uso de métodos formales podría
fortalecer la ingeniería de requisitos ágiles (2004).
ÿ Disponibilidad del cliente
Aunque todavía existen desafíos importantes en el uso de metodologías ágiles para la ingeniería
de software, también existen ventajas significativas. Por lo tanto, las metodologías ágiles de software
deben considerarse al menos para la mayoría de los proyectos. E incluso cuando las metodologías
ágiles no se consideran adecuadas para ciertos proyectos de software, o cuando el proyecto no es
software, se podrían utilizar muchas de las prácticas discutidas para las metodologías ágiles. Por
ejemplo, prácticas como el cliente siempre en el sitio, el enfoque en el producto sobre la
documentación y el desarrollo temprano de casos de prueba, aún deben incorporarse en casi todos
los proyectos.
Finalmente, Inayat et al. (2015) resumió un conjunto de desafíos de ingeniería de requisitos
ágiles. Los desafíos identificados por Inayat et al. fueron:
La gestión de requisitos está integrada en el proceso (por ejemplo, XP y Scrum), pero se centra
principalmente en el nivel de código. Williams sugiere que la gestión de requisitos podría fortalecerse
agregando más prácticas de gestión de configuración estándar.
Estos desafíos se hicieron eco de algunos de los identificados por otros.

VIÑETA 7.1 Sitio web de la Ley del Cuidado de Salud a Bajo Precio
En 2010, los Estados Unidos aprobaron la Ley del Cuidado de Salud
a Bajo Precio que exige que todos los ciudadanos obtengan algún
tipo de seguro médico. La ley fue controvertida, y se sumó a la
controversia el lanzamiento desastroso del sitio web asociado del
gobierno federal. El proyecto fue complejo e involucró a 55 contratistas.
En lugar de centrarse en un proceso de desarrollo sólido, hubo prisa
por implementar el sitio web y, como era de esperar, sufrió muchos
problemas. Hubo muchos problemas estructurales y de seguridad,
pero los problemas de usabilidad, como bloqueos frecuentes, tiempos
de respuesta deficientes, contenido faltante o engañoso y dificultades
de navegación recibieron la mayor atención pública (Venkatesh et al.
2014). Alrededor de 9,47 millones de usuarios intentaron registrarse
durante la primera semana de implementación, pero solo 271ÿ000 lo
lograron (Cleland-Huang 2014). Los estudios sobre el lanzamiento
fallido del sitio web mencionaron una variedad de causas
fundamentales, incluida la subestimación del cronograma del proyecto,
el alcance mal definido, la especificación deficiente de los requisitos
y el análisis y la gestión de riesgos ineficientes (Anthopoulos et al. 2016).
Si bien muchos expertos sugirieron correctamente que un mejor
proceso de requisitos tradicionales habría mitigado estos problemas,
la presión para implementar el sitio rápidamente fue tremenda. Sin
embargo, es probable que un proceso ágil y dinámico de
descubrimiento y desarrollo de requisitos podría haber llevado a
mejores resultados del proyecto y percepción pública, al tiempo que
permitió una implementación más temprana. No se informa que tal
proceso haya sido sugerido o considerado.
7.2 ¿Es posible utilizar metodologías ágiles cuando el cliente no está en el sitio?
7.3 ¿Por qué las metodologías ágiles generalmente no son adecuadas para proyectos basados en
hardware a diferencia de los proyectos de software?
7.7 Para el sistema POS de la tienda de mascotas, genere casos de uso para varios clientes
¿Si es así, cómo?
7.4 ¿Por qué puede ser difícil que las metodologías ágiles cubran requisitos no funcionales?
compras
Ejercicios
7.5 ¿Hay algún problema al encapsular los requisitos en las historias de los usuarios?
7.1 ¿Cómo encaja la documentación de SRS en un marco ágil?
7.6 Para el sistema POS de la tienda de mascotas, genere una historia de usuario para las compras de los clientes.

7.11.1 Sistema POS de tienda de mascotas
7.11.3 Sistema de casa inteligente (Apéndice A)
7.9 Para el sistema de manejo de equipaje del aeropuerto, genere casos de uso para tratar una pieza
de equipaje perdida.
7.11.2 Sistema de manipulación de equipaje de líneas aéreas
*7.12 Hay una serie de herramientas de software, tanto comerciales como de código abierto, que se pueden
utilizar para gestionar las actividades de requisitos de un proyecto ágil.
7.10 Para el sistema de manejo de equipaje del aeropuerto, generar casos de uso para manejar el
equipaje que se desviará a otro vuelo.
Investigue estas herramientas y prepare una matriz de comparación de productos.
7.8 Para el sistema de manejo de equipaje del aeropuerto, genere una historia de usuario para tratar
7.11 Para los siguientes sistemas, discuta las ventajas y desventajas de usar un enfoque ágil (para los
componentes de software):
con equipaje que va a ser desviado a otro vuelo.
Referencias
Inayat, I., Moraes, L., Daneva, M. y Salim, SS (mayo de 2015). Una reflexión sobre la ingeniería de
requisitos ágiles: Soluciones aportadas y retos planteados. En Actas del taller científico de
XP2015, p. 6, ACM, Chicago, IL.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., et
al. (2001). “Manifiesto Ágil” y “Principios detrás del Manifiesto Ágil”. http://agilemanifesto.org/
(consultado en enero de 2017).
CRC/Taylor & Francis, Boca Ratón, Florida.
Laplante, PA (2006). Lo que todo ingeniero necesita saber sobre ingeniería de software.
Educación. Londres.
Rubin, E. y Rubin, H. (2011). Apoyar el desarrollo ágil de software a través de activos
Cleland-Huang, J. (2014). ¡No despidas al arquitecto! ¿Dónde estaban los requisitos? Software IEEE,
31(2): 27–29.
documentación. Ingeniería de requisitos, 16(2): 117–132.
Boehm, B. y Turner, R. (2003). Equilibrar la agilidad y la disciplina: una guía para los perplejos.
Addison-Wesley. Bostón.
Mugridge, R. (2008). Gestión de requisitos de proyectos ágiles con desarrollo basado en pruebas de
historia. Software, 25(1): 68–75.
com/essays/changeManagement.htm (consultado en enero de 2017).
estudio. Software, 25(1): 60–67.
Ambler, S. (2007). Gestión ágil del cambio de requisitos. http://www.modeladoagile.
Kassab, M., Neill, C. y Laplante, P. (2014). Estado de la práctica en ingeniería de requisitos: datos
contemporáneos. Innovaciones en Ingeniería de Sistemas y Software, 10(4): 235–241.
Cao, L. y Ramesh, B. (2008). Prácticas ágiles de ingeniería de requisitos: un estudio empírico
Beck, K. (2000). Programación extrema explicada: aceptar el cambio. Longman superior
Anthopoulos, L., Reddickb, CG y Giannakidou, I. (2016). ¿Por qué fracasan los proyectos de gobierno
electrónico? Un análisis de la Sanidad. Gov. Government Information Quarterly 33(1): 161–173.

West, D., Grant, T., Gerush, M. y D'Silva, D. (2010). Desarrollo ágil: la adopción generalizada ha
cambiado la agilidad. Investigaciones Forrester. Cambridge, MA.
Sillitti, A. y Succi, G. (2006). Ingeniería de requisitos para métodos ágiles, en A. Aurum y C. Wohlin
(Eds.), Requisitos de ingeniería y gestión de software, págs. 309–326.
Williams, L. (2004). Elicitación ágil de requisitos. http://agile.csc.ncsu.edu/SEMaterials/
Saltador. Nueva York, NY.
AgileRE.pdf (consultado en enero de 2017).
Venkatesh, V., Hoehle, H. y Aljafari, R. (2014). Una evaluación de usabilidad del sitio web de Obamacare.
Información Gubernamental Trimestral, 31(4): 669–680.
Schwaber, K. y Beedle, M. (2001). Desarrollo Ágil de Software con SCRUM. Prentice Hall.
Vlaanderen, K., Jansen, S., Brinkkemper, S. y Jaspers, E. (2011). La refinería de requisitos ágil: aplicación
de los principios SCRUM a la gestión de productos de software. Tecnología de la información y el
software, 53(1): 58–70.
Upper Saddle River, Nueva Jersey.

Requirements Engineering for Software and Systems_chapter07 (1).pdf

Más contenido relacionado

Similar a Requirements Engineering for Software and Systems_chapter07 (1).pdf (20)

Último (20)

Requirements Engineering for Software and Systems_chapter07 (1).pdf