PROGRAMACION PROGRAMACION PROGRAMACION PROGRAMACION EXTREMA Y EXTREMA Y

SOFTWARE LIBRESOFTWARE LIBRE

Julio 2008MSc.MSc. Miguel Miguel CotañaCotaña MierMier 1

CONTENIDOCONTENIDO

1.- PROGRAMACION EXTREMA

2.- SOFTWARE LIBRE

3.- SOFTWARE LIBRE Y XP3.- SOFTWARE LIBRE Y XP

2

Inicio de un Proyecto

Cualquier proyecto software nacepor la “necesidad” manifiesta delpor la “necesidad” manifiesta delnegocio u organización:

Corregir un defecto en unsistema existente;

Adecuar un sistema heredado;

Extender funciones yExtender funciones ycaracterísticas de unaaplicación existente;

Crear un producto nuevo. 3

Definición de I.S., según IEEE

La Ingeniería del software La Ingeniería del software es la aplicación de un enfoque sistemático,

disciplinado y cuantificable al desarrollo, operación y

mantenimiento del software; mantenimiento del software; es decir, la aplicación de la ingeniería al software.

4

Algunos conceptos

MétodoMétodo:: Procedimiento paraalcanzar un determinado fin. Losalcanzar un determinado fin. Losmétodos de la I.S. indican “cómo”construir técnicamente el software;Metodología: EnEn unun proyectoproyecto dededesarrollodesarrollo dede softwaresoftware lalametodologíametodología definedefine QuiénQuién debedebemetodologíametodología definedefine QuiénQuién debedebehacerhacer QuéQué,, CuándoCuándo yy CómoCómo debedebehacerlohacerlo;;Procedimiento: Método de ejecutaralgunas cosas;

5

ProcesoProceso:: Una secuencia de pasosdesarrollados para un propósito dado;desarrollados para un propósito dado;HerramientasHerramientas:: Las herramientas dela I.S. proporcionan un enfoqueautomático o semi-automático para elproceso y para los métodos;proceso y para los métodos;ModeloModelo:: Es la representación formalde un sistema. Es una abstracción dealgo, cuyo objetivo es comprenderloantes de construirlo. 6

¿Qué es la agilidad?

Un equipo ágil es un equiporápido que responde demanera apropiada a losmanera apropiada a los“cambios”:

Cambios en el softwareque se va a construir;que se va a construir;

Cambios entre losmiembros del equipo;

Cambios debidos a lasNTIC. 7

Modelos ágiles de proceso

La historia de la IS está llena de

decenas de descripciones ydecenas de descripciones y

metodologías, métodos de modelado

y notaciones, herramientas y

tecnologías obsoletas.

Los modelos ágiles se ajustan alLos modelos ágiles se ajustan al

manifiesto para el desarrollo de

software y a los 12 principios para

quienes quieren alcanzar la agilidad. 8

1.- Programación Extrema

9

La XP, es una metodología paraLa XP, es una metodología parael desarrollo de proyectossoftware que trata de darsolución a los problemas de laingeniería del software desdeingeniería del software desdeun enfoque completamentedistinto al tradicional.

10

La XP, recibe este calificativo porquedefiende un enfoque radical.defiende un enfoque radical.Reconoce las bondades de lasprácticas de las metodologíastradicionales y propone llevarlashasta su extremo:

“Si diseñar es bueno, diseñemos todo el tiempo”

“Si las pruebas son buenas, probemos todo el tiempo” 11

La XP utiliza un enfoque OO, como

su paradigma de desarrollo

preferido. La XP abarca un conjuntopreferido. La XP abarca un conjunto

de reglas y prácticas que ocurren

en el contexto de 4 actividades del

marco de trabajo:

Planeación;

Diseño;

Codificación;

Prueba.12

Proceso de desarrollo extremo

HistoriasHistorias del usuariodel usuariovaloresvalores

Diseño simpleDiseño simplecartas CRCcartas CRC

Soluciones picoSoluciones picoprototiposprototipos

PlaneaciónPlaneación

diseñodiseño

codificacióncodificación

pruebaprueba

valoresvalorescriterios de las pruebas de iteracióncriterios de las pruebas de iteraciónPlan de iteraciónPlan de iteración

refabricaciónrefabricación

pruebaprueba

Incremento de softwareIncremento de softwarevelocidad calculadavelocidad calculadadel proyectodel proyecto

LanzamientoLanzamiento

ProgramaciónProgramaciónen parejaen pareja

Integración continuaIntegración continua

Prueba de unidadPrueba de unidad

Pruebas de aceptaciónPruebas de aceptación 13

Valores de XP

Comunicación. Para ser efectiva,debe involucrar a todos losdebe involucrar a todos losparticipantes en el proyecto, y debe serlibre y sincera;

