Proyecto de Ingeniería de Software - 2003

1. Proyecto de Ingeniería de Software - 2003 Desarrollo con Genexus Ing. de Software

2. Procesos para Desarrollo con GX • ModsGX – Adaptación de RUP a Genexus • GXP – Adaptación de XP a Genexus Tienen en Común: • Procesos iterativos e incrementales • Enfocados a mitigar el riesgo • Divididos en iteraciones • Se entregan periódicamente productos al cliente

3. Rational Unified Process • Proceso disciplinado sobre eldesarrollo de software con el fin de hacerlo más predecible y eficiente. • Guiado por casos de uso, centrado en la arquitectura • Disciplinas y actividades con alto nivel detalle • Roles y responsabilidades definidas • La crítica más frecuente a estametodología es que es burocrática. • Hay tanto que hacer para seguir la metodología que el ritmodel desarrollo se retarda.

4. Roles • Analista • Arquitecto • Responsable de Verificación • Asistente de Verificación • Implementador • Responsable del Consolidado • Responsable del Núcleo • Responsable SCM • Responsable de SQA • Administrador • Especialista Técnico • Java y Configuración • Genexus y Base de Datos

5. Integrantes y Roles • ModsGX • 8 integrantes por grupo ( 2 grupos) • Roles: • Analista - Documentador de Usuario - Asistente de Verificacion - Instructor (Responsable de Analisis) • Analista - Implementador - Responsable del Consolidado • Responsable de Verificacion – Analista • Arquitecto - Coordinador de Desarrollo - Asistente de Verificacion • Responsable de SQA - Responsable de SCM • Administrador - Responsable de la Comunicacion - Asistente de Verificacion • Especialista Tecnico Genexus y Base de Datos - Implementador - Responsable de Nucleo • Especialista Tecnico Java y Configuracion - Implementador

6. Extreme Programming • Metodología de desarrolloágil • Busca un justo medio entreningún proceso y demasiado proceso • Diferencias: • menos orientado al documento, exigiendouna cantidad más pequeña de documentación para una tarea dada. • la parte importante de la documentación es elcódigo fuente. • Orientado a la gente y no al proceso • El cambio es bienvenido

7. Según los libros tradicionales de Ingeniería de Software: Según XP el costo del cambio, no crece con el tiempo: El Costo del Cambio • Debido a esta creencia, XP realiza las grandes decisiones lo mas atrás en el tiempo posible, para diferir el costo de tomar la decisión • Es por esto que se debe implementar lo que hay que hacer, sin la necesidad de anticiparse al mañana. • Las prácticas que ayudan son: • Diseño simple, sin agregar elementos extras que no serán usados, pero se espera que se usen en el futuro • Pruebas automáticas • Mucha practica en modificar el diseño

8. Cuatro Valores • Los cuatro valores en los que se basa XP son: • Comunicación • Simplicidad • Feedback ( Retroalimentación) • Coraje • Comunicación: • Comunicación entre todos los miembros del equipo • Comunicación con el cliente • Simplicidad: • XP propone el principio de hacer la cosa más simple que pueda funcionar y cambiarlo mañana si es necesario. • Es mejor hacer algo simple hoy, que hacerlo más complicado hoy y probablemente nunca usarlo.

9. Cuatro Valores • Retroalimentación : • Del cliente, del equipo y de los usuarios finales Coraje: • El coraje (valor) existe en el contexto de los otros 3 valores. • Se requiere coraje para confiar en que la retroalimentación durante el camino es mejor que tratar de adivinar todo con anticipación. • Se requiere valor para mantener el sistema simple, dejando las decisiones de mañana.

10. Historias de Usuario • Su propósito es análogo al de los casos de uso • Son escritas por el cliente, son las cosas que el sistema debe hacer • No son casos de uso, pero describen escenarios • Su formato son tres sentencias de texto escritas por el cliente, en su terminologia sin sintaxis técnica. • Cuando llega el momento de implementarla, los dasarrolladores van con el cliente y reciben una descripcion detallada de los requerimeintos, cara a cara • Conducen las pruebas funcionales (de aceptación)

11. Programación por pares 40 horas semanales Integración continua Estándares de codificación Propiedad colectiva Pruebas automatizadas Pequeñas liberaciones El juego de la Planificación Metáfora Diseño simple Refactorizar Cliente en el lugar Requieren de otras practicas para poder balancearse Las 12 prácticas • Ninguna de las practicas establece algo por si mismas

12. Programación por pares Las 12 prácticas • Todo el código es producido con dos programadores en una máquina con 1 teclado y un mouse • El que usa el teclado y el mouse: Piensa la mejor forma de implementar el método • La otra persona piensa si el enfoque es adecuado, si hay mas casos de prueba, si hay otra forma de simplificar el problema para que el problema desaparezca • Los pares son dinámicos

