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

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

XP- EXTREME PROGRAMMING

XP- EXTREME PROGRAMMING XP- EXTREME PROGRAMMING RUBBY CASALLAS DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN FACULTAD DE INGENIERÍA UNIVERSIDAD DE LOS ANDES Agenda Qué es XP? 12 Prácticas Actividades Principales: Planeación Diseño Codificación

Más detalles

Desarrollo Ágil. Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I

Desarrollo Ágil. Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I Desarrollo Ágil Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I Coordinación de Ciencias Computacionales INAOE 2011 Preguntas

Más detalles

Metodologías Iterativas de Desarrollo

Metodologías Iterativas de Desarrollo Metodologías Iterativas de Desarrollo Lic. Carlos Leone (MBA) Ing. Nicolás Passerini Ing. Gustavo A. Brey 2005 Agenda # Tema 1 Introducción a Metodologías de Desarrollo 2 Tipos de Metodología 3 Metodologías

Más detalles

Bachilleres: Bustamante Dayana C.I: 22.983.709 Rodríguez Jean C. C.I: 21.169.047

Bachilleres: Bustamante Dayana C.I: 22.983.709 Rodríguez Jean C. C.I: 21.169.047 UNIVERSIDAD NACIONAL EXPERIMENTAL DE LOS LLANOS OCCIDENTALES EZEQUIEL ZAMORA Ingeniería en Informática Subproyecto: Metodología de Desarrollo del Software Semestre VII Bachilleres: Bustamante Dayana C.I:

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI MODELO Y HERRAMIENTA DE AUTOMATIZACIÓN PARA AGREGAR VALOR A LOS PRINCIPIOS ÁGILES DE DESARROLLO

Más detalles

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM Metodología BPM:RAD - Rapid Analysis & Design Capítulo extraído de El Libro del BPM 2011 Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Más detalles

Agile, Scrum & extreme Progammig

Agile, Scrum & extreme Progammig Agile,, Introduction Departamento de Computación Facultad de Cs. Exactas Fco-Qcas y Naturales Universidad Nacional de Río Cuarto {fbrusatti}(at)dc.exa.unrc.edu.ar Agile,, Metodologías Agiles Son metodologías

Más detalles

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG)

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Grupo de Ingeniería del Software Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 3.0 - España 1 Objetivos del Tema Qué

Más detalles

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar

Más detalles

Programación Extrema. Ing. Sebastian Priolo

Programación Extrema. Ing. Sebastian Priolo Programación Extrema Ing. Sebastian Priolo Metodologías Ágiles Menos orientadas a los documentos. Orientadas al código. El cambio es bienvenido. Procesos que cambian NO son predictivos Son adaptables Ejemplos

Más detalles

Laboratorio de Software de Comunicaciones

Laboratorio de Software de Comunicaciones Universidad Carlos III de Madrid Laboratorio de Software de Comunicaciones Trabajo de Tecnología Educativa: Diseño de un curso Web de programación en Java Titulación: Ingeniería de Telecomunicación, Curso

Más detalles

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM Por Jesus Demetrio Velázquez Camacho Dentro de las organizaciones de desarrollo de aplicaciones existen dos grandes corrientes para la metodología

Más detalles

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina

Más detalles

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Mario R. MORENO SABIDO Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México y Jorge

Más detalles

Balanceo de metodologías Ágiles y Orientadas al Plan

Balanceo de metodologías Ágiles y Orientadas al Plan Balanceo de metodologías Ágiles y Orientadas al Plan Facultad de Ingeniería Universidad de Buenos Aires Ing. Juan Gabardini Ing. Lucas Campos (lcampos@rmya.com.ar) diciembre de 2005 75.46 Administración

Más detalles

METODOLOGÍA TRADICIONAL.

METODOLOGÍA TRADICIONAL. COMPARACIÓN DE METODOLOGÍAS METODOLOGÍA TRADICIONAL. Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación

Más detalles

Ciclo de Ingeniería de Software

Ciclo de Ingeniería de Software Ciclo de Ingeniería de Software Desarrollo Iterativo de Software Aplicaciones Cliente Servidor Aplicaciones OO Universidad FASTA 2008 Licencia Contenido Introducción Conceptos Planificación Calidad del

Más detalles

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES TEMA: La Programación Extrema aplicada al desarrollo del Sistema Informático

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

Proceso Unificado de Rational

