Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones Trabajos Diciembre 2004

Transcripción

1 Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones Trabajos Diciembre 2004 Departamento de Computación Facultad de Ciencias Exactas Universidad de Buenos Aires Página 1 de 1

2 Indice Introducción...4 extreme Programming...5 Qué es XP?... 5 Porqué surge XP?... 5 Principios de XP... 5 Prácticas de XP... 7 Es XP económicamente viable?... 9 Cuándo usar XP?... 9 Cuándo NO usar XP? XP vs. metodologías tradicionales Conclusiones Bibliografía Extreme Programming vs. CMM...12 Qué es XP? Prácticas de XP XP vs. CMM Casos de estudio Bibliografía Buenas Practicas...16 Introducción Porque? Que Son? Sobre que? Desarrollo de Aplicaciones Conclusiones Referencias EAI: Un Vistazo General...25 Resumen Qué es EAI? Muchos nombres, la misma intención Actualidad Futuro Conclusión Referencias SOA Caso de Estudio...30 Introducción Requerimientos Niveles de Arquitectura Requisitos de Diseño y Construcción La Arquitectura Orientada a Servicios Despliegue de Componentes Referencias Model Driven Architecture...39 Introducción Construyendo una aplicación MDA Ingeniería de Reversa y Bridge Generation Detalle de Conceptos utilizados en MDA Productos Conclusiones Bibliografía Integración de Aplicaciones con Web Services...48 Acerca de este documento Introducción El Problema: La Integración Solución La Tecnología Integrando con SOAP Conclusión Página 2 de 2

3 Referencias Business Process Management (BPM)...58 Introducción Qué es Business Process Management (BPM)? BPM en la práctica La tecnología de BPM BPM hoy Conclusiones Bibliografía JAIN/SLEE...68 Introducción Motivación Objetivos JAIN Service Logic Excecution Enviroment (JSLEE) Jain Session Initiation Protocol (JSIP) JAIN y otras tecnologías de Java (Big Picture) Estado Conclusión Referencias Programación Orientada a Aspectos...74 Introducción El problema a resolver Algunas definiciones básicas Aprendiendo AOP con un ejemplo Herramientas disponibles para java y.net Visión de futuro Conclusiones Bibliografía Sistemas de Administración de Contenidos...79 Qué es un CMS? Algo de historia Conceptos importantes detrás de un CMS Cuándo conviene usar un CMS? [1] Beneficios Características de un CMS Problemas observados en los CMS Estado actual del mercado de los CMS Cómo encontrar el CMS adecuado? [3,6,7,8] El futuro de los CMS Referencias Self-Healing Systems...87 Introducción Qué son los Self-Healing Systems? Consecuencias para la ingeniería de software? Taxonomía de Temas Elementos del modelo del espacio de problemas La propuesta de IBM: Informática Autónoma Propuesta desde la Biología Otra propuesta: Homeostasis Propuestas Self-Healing basadas en Arquitecturas Casos prácticos de la industria IT Bibliografía Links de interés Página 3 de 3

4 Introducción En este documento se presentan los trabajos entregados por los alumnos, como trabajo final de la materia dictada entre octubre y diciembre de Los trabajos están agrupados por su temática, cubriendo los distintos contenidos ofrecidos en la materia, haciendo hincapié en las citas y referencias que permiten profundizar cada uno de los temas. Página 4 de 4

5 extreme Programming Adrián Pablo Eidelman Qué es XP? XP es una disciplina de desarrollo de software basada en ideas y prácticas simples y de sentido común que poseen varios años de utilización. El objetivo principal de XP es perderle el miedo al cambio y a través de esto permitir que el desarrollo se adapte constantemente a las necesidades de un negocio que cambia todo el tiempo. XP propone trabajar con una mentalidad del desahogo esto significa programar como si se tuviera todo el tiempo del mundo, tomándose el tiempo para escribir pruebas y cambiar el código en cuanto se sienta que se aprendió algo nuevo. Esto es un gran contraste respecto de la mentalidad del esfuerzo continuo en la que la mayoría de los desarrollos de software se encuentran hoy inmersos y que trae como resultado retrasos, malhumor, trabajo a desgano y rotación alta de personal. Porqué surge XP? XP surge como una solución a los problemas de las metodologías de desarrollo de software tradicionales. Estas fallan generalmente en brindar al cliente el máximo beneficio que pueda obtener de su inversión. También fallan en un sentido social al quitar importancia al factor humano en pos de los procesos asumiendo una visión de la producción de software comparable a una línea de ensamblaje en la que cada obrero puede ser fácilmente reemplazado sin que se modifique de manera apreciable el funcionamiento general. XP surge también como una forma de mitigar los riesgos inherentes a cualquier desarrollo de software y la mayoría de los cuales no son correctamente encarados por las metodologías tradicionales. Entre estos riesgos encontramos: Llegar a la fecha de finalización del proyecto y enterarnos que el proyecto se retrasará otros seis meses A medida que pasa el tiempo, el costo de agregar nuevas modificaciones al programa se vuelve cada vez más grande La calidad del desarrollo es mucho menor a la esperada Una vez que el programa está listo, al cliente no le sirve porque el negocio cambió mucho desde el inicio del proyecto El sistema tiene muchas funcionalidades que agregan poco valor al negocio del cliente Principios de XP Antes de poder definir un conjunto de prácticas específicas que permitan resolver o mitigar los riesgos, se debe definir un conjunto de principios que servirán de guía durante todo el desarrollo y permitirán juzgar y evaluar cada una de las prácticas que se quiera introducir. Estos principios también ayudarán a tomar decisiones de forma más rápida y precisa ya que sabiendo hacia donde se quiere ir es más fácil decidir qué camino se acerca o aleja del objetivo. Realimentación rápida Para contar con una disciplina que se adapte constantemente a los cambios del negocio, es indispensable contar con una realimentación rápida. De esta forma, los programadores podrán aprender constantemente qué necesitan los usuarios y estos podrán entender qué es lo que los primeros pueden hacer por ellos. Asumir la sencillez Rompiendo con la tradición impuesta por todas las metodologías que la preceden, XP propone resolver los problemas que se presentan de la manera más sencilla posible. En vez de planificar y diseñar para soportar los posibles cambios futuros, solo se debe resolver el problema puntual tal cual se presenta el momento. En el 95% de los casos esto será suficiente y los recursos que se ahorran son mucho más que los necesarios para resolver el 5% restante. Página 5 de 5