Simplicidad. Nunca debe perderse devista que el objetivo de un proyecto esvista que el objetivo de un proyecto esproporcionar valor al cliente; no esdemostrar la pericia técnica del equiponi construir una aplicación que resuelvamás problemas que los del cliente; 14

Refabricación. No se puede dirigiradecuadamente un proceso si no sedispone de realimentación permanentedispone de realimentación permanentesobre su progreso. La realimentaciónpuede provenir del cliente, de losprogramadores, de herramientasautomáticas, etc.

Coraje. A veces, hacer lo que es correctoCoraje. A veces, hacer lo que es correctorequiere valor. Por ejemplo, hay quetener coraje para reescribir código quefunciona pero ha alcanzado su límite deescalabilidad.

15

Principios de la XP

Los valores mencionados dan origen acinco principios básicos:cinco principios básicos:

1.- Conseguir realimentación rápida;

2.- No complicar las cosas consuposiciones (asumir que lascosas son simples);cosas son simples);

3.- Realizar cambios incrementales;

4.- Abrazar el cambio;

5.- Generar productos de calidad. 16

Prácticas de la XP

Los principios se manifiestan a travésde las prácticas de XP.

Son actividades que el equipo de unSon actividades que el equipo de unproyecto lleva a cabo cada día. Las 12prácticas de la XP tienen su origen enprácticas conocidas en la IS y en elsentido común. Sin embargo, lo quesentido común. Sin embargo, lo quecaracteriza a este conjunto es lacohesión de todos los elementos, y quecada práctica ha sido llevada alextremo: 17

1. El juego de la planificación. Estapráctica busca dividir la funcionalidadpráctica busca dividir la funcionalidadde un proyecto en pequeñosfragmentos autocontenidos, c/u de loscuales se denomina historia de usuario.

2. Entregas frecuentes. Se trata de2. Entregas frecuentes. Se trata depublicar una nueva versión en cuantosea posible aportar algún nuevo valoral cliente.

18

3. Diseño simple. El sistema debe serel más simple posible que cumplael más simple posible que cumplaespecificaciones (pruebas deaceptación). En un entorno donde losrequisitos del cliente y sus prioridadescambian continuamente, no tienesentido realizar un diseño sofisticado. Lasentido realizar un diseño sofisticado. Lamejor forma de obtener una idea de losfuturos requisitos de un sistema esproporcionar cuanto antes un prototipoal cliente y obtener realimentación;

19

4. Pruebas automáticas. ¿Cómopuede saber un programador que elpuede saber un programador que elcódigo que ha escrito funcionarealmente? ¿Cómo puede saber queseguirá funcionando siempre, inclusoaunque lo refactorice?

La única manera de asegurarlo conLa única manera de asegurarlo concierta confianza es escribiendo pruebasautomáticas con las que puedacomprobar el código en cualquiermomento y sin esfuerzo.

20

5. Integración continua. Nuevamente selleva al extremo una práctica convencionallleva al extremo una práctica convencionalde la ingeniería del software.Si la integración es una fase crucial, en laque pueden aparecer errores, ¿por quédejarla para el final, cuando el riesgo esmayor? Resulta más conveniente realizarmayor? Resulta más conveniente realizarintegración continua (cada hora, cada día).Para poder hacerlo, es imprescindible que elproceso de integración esté automatizado ypueda verificarse mediante pruebas.

21

6. Refactorización. La refactorizaciónes un proceso disciplinado por el cuales un proceso disciplinado por el cualse modifica el diseño de un módulo sinafectar a su comportamiento externo.

Gracias a la refactorización, es posiblecompatibilizar el diseño simple con lacompatibilizar el diseño simple con laflexibilidad.

El coraje para refactorizar proviene dela disponibilidad de pruebasautomáticas. 22

7. Programación por parejas. Llevar alextremo una práctica habitual: las revisionesextremo una práctica habitual: las revisionesformales de código. Si revisar el código esbueno, ¿por qué no revisarlo continuamente,incluso desde el mismo momento en el quese escribe por primera vez? En lase escribe por primera vez? En laprogramación por parejas, dosprogramadores comparten un únicoordenador y colaboran para escribir elcódigo o las pruebas 23

8. Propiedad colectiva del código. En eltranscurso de una refactorización, o mientrasse corrige un defecto, algún programador vaa tener que modificar líneas de códigoescritas por otro programador.XP invita a llevar a cabo esa modificacióncon coraje, y el coraje procede de lascon coraje, y el coraje procede de laspruebas automáticas. Esta práctica permiteque funcionen bien los equipos dinámicos,cuya composición puede variar durante elproyecto.

24