Proceso Unificado de Rational RUP: El Proceso Unificado de Rational XP: Programacion Extrema EAP: Computación Científica Ciencia de la Computación V Prof. Oscar Brnito Pacheco Proceso Unificado de Rational Orígenes Modelo original

Más detalles

METODOLOGÍA TRADICIONAL.

METODOLOGÍA TRADICIONAL. METODOLOGÍA TRADICIONAL. Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos

Más detalles

270081 - ASW - Aplicaciones y Servicios Web

270081 - ASW - Aplicaciones y Servicios Web Unidad responsable: 270 - FIB - Facultad de Informática de Barcelona Unidad que imparte: 747 - ESSI - Departamento de Ingenieria de Servicios y Sistemas de Información Curso: Titulación: 2015 GRADO EN

Más detalles

Introducción 90% Figura 1 Síndrome del 90%

Introducción 90% Figura 1 Síndrome del 90% El Problema Quality Control = Project Control? Indicadores Objetivos para Control de Proyectos de Desarrollo de Software Lic. Juan Pablo Pussacq Laborde Jefe de la Oficina de Proyectos, RMyA Introducción

Más detalles

Ingeniería de Sistemas I

Ingeniería de Sistemas I Ingeniería de Sistemas I Metodologías Ágiles 1 Agenda Metodologías Ágiles, Origen Valores y Principios de las Metodologías Ágiles Ejemplos de Metodologías Ágiles SCRUM XP SCRUM y XP Agilidad o Disciplina?

Más detalles

MANTENIMIENTO DE SOFTWARE

MANTENIMIENTO DE SOFTWARE MANTENIMIENTO DE SOFTWARE Definición de Mantenimiento El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del Software como la modificación de un producto software después de haber sido entregado

Más detalles

Caso práctico. Examen oral para la acreditación de la licenciatura (EXOAL) Clave del caso práctico 777 Fecha de examen de primera etapa

Caso práctico. Examen oral para la acreditación de la licenciatura (EXOAL) Clave del caso práctico 777 Fecha de examen de primera etapa Caso práctico Examen oral para la acreditación de la licenciatura (EXOAL) Licenciatura por acreditar Nombre del sustentante Informática J. Genaro Contreras Ocampo Clave del caso práctico 777 Fecha de examen

Más detalles

Propiedad Colectiva del Código y Estándares de Codificación.

Propiedad Colectiva del Código y Estándares de Codificación. Propiedad Colectiva del Código y Estándares de Codificación. Carlos R. Becerra Castro. Ing. Civil Informática UTFSM. Introducción. n. En este trabajo se presentan específicamente dos prácticas de XP: Collective

Más detalles

Una mejor organización para los procesos de Desarrollo de Software

Una mejor organización para los procesos de Desarrollo de Software Una mejor organización para los procesos de Desarrollo de Software Informe Final Ingeniería de Software Avanzada Dr. Marcello Visconti 22 de Junio de 2004 Angelo Cabrera M. 9973012-9 Carol Chamblas R.

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza

Más detalles

Programación Extrema

Programación Extrema Programación Extrema Índice 1. Qué es XP?...2 1.1. Metodología ágil... 2 1.2. Definición...2 1.3. Posturas a favor y en contra... 2 2. Historia...4 3. Principios básicos... 5 4. Proceso de desarrollo...

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP) MATERIA : INGENIERIA SOFTWARE DOCENTE : LIC. ERVIN FLORES ESTUDIANTE : JORGE LUIS CORDERO

Más detalles

Continuous Integration Contenido

Continuous Integration Contenido Continuous Integration Contenido Continuous Integration... 1 Principios del Manifiesto Ágil... 3 Concepto... 3 Qué es integrar?... 3 Qué implica construir?... 3 Entonces, Qué es la Integración Continua?...

Más detalles

Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software.

Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software. Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software. Rodolfo Meda (rodolfomeda@yahoo.com), Jorge Ierache (jierache@yahoo.com.ar).

Más detalles

Revista Granma Ciencia. Vol. 16, no. 2 mayo - agosto 2012 ISSN 1027-975X

Revista Granma Ciencia. Vol. 16, no. 2 mayo - agosto 2012 ISSN 1027-975X Título: Gestión de la Calidad en el Ciclo de Desarrollo del Software de proyectos que usan metodologías ágiles. Title: Quality Management in Development Cycle Software projects using agile methodologies.

Más detalles

