Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Introducción a Requerimientos
Ágiles
-Mgtr. Natalia Andriano
-Ing. Claudio Gonzalez
Introducciones
• Natalia Andriano o Magister en Ingeniería de
Software. UNLP. o Ingeniera en Sistemas, UTN –
FRC.
o Project Management Professional (PMP) – PMI.
o Profesor Adjunto; UTN -FRC o Docente Investigador
o categoría C – UTN; o categoría 4 CONEAU;
o Encargada Laboratorio Motorola-
UTN
Claudio Gonzalez
o Ingeniero de Sistemas de Información UTN – FRC
o Ingeniero Senior de Software Motorola Mobility
o Ayudante de Primera; UTN -FRC
o Docente Investigador Laboratorio Motorola-UTN
4
Agenda
• ¿Qué son los requerimientos ágiles?
• Comparación con los requerimientos tradicionales
• Estrategias / Buenas prácticas
• Cómo escribir requerimientos ágiles
▫ User stories
▫ TDD
▫ BDD
Introducción a Requerimientos Ágiles
¿Qué debe hacer?
¿Qué debe
ser?
¿Qué
limitaciones
existen?
• “Un requerimiento es una capacidad, atributo o restricción de diseño del software que provee valor o es necesario para algún interesado (stakeholder).” [ASQ]
• Define el “QUE”
Requerimientos
¿Qué debe
hacer?
¿Qué
debe
ser?
¿Qué
limitaci
ones
existen?
¿Qué son los requerimientos ágiles?
Requerimientos Ágiles
Contacto frecuente
con cliente
Proceso flexible
Requerimientos
incrementales
Estrategias / Buenas prácticas
Stakeholders
• Participación activa de los involucrados
• Reconocer la amplia variedad de stakeholders
• Adoptar la terminología de los stakeholders
Requerimientos
• Priorización de requerimientos
• Preveer los requerimientos iniciales
• Preferir requerimientos ejecutables a documentación estática
• Requerimientos no funcionales
Participación activa de los involucrados
• Ayudan a obtener un mejor entendimiento de las necesidades
Ventajas
• Dirección del proyecto a través de la evolución de requerimientos
Proveer información y tomar decisiones • Mejorar la calidad
del software.
Testing de aceptación
Desventajas
Habilidad para proveer
requerimientos
Voluntad para trabajar en
equipo
Reconocer la amplia variedad de
stakeholders
Fuente oficial de información y decisiones sobre prioridades
• No se debe forzar una terminología extraña
• Utilizar SU terminología.
• Confeccionar un glosario de términos
▫ Incluir términos técnicos y del negocio.
▫ Debe estar disponible a todos
(Ej: wiki)
Adoptar la terminología de los
stakeholders
Priorización de requerimientos
Preveer los requerimientos iniciales
• El objetivo es modelar lo suficiente para identificar
el alcance del sistema y producir una lista inicial
de requerimientos.
• El objetivo no es crear una especificación
detallada de requerimientos.
• Modelo de uso • Modelo de dominio • Modelo de interfaz de usuario
Preveer los requerimientos iniciales –
Buenas prácticas
Preveer los requerimientos iniciales –
Modelo de uso
Permite explorar cómo
los usuarios van a trabajar con el sistema.
Preveer los requerimientos iniciales -
Modelo de Dominio
• Debe capturar las principales entidades y relaciones del negocio.
Preveer los requerimientos iniciales -
Modelos de interfaz
• Modelado detallado en forma de: ▫ Especificaciones ejecutables
▫ Tests de aceptación
Preferir requerimientos ejecutables a
documentación estática
User stories
TDD
BDD
Historias de usuarios (User stories)
Definen lo que hay que construir dentro de un proyecto de software.
Son priorizadas por el cliente
• Son descompuestas en tareas y estimadas por los desarrolladores
Tienen que tener asociadas al menos un test case de aceptación
• Permiten al desarrollador testear la funcionalidad • Permiten al cliente validar que la funcionalidad esté
implementada correctamente.
• Es una descripción simple y corta de una funcionalidad del sistema vista desde la perspectiva de la persona que desea dicha nueva funcionalidad, generalmente un usuario o cliente del sistema.
• Las historias favorecen el enfoque de discutir las nuevas funcionalidades más que escribir acerca de ellas.
Historias de usuarios (User stories)
Historias de usuarios (User stories)
Ventajas Desventajas
• “Como un usuario, quiero buscar los clientes por nombre de provincia para poder tener listados según ubicación geográfica”
▫ Rol: “Usuario”
▫ Objetivo: “buscar los clientes por nombre de provincia”
▫ Razón: “poder tener listados según ubicación geográfica”
Ejemplos…
• Describen requerimientos de caja negra.
▫ Para las metodologías tradicionales son artefactos de prueba ya que definen criterios para determinar si el sistema cumple con sus necesidades.
• Son especificaciones ejecutables
• Una de las técnicas de especificación de pruebas de aceptación es BDD … pero antes…
Criterios de aceptación y test del
cliente como requerimientos
TDD
• NO es un método de testing, sino de desarrollo
• NO reemplaza a las pruebas de performance, rendimiento, ni usabilidad
• El objetivo es: “Código limpio que funciona”
• Escribir los tests antes que el código, y refactorizar
incrementalmente
Test-Driven Development (TDD)
Test-Driven Development (TDD)
Escribir caso de prueba
Codificar Ejecutar caso
de prueba
No falla
Falla
Test-Driven Development (TDD)
Los casos de prueba sirven como documentación del sistema
Se hace hincapié en el diseño de la interfaz de un módulo antes de pensar en la implementación
La ejecución de los casos de prueba se realiza en forma automatizada
Beneficios
Test-Driven Development (TDD)
Crear nuevo caso de prueba
Ejecutar caso de prueba
• Para comprobar que falla
Realizar pequeños
cambios a la implementación
Ejecutar caso de pruebas
• Hasta que todos pasen con éxito
Refactorizar el código para
mejorar el diseño
Ejecutar casos de prueba
• Para comprobar que todo sigue funcionando correctamente
Test-Driven Development (TDD)
Desventajas
Difícil de utilizar en situaciones que
requieran test funcional completo
El soporte gerencial es
esencial.
Los unit test son creados por el desarrollador que es el que
genera también el código
El nivel de cobertura y el detalles del testing logrado pueden no se re
creados tan fácilmente en
ocasiones posteriores.
BDD
• BDD
▫ Foco lenguaje e interacciones usadas en el proceso de desarrollo de software.
▫ Permite un entendimiento más global del sistema a crear,
▫ Posibilita un entendimiento común de todos los involucrados y
▫ Ayuda a eliminar malos entendidos sobre lo que el sistema debe hacer
Behaviour Driven Development (BDD)
TDD DDD BDD
Behaviour Driven Development (BDD)
Behaviour Driven Development (BDD)
• Involucrar a los stakeholders
• Utilización de ejemplos para describir el comportamiento de la aplicación
• Automatizar esos ejemplos para proveer un feedback rápido y testing de regresión
• Utilización de mocks para definir módulos que todavía no han sido escritos.
Buenas Prácticas:
• Herramientas ▫ Jbehave!!!
▫ SpecFlow
Behaviour Driven Development (BDD)
• Historias
▫ Descripciones textuales de un conjunto de escenarios
• Pasos (Steps)
▫ Implementación Java de cada una de los pasos de los escenarios.
• Reportes
▫ Después de cada ejecución podemos acceder a un completo conjunto de reportes para evaluar los resultados
Jbehave en acción
• El motor de ejecución es JUNIT lo que facilita la integración con el proceso de desarrollo.
Jbehave ejecución
Historias
• Jbehave brinda un conjunto de anotaciones que nos permiten especificar la implementación de los pasos: ▫ @Given: determina la implementación de una
precondición
▫ @When: determina la condición a validar
▫ @Then: determina la implementación de una evaluación
Pasos
Ejemplo
Y (algunas) respuestas…
Pre
gunta
s
• http://www.ambysoft.com/essays/agileTesting.html#ActiveStakeholderParticipation
• http://www.agilemodeling.com/essays/initialRequirementsModeling.htm
• http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm
• http://www.agilemodeling.com/artifacts/acceptanceTests.htm
• http://fitnesse.org/
• http://ase.cpsc.ucalgary.ca/index.php/EATDD/Home
• http://www.volere.co.uk/tools.htm
• http://ase.cpsc.ucalgary.ca/uploads/Publications/MelnikPhD.pdf
• http://openseminar.org/se/modules/126/index/screen.do
• http://www.informit.com/articles/article.aspx?p=26059
• http://www.featuredrivendevelopment.com/
• http://www.product-arts.com/joomla/articlelink/204-agile-requirements-so-whats-different
• Behavior Driven Development. [En línea] [Citado el: 09 de 12 de 2010] http://www.dosideas.com/wiki/Behavior_Driven_Development
• Cohn, Mike. Mountaing Goat Software. [En línea] [Citado el: 01 de 04 de 2010] http://www.mountaingoatsoftware.com/scrum/figures
Referencias
• Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. [En línea] [Citado el: 09 de 12 de 2010] http://agilemanifesto.org/
• Scott W. Ambler. Agile Requirements Change Management [En línea] [Citado el: 09 de 12 de 2010] http://www.agilemodeling.com/essays/agileRequirements.htm
• Shelly Park and Frank Maurer, "The Requirements Abstraction in User Stories and Executable Acceptance Tests," in Agile 2008, Toronto, 2008.
• http://en.wikipedia.org/wiki/Feature_Driven_Development
• http://www.petercoad.com/download/bookpdfs/jmcuch06.pdf
• http://pisis.unalmed.edu.co/cursos/material/3004582/1/PresentacionFDD.ppt
• http://www.nebulon.com/fdd/
• http://elvex.ugr.es/decsai/java/pdf/8D-TDD.pdf
• http://download.microsoft.com/download/F/F/1/FF1C1D0C-3242-4DA3-9897-3C234C6DF711/SQL102005BA.ppt
• http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/
• http://msdn.microsoft.com/en-us/magazine/gg490346.aspx
• http://dannorth.net/introducing-bdd/
• http://pages.cpsc.ucalgary.ca/~parksh/Publications/index.html
Referencias
• http://ase.cpsc.ucalgary.ca/uploads/Publications/ParkMaurerXP2009.pdf
• http://www.craiglarman.com/wiki/index.php?title=Agile_Acceptance_Test-Driven_Development:_Requirements_as_Executable_Tests
• http://c2.com/cgi/wiki?UserStory
Referencias
Versiones
Versión Fecha Comentarios Autor
1.0.0_Draft_A Sep-2011 Versión inicial Natalia Andriano
1.0.0_draft_B Ago-2012 Cambios para resaltar TDD
Natalia Andriano
1.0.0 May-2013 Baseline Natalia Andriano