SG #30

Cómputo Ubicuo

Anonymous — Tue, 04 Jan 2011 18:43:17 +0000

Cómputo Ubicuo Anonymous Tue, 01/04/2011 - 12:43

Publicado en

SG #30

Columna invitada

Autor

Héctor Cuesta

“Una tecnología suficientemente avanzada, es indistinguible de la magia.”

Esta afirmación hecha por el brillante escritor de ciencia ficción Arthur C. Clark nunca ha sido más cierta que cuando nos enfrentamos con una tecnología embebida en nuestras labores cotidianas. La mejor forma de saber que estamos frente a computación ubicua es que las computadoras están integradas al ambiente de tal forma que nuestra interacción con estas sea casi invisible pero si perceptible, por esto también es llamada Inteligencia Ambiental.

“En el cómputo ubicuo se pasa de un usuario operador a uno que interactúa de forma natural.”

No importa como la llamemos, la computación ubicua está a nuestro alrededor y poco a poco ha ido generando ambientes amigables al usuario, el soporte eficiente y distribuido de servicios, el aumento del poder del usuario sobre su entorno, y el soporte para la interacción humana. Es un ambiente basado en un modelo de interacción en el cual los usuarios están rodeados de un entorno digital consiente de su presencia, sensible al contexto y que puede adaptarse a sus necesidades y hábitos, Además, el cómputo ubicuo es una visión que coloca al ser humano como centro de desarrollo futuro en la sociedad del conocimiento, la información y la tecnología. Estas tecnologías serán empotradas en dispositivos cotidianos y casi invisibles a aquellos que las utilizan, las interfaces serán sencillas y usables en un modo natural. Esta visión nos propone un distanciamiento de las computadoras de escritorio tradicionales hacia una amplia gama de dispositivos embebidos en nuestro entorno y que son accedidos desde interfaces inteligentes como RFID (tarjetas de identificación por radiofrecuencia), los dispositivos móviles (PDA’s, Celulares, etc.) con conexiones bluetooth, infrarrojo o wifi. Los siguientes son ejemplos de objetos inteligentes dentro de un entorno ubicuo:

Sintonización automática del canal de televisión más adecuado a la hora, día y grupo de miembros de la familia sentadas en el sillón en frente de la televisión.
Control de iluminación de un hogar u oficina acorde con las personas presentes, nivel de luminosidad o actividad en curso.
Apertura automática de puertas, llamada de ascensores y subida a los pisos correctos dependiendo de los usuarios presentes en el ascensor.
Transacciones económicas facilitadas por nuestros dispositivos o tarjetas inteligentes, entre ellos el próximo DNI digital.
Ofrecimiento de servicios en base a nuestra localización actual, por medio de nuestro teléfono móvil.

¿En realidad cómo se coordinan los dispositivos a nuestro alrededor para darnos la sensación de inteligencia ambiental?

La respuesta a esta pregunta no es trivial, ya que hay muchos aspectos y tecnologías involucradas. Sin embargo, dos tecnologías fundamentales para este paradigma es el Internet y los servicios web. El papel que juega el Internet en el cómputo ubicuo es primordial: la alta conectividad, la capacidad de interconectar sistemas y acceder a diferentes bases de datos. Los servicios web nos permiten acceder a todo esto de forma sencilla y estandarizada. Cualquier dispositivo con conectividad a Internet tiene el potencial de realizar peticiones a web services y de esta forma recibir o actualizar información.

Conclusión

En los próximos años, estaremos trabajando en aspectos tecnológicos y sociales que nos acerquen a la computación ubicua. En el aspecto tecnológico, debemos enfocarnos en el desarrollo de entornos y objetos inteligentes, así como en el Internet “de las cosas” y no solo “de los documentos”, donde damos un entendimiento semántico y no solo sintáctico. Por el lado social hay muchas críticas a esta tendencia, argumentando que es un riesgo a la privacidad. Ya se ha iniciado la creación y adopción de mecanismos, prácticas y legislación relacionadas con la gestión de la privacidad de la información en el mundo digital, pero sin duda es un área donde nos falta mucho por madurar.

Sin lugar a dudas, el cómputo ubicuo es el siguiente paso evolutivo en la computación, donde se pasa de un usuario operador a uno que interactúa de forma natural.

Referencias

A. Greenfield. Everyware: The Dawning Age of Ubiquitous Computing. New Riders Publishing, 2006.

Bio

Héctor Cuesta Arvizu es Lic. en Informática y actualmente cursa la maestría en ciencias de la computación en la UAEM Texcoco. Cuenta con seis años de experiencia desarrollando y administrando proyectos de software en el ámbito de manufactura y recursos humanos. Adicionalmente se desempeña como instructor de TI para Nyce en el area de base de datos e ingenieria de software. @hmcuesta

El Estado del Arte y la Prueba de Software

Anonymous — Tue, 04 Jan 2011 18:37:36 +0000

El Estado del Arte y la Prueba de Software Anonymous Tue, 01/04/2011 - 12:37

Publicado en

SG #30

Prueba de Software

Autor

Luis Vinicio León Carrillo

En el ámbito del desarrollo de software, el estado del arte (state of the art) típicamente ha estado vinculado con la evolución de los lenguajes de computación. Uno de los primeros grandes saltos en esa dirección fue el desarrollo del primer lenguaje de alto nivel, FORTRAN. En sus inicios, el desarrollo de software en ese lenguaje era considerado “programación automática” porque requería menos conocimientos técnicos que los lenguajes ensambladores. Los detractores (gurús que programaban en lenguaje ensamblador) solían justificar su rechazo mostrando que los programas en FORTRAN eran significativamente más ineficientes comparados con los que ellos escribían. Hoy no solo tenemos lenguajes de programación de alto nivel, de “cuarta” y de “quinta generación”, funcionales u orientados a objetos; también lenguajes de documentación (Latex, HTML, etc.), de especificación (bison, flex, etc.), y otros. Sin embargo, estos lenguajes hoy representan más bien lo que suele llamarse el “state of practice”: lo que incorporan las herramientas comerciales y que utiliza la industria.

Una de las vertientes del “state of the art” tiene que ver con lo que denominamos “métodos formales” (MF).

En términos generales, los MF son técnicas mediante las cuales:

Se escribe la especificación del sistema a desarrollar utilizando un lenguaje formal L1 (usualmente del paradigma declarativo), que luego es verificada con intervención humana y procesada mediante un compilador C1 para así generar el código en otro lenguaje formal L2 que representa un diseño de alto nivel.
Este diseño escrito en el lenguaje L2 a su vez es verificado con intervención humana y procesado mediante un compilador C2 que genera el código en otro lenguaje formal L3 (usualmente del paradigma imperativo).
Este código en el lenguaje L3 se procesa mediante un compilador C3 para obtener finalmente el sistema ejecutable.

Las verificaciones mencionadas suelen ser demostraciones matemáticas de que el código actual Cn tiene ciertas propiedades.

En realidad, en el desarrollo de software siempre utilizamosun tipo de MF, pues finalmente se escribe el sistema en algún lenguaje Lx, que es procesado por un compilador Cx, el cual usualmente genera código ejecutable. Sin embargo, esta transformación suele realizarse solamente para la fase final de las arriba descritas (la generación del sistema ejecutable a partir del programa escrito en un lenguaje de programación, usualmente imperativo), no para todo el ciclo de desarrollo (requerimientos-diseño-programación). Los MF abordan el ciclo completo. Algunos de los métodos formales más conocidos son el “Método B” y la “Notación Z”.

Ejemplo de un método formal

Muchos de ustedes, estimados lectores, habrán llevado algún curso de construcción de compiladores durante su carrera. Recordarán que un compilador contiene 4 grandes bloques:

El analizador léxico, que se encarga de concatenar caracteres significativos para construir “palabras”.
El analizador sintáctico, que verifica que esas “palabras” formen “oraciones” con un orden que es permitido.
El procesador semántico, que checa que esas “oraciones” tengan significado.
El generador de código, que finalmente transforma el programa escrito en el lenguaje fuente en otro documento escrito en el lenguaje destino.

Probablemente también recuerden que el analizador sintáctico o “parser” suele definirse mediante una gramática, usualmente utilizando alguna nomenclatura especializada como los grafos de sintaxis (GS). Hay un tipo de gramáticas (las descendentes predictivas) para las cuales es relativamente fácil la escritura del parser que las procesen, pero tienen ciertas restricciones; en particular:

la definición no puede tener recursión izquierda (el procesamiento se ciclaría indefinidamente),
en una alternación de grafos, no puede ocurrir que un par de ellos comience con la misma cadena (siempre tomaría la primer alternativa).

Las reglas para construir un parser descendente predictivo son relativamente sencillas y pueden ser automatizadas para generarlos en pseudocódigo; por razones de espacio, nos ahorraremos su definición aquí. Con esa automatización tendríamos un pequeño MF:
1. Escribiríamos la especificación del parser a desarrollar utilizando el lenguaje formal de los grafos de sintaxis, que sería verificada por un compilador de GS para detectar, entre otras cosas, recursión izquierda y/o alternaciones de GS no permitidas; en caso de haberlas, la especificación sería corregida con intervención humana. Una vez corregida y verificada, el compilador de GS podría generar el “diseño” del parser en pseudocódigo, como lenguaje intermedio.
2. Este “diseño” a su vez sería procesado mediante un compilador de pseudocódigo que generaría el programa P en algún lenguaje de alto nivel, a elección del usuario (v.gr. Java, LISP).
3. El programa P sería procesado por el compilador correspondiente y generaría el código ejecutable.

Utilizando el MF para desarrollar ese componente de un compilador, nuestra actividad se centra más en el diseño de una gramática que tenga características deseables, que en la escritura de un programa que la procese. Para lograrlo fue necesario conocer el lenguaje de especificación (los GS), y las características que deben tener las gramáticas (v.gr. no recursión izquierda). Ese es el enfoque usual en los MF.

