• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ingenieria del software y metodologias agiles
 

Ingenieria del software y metodologias agiles

on

  • 539 views

 

Statistics

Views

Total Views
539
Views on SlideShare
539
Embed Views
0

Actions

Likes
1
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Ingenieria del software y metodologias agiles Ingenieria del software y metodologias agiles Presentation Transcript

    • Ingeniería del software y metodologías ágilesRodrigo Corralrcorral@plainconcepts.comhttp://geeks.ms/blogs/rcorralMVP Team System / CSM / CSPPlain Concepts
    • Ingeniería del softwareIntegración TDD ATDD continua Mock Gated Checkins SCM Documentación Comunicación Calidad Testeo Unitario ROI Gestión de la Construcción configuración Gestión del automatizada cambio
    • SOCORRO ! Pruebas unitarias Gestión de la configuración Integración continuaMás en próximos capítulos… ;)
    • ¿Qué es la ingeniería del software?
    • ¿Es posible la agilidad sin buenosfundamentos de ingeniería del software? Posible, quizás… Probable… ¡NO!
    • Pruebas unitarias• La detección más temprana posible• Demostración de que no hemos roto nada• Documentación• Marcador claro de que una tarea está completada• Mejora el diseño• Verifica la correcta corrección de errores• El tiempo de depuración se reduce
    • Pruebas unitarias• ¿Cómo son las buenas pruebas unitarias? – Se ejecuta rápido, se ejecuta rápido, se ejecuta rápido – Tiene escasas dependencias – Su alcance es claro y limitado – Se ejecutan y pasan de manera independiente. – Revelan claramente su intención – Tienen la mayor cobertura posible – No alteran el estado del sistema
    • Gestión de la configuración• Desarrollo concurrente y en equipo• ‘Aislar’ el entorno de pruebas• Lograr incrementos de funcionalidad potencialmente entregables• Habilitar mecanismos ágiles y operativos para la corrección de errores
    • Desarrollo concurrente y en equipo Estructura de ramas Estructura de carpetas DEV-401 $ PROJECTAntes de comenzar DEV-402 + DEV a trabajar en unahistoria de usuariocreamos una rama - FEATURES Branch Branch + RI RI sobre la que DEV-401 realizamos el desarrollo DEV + DEV-402 Concluido el desarrollo de la historia de usuario, integramos el código en la rama principal de desarrollo
    • ‘Aislar’ el entorno de pruebas Estructura de ramas Estructura de carpetas DEV-401 $ PROJECT DEV-402 + DEV RI - Branch FEATURES Branch RI + DEV-401 DEV + DEV-402 Branch RI MAIN + MAIN Cuando se cumplen las Cuando se cumplen las condiciones de calidad el código condiciones de calidad el código en desarrollo se integra en la ramaen desarrollo se integra en la rama MAIN para que los testers MAIN para que los testers comiencen el trabajo de comiencen el trabajo de estabilización estabilización
    • Incrementos de funcionalidad potencialmente entregables Estructura de ramas Estructura de carpetas DEV-401 $ PROJECT DEV-402 + DEV RI - Branch FEATURES Branch RI + DEV-401 DEV + DEV-402 Branch RI Fin de Sprint MAIN + MAIN Usar ramas de característicaRealizar el desarrollo de nuevas garantiza que a la rama principal, funcionalidades sobre ramas sobre la que realizamos la dedicadas permite que si una estabilización del software, solo funcionalidad no se completa a contendrá característicastiempo para incluirla en el Sprint completas y que han alcanzado un Review el resto de la base de mínimo de calidad que permita código principal siga siendo que el trabajo de los testers sea coherente y no incluya productivo características incompletas
    • Corrección de errores Los errores que no son urgentes se corrigen sobre la línea principal de desarrollo y se llevan Estructura de ramas a las ramas de release, Estructura de carpetas si es necesario, DEV-401 haciendo merge del $ PROJECT changeset asociado a la corrección del error DEV-402 + DEV RI - Branch FEATURES Branch RI + DEV-401DEV + DEV-402 Branch RI RI FIMAIN + MAIN Branch RI V1.0.1 FI + RELEASE RELEASE 1.0 Contar con una rama de V1.0 (hotfix) + RELEASE x.y.z RELEASE nos permite liberar parches de emergencia, para ‘showstopers’, minimizando losposibles impactos sobre el entorno de producción y minimizando las necesidades de validación por parte de los testers
    • Construcción automatizada• Construcción automatizada: patrón ‘one command complete build’• ¿Qué es completo? – Define tu nivel de completo para tu ‘build’.• Automatiza, automatiza, automatiza.• Se puede compilar un kernel luego se puede compilar automáticamente tu proyecto.• ¡No hay escusas!• Entorno neutral – En mi máquina compila. – En mi máquina pasan los test. – En mi máquina funciona.
    • Integración continua• Precondición: construcción automatizada.• Detección más temprana posible de: – Errores de integración. – Regresiones en las pruebas unitarias.• Evita que la ejecución de los test unitarios se supedite a la voluntad del desarrollador.• Debe proteger todas las ramas donde se integra código.• Ocurre en cada check-in.• Si se rompe una build la prioridad es corregirla.
    • Integración continua Source Control Client 6 Build Service Execute Build 1 Check In Build Build Drop Scripts and Site Targets 7 2 Store changeset Source Build Server Copy Binaries Control Repository Service 5 Start Build Source Control 3 8Poll for changes Build Finished 4 Retrieve latest version Continous Integration Service Build Store 9 Continuous Integration Server Store Build Data
    • Integración contínua• Ventajas: – Los problemas de integración se detectan y corrigen continuamente. – Alerta temprana de código erroneo/incompatible. – Test unitario inmediato de todos los cambios. – Disponibilidad total de una build “actual” para una demo de pruebas o para ser liberada. – El impacto inmediato del check in de código erroneo actua como actua como incentivo para no meter la pata.
    • Integración contínua• Inversiones: – Necesita mucho mantenimiento. – Necesita servidores de compilación. – El impacto de los fallos actua como incentivo negativo para hacer check-ins frecuentes (backup check-in). – El código erroneo solo se detecta una vez añadido al repositorio.
    • Gated check-ins• Cuando se rompe la build – Es tarde el código ya está integrado• Todo el equipo se ve afectado• Alternativa: gated check-ins.
    • ¿Preguntas?