9. Semana de 40 horas. Los programadorescansados se equivocan más. Si las semanascansados se equivocan más. Si las semanasde más de 40 horas son la norma, algo nofunciona bien en el proyecto o en laempresa;10. Metáfora . El objetivo de esta práctica es10. Metáfora . El objetivo de esta práctica esencontrar una metáfora que ayude al equipodel proyecto y al cliente a hablar en losmismos términos, compartiendo una visióncomún del sistema; 25

11. Cliente en el equipo. Para lograruna realimentación ágil, el cliente nouna realimentación ágil, el cliente nopuede estar muy lejos del equipo; enuna situación ideal, el cliente debe estardentro del equipo.

12. Estándares de codificación. Esuna necesidad cuando se trata deuna necesidad cuando se trata deescribir código que otrosprogramadores puedan entender ymodificar.. 26

2.- Software Libre

27

SOFTWARE LIBRE

“Software Libre'' se refiere a la libertad de los usuarios paralibertad de los usuarios paraejecutar, copiar, distribuir,

estudiar, cambiar y mejorar el software. De modo más

preciso, se refiere a cuatropreciso, se refiere a cuatrolibertades de los usuarios del

software.28

Libertad de los usuarios

La libertad de usar el programa, concualquier propósito;

La libertad de estudiar cómo funcionaLa libertad de estudiar cómo funcionael programa, y adaptarlo a susnecesidades;

La libertad de distribuir copias, con loque puedes ayudar a tu vecino;que puedes ayudar a tu vecino;

La libertad de mejorar el programa yhacer públicas las mejoras a losdemás, de modo que toda lacomunidad se beneficie.

29

CopyRight

Nació para beneficiar a los usuarios (losque leen libros, escuchan música outilizan software), no para beneficiar autilizan software), no para beneficiar alos editores o los autores.

La Constitución permite que seconcedan derechos de copyright a losautores. En la práctica, normalmenteautores. En la práctica, normalmentelos autores se los ceden a los editores;son los editores, y no los autores,quienes suelen ejercer los derechos yquienes se quedan con los beneficios.

30

CopyLeft

Es un método para convertir unEs un método para convertir unprograma en software libre y exigirque todas las versiones del mismo,modificadas o ampliadas, también losean.

La forma más sencilla de hacer queLa forma más sencilla de hacer queun programa sea libre es ponerlo enel dominio público, sin derechosreservados.

31

Patentes

La patente es un monopolioabsoluto sobre el uso de una idea.absoluto sobre el uso de una idea.Incluso si pudieras probar que laidea es tuya, sería completamenteirrelevante si la idea ha sidopatentada por otro.patentada por otro.

Las patentes de softwaresubordinan a todo desarrollador desoftware y a todo usuario a unanueva forma de burocracia. 32

33

MODELO DE DESARROLLO SL

Raymond, cataloga el modelo dedesarrollo del software libre como undesarrollo del software libre como unmodelo donde no existe un ordenestricto de creación, sino que se tratamás bien de un caos en el desarrollo.

El interactuar entre los diferentesactores no esta controlado por ningúnEl interactuar entre los diferentesactores no esta controlado por ningúntipo de persona ni entidad, sino queexiste una gran cantidad de interesesy de intercambios de diferentes tipos.

34

¿Cuál es la metodología, si ¿Cuál es la metodología, si es que existe alguna, que siguen los proyectos de

software libre?

NO es posible dar una NO es posible dar una respuesta en términos

absolutos!!!35

Raymond, catalogó el modelo dedesarrollo de algunos (no todos)proyectos de software libre como elproyectos de software libre como elmodelo de bazar.

La metodología tradicional se podíacomparar con la construcción decatedrales, donde existía un granarquitecto que hacía el diseño y elarquitecto que hacía el diseño y elreparto de tareas, para queposteriormente un conjunto deoperarios y peones realizaran lasoperaciones pertinentes. 36

En el modelo de bazar, por el contrario,no existe ese orden tan estricto, sinono existe ese orden tan estricto, sinoque se asemeja más bien al caos quese forma en un bazar oriental. Lamanera de interactuar entre losdiferentes actores en el caso del bazarno está controlada por ningún tipo deno está controlada por ningún tipo depersonas ni entidades, sino que existeuna enorme cantidad de intereses y deintercambios de diferentes tipos(transacciones). 37

HERRAMIENTAS DESARROLLO

El proceso de desarrollo debe ser lomás abierto posible, ya que es posiblemás abierto posible, ya que es posibleque crezcan las erratas con usuariosque tienen acceso al código.

La herramienta que mejor se adapta aesta necesidad es un sistema decontrol de versiones abierto al público.control de versiones abierto al público.

La última versión (y todas lasanteriores) del código estará disponiblepara todo aquél que lo desee. 38

Práctica XP Modelo bazar Herramientas

Juego de la planificación