Aplicación de los métodos formales en la industria
El uso de los MF en el desarrollo de sistemas críticos no es poco común. En el artículo “Software’s Chronic Crisis” [1] pueden encontrarse algunos casos clásicos, entre ellos el uso del método formal “B” para desarrollar un sistema que solucionaba el siguiente problema del metro en París:
La cantidad de usuarios de las líneas del metro se había incrementado considerablemente, de manera que era necesario construir más vías para que circularan más trenes, o bien automatizar la sincronización de las llegadas y salidas de las líneas a cada estación, de manera que se redujera el tiempo entre la partida de un convoy y la llegada de otro. Esta automatización es un buen ejemplo de un sistema crítico: si el software fallara al sincronizar llegadas y salidas, podría ocurrir que sobre la misma vía arribara un convoy en una dirección al tiempo que llegara otro en la dirección opuesta, ocasionando una colisión en la que podría morir mucha gente. Obviamente, ante esa posibilidad no es aceptable un sistema con digamos 99.99999% de confiabilidad (que puede fallar una vez en diez millones). En lugar de ello se utilizó el MF B para “desarrollar software libre de defectos por construcción”: se escribió una especificación formal que fue verificada matemáticamente, a partir de la cual se generó un diseño que fue igualmente verificado, para de ahí generarse el código fuente del que se obtuvo luego el sistema ejecutable.

Algunos mitos sobre los MF
Uno de los mitos de los MF es que son difíciles de aprender. En realidad, la dificultad para aprenderlos solamente radica en que son un tanto “diferentes” de lo usual, pero finalmente están basados en lenguajes formales, y los podemos aprender como aprendemos los de programación (finalmente, lo aprendimos también en nuestro curso de Compiladores). Otro mito más es que poca gente los conoce, y que no son enseñados en las universidades. Este, junto con el anterior, genera un círculo vicioso que se romperá cuando uno de ellos sea descartado. En buena medida gracias a estos prejuicios (y otros más), y a que no se tienen métodos formales genéricos e integrados, esta técnica no ha proliferado en proporción a su potencial. Sin embargo, cada vez más elementos de los incluidos en ellos se han venido introduciendo en muchos ambientes de programación.

Los métodos formales y la prueba de software
Este paradigma cambia tanto la actividad de la programación de sistemas, como la de la prueba de los mismos: el desarrollo tiene que ver menos con escribir código e incluye más tareas de verificación (detección de errores “de alto nivel”), que actualmente se incluyen en las actividades de pruebas. En ese sentido, ambas actividades parecieran confluir. Sin embargo, aún en ese escenario, será necesario probar para revisar por un lado si el sistema desarrollado cumple con los requerimientos del usuario (aspecto que no puede validar el método formal), y por otro si no se cometieron errores durante las verificaciones. Además, hoy en día tenemos tecnologías que interactúan cada vez más con otras, y la integración de sistemas de sistemas es algo que también debe ser probado. Las pruebas serían pues también necesarias, aunque con variaciones significativas.

Referencias

W. Gibbs; “Software’s Chronic Crisis”, Scientific American, September 1994. http://bit.ly/sg30r1

Bio

Luis Vinicio León Carrillo es actualmente Director General de e- Quallity, empresa especializada en prueba de software, de la que es co-fundador. Fue profesor-investigador en el ITESO durante varios lustros, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de esa disciplina. Fue co-fundador del Capítulo Jalisco de la AMCIS.

Los Muchos Significados del "Cómputo en la Nube"

Anonymous — Tue, 04 Jan 2011 18:26:18 +0000

Los Muchos Significados del "Cómputo en la Nube" Anonymous Tue, 01/04/2011 - 12:26

Publicado en

SG #30

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Uno de los términos ampliamente en boga en nuestro campo hoy en día es el “cómputo en la nube”. Tan en boga que me parece que se ha convertido en una palabra mágica, bastante hueca y sintomática de querer parecer en sintonía con los últimos desarrollos tecnológicos, sin comprenderlos en realidad. Además, al ser una frase que de golpe comenzó a escucharse con tanta insistencia, asumimos que es una estrategia nueva, una idea posibilitada por los nuevos avances tecnológicos — Y esto dista de ser el caso. En esta columna busco clarificar los conceptos y tipos básicos de cómputo en la nube, sus principales ventjas y desventajas, y brevemente encontrar paralelos con casos documentados de estos ”novedosos” conceptos.

No critico, ojo, a las estrategias que están detrás de este sonoro término — Muy por el contrario, resultan muy convenientes a la hora de implementar, y como profesionales del desarrollo de software tenemos la obligación de estar familiarizados con ellas. Lo que critico es el abuso de un término ambíguo, que suele poner en problemas a los implementadores, al no estar claramente comprendido.

La mayor parte de las referencias que consulté mencionan a tres capas o niveles principales: El software –o la aplicación– como un servicio (Software as a Service, SaaS), la plataforma como un servicio (Platform as a Service, PaaS) y la infraestructura o el hardware como un servicio (Infrastructure as a Service, IaaS). Mi punto de vista, es que más que un nivel distinto, IaaS es un conjunto de cualidades adicionales que dan valor agregado a una oferta de PaaS.

SaaS: Bloques de construcción

Cuando uno de nuestros sistemas utiliza un API público remoto, o cuando para nuestro flujo de trabajo empleamos a una aplicación que reside y es administrada fuera de nuestra organización, estamos empleando SaaS. Nuestro proveedor puede cobrar su servicio de diversas maneras: a través de una renta directa, requiriendo del despliegue de publicidad, recibiendo autorización para recolectar nuestra información y hacer minería de datos sobre de ella — Hay una enorme variedad de esquemas, que refleja la gran variedad de niveles de integración que se puede dar a los servicios.

Notarán que la principal diferencia con los esquemas tradicionales cliente-servidor con que hemos trabajado desde hace décadas es el uso explícito de un proveedor externo — Sin embargo, técnicamente, nuestros sistemas no seguirán una lógica o un proceso de desarrollo diferente de como lo vienen haciendo por décadas. Al mismo tiempo, sí hay una importante diferencia: Al no controlar nosotros el proceso que ocurre dentro de uno de nuestros subsistemas, nos vemos forzados a hacer bien lo que ya deberíamos estar haciendo: Implementar una separación limpia de responsabilidades entre los componentes, utilizando exclusivamente las interfaces publicadas explícitamente — No brincarnos las capas de abstracción, como muchas veces estaríamos tentados a hacerlo en un desarrollo interno.

Hay algo que no podemos perder de vista cuando empleamos un servicio de aplicaciones como parte de nuestra infraestructura en sistemas: Al depender de un tercero, ponemos en sus manos parte importante de nuestras promesas (y, por tanto, requerimientos), en tanto a disponibilidad, protección de datos y continuidad de la operación. Respecto a la disponibilidad, resulta natural que una falla en el servicio de cualquiera de nuestros proveedores de aplicaciones llevará a que nuestro sistema presente información incompleta o errónea a sus usuarios. En cuanto a la proteción de datos, no sólo debemos tener en cuenta las implicaciones directas (el proveedor tendrá acceso a todos los datos específicos que le enviemos para operar), sino también las indirectas: todo ataque por medio del cual un agente hostil pueda llevar a cabo recolección de información sobre de nuestros proveedores resultará en la probable divulgación de información interna nuestra, e incluso el mismo proveedor puede estar realizando un seguimiento estadístico de nuestros patrones de uso, revelando mucho más de lo que podríamos querer darle. En tanto a la continuidad de operación, si el proveedor del servicio decide cambiar los términos bajo los cuales brinda sus recursos, o si sencillamente deja de operar, podemos quedar sin una alternativa disponible para parte importante de nuestro flujo de trabajo. Como corolario de la dependencia de terceros, al depender de aplicaciones como servicio perdemos la capacidad de planear las actualizaciones de nuestra infraestructura — Al depender de proveedores externos, en el momento en que cualquiera de sus APIs cambia, nos vemos forzados a actualizar de inmediato. Nuestros servicios en producción pueden fallar, y el mero concepto de “rama estable” pierde buena parte de su atractivo [1].

PaaS+IaaS: Flexibilidad en el uso de recursos

Mientras que en el apartado anterior partíamos de que –desde el punto de vista del usuario– hay una aplicación central que corre en sus instalaciones y consume procesamiento realizado por componentes distribuídos por el mundo (”en la nube”), aquí la aplicación completa será desplegada en el proveedor de servicios. El usuario deja de emplear un servidor –o una granja de servidores– para consumir sólo los recursos. Y, consecuentemente, el esquema de utilidad para un proveedor de servicios bajo esta modalidad puede ir desde la renta a costo fijo hasta un cobro por uso de recursos, típicamente permitiendo reconfiguraciones dinámicas del paquete (del conjunto máximo de recursos) como respuesta a la demanda del sistema.

La justificación detrás de este concepto es que los servidores ”en casa” representan un gasto demasiado grande — Compra y actualización periódica de equipo, consumo eléctrico, uso de espacio físico y de ancho de banda, siendo que las instalaciones de la mayor parte de los usuarios no cuentan siquiera con un centro de datos. Además, todo servidor debe ser adquirido contemplando la carga estimada que sostendrá, pero contemplando un espacio para sobreconsumo en picos de actividad no planificable. En cambio, un proveedor masivo de servicios balancea el exceso de demanda de un usuario con la reducción de demanda de otro, permitiendo un menor sobredimensionamiento — Y una reducción neta de precios.

Nuevamente, apreciarán que la idea no es nueva — Los proveedores de presencia o de hosting existen desde hace muchos años en Internet. Más allá aún, precisamente este esquema fue planteado a mediados de los 1960, cuando fue desarrollado el sistema MULTICS [2]. La principal diferencia con el esquema tradicional de renta de servidores es que bajo este esquema, el usuario deja de ser responsable de la administración incluso del servidor en el que se ejecutarán sus aplicaciones; el proveedor de servicios ofrece una cartera de plataformas administradas. Las plataformas pueden ser desde aplicaciones medianamente complejas, como plataformas Web que llevan un grado no trivial de configuración y representan una solución completa e integrada, hasta marcos para el desarrollo de sistemas (como Rails, Struts, Django, GWT), para los cuales los clientes sólo proveen el código específico de su aplicación, y aprovechan todo el andamiaje común que ya existe para una amplia base de clientes.

Respecto a consideraciones de seguridad y confiabilidad: Si bien al emplear PaaS no caemos ya en la trampa descrita en el primer apartado respecto a emplear código del cual no tenemos más conocimiento que el API, éste esquema sigue depositando todos nuestros datos en control del proveedor, en infraestructura compartida, con lo cual la probabilidad de que un ataque a un sistema sin relación aparente con el nuestro puede dar a un intruso acceso pleno a nuestra información. El riesgo de que el proveedor cambie sus políticas de cobro a un esquema que no nos convenga se reduce también fuertemente, dado que en principio tenemos todo lo necesario para replicar la instalación con cualquier otro proveedor, o incluso migrar a una solución ”en casa”. Sin embargo, seguiremos sujetos a los “días bandera” de actualización forzada, dado que el proveedor típicamente ofrecerá la misma versión base a todos sus clientes — Y este factor puede dificultarnos una migración entre proveedores. Hablando meramente de la conveniencia: Podemos enviar a uno de nuestros sistemas a la nube dados sus requisitos de almacenamiento de información, o de ancho de banda. Ahora bien, ¿cómo estamos realizando nuestros respaldos? Para poder hacer frente a contingencias, contar con una estrategia de respaldos buena y probada es mucho más importante aún que cuando hablamos de despliegues en infraestructura propia.