6 Cambio incremental Es muy raro que un cambio radical y profundo tenga los resultados esperados. Por eso XP propone subdividir un gran cambio en muchos cambios pequeños. De esta forma, es mucho más fácil controlar la aplicación de cada uno e incluso permite ir ajustando los cambios futuros de acuerdo a si los cambios ya implementados tuvieron o no los efectos deseados. Esta estrategia de cambio incremental no solo se aplica a la programación dentro de XP sino también al diseño y la planificación. Aceptar el cambio Si se desea utilizar XP se debe estar completamente dispuesto a aceptar el cambio constante. Más adelante se verá como XP soporta el cambio constante sin que se introduzcan riesgos para la calidad y funcionamiento del sistema. Trabajar con calidad La calidad no es una variable independiente que pueda ser ajustada a cualquier nivel. Esto es una verdad tanto para el negocio como para los programadores. El negocio no querrá un producto que no funcione correctamente y los programadores rápidamente se cansarán de trabajar en un proyecto de calidad dudosa. Enseñar a aprender Mejor que dar pescado es enseñar a pescar. En esto se basa la filosofía de XP. XP no dice cuales son todas las pruebas que se deben implementar para cada funcionalidad. XP propone ciertos lineamientos y está en cada uno de los que deciden adoptarlos explorar y decidir hasta donde deben ser llevados a cabo. Experimentos concretos Cada vez que se toma una decisión hay una posibilidad de que se este cometiendo un error. Por lo tanto es mejor realizar un pequeño experimento (prototipo, prueba de concepto, etc.) que permita reducir el riesgo y tener mayor confianza en que se va por el camino correcto. Comunicación abierta y honesta Muchos proyectos son cancelados, se retrasan o sufren seriamente debido a que no se cuenta con una comunicación abierta y honesta. Muchas veces se teme comunicar malas noticias para no parecer el responsable. XP propone todo lo contrario. La única forma de llevar a buen puerto un proyecto es comunicándose constantemente, tanto las buenas como las malas noticias. De esta forma, aquellos que tengan la autoridad o capacidad podrán tomar las decisiones adecuadas cuando todavía hay tiempo de revertir el proceso. Aceptar la responsabilidad Nada quita más la motivación a una persona o a un equipo que el hecho de que venga alguien a decirles qué es lo que tienen que hacer. En XP, se propone que cada uno tome la responsabilidad acerca de las tareas que va a realizar. Esto no quiere decir que siempre se haga lo que se desea. Si el equipo decide que hay tareas que se deben hacer, alguien tendrá que hacerlas. Ir ligero de equipaje No se puede esperar llevar mucho equipaje y moverse rápido al mismo tiempo. Los miembros de un equipo XP deben estar preparados para moverse rápidamente en cuanto surja una nueva necesidad de negocio o una mejor solución de diseño. Por lo tanto solo deben llevar consigo aquello que aporta valor al cliente: las pruebas y el código. Adaptación particular La disciplina propuesta por XP no se encuentra en ningún sentido cerrada. De hecho, es parte de la disciplina que cada uno la adapte a sus necesidades y posibilidades particulares. Es cierto que hay unas pocas prácticas que si o si deben ser aplicadas, pero incluso en estos casos se puede decidir cómo y cuándo aplicarlas. Medidas justas Para poder conocer el estado de un proyecto es inevitable tener que llevar algún tipo de medición. Sin embargo, es de extrema importancia que las medidas utilizadas sean justas ya que podrían llegar a influir la forma de trabajar de cada miembro del equipo. Página 6 de 6

7 Prácticas de XP Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones En base a los principios mencionados anteriormente, XP propone doce prácticas que deberían ser llevadas a cabo en todo desarrollo de software. Estas son: El juego de la planificación Versiones pequeñas Metáfora Diseño sencillo Hacer pruebas Recodificación (refactoring) Programación en parejas Propiedad colectiva del código Integración continua Semanas de 40 horas Cliente junto al equipo de desarrollo Estándares de codificación El juego de la planificación El objetivo del juego de la planificación es determinar de forma rápida y claramente detallada cuál es el alcance de la siguiente versión. Para esto es necesario combinar las prioridades del negocio con las posibilidades y estimaciones técnicas. Las personas del negocio necesitan decidir sobre: el alcance (qué es lo que se necesita hacer para que el sistema genere el mayor valor posible al negocio o sea qué es lo imprescindible y qué lo deseable), las prioridades (qué se hace primero y qué después) y las fechas (para cuando necesita el negocio contar con cada funcionalidad). Por su parte, el personal de desarrollo deberá proveer de un contexto dentro del cual la gente de negocio pueda tomar sus decisiones. Son decisiones de ellos: las estimaciones (cuánto tiempo se tardará en desarrollar cada una de las características requeridas), las consecuencias tecnológicas (hay ciertas decisiones de negocio que requieren un cuidado análisis del posible impacto tecnológico que podrían acarrear en caso de llevarse a cabo), el proceso (cómo se organizará el trabajo y el equipo) y el orden del desarrollo dentro de una versión (a veces es tecnológicamente conveniente desarrollar primero una característica menos prioritaria). Versiones pequeñas Cada versión debería ser tan pequeña como fuera posible conteniendo solo los requisitos de negocio más importantes. Sin embargo, no se puede perder de vista que cada versión tiene que tener un sentido por sí misma. No se puede implementar la mitad de una característica en una versión y la otra mitad en la siguiente. Cuanto más reducido sea el tiempo de cada versión, mayor será la retroalimentación obtenida y más posibilidades habrá de controlar el presupuesto, los tiempos y la aceptación por parte del cliente. Metáfora La metáfora sirve de guía para cada proyecto. De ella se toman las palabras a utilizar para describir cada uno de los componentes del proyecto y sirve como un faro que mantiene la cohesión dentro del sistema como un todo. Diseño sencillo Pon lo que necesites solo cuando lo necesites. Esta frase resume muy bien la idea del diseño sencillo en XP y se basa en dos creencias fundamentales: que el futuro es incierto y que será fácil cambiar las cosas en el futuro. XP provee una sencilla lista de pasos para evaluar si un diseño es realmente sencillo. Simplemente debe cumplir con estas cuatro reglas: Funciona con todas las pruebas No tiene lógica duplicada Manifiesta cada intención importante para los programadores Tiene el menor número posible de clases y métodos Un método sencillo para simplificar un diseño es simplemente eliminar cualquier elemento del mismo de forma tal que se sigan cumpliendo las tres primeras reglas. Hacer pruebas Todas las características del programa deben tener una o más pruebas asociadas. Esto es indispensable para cualquier proyecto XP ya que es lo que permite que con el correr del tiempo el programa sea más modificable (y no menos como sucede en las metodologías tradicionales). Hay dos tipos básicos de pruebas, las de unidad y las funcionales. Las primeras las escriben los programadores y les permite ir incrementando su confianza en el Página 7 de 7