EL SECRETO DE UN SOFTWARE EXITOSO

EL SECRETO DE UN SOFTWARE EXITOSO EL SECRETO DE UN SOFTWARE EXITOSO Por Br. Carlos Soria, carlmanmagnifico@gmail.com RESUMEN El presente artículo nos muestra el impacto del software en el negocio, y él énfasis que se debe hacer en desarrollarlo

Más detalles

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013 Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles Iñigo Garro, Octubre de 2013 Este documento se ha basado en el informe técnico CMU/SEI-2010-TR-033 del Software Engineering Institute,

Más detalles

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE Recibido: 23 de febrero de 2011 Aceptado: 29 de marzo de 2011 SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE MSc. Ailin Orjuela, MSc. Luis Alberto Esteban, MSc.

Más detalles

Introducción a las Metodologías Ágiles. Nicolás Brailovsky March 7, 2009

Introducción a las Metodologías Ágiles. Nicolás Brailovsky March 7, 2009 Universidad Tecnológica Nacional Facultad Regional Buenos Aires Diseño de Sistemas Introducción a las Metodologías Ágiles Nicolás Brailovsky March 7, 2009 1 Qué es una metodología? 2 Metodologías Ágiles

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Tema 3. Procesos ligeros de desarrollo de software.

Tema 3. Procesos ligeros de desarrollo de software. Ingeniería del Software II 2011 Tema 3. Procesos ligeros de desarrollo de software. Tipos de procesos ligeros. Tipos de procesos ligeros: Desarrollo Rápido de Software. Desarrollo Ágil. Programación Extrema.

Más detalles

Seminario en CD Bases para Java

Seminario en CD Bases para Java G: Suplementos Hay varios suplementos para este libro, incluyendo el seminario grabado en el CD que se encuentra en la parte trasera del libro y otros artículos, seminarios y servicios disponibles a través

Más detalles

Está buscando servidores de aplicaciones basados en código abierto? Responda a las preguntas adecuadas y haga sus cálculos.

Está buscando servidores de aplicaciones basados en código abierto? Responda a las preguntas adecuadas y haga sus cálculos. Software de infraestructura de aplicaciones Para cubrir sus necesidades empresariales Está buscando servidores de aplicaciones basados en código abierto? Responda a las preguntas adecuadas y haga sus cálculos.

Más detalles

3-2-8. Participantes

3-2-8. Participantes 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos: METODOLOGIAS AGILES Licenciatura en Informática 3-2-8 2.- HISTORIA DEL PROGRAMA

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles

El modelo de ciclo de vida cascada, captura algunos principios básicos:

El modelo de ciclo de vida cascada, captura algunos principios básicos: Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada",

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio BPM Business Process Management Gestión de Procesos de Negocio Palabras Clave: BPM, Business Process Management, Workflow, Gestión de Procesos de Negocio, Reingeniería de Procesos, Optimización de Procesos,

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA Resumen AUTORIA CARLOS CABALLERO GONZÁLEZ TEMATICA INFORMÁTICA ETAPA ESO-BACHILLERATO-CFGM(ESI,ASI,DSI) Se describe la revolución que supuso la incursión

Más detalles

Período Teoría Práctica Laboratorio de crédito Electiva 3 0 0 3 Requisitos Metodología del Software

Período Teoría Práctica Laboratorio de crédito Electiva 3 0 0 3 Requisitos Metodología del Software Asignatura METODOLOGÍAS ÁGILES DE GESTIÓN Y DESARROLLO DE PROYECTOS DE TI Vigente desde: Marzo 2008 Horas semanales Unidades Período Teoría Práctica Laboratorio de crédito Electiva 3 0 0 3 Requisitos Metodología

Más detalles

http://www.informatizate.net

http://www.informatizate.net http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C.

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

ZENITH FORMATION ZENITH COACHING SERVICES

ZENITH FORMATION ZENITH COACHING SERVICES ZENITH FORMATION ZENITH COACHING SERVICES TABLA DE CONTENIDOS 1. Coaching 2 2. Qué es coaching?...2 3. Coaching Ontológico.2 4. El Coaching Ejecutivo...3 5. Coaching Organizacional.4 6. Proceso: Coaching

Más detalles

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L REFERE CIA AL SISTEMA EDUCATIVO ACTUAL. Los contenidos de este tema, están enfocados a introducir al alumno en el concepto de Ingeniería del