Por último, respecto al IaaS: Este resulta el más nebuloso y ambiguo — Ya no se trata de sistemas o entornos para que éstos se ejecuten, sino que de recursos de cómputo que están a nuestra disposición: Espacio en disco o en memoria, ”ticks” de procesador, ajuste de ancho de banda, como componentes discretos y ajustables en vivo — Atributos que se apoyan fuertemente en la virtualización para poder ser desplegados y controlados. Hay quien incluye la virtualización de escritorios dentro de la definición de IaaS, pero si mucho, eso debe ser visto como consolidación de recursos y mejoría en el aprovechamiento de recursos, pero por calidad en el servicio debe hacerse utilizando recursos internos a la organización — Y por tanto, se aleja de las definiciones básicas de en la nube.

Llevamos años haciendo cómputo en la nube de un tipo o de otro. Al desmitificarlo un poco, espero abonar a una mejor utilización. Y al hablar acerca de los nada ignorables riesgos que conlleva, apunto a la cautela que debemos tener al adoptarlo, no entrar de lleno sólo porque es la moda.

Notas

Un ejemplo de esto se dio en agosto de este año cuando Twitter cambió su esquema de autenticación, obligando a miles de aplicaciones a migrar su código al nuevo esquema.
El sistema operativo MULTICS partía del planteamiento de que el cómputo se convertiría en un servicio provisto centralmente, como la electricidad o el teléfono. http://www.multicians.org

Bio

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. www.gwolf.org

Infraestructura: Redes Inalámbricas

Anonymous — Tue, 04 Jan 2011 18:07:00 +0000

Infraestructura: Redes Inalámbricas Anonymous Tue, 01/04/2011 - 12:07

Publicado en

SG #30

Infraestructura

Autor

Tino Rodríguez

Sin lugar a dudas, la computación en la nube (cloud computing) y las nuevas tendencias en comunicaciones, como la videoconferencia, las comunicaciones unificadas o las aplicaciones de colaboración, representan oportunidades para el sector corporativo, tanto grandes corporaciones como pequeñas y medianas empresas. Correctamente implementados, estos recursos aportan un avance importante en la productividad de los trabajadores y las empresas. Tanto las aplicaciones de computación en la nube como las nuevas herramientas de comunicación están teniendo un auge importante en el presente.

De manera paralela están surgiendo, cada vez con mayor velocidad, nuevos equipos que rápidamente encuentran su lugar en la vida empresarial. No hace mucho tiempo aparecieron las netbooks, y ahora se encuentran en pleno apogeo las tabletas (tablets) y los smartphones. A la vez, continúan desembarcando en las empresas equipos tradicionales como notebooks, desktop y teléfonos WiFi, entre otros.

Tanto las aplicaciones como los nuevos dispositivos conectados enriquecen el trabajo en las empresas. Pero, ¿qué sucede con la red que debe soportar todos estos equipos y la multiplicación del tráfico? No solo está aumentando la cantidad de equipos conectados a nuestras redes, sino la cantidad de datos que cada uno transmite o recibe. Es así que los departamentos de infraestructura de TI requieren cada vez más agilidad para dar respuesta a la demanda de conectividad de sus clientes internos.

Afortunadamente hay nuevas tecnologías también en este campo. La maduración del estándar 802.11n, que ofrece capacidades de transmisión de hasta 600 Mbps, está impulsando las ventas del equipamiento de red, lo que muestra claramente que los departamentos de IT de las empresas están conscientes de la necesidad de aumentar la capacidad de transmisión de su infraestructura.

Aunque 802.11n permite una mayor capacidad de transmisión en los nodos de nuestra red, esto de nada sirve esto si no se acompaña de un adecuado planeamiento de la red. El problema que enfrentamos es que la mayoría de las redes inalámbricas existentes son de tipo “estrella”, con un controlador central que administra aspectos como la seguridad de la red, la calidad de servicio (Quality of Service, QoS) y el tráfico de datos. Al añadir mayor capacidad de transmisión en los nodos, se aumenta exponencialmente el tráfico dirigido hacia el controlador central, lo que puede ocasionar congestionamientos en esta instancia de la red y ocasionar deficiencias en el servicio y pérdidas en la transmisión de datos.

Ante esta problemática, los fabricantes de equipo de infraestructura de redes ya están buscando soluciones. La mayoría de los proveedores están optando por la incorporación de más equipamiento a la infraestructura, para soportar mayores cantidades de tráfico de forma central. Por su parte, Motorola ha desarrollado recientemente una nueva tecnología para la gestión de redes inalámbricas denominada WiNG 5, que permite a los nodos de una red comunicarse directamente entre sí, sin necesidad de pasar por el controlador central, lo que reduce sustancialmente el tráfico que éste debe administrar, ayudando a aliviar posibles congestionamientos. Esta innovación permite establecer rutas inteligentes para el tráfico de la red, potenciar su capacidad y aumentar la velocidad de transmisión. A la vez, la calidad de servicio y la seguridad se gestionan desde cada punto de acceso, lo que permite la administración de estos aspectos en el “borde” de la red.

Con el desembarco de nuevos dispositivos y la proliferación de aplicaciones que demandan cada vez más capacidad de transmisión, la gestión del tráfico será sin dudas un punto importante en la agenda de los departamentos de IT de todas las organizaciones. Los responsables de tecnología deben comenzar a buscar soluciones que les ofrezcan la agilidad necesaria para responder a la demanda creciente del tráfico de red, la infraestructura tecnológica clave que está por detrás de los procesos de negocios.

Bio

Tino Rodríguez es Gerente de Productos de Redes Inalámbricas para Latinoamérica en Motorola Solutions.

Valores y Capacitación

Anonymous — Tue, 04 Jan 2011 17:33:52 +0000

Valores y Capacitación Anonymous Tue, 01/04/2011 - 11:33

Publicado en

SG #30

Mejora continua

Autor

Luis Cuellar

Fin de año, tiempo para la reflexión. Este fin de año en particular he estado trabajando mucho en la definición de diferenciadores de negocio, ¿qué hace que una compañía sea mejor que otra?, ¿cómo podemos diferenciar nuestro servicio al de nuestra competencia?

Después de varios diálogos con compañeros y amigos, me inclino a pensar que una empresa de servicios sólo tiene dos posibles diferenciadores:

Los valores que guían los servicios que ofrecen.
El conocimiento que define qué tan bien los integrantes de la compañía saben ejecutar los servicios que ofrecen.

Me llama la atención que la mayoría de las industrias de servicio tienen esto perfectamente claro. La mayoría de ellos trabajan fuertemente para establecer los valores con los cuales se rigen y la institucionalización de su entrenamiento.

¿Quién no ha escuchado sobre los valores de servicio al cliente, comodidad y confianza de la industria hotelera, así como la fuerte cantidad de capacitación que se requiere para servir una taza de café en Starbucks o una hamburguesa en McDonald’s?

En la industria de software en México apenas estamos entendiendo estos principios. Normalmente nos enfocamos mucho en la visión y misión de la organización, ¿dónde nos vemos en 10 o 15 años?, pero, ¿qué tan claro están los principios que debemos seguir durante este tiempo?.
Honradez, confianza o apego a las necesidades del cliente, como ejemplos. Adicionalmente, ¿cómo estos principios deben de ser aplicados en nuestro día con día? ¿apego al cliente significa que haremos cualquier cosa que el cliente pida sin decir nada?, ¿o quiere decir que es parte de nuestra responsabilidad ayudar al cliente a hacer las cosas en forma más eficiente? Estas ideas son la base de las acciones y decisiones de la organización y es de suma importancia tomarlas en serio.

El otro punto es el entrenamiento y crecimiento de nuestra gente. El grueso de la industria de software en México consiste de PyMEs, las cuales normalmente no tienen capital para mantener una cantidad significativa de empleados en la banca con la expectativa de que caerá un proyecto grande, por lo que cuando esto sucede salen al mercado a contratar personas para incorporarlas a los proyectos. Pero cuando todas las organizaciones se basan en traer gente de fuera, ¿cuál es entonces el diferenciador?, ¿qué hace que una compañía sea mejor que otra?

Para resolver este dilema algunas compañías se basan en la especialización, esto es especialistas en una tecnología o un producto en particular, las cuales, cuando se requiere, pueden crecer rápidamente debido a que tienen suficiente gente que conoce la tecnología como para enseñar o controlar a la gente que se incorpora. Esto por supuesto funciona siempre y cuando el crecimiento no sea demasiado acelerado. En un siguiente nivel se encuentra la idea de definir los procesos con los que vamos a trabajar, estos procesos no son más que un acuerdo sobre cómo manejaremos los principales problemas con los que nos topamos y cómo deberían manejarse en un futuro. Estos procesos nos facilitan el incorporar a la gente en nuestra organización permitiendo traspasar rápidamente el aprendizaje de un grupo al nuevo grupo que se incorpora, los procesos son un excelente punto para incorporar el conocimiento de la organización y las mejores prácticas de la misma. Obviamente los procesos tienen sus limitantes, el tenerlos escritos no asegura que cualquier persona puede simplemente leerlos, entenderlos y cambiar su comportamiento. Este punto nos lleva al siguiente y último nivel de crecimiento el cual está enfocado a una estructura madura de entrenamiento dentro de la organización y qué tan rápida, completa y eficiente es para lograr los objetivos de crecimiento del personal.

Una de las principales limitaciones de la capacitación y entrenamiento en la industria de software, es que en muchas ocasiones prevalece la idea de que capacitar es estar en un salón de clases con un instructor que les platica a nuestros empleados sobre las tecnologías del futuro y modelos interesantes que no se llevan a cabo en la práctica. A partir de ahí, la persona sale con mayor madurez y con nuevas ideas para tomar mejores decisiones en la organización. La realidad es que las tendencias de capacitación a nivel mundial han cambiado radicalmente, es de vital importancia un objetivo claro para un plan de capacitación el cual debe de enfocarse principalmente en asegurar que los individuos saben operar y tienen las habilidades necesarias para ejecutar correctamente y en forma eficiente los procesos que conllevan sus roles y los procesos necesarios para mejorar continuamente el trabajo que están haciendo.