8 programa a la vez que pasan a formar parte del mismo. Lo mismo sucede con las pruebas funcionales y los clientes. No se debe malinterpretar esta práctica. La idea no es hacer una prueba para cada método de cada clase sino solo para aquellas funcionalidades importantes que pueden llegar a fallar. Recodificación (Refactoring) La recodificación implica modificar código que está funcionando para mantener el diseño lo más sencillo posible. Cada vez que un programador debe añadir una nueva característica lo primero que hace es programarla de la manera más sencilla posible. Luego trata de ver la forma de hacer el diseño lo más simple posible y que sigan funcionando las pruebas. A veces, esto lleva más tiempo que el absolutamente necesario para hacer que algo funcione. Sin embargo, es esta pequeña inversión la que permite que sea sencillo de agregar el próximo cambio y el siguiente, etc. Son los pequeños cambios de la recodificación los que permiten hacer grandes cambios en el sistema con bajo riesgo. Programación en parejas Todo el código del programa debe ser escrito por dos personas sentadas frente a una sola computadora con un teclado y un mouse. Cada uno de los programadores tiene un rol distinto. El que tiene en su poder el teclado y el mouse está ocupado en encontrar la mejor forma de implementar el método. Su pareja, tiene una visión más estratégica y debería pensar en: nuevos casos de prueba que hagan fallar el método, si la aproximación utilizada es la mejor y si hay alguna forma de simplificar el sistema de forma tal que el problema actual desaparezca. La parejas no deben ser fijas y pueden variar hasta dos o tres veces en un mismo día dependiendo de la disponibilidad y de las habilidades requeridas para cada tarea. Esta práctica da como resultado un código fuente de mucha mayor calidad que el que podría producir un programador trabajando por separado. Y contrariamente a lo que podría esperarse, no solo no genera una reducción en la producción de los programadores sino que la mantiene constante (con mayor calidad) o incluso la aumenta. Propiedad colectiva del código Todos los miembros del equipo son propietarios y responsables de todo el código del sistema. Por lo tanto cualquiera puede hacer un cambio en cualquier lugar siempre y cuando las pruebas sigan andando. De esta forma, se evita el cuello de botella que genera el modelo más tradicional de propietario único del código en el cual se debe requerir al propietario que haga las modificaciones que uno necesita. Integración continua Todas las parejas deben integrar su código con la última versión estable por lo menos una vez al día. Cada vez que se realiza la integración, los que la hacen deben asegurarse que todas las pruebas se ejecutan correctamente. En caso de no ser así esa pareja deberá corregir el código hasta que pase las pruebas y en caso de no poder, deberá retirar sus actualizaciones y volver a la versión anterior a la integración. Esta práctica asegura que la última versión del código no divergirá demasiado de la versión que cada desarrollador tiene y de esta forma se evitará largas jornadas de integración y aún más largas jornadas de corrección de errores de integración. Semanas de 40 horas Nadie puede trabajar cómodo y a gusto si todas las semanas está 50 o 60 horas trabajando. Si se mantiene ese ritmo, al poco tiempo los desarrolladores se cansarán y empezarán a producir un código de muy mala calidad y al tiempo buscarán un nuevo lugar de trabajo. Es por esto que XP propone que las semanas no deben ser de más de 40 horas. Puede haber excepciones, pero si estas se prologan por más de una semana seguida entonces es un síntoma de que hay algo que no está andando bien y se deberá revisar lo que se está haciendo. Cliente junto al equipo de desarrollo Es muy importante para XP que los programadores puedan estar en contacto permanente con el cliente. De esta manera, ellos podrán ir aprendiendo acerca del negocio y consultar todas las dudas que tengan y no tener que esperar días o semanas a que se produzca una reunión y recién ahí saber qué es lo que el cliente quiere. El cliente también puede proporcionar un feedback inmediato acerca del funcionamiento de las nuevas características. Estándares de codificación Ya que los programadores estarán cambiando constantemente cualquier parte del código, es necesario tener ciertos estándares básicos que den una consistencia de estilo al código. El estándar debería exigir la menor cantidad de trabajo posible y ser consistente con la regla de no duplicar código. Es importante que todo el equipo acepte voluntariamente el estándar. Página 8 de 8

9 Es XP económicamente viable? Si nos basamos en la creencia tradicional que dice que el costo de hacer una modificación en un programa crece exponencialmente (Figura 1) a medida que se avanza en el desarrollo del mismo, claramente XP no es una disciplina de desarrollo de software viable. Figura 1 Sin embargo, XP presenta una visión completamente distinta respecto de este punto. XP sostiene que si se aplican las prácticas descritas anteriormente, el costo del cambio no solo no crece exponencialmente sino que tiende a ser como lo muestra la Figura 2. Figura 2 Por lo tanto, si el costo del cambio crece lentamente a medida que pasa el tiempo, se deberían aplazar las decisiones más importantes para mantener las opciones abiertas. Solo se debería implementar lo que se necesita hoy y no pensando en lo que se necesitará a futuro. Ya que seguramente el negocio cambiará, la inversión de hacer lo que creemos que será útil, seguramente no terminará siendo rentable. Para poder mantener la curva de costo según la Figura 2, XP se basa en dos herramientas claves. La primera es la programación orientada a objetos ya que esta al mantener unido el código con los datos sobre los que opera hace más fácil la introducción de nuevos cambios. La segunda es un subconjunto de las prácticas: el diseño simple y las pruebas automatizadas. El diseño simple mantiene el programa sencillo y solo con lo que se necesita en el momento, por lo tanto es más fácil de modificar y sin las pruebas automatizadas, realizar cualquier cambio sería introducir grandes riesgos sobre un código que ya funcionaba. Cuándo usar XP? XP puede ser usado para una infinidad de proyectos distintos tanto sean desarrollos nuevos como mantenimiento o modificación de programas existentes. Si el proyecto es nuevo, se pueden aplicar todas las prácticas desde el principio. Sin embargo, en los demás casos, cambiar completamente la forma de trabajo tal vez no sea lo más adecuado. En estos casos, es recomendable seguir este sencillo procedimiento : Identificar el peor problema que se tenga Resolverlo usando XP Cuando deje de ser el peor problema volver al paso 1 En general los problemas más acuciantes de casi cualquier proyecto son la baja calidad del código existente y el desequilibrio en la negociación entre los desarrolladores y el cliente. Por lo tanto en general se empieza aplicando las pruebas automatizadas y el juego de la planificación. Las pruebas se deberán ir generando solo para el código que es necesario modificar. De esta forma se mantiene el principio de hacer solo lo que se necesita hoy y dejar para mañana lo que se necesitará mañana. Página 9 de 9