Más detalles

CMMi. Lic. Virginia Cuomo

CMMi. Lic. Virginia Cuomo CMMi Lic. Virginia Cuomo 1 Agenda Repaso CMMI Introducción Arquitectura Niveles de Madurez Representaciones Representación Discreta Representación Continua Discreta VS Continua 2 Repaso Qué vimos la tercer

Más detalles

La incertidumbre y la ingeniería de software María Irma Díaz

La incertidumbre y la ingeniería de software María Irma Díaz d o s La incertidumbre y la ingeniería de software María Irma Díaz Una respuesta metodológica al desafío de modificar el pensamiento para enfrentar las condiciones del presente y el futuro. A comienzos

Más detalles

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA).

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). López, G. 1 ; Jeder, I. 1 ; Echeverría, A. 1 ; Fierro, P. (PhD.) 2 1. Laboratorio de Informática de Gestión

Más detalles

Cómo mejorar la usabilidad de nuestra web: Metodologías y técnicas

Cómo mejorar la usabilidad de nuestra web: Metodologías y técnicas Usabilidad web Cómo mejorar la usabilidad de nuestra web: Metodologías y técnicas En apartados anteriores se ha visto la gran importancia de la usabilidad y la experiencia de usuario cuando tratamos temas

Más detalles

La clara definición de los procesos de elaboración de software, nos permite brindar un servicio predecible y de la más alta calidad.

La clara definición de los procesos de elaboración de software, nos permite brindar un servicio predecible y de la más alta calidad. Software Factory Presentación Concepto Dada la necesidad de las compañías de concentrarse en las actividades propias del negocio; y en tren de bajar costos, mejorar los tiempos de desarrollo o de no montar

Más detalles

ERP. SOLUCIÓN PARA PYMES?

ERP. SOLUCIÓN PARA PYMES? ERP. SOLUCIÓN PARA PYMES? Febrero 2011 Introducción La Planificación de Recursos Empresariales, o simplemente ERP (Enterprise Resourse Planning), es un conjunto de sistemas de información gerencial que

Más detalles

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles

Calidad y Mejoramiento de Procesos Ágiles. de Software

Calidad y Mejoramiento de Procesos Ágiles. de Software Calidad y Mejoramiento de Procesos Ágiles de Software Marcello Visconti Departamento de Informática Universidad Técnica Federico Santa María Valparaíso, Chile visconti@inf.utfsm.cl Agenda Introducción

Más detalles

Rol del Arquitecto de Software

Rol del Arquitecto de Software Rol del Arquitecto de Software Ing. Gustavo Andrés Brey Ing. Gastón Escobar 2005 Agenda # 1 2 3 4 5 6 Tema Introducción Responsabilidades y Organización del Grupo de Desarrollo Liderazgo y Mentoring Diferentes

Más detalles

Beneficios de la implantación de una metodología para el ciclo de vida de desarrollos software

Beneficios de la implantación de una metodología para el ciclo de vida de desarrollos software Beneficios de la implantación de una metodología para el ciclo de vida de desarrollos software Dirección de Desarrollo y Aplicaciones Miguel Martínez Vélez Agenda 1. Introducción 2. El Proceso Software

Más detalles

Siendo ITIL una ventaja aplicable a las organizaciones de TI, es implementable en cualquier empresa independientemente de su tamaño?.

Siendo ITIL una ventaja aplicable a las organizaciones de TI, es implementable en cualquier empresa independientemente de su tamaño?. ITSM para Pymes Autor: Norberto Figuerola Las Pyme experimentan problemas y desafíos que son inherentemente diferentes de los que deben enfrentar las empresas más grandes. Por lo general disponen de menos

Más detalles

Describir el CMMI para el desarrollo de software, evolución, alcance y representación

Describir el CMMI para el desarrollo de software, evolución, alcance y representación Unidad 6: Introducción a CMMI Objetivo terminal de la Unidad Describir el CMMI para el desarrollo de software, evolución, alcance y representación Temas: Acerca del Modelo Capacidad Madurez Evolución de

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

Orientaciones Iniciales

Orientaciones Iniciales Si es necesario, ajuste el idioma de la sala virtual en la barra de herramientas en la parte superior El evento tendrá 45 min. de presentación y 15 min. al final para preguntas Usted podrá mandar sus preguntas

Más detalles

Administración y Gestión de Proyectos de Software