Las únicas restricciones reales de un plan de capacitación son: a) que el proceso sea repetible a través del tiempo, b) que se pueda evaluar su avance, c) que exista una forma clara de medir su éxito. En otra palabras, manejar un curso en un salón de clases es entrenamiento pero también lo es hacer una estructura virtual a través de cursos pre-grabados, también podría utilizarse diferentes medios de comunicación como son vídeos, escritos y programas de audio, o grupos de apoyo a través de redes sociales. El “aprendizaje mientras trabajas” (on-the-job learning) funciona siempre y cuando esté claro lo que se debe aprender, tengamos una forma de medir qué se enseñó y cuándo, y podamos evaluar qué tan bien funciona esta capacitación. Si hacemos una búsqueda sobre tecnología de entrenamiento podemos encontrar capacitación virtual con objetivos sencillos hasta doctorados y especialidades, modelos de coaching para generar habilidades de dirección, simulaciones y juegos que enseñan desde tácticas de planeación hasta conocimiento sobre negociación en situaciones de liberación de rehenes. Todos estos son modelos de capacitación que pueden ayudar a nuestra compañía a adquirir en forma rápida el conocimiento que nos diferencie de la competencia.

La capacidad para crecer de una organización depende en gran medida en su modelo de capacitación y entrenamiento. Conozco compañías de outsourcing de software en el extranjero en donde los tres accionistas principales son el presidente de la compañía, el director de operaciones, y el director de entrenamiento. Este foco en cómo hacemos que nuestra gente crezca lo más rápido posible, diferencia a una compañía que puede entregar lo que promete de una compañía que no. Estoy convencido que si queremos desarrollar la industria de software en México, el mayor retorno en inversión se encuentra en afianzar nuestros valores como compañías y asegurar que enfocamos nuestros esfuerzos de innovación en tecnología de entrenamiento. En la era del conocimiento lo único que diferencia una compañía mediocre y una compañía excelente son sus valores y qué tan bien sabemos aplicarlos. ¡Mucho éxito para el 2011!

Bio

Luis R. Cuellar (@lcuellar) es director de calidad a nivel mundial de Softtek. Es reconocido por la ASQ como Certified Quality Manager, Certified Sofware Engineer y Six Sigma Black Belt.

Análisis de Distintos Contextos de Prueba

Anonymous — Tue, 04 Jan 2011 17:30:42 +0000

Análisis de Distintos Contextos de Prueba Anonymous Tue, 01/04/2011 - 11:30

Publicado en

SG #30

Testing

Autor

Juan Gabardini

Es tentador pensar que siempre hay una “mejor manera” de hacer las cosas. Alguna vez pensé conocer “la mejor manera” de probar software. Luego aprendí o cambié de contexto, y “la mejor manera” cambió. A partir de entonces soy algo escéptico cuando me encuentro con una “mejor manera”. Esta nueva “mejor manera”, ¿que problemas viejos resuelve? ¿que problemas nuevos crea? ¿en qué contexto está siendo usada?

En este artículo comparto mi experiencia personal con diferentes formas y contextos de prueba, analizando los problemas comunes y cultura, y también si ese contexto es un estado final o sólo un paso hacia otro estado. Este texto se basa en la presentación que realicé en el congreso Ágiles 2010 en Lima, que pueden ver en http://bit.ly/b9bIrT

Aclaro que no trato el problema más general de la calidad de software, sino solamente sobre la prueba.

El modelo

La estructura de este artículo está organizada en base al modelo de prueba comentado en el libro “Agile testing”, de Lisa Crispin y Janet Gregory (ver figura 1). En este modelo, tenemos 4 tipos de prueba:

• Pruebas manuales.

• Pruebas de interfase usuaria o UI (automatizada).

• Pruebas de aceptación (automatizada).

• Pruebas técnicas o unitarias y de componentes (automatizada).

El costo de ejecución es menor en las pruebas técnicas y va creciendo hasta el máximo costo, que es la ejecución de pruebas manuales. El costo de mantenimiento de las pruebas automáticas también es creciente, desde el mínimo en las pruebas técnicas, hasta el máximo en las pruebas de UI. El mantenimiento de las pruebas manuales es equivalente o menor que el caso de pruebas técnicas automatizadas. En todos los casos, el costo y mantenimiento de las pruebas automatizadas requiere una inversión importante en experiencia e infraestructura. Pero esa inversión se puede llevar en muchos casos de un proyecto a otro. Los costos consideran esa inversión amortizada o distribuida en gran cantidad de pruebas.

La relación entre los costos lleva a sugerir que la forma más eficiente de dedicar esfuerzo tiene la forma de una pirámide, con las pruebas técnicas (unitarias y de componentes) en la base, las de aceptación (o API) luego, y finalmente las pruebas de UI en el vértice de la pirámide.

Contexto: Prueba ad-hoc

Durante los primeros años de mi carrera trabajé en grupos de 5 personas o menos, realizando desarrollos a la medida para áreas muy distintas.

En estos equipos no había clara separación de roles, todos hacíamos un poco de todo. En particular, las pruebas las hacíamos entre todos, intercambiábamos roles probando la funcionalidad realizada por otro. La prueba final la hacían los jefes, usuarios o, si existían, las personas de servicio a cliente.

Al no haber responsables claros, la prueba suele quedar huérfana, sin mejora. Aparecen problemas con las tareas poco atractivas y complejas, como realizar pruebas de regresión.

La evolución de este contexto suele ser incorporar un tester o área de testing para prueba manual (camino tradicional) o que los programadores empiecen a desarrollar pruebas técnicas o incluso test driven development (camino del desarrollo ágil).

Motto: ¡No vale la pena probar!

Problemas: Baja calidad, baja previsibilidad, regresiones

Cobertura: No hay métricas

Responsable: Todos y ninguno. Pruebas por el usuario

Organización: Generalmente chicas y con poca estructura

Contexto: Prueba manual

En mi siguiente reencarnación estuve 8 años en una compañía que se dedicaba a ayudar a empresas de contexto Ad hoc a madurar su práctica de prueba. Este cambio cultural es difícil, y con riesgo de involuciones. Por eso se busca separar en un grupo más o menos autónomo a los responsables de probar. La separación y la función de probar, que a veces se desvirtúa como prueba de programador en vez de prueba del producto, provoca enfrentamientos y fricciones con los programadores.

El diseño de las pruebas es divertido, pero ejecutarlas una y otra vez es terriblemente aburrido, lo que lleva a que pocas personas quieran quedarse mucho tiempo haciendo esto. Resultado: muchas personas capaces se van a otras áreas, más divertidas (como desarrollo), lo que produce mucho recambio y mayoría de novatos en los roles de prueba.

El problema es que la prueba de regresión de productos medianos y grandes, se hace muy costosa, lo que lleva a ciclos de desarrollo muy largos (para minimizar las pruebas de regresión) o disminución de las pruebas realizadas durante la regresión (lo que lleva a baja calidad).

La solución sería la automatización, pero no es sencilla, ya que las personas en el grupo de prueba no tienen conocimientos técnicos, y la relación con el grupo de programación, que puede aportar el conocimiento técnico, no es la mejor.

Motto: ¡No vale la pena automatizar las pruebas!

Problemas: Costo de ejecución, que a su vez lleva a seleccionar las pruebas, que baja la confianza y lleva a pocos releases

Cobertura: Requerimientos, casos de uso

Responsable: Testers / QA

Organización: Testing separado

Prácticas: Casos de prueba manuales, checklist

Contexto: Prueba manual optimizada

Luego de 6 años en prueba manual reencarné en prueba manual optimizada, porque un cliente exigió en un proyecto que automatizaramos.

Con gran esfuerzo se mantiene un conjunto de pruebas automatizadas, que permiten tener regresiones en forma rápida. El ahorro en tiempo y esfuerzo es grande, pero por otro lado, debido a la separación entre los grupos de programación y los de prueba, es frecuente que cambios realizados en forma inconsulta en el producto rompan las pruebas automatizadas. Por eso, y por el hecho de que estas pruebas suelen ser de caja negra a través de la UI, el costo de mantenimiento de las pruebas automatizadas es alto.

Es una situación extraña, ya que en muchos casos nos damos cuenta que se podría ser mucho más eficiente si algunas pruebas se hicieran por caja blanca, por los programadores, o si los testers pudieran participar en la toma de decisiones sobre cambios al producto.

Motto: No podemos mejorar la producción del código.

Problemas: Mantenimiento de las pruebas

Cobertura: Requerimientos, riesgos

Responsable: Testers, Testers automatizadores, QA

Organización: Organizaciones grandes, grupos separados

Prácticas: Pruebas automatizadas de UI

Contexto: Prueba técnica

Algunos equipos en los que trabajé tenían la cultura de calidad incorporada con fuerte influencia de XP, por ejemplo con prácticas de integración continua, TDD y pair programming incorporadas (en mayor o menor medida).

En estos equipos la calidad es alta comparada con los contextos de prueba manual. Se suele utilizar cobertura de código como métrica relevante. Los problemas que suelen presentarse son el mantener el tiempo total de ejecución de las pruebas bajo (<10 min), y que nuestro producto pase todas las pruebas (en este contexto, significa pruebas unitarias automatizadas), pero no es aceptado por el usuario. Las funcionalidades requieren siempre al menos dos iteraciones para ser aprobadas y el grupo se desmotiva por los cambios de UI y de requerimientos que parecen llegar siempre tarde, y siempre hay uno más.

Motto: Sólo vale la pena las pruebas automatizadas

Problemas: Usabilidad y regresiones en cuanto a requerimientos

Cobertura: Líneas de código

Responsable: Programador.

Organización: Equipo de programadores

Prácticas: TDD (Test Driven Development),

CI (Continuous Integration)

Contexto: Prueba técnica++

Los equipos en este contexto son equipos que vienen de la prueba técnica (agregando prueba de APIs y quizás de UI) o de la prueba manual optimizada (agregando prueba unitaria y quizás de API). En ambos casos, tienen desbalanceada la pirámide de prueba. En el caso de los que vienen desde prueba manual optimizada, puede ocurrir que pierdan la prueba manual o la prueba de UI automatizada, dado que el esfuerzo por incorporar pruebas unitarias es grande, y se detecta duplicación de esfuerzo entre las pruebas existentes (manuales o automáticas a nivel UI).

