Maestr í a en Ingenier í a de Software 2006 Me todolog í as de Desarrollo de Software Á giles

5
Maestría en Ingeniería de Software 2006 Metodologías de Desarrollo de Software Ágiles Germán A. Montejano

description

Maestr í a en Ingenier í a de Software 2006 Me todolog í as de Desarrollo de Software Á giles. Germán A. Montejano. - PowerPoint PPT Presentation

Transcript of Maestr í a en Ingenier í a de Software 2006 Me todolog í as de Desarrollo de Software Á giles

Page 1: Maestr í a en Ingenier í a de Software 2006 Me todolog í as de Desarrollo de Software  Á giles

Maestría en Ingeniería de Software 

2006

Metodologías de Desarrollo de Software Ágiles

Germán A. Montejano

Page 2: Maestr í a en Ingenier í a de Software 2006 Me todolog í as de Desarrollo de Software  Á giles

Práctico # 1Metodologías Ágiles

1. Fundamentar reducciones en el costo de cambio de requerimientos en una metodología que cumple los principios Ágiles. (Comenzar con la curva clásica, de cualquier libro de ingeniería de software)

2. Evaluar el costo de cambios desde una perspectiva del cliente. ¿Es similar la necesidad del cliente si se usa una metodología tradicional? (¿Es similar el tratamiento de la necesidad del cliente (Valor vs. Costo) usando una metodología Tradicional o Ágil?)

3. Si vemos un libro de requerimientos como una orden de trabajo, y las correspondientes estimaciones como el presupuesto, el contrato de la empresa de software con su cliente es bastante directo. Bosqueje como sería un contrato usando una metodología ágil que implemente la misma aplicación.

Page 3: Maestr í a en Ingenier í a de Software 2006 Me todolog í as de Desarrollo de Software  Á giles

Práctico # 2Sinergia de las prácticas de XP

1. Determinar para cada práctica cuáles son las prácticas que la soportan (marcándolas en la grilla con una X).

2. Elegir 3 de ellas y explicar por que las practicas señaladas la soportan.

(A modo de ejemplo se señalan 4 prácticas que soportan el Collective Code Ownership)

1. Testing automatizado nos va a permitir conocer si se introdujeron bugs.

2. Pair programming reduce la probabilidad de cambiar algo de manera errónea, al tener un compañero que nos lo puede indicar.

3. Continuous integration nos va a permitir reducir la probabilidad de conflictos.

4. Coding standards nos permite que luego del cambio la estructura del código sea similar.

Page 4: Maestr í a en Ingenier í a de Software 2006 Me todolog í as de Desarrollo de Software  Á giles

Práctico # 2 (cont.)Sinergia de las prácticas de XP

PracticeThe Planning

Game Frequent, Small

Releases System Metaphor Simple Design

Test Driven Deveopment

Refactoring Pair Programming Collective Code

Ow nership Continuous Integration

40-hour w ork w eek

On-site Customer Coding Standard

The Planning Game

Frequent, Small Releases

System Metaphor

Simple Design

Test Driven Deveopment

Refactoring

Pair Programming

Collective Code Ow nership

X X X X

Continuous Integration

40-hour w ork w eek

On-site Customer

Coding Standard

Page 5: Maestr í a en Ingenier í a de Software 2006 Me todolog í as de Desarrollo de Software  Á giles

Práctico # 3Desarrollo en XP

Especificar las historias de usuario del dominio de la práctica que desarrollaron en el módulo anterior.Usando las historias de usuario, confeccionar las fichas de tareas en las que se descomponga cada una.Para cada una de las fichas de tareas confeccionadas desarrolle los casos de test que deberían usarse para la prueba del módulo de software que se construirá correspondiente a tal ficha de tarea.Construir dos módulos de software correspondientes a dos fichas de tareas en algún lenguaje a elección. Recordar que se debe refactorizar cuando sea necesario.Probar cada módulo con los casos de test desarrollados previamente.