Ing. de Software 1

Proyecto de Ingeniería de Software - 2003

Desarrollo con Genexus

2

Procesos para Desarrollo con GXModsGX – Adaptación de RUP a GenexusGXP – Adaptación de XP a Genexus

Tienen en Común:Procesos iterativos e incrementalesEnfocados a mitigar el riesgoDivididos en iteracionesSe entregan periódicamente productos al cliente

3

Rational Unified ProcessProceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Guiado por casos de uso, centrado en la arquitecturaDisciplinas y actividades con alto nivel detalleRoles y responsabilidades definidasLa crítica más frecuente a esta metodología es que es burocrática. Hay tanto que hacer para seguir la metodología que el ritmo del desarrollo se retarda.

4

RolesAnalistaArquitectoResponsable de VerificaciónAsistente de VerificaciónImplementador

Responsable del ConsolidadoResponsable del Núcleo

Responsable SCM Responsable de SQAAdministradorEspecialista Técnico

Java y ConfiguraciónGenexus y Base de Datos

5

Integrantes y RolesModsGX

8 integrantes por grupo ( 2 grupos)Roles:

Analista - Documentador de Usuario - Asistente de Verificacion - Instructor (Responsable de Analisis)Analista - Implementador - Responsable del ConsolidadoResponsable de Verificacion – AnalistaArquitecto - Coordinador de Desarrollo - Asistente de VerificacionResponsable de SQA - Responsable de SCMAdministrador - Responsable de la Comunicacion - Asistente de VerificacionEspecialista Tecnico Genexus y Base de Datos - Implementador - Responsable de Nucleo Especialista Tecnico Java y Configuracion - Implementador

6

Extreme ProgrammingMetodología de desarrollo ágilBusca un justo medio entre ningún proceso y demasiado procesoDiferencias:

menos orientado al documento, exigiendo una cantidad más pequeña de documentación para una tarea dada. la parte importante de la documentación es el código fuente.Orientado a la gente y no al procesoEl cambio es bienvenido

7

El Costo del Cambio Según los libros tradicionales de Ingeniería de Software:

Según XP el costo del cambio, no crece con el tiempo:

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 futuroPruebas automáticasMucha practica en modificar el diseño

8

Cuatro Valores Los cuatro valores en los que se basa XP son:

ComunicaciónSimplicidadFeedback ( 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 ValoresRetroalimentació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 UsuarioSu propósito es análogo al de los casos de usoSon escritas por el cliente, son las cosas que el sistema debe hacerNo 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 caraConducen las pruebas funcionales (de aceptación)

11

Las 12 prácticasProgramación por pares 40 horas semanalesIntegración continuaEstándares de codificaciónPropiedad colectivaPruebas automatizadasPequeñas liberacionesEl juego de la PlanificaciónMetáforaDiseño simpleRefactorizarCliente en el lugar

Ninguna de las practicas establece algo por si mismas

Requieren de otras practicas para poder balancearse

12

Programación por paresTodo 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étodoLa 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

Las 12 prácticas

13

40 Horas SemanalesLa regla es no trabajar más de 40 horas a la semana.Nunca trabajar extra dos semanas seguidas

Para Proyecto de ISLa regla es trabajar 15 horas a la semanaNunca trabajar más de 20 horas dos semanas seguidas

Las 12 prácticas

14

Integración continuaEl 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 menosUna 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 terminadoSi no se integra rápidamente, la chance de conflictos crece y el costo de la integración crece desmesuradamente

Las 12 prácticas

15

Estándares de CodificaciónEscribir el codigo siguiendo reglas enfatiza la comunicación a través del códigoEl estándar debe pedir la menor cantidad de trabajo posibleSi todos los programadores pueden cambiar código, cambiando de pares, se debe tener estandarizada la forma de escribir código

Las 12 prácticas

16

Pruebas automatizadasPruebas 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 baseSi no se escriben pruebas automatizados, XP no funciona XP: Las pruebas unitarias se realizan con JunitGXP: Las pruebas unitarias y funcionales se realizan con Rational Robot

Las 12 prácticas

17

Propiedad y Responsabilidad ColectivaCualquiera puede cambiar cualquier código en cualquier momentoTodos toman la responsabilidad por el sistema completoSe integra a intervalos cortos de tiempo, para que los conflictos aparezcan lo antes posibleSe escriben y corren las pruebas para que los accidentes sean descubiertosSe programa de a pares, se tiene menos probabilidad de cometer erroresSe adhiere a los estándares

Las 12 prácticas

18

Pequeñas liberacionesPoner un sistema simple rápidamente en producción y liberar versiones nuevas en ciclos cortosDebe 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ónGXP: Sistema liberado en semana 13 del proyecto (3 meses)

Las 12 prácticas

19

El juego de la PlanificaciónObjetivo: Planificar el alcance de la liberación, maximizando el valor del software producido Participantes:

Los clientes deciden sobre: Alcance, PrioridadLos desarrolladores deciden sobre:

EstimacionesConsecuencias técnicas Como se trabaja y como se organiza el trabajoAgenda detallada

Las piezas: Historias de usuarioTener 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

Las 12 prácticas

20

MetáforaVisió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

Las 12 prácticas

21

Diseño SimpleEl 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 comunicarEl sistema no debe contener código duplicadoDebe tener la menor cantidad de clasesDebe 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 necesitaSimple no es fácil

Las 12 prácticas

22

RefactorizarLos programadores restructuran el sistema sin cambiar su comportamiento para:

sacar duplicadosmejorar la comunicacionSimplificaragregar 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..

Las 12 prácticas

23

Cliente en el LugarUn 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 funcionalidadProduce 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

Las 12 prácticas

24

PrincipiosJugar para ganar Experimentos concretos Comunicación honesta y abierta Aceptar responsabilidadViajar 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 pruebasMediciones honestas

25

Roles en XPDesarrolladorClienteVerificadorEncargado de Registrar (Tracker)Entrenador (Coach)

26

Roles en XP - DesarrolladorDeben aprender, para tener destreza en:

Programación por paresComunicación y coordinación con los otros programadoresEl 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 escribenSaber hacer refactoringProbar unitariamente los módulos

Responsabilizarse por estimar y completar su propio trabajoMedir el tiempo real, para de esa forma mejorar sus estimaciones

27

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

28

Roles en XP - VerificadorEste 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

GXP7 integrantes por grupo (2 grupos)Roles:

Desarrollador – Verificador (1)Analista – Desarrollador (1)Analista - Encargado de registrar – Verificador (1)Desarrolladores (4)

33

Grupos que siguen XPProgramación por pares (dinámicos)Integrar y correr pruebas automatizadasSeguir estandar de códigoTrabajar con gusto en grupoDisponer de tiempo para reunionesConocimiento en todas las áreasCurso de Verificación Automatizada

Rational Robot & Test Manager18,19 y 20 de Agosto de 18 a 21 horasSalón 115

34

GeneralidadesEstudiar : Desarrollo de aplicaciones Web con GX, curso no presencialClientes

Unidad de Enseñanza SeCiu

Docentes:Gerardo Balbuena & Leandro BustosBeatriz Pérez

Paginas web ModsGX: www.fing.edu.uy/~t5ingswXP : www.fing.edu.uy/inco/cursos/ingsoft/XP/index.htm

Pasantes (6)