Luego de lograr el balance en la pruebas automatizadas, el problema remanente son las pruebas de difícil automatización y la falta de prueba exploratoria. Esto último puede llevar a productos que son correctos desde el punto de vista funcional, pero que no son sobresalientes.

Motto: Sólo valen la pena las pruebas automatizadas

Problemas: Usabilidad, requerimientos no funcionales

Cobertura: Líneas de código y requerimientos

Responsable: Usuario y programador

Organización: Equipo de programadores

Prácticas: ATDD (Acceptance Test Driven Development), BDD

(Behavior Driven Development), TDD, CI

Contexto: Nirvana

Estos equipos han incorporado todas las prácticas de XP. Están en continuo aprendizaje sobre como complementar los distintos tipos de pruebas, la automatización a diferentes niveles y la exploración, para lograr la combinación óptima. Están en un equilibrio dinámico, siempre cambiante, atentos a cambios en el negocio, el producto y las tecnologías. Se preocupan por la cadena de valor completa.

Motto: Optimizamos el todo

Problemas: Buscar el balance óptimo

Cobertura: Líneas de código y requerimientos, riesgos

Responsable: Equipo completo (whole team)

Organización: Lean

Prácticas: ATDD, BDD, TDD, CI

Re-visitando

Las descripciones dadas en cada contexto plantean la visión que tenía de lo ‘correcto’ cuando estuve en ellos. Mirando ahora hacia atrás, tengo una visión distinta. Comparto mis reflexiones:

Ad hoc. ¿Qué pasa cuando la solución implica poco o nada de programación en el sentido estricto, sino más bien configurar soluciones existentes o crear contenido? En algunas situaciones, la prueba Ad hoc podría ser lo mejor: ej. desarrollo de sitios sencillos usando un CMS.

Prueba Manual y Prueba Manual Optimizada. Cuando hay en juego mucho dinero o vidas, queremos redundancia. Podemos pagar prubas manuales para lograr independencia (dos grupos, con dos técnicas distintas). Por otra parte, hay que recordar que el producto a probar no es sólo software: puede ser factible automatizar parte de la prueba (correspondiente al software) y realizar el resto en forma manual, por ejemplo: CMS complejos, en los que no solo se desarrolla contenido, sino también extensiones o aplicaciones; productos en los que el software acompaña al texto, y probablemente el texto sea lo más importante, como tutoriales; soluciones que incluyan actividades manuales realizadas por humanos.

Conclusiones

Las metodologías ágiles han logrado una mejora muy importante en la calidad lograda en los desarrollos. Es tentador aplicar siempre las técnicas y prácticas que han permitido estas mejoras, y es tentador pensar que nuestros problemas se resuelven con más y mejor aplicación de las mismas. Por otro lado, he hecho críticas a algunas prácticas (como el (ab)uso de métricas de cobertura de código), para luego encontrar que personas a las que respeto encuentran estas críticas inconvenientes.

Estos contextos me han ayudado a aclarar las discusiones sobre la conveniencia de la utilización o no de las distintas prácticas. Espero que pueda ayudar a otros. ¿Tú que opinas?

Figura 1. Distintos tipos de prueba.

Bio

Juan Gabardini participa en equipos como tester y ayudando a incorporar el desarrollo ágil de software. Participa también en la organización de los eventos latinoamericanos Ágiles 20xx y Agile Open Tour. Es Ingeniero Electrónico egresado de FIUBA, miembro del IEEE, SADIO, Scrum Alliance, Agile Alliance, Agilar Argentina y Jefe de Trabajos Prácticos en FIUBA. Cuenta con más de 10 años de docencia universitaria y más de 20 años de experiencia en desarrollo de software, enseñanza y consultoría.

Desarrollo Global de Software

Anonymous — Tue, 04 Jan 2011 16:51:03 +0000

Desarrollo Global de Software Anonymous Tue, 01/04/2011 - 10:51

Publicado en

SG #30

Tejiendo nuestra red

Autor

Hanna Oktaba

El desarrollo global de software, conocido también como desarrollo y entrega global, no es un concepto nuevo. El primer libro bajo este título fue publicado en 1998 [1]. La definición simple de lo que es el Desarrollo Global de Software habla de desarrollo entre varios equipos en localidades distribuidas geográficamente. Los equipos pueden ser de la misma organización o pertenecer a distintas organizaciones. La distribución geográfica puede variar desde distintos edificios de la misma ciudad hasta diferentes continentes.

La motivación inicial de este tipo de desarrollo fue abaratarlos costos de mano de obra. La India fue el primer país en la mira y lo supo aprovechar muy bien. Pero hoy en día esta práctica se ha popularizado entre múltiples actores y también puede tener otro tipo de motivaciones, como por ejemplo:

Desarrollo de sistemas complejos, que requieren de equipos con distintas especializaciones.
Desarrollo 24 hrs, que aproveche diferencias de horarios.
Estar más cerca del cliente o del mercado.

Retos

El desarrollo global de software es una fuente de nuevos retos para la Ingeniería de Software. Algunos de los más importantes son los siguientes [2]:

Procesos. Los modelos de procesos que tenemos disponibles están diseñados para una sola organización y, a lo más incluyen a los subcontratados, pero no tenemos procesos para organizar la colaboración y coordinación entre varias organizaciones para un proyecto común. Hoy en día esta falta significa, según algunas fuentes, la disminución de productividad hasta en 50%.

Comunicación. Si de por sí la comunicación es difícil dentro de un solo equipo y con un solo cliente, este problema se multiplica en caso de equipos distribuidos geográficamente. La comunicación incompleta da lugar a malos entendidos, omisiones, errores y, en consecuencia, re-trabajo.

Cuestiones culturales. Las barreras del idioma, las diferencias en formas de pensar y expresarse, así como diferentes costumbres y formas de trabajar pueden afectar a las relaciones entre equipos, disminuir confianza, y por lo tanto, ser causante de retrasos.

Coordinación del trabajo. Distribuir las tareas entre varios sitios y zonas horarias es mucho más complejo que hacerlo para un proyecto de un solo sitio. En efecto, el costo de la coordinación es mayor y los resultados en vez de ser más rápidos se obtienen con retraso.

Visibilidad y control. En proyectos tradicionales en un solo sitio, es viable transmitir de forma oportuna a todos los participantes el conocimiento sobre la estructura del proyecto, roles y sus responsabilidades, asignación de las actividades de desarrollo, así como el estatus global del avance del proyecto. Sin embargo, transmitirlo oportunamente a distintos sitios geográficamente distribuidos puede ser difícil, especialmente cuando se colabora con otras empresas o con equipos en distintas zonas horarias.

Métricas del proyecto. La recolección de datos para mediciones establecidas para un proyecto de desarrollo global de software puede no ser tan fácil. Las diferencias en procesos o infraestructuras heterogéneas pueden ser causantes de datos poco coherentes y, en consecuencia, harán difícil la evaluación cuantitativa del éxito del proyecto.

Cuestiones políticas. Tanto dentro de las organizaciones, que, por ejemplo, temen perder trabajo o resienten la competencia de sitios remotos, como en países o regiones, se pueden dar situaciones que conduzcan a agendas ocultas u objetivos contradictorios.

Protección de propiedad intelectual. Es una preocupación muy latente en desarrollo global especialmente en los países donde las leyes de propiedad intelectual son más laxas.

Infraestructuras y herramientas de desarrollo. Al tener equipos distribuidos y multiempresa es común que la infraestructura y herramientas varíen. Quienes provienen de organizaciones más maduras cuentan frecuentemente con herramientas robustas y propietarias, mientras que los equipos más pequeños están utilizando las herramientas ligeras, con frecuencia de código abierto. Esto puede ser un causante adicional de incompatibilidades de ambientes de desarrollo y problemas de integración.

Factores de éxito

Según Global Software Development Handbook [3] los factores críticos de éxito de este tipo de proyectos son los siguientes:

Reducir ambigüedades de procesos organizacionales, de administración, de requerimientos y diseño. Cualquier ambigüedad puede llevar a diferentes entendimientos, estos a conflictos y re-trabajo.
Maximizar la estabilidad, sobre todo de requerimientos y de arquitectura. Según estudios, una solicitud de cambio a requerimientos en un proyecto distribuido requiere 2.4 veces más de tiempo que en uno de un solo sitio.
Entender dependencias, tanto técnicas como temporales, es crucial. De esto depende la posibilidad de buena distribución del trabajo y la definición adecuada de actividades de coordinación en su volumen, frecuencia y tipo.
Facilitar la coordinación. Existen múltiples maneras de lograr la coordinación entre equipos. La más común es a través de comunicación, aunque también se puede lograr vía procesos, administración del proyecto o la arquitectura.
Balancear flexibilidad y rigidez en procesos. Los procesos tienen que ser lo suficiente flexibles para incorporar diferentes prácticas y experiencias de los equipos y dejarles cierto margen de libertad, pero lo suficientemente rígidos para asegurar que ciertos aspectos del proyecto estén perfectamente definidos, como por ejemplo: instrucciones comprendidas, arquitecturas respetadas, requerimientos cubiertos, administración de configuración definida y aplicada, procedimientos para integración y pruebas adecuados, etc.

Para aterrizar estas ideas al territorio mexicano quiero agregar algo. Seguramente ya tenemos en México empresas que están involucradas en el desarrollo de software global. Sabemos poco de sus experiencias. Por otro lado, tenemos desde hace años el movimiento de creación de clusters, pero cuando los visito y pregunto por proyectos en los que participan varias empresas, la respuesta es que “todavía no, pero ya pronto”.

Conozco los primeros intentos de este tipo de esfuerzos y los estoy observando con el objetivo de tener elementos para generar un modelo de procesos, que permita organizar las empresas pares para que colaboren en proyectos complejos. Digamos un MoProSoft Colaborativo. A los que tienen experiencia en este tipo de proyectos los invito a colaborar.

Referencias:
[1] D. W. Karolak. Global Software Development: Managing Virtual Teams and Environments. IEEE Computer Society, 1998.
[2] K. Fryer, M. Gothe. “Global software development and delivery: Trends and challenges”. http://bit.ly/sg30r2
[3] R. Sangwan, M. Bass, N. Mullick, D.J. Paulish & J. Kazmeier. Global Software Development Handbook. Auerbach Publications, 2007.

Bio

La Dra. Hanna Oktaba es profesora de la UNAM, miembro del IPRC, y directora técnica del proyecto COMPETISOFT.
hanna.oktaba@ciencias.unam.mx

Documentación de Arquitectura

Anonymous — Tue, 04 Jan 2011 16:50:02 +0000