13. 40 Horas Semanales Las 12 prácticas • La regla es no trabajar más de 40 horas a la semana. • Nunca trabajar extra dos semanas seguidas • Para Proyecto de IS • La regla es trabajar 15 horas a la semana • Nunca trabajar más de 20 horas dos semanas seguidas

14. Integración continua Las 12 prácticas • El código es integrado y probado al menos una vez por día de desarrollo. • Para GXP: Cada 3 días (2 veces por semana) al menos • Una manera simple de hacer esto es tener una máquina dedicada a la integración. Cuando esta libre, un par carga la ultima liberación, carga sus cambios, resuelve las posibles colisiones y corre las pruebas hasta que pasen el 100% • Si las pruebas no corren, debemos volver atrás, dado que ese requerimientos no fue terminado • Si no se integra rápidamente, la chance de conflictos crece y el costo de la integración crece desmesuradamente

15. Estándares de Codificación Las 12 prácticas • Escribir el codigo siguiendo reglas enfatiza la comunicación a través del código • El estándar debe pedir la menor cantidad de trabajo posible • Si todos los programadores pueden cambiar código, cambiando de pares, se debe tener estandarizada la forma de escribir código

16. Pruebas automatizadas Las 12 prácticas • Pruebas unitarias: Los programamdores continuamente escriben pruebas unitarias, que deben correr sin defectos para poder continuar desarrollando. • Pruebas funcionales: Los clientes escriben pruebas para demostrar que los requerimientos se han completado • GXP: Verificador escribe pruebas funcionales • Crear y mantener un conjunto de pruebas que son corridas, luego de cada cambio para asegurar la calidad de la línea base • Si no se escriben pruebas automatizados, XP no funciona • XP: Las pruebas unitarias se realizan con Junit • GXP: Las pruebas unitarias y funcionales se realizan con Rational Robot

17. Las 12 prácticas Propiedad y Responsabilidad Colectiva • Cualquiera puede cambiar cualquier código en cualquier momento • Todos toman la responsabilidad por el sistema completo • Se integra a intervalos cortos de tiempo, para que los conflictos aparezcan lo antes posible • Se escriben y corren las pruebas para que los accidentes sean descubiertos • Se programa de a pares, se tiene menos probabilidad de cometer errores • Se adhiere a los estándares

18. Pequeñas liberaciones Las 12 prácticas • Poner un sistema simple rápidamente en producción y liberar versiones nuevas en ciclos cortos • Debe contener los requerimientos de mayor valor para el negocio y tener sentido como un todo. • El juego de planificación ayuda a trabajar en las historias de mas valor • Las pruebas reducen la tasa de defectos • Se realiza un diseño simple, suficiente para esta liberación • GXP: Sistema liberado en semana 13 del proyecto (3 meses)

19. El juego de la Planificación Las 12 prácticas • Objetivo: Planificar el alcance de la liberación, maximizando el valor del software producido • Participantes: • Los clientes deciden sobre: Alcance, Prioridad • Los desarrolladores deciden sobre: • Estimaciones • Consecuencias técnicas • Como se trabaja y como se organiza el trabajo • Agenda detallada • Las piezas: Historias de usuario • Tener en cuenta: • Implementar primero los requerimientos de mayor prioridad • Cuando la realidad sobrepasa el plan, modificar el plan. • El cliente debe escoger aquella liberación más corta, que le brinde mayor valor para el negocio

20. Metáfora Las 12 prácticas • Visión común: • Guiar todos los desarrollos compartiendo una historia simple de como el sistema trabaja como un todo • Vocabulario compartido: • Debe ayudar a todos a entender los elementos básicos y sus relaciones. • El cliente se siente cómodo hablando del sistema en términos de la metáfora • La metafora permite una arquitectura que es fácil de comunicar y construir

21. Diseño Simple Las 12 prácticas • El sistema debe ser diseñado tan simple como sea posible en un momento dado. • Que es simple? : El mejor diseño, es aquel más simple que corre todos los casos de prueba. • Para XP simple significa (en orden de prioridad) • EL sistema (código y casos de prueba) deben comunicar todo lo que se deba comunicar • El sistema no debe contener código duplicado • Debe tener la menor cantidad de clases • Debe tener la menor cantidad de métodos • Esto es lo opuesto a “diseñar para el mañana”, en XP se hace lo que se necesita cuando se necesita • Simple no es fácil

