Proyecto de Ingeniera de

Software - 2003

Desarrollo con Genexus

Ing. de Software

Procesos para Desarrollo con GX

ModsGX Adaptacin de RUP a Genexus
GXP Adaptacin de XP a Genexus
Tienen en Comn:
Procesos iterativos e incrementales
Enfocados a mitigar el riesgo
Divididos en iteraciones
Se entregan peridicamente productos al
cliente
2

Rational Unified Process

Proceso disciplinado sobre el
desarrollo de software con el
fin de hacerlo ms predecible
y eficiente.
Guiado por casos de uso,
centrado en la arquitectura
Disciplinas y actividades con
alto nivel detalle
Roles y responsabilidades
definidas
La crtica ms frecuente a esta metodologa es que es
burocrtica.
Hay tanto que hacer para seguir la metodologa que el ritmo del
desarrollo se retarda.

Roles
Analista
Arquitecto
Responsable de Verificacin
Asistente de Verificacin
Implementador
Responsable del Consolidado
Responsable del Ncleo

Responsable SCM
Responsable de SQA
Administrador
Especialista Tcnico
Java y Configuracin
Genexus y Base de Datos

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

Extreme Programming
Metodologa de desarrollo gil
Busca un justo medio entre ningn proceso y
demasiado proceso
Diferencias:
menos orientado al documento, exigiendo
una cantidad ms pequea de documentacin
para una tarea dada.
la parte importante de la documentacin es
el cdigo fuente.
Orientado a la gente y no al proceso
El cambio es bienvenido
6

El Costo del Cambio

Segn los libros tradicionales de
Ingeniera de Software:

Segn XP el costo del cambio,

no crece con el tiempo:

Debido a esta creencia, XP realiza las grandes decisiones lo mas

atrs en el tiempo posible, para diferir el costo de tomar la
decisin
Es por esto que se debe implementar lo que hay que hacer, sin la
necesidad de anticiparse al maana.
Las prcticas que ayudan son:
Diseo simple, sin agregar elementos extras que no sern usados,
pero se espera que se usen en el futuro
Pruebas automticas
Mucha practica en modificar el diseo

Cuatro Valores
Los cuatro valores en los que se basa XP son:
Comunicacin
Simplicidad
Feedback ( Retroalimentacin)
Coraje

Comunicacin:
Comunicacin entre todos los miembros del equipo
Comunicacin con el cliente
Simplicidad:
XP propone el principio de hacer la cosa ms simple que pueda
funcionar y cambiarlo maana si es necesario.
Es mejor hacer algo simple hoy, que hacerlo ms complicado
hoy y probablemente nunca usarlo.

Cuatro Valores
Retroalimentacin :
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
retroalimentacin durante el camino es mejor que
tratar de adivinar todo con anticipacin.
Se requiere valor para mantener el sistema simple,
dejando las decisiones de maana.

Historias de Usuario
Su propsito es anlogo 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 tcnica.
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 aceptacin)

10

Las 12 prcticas
Programacin por pares
40 horas semanales
Integracin continua
Estndares de codificacin
Propiedad colectiva
Pruebas automatizadas
Pequeas liberaciones
El juego de la Planificacin
Metfora
Diseo simple
Refactorizar
Cliente en el lugar

Ninguna de las
practicas establece
algo por si mismas

Requieren de
otras practicas
para poder
balancearse

11

Programacin por pares

Las 12 prcticas

Todo el cdigo es producido con dos programadores en

una mquina con 1 teclado y un mouse
El que usa el teclado y el mouse: Piensa la mejor forma de
implementar el mtodo
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 dinmicos

12

40 Horas Semanales

Las 12 prcticas

La regla es no trabajar ms 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 ms de 20 horas dos semanas
seguidas

13

Integracin continua

Las 12 prcticas

El cdigo es integrado y probado al menos una vez

por da de desarrollo.
Para GXP: Cada 3 das (2 veces por semana) al menos

Una manera simple de hacer esto es tener una

mquina dedicada a la integracin. Cuando esta
libre, un par carga la ultima liberacin, carga sus
cambios, resuelve las posibles colisiones y corre
las pruebas hasta que pasen el 100%
Si las pruebas no corren, debemos volver atrs,
dado que ese requerimientos no fue terminado
Si no se integra rpidamente, la chance de
conflictos crece y el costo de la integracin crece
desmesuradamente
14

Estndares de Codificacin

Las 12 prcticas

Escribir el codigo siguiendo reglas enfatiza la

comunicacin a travs del cdigo
El estndar debe pedir la menor cantidad de
trabajo posible
Si todos los programadores pueden cambiar
cdigo, cambiando de pares, se debe tener
estandarizada la forma de escribir cdigo