Documentación de Arquitectura Anonymous Tue, 01/04/2011 - 10:50

Publicado en

SG #30

Arquitectura

Autor

En entregas previas de esta sección, nos hemos enfocado en aspectos relativos a los requerimientos que influyen a la arquitectura, y a la manera de diseñar la arquitectura con el fin de satisfacer estos requerimientos. Para ser útil, este diseño necesita ser comunicado de forma adecuada. Así que en esta ocasión abordamos aspectos de comunicación del diseño y más particularmente en la actividad de documentación de la arquitectura.

La documentación del diseño de la arquitectura de software cumple varios propósitos importantes. Entre ellos están:

• Comunicar a los distintos involucrados el diseño y las decisiones que permitieron llegar a éste.

• Permitir realizar análisis y evaluación del diseño.

• Soportar las actividades de mantenimiento.

¿Cómo se documenta el diseño arquitectural? Para contestar esto, primero recordemos que hemos definido la arquitectura de software como un conjunto de estructuras compuestas por elementos con propiedades y relaciones entre ellos. Entonces, para documentar un diseño arquitectural requerimos poder representar estas distintas estructuras. De manera similar a lo que se hace en la construcción, en donde se tienen distintos planos para un mismo edificio, las estructuras del diseño arquitectural se documentan de forma separada a través de distintas vistas. Cada vista modela una parte del diseño arquitectural desde distintas perspectivas que pueden ser por ejemplo dinámicas, lógicas o físicas.

El concepto de vista

La documentación de una vista normalmente incluye una representación gráfica (es decir un diagrama) de la estructura que se está modelando. Aunque existe libertad con respecto a la notación usada, lo más común y conveniente es usar UML. Contar con diagramas que representan una estructura indispensable, pero generalmente no es suficiente para poder comunicar el diseño de forma adecuada. Así que al documentar una vista, conviene acompañar al diagrama de información adicional donde se expliquen decisiones de diseño, además de brindar mayor detalle sobre los elementos mostrados en el diagrama y las relaciones entre estos.

Cabe señalar además que puede ser necesario dividir el diagrama si la estructura es muy compleja. En ese caso, cada parte de la estructura se documenta como una vista individual y se incluye un diagrama de contexto que permite comprender la ubicación de la estructura dentro del sistema completo.

Enfoques de documentación

Es conveniente usar un enfoque preestablecido que sirve de guía en la elección y organización de las vistas. Estos son algunos enfoques populares:

4+1 Views. El enfoque (o modelo) 4+1 vistas es muy popular, particularmente porque está asociado al proceso de desarrollo RUP. Este modelo propone que se usen 5 vistas:

• Vista lógica. Modela elementos que soportan la funcionalidad que el sistema provee al usuario final de un punto de vista estático o dinámico mediante diagramas tales como clases, paquetes y secuencia.

• Vista de proceso. Esta vista opcional modela los aspectos dinámicos del sistema y captura aspectos tales como concurrencia y sincronización mediante diagramas tales como el de actividades.

• Vista de desarrollo. Modela la organización estática del software en su ambiente de desarrollo, típicamente mediante diagramas de componentes.

• Vista física. Modela el mapeo del software con el hardware, típicamente con diagramas de implantación.

• Vista de casos de uso. Esta es la vista adicional (+1) que es central al modelo y que agrupa escenarios de casos de uso principales. Para su representación se puede usar un diagrama de casos de uso acompañado de descripciones textuales de los escenarios. Las otras vistas deben permitir comprender la manera en que los escenarios de casos de uso son soportados por la arquitectura.

IEEE 1471. Es un estándar de la IEEE para la descripción arquitectural de sistemas intensivos de software. IEEE 1471 define un marco conceptual que relaciona los conceptos de sistema, descripción arquitectural y vista. En éste marco, las vistas se deben ajustar a un viewpoint (punto de vista), el cual especifica las convenciones para construir y usar una vista, e incluye elementos tales como los lenguajes que pueden ser usados para describir la vista así como los métodos de modelado y las técnicas de análisis que pueden ser aplicados a las representaciones de la vista. En IEEE 1471, una descripción arquitectural incluye uno o más viewpoints, los cuales se seleccionan con base en los involucrados hacia los cuales está dirigida la arquitectura.

Views and Beyond. Este enfoque, desarrollado por el SEI, establece que la documentación de una arquitectura de software involucra la elección de las vistas relevantes de la arquitectura, la documentación de cada una de esas vistas, así como la documentación de la información que aplica a más de una vista o a un conjunto de vistas en su totalidad. Los detalles del enfoque incluyen el método para elegir las vistas más relevantes para los involucrados de la arquitectura, plantillas estándar para documentar las vistas, información necesaria para documentar información que aplica a través de varias vistas, así como definiciones del contenido de las plantillas. A diferencia del enfoque 4+1 vistas, Views and Beyond no especifica el número de vistas a usar.

Ejemplo

Apliquemos el modelo 4+1 vistas al ejemplo que hemos venido desarrollando en artículos anteriores de esta sección. Recordando, el ejemplo hacía referencia a la “compañía xyz que se dedica a la comercialización de productos de diversos fabricantes”.

Vista de casos de uso. La vista de casos de uso incluiría un diagrama con los casos de uso primarios junto con descripciones de estos escenarios. Uno de los escenarios que debería incluir esta vista es el flujo principal del caso de uso primario “Realizar consultas del catálogo de productos”.

Vista lógica. La vista lógica (ver Figura 1) presenta los módulos para llevar a cabo las consultas al catálogo de productos, como son “consulta de productos” y “administrador de búsquedas”, además de los módulos necesarios para comprar productos específicos como son “carro de compras”, “pagos” y “administrador de compras”. Cabe señalar que el diagrama presentado muestra un segundo nivel de descomposición del sistema. Un tercer nivel de descomposición requeriría tomar los diferentes módulos y descomponerlos en componentes asociados a las tecnologías específicas utilizadas en el sistema. De un punto de vista dinámico, la realización del caso de uso “Realizar consultas del catálogo de productos” se aprecia en la Figura 2. Esta representación supone que se ha realizado una descomposición del sistema, de la cual surgieron los componentes especificados en el diagrama de secuencia, y supone además que se eligieron las tecnologías JSF para la capa de presentación y Spring Webservices para la capa de integración.

Vista física. La vista física muestra mediante un diagrama de implantación (deployment) de UML, la terminal por medio de la cual se va a utilizar el sistema, el servidor de aplicaciones en el que van a estar instaladas las capas de la aplicación: vista, negocio e integración, y sistemas en servidores externos a través de los cuales nuestro sistema va a obtener información.

Otras vistas. De forma similar sería necesario incluir la vista de desarrollo. La vista de proceso no es necesaria en éste ejemplo debido a que el sistema no requiere representar elementos de concurrencia o sincronización.

Conclusión

La documentación de la arquitectura es una actividad fundamental para poder realizar una comunicación adecuada del diseño. Es importante recalcar que no existen criterios precisos que permitan determinar el grado exacto de documentación que se debe realizar, y esto se debe determinar considerando diversos aspectos que incluyen a los involucrados, el tipo de proyecto y la experiencia del equipo de desarrollo.

Figura 1. Diagrama de paquetes asociado al caso de uso de consulta de catálogo de productos.

Figura 2. Diagrama de secuencia asociado al caso de uso de consulta de catálogo de producto.

Figura 3. Figura 3. Diagrama de implantación general al sistema.

.BIO

El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Ha realizado investigación en temas relacionados con arquitectura de software desde el año 2000 y en años recientes se ha enfocado en el estudio y la aplicación de métodos que apoyen al desarrollo de arquitectura de software dentro de la industria Mexicana. www.humbertocervantes.net
La MSc. Edith Valencia es arquitecto de software en la empresa QuarkSoft S.C. Cuenta con más de 10 años de experiencia profesional y obtuvo la maestría con honores en Ingeniería de Software en la Universidad de York en El Reino Unido. Sus áreas de interés incluyen arquitecturas de software, ingeniería de procesos de software y metodologías ágiles. evalencia@quarksoft.net

Referencias

[1] Kruchten Philippe, “Architectural Blueprints—The “4+1” View Model of Software Architecture”, IEEE Software 12, 1995
[2] IEEE Computer Society, “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”, IEEE Std 1471-2000, 2000
[3] Clements P. et al. Documenting Software Architectures, Views and Beyond. Addison Wesley, 2003

El Papel de la Arquitectura de Software en Scrum

Anonymous — Tue, 04 Jan 2011 16:19:57 +0000

El Papel de la Arquitectura de Software en Scrum Anonymous Tue, 01/04/2011 - 10:19

Publicado en

SG #30

Arquitectura

Autor

Como ustedes saben, Scrum es una metodología ágil para la gestión del desarrollo de software, que está basada en un proceso iterativo e incremental. Debido a la importancia de la arquitectura de software, es primordial definir claramente su papel en scrum. Es por esto que en el presente artículo se describe una propuesta del papel de la arquitectura de software en el ciclo de desarrollo de Scrum y de las responsabilidades del arquitecto de software en esta metodología.

La competitividad del mercado de desarrollo de software y la necesidad de los clientes de reducir el “time to market” obligan a las organizaciones de desarrollo de software a ser agresivas en sus calendarios de entrega. Esto ha hecho que hayan surgido metodologías de desarrollo de software ágiles tales como Scrum: una metodología para la gestión y desarrollo de software basada en un proceso iterativo e incremental. Su estructura está basada en sprints los cuales son iteraciones de 1 a 4 semanas. Scrum se usa en proyectos de entorno complejos, donde se desea obtener resultados rápidos y la productividad es lo más importante [1].

En los proyectos basados en Scrum se consideran tres roles:

Dueño del producto (Product Owner): Es quien determina las prioridades de los entregables.
Maestro de Scrum (Scrum Master): Administra y facilita la ejecución del proceso.
Equipo de Trabajo (Stakeholders): Trabajan en conjunto para entregar resultados en cada sprint.

Como se puede observar, en medio de los participantes del proceso no quedan claras las responsabilidades del arquitecto de software. Sin embargo, como comenta Charlie Alfred, “la arquitectura es el aceite y el filtro que lubrica adecuadamente a Scrum” [2].

Si se compara el rol del arquitecto de edificaciones con el del arquitecto de software, se puede observar que ambos modelan las construcciones a un alto nivel de abstracción, proveen posibles soluciones, mejoran la comunicación con los miembros del equipo de construcción a través de modelos, visualizan las generalidades del problema, definen los roles y las interacciones entre los componentes de construcción, entre otras tareas. Al igual que es imposible pensar que un rascacielos puede ser construido sin una arquitectura sólida, es imposible pensar que productos de software empresariales puedan ser implementados sin una arquitectura bien pensada.

Según Bass, Clements y Kasman [3], “la arquitectura de software de un programa o sistema informático, es la estructura o estructuras del sistema, que incluyen elementos de software, las propiedades externamente visibles de esos elementos, y las relaciones entre ellos.” Esta definición nos lleva a concluir que la arquitectura de software garantiza el buen desarrollo del software y a tener un sistema que cumpla con los requerimientos funcionales y no funcionales del cliente. Además, la arquitectura es clave en la reutilización de artefactos de software en sistemas de líneas de productos de software.

Viendo la importancia de la arquitectura en el desarrollo de software, en éste artículo se presenta una propuesta para gestionar la arquitectura de software en Scrum. En el primer capítulo se trata el tema de la localización de la arquitectura de software en el ciclo de desarrollo de Scrum; en el segundo capítulo se describen las tareas del arquitecto de software en Scrum; finalmente se presentan las conclusiones y el trabajo futuro.

Arquitectura de software en el ciclo de desarrollo de Scrum

La idea fundamental de la presente propuesta es adicionar un sprint inicial llamado “Sprint 0” al inicio del ciclo de desarrollo. El objetivo principal del arquitecto en el Sprint 0 es analizar y diseñar la generalidad del sistema, que satisfaga los requisitos y sea entendible por los miembros del equipo desde sus diferentes puntos de vista durante el desarrollo. Un punto clave, es reutilizar artefactos de software creados a partir de la arquitectura para ser más ágiles en el desarrollo de productos específicos.

En la Figura 1 se puede observar que el Sprint 0 comprende tres fases que fueron tomadas del ciclo de vida de entregas evolutivas [3]. En el Sprint 0 se construye la arquitectura de forma iterativa mediante un análisis preliminar de los conductores arquitectónicos (requisitos funcionales, de calidad y del negocio), y de un estudio de factibilidad del proyecto. No se necesita tener todos los requisitos claros para comenzar la fase de diseño arquitectónico.

Para determinar los conductores arquitectónicos, se debe identificar los objetivos del negocio de más alta prioridad, que son pocos. Estos objetivos del negocio se convierten en los escenarios de calidad o casos de uso. De esta lista, se deben escoger los que tendrán un mayor impacto sobre la arquitectura.El diseño arquitectónico puede comenzar una vez que se encuentran definidos los conductores arquitectónicos. El proceso de análisis de requisitos será entonces influenciado por las preguntas generadas durante el diseño arquitectónico.

El resultado del Sprint 0 es un documento inicial que explica la arquitectura. El documento puede basarse en los pasos definidos por el método ADD (Attribute Driven Design). Este método ha sido probado exitosamente en proyectos anteriores [4]. Con ADD se puede definir una arquitectura de software mediante un proceso de descomposición basado en los atributos de calidad del software.

El documento inicial de la arquitectura se debe evaluar con el fin de saber si la arquitectura cumple con los requisitos de calidad. Para realizar esta evaluación, se propone el método ATAM (Architecture Tradeoff Analysis Method). El ATAM revela cuán bien una arquitectura satisface los objetivos particulares de calidad y provee una aproximación de cómo los objetivos de calidad interactúan.

Figura 1. Propuesta de gestión de la arquitectura de software en Scrum.

Si en la evaluación de la arquitectura se encuentra que se deben realizar cambios a la misma, entonces ésta se debe refinar hasta llegar a tener como resultado del Sprint 0 el documento pulido de la arquitectura junto con el sistema esqueleto. Finalmente, la arquitectura creada en el Sprint 0 beneficiará el desarrollo en los siguientes sprints.

Rol del arquitecto de software en Scrum

El rol y actividades del arquitecto de software cambia de enfoque dependiendo de si se está en el Sprint 0, o en sprints subsecuentes.

Sprint 0. En sistemas complejos, una persona difícilmente puede cubrir con amplitud técnica las decisiones arquitectónicas y dar credibilidad a la arquitectura de software [5]. Esto quiere decir que la participación del equipo es de vital importancia para la creación y el mantenimiento de la arquitectura. Un equipo de arquitectos de software que se aísle del equipo de Scrum, puede producir una arquitectura que corra el riesgo de ser rechazada. Es por esto que recomendamos que el arquitecto o los arquitectos de software sean miembros del equipo de Scrum. Una de las actividades que se debe realizar en equipo es la evaluación de la arquitectura. Específicamente, en el método ATAM se requiere la participación mutua de tres equipos que trabajan en conjunto con los arquitectos de software: el de evaluación, el de tomadores de decisiones del proyecto, y el de los involucrados en la arquitectura.

Sprints subsecuentes. El arquitecto de software asegura que el equipo de Scrum entienda el enfoque y los retos arquitectónicos más importantes en cada sprint. Los equipos de Scrum realizan construcciones cortas, guiados por las estrategias de la arquitectura. A continuación se nombran algunas de las responsabilidades del arquitecto de software desde el Sprint 1 en adelante:

El dueño del producto y el maestro de Scrum trabajan con el arquitecto para priorizar los requisitos a implementar en cada iteración.
El arquitecto comunica las decisiones y facilita las conversaciones arquitectónicas de distintos puntos de vista en cada sprint.
El arquitecto asegura que haya conformidad entre las entregas en cada sprint y la arquitectura.
El arquitecto responde preguntas y da orientación arquitectónica cuando sea necesario.
Junto con el maestro de Scrum, coordina a los miembros del equipo para adaptarse a la arquitectura prevista.
El arquitecto junto con el dueño del producto y los miembros del equipo preparan el Product Backlog.

Conclusión y trabajo futuro

La arquitectura de software y Scrum no se repelen, más bien se complementan. El arquitecto describe las tácticas que se deben seguir para cumplir con los requisitos de calidad del sistema, teniendo clara la imagen global de éste. Además, permite que los artefactos a construir se reutilicen con el fin de reducir el tiempo de desarrollo y mejorar la calidad del producto.

En el presente artículo ofrecimos una propuesta para incluir la arquitectura de software en Scrum. En el Sprint 0 se realizan las actividades concernientes al análisis y diseño de la arquitectura de software, y el sistema esqueleto. En los siguientes sprints el arquitecto de software se asegura de que la implementación cumpla con la arquitectura.

En un futuro proyecto implementaremos la presente propuesta en una línea de productos de software.

Referencias

O. Soto & G.H. Alférez. “Scrum, ¿Un Paradigma de Administración de Proyectos que Cumple lo que Promete?” Software Guru, Agosto 2009. http://bit.ly/sg30r3
C. Alfred. “Scrum and Architecture Partners or Adversaries”. http://bit.ly/sg30r4
L. Bass, P. Clements, & R. Kasman. Software Architecture in Practice. Addison Wesley, 2da ed., 2003.
O. Soto & G.H. Alférez. “An Architecture Proposal for Academic Software in Adventist Universities”. Catalyst, Asia-Pacific International University, Vol. 4, num. 1. http://bit.ly/sg30r5
R. Malan & D. Bredemeyer. “Architecture Teams”. http://bit.ly/sg30r6
R. Sullivan. “Scrum and Architecture”. http://bit.ly/sg30r7

Bio

Edwin Rafael Mago Vásquez es Director de la Escuela de Informática del Instituto Universitario Adventista de Venezuela (IUNAV). Es graduado de la Maestría en Educación con Énfasis en Educación Superior de la Universidad de Montemorelos, México. Actualmente está cursando la Maestría en Ciencias Computacionales en esta universidad. ermago@cantv.net

Germán Harvey Alférez Salinas es Director del Centro de Investigación y Desarrollo de Tecnología (CIDET) de la Facultad de Ingeniería y Tecnología en la Universidad de Montemorelos, e investigador asociado en Asia-Pacific International University, Tailandia. Es graduado con honores del Master of Science in Information and Communication Technology en Assumption University, Tailandia. Sus áreas de interés incluyen software product lines, model driven development, y software architectures. http://fit.um.edu.mx/harvey

Calidad de Datos en Aplicaciones Web

Anonymous — Mon, 03 Jan 2011 23:14:02 +0000

Calidad de Datos en Aplicaciones Web Anonymous Mon, 01/03/2011 - 17:14

Publicado en

SG #30

Autor

En la actualidad, es fundamental mantener un nivel aceptable de calidad en los datos que gestionan las compañías, sobre todo en las aplicaciones Web. Para asegurar esos niveles de calidad de datos (DQ), es imprescindible llevar a cabo una gestión de los requisitos específicos de DQ durante todo el ciclo de desarrollo de la aplicación Web. Sin embargo, en el ámbito de desarrollo de aplicaciones Web no existen propuestas que contemplen artefactos para la gestión de este tipo de requisitos de calidad de datos. El objetivo de este trabajo es dotar a los analistas y desarrolladores de aplicaciones Web de las herramientas necesarias para especificar e implementar de forma clara e intuitiva los requisitos de DQ mediante distintos elementos de modelado.

Considerando el enfoque MDA (Model Driven Architecture) y basándonos en la Ingeniería Web Dirigida por Modelos (MDWE), en este artículo se presenta una propuesta basada en extensiones al metamodelo WebRE, que permitirá modelar los elementos considerados básicos para la gestión de requisitos de DQ en aplicaciones Web. Adicionalmente se presenta los artefactos desarrollados que permiten hacerlo operativo a través de un plugin desarrollado en la plataforma Eclipse.

Introducción a la calidad de datos (DQ)

Es común que una aplicación de software presente comportamientos erróneos, no por defectos en la aplicación como tal, sino por defectos en los datos que utiliza. Es decir, por niveles inadecuados de calidad en sus datos.

La calidad de los datos (DQ) depende del contexto en el que éstos se van a utilizar. Es decir, un dato es de calidad si es válido para el propósito en que un usuario quiere utilizarlo para una tarea determinada. Este concepto se conoce como “adecuación al uso” (fitness for use).

Para abordar la calidad de datos en un contexto en específico, se acostumbra dividirla en partes más pequeñas, “calidades menores” conocidas como dimensiones de calidad de datos. La agrupación de varias de estas dimensiones recibe el nombre de modelos de calidad de datos.

Si bien no existe un modelo universal de DQ, el propuesto por el estándar internacional ISO/IEC 25012 para Sistemas de Información proporciona una buena aproximación. Dicho modelo identifica 15 características o dimensiones consideradas desde dos puntos de vista:

• Inherente: la calidad de datos inherente se refiere al grado en el cual las características de calidad del dato tienen el potencial intrínseco para satisfacer las necesidades implicadas cuando el dato es usado bajo condiciones específicas.

• Dependiente del sistema: se refiere al grado en el cual la calidad del dato es enriquecida y preservada dentro de un sistema de cómputo cuando el dato es usado bajo condiciones específicas.

La tabla 1 en la siguiente página describe las dimensiones de calidad de datos propuestas por el estándar ISO/IEC 25012.

Definimos un “requisito de calidad de datos” como “la especificación de las dimensiones o características que un conjunto de datos debería cumplir para una tarea específica”. El propósito principal es satisfacer las necesidades específicas de calidad en los datos que cada uno de los usuarios requiere en un momento determinado.

El Metamodelo WebRE

En lugar de crear una nueva metodología para desarrollo web que incorpore aspectos de calidad de datos, consideramos que es mejor ampliar una metodología existente. Analizando las distintas opciones de metodologías para desarrollo Web que soportan las fases de requisitos y diseño encontramos el metamodelo Web Requirementes Engineering (WebRE) propuesto por Escalona y Koch [2].

En la figura 1 se aprecia el metamodelo propuesto por WebRE. Las metaclases representan los conceptos sin ninguna información acerca de su representación, y son agrupados en dos paquetes siguiendo la estructura del metamodelo de UML “WebRE Structure” y “WebRE Behavior”.

Figura 1. Metamodelo WebRE.

Tabla 1. Dimensiones de DQ según el estándar ISO/IEC 25012.

La funcionalidad de un sistema Web (WebRE Behavior) es modelada por un conjunto de instancias de dos tipos de casos de uso específicos “Navigation” y “WebProcess”, y actividades específicas como “Browse”, “Search” y “UserTransaction”.

El segundo paquete del metamodelo “Structure Package”, contiene las metaclases usadas para describir los elementos estructurales del sistema Web: contenido (Content), nodo (Node) e interfaz de usuario Web (WebUI). Una breve descripción de cada elemento del metamodelo se muestra en la Tabla 2.

Metamodelo de Requisitos de Calidad de Datos para Aplicaciones Web

Una vez que hemos mostrado las características y elementos principales del metamodelo tomado como base (WebRE), describamos ahora la propuesta de metamodelo ampliado (DQ_WebRE) para la integración de elementos para la gestión de requisitos de calidad de datos. Para ello introducimos los siguientes conceptos: “DQRequirement”, “InformationCase”, “Add_DQ_Metadata”, “DQ_Validator” y “DQ_Metadata”. Dichos conceptos se presentan como elementos fundamentales dentro del metamodelo propuesto (ver Figura 2).

Tabla 2. Elementos del metamodelo WebRE.

Figura 2. Metamodelo para requisitos de calidad de datos DQ_WebRE

La metaclase “DQ_Requirement” representa un caso de uso específico, necesario para modelar los requisitos de DQ (dimensiones de DQ) que estarán relacionados a los casos de uso “InformationCase” (IC).

La metaclase “InformationCase” representa los casos de información (IC) de la aplicación Web. A diferencia de los casos de uso normales, la principal función de los IC es gestionar y almacenar los datos involucrados con las funcionalidades de tipo “WebProcess”. Estos datos estarán relacionados a los requisitos específicos de DQ (DQ_Requirement).

La metaclase “Add_DQ_Metadata” representa una actividad concreta relacionada a las diferentes actividades “UserTransaction”, esta metaclase se encarga de agregar y/o verificar la información de DQ (metadatos de DQ) asociada a cada una de las instancias de las metaclases DQ_Metadata y DQ_Validator.

La metaclase “DQ_Metadata” representa un elemento estructural de la aplicación Web. Aquí serán gestionados y almacenados los metadatos de DQ. Estos metadatos estarán asociados a los elementos de tipo “Content”. En este sentido, será posible especificar diferentes requisitos de DQ ligados directamente a los datos almacenados por los elementos de tipo “Content”.

La metaclase “DQ_Validator” representa un elemento estructural del sistema Web, esta metaclase será la responsable de implementar funciones específicas de DQ, con el objetivo de validar o restringir los elementos de interfaz de usuario (WebUI) que proveerá la aplicación Web.

Aplicación usando plugin de Eclipse

El metamodelo DQ_WebRE se implementó en la plataforma Eclipse, haciendo uso del Eclipse Modeling Framework (EMF). Esto permite que los modelos generados a partir de este metamodelo podrán ser almacenados en formato XMI , el cual puede considerarse como un modelo de entrada para posteriormente implementar las transformaciones necesarias y convertir los modelos definidos a modelos de diseño (por ejemplo, diagramas de clases) y posteriormente código.

Con el objetivo de soportar nuestro enfoque, se desarrolló un plugin usando GMF (Graphical Modeling Framework). Dicho plugin permite modelar los distintos elementos para la gestión de la calidad de datos mediante diagramas de casos de uso y diagramas de actividades.

El plugin se desarrolló para proporcionar un ambiente de trabajo adecuado que entre otras cosas, permitiera realizar diagramas de modelado con los elementos definidos. En la parte derecha de la herramienta (ver Figura 3), se puede observar un “toolbox” especial con los elementos definidos en el metamodelo “DQ_WebRE”.

El ejemplo ilustrativo describe un proceso de negocios típico de una aplicación Web, que permite llevar a cabo la reserva y pago de entradas para conciertos y eventos. En este ejemplo, un analista podría modelar el correspondiente caso de uso “Realizar reserva de entradas” usando los elementos propios del metamodelo (ver Figura 3). En este diagrama el analista incluye el caso de uso “Hacer reserva y pago de entradas” (de tipo InformationCase), el cual se puede relacionar con los requisitos específicos de DQ (Asegurar Confidencialidad de los datos, Garantizar Exactitud de datos respecto al formato, Verificar Completitud en datos introducidos y Confirmar la Credibilidad de los datos), indicando de esta forma que los datos gestionados por este tipo de caso de uso deberán cumplir dichos requisitos de DQ, los cuales deberían ser implementados en las etapas posteriores de diseño y programación de la aplicación Web.

Haciendo uso de los elementos definidos en el metamodelo, es posible también realizar los correspondientes diagramas de actividad (ver Figura 4). En esta figura, el diagrama modela las actividades principales llevadas a cabo con el objetivo de describir de mejor manera el caso de uso “Realizar reservación de entradas”. El cliente primeramente debería ser capaz de ver los conciertos y eventos disponibles. Sin embargo, para poder realizar una reserva de entradas tendrá que registrarse o iniciar sesión en la aplicación Web. Una vez que se consigue el acceso a la aplicación, el cliente podrá seleccionar el evento y verificar la disponibilidad y el coste; si el cliente está de acuerdo con los datos, podrá hacer la reserva introduciendo los datos específicos para la reserva. Enseguida el cliente podrá realizar el pago de las entradas y el sistema le enviará las entradas de forma electrónica por email.

En este diagrama de actividades, el analista será capaz de modelar las actividades específicas para cumplir con los requisitos de DQ, estas actividades estarán relacionadas a los distintos elementos propios del modelado de la aplicación Web. En este ejemplo ilustrativo, la actividad “Verificar y agregar metadatos de confidencialidad” será la responsable de cotejar y anexar dichos metadatos de confidencialidad, los cuales serán almacenados en una instancia de la clase “DQ_Metadata”, cumpliendo de esta manera con el requisito de DQ de “Asegurar Confidencialidad de datos”. En el diagrama también se observa la relación existente de los metadatos de Confidencialidad con los datos de la reservación.

La actividad “Verificar Exactitud de los datos”, será la responsable de agregar las funciones específicas (almacenadas en una instancia de la clase “DQ_Validator”) para verificar el requisito de DQ “Garantizar Exactitud de datos respecto al formato”, de los datos gestionados en la “Página Web de reservas” (del tipo WebUI).

De manera similar, la actividad “Verificar Completitud de datos” estará encargada de agregar las funciones específicas para verificar la completitud de cada uno de los elementos gestionados dentro de la “Página Web de pagos” (tipo WebUI).

Finalmente, la actividad “Verificar Credibilidad de datos” será la responsable de gestionar y agregar los metadatos de DQ (almacenados en una instancia de la clase “DQ_Metadata”), con el objetivo de garantizar el requisito de DQ de “Confirmar la Credibilidad de los datos”, el cual estará relacionado con los datos respectivos de Facturación (de tipo “Content”).

Conclusiones y trabajo futuro

Una correcta gestión de los requisitos de calidad de datos contribuye significativamente a eliminar o al menos minimizar posibles problemas con los datos, permitiendo a los usuarios de los sistemas de información efectuar sus operaciones con un mayor nivel de confianza.

En este artículo se muestra una propuesta de solución basada en el enfoque de desarrollo dirigido por modelos, presentando un metamodelo ampliado (DQ_WebRE) para la gestión de requisitos de calidad de datos tomando como base el metamodelo (WebRE). Mediante la especificación de este metamodelo y haciendo uso del plugin desarrollado, es posible gestionar y modelar los aspectos clave de DQ desde la etapa inicial del proceso de desarrollo, lo que permitirá a los desarrolladores el tener conciencia de los requisitos de DQ.

Como trabajo futuro se ha planificado la incorporación de mecanismos o reglas de transformación de modelos, mediante el lenguaje QVT (Query/View/Transformation). Esto permitirá obtener a partir de modelos de análisis distintos modelos de diseño y posteriormente la generación de código de forma semiautomática.

Figura 3. Diagrama de casos de uso especificando requisitos de DQ.

Figura 4. Diagrama de actividades con gestión de DQ.

Referencias

M. Ge & M. Helfert. “A Review of Information Quality Research”, International Conference on Information Quality, 2007.
D. Strong, Y.W. Lee, & R.Y. Wang. “Data Quality in Context”, Communications of the ACM Vol 40 Issue 5, 1997.
M.J. Escalona & N. Koch. “Metamodeling the Requirements of Web Systems”, Web Information Systems and Technologies, 2006. http://bit.ly/sg30r8

Bio

César Guerra-García es profesor en el Departamento de Tecnologías de Información en la Universidad Politécnica de San Luis Potosí, y doctorando en la Universidad de Castilla La Mancha. cguerra74@gmail.com

Ismael Caballero es profesor en el Departamento de Tecnologías y Sistemas de Información en la Universidad de Castilla-La Mancha en Ciudad Real, España. ismael.caballero@uclm.es