10 Cuándo NO usar XP? Tendencias Tecnológicas en Arquitecturas y Desarrollo de Aplicaciones XP no es una disciplina que se adapte a todos los proyectos. Es importante antes de decidir aplicarla analizar si el tipo de proyecto que se va a encarar obtendrá beneficios de su uso. No existe una lista exhaustiva de proyectos o tipos de proyectos que no puedan o no deban ser llevados a cabo con XP, lo que si hay es algunos consejos obtenidos a partir de distintas experiencias acerca de qué funcionó y que no. La siguiente lista, muestra solo algunos rasgos que tenían algunos proyectos para los que XP no funcionó: Si la cultura de la empresa consiste en quedarse después de hora para demostrar el compromiso con el proyecto Si se va a necesitar más de una o dos docenas de programadores Si el tiempo en el que se obtiene un ejecutable para realizar las pruebas es de más de un día Si se necesita pasar por certificaciones de calidad que llevan varias semanas antes de poner el código en producción Si no se puede replicar (de manera satisfactoria) el entorno de producción de forma de realizar pruebas confiables Si se trata de hacer las cosas de una manera complicada para mantener la compatibilidad con aplicaciones legacy Si no se pueden reordenar los muebles de forma tal que dos programadores trabajen cómodos en una misma máquina De todas formas, todos los días hay nuevos proyectos que se encaran utilizando XP y que mueven la barrera entre lo que antes se consideraba posible y lo que no. XP vs. metodologías tradicionales A continuación se presenta una lista con algunos puntos en los que las metodologías tradicionales difieren completamente con XP. Documentación Las metodologías tradicionales ponen un gran énfasis en la documentación, tanto en la forma de manuales como en la de diagramas. A la larga, terminan pasando una de dos cosas, o la documentación empieza a desactualizarse hasta convertirse en inservible o el costo de estar constantemente actualizándola se vuelve un obstáculo en el avance del proyecto. XP ve a la documentación como una herramienta y no como un fin. Por lo tanto solo recomienda documentar cuando esta documentación provea un valor en sí mismo y descartarla en cuanto pase a ser un obstáculo. Orientación del proceso Las metodologías tradicionales son orientadas al proceso. Esto significa que su objetivo es desarrollar un proceso en donde las personas involucradas sean fácilmente reemplazables. Lo que importa en el proceso son los roles y no las personas que los cumplen. XP es una metodología orientada a las personas ya que reconoce que la única forma de llevar adelante un proyecto exitoso es contando con gente capaz, motivada y que trabaja bien dentro del equipo. No es posible conseguir este tipo de recursos humanos si no se les da la importancia que merecen. Por eso XP trata a los participantes del desarrollo como partes esenciales del proyecto y no accidentales como las metodologías tradicionales. Predicibilidad de los requerimientos Las metodologías tradicionales siguen un proceso predecible. Para que esto tenga sentido, asumen que se puede predecir en la etapa inicial del proyecto cuales van a ser todas las características esperadas del sistema. Una vez finalizada la etapa de relevamiento, estas metodologías tratan de poner la mayor cantidad de trabas posibles en los cambios de los requerimientos ya que estos implicarían grandes cambios en el plan. XP reconoce que en el mundo altamente competitivo de los negocios, es casi imposible predecir con un grado de acierto alto qué se va a necesitar del sistema dentro de dos o incluso un año. Por lo tanto propone un modelo de desarrollo iterativo en donde el cliente expresa sus necesidades más acuciantes y recibe periódicamente (cada una o tres semanas) versiones incrementales del sistema. De esta forma va teniendo contacto con el mismo y pudiéndolo utilizar mucho antes de que esté completamente finalizado. Así puede enterarse prematuramente si una característica fue interpretada correctamente y si en realidad era tan útil como lo imaginaba. Página 10 de 10

11 Qué significa un proyecto exitoso? Para las metodologías tradicionales, un proyecto exitoso es aquel que se está ejecutando según el plan en términos de tiempo y costos. Para XP un proyecto es exitoso si y solo si le brinda al cliente el mayor provecho posible. XP pone un gran énfasis en el valor que tiene para el cliente el sistema. Si el negocio cambia drásticamente una vez empezado el proyecto, el desarrollo debe ser capaz de ajustarse a ese cambio. No tiene ningún sentido continuar con un plan que llevará a un sistema inservible o que será poco usado. Visión del cambio Las metodologías tradicionales ven al cambio como un problema que debe ser evitado a toda costa. Tratan de obtener por escrito con el mayor detalle posible todo lo que hará y lo que no hará el sistema antes de empezar. También los criterios de aceptación de cambios son pactados de antemano y puestos en el contrato. XP ve al cambio como una posibilidad. Una posibilidad de darle al cliente un producto más valioso que el que originalmente se había previsto. La gran mayoría de las prácticas de XP están diseñadas para hacer los cambios posibles. Conclusiones Hoy en día, cada vez más proyectos deciden adoptar XP como guía del desarrollo. Esto se debe a que XP tiene como objetivo principal producir el mayor beneficio posible al cliente y al mismo tiempo tiene muy en cuenta las necesidades, fuerzas y debilidades de la gente de desarrollo. Además brinda al cliente una sensación de control e inmersión en el proyecto muy superior a la que hasta ahora habían experimentado con otros procesos. Hasta ahora pocas metodologías habían hecho tanto énfasis en la necesidad de comunicación, en las personas y en una relación tan fluida ente el cliente y los desarrolladores como propone XP. Es la visión del autor que cada vez más las pequeñas y medianas empresas que requieren y/o proveen desarrollo de software empezarán a adoptar XP y que no pasará mucho tiempo antes de que XP sea adaptado a otras ramas de la industria. El objetivo de este trabajo fue presentar XP describiendo los principios en los que se basa y las prácticas que de ellos se derivan. También se mostró cómo es que estas prácticas pueden ser económicamente sustentables a pesar de ir en contra de lo que tradicionalmente se creía correcto. Por último se brindó una breve reseña acerca de cuando si y cuando no usar XP junto con un resumen de las diferencias más significativas entre XP y sus antecesoras. Bibliografía Kent Beck, Extreme Programming Explained Jonas Martinsson, Evaluation of Extreme Programming Pilot Project at Labs2 Martin Fowler, The New Methodology Martin Fowler, Refactoring: Doing Design After the Program Runs Martin Fowler, Variations on a Theme of XP Martin Fowler y Cara Taber, Planning and Running an XP Iteration Daniel Karlström, Introducing Extreme Programming An Experience Report Página 11 de 11

12 Extreme Programming vs. CMM Esteban Franqueiro Qué es XP? Puede clasificarse como una de las metodologías ágiles, surgidas como reacción ante las metodologías ingenieriles y su burocracia. Atribuida a Kent Beck, Ron Jeffries y Ward Cunningham, XP está pensada para pequeños y medianos proyectos con requerimientos vagos y que cambian frecuentemente. Asumiendo que un alto costo del cambio de requerimientos es debido a las tecnologías en uso (patterns, information hiding, etc), XP trata que el proceso de desarrollo de software sea altamente dinámico. El equipo XP trata los cambios a través de un ciclo de vida iterativo de ciclos cortos. Las cuatros actividades básicas en el ciclo de vida de XP son coding, testing, listening y design. El dinamismo es demostrado por cuatro valores: comunicación continua con el cliente y dentro del equipo, simplicidad para enfocarse en la solución mínima, feedback rápido y constante a través del testing de unidad y funcional y el coraje para gestionar los problemas proactivamente. Prácticas de XP XP se basa en alguna prácticas (llamadas Core Practices 1 ). Las siguientes son algunas de ellas. Whole Team En cada proyecto XP existe un único equipo del que todos los participantes del proyecto son miembros. Este equipo incluye representantes del cliente, que proveen los requerimientos, fijan sus prioridades y le dan dirección al proyecto. Los programadores también son parte de este equipo, así como los testers, que ayudan al cliente a definir los tests de aceptación. También lo son los analistas que ayudan al cliente a definir requerimientos. Suele haber un coach que mantiene al equipo en camino y también puede haber un manager que se encarga de proveer los recursos, manejar la conversación con el exterior, coordinar actividades, etc. Ninguno de estos roles es propiedad de una única persona, cada miembro del equipo contribuye como puede. Los equipos no tienen especialistas, sino contribuyentes con habilidades especiales. Planning Game El planeamiento en XP se ocupa de dos temas centrales: predecir que objetivos serán alcanzados en la fecha de entrega, y decidir cuál será el siguiente paso. El énfasis está en darle dirección al proyecto, en vez de predecir exactamente qué se necesitará y cuánto llevará hacerlo. Hay dos pasos que se ocupan de estos temas: Release Planning Práctica en la que los clients presentan las características (features) deseadas y los programadores estiman su dificultad. Con esta estimación de costos y las prioridades de estas características, el cliente plantea un plan de trabajo. Los planes iniciales suelen no ser precisos (ni las prioridades ni las estimaciones son realmente sólidas) y hasta que el equipo no comience a trabajar no puede saberse qué tan rápido irán. Estos planes son revisados regularmente. Iteration Planning Es la práctica en la cual al equipo se le da dirección cada un par de semanas. Las iteración son cada dos semanas, y al final de cada iteración el equipo produce software útil. Durante este planeamiento, el cliente presenta las características requeridas en las próximas dos semanas. Los programadores las dividen en tareas y estiman su costo (a un nivel más fino que el obtenido en release planning). Página 12 de 12

