Programacin Extrema La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de software formulado por Kent Beck, autor

del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es la ms destacada de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software. Las caractersticas fundamentales del mtodo son: Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin. Vase, por ejemplo, las herramientas de prueba JUnit orientada a Java y DUnit orientada a Delphi e inspirada en JUnit. Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente interaccin del equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes. Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo. Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados. Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo. La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Mientras ms simple es el sistema, menos tendr que comunicar sobre este, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores.

Programacin Extrema I En la Ingeniera de Software existe lo que se llama Caso de Uso (ms bien esto existe en una metodologa de desarrollo de software llamada UML). Un conjunto de Casos de Uso definen qu debe hacer el sistema y cmo interactuar el usuario con el mismo. Sirven para: que los desarrolladores sepan qu funcionalidad deben implementar en el sistema, y que el cliente sepa qu har el sistema antes de que sea programado. Lamentablemente, el desarrollo dirigido por Casos de Uso es ms burocrtico que prctico: Los casos de uso son difciles de comprender por el cliente (ya que l no se dedica a la Ingeniera de Software), por lo tanto, difcilmente el cliente termine conforme con un sistema que fue desarrollado bajo Casos de Uso que ni l mismo entiende (o que ni el mismo ley). Pero por qu usar Casos de Uso? Para evitar perder dinero. Los Ingenieros en Sistemas de Informacin, como cualquier otro profesional capitalista, no quieren regalar nada. Si hacen algo pretenden hacerlo una vez, y si hicieron algo que no es "lo que el cliente quiere" por lo menos debe ser "lo que el cliente pensaba que quera". A qu me refiero con todo esto? Los Casos de Uso son como la sentencia de muerte del cliente, son el contrato que indica que "El cliente se compromete a pagarnos lo acordado si nosotros hacemos lo que los Casos de Uso establecen", en conclusin, cualquier cambio que el cliente pida una vez aceptados los Casos de Uso, debern ser negociados. Pero existen un gran problema: El cliente comprender lo errado de los Casos de Uso cuando pueda ver el sistema (o un prototipo) funcionando. Ah mismo comprender que no es lo que deseaba, pidiendo as modificaciones del sistema y generando lo que a m me gusta llamar como requerimientos en reversa, ya que no tan slo hay que modificar el sistema, sino que a partir de ste tambin hay que actualizar la documentacin de requerimientos (los Casos de Uso). Entonces mi conclusin es: si sabemos que nuestras mentes no son perfectas y somos incapaces de visualizar el negocio del cliente con total claridad, por qu intentamos utilizar una herramienta para dirigir todo el desarrollo completo de un Sistema de Informacin que sabemos que no le ser de utilidad al cliente? Lo hacemos slo para no perder dinero? Por qu no tratar de buscar nuevas formas de desarrollo que prevean las modificaciones y caprichos del cliente? Supongo que nuevos mtodos necesitan ser creados. Un intento es la programacin extrema (XP), que pretende una continua retroalimentacin con el usuario: debido a que l es el nico que conoce el negocio, es l quien mejor nos puede indicar qu debe hacer el sistema y cmo solucionar cualquier adversidad en el desarrollo. En otras palabras: tener al cliente a nuestra disposicin a cualquier momento para solucionar cualquier duda es crtico para el desarrollo gil de un sistema que haga lo que el cliente quiere que haga.

Proceso Unificado de Rational El Proceso Racional Unificado (RUP, el original ingls Rational Unified Process) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. RUP es en realidad un refinamiento realizado por Rational Software del ms genrico Proceso Unificado. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Principios de desarrollo [editar] El RUP est basado en 6 principios clave: Adaptar el proceso [editar] El proceso deber adaptarse a las caractersticas propias del proyecto u organizacin. El tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Balancear prioridades [editar] Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos. Colaboracin entre equipos [editar] El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados,etc. Demostrar valor iterativamente [editar] Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto. Elevar el nivel de abstraccin [editar] Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Esto previene a los ingenieros de software ir directamente de los requisitos a la codificacin de software a la medida del cliente. Un nivel alto de abstraccin tambin permite discusiones sobre diversos niveles arquitectnicos. stos se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con UML. Enfocarse en la calidad [editar] El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin Ciclo de vida [editar] [Ciclo de vida del Proceso Unificado.Un tpico perfil de proyecto mostrando el tamao relativo de las cuatro fases] El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al final de cada ciclo, cada ciclo se divide en fases que finalizan con un hito donde se debe tomar una decisin importante: Concepcin: se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos Elaboracin: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos

Construccin: se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario Implementacin: se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados. Principales caractersticas [editar] Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso).

Fases [editar] Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso Un poco de historia [editar] Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la investigacin. En 1995 Rational Software es comprada por una compaia sueca llamada Objectory AB. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory, proceso desarrollado por el fundador de Objectory Ivan Jacobson. El primer resultado de esta fusin fue el Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten. Comentarios sobre Alcance del RUP [editar] La metodologa RUP es ms apropiada para proyectos grandes, dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es posible que no sea posible cubrir los costos de dedicacin del equipo de profesionales necesario. Comentarios sobre Metodologa [editar] Por otro lado en lo que se refiere a la metodologa esta comprende tres frases claves. Dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental. En lo referente a dirigido por los casos de uso esta enfocado hacia el cliente y se utilizan , con algunas modificaciones tal vez, hasta la fase de pruebas. Una de las arquitecturas que esta vigente es la de 3 capas, y esta se le debera adaptar los casos de uso. Las capas son: presentacin, reglas de negocio y datos. Metodologas giles en el Desarrollo de Software En las dos ltimas dcadas las notaciones de modelado y posteriormente las herramientas han sido las "balas de plata" para el deseado xito en el desarrollo de

software. El proceso de desarrollo asumido en este contexto llevaba asociada una marcada tendencia hacia el control del proceso mediante una rigurosa definicin de actividades, artefactos y roles. Este esquema "tradicional" para abordar el desarrollo de software demostr ser efectivo en proyectos de gran envergadura donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. En la prctica, para muchos equipos de desarrollo, ante las dificultades para utilizar metodologas tradicionales, se lleg a la resignacin de prescindir del "buen hacer" de la ingeniera del software con el objetivo de ajustarse a estas restricciones. Ante esta situacin, las metodologas giles aparecen como una posible respuesta para llenar este vaco metodolgico. Por estar especialmente orientadas para proyectos pequeos, las metodologas giles constituyen una solucin a medida, con una elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del producto. Las metodologas giles son sin duda uno de los temas emergentes en ingeniera de software que estn acaparando gran inters. Las metodologas giles se estn haciendo un espacio destacado en la mayora de conferencias y workshops celebradas en los ltimos aos. Es tal su impacto que actualmente existen 4 conferencias internacionales de alto nivel y especficas sobre el tema (una en Europa, dos en EEUU y una en Australia), registrando una gran asistencia. Adems ya es un tema de interes con cabida en prestigiosas revistas internacionales tales como la IEEE Software. En la comunidad de la IS, se est viviendo con intensidad un debate abierto entre los partidarios de las metodologas tradicionales (referidas frecuentemente como "metodologas pesadas") y aquellos que apoyan las ideas emanadas del "Manifiesto gil". En los ltimos aos, diversos grupos en Espaa han dedicado parte de sus esfuerzos de investigacin a explorar la idoneidad de los mtodos giles, as como la aplicabilidad de las herramientas por ellos desarrolladas para soportar procesos ligeros de desarrollo. Hasta 7 grupos estn implicados en la red europea NAME (Network of Agile Methods Experience), germen de un posible proyecto europeo para el VI programa marco. El tema es de rabiosa actualidad. La curiosidad que siente la mayor parte de ingenieros de software, profesores, e incluso alumnos, sobre los mtodos giles hace preveer una fuerte proyeccin industrial de las metodologas giles. Por un lado, para muchos equipos de desarrollo el uso de metodologas tradicionales les resulta muy lejano a su forma de trabajo actual considerando las dificultades de su introduccin e inversin asociada en formacin y herramientas. Por otro, las caractersticas de los proyectos para los cuales las metodologas giles han sido especialmente pensadas se ajustan a un amplio rango de proyectos industriales de desarrollo de software; aquellos en los cuales los equipos de desarrollo son pequeos, con plazos reducidos, requisitos voltiles, nuevas tecnologas, etc. Esto ltimo abrira interesantes canales de cooperacin entre la industria y la universidad. El objetivo de este taller es constituir un punto de encuentro para acadmicos y gente de industria interesadas en metodologas giles (extensible a procesos de desarrollo de software, en general). Los mtodo giles se basan en la premisa de que los requerimientos de un sistema son difcilmente predecibles, por lo que un software altamente adaptable tiene mayores probabilidades de xito. Uno de mis mis intereses particulares es la Ingeniera de Calidad y una de mis