22. Refactorizar Las 12 prácticas • Los programadores restructuran el sistema sin cambiar su comportamiento para: • sacar duplicados • mejorar la comunicacion • Simplificar • agregar flexibilidad • Algunas veces se hace mas trabajo que el necesario para tener un requerimiento andando, pero se asegura que el próximo requerimientos pueda ser agregado con un esfuerzo razonable y el siguiente y el siguiente..

23. Cliente en el Lugar Las 12 prácticas • Un cliente real debe sentarse en el lugar, disponible para contestar preguntas, resolver disputas y prioridades de pequeña escala. • Produce valor al proyecto escribiendo pruebas de funcionalidad • Produce valor al proyecto realizando priorizaciones de pequeña escala y decisiones sobre el alcance • En GXP: • Las historias las escriben algunos integrantes del grupo (analistas) • Las pruebas funcionales las escriben los verificadores

24. Principios • Jugar para ganar • Experimentos concretos • Comunicación honesta y abierta • Aceptar responsabilidad • Viajar ligero: Los artefactos de XP son pocos, simples y valiosos. Los equipos de XP no llevan mucho equipaje ya que quieren ir rápido. • Solo hay que llevar lo que tiene valor para el cliente: código y pruebas • Mediciones honestas

25. Roles en XP • Desarrollador • Cliente • Verificador • Encargado de Registrar (Tracker) • Entrenador (Coach)

26. Roles en XP - Desarrollador • Deben aprender, para tener destreza en: • Programación por pares • Comunicación y coordinación con los otros programadores • El hábito de la simplicidad: cuando el cliente pide “ hacer esto y esto y esto”, estar preparados para discutir cuales de esas cosas son realmente necesarias y cuanto de cada uno. • Simplicidad en el código que escriben • Saber hacer refactoring • Probar unitariamente los módulos • Responsabilizarse por estimar y completar su propio trabajo • Medir el tiempo real, para de esa forma mejorar sus estimaciones

27. Roles en XP - Cliente • Entiende el dominio por trabajar en él. • Puede entender con ayuda de los desarrolladores, el valor que el software provee al dominio • Quiere liberar valor regularmente y no tiene miedo de liberar poco antes que nada • Puede tomar la decisión sobre que se necesita ahora y que luego • Acepta responsabilidad por el éxito o el fracaso del producto. • Debe confiar en el equipo de desarrollo

28. Roles en XP - Verificador • Este rol se focaliza en ayudar al cliente. • Ayuda al cliente a encontrar y escribir pruebas funcionales. • Es responsable por correr las pruebas regularmente y poner los resultados en un lugar visible.

29. Roles en XP – Encargado de Registrar • Hacer buenas estimaciones es esencial en XP. • Las personas estiman, luego se debe medir y decirles en cuanto se equivocaron en las estimaciones, de esa forma lo harán mejor la próxima vez. • Es responsable además de tener una visión global. • Debe saber cuando no se esta pudiendo llegar a finalizar la iteración, para poder decírselo a tiempo al equipo.

30. Roles en XP – Entrenador (Coach) • El entrenador es responsable del proceso. • Cuando nota que una persona se esta desviando del proceso, debe llamarle la atención. • Debe entender XP en profundidad (que practicas alternativas hay para una situación, cuales son las ideas detrás de XP y como se relacionan) • Debe todo el tiempo guiar al equipo y debe ver cuando intervenir o no al detectar un problema. • Debe hablar con las personas para que ellas resuelvan la situación. • A medida que el equipo madura, este rol disminuye su importancia. El proceso termina siendo responsabilidad de todos

31. Agenda: Fases e iteraciones Planificación de la liberación Planificación de iteración

32. Integrantes y Roles • GXP • 7 integrantes por grupo (2 grupos) • Roles: • Desarrollador – Verificador (1) • Analista – Desarrollador (1) • Analista - Encargado de registrar – Verificador (1) • Desarrolladores (4)

33. Grupos que siguen XP • Programación por pares (dinámicos) • Integrar y correr pruebas automatizadas • Seguir estandar de código • Trabajar con gusto en grupo • Disponer de tiempo para reuniones • Conocimiento en todas las áreas • Curso de Verificación Automatizada • Rational Robot & Test Manager • 18,19 y 20 de Agosto de 18 a 21 horas • Salón 115

34. Generalidades • Estudiar : Desarrollo de aplicaciones Web con GX, curso no presencial • Clientes • Unidad de Enseñanza • SeCiu • Docentes: • Gerardo Balbuena & Leandro Bustos • Beatriz Pérez • Paginas web • ModsGX: www.fing.edu.uy/~t5ingsw • XP : www.fing.edu.uy/inco/cursos/ingsoft/XP/index.htm • Pasantes (6)