13 Customer Tests Como parte del pedido de cada característica, los clientes deben definir tests automatizados de aceptación que muestren que la característica está funcionando. El equipo debería tratar los tests de los cliente como cualquier otro test hecho por programadores: una vez que el sistema los pasa, los deberá pasar siempre. De esta forma el sistema siempre avanza. Small Releases El equipo genera pequeños releases, produciendo en cada iteración software que corre, que fue testeado y que tiene valor para el cliente. El cliente puede usar este software como quiera, ya sea para evaluarlo o incluso para ser usado en producción (esto último es altamente recomendado). Simple Design El equipo utiliza diseños simples para construir el software. Comienza simple, y mediante otras prácticas (programmer testing y design improvement) mantienen esta simplicidad. Se mantiene el diseño justo para la funcionalidad actual del sistema. En XP, el diseño no es algo que se haga una sola vez al principio, sino que es algo que se hace constantemente. A lo largo de todo el proyecto hay etapas de diseño (en el planeamiento de releases, de iteraciones, en sesiones de diseño y en revisiones de diseño mediante refactoring). Pair Programming Todo el software es producido por grupos de dos programadores, sentados uno al lado del otro, en la misma computadora. Esta práctica garantiza que todo el código sea revisado por al menos otro programador, y resulta en un mejor diseño, testing y código. Además, esta práctica sirve para comunicar mejor el conocimiento en el equipo a medida que las parejas van cambiando. Test-Driven Development El equipo primero crea los tests y luego el código que deberá pasar exitosamente dichos tests. Estos tests se mantienen todos juntos, con el código base, y cada vez que un par de programadores agrega código al repositorio, cada uno de los tests existentes debe correr sin errores. Design Improvement XP se enfoca en producir, en cada iteración, algo que tenga valor comercial para el cliente. Para esto, el software debe estar bien diseñado. Para mejorar continuamente el diseño, XP usa el proceso de refactoring. Este proceso se basa en eliminar código duplicado, aumentar la cohesión y disminuir el acoplamiento. De esta forma, se comienza con un diseño simple y se lo mantiene. El uso de refactoring va acompañado de testing, de forma que lo que se modificó no rompa cosas que ya funcionaban bien. Continuous Integration Siempre se debe mantener el sistema completamente integrado, lo que implica múltiples builds por día. La falta de integración constante genera, al momento de hacer un build o release, que se encuentren todos los problemas de integración clásicos. Collective Code Ownership El código le pretence al equipo, no a un programados o par de programadores en particular. Cualquier par puede mejorar cualquier código en cualquier momento. Esto significa que todo el código tiene la atención de todos, lo que aumenta su calidad y reduce defectos. Esto tiene otras ventajas. Cuando el código tiene un dueño, ciertas características pueden ser implementadas en el lugar equivocado para no tener que esperar a que el dueño del código correcto la implemente. Coding Standards Todo el equipo sigue las mismas reglas al escribir código. Esto ayuda a cumplir la práctica anterior. Metaphor El equipo consigue una visión común de cómo funciona el sistema (llamada metáfora). Esta puede ser una metáfora de verdad, o simplemente un sistema común de nombres para las cosas, de forma que todos entiendan como funciona el sistema, y dónde buscar la funcionalidad que requieren o agregar nuevas funcionalidades. Sustainable Pace El equipo trabaja a un ritmo que pueda ser sostenido indefinidamente. Esto significa que trabajan sobretiempo cuando es efectivo, y que cuando los programadores están cansados, descansan. XP vs. CMM Para analizar la compatibilidad de XP con CMM, debemos revisar si puede o no cumplir los KPA s de CMM. En [4] podemos encontrar un análisis detallado sobre el tema. La siguiente tabla resume dicho informe: Nivel de CMM KPA Satisfacción en XP 2!"!" Página 13 de 13

14 Requirements Management ++ Software Project Planning ++ 2 Software Project Tracking and Oversight ++ Software Subcontract Management -- Software Quality Assurance + Software Configuration Management + Organization Process Focus + Organization Process Definition + Training Program -- 3 Integrated Software Management -- Software Product Engineering ++ Inter-group Coordination ++ Peer Reviews ++ 4 Quantitative Process Management -- Software Quality Management -- Defect Prevention + 5 Technology Change Management -- Process Change Management -- Qué tienen en común los KPA s en los que XP falla? Los KPA s en los que XP falla pueden dividirse principalmente en dos grupos. Los que involucran (sub-) contrataciones de terceros. Aquellos que tienen que ver con procesos a nivel organizacional más que grupal. En el primer grupo entra Software Subcontract Management. Esto se debe a que XP está pensado para grupos y proyectos pequeños o medianos, en los que no tiene sentido la contratación de terceros. Por este motivo, la pérdida de este KPA no es realmente importante para decidir si XP es o no compatible con CMM (en los casos en los que XP se aplica, claro). Los restantes KPA s que XP no satisface caen en el segundo grupo, el de los que se refieren al concepto de institucionalización, o sea, a establecer la idea de así es como hacemos las cosas acá. Si bien está implícita en algunas prácticas, XP mayormente ignora la infraestructura que CMM identifica como clave para la institucionalización de buenas prácticas de ingeniería y management. Los KPA s de CMM, en cambio, comparten características comunes que implementan e institucionalizan procesos. XP ignora algunas de estar prácticas, como las políticas organizacionales, mientras que otras (como entrenamiento y QA) las satisface indirectamente como consecuencia de sus propias prácticas. Finalmente existe otro grupo de prácticas de CMM que XP satisface parcialmente (por ejemplo las relacionadas con temas específicos de proyectos). En general XP se enfoca en el lado técnico del proceso de desarrollo, mientras que CMM se enfoca en temas administrativos. Es por esta razón que XP generalmente ignora los KPA s relacionados con procesos. Por otro lado, el formalismo de CMM viene dado por las necesidades de proyectos grandes. A medida que los sistemas crecen, se vuelve cada vez más importante el concepto de arquitectura del sistema, y entonces algunas de las prácticas de XP se vuelven difíciles de mantener o implementar. En estos sistemas grandes, variantes del modelo bottom-up de XP (como por ejemplo el diseño basado en arquitectura) pueden ser más apropiados. Un último problema de XP es que los proyectos grandes tienden a ser multidisciplinarios, mientras que XP está dirigida específicamente al software. Casos de estudio XP en una empresa CMM Nivel 3 En cierta empresa, la administración decidió que todos los sistemas de la misma debían migrarse a aplicaciones web en 18 meses. El objetivo era reducir costos. Este requerimiento de 18 meses, chocaba contra los 5 años estimados basándose en experiencias y procesos anteriores. Los desarrolladores eligieron trabajar con XP con la esperanza de que esta metodología les permitiera cumplir la fecha impuesta. El equipo modificó algunas de las prácticas de XP para que tuvieran en cuenta el tamaño del proyecto. Esto afectó principalmente las prácticas Página 14 de 14 ##"$