obsesiones es el estudio de sistemas dinmicos no lineales (caos). La calidad en muchos casos no es otra cosa que el control de la variabilidad (Ver la funcin de prdida de Taguchi). El control absoluto de esta variabilidad es imposible en muchos casos, sin embargo es posible entender un poco ms sobre esta variabilidad al dejar de lado el comportamiento lineal de los sistemas y encaminarnos hacia una anlisis no lineal. Al entender e identificar los patronesde fenmenos aparentemente caticos es posible lograr una aceptable predictibilidad. Sin embargo, para poder predecir sistemas altamente dinmicos se requieren de herramientas estadsticas y matemticas muy avanzadas que slo mediante una satisfactoria instrumentacin del proceso pueden ser efectivas. En el caso de una misin a Marte es indispensable poder ser capaz de predecir hasta el ltimo detalle de la misin, pero en muchos casos prcticos los niveles de satisfaccin permiten una mucho mayor variabilidad. En el caso del software nos encontramos con estas dos mentalidades chocando constantemente sin entender que hay espacio para ambas. Al definir un proyecto debemos saber exactamente con que recursos contamos precisamente porque dichos recursos son limitados y de ese modo podemos escoger. Como fantico de la calidad me inclino a la utilizacin de una Ingeniera de Software formal, mientras que como empresario, en muchas ocasiones he tenido que recurrir a soluciones como las que ofrecen las metodologas giles para poder sacar la chamba. Un gestor de proyecto siempre se enfrentar ante la disyuntiva entre planeacin y estrategia. El gran reto, es saber escoger entre ambas. Las metodologas giles fracasarn, como todas las dems metodologas, porque en informtica lo importante no son los procesos, sino el talento. Adems, porque aprovecharlas probablemente significa olvidarse de CMMIs, ISOs y dems siglas que les gusta a los tipos encorbatados que impiden que las cosas se hagan como se debe. Sin embargo, sus tcnicas estn aqu para quedarse: Testing: hacer pruebas es poco costoso y muy beneficioso. Permite desarrollar ms gilmente, sin intervencin de pesados servidores de aplicaciones. Detecta errores en cambios (cuntas veces las cosas dejan de funcionar y es el usuario el que lo detecta?). En Navegpolis listan herramientas de pruebas, a las que yo aado las siguientes: o JMeter: pruebas de carga y funcionales. o BadBoy: un Internet Explorer que permite "grabar macros" para despus lanzarlas. Permite probar Javascript, y su proxy funciona incluso usando https y certificados de cliente (ya que se ejecuta "por encima del navegador", en vez de "por debajo" como el JMeter). o Unitils: un recubrimiento de JUnit y otras cuantas que como mnimo te facilita la vida hasta que todos (JUnit, Spring...) se pongan de acuerdo para funcionar de verdad juntos.

Integracin Contnua: mantenme informado de cmo va el cdigo de nuestro proyecto (compila al menos? pasa las pruebas? cumple las mtricas? avsame al messenger si hay problemas!) o Continuum o CruiseControl son las dos herramientas OS ms comunes. Olvidarse de tantos diagramas UML, documentos de viabilidad, planificacin, requisitos, anlisis, diseo, presentaciones powepoint y dems basura que no sirve para casi nada, y "smplemente hacerlo (6:00)". PD: el artculo citado antes enlaza a su vez con otro sobre procesos de obligada lectura, y saca de l una cita que no puedo menos que plagiar tambin: Las pautas que en los entornos industriales logran eficiencia, en el software producen mediocridad. Gestionar empresas del conocimiento con teora de management industrial genera productos mediocres y tcnicos desmotivados.

BIBLIOGRAFIA http://iiso.blogspot.com/2007/05/tcnicas-giles.html http://issi.dsic.upv.es/tallerma http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational http://www.solotuweb.com/vc~t~Programacion-eXtrema,-software-libre--yaplicabilidad--en-Ingenieria-de-software~id~6745.html