Entregas frecuentes Release soon, release often

Relación

often

Diseño simple

Pruebas automáticas JUnit, HttpUnit, DbUnit...

Integración continua Repositorios, nightlybuilds, unstable

CVS, SVN, Ant, CruiseControl...

Refactorización Eclipse

Programación por parejas

Propiedad colectiva del código GPL y otras licencias CVS, SVNPropiedad colectiva del código GPL y otras licencias libres

CVS, SVN

Semana de 40 horas

Cliente en el equipo Realimentación de bugs y feature requests

Bugzilla, listas de correo, foros...

Metáfora

Estándares de codificación Guías de estilo Jalopy, Indent, JCSC...39

3.- Software Libre y XP

40

CARACTERÍSTICAS

Un buen proyecto comienza a partir de lasideas o necesidades del programador;Los buenos programadores saben quéescribir. Los mejores, qué reescribir (yreutilizar);"Planee desechar algo; de todos modostendrá que hacerlo.“;tendrá que hacerlo.“;Publicar el código fuente bajo algunalicencia de Software Libre;Propiedad colectiva del código; 41

Tratar a los usuarios como colaboradoreses la forma más apropiada de mejorar elcódigo, y la más efectiva de depurarlo;código, y la más efectiva de depurarlo;Liberar rápido y muy seguido, escuchandoa los clientes;Si los colaboradores son el recurso másvalioso, ellos responderán convirtiéndosevalioso, ellos responderán convirtiéndoseen el recurso más valioso;Lo más importante, después de tenerbuenas ideas, es reconocer las buenasideas de los usuarios.

42

PRÁCTICAS DE ADAPTACION

Carga de trabajo de 40 horassemanales;

Cliente en casa;Cliente en casa;

El juego de planificación:

No hay cliente que dificulte laplanificación;

Los proyectos se crean paraLos proyectos se crean parasatisfacer necesidades personales(no hay historias);

Programación por parejas.43

PRÁCTICAS INTERESANTES

Metáfora

Que todos hablen el mismo idiomaQue todos hablen el mismo idiomay que nuevos desarrolladores loadapten en forma temprana;

Utilización de patrones de diseño;

Mejorar la falta de información queexiste en el software.

44

RefactorizaciónRefactorización

En vez de corregir códigoerróneo se reescriba;

Mejores códigos permiten queMejores códigos permiten quenuevos desarrolladores entrenen el proyecto.

45

INTERROGANTES Y RETOS

Compatibilidad hacia atrás ydependencias;

Interrogantes económicos ypsicológicos:

dificultad de estimar cuánto va acostar un proyecto;

sería interesante tener algunasería interesante tener algunaforma de hacerlo de manera más omenos exacta para el desarrollo desoftware libre. 46

Efectos de la Refactorización;

Desarrolladores de softwareDesarrolladores de softwarelibre suelen adaptarserápidamente a nuevas ideas;

El éxito en la Adopción de XPdepende de la creación dedepende de la creación denuevas herramientas que lassoporten o que las existenteslas integren. 47

Conclusiones

La XP y el SL tienen algunos puntos encomún, pero también tienen aspectoscomún, pero también tienen aspectosdifícilmente conciliables.

La XP se beneficia de la existencia deherramientas de SL que permitenaplicarla con gran productividad. A suvez, el SL puede inspirarse en algunasvez, el SL puede inspirarse en algunasde las prácticas de la XP (diseñosimple, planificación y refactorización)para refinar su modelo de desarrollo ycontrolar mejor sus proyectos.

48

Muchas gracias

Preguntas…???

http://200.87.124.42/pagina/miguel_cotanamickycotana@gmail.com 49

Historia de usuarioNúmero: 1 Nombre: Enviar artículo

Usuario: Autor

Historias de usuarios

Usuario: Autor

Modificación de Historia Número: Iteración asignada: 2

Prioridad en negocio: Alta(Alta/Media/Baja)

Puntos estimados:

Riesgo en desarrollo(Alta/Media/Baja)

Puntos reales

Descripción:

Se introducen los datos del artículo (título, fichero adjunto,Se introducen los datos del artículo (título, fichero adjunto,tópicos) y de los autores (nombre, e-mail, afiliación). Uno de losautores debe indicarse como autor de contacto. El sistemaconfirma la correcta recepción del artículo enviando un e-mail alautor de contacto con su login y password para que el autorpueda posteriormente acceder al artículo

Observaciones: 50

Nombre de la clase: PEDIDO

Cartas CRC

Nombre de la clase: PEDIDO

Responsabilidades Colaboradores

Revisar si existen elementos en existencia

Línea de pedidos

Determinar el precio Línea de pedidos

Revisa si el pago es ClienteRevisa si el pago es válido

Cliente

Despacha a la dirección de entrega

51