15 relacionadas con el testing, ya que en lugar de primero crear los tests y luego escribir el código que los pase, se formaron equipos de testing independientes de los de desarrollo. Por otro lado, el equipo de QA se quejó ante la administración por la falta de documentación generada. El problema aquí fue que, en lugar de aplicar XP de forma racional dentro de los procesos de la empresa, se formaron bandos que comenzaron a culparse mutuamente. Al momento de escribirse el artículo original, el proyecto es encontraba detenido. XP en un proyecto de investigación científica Este proyecto se llevó a cabo en el Langley Creativity & Innovations Office del Langley Research Center de la NASA. De los 9 entornos que Beck dice que no son apropiados para XP, 6 van en contra de la cultura existente en el laboratorio 3. Según Beck, el principal obstáculo para el éxito de un proyecto XP es la insistencia de tener un diseño a priori, en lugar de ir diseñando el software mientras se lo desarrolla. Esto claramente contrasta con un ambiente como el de la NASA en donde los errores de software pueden ser trágicos. Al contrario que en el caso anterior, este proyecto concluyó de forma más que satisfactoria. Los autores del artículo cuentan que la nueva metodología de desarrollo casi duplicó su productividad comparada con proyectos previos. Este se debió a que si bien produjeron la misma cantidad de código de producción, además produjeron una cantidad similar de código de soporte (en forma de tests, tanto de unidad como de aceptación). También encontraron que el código resultó más conciso y claro (todo esto lo atribuyen a la aplicación sin misericordia del refactoring). Como consecuencia de esta prueba piloto, otros proyectos grandes de la NASA están adoptando XP. XP en una empresa RUP La empresa se dedica al diseño y construcción de servicios de Internet basados en Java, y utilizando las herramientas de Rational. Todo esto bajo el control de RUP. El experimento duró dos años en el contexto de dos laboratorios. El primero completó dos proyectos. Para el primer proyecto aplicaron una versión simplificada de XP. El resultado no fue bueno, cumpliendo la regla 20/80 propuesta por Beck: si se sigue el 80% del proceso, se obtiene el 20% de los beneficios. El problema fue que el proyecto no tuvo control y coordinación. Para el siguiente proyecto siguieron las reglas al pie de la letra y consiguieron alcanzar los objetivos propuestos y algunos más. Actualmente la empresa no utiliza XP, pero aplica sus principios. La empresa ahora mezcla programadores con y sin experiencia XP. El artículo además cuenta las perspectivas de cada uno de ellos frente a la metodología. Este caso muestra la necesidad de no quedarse a mitad de camino en la aplicación del método, y confirma que quienes aplicaron XP en proyectos de escala acotada obtuvieron resultados satisfactorios. Bibliografía IEEE Software, May/June Extreme Programming from a CMM Perspective. Paulk, M.; IEEE Software, November/December % &'() "* "* ( "* Página 15 de 15

16 Buenas Practicas Pablo Demidoff Introducción El objetivo de este trabajo es dar una introducción al tema de Buenas Practicas (Best Practices) y servir como guía para la búsqueda de información en la Web sobre las buenas practicas aplicadas a los temas vistos durante el seminario. Motivación Buscando en la Web sobre como resolver el problema del doble clic en el desarrollo de aplicaciones Web (porque surgió el problema en el trabajo), me encontré con un montón de información sobre el tema de Buenas Practicas, y me di cuenta que hay sobre todos los temas que a uno se le puedan ocurrir y que sobre la mayoría yo no tenia ni idea. Así que me pareció bien escribir una especie de guía que explicara que son y dar puntos de referencia para buscar información sobre las buenas practicas de algunos temas vistos en clase. Porque? El desarrollo de software tiene una rica historia que proviene de mas de 40 años de practicas probadas y reales. Desde modelos de programación estructurada a métodos orientados a objetos, el desarrollador es generalmente librado a sus propios recursos para implementar código basado en un proceso de diseño altamente creativo y subjetivo. El acceso a la información sobre el desarrollo de software ya no es un reto. Puede ser, por otro lado, dificultoso asimilar todas las nuevas características, los numerosos recursos, las opciones de herramientas, etc. Cuando hay que escribir un programa o toda una aplicación, los desarrolladores tienen, una y otra vez, el deseo de obtener consejos. Que Son? El objetivo de las Buenas Practicas es proveer consejos rápidos, concretos y aplicables que nos asistan en la escritura de código legible, mantenible y eficiente. Las Buenas Practicas están diseñadas para rápidamente ponernos al tanto de aspectos útiles sobre el aspecto tecnológico que estamos analizando. Se puede decir que las Buenas Practicas son algo mas generales que los Patrones (Patterns) dado que estos últimos sirven para dar soluciones a problemas particulares, bien documentados. Las Buenas Practicas por otro lado, se pueden aplicar a cualquier faceta del desarrollo de aplicaciones, desde la escritura de código (formato, nombre variables) hasta que soluciones o técnicas utilizar en determinadas soluciones. Es mas, una Buena Practica, podría llegar a decir, es bueno usar el Patrón XXX para solucionar tal problema. También son conocidas como consejos (tips), técnicas probadas, guías, etc, etc. En el libro Oracle PL/SQL Best Practices (1), el autor intento clasificar los Best Practices por temas, y clasificarlo como si fueran patrones, utilizando los siguientes datos: Título Una sentencia que describa la buena practica y provea un identificador para la misma de la forma XXX-nn, donde XXX es el tipo de buena practica, ejemplo, EXC para Excepciones, y nn es el número secuencial dentro de este conjunto de buenas practicas. Página 16 de 16

