1 / 5

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

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

arlen
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Maestría en Ingeniería de Software2006Metodologías de Desarrollo de Software Ágiles Germán A. Montejano

  2. 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) 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?) 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. Práctico # 1Metodologías Ágiles

  3. Determinar para cada práctica cuáles son las prácticas que la soportan (marcándolas en la grilla con una X). 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) Testing automatizado nos va a permitir conocer si se introdujeron bugs. Pair programming reduce la probabilidad de cambiar algo de manera errónea, al tener un compañero que nos lo puede indicar. Continuous integration nos va a permitir reducir la probabilidad de conflictos. Coding standards nos permite que luego del cambio la estructura del código sea similar. Práctico # 2Sinergia de las prácticas de XP

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

  5. 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. Práctico # 3Desarrollo en XP

More Related