15

Pruebas automatizadas

Las 12 prcticas

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 lnea 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
16

Las 12 prctica

Propiedad y Responsabilidad Colectiva

Cualquiera puede cambiar cualquier cdigo 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 estndares
17

Pequeas liberaciones

Las 12 prcticas

Poner un sistema simple rpidamente en produccin 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 planificacin ayuda a trabajar en las
historias de mas valor
Las pruebas reducen la tasa de defectos
Se realiza un diseo simple, suficiente para esta
liberacin
GXP: Sistema liberado en semana 13 del proyecto (3
meses)

18

El juego de la Planificacin

Las 12 prcticas

Objetivo: Planificar el alcance de la liberacin,

maximizando el valor del software producido
Participantes:
Los clientes deciden sobre: Alcance, Prioridad
Los desarrolladores deciden sobre:

Estimaciones
Consecuencias tcnicas
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 liberacin ms corta, que le
brinde mayor valor para el negocio

19

Metfora

Las 12 prcticas

Visin comn:
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
bsicos y sus relaciones.
El cliente se siente cmodo hablando del sistema en
trminos de la metfora

La metafora permite una arquitectura que es

fcil de comunicar y construir
20

Diseo Simple

Las 12 prcticas

El sistema debe ser diseado tan simple como sea

posible en un momento dado.
Que es simple? : El mejor diseo, es aquel ms simple
que corre todos los casos de prueba.
Para XP simple significa (en orden de prioridad)

EL sistema (cdigo y casos de prueba) deben comunicar todo

lo que se deba comunicar
El sistema no debe contener cdigo duplicado
Debe tener la menor cantidad de clases
Debe tener la menor cantidad de mtodos

Esto es lo opuesto a disear para el maana, en XP se

hace lo que se necesita cuando se necesita
Simple no es fcil
21

Refactorizar

Las 12 prcticas

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 prximo requerimientos pueda ser
agregado con un esfuerzo razonable y el siguiente y
el siguiente..
22

Cliente en el Lugar

Las 12 prcticas

Un cliente real debe sentarse en el lugar,

disponible para contestar preguntas, resolver
disputas y prioridades de pequea escala.
Produce valor al proyecto escribiendo pruebas
de funcionalidad
Produce
valor
al
proyecto
realizando
priorizaciones de pequea escala y decisiones
sobre el alcance
En GXP:
Las historias las escriben algunos integrantes del
grupo (analistas)
Las pruebas funcionales las escriben los
verificadores
23

Principios
Jugar para ganar
Experimentos concretos
Comunicacin 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 rpido.
Solo hay que llevar lo que tiene valor para el
cliente: cdigo y pruebas
Mediciones honestas
24

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

25

Roles en XP - Desarrollador
Deben aprender, para tener destreza en:
Programacin por pares
Comunicacin y coordinacin con los otros programadores
El hbito 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 cdigo que escriben
Saber hacer refactoring
Probar unitariamente los mdulos

Responsabilizarse por estimar y completar su propio

trabajo
Medir el tiempo real, para de esa forma mejorar sus
estimaciones
26

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 decisin 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
27

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.

28

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 harn mejor la
prxima vez.
Es responsable adems de tener una visin
global.
Debe saber cuando no se esta pudiendo llegar
a finalizar la iteracin, para poder decrselo a
tiempo al equipo.
29

Roles en XP Entrenador (Coach)

El entrenador es responsable del proceso.
Cuando nota que una persona se esta desviando del
proceso, debe llamarle la atencin.
Debe entender XP en profundidad (que practicas
alternativas hay para una situacin, cuales son las
ideas detrs 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 situacin.
A medida que el equipo madura, este rol disminuye su
importancia. El proceso termina siendo responsabilidad
de todos
30

Agenda: Fases e iteraciones

Planificacin de la liberacin
Planificacin de iteracin

31

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)

32

Grupos que siguen XP

Programacin por pares (dinmicos)
Integrar y correr pruebas automatizadas
Seguir estandar de cdigo
Trabajar con gusto en grupo
Disponer de tiempo para reuniones
Conocimiento en todas las reas
Curso de Verificacin Automatizada
Rational Robot & Test Manager
18,19 y 20 de Agosto de 18 a 21 horas
Saln 115
33

Generalidades
Estudiar : Desarrollo de aplicaciones Web con
GX, curso no presencial
Clientes
Unidad de Enseanza
SeCiu

Docentes:

Gerardo Balbuena & Leandro Bustos

Beatriz Prez

Paginas web

ModsGX: www.fing.edu.uy/~t5ingsw
XP :
www.fing.edu.uy/inco/cursos/ingsoft/XP/index.htm

Pasantes (6)

34