17 Descripción Una explicación mas larga para la buena practica. Es simplemente no posible cubrir todos los matices en una sola sentencia. Ejemplo Nosotros aprendemos mejor con ejemplos, con lo cual, se ilustran a través de código o anécdotas el valor de estas buenas practicas. Beneficios Porque deberíamos molestarnos con esta buena práctica?. Cuan crucial es para uno seguir esta recomendación en particular?. Esta sección ofrece una rápida reseña de los principales beneficios que obtendremos siguiendo esta buena practica. Desafíos Esta sección nos previene sobre los desafíos o inconvenientes que podemos enfrentar al implementar esta buena practica. Recursos En el mundo de la Internet, todo esta conectado, ningún programador esta solo!. Esta sección recomienda recursos, libros, páginas Web, etc. Sobre que? Dado que las Buenas Practicas son consejos, guias, y comentarios, se pueden aplicar a cualquier aspecto de la vida en general. Solo se necesita tener experiencia en algun rubro en particular y dictar los consejos que se crea necesarios. En el ambito del desarrollo de Software, se encuentra buenas practicas de Administración de Proyectos, Diseño de Sites, JSP, Servlets, Struts, EJB, J2EE, Oracle, Seguridad, Administracion de Application Servers (ej. Websphere), etc, et.. Desarrollo de Aplicaciones A continuacion, intentaremos agruparlos según la arquitectura de N-Capas vista en clase, y algunos otrs conceptos como seguridad, administración y metodologia. Diseño de Sitios Estas guías sirven para definir como tiene que ser un sitio, desde su aspecto hasta como esta distribuida la información, que tipo de información se muestra, y las opciones de accesibilidad que se le brindan a los usuarios. Se utilizan para mantener un aspecto uniforme dentro de una organización u empresa muy grande, en la cual, hay mas de un grupo de desarrollo trabajando sobre el sitio corporativo o institucional. Por ejemplo, el artículo NASA WWW Best Practices (2) dice: Las Buenas Practicas bosquejadas en este documento sirven como pauta para todas las entidades de la NASA dedicadas al desarrollo y mantenimiento de recursos WWW. Estas pautas facilitan un despliegue consistente, fiable y eficiente de los servicios WWW a través de la agencia. Estos criterios deben ser vistos como recomendaciones base. Estas buenas prácticas continuarán siendo revisadas por la comunidad NASA WWW. Desarrollo de Sistemas Estas guías sirven para el desarrollo de software. Son tanto lineamientos sobre como elegir el proceso de desarrollo a utilizar, como obtener los requerimientos, como armar la arquitectura, como elegir el modelo de testeo, etc. Son pautas para cada una de las etapas en el desarrollo de aplicaciones. Por ejemplo, el artículo Best Practices for Software Development Projects (3) dice: La mayoría de los proyectos de software fracasan. De hecho, el grupo Standish reporta que más del 80% de los proyectos son fallidos porque son sobre presupuestados, tardíos, falta funcionalidad o una combinación de los mismos. Además, 30% de los proyectos de software son tan pobremente ejecutados que hacen que sean Página 17 de 17

18 cancelados antes de finalizar. En nuestra experiencia, los proyectos de software usando tecnologías modernas como Java, J2EE, XML y Web Services no son excepciones a esta regla. Por otro lado, en el libro Designing Enterprise Applications with the J2EE Platform, Second Edition (4) (5), se explican reglas de arquitecturas para aplicar con la tecnología J2EE. En el articulo, Software Development: Best Practices for Developing Enterprise Applications (6), habla sobre 7 practicas que van mas allá de la fase, arquitectura o tipo de proyecto. Estas son (en ingles) Orthogonal, DRY, Model-View, Meta-programming, Automatic, Test First y Refactoring. En el artículo, Capturing and Formalizing Best Practices in a Software Development Organization (7), el autor dice: El número de recursos que los desarrolladores de software moderno deben utilizar para crear aplicaciones es simplemente increíble. Modelos de procesos, métodos de desarrollo, tecnologías, y herramientas de desarrollo apenas arañan la superficie del arsenal contenido en el kit de herramientas del diseñador de software. Pero la comunidad de ingeniería de software ha por la mayor parte ignorado el conocimiento adquirido y la esencia de la maestría en herramientas, optando en cambio por amontonar nuevos métodos, lenguajes, herramientas y métodos formales sobre la pila de conocimientos. Poco soporte es dado para el entendimiento de cuando las diferentes metodologías deben ser usadas y como ellas deben ser aplicadas al esfuerzo de desarrollo con conjuntos específicos de requerimientos. Este paper presenta una infraestructura que soporta conocimiento evolutivo por técnicas basadas en casos que ayudan a las organizaciones de desarrollo de software a pasar de la metodología tradicional de desarrollo (Standard Development Methodology) a un medio dinámico que capture buenas practicas y las convierta en organizaciones basadas en la información. En el artículo Reference Architecture: The Best of Best Practices (8), el autor dice: Porque un proyecto dentro de una organización florece mientras un proyecto dentro con las mismas necesidades fundamentales arquitectónicas, dentro de la misma organización, lucha por mantenerse a flote?. A menudo, la raíz del problema es la falta de comunicación horizontal a través de todos los proyectos en lo concerniente a elecciones arquitectónicas, tanto para buenas como malas, que fueron realizadas en proyectos pasados. RUP dice que tal recolección de buenas practicas dentro de la organización es el primer paso hacia la construcción de una arquitectura de referencia versátil y fuerte. Brevemente, una arquitectura de referencia consiste en información accesible para todos los miembros del equipo del proyecto que provee un conjunto consistente de buenas practicas arquitectónicas. Estas pueden ser plasmadas en muchas formas: artefactos arquitectónicos previos, estándares de la compania, patrones de diseño, frameworks comerciales, etc. Capa Presentación Estas Buenas Practicas sirven para como mejorar el desarrollo de la capa de presentación, o sea, como se muestran los datos al usuario. Incluyen a todas las tecnologías que se ocupan de este rubro, como ser HTML, JSP, Servlets, Struts, etc. El sitio de IBM developerworks contiene toda una sección de JSP Best Practices (9), donde se van publicando artículos periódicamente sobre este tema. En el artículo, Solving the logout problem properly and elegantly (10), el autor dice: El manejo correcto del proceso de logout en una aplicación Web protegida por password requiere mas que una llamada al método invalidate() del objeto HttpSession porque la mayoría de los navegadores modernos, con los botones de Adelante y Atrás, permiten a los usuarios avanzar y retroceder en una pagina. Si el botón Atrás causa que el navegador muestre paginas viejas desde sus caches después del proceso de logout, los usuarios de estas aplicaciones inadecuadamente desarrolladas pueden volverse confundidos, perdidos, y preguntarse que ha o pudo haber pasado con sus datos personales. Muchas aplicaciones Web agregan una pagina intimidando a los usuarios a cerrar sus navegadores completamente, esto, de hecho, previniéndolos de hace click en el botón atrás. Otros, usan JavaScript el cual no siempre esta activo en el navegador del cliente. La mayoría de estas soluciones son torpemente implementadas, fallan en funcionar el 100 % de las veces bajo todas las circunstancias, o requieren mucho entrenamiento de los usuarios. Este articulo presenta soluciones para manejar apropiadamente el problema del logout con programas de ejemplo. El autor Kevin Le empieza describiendo una aplicación Web protegida por password ideal. El luego usa programas ejemplo para ilustrar como los problemas se manifiestan y discute soluciones requeridas para solucionar dichos problemas. Centrando la discusión en JSP, el articulo presenta los conceptos que pueden ser Página 18 de 18