Administración y Gestión de Proyectos de Software Administración y Gestión de Proyectos de Software 2do. Cuatrimestre 2005 Depto. Cs. e Ingeniería de la Computación Universidad Nacional del Sur Riesgo: Componentes Riesgo de Rendimiento: el grado de incertidumbre

Más detalles

Calidad y Mejoramiento de Procesos Ágiles de Software

Calidad y Mejoramiento de Procesos Ágiles de Software Calidad y Mejoramiento de Procesos Ágiles de Software M. Visconti & H. Astudillo Departamento de Informática Universidad Técnica Federico Santa María Introducción Principios

Más detalles

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos Capítulo 2 Ideas generales de CMMI-SW 2.1 Introducción El Capability Maturity Model Integration (en adelante CMMI), se compone de un conjunto de modelos, métodos de evaluación y cursos de formación para

Más detalles

Lineamientos de la JICA para la Evaluación de Proyectos

Lineamientos de la JICA para la Evaluación de Proyectos Lineamientos de la JICA para la Evaluación de Proyectos ~ Métodos Prácticos para la Evaluación de Proyectos ~ Septiembre de 2004 Oficina de Evaluación, Departamento de Planeación y Coordinación Agencia

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Gerencia Ágil de proyectos de software con base en ambientes

Gerencia Ágil de proyectos de software con base en ambientes Gerencia Ágil de proyectos de software con base en ambientes colaborativos María Consuelo Franky lfranky@javeriana.edu.co Universidad Javeriana 2011 pg.1 Temática Hemos oído de metodologías ágiles durante

Más detalles

WebRatio. Para el sector Energético y Empresas de Servicios Públicos. Web Models s.r.l. www.webratio.com contact@webratio.

WebRatio. Para el sector Energético y Empresas de Servicios Públicos. Web Models s.r.l. www.webratio.com contact@webratio. WebRatio Para el sector Energético y Empresas de Servicios Públicos Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 9 Web Models s.r.l. www.webratio.com contact@webratio.com 2 / 9 La necesidad:

Más detalles

Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y Sandra Dinora Orantes Jiménez

Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y Sandra Dinora Orantes Jiménez Revista Digital Universitaria 1 de enero 2012 Volumen 13 Número 1 ISSN: 1067-6079 Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y

Más detalles

CRC y un Taller. Ing. Diego Vallespir.

CRC y un Taller. Ing. Diego Vallespir. CRC y un Taller Ing. Diego Vallespir. Presentado para llamado a Grado 1 del Instituto de Computación - Facultad de Ingeniería Universidad de la República. 26 de Junio de 2002, Montevideo Uruguay. Resumen

Más detalles

Retos de la Gerencia de Proyectos de Software

Retos de la Gerencia de Proyectos de Software Retos de la Gerencia de Proyectos de Software Software and Cathedrals are much the same, First we build them then we pray!!! -Sam Redwine, Jr. Por Bernardo Díaz Arias berdiaz@yahoo.com Agenda 1. Introducción

Más detalles

capacitación y guía para el desarrollo de software Pruebas de Software Pruebas de Software 1

capacitación y guía para el desarrollo de software Pruebas de Software Pruebas de Software 1 Pruebas de Software Pruebas de Software 1 PRUEBAS DE SOFTWARE... 3 INTRODUCCIÓN... 3 Definiciones [1]... 3 Filosofía y Economía... 4 Justificación... 4 PRINCIPIOS [1]... 7 NIVELES DE PRUEBAS... 8 TIPOS

Más detalles

Ofertas y Contratos en Scrum

Ofertas y Contratos en Scrum Ofertas y Contratos en Scrum Aspectos que se deben considerar para ofertar y contratar proyectos de entrega incremental. José Vázquez Sánchez 2013 José Vázquez Sánchez Twitea sobre el libro! Por favor

Más detalles

IT Project Management Desarrollo de Software

IT Project Management Desarrollo de Software IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación

Más detalles

Mexico First. Propuesta. 11 de Mayo de 2015

Mexico First. Propuesta. 11 de Mayo de 2015 Propuesta Cursos: Certificación Scrum Master Accredited Certificación Scrum Team Member Accredited Certificación Scrum Product Owner Accredited Mexico First 11 de Mayo de 2015 Con atención: Andrá Simón

Más detalles

Metodologías Ágiles Desde una Perspectiva de Project Management. Fernando Contreras Velásquez Project Management & Engineering Services.

Metodologías Ágiles Desde una Perspectiva de Project Management. Fernando Contreras Velásquez Project Management & Engineering Services. Metodologías Ágiles Desde una Perspectiva de Project Management Fernando Contreras Velásquez Project Management & Engineering Services. Ing. Fernando Contreras Velásquez: PMP, PMI-SP, PMI-RMP Acerca del

Más detalles

Anuncio de software ZP11-0010 de IBM Europe, Middle East and Africa con fecha 18 de enero de 2011

Anuncio de software ZP11-0010 de IBM Europe, Middle East and Africa con fecha 18 de enero de 2011 con fecha 18 de enero de 2011 IBM Tivoli Business Service Manager for the Enterprise V4.2.1 permite que los negocios y las operaciones vean y comprendan las complejas relaciones de impacto empresarial

Más detalles

calidad brochure Software Quality Assurance/Project Management IDEOLOGY INTELLIGENCE INFORMATION IMPR INNOVATION ISO 9001:2000

calidad brochure Software Quality Assurance/Project Management IDEOLOGY INTELLIGENCE INFORMATION IMPR INNOVATION ISO 9001:2000 calidad 2009 brochure Software Quality Assurance/Project Management IDEOLOGY INTELLIGENCE INFORMATION IMPR INNOVATION Software Quality Assurance Project Management Dos de los factores que más positivamente

Más detalles

Modelos y Normas Disponibles de Implementar

Modelos y Normas Disponibles de Implementar Modelos y Normas Disponibles de Implementar AmericaVeintiuno tiene capacidad para asesorar a una organización en base a diferentes modelos o normativas enfocadas al mercado informático. A partir de determinar

Más detalles

DESARROLLO DE SOFTWARE DE CALIDAD: EXTREME PROGRAMMING Y HERRAMIENTAS OPENSOURCE. Mª Carmen Bartolomé. mcbartolome@qualityobjects.

DESARROLLO DE SOFTWARE DE CALIDAD: EXTREME PROGRAMMING Y HERRAMIENTAS OPENSOURCE. Mª Carmen Bartolomé. mcbartolome@qualityobjects. DESARROLLO DE SOFTWARE DE CALIDAD: EXTREME PROGRAMMING Y HERRAMIENTAS OPENSOURCE Mª Carmen Bartolomé mcbartolome@qualityobjects.com Índice Introducción a extreme Programming (XP) Herramientas OpenSource

Más detalles

Agile Testing. Sesión 8. Metodologías Ágiles de Desarrollo de Software Domingo Gallardo, DCCIA, Univ. Alicante

Agile Testing. Sesión 8. Metodologías Ágiles de Desarrollo de Software Domingo Gallardo, DCCIA, Univ. Alicante Agile Testing Sesión 8 Unas palabras previas de cautela Las pruebas no son una verificación formal de un programa, no pueden garantizar la corrección del software para todos los posibles casos de entrada

Más detalles

Desafíos de gestionar proyectos de analítica de negocios

Desafíos de gestionar proyectos de analítica de negocios Desafíos de gestionar proyectos de analítica de negocios Desafíos de gestionar proyectos de analítica de negocios Tipología de proyectos BA Complejidad de proyectos BA Proyectos BA versus tradicionales

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: CICLO DE VIDA VISIÓN TRADICIONAL DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN STEMAS DE INFORMACIÓN Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza M. Material revisado

Más detalles

Introducción a la implementación de Scrum

Introducción a la implementación de Scrum Introducción a la implementación de Scrum Jorge Iván Meza Martínez http://www.jorgeivanmeza.com/ Jorge Iván Meza Martínez - 1 Contenido Introducción. Historia. Qué es un proyecto. Gestión

Más detalles

LAS METODOLOGÍAS AGILES

LAS METODOLOGÍAS AGILES LAS METODOLOGÍAS AGILES Varias metodologías encajan bajo el estandarte de ágil. Mientras todas ellas comparten muchas características, también hay algunas diferencias significativas. No puedo resaltar

Más detalles

Checklist para Scrum Masters

Checklist para Scrum Masters Fuente original : Michael James (mj4scrum@gmail.com). http://www.colabpro.com 14 September 2007 (Revised 24 July 2012) Traducción : José Vázquez Sánchez. (a113779@gmail.com) http://www.gestiondeproyectosit.es

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles