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