19 fácilmente entendidos y adoptados para otras tecnologías Web. Le concluye esta discusión mostrando como construir aplicaciones Web con Jakarta Struts puede resolver el problemas mas elegantemente. Programas ejemplo para JSP y Struts están incluidas. En el sitio developers.sun.com hay un articulo, Servlets and JSP Pages Best Practices (11), que presenta varias Buenas Practicas sobre Servlets y JSP. Al principio, el autor comenta: Las buenas practicas son enfoques probados para desarrollar aplicaciones Web basadas en servlet y JSP que son de calidad, re-usables y fácilmente mantenibles. Por ejemplo, código embebido Java (scriptlets) en secciones de documentos HTML pueden resultar en aplicaciones complejas que no son eficientes, dificultosas de re-usar, extender y mantener. Las buenas practicas pueden cambiar todo esto. En el artículo, Struts best practices. Build the best performing large applications (12), el autor dice: Muchas opciones están disponibles para resolver problemas con Struts. Cuando decidimos entre estas alternativas, la elección debe estar basada en parámetros como la escala del trabajo y la disponibilidad de tiempo. Sin embargo para aplicaciones grandes y con necesidad de buena calidad de servicio, cada decisión se transforma en crucial y esfuerzos extras son requeridos para elegir la solución apropiada. Para ayudarlo con estas decisiones, Puneet Agarwal discute algunas de las buenas practicas para desarrollar aplicaciones basadas en Struts. En el artículo Best practices for Struts development. Optimize the Struts framework in your Web application development (13), dice: Mejore el desarrollo de aplicaciones Web usando el flexible framework Struts. Aca, los autores exploran buenas practicas que vos podes seguir para optimizar este framework open source y maduro. Aprenda a usar componentes Struts valiosos y estándares, incluyendo ActionForm, la clase Action y ActionErrors. Capa Lógica Aplicación Estas Buenas Practicas están pensadas para lo que se refiere a modelar la capa de negocios o la lógica de la aplicación. En este trabajo nos concentraremos en los EJB. En el articulo Ease of Development in Enterprise JavaBeans Technology (14), se explica un poco cuales son los nuevos features de la versión 3.0 de EJB y porque simplifica su uso, dado que la gente es reticente a utilizar dicha tecnología por se un tanto complicada. El sitio de IBM developerworks contiene toda una sección de EJB Best Practices (15), donde se van publicando artículos periódicamente sobre este tema (casualmente es el mismo autor de los JSP Best Practices). En el artículo, Best practices in EJB exception handling (16), se habla sobre como manejar correctamente el tema de excepciones en EJB. Capa Administración de Datos Estas Buenas Practicas están pensadas a la programación del código en la base de datos, y a como optimizar el acceso a los datos, por ejemplo, con el uso de JDBC. En el artículo Scalability and Performance: JDBC Best Practices and Pitfalls (17), se mencionan varias pautas, en varias capas de la arquitectura, siendo: DBMS configuration parameters Physical database design SQL statements and query execution plans JDBC driver setup/configuration JDBC usage from within Java application code JDBC driver selection Application architecture general design issues Esta es una breve descripción de los capitulos del libro Oracle PL/SQL Best Practices (1): Capitulo 1: Comienza con recomendaciones especificas de programación. Ofrece consejos sobre como mejorar todo el proceso por el cual usted escribe código Página 19 de 19

20 Capitulo 2: Ofrece una serie de sugerencias sobre como formatear y organizar su código, para que este sea mas legible y, por consiguiente, mas mantenible. Capitulo 3: Toma una vista cercana a como usted debería declarar y manejar datos dentro de programas PL/SQL. Capitulo 4: Es un capitulo Regreso a los básico que habla sobre la mejor manera de escribir sentencias IF, ciclos, y hasta la sentencia GOTO. Seguro, estas no son construcciones terriblemente complicadas, pero hay aun correctas e incorrectas formas de trabajar con ellas. Capitulo 5: Cubre otro aspecto critico del desarrollo robusto de aplicaciones: el manejo de excepciones, o que hacer cuando las cosas salen mal. Capitulo 6: Se enfoca en el aspecto más crucial del desarrollo en PL/SQL: como debería escribir las sentencias SQL en sus programas. Capitulo 7: Ofrece consejo sobre la mejor forma de construir procedimientos, funciones y otras unidades de programa que contienen la lógica del negocio. Además incluye buenas practicas para la construcción de parámetros. Capitulo 8: Presenta recomendaciones sobre paquetes, los bloques de construcción de cualquier aplicación basada en PL/SQL bien diseñada. Capitulo 9: Hace foco en como tomar la mejor ventaja de unos pocos de los mas usados paquetes provistos por Oracle Corporation. Seguridad Estas Buenas Practicas están relacionadas con el tema de la seguridad en las aplicaciones. Tanto sobre como se piensa (o no) en las mismas, como sobre las tecnologías que existen para evitar las fallas de seguridad en nuestros sistemas. En el artículo Abstracting Application-Level Web Security (18), los autores dicen: Seguridad Web a nivel aplicación se refiere a vulnerabilidades inherentes en el código de la aplicación en si misma (independientemente de la tecnología en la cual esta implementada o la seguridad del servidor Web y de base de datos sobre la cual esta construido). En los últimos meses vulnerabilidades a nivel aplicación han sido explotadas con serias consecuencias: hackers han trampeado sitios de e-commerce, usuarios y claves han sido cosechados e información confidencial (como direcciones y números de tarjetas de crédito) ha sido violada. En este paper investigamos nuevas herramientas y técnicas que tratan el problema de seguridad a nivel aplicación Web. (i) Describimos un mecanismo de construcción escalable que facilita la abstracción de políticas de seguridad para grandes aplicaciones Web desarrolladas en entornos multiplataforma heterogéneos; (ii) presentamos una herramienta que asiste a los programadores a desarrollar aplicaciones seguras las cuales son fuertes contra una amplia gama de ataques comunes; y (iii) reportamos resultados y experiencias surgidos por nuestra implementación de estas técnicas. En el artículo Best Practices for Secure Web Development (19), el autor explica algunos términos básicos del tema y presenta 18 Best Practices, en el siguiente orden: Seguridad como parte de la idea del negocio. Seguridad como parte de la recolección de requerimientos. Seguridad como parte de la arquitectura. No ser anónimo cuando no queres terminar siéndolo. No usar cuentas administrativas a menos que sea necesario. No usar GET para enviar datos delicados. No confiar en que los clientes (navegadores) mantienen datos importantes entre requerimientos. No almacenar datos delicados en las mismas paginas ASP o JSP. Tener cuidado con los comentarios HTML dejados en códigos de produccion. Cross-site scripting Chequear el código de ejemplo o generado por wizards. Middleware security Declarative vs programmatic PKI no es una bala de plata. Página 20 de 20