jueves, noviembre 16, 2006

Requisitos No Funcionales - Parte 1


Con la moda de arquitectura (aunque es indiscutiblemente necesario tener un arquitecto en la organización… jejeje), se ha tomado mas en serio el tema de los REQUISITOS NO FUNCIONALES (aunque no lo crean, se deben tener en cuenta al hacer software), hoy voy a dar unos primeros conceptos para estos requisitos no funcionales.

Según Somerville, los requisitos no funcionales definen propiedades y restricciones del sistema, - aunque la palabra restricciones puede ser ambigua, porque en otros textos, una restricción es algo impuesto por la organización, desde el punto de vista de software, pero sigamos con Somerville. Algunos ejemplos de estos requisitos no funcionales son: Tiempo de Respuesta, Requisitos de almacenamiento, confiabilidad.

Estos requisitos pueden ser mas críticos que los requisitos funcionales, ya que son normalmente a los que debe apuntar la arquitectura y si estos no son cumplidos, el software puede no funcionar o el cliente simplemente no acepta el producto (OJO: No se dejen meter goles con las definiciones de requisitos no funcionales).

Dentro de estos requisitos no funcionales encontramos una clasificación que nos permite identificarlos mas fácilmente (cuando se definen taxonomias de lo que sea lo que se busca es entender mejor el concepto, DIVIDE y CONQUISTARAS; y les puedo garantizar que una clasificación no acelera la terminación del proyecto, pero permite trabajar mejor). Podemos encontrar tres grupos de requisitos no funcionales. Los requisitos de producto, los cuales especifican que el producto debe comportarse de una forma en particular. Ej. Velocidad de ejecución, confiabilidad, escalabilidad y otras tantas que en la parte 2 de esta nota explicaré.

Los requisitos Organizacionales (y aquí nos empezamos a perder porque solo pensamos en bolear código), los cuales son consecuencia de políticas y procedimientos organizacionales. Ej. Delivery, Requisitos de Implementación, Estándares.

Y los requisitos Externos, y estos si se pierden por causa del “síndrome del estudiante” (Otro concepto que explicaré después, pero que tiene que ver con la teoría de los proyectos que dice mi amigo John, donde al principio del proyecto nos dormimos, para después estar apurados), estos requisitos emergen de factores que son externos a los sistemas y sus procesos de desarrollo. Ej. Interoperabilidad, Requisitos Legislativos (Privacidad y Seguridad), Requisitos ETICOS Y MORALES.

Los requisitos no funcionales pueden ser difíciles de encontrar y enunciar de forma precisa y los requisitos que son imprecisos son difíciles de verificar. Por eso se deben definir muy bien las metas (OJO, diferentes a los objetivos… yo creía que eran lo mismo… ahí que arreglar el Enterprise Architect, Ej: El objetivo es medible, la meta es un esfuerzo) porque estas ayudan a los desarrolladores a transmitir las intenciones de los usuarios del sistema y a verificar los requisitos no funcionales.

Podemos ver que las metas y los requisitos no funcionales toman la siguiente forma:

Meta: Intención general de usuario, tal como facilidad de uso.

Requisito no funcional verificable: Un enunciado usando alguna MEDIDA que pueda se objetivamente probada (Y AQUÍ ES DONDE SE METEN LOS GOLES).

Ejemplos:

Una meta del sistema: El sistema debe ser fácil de usar por controladores experimentados y debe estar organizado de tal manera que los errores de usuario sean minimizados (ASI LO ENTREGAN… increíble!!!!).



Un requisito no funcional verificable: Los controladores experimentados deben ser capaces de usar todas las funciones del sistema después de un total de dos horas de entrenamiento. Después de este entrenamiento, el número promedio de errores generados por estos usuarios experimentados no deberá exceder de 2 por día. (ASI LO DEBEMOS TRADUCIR)



Si lo ven bien, si cumplimos este requisito no funcional, indiscutiblemente podemos cumplir con la meta, y por otro lado tenemos una base para iniciar un TRADE-OFF (negociación) con el cliente. Para que se entienda mejor, los requisitos no funcionales pueden presentar conflictos entre ellos, algunas veces cumplir un requisito NF al 100% implica impactar otro requisito. Ej: Portabilidad - Performance. Escalabilidad – Administrabilidad.



Requisito NO FUNCIONAL MAL ESCRITO: El sistema debe ser escalable. (Cuidado con los goles).



Otros ejemplos:

Requisito NF de producto: La interfaz de usuario para el sistema X, debe ser implementada como HTML simple sin FRAMES o Applets de Java (Para que tengan en cuenta a los diseñadores también).



RQ NF Organizacional: El proceso de desarrollo del sistema y los documentos entregables deberán estar conforme al proceso y entregables definidos en XYZ_1234. (Uichhhh… este no lo he visto escrito en un catalogo de requisitos).



RQ NF Externo: El sistema no revelará información personal acerca de los clientes aparte de su nombre y número de referencia a los operadores del sistema. (Aquí es donde dicen, “pero eso es obvio”… claro que puede ser obvio… pero hay que escribirlo).



(NOTA ADICIONAL: Escribir requisitos como lo especifica el estándar IEEE 830-1998, es decir, empezando “El sistema deberá”, no nos permite escribirlos de forma fácil, porque nos lleva a pensar inmediatamente en el software (es decir, debemos trabajar sobre lo no construido) y no nos dan idea de lo que realmente necesita el usuario (Por eso se deben utilizar Casos de Uso o Historias de Usuario).



Tácticas de desempeño



El desempeño, que puede ser medido en términos de LATENCIA (cuanto tiempo toma un servicio desde que recibe la petición, hasta que la petición es completada), tiempo de respuesta o throughput como lo ve el usuario, es muy importante en todos los sistemas. A la fecha, existen muchas teorías para manejar el desempeño, tales como teoría de encolado, teorías de planeación en tiempo real, redes de petri, etc.

Normalmente, se han usado en diseño de dispositivos de hardware, tales como switches. Con la llegada del desarrollo de software basado en componentes, la arquitectura de software, los ORBs, diseñar software para que tengan buen desempeño se ha convertido en un gran reto.

Las tácticas del SEI para desempeño caen en 3 categorías: Demanda de recursos, Gestión de Recursos y Arbitramiento de Recursos.

Para demanda de recursos, la primera táctica es incrementar la eficiencia computacional, esto no quiere decir comprar una maquina mas grande, sino mejorar los algoritmos en las áreas criticas (esto para no pelear con los clientes).

La segunda táctica es reducir sobreesfuerzo computacional, ejemplo, usar llamados binarios en vez de RMI.

La tercera táctica es manejar las tasas de eventos, por ejemplo, reducir la frecuencia de muestreo o por medio de cerrados parciales.

La cuarta táctica es controlar la frecuencia de muestreo.

Para la gestión de recursos la primera táctica es introducir concurrencia. La segunda táctica es mantener múltiples copias de los datos, por ejemplo, utilizando esquemas de caching.

La tercera táctica es incrementar la cantidad de recursos disponibles, por ejemplo, procesadores más rápidos, procesadores adicionales, memoria adicional, y redes más rápidas.

Para el arbitramiento de recursos, la táctica es definir políticas de planeación, como FIFO, planeamiento con prioridad fija, planeamiento estático.

Cada una de estas tácticas puede ser resuelta por software, ej. Cuando se quiere reducir la tasa de eventos se puede crear un filtro que nos permita controlar las tasas de llegada de peticiones (aunque pueden perderse peticiones).

Cuales son los artefactos de SCRUM? El PRODUCT BACKLOG

En SCRUM tenemos varios artefactos que se deben llevar, estos se utilizan en tarea especificas dentro del proceso de desarrollo.

Como todo en esta vida no es echar código, en una serie de correos les estaré empapando de estos temas.

Iniciemos con el Product Backlog

El dueño del producto (internamente son los directores de proyecto) deben articular la visión del producto. Esto se lleva a cabo listando las características requeridas, priorizadas en orden de que es de MAYOR VALOR PARA EL NEGOCIO (No empezando por los maestros), cual puede tener mayor ROI para la compañía (nota: Que no hagamos parte de las empresas clientes, no quiere decir que no sepamos que es de mayor valor para el negocio del cliente, y hacer propuestas). Esta priorización pone los ítems de mayor valor en el TOP. Si lo vemos desde el punto de vista de la mejora de procesos, esto es un proceso de toma de decisión para DESARROLLO DE REQUISITOS y SOLUCION TECNICA, desde el punto de vista de saber que componentes se van a desarrollar primero, es la forma de sustentar por que empezamos el proyecto por donde empezamos. Este listado priorizado debe quedar sustentado en el PRODUCT BACKLOG, el cual es un artefacto que debe existir en todo momento y evolucionar conforme el producto se va desarrollando. Ojo: Evolucionar para cambiar la priorización o para adicionar características.

Este PRODUCT BACKLOG incluirá una variedad de ítems, como características (“Permitir a todos los usuarios ingresar a la aplicación dependiendo del rol”), requisitos no funcionales (“Mejorar el procesos cache para que sea distribuible y escalable en cluster”, “Mejorar la consultas de base de datos para que utilicen el optimizador por ESTADISTICAS”, etc.), trabajo exploratorio (“Investigar soluciones para acelerar el llenado de la planilla con AJAX”), y bugs conocidos (“Diagnosticas y arreglar los errores de Javascript cuando se asigna un BUG en Mantis (BUG 1232) ”).

Uno de los errores que se comete cuando se definen ítems (no actividades, ni tareas, sino ítems) es no definir el detalle en el cual se escribirán. Mi recomendación es que en los primeros sprints se definen características y/o funcionalidades generales. Pero después se debe ir refinando para dar un mayor detalle a cada uno de los ítems. Sugerencia: Utilizar el menor espacio para dar el mayor detalle. Ej.:

1. Mejorar el procesos cache para que sea distribuible y escalable en cluster

2. Mejorar el procesos cache para que sea distribuible y escalable en cluster, soportar 500 transacciones simultaneas, Granja de 3 servidores OAS en cluster.

Se supone que este product backlog será partido en piezas mas pequeñas en las Sprint Planning Meetings.

Eres POLLO o CERDO?


Una de las cosas principales para aplicar una metodología es que hay que ser puristas en la teoría y adaptar en la practica (Tailoring). Hoy, voy a ser un poco purista en cuanto a las metodologías ágiles, específicamente en scrum.

Scrum es un juego de CERDOS y POLLOS.

Esta caricatura de arriba representa 2 de los 4 roles de Scrum, El tercer rol no mencionado en la caricatura es el Scrum Master, del cual hablaremos después. Otro rol es el Product Owner, (que realmente es un PUERCO disfrazado... jejeje).

Los CERDOS son aquellos que están metidos de lleno en el cuento. Son aquellos que van a dar el “tocino”. En otras palabras, los CERDOS son considerados los miembros del equipo desarrollador, los que ejecutan. La gente que hace el trabajo….

Un POLLO es alguien que obtiene ganancias con lo que hacen los CERDOS, pero realmente, no contribuyen día a día a que las cosas se hagan. Sus aportes (Huevos) son recursos renovables. Son personas que están interesadas, pero que no están trabajando. El Scrum Team debe estar compuesto de máximo 6-9 miembros tipo PIG.

Los CERDOS, hablan en cada Scrum Meeting… Si… la reunioncita que hacen todos los días, que aunque no lo crean no es una reunión personal, es una reunión del equipo para mejorar la comunicación y no tener algo de lo que hablaba anteriormente INDISPENSABILIDAD EN LOS EQUIPOS DE TRABAJO. Estos CERDOS son contribuyentes a la solución.

Los POLLOS no están comprometidos con el proyecto y no son responsables en los entregables, no hablan en las reuniones. Son personan que son excesos en la reunión. Los POLLOS son los chismosos. Por donde quiera que se mire, son negativos porque tienden a disminuir la productividad. Son parásitos que viven del trabajo de los CERDOS. Lo siento mucho por los comentarios fuertes, pero si alguien ayuda a definir un eufenismo que pueda equilibrar el decirlo “agradablemente” y comunicar que los POLLOS deben minimizar el impacto en la productividad del equipo.

Se pueden identificar fácilmente, porque solo quieren saber que pasa en el Scrum porque impacta en su trabajo de alguna manera. No necesitan saber que pasa en el Daily Scrum. Solo necesitan conocer sus actividades, y al final del SPRINT (otra vez con T), el donde realmente son productivos, es decir, están involucrados, pero no comprometidos.

A los POLLOS les gusta ir a las reuniones solo para lloriquear porque no llegaron a las metas porque fueron a los Daily Scrum.

Los proyectos no pueden tener muchos POLLOS porque estos pueden hundir el barco. Pero pueden ser útiles si solo se les tiene en cuenta para el final del sprint para mostrar resultados sin tenerlos en cuenta en los Daily Scrum.







Tenemos que ser ARIDOS


Mientras que existen métodos para analizar y evaluar arquitecturas, tales como SAAM, ATAM, CBAM, QAW. Los diseñadores y arquitectos (y también los encargados de la calidad del software) necesitan hacer ZOOM a los diseños para revisar sin son viables estas estrategias tempranas de diseño.

Estas estrategias iniciales son pobremente documentadas y diagramadas, y presentan una falta de detalles importantes que indiscutiblemente surgirán en etapas posteriores (les parece conocido….. Es que en la vida no todo es bolear código). Eso sin contar con que la documentación solo se hace como para cumplir un requisito y no se mantiene una constante actualización que permita minimizar los tiempos de empalme y de “curva de aprendizaje” a la cual le tienen tanto miedo. Aunque no crean, en mi mas humilde opinión, el fracaso de la mayoría de los proyectos de desarrollo se debe al miedo al cambio, adopción de la tecnología adecuada (por la “curva de aprendizaje”) y a la indispensabilidad (o poca comunicación en el equipo de trabajo), esto ultimo se resume a una frase que ya he escuchado en varios proyectos y que es síntoma de una mala gestión y de una mala comunicación en el equipo, “Es que el único que sabe de eso es perengano”, o “Es que yo soy el único que puede hacer eso” (que pasa si se incapacita, se acaba el proyecto?).

Pero me desvié mucho del tema (La buena gestión de proyecto es otro tema mucho mas largo que discutir). Retomando la pobre documentación en el diseño inicial, la revisión del diseño en etapas tempranas puede descubrir importantes inconsistencias en donde una corrección temprana de estas puede ser invaluable para el proyecto. Si lo vemos en plata, es menos tiempo, pero yo lo veo mas como las trasnochadas de los desarrolladores, la mala fama ante los clientes, las inconformidades en las entregas y la mejora en la estimación de los SPRINTS (con T).

Para solventar este problema, el SEI (Software Engineering Institute) ha trabajado en un método llamado ARID (por Active Reviews for Intermediate Designs) complementario a las revisiones de arquitectura. Este permite asegurar diseño detallados de alta calidad en el desarrollo de software. Como lo cita el SEI en http://www.sei.cmu.edu/architecture/arid.html; “El método asegura participación activa de los revisores cuestionándolos a utilizar el diseño en una serie de ejercicios, mientras que se evitan las preguntas SI/NO que son fácilmente de contestar para el revisor con respuestas no muy claras y a la ligera”. Por esto, se prueba un diseño de forma real y no fingido.

Como una introducción a ARID, muestro estos 4 grandes pasos:

  1. Se deben identificar los revisores. Se recomienda que sean los encargados de utilizar el diseño, si son diferentes a los diseñadores.
  2. Se prepara una breve explicación del diseño (por parte del diseñador). Se presenta a los revisores y hace explicación completa de los ejercicios usando el diseño.
  3. Los revisores realizan una tormenta de ideas para usar el diseño para resolver los problemas que esperan enfrentar. Se priorizan los escenarios, y se define como se puede utilizar el diseño en el escenario. Si el diseño trabaja bien para los escenarios definidos, entonces se acuerda que el diseño ha pasado la revisión.
  4. Los revisores realizan pseudo-código donde usen servicios del diseño para los escenarios de mas alta prioridad. Y se almacenan los problemas, inconvenientes y lugares que son difíciles de pasar.

Igual a las sesiones JAD, este método puede ser difícil de implementar en empresas donde los proyectos son pequeños, donde no existen muchos revisores (Creo que por ese muro mental que se tienen a las revisiones en grupo). Y donde los diseños se saquen a la ligera por el afán de escribir código. Pero puede ser una herramienta fuerte para la detección de problemas tempranos, y sobre todo a ver si utilizamos el titulo de Ingenieros para algo diferente a bolear código.

SOA, cual es la realidad?


Como cualquier nuevo paradigma tecnológico o de TI, SOA esta teniendo el mismo problema en el que generalmente siempre se empieza a trabajar con él desde la implementación, cometiéndose el error de querer implementar algo que no se tiene claro, de lo cual no se tiene conocimiento. Y es que el público en general cree que SOA es que la aplicación tenga un Web Service o que las aplicaciones expongan Web Services. Esto apoyado con la tarea de los grandes proveedores de software que prometen implementar SOA en todas las aplicaciones son haciendo clic.

Primero que todo, SOA inicia como una estrategia de arquitectura empresarial, esto quiere decir que, como toda estrategia empresarial debe tener el sponsorship de la alta gerencia (Quien es tu papá?), al fin y al cabo a ellos les interesa es el ROI (Soportar al negocio). Además de esto esta basado en servicios que hacen parte de un proceso, ya sea de soporte o de la cadena de valor, pero al fin y al cabo procesos, que deben ser definidos antes que todo para implementar SOA (Tener una visión).


Para poder definir los procesos organizacionales, se debe empezar a pensar en las labores de cada uno de los empleados de la compañía y a su vez para implementar SOA se debe tener un respaldo fuerte de los actores de los procesos, porque es muy probable que varios cargos o actividades se vean afectados por la nueva estrategia organizacional y tal vez puedan presentarse cambios de cargos, actividades o en ultima instancia despidos.

Ahora, SOA no cabe en todas las organizaciones, SOA es exitoso para compañías donde los procesos pueden tener puntos transversales comunes, se tengan long running process, no basta con querer que la nomina “hable” con el aplicativo de proveedores.

Y si esto no es suficiente, todos dicen, “Queremos que la aplicación tenga una arquitectura SOA”, aun sabiendo que las aplicaciones no tienen arquitectura SOA, es la estrategia de TI, las aplicaciones se pueden hacer SOA-Enabled, esto quiere decir, que expongan servicios y que puedan ser integradas (Definir proyectos alcanzables). Esto demanda una muy buena definición del negocio, una excelente definición de casos de uso, y algo a lo que no se esta muy acostumbrado. Una buena correlación entre casos de uso y componentes de negocio. Esto a su vez implica un cambio en los paradigmas de ventas y de gestión de los proyectos actuales. Ya que los componentes deben ser reutilizables, se requiere que se requiere mucho más tiempo en el diseño y en la documentación de las interfaces que en la implementación. Y esto debe ser un común denominador para todos los proyectos de software, porque al fin y al cabo “NO TODO EN LA VIDA ES ECHAR CÓDIGO”. Para esto se requieren INGENIEROS DE SOFTWARE o SISTEMAS y no PROGRAMADORES (Lo cual lastimosamente, parece que se nos está olvidando).

Ahora, hablando de que las aplicaciones deben ser SOA Enabled, quiere decir que exponen servicios (La flexibilidad ante todo), teniendo en cuenta que servicios no son Web Services y que Web Services no es SOA. Un servicio puede ser creado con cualquier tecnología de acceso remoto (http, RMI, COM+, DCOM, CORBA, Sockets) y los Web Services pueden ser creados con SOAP o con REST. Por otra parte, es difícil exponer servicios en un sistema legado COBOL, no es solo hacer clic como lo prometen.

Ya para concluir, desde el punto de vista de la compañía (nuestros clientes) no se puede estar pensando todavía que la implementación de estrategias de TI se empiezan con la compra de software, se debe empezar con la definición clara del panorama tecnológico organizacional y esto implica muchos cambios organizacionales y mucha inversión en reestructuración de la compañía y cambio en la mentalidad de los empleados (Perder el miedo al cambio). Y que desde el punto de empresa de desarrollo (Avansoft en este caso), no se puede hacer software solo con “código ventiao”, existen métodos, metodologías, patrones, artefactos, etc. Que deben ser ANALIZADOS y DISEÑADOS con mucho mas tiempo que el que gastamos mirando como lo hacemos en Java o .NET (y esa es otra discusión, es que el desarrollo de software no es solo decir que .NET es mejor que Java porque tiene menos código, o lo contrario). Ojo: Solo el 50% de los proyectos de TI son exitosos.

Una nota de Matt Hotle de Gartner, “para el 2008, el desarrollo de software se debe enfocar en Workflow (Y eso que es? Como se come?), funcionalidad y procesos (Procesos? Será que pensamos en eso? Y cuando boleamos código?), no aplicaciones tipo SILOS o CHIMENEAS. Los desarrolladores tendrán que escribir aplicaciones compuestas una vez y REUTILIZAR sus componentes muchas veces en todo el negocio”. Y continua “Una cultura de REUTILIZACIÓN será aceptada y el desarrollo de aplicaciones orientadas a servicios dominará” “El código será bien usado y los desarrolladores deben estar motivados para hacerlo”.Porque esperara hasta el 2008? No podemos empezar ya?.

jueves, septiembre 28, 2006

¿Como decidir que framework de AJAX se debe utilizar?

AJAX se ha convertido en una de las innovaciones tecnológicas con más crecimiento en el último año. Este crecimiento ha traído la proliferación de una gran cantidad de middleware (frameworks, librerías y toolkits) que permiten hacer uso de este conjunto de tecnologías de forma más fácil.

Pero la gran cantidad de middleware existente hace que sea difícil saber cual tener en cuenta al momento de tomar una decisión en el desarrollo de un aplicativo.

La importancia de utilizar un framework, toolkit o librería radica en la reutilización de funcionalidad, ya que lo más importante de usarlos o no es poder evitarle al desarrollador los problemas de trabajar con Javascript, DHTML y XML todo junto.

Para poder saber como utilizar estos componentes reutilizables. Debemos tener en cuenta que tipo de middleware se ofrecen en el mercado para trabajar con AJAX. Estos middleware pueden ser frameworks, librerías de widgets [1]o toolkits.

Los primeros, como Gamma lo indica, son “un conjunto de clases cooperando que hacen uso de un diseño reusable para una clase de software especifico”. En este caso, los frameworks AJAX proveen simplemente el uso de AJAX en una aplicación Web y ocultar el trabajo con Javascript y XML.

Los toolkits, son un conjunto de clases relacionadas y reusables que proveen funcionalidad de propósito general; en este caso, los toolkits de AJAX permiten el trabajo con AJAX en general y no se concentran en un tipo específico de aplicaciones o software.

Por ultimo, las librerías de widgets son un conjunto de etiquetas y widgets predeterminados de los cuales se puede hacer uso en una aplicación, son fáciles de usar pero no son tan flexibles como los frameworks y toolkits.

Existe otra clasificación para los middleware de AJAX, esta es por la plataforma objetivo del middleware. Un ejemplo de esto es que existen frameworks AJAX java centric, dot NET centric, Struts centric, JSF centric, PHP centric, etc.

Para poder decidir que framework de AJAX se debe utilizar debemos comparar que tan beneficioso es para el desarrollo. Pero lo importante es definir los criterios que nos permiten esa comparación. Aquí miraremos los criterios y definiremos cuales son los mejores frameworks o toolkits a utilizar.

  1. Plataforma.

La plataforma en la cual esta soportado el middleware es el primer criterio que se debe tener en cuenta para la selección. Para Java se pueden tener en cuenta (aunque no son los únicos) DWR (Direct Web Remoting), Echo2 en cuanto a frameworks o Dojo, Script.aculo.us, Prototype, AJAXLib por parte de los toolkits. En .NET existen frameworks como AJAX Engine, ATLAS, ConfortASP .NET, MagicAJAX .NET, Telerik. Y para php existen AjaxAC, Zoop.

  1. Orientación.

Para Java, podemos tener frameworks que se especializan para una tecnología especifica, como JSP, JSF, TagLibraries, Struts.

  1. Programación Directa o Indirecta.

La programación de AJAX puede ser indirecta o directa. En la programación indirecta se permite la actualización del contenido de la página sin programar en AJAX directamente.

Concretamente, la programación directa de AJAX, significa tratar con scripts en el cliente, DHTML, métodos delegados, despliegue en el lado del cliente, etc.

Las soluciones de programación indirecta de AJAX, permiten actualizar proyectos ya creados, mientras que las soluciones de programación directa; son mas recomendadas para proyectos nuevos, y permiten mas control del código (tu sabes que se está haciendo).

  1. Soporte de controles no AJAX.

Otra característica importante es que se soporten controles no AJAX y se mejoren con características AJAX, es decir, que no solo provean controles con AJAX incluido sino que se pueda extender el uso de AJAX a otros controles. Las librerías con controles preestablecidos, son útiles para características muy simples o cuando el equipo desarrollador tiene un conocimiento bajo o nulo de AJAX.

  1. Soporte de Múltiples Navegadores

Dependiendo de las condiciones del cliente, se puede establecer que se requiere portabilidad en varios navegadores, esto hace importante que se deba utilizar un framework o toolkit que soporte las necesidades del cliente.

  1. Trafico de Red.

Es necesario saber que tanto tráfico el framework o toolkit envía y recibe en una petición. Esto puede afectar directamente el desempeño del aplicativo. Por ejemplo, para una prueba de concepto con el Hello World, el framework con más consumo de tráfico de red para .NET fue ATLAS y el menor fue FastPage.

  1. Instalación.

Muchos de estos frameworks son tan fáciles de instalar como montar archivos .jar o assemblies, pero otros son mucho más difíciles por las dependencias requeridas para que el framework funcione correctamente. El grado de dificultad para instalar se convierte en un factor clave para la selección del framework.

Cuando se debe trabajar con AJAX, no podemos determinar un solo middleware que sirva para todo tipo de proyectos, por eso se debe tener en cuenta las características de la funcionalidad que se quiere desarrollar en AJAX para poder elegir el framework correcto. Igualmente, no se trata de tener 2, 3 o 4 frameworks en el mismo proyecto, sino tratar de cubrir el mayor número de características a implementar con AJAX en el mismo aplicativo.

Para la plataforma Java, cuando se quiere tener control total sobre el código que se quiere implementar del lado del cliente, lo mejor es optar por un toolkit como Dojo o Script.aculo.us.

Si tenemos un aplicativo que requiera implementar AJAX con controles estándar (textbox, input) la mejor opción es una librería de Widgets, Ej., AjaxTags. Para el trabajo con Struts o JSF se puede trabajar con Dojo o con un framework específico para la tecnología como AjaxAnyWhere o ajaX JSF Framework; o trabajar con la última versión de Struts (Shale).

Para el trabajo con .Net los frameworks más recomendables son ComfortASP y ATLAS.

Por último y para recordar, Internet Explorer presenta una fuga de memoria cuando se trabaja con scripts en el cliente y DHTML. Dependiendo del framework que se utilice, la fuga de memoria es diferente.



[1] Window Gadget. Término genérico para referirse a los elementos de una interfaz gráfica con el usuario, como botones, barras de desplazamiento, campos de entrada de texto, etc.

miércoles, abril 26, 2006

SCRUM. Una Herramienta de Hiper-Productividad


El problema para los desarrolladores es que los cambios en el software se traducen en problemas, especialmente cuando el error puede “tumbar” el sistema completo. Con Scrum se trata de convertir estos problemas en oportunidades.


Para Rugby, Scrum es la forma de reiniciar el juego, después de una falta menor. En cambio, en desarrollo de software, Scrum es una mejora a las aproximaciones metodologicas incrementales e iterativas, que lo que busca es tener una “caja negra” controlada.

El proceso de desarrollo de software es complejo y complicado. Sobretodo si se requiere alta flexibilidad y control. Para esto, la selección de la metodología juega un papel importante para determinar la probabilidad de éxito en el proyecto. Las metodologías ágiles permiten esta flexibilidad, pero eventualmente pueden tornarse impredecibles e impracticas.

Scrum, tiene como premisa ser una “herramienta hiper-productiva”. Su objetivo primordial es encontrar el máximo de productividad de un equipo de desarrollo. Tratando de reducir al máximo la burocracia y los riesgos generados por las actividades no orientadas a producir software, optimizando al máximo el retorno de la inversión y dando valor agregado en corto tiempo.

Este proceso ágil, tiene varias características, una de ellas es que es un proceso iterativo con iteraciones mensuales en las cuales el cliente interactúa con el equipo para saber que quiere desarrollar. Existen 3 actores en Scrum, uno de ellos es el equipo desarrollador (Scrum Team), que es autogerenciado, y sabe que es lo que va a hacer, el cliente que se llama Product Owner que se encarga de saber que funcionalidades son de alto riesgo para el producto y quiere que sea implementado para la próxima iteración mensual, llamada Sprint. Al inicio de cada Sprint, el equipo se reúne en una Sprint Planning Meeting y en conjunto con el Product Owner prioriza las características a desarrollar del producto que están consignadas en un artefacto llamado Product Backlog. De esta priorización el Scrum Team selecciona la tareas que se van a completar durante el Sprint, y estas tareas son “movidas” del Product Backlog al Sprint Backlog que es un artefacto en el cual se almacenan las actividades del Sprint.

Durante todo el mes, se realizan reuniones diarias al inicio del día, llamadas Daily Scrum Meeting, en las cuales se resuelven los problemas que se tuvieron desde la anterior reunión. Los problemas que se deben resolver en los Daily Scrum se basan en dar respuesta a las siguientes preguntas:

- ¿Que hiciste ayer?

- ¿Que harás hoy?

- ¿Hubo algún impedimento para realizar tu trabajo?

Enfocándose solo en lo que se hizo ayer y lo que se hará hoy, se gana un buen entendimiento de la velocidad con que se desarrolla el proyecto. Esta reunión no es para que un jefe recolecte información de lo que están haciendo los miembros del equipo o quien se esta atrasando. En vez de eso, esta reunión es para que lo miembros hagan compromisos con los otros miembros y haya una buena comunicación en el equipo, es decir, alinear a las personas hacia una misma dirección. Esta reunión es coordinada por el tercer actor, el Scrum Master, que (y espero se entienda bien), no es un director de proyectos, es el líder del equipo que se encarga de que los miembro del equipo se compenetren con las practicas y valores de Scrum, vela para que el equipo no se comprometa con cosas que puede cumplir durante el Sprint, además de facilitar y ser responsable de remover cualquier obstáculo que el equipo reporta en las reuniones diarias.

A pesar de que Scrum parece ser un proceso simple, para medianos y pequeños proyectos, no nos podemos dejar engañar. Solo un tercio de las empresas que adoptan Scrum logran implementarlo con éxito. Y no es porque Scrum no sirva, es porque realmente es difícil de implementar, debido a que las organizaciones están estructuradas para construir software de forma tradicional en la cuales los equipos son controlados y comandados por alguien que les dice que hacer, mientras que Scrum requiere de equipos autogerenciados, además de los roles funcionales contra los equipos ínter funcionales con la capacidad de entregar productos al cliente de forma mas rápida. En resumen, es difícil de implementar porque requiere un cambio de hábitos que se han mantenido a lo largo de los años, esto es algo con lo que las organizaciones deben lidiar. Pero la forma de afectar esto es crear cultura, empezando con un equipo a trabajar y ver que no se esta trabajando con un batallón militar, sino como equipo colaborativos, con personas que están pensando como resolver problemas conjuntamente, cuando los otros equipos vean esta forma de trabajar, van a querer saber que esta haciendo ese equipo para ser productivo, y eventualmente los cliente se van a dar cuenta que se le esta entregando software cada mes y va a querer saber como se trabaja y va a integrarse al proceso, y al final toda la organización va a estar trabajando con esta herramienta altamente productiva.

miércoles, abril 05, 2006

AJAX, el ¿que?, y ¿donde?


Desde hace varios años, los clientes siempre nos han preguntado como hacer para que una aplicación Web tenga la misma facilidad de respuesta y versatilidad de una aplicación de escritorio.

Debido a la simplicidad de las aplicaciones Web, existe una brecha entre estos 2 tipos de aplicaciones.

Esta brecha se está cerrando, con las nuevas tecnologías y los avances en los nuevos navegadores en la Web, podemos lograr una mayor y mejor experiencia para los usuarios de nuestras aplicaciones.

Así como LAMP o SPA ha surgido un nuevo conjunto de tecnología llamado AJAX, que representa un cambio fundamental en lo que es posible hacer en las aplicaciones Web.

Que es?

Ajax no es un framework, ni una nueva tecnología, ni un API. Es realmente un conjunto de tecnologías existentes desde hace varios años, pero que antes se usaban independientemente, y que ahora en conjunto ofrecen nuevas formas de trabajo para las aplicaciones Web.

AJAX es la abreviatura de Asynchronous JavaScript and XML (ingles para Javascript Asíncrono y XML), y esta compuesto por tecnologías como Hojas de Estilo en Cascada y XHTML, DOM (Documento Object Model), XML y XSLT, XMLHttpRequest, y Javascript.


Comúnmente, las aplicaciones Web funcionan con un esquema petición-respuesta, en donde las acciones del usuario disparan peticiones HTTP al servidor. El servidor realiza algún procesamiento y retorna una respuesta HTML al cliente.

Esto requiere que el usuario tenga que esperar hasta que se pinte la pantalla cada vez que la aplicación requiere algo del servidor.

Con una aplicación con AJAX, logramos eliminar esta característica propia de las aplicaciones Web. Aquí se introduce un componente mas entre el servidor y el usuario, el motor Ajax. Al inicio de una sesión, se carga el motor Ajax, en un frame oculto, el cual se encarga de pintar la interfaz y de enviar y recibir peticiones del servidor. Ajax muestra un esquema de interacción con el servidor de la siguiente manera
A grandes rasgos la interacción es similar al esquema clásico; la diferencia radica en el concepto de Asincronía, que permite hacer las peticiones sin requerir que el usuario vea que la pantalla se tiene que pintar nuevamente, algo antes hecho usando DHTML, y mostrado en el framework UIX de Oracle que le dio el nombre de Partial Page Rendering.

¿Donde y Cuando?

Como toda tecnología nueva, no debemos correr a implementarla en todos los proyectos, solo por estar a la moda, existen ciertas características que deben tener las aplicaciones para poder obtener las mayores ventajas de Ajax.

Debido a que Ajax es un conjunto de tecnologías y no un framework, el uso de este al inicio del proyecto, en un proyecto ya existente o en fases de mantenimiento es viable, siempre y cuando se tengan las siguientes características en las aplicaciones:

  1. Interacción basada en Formas.

La naturaleza de los formularios es que son lentos, todos requieren que se envíe la petición al servidor y que regrese la respuesta. Con AJAX las validaciones son en línea y los cambios pueden ser vistos instantáneamente.

  1. Menús de Selección

Es una variante de los formularios. Si tenemos un menú de selección como de países y departamentos, la lista de departamentos puede ser generada dinámicamente sin requerir que se pinte toda la pantalla.

  1. Navegación con Árboles Jerárquicos.

Las aplicaciones con menús tipo árbol son muy complejas. Se pueden hacer con DHTML y cargar todo el menú en Javascript lo que lo hace pesado, o se puede hacer dinámico, pero pintando toda la pagina. Con AJAX se puede recuperar desde el servidor la parte del árbol que se requiere y solo actualizar esa parte del menú.

  1. Comunicación P2P rápida – chats.

Antes los chats si no eran hechos con tecnologías como Applets, no se podían tener notificaciones inmediatas a menos que se pintara la página cada cierto tiempo. Con AJAX podemos hacer las actualizaciones del Chat mucho más rápido porque no hay que pintar todos los mensajes anteriores. Ej.: GMail con Gtalk integrado.

  1. Votaciones, Encuestas

Con AJAX se puede tener el resultado de las votaciones, inmediatamente después de hacer el envío de la elección hecha.

  1. Manipulación de datos y filtros.

Cuando se trabaja con tablas de datos, que pueden requerir ordenamiento o filtros, no es necesario ir al servidor. Esta puede ser hecha con AJAX para que sea mucho más rápido.

  1. Auto completar y texto comúnmente ingresado.

Si siempre se ingresa la misma frase o tener texto predictivo es muy útil en las aplicaciones Web y esto puede ser logrado con AJAX, como en Google Suggest.

  1. Errores Interactivos.

El proceso de entrada de datos puede ser muy rápido si con AJAX se hacen las validaciones inmediatamente después de que el usuario ha ingresado un dato, sin necesidad de terminar todo el formulario.

  1. Queries muy grandes – Web Services (Llamados Remotos).

Los llamados a Web Services que tomen mucho tiempo, pueden ser manejados con AJAX, los usuarios no tienen que esperar a que el Web Service responda para seguir trabajando en la aplicación.

  1. Operaciones Computacionales Costosas.

Javascript es muy lento para realizar operaciones matemáticas. Con AJAX, todas estas operaciones pueden ser hechas en el servidor y mostrar el resultado inmediatamente sin el tiempo de latencia de pintar el resultado.

Cuando NO? Riesgos?

Hasta ahora se han identificado 3 riesgos potenciales al momento de utilizar AJAX. Estos son inherentes al procesamiento asíncrono y a las tecnologías que hacen posible este tipo de procesamiento.

  1. Compatibilidad de Javascript.

Javascript siempre ha tenido problemas de compatibilidad con los distintos browsers. Esto puede ser un riegos si el aplicativo va dirigido a varios navegadores, pero puede ser evitado con algo de esfuerzo al hacer las librerías AJAX o con un cross-browser AJAX framework.

  1. Compatibilidad de los Bookmarks (Favoritos)

Al igual que los frames, cuando se trabaja con AJAX y con páginas dinámicamente generadas, existe el problema que no se puede hacer bookmark de la página generada porque la URL puede llevar a un lugar no deseado.

  1. Compatibilidad del botón regresar.

AJAX rompe la funcionalidad del botón regresar, porque el histórico es dinámicamente generado. Si el usuario requiere este botón hay que tener mucho cuidado al usar AJAX. Existen scripts que permiten evitar este problema.

  1. Múltiples peticiones.

Si tenemos un script que vaya muchas veces al servidor usando AJAX, se debe tener en cuenta el número de usuarios que usaran el aplicativo, ya que estos multiplicarán el número de peticiones y pueden generar indisponibilidad del servidor.

Como vimos, al igual que cualquier tecnologia, Ajax tiene sus ventajas y desventajas. Igualmente debe ser usado en ciertos tipos de aplicaciones y para en algunos casos. Podemos esperar que Ajax mejore los tiempos de respuesta de una aplicación, como un plus al objetivo inicial, que es mejorar la experiencia del usuario.

miércoles, marzo 29, 2006

REUTILIZACION, Es cuestión de cultura.


Sabes UML?, Sabes Java?.... esas son las preguntas que te hacen normalmente para ingresar a una compañía. Y revisando pensums, experiencias, cursos, seminarios, etc., etc., etc. se diría: “Esas aplicaciones deben salir perfectas”. Pero la cruda verdad es que no es así.

Al parecer todos esos papeles (porque los cursos parecen que no son mas que eso) no sirven para nada si no existe una CULTURA para el desarrollo de software y la calidad que debemos lograr. Se supone que con el nivel de nuestros analistas debemos tener una gran reutilización de componentes y no estar haciendo las mismas cosas cientos de veces para cada aplicación. ¿Pero donde están esos componentes? ¿Donde esta esa reutilización? ¿Porque se esta volviendo a hacer lo que miles de desarrolladores hacen a nivel mundial? (Frameworks).

Creo que el problema se reduce a una sola palabra, CULTURA (dejando a un lado la excusa del cronograma), el problema de las barreras culturales en software es evidente, no existe cultura para investigar y atreverse a mejorar (porque no es aprender, es mejorar) el desarrollo, no existe cultura para documentar lo que hemos hecho, no existe cultura para reutilizar.

Hace varios años trabajaba en una empresa donde un analista se jactaba de ser el mejor por haber hecho un pool de conexiones, pero realmente era el mejor? Mi respuesta es la siguiente, tal vez era el mejor escribiendo líneas de código, pero el mejor es aquel que tiene la capacidad de visionar cuando utilizar lo que ya se ha hecho antes, no perder tiempo (y aquí tumbo la excusa del cronograma) reinventando la rueda, y teniendo la capacidad de crear una aplicación que pueda servir como base para otras aplicaciones.

Aquí está el beneficio de una arquitectura basada en componentes, una arquitectura orientada a la reutilización, no solo basta con saber Java o UML, es tener una CULTURA que nos permita saber cuando reutilizar, cuando hacer componentes reutilizables, cuando usar un framework. ¿Que crees tú?

SERA EMPEZAR A ESCRIBIR.


Hoy he decidido seguir la "moda" (no se si es moda o necesidad) de escribir en un blog. Ya he escrito varios documentos en mi corto haber como ingeniero y "cuasi-arquitecto" y creo que puedo tomar el habito de escribir por el simple hecho de escribir. El blog no solo va a ser sobre desarrollo de software, sino sobre lo que puede pasar alrededor de una empresa de desarrollo. Espero que no me aburra.....