Blog de Leo Miaton

Thinking about numbers

2011-06-10T13:43:00.003-03:00

Numbers are left-winged! Who would have thought that this right-winged, liberal world would have its foundations based on exactly its opposite ideology. Yes, these eleven members of the evil Numerates sect, yes, to believe or not to believe, if you watch them carefully you will notice that when put together in a line, the one in the left goes first! the boss is on the left!

Besides, as in any sect, each member has its own, hidden personality.

Everybody thinks that number one is the tallish, self-important, big-headed of all numbers. There must be some truth in it, as it is in most cases that it comes first in line...oh, but no one has seen that it is not a "he" but a "she"...haven't you considered her haircut?

Next is number two, the duck...and let me say that I don´t quite see why it is that in the box of matches there are swans instead of ducks...and then city boys are said to confuse a chicken with a cow! Isn't it ironic?

Following number two, there comes the busty girl in the group, the slutty one that enjoys being amongst others. I wonder who the others are...

At night, or early in the morning, it is when they appear. In the bar by the corner, when everybody is gone and only the waiter Oswald stays, cleaning up the tables.

At the crack of dawn, when workers start waking up, five joins them, the most left-winged number in the group, the one that represents the working class. Number six is also working class but I dare say that five is a bit more self-sacrificed.

As in any group, there is a darling, even when I cannot tell the reason this is so, maybe it is because of her long hair, her delicate curves, or if I'm mean I can think it is because she's a bit of a flat-head! haha

To infinity and beyond! who am I talking about? if it wans't because it is always wasted, you could easily tell. Beware: sometimes it is the busty one and her lesbian sister!

After that, nine appears with his twin brothers, all nines, but something uneasy is in the air, they are the conmen, who pretend to be cheap but who are in fact really close to the big-headed and the fatty ones!

And last, but not least, the fatty one himself: zero, who is never overlooked. He may appear in a group and sometimes by the left, when he meets his friend, the comma. Many books have been written about him, he's misterious, but poor him, he is used by the others, talked about, he is even called fatty when his belly is empty (only a few have feed him, the Big blue among them).

Style

2011-06-10T13:41:00.001-03:00

Style is the most important thing: to travel with style, to live with style, to enjoy stylishly; but to suffer with style is, indeed, what makes the difference, what makes us unique.

Escrito a mano

2011-04-25T10:42:00.001-03:00

¿Cuánto hace que no experimentamos el placer de recibir una carta manuscrita en letra cursiva? La caligrafía es una habilidad humana en rápida extinción, porque ya casi no se enseña en las escuelas.

Cuando se emplea una lapicera, en general se lo hace para escribir con letra de imprenta. Stefano Bartezzaghi y María Novella de Luca, periodistas italianos interesados en el tema, se preguntan si la preocupación por el ocaso de la escritura cursiva responde a la nostalgia o constituye una emergencia cultural. Muchos expertos se inclinan por la última alternativa.

En Inglaterra se vuelve a usar la estilográfica para que los estudiantes aprendan la grafía. En Francia también se considera que no se debe prescindir de esa habilidad, pero allí el problema reside en que ya no la dominan ni los maestros.

Aunque el mundo adulto no está aún preparado para recibir las nuevas inteligencias de los niños producto de la tecnología, la pérdida de la habilidad de la escritura cursiva explica trastornos del aprendizaje que advierten los maestros e inciden en el desempeño escolar.

En la escritura cursiva, el hecho de que las letras estén unidas una a la otra por trazos permite que el pensamiento fluya con armonía de la mente a la hoja de papel. Al ligar las letras con la línea, quien escribe vincula los pensamientos traduciéndolos en palabras.

Por su parte, el escribir en letra de imprenta, alternativa que se ha ido imponiendo, implica escindir lo que se piensa en letras, desguazarlo, anular el tiempo de la frase, interrumpir su ritmo y su respiración.

Si bien ya resulta claro que las computadoras son un apéndice de nuestro ser, hay que advertir que favorecen un pensamiento binario, mientras que la escritura a mano es rica, diversa, individual, y nos diferencia a unos de otros.

Habría que educar a los niños desde la infancia en comprender que la escritura responde a su voz interior y representa un ejercicio irrenunciable.

Es ilógico suponer que la tendencia actual se revertirá, pero al menos los sistemas de escritura deberían convivir, precisamente por esa calidad que tiene la grafía de ser un lenguaje del alma que hace únicas a las personas. Su abandono convierte al mensaje en frío, casi descarnado, en oposición a la escritura cursiva, que es vehículo y fuente de emociones al revelar la personalidad, el estado de ánimo.

Posiblemente sea esto lo que los jóvenes temen, y optan por esconderse en la homogeneización que posibilita el recurrir a la letra de imprenta. Porque, como lo destaca Umberto Eco, que interviene activamente en este debate, la escritura cursiva exige componer la frase mentalmente antes de escribirla, requisito que la computadora no sugiere.

En todo caso, la resistencia que ofrecen la pluma y el papel impone una lentitud reflexiva. Muchos escritores, habituados a escribir en un teclado, desearían a veces volver a realizar incisiones en una tableta de arcilla, como los sumerios, para poder pensar con calma. Eco propone que, así como en la era del avión se siguen tripulando barcos a vela, sería auspicioso que los niños aprendieran caligrafía, para educarse en lo bello y para facilitar su desarrollo psicomotor.

Como en tantos otros aspectos de la sociedad actual, surge aquí la centralidad del tiempo. Un artículo reciente en la revista Time , titulado Duelo por la muerte de la escritura a mano, señala que es ése un arte perdido, ya que, aunque los chicos lo aprenden con placer porque lo consideran un rito de pasaje, "nuestro objetivo es expresar el pensamiento lo más rápidamente posible. Hemos abandonado la belleza por la velocidad, la artesanía por la eficiencia. Y , sí -admite su autora, Claire Suddath-, tal vez seamos algo más perezosos.

La escritura cursiva parece condenada a seguir el camino del latín: dentro de un tiempo, no la podremos leer". Abriendo una tímida ventana a la individualidad, aún firmamos a mano. Por poco tiempo.

By Guillermo Jaim Etcheverry

Las escuelas matan la creatividad

2011-03-20T19:34:00.005-03:00

Sir Ken Robinson plantea de manera entretenida y conmovedora la necesidad de crear un sistema educativo que nutra (en vez de socavar) la creatividad.

(pueden maximizarlo y ver los subtitulos)

Que les parece?

20 Consejos

2011-03-20T18:03:00.004-03:00

Algo para pensar...

Aprende las reglas, así sabrás como romperlas apropiadamente.
Recuerda que a veces el silencio es la mejor respuesta.
Cuando pierdes, no pierdes la lección.
Acércate al amor y a la cocina con osada entrega.
Sigue las tres R: Respeto a ti mismo, Respeto para los otros y Responsabilidad sobre todas tus acciones
Recuerda que no conseguir lo que quieres, a veces significa un maravilloso golpe de suerte.
Ten en cuenta que el gran amor y los grandes logros requieren grandes riesgos
No permitas que una pequeña disputa destroce una Gran amistad.
Cuando creas que has cometido un error, haz algo inmediatamente para corregirlo.
Ocupa algo de tiempo cada día en estar solo.
Abre tus brazos al cambio, pero no te olvides de tus valores.
Vive una buena y honorable vida, así cuando seas mayor y mires atrás podrás disfrutarla por segunda vez.
Una atmósfera amorosa en tu casa es el cimiento para tu vida.
En discusiones con alguien querido ocúpate sólo de la situación actual, no saques a relucir el pasado.
Comparte tu conocimiento, es una manera de conseguir la inmortalidad.
Se considerado con la Tierra.
Una vez al año ve a algún lugar en el que nunca hayas estado antes.
Recuerda que la mejor relación es aquella en la que el amor por cada uno excede la necesidad por el otro.
Juzga tu éxito según lo que has sacrificado para conseguirlo.
Cuando juzgues a los demás, hazlo con la mejor voluntad.

(Consejos del Dalai Lama)

¿Cómo abordar el equilibrio vida-trabajo con equilibrio?

2011-03-08T22:41:00.003-03:00

El equilibrio vida-trabajo, dice Nigel Marsh, es demasiado importante para dejarlo en manos del empleador. En TEDxSydney, Marsh establece un día ideal equilibrado entre el tiempo con la familia, el tiempo personal y la productividad -y ofrece un cierto estímulo conmovedor para lograrlo.

Regla fundamental del valor

2010-12-14T15:47:00.002-03:00

Cuando no se genera valor, se destruye valor. No hay opciones intermedias.
Por consiguiente, no generar valor a través del gerenciamiento, equivale a destruir oportunidades, beneficios, capital y competitividad.
Las empresas que no crecen desaparecen y la causa principal es la "no generación de valor".

Sentimientos derivados de un nuevo ciclo educativo que finalizó

2010-11-30T10:48:00.004-03:00

Estamos al final del 2010, terminó el ciclo regular en la universidad en la que intento transmitir mis conocimientos y experiencias... y el resultado ha sido deplorable, solo un pequeño grupo ha aprobado la materia. Soy de la idea que cuando la mayoría de los alumnos no logra cumplir el objetivo, el problema es principalmente el docente. Muy preocupado consulto con mis colegas, qué es lo que les estaba sucediendo... y lamento descubrir que mi materia no es la excepción. Varios factores comunes he encontrado, pero una en particular me alarma: un gran porcentaje de los alumnos muestran un llano desinterés por adquirir conocimiento (vale aclarar que la universidad es privada, los niños pagan, y no poco, por recibir una educación). Esto me entristece, es vergonzoso... lamentable.

Hace poco recibí estas viejas palabras.. tan actuales:

Argentina y una realidad histórica

Los medios de protección que la Constitución nos proporciona, son la libertad y los privilegios y recompensas conciliables con la libertad.
Los argentinos hemos sido ociosos por derecho y holgazanes legalmente. Se nos alentó a consumir sin producir. Nuestras ciudades capitales son escuelas de vagancia de quienes se desparraman por el resto del territorio, después de haberse educado entre las fiestas, la jarana y la disipación.
Nuestro pueblo no carece de alimentos, sino de educación y por eso tenemos pauperismo mental.
En Realidad nuestro pueblo argentino se muere de hambre de instrucción, de sed de saber, de pobreza de conocimientos prácticos y de ignorancia en el arte de hacer bien las cosas.
Sobre todo, se muere de pereza, es decir de abundancia. Quieren pan sin trabajo, viven del mana del Estado y eso les mantiene desnudos, ignorantes y esclavos de su propia condición.
El origen de la riqueza son el trabajo y el capital, ¿Qué duda cabe de que la ociosidad es el manantial de la miseria?
La ociosidad es el gran enemigo del pueblo argentino, es preciso marcarla de infamia, ella engendra la miseria y el atraso mental de los cuales surgen los tiranos y la guerra civil, que serian imposibles en medio del progreso y la mejora del pueblo.

Juan Bautista Alberdi

Sistema Económico y Rentístico de la Confederación Argentina / Marzo de 1855

Nada hemos aprendido?

TED en Argentina

2010-02-19T14:18:00.001-03:00

TED (Tecnología, Entretenimiento, Diseño, del inglés: Technology, Entertainment, Design) es una organización sin fines de lucro dedicada a las "ideas que vale la pena difundir". TED es ampliamente conocida por su conferencia anual (TED Conference) y sus charlas (TED Talks) que cubren un amplio espectro de temas que incluyen ciencias, arte y diseño, política, educación, cultura, negocios, asuntos globales, tecnología y desarrollo, y entretenimiento. Entre los conferencistas que han participado, se encuentran personas como el ex-Presidente de los Estados Unidos Bill Clinton, los laureados con el Premio Nobel James D. Watson, Murray Gell-Mann, y Al Gore, el co-fundador de Microsoft, Bill Gates, los co-fundadores de Google Sergey Brin y Larry Page, y Billy Graham.

TED Conference, es una conferencia anual que reúne a muchos de los más grandes pensadores y hacedores mundiales, para que compartan aquello que los apasiona. La idea es que ellos presenten sus ideas para que el conocimiento y la inspiración que eso genere contribuya a cambiar actitudes y vidas. Estos pensadores comenzaron a compartir gratuitamente los videos de las charlas en internet, y a partir de eso el fenómeno TED alcanzó escala global.

Las presentaciones de TED pueden verse online en su sitio, con gran cantidad de videos subtitulados en español, y son algunos de los materiales preferidos en Internet. En este contexto, un grupo local se puso a trabajar para generar una reunión TEDx en Buenos Aires, que finalmente se concretará en el mes de abril de 2010.

Más información:
- TEDxBuenosAires - 4/8/2010
- TEDxRiodelaPlata – TBD
- TEDxRosario - 6/10/2010
- Conversaciones online subtituladas aquí.

La navegación y sus enseñanzas para la empresa

2009-11-04T08:38:00.005-03:00

La náutica nos enseña a tener un plan B alternativo para las emergencias/crisis, que tenemos en la travesía, se pierde gente en la empresa, se pierden hombres en la travesía, alguien debe cubrir ese rol, cómo se hacen las rotaciones de responsabilidades y cuál es la capacidad de adaptación a los rápidos cambios del mercado.

La náutica es a veces una dura experiencia, por el frío, por el esfuerzo y por la demanda física que esta representa los días de mucho viento, al igual que cualquier semana en la empresa, donde las presiones, los objetivos, nos ponen en un stress extremo que debemos saber manejar.

Las comunicaciones son claves durante la travesía, un orden dada o interpretada de manera incorrecta, implica dar vuelta el velero o que alguien reciba la botavara en su cabeza ante un giro inadecuado o sin la comunicación debida, nada diferente a lo que ocurre en las empresas.

El desarrollo de habilidades, conocimientos y destrezas y es otra de las características de la náutica, algunos se adaptan y difrutan del movimiento permanente del velero, otros sucumben y se descomponen sin poder manejar esa sensación de náuseas.

Es igual la actitud de las personas en la empresa…? Sin duda que no, y en un día de navegación salen a la luz esas actitudes, de manera espontánea y muy visibles en una tripulación de 8 personas.

Los resultados de un día de trabajo dan mucho para redactar, el outdoor, sólo fue el comienzo para detectar y hacer el diagnóstico de los puntos a trabajar por el equipo evaluado.

Comentario de Alberto Herrera - Link

No esperéis libraros de los libros

2009-05-20T13:17:00.001-03:00

MADRID.- Umberto Eco acaba de publicar un libro en Italia con el significativo título de No esperéis libraros de los libros y ayer, en Madrid, defendió la supervivencia del papel frente a los soportes digitales.

Pero el semiólogo y popular novelista no apoya el invento de Gutenberg por razones nostálgicas, sino por variados argumentos que desgrana en el libro, que ha surgido como fruto de un debate con el cineasta francés Jean-Claude Carrière.

"Si tuviera que dejar un mensaje de futuro para la humanidad, lo haría en un libro en papel y no en un disquete electrónico", dijo Eco.

"He visitado la Biblioteca Nacional y he visto libros que tienen 500 años de antigüedad y manuscritos de hace 1000 años. Ahora bien, no sabemos cuánto puede durar un disquete de ordenador. Los llamados discos flexibles han muerto antes de agotar su capacidad de almacenamiento de datos. Hemos escrito un libro de 350 páginas para argumentar la larga vida que aguarda al libro en papel", comentó el autor, de 77 años.

A juicio de Eco, que recibió la medalla de oro del Círculo de Bellas Artes de Madrid, "los nuevos medios de expresión que han surgido a lo largo de la historia no han matado a los anteriores". Así, ni el cine terminó con el teatro ni la televisión obligó a desaparecer a la radio.

"Desconocemos todavía la dimensión del fenómeno de Internet. Pero en un libro o en una obra de teatro sabemos quién es el autor o la tendencia ideológica, mientras que Internet se presta a una especie de mermelada comunicativa en la que todos hablan igual, como sucedió con las emisoras de radio hace unos años."

No se mostró tan seguro el filósofo italiano sobre el futuro de los periódicos en papel. "El libro electrónico -afirmó- no sustituirá a los libros en papel, pero es probable que los soportes digitales releven a los diarios. Está claro que los periódicos ya sufrieron una crisis con la irrupción masiva de la TV. Ahora los informativos ofrecen las noticias en forma de telegrama, mientras el diario del día siguiente proporciona los temas con la extensión de una carta."

"Una de las alternativas que se abren para los diarios es profundizar en las noticias y generar un debate sobre ellas. Hegel dijo que la lectura de los diarios por la mañana eran el rezo matutino del hombre moderno, pero no sé si mi nieto querrá rezar de esa manera", precisó Eco.

Sin su característica barba y apoyado en un bastón, Eco no perdió vigor intelectual ni su simpática ironía. Ante una pregunta sobre el libro que le regalaría a Silvio Berlusconi, dijo: "No le regalaría ninguno, porque él dijo hace 20 años que no lee, aunque a la vista de las últimas noticias, le regalaría Lolita , de Nabokov".

Nota de ElPais.es

Colaboración entre iguales

2008-08-12T16:13:00.008-03:00

(Pensamientos)

Está produciendose un cambio esencial en el modo de canalizar la capacidad de innovación y creación de valor que tienen las empresas. Las empresas inteligentes y multimillonarias reconocen que la innovación suele iniciarse en la periferia del sistema. Cada vez más, estas empresas jerárquicas están recurriendo a modelos de redes de negocios basados en la colaboración y la auto-organización, donde masas de consumidores, empleados, proveedores, socios e, incluso, competidores crean valor cooperando, sin el control directo de una dirección. Esto tiene que ver con el coste cada vez mas reducido de la colaboración....

La era de la inteligencia interconectada en red es una era de oportunidades. No se trata sólo de la interconexión en red de la tecnología, sino de la interconexion en red de los seres humanos mediante la tecnología. No es una era de maquinas inteligentes, sino de seres humanos que, mediante redes, combinan su inteligencia, conocimiento y creatividad para conseguir avances en la creación de riqueza y el desarrollo social. Es una era de nuevas y enormes oportunidades, con un potencial inimaginable.

Pensemos en la investigación científica. En el pasado, los científicos trabajaban con una supercomputadora muy potente, por ejemplo, para simular los mecanismos de una membrana celular biológica como recurso que les permitía comprender la estructura de las moléculas biológicas. Sin embargo, a medida que las redes van invadiendo el planeta, es posible unir de forma simultánea los ordenadores de todas partes del mundo para atacar el problema.
En lugar de un único ordenador caro que presta apoyo a un solo grupo de científicos, es posible interconectar una red global de ordenadores para prestar apoyo a grupos de científicos distribuidos. La red se transforma en un ordenador, infinitamente mas potente que una sola maquina. Y la inteligencia humana interconectada en red se aplica a la investigación, creando así un orden mas elevado de pensamiento, conocimiento --y, tal vez, incluso una conciencia interconectada en red--- entre las personas.

Idéntica interconexion puede aplicarse a los negocios y a casi todos los demas aspectos de la iniciativa humana: aprendizaje, asistencia sanitaria, trabajo, entretenimiento.

La interconexion en red puede transformar la inteligencia de una empresa al incorporar el know-how colectivo para que influya en la resolución de problemas y la innovacion. Al abrir en forma espectacular los canales de comunicación humana, es posible que la conciencia se amplíe y pase de los individuos a las organizaciones? Las organizaciones inconsistentes, como las personas, no aprenden. Si adquieren conciencia, las organizaciones pueden ser capaces de aprender y eso es una condicion previa para la supervivencia. La inteligencia interconectada en red es el eslabón perdido del aprendizaje de las organizaciones y la organización consciente puede construir la base para lograr organizaciones que aprenden, tan difíciles de conseguir. Y, tal vez, la inteligencia interconectada en red pueda extenderse mas allá de las organizaciones para crear una toma de conciencia mas amplia --la conciencia social--- en las comunidades, las naciones y otras entidades mas amplias.

Para las empresas inteligentes, la creciente oleada de colaboración masiva ofrece enormes oportunidades. Las empresas pueden salir de sus cuatro paredes para sembrar las semillas de la innovacion y recoger una abundante cosecha. De hecho, las empresas que entablan unas relaciones agiles y basadas en la confianza con colaboradores externos están bien posicionadas para construir unos ecosistemas empresariales muy activos que crean valor con mayor eficacia que las empresas organizadas jerarquicamente.

Esta nueva forma de innovacion y creacion de valor se la denomina comúnmente "producción entre iguales" y describe lo que ocurre cuando masas de personas y empresas colaboran abiertamente para potenciar la innovacion y el crecimiento en sus sectores.

La produccion entre iguales, en su forma mas pura, constituye una manera de producir bienes y servicios basada completamente en la autoorganizacion y en comunidades igualitarias de individuos que se unen de forma voluntaria para producir un resultado compartido. En realidad, la producción entre iguales combina elementos de jerarquía y autoorganizaicon, y se fundamenta en principios meritocraticos de organización; en otras palabras, los miembros mas cualificados y con mas experiencia asumen el liderazgo y ayudan a integrar las aportaciones de la comunidad.
En muchas comunidades de producción entre iguales, las actividades productivas son voluntarias y no reportan beneficios monetarios. Son voluntarias en el sentido de que las personas hacen contribuciones a esas comunidades porque quieren y porque pueden. Nadie ordena a un trabajador que publique un articulo en Wikipedia o que aporte código al sistema operativo Linux. No reportan beneficios monetarios porque la mayoría de los participantes no se les paga por las contribuciones que hacen (al menos, no en forma directa) y los individuos determinan si quieren producir, qué producen y qué cantidad quieren producir. Sin embargo, que la gente no reciba un dinero por participar en producción entre iguales no implica que no se beneficien de otras maneras.

Por lo pronto, la producción entre iguales aprovecha motivaciones voluntarias de una manera que propicia la asignación de la persona adecuada a la tarea adecuada con mayor eficacia que las empresas tradicionales. La razón es la auto selección.

Normalmente, las comunidades de productores suelen utilizar "licencias publicas generales" para garantizar a los usuarios el derecho a compartir y modificar obras de creación siempre que se comparta con la comunidad cualquier modificación introducida.

Las personas participan en comunidades de producción entre iguales por una amplia variedad de motivos intrínsecos y de interés propio.
Ya sea por diversión, altruismo, obtener stutus dentro de la comunidad para aspirar crecimiento profesional, etc etc

Este tipo de producción funciona cuando se cumplen tres condiciones mínimas:

El objeto de la producción es información o cultura, una circunstancia que mantiene a un nivel bajo el coste de participación para las personas que contribuyen,
las tareas pueden descomponerse en porciones reducidas que los individuos pueden aportar con pequeños incrementos y con independencia de los demás productores (a saber, entradas de una enciclopedia o componentes de un programa informático) y
el coste de combinar esas porciones para obtener un producto final terminado, incluyendo aquí el liderazgo y los mecanismos de control de calidad, debe ser bajo.

En definitiva, la producción entre iguales funciona porque pueden hacerlo.

(Gracias a Don y Anthony)

Negocios en tercera dimensión

2008-07-25T10:04:00.002-03:00

Mucho se ha dicho acerca de la participación de las empresas en Second Life. Lo que en un principio fue un furor, el lugar clave donde "había que estar", hoy tiene algunas miradas escépticas y empieza a despertar desconfianza. Están quienes dicen que las empresas tienen sus locales vacíos, que no hay nadie que los atienda, y que incluso algunas ya piensan en abandonar este espacio.

Second Life, el mundo virtual creado por la empresa Linden Lab, donde las compañías pueden adquirir parcelas de tierra para construir oficinas, salas de conferencias y jardines, fue concebido en un primer momento como un espacio para reforzar el marketing de las compañías. Las noticias acerca de lo que pasaba en esta segunda realidad repercutían luego en el "mundo real", por lo que para tener resonancia en el mercado parecía fundamental formar parte de este juego.

Pero, como suele pasar con todo "boom mediático", Second Life también dejó de ser noticia, y desde las áreas de Marketing se dejó de concebir como el lugar donde "había que estar".

Sin embargo, y más allá de las críticas, hay quienes siguen apostando a esta segunda realidad, utilizando las herramientas que presenta con fines diferentes a la mera visibilidad de la empresa. Así, hay universidades que dictan clases aquí, e incluso ciudades que son sedes de conferencias, para dar algunos ejemplos.

Quienes participamos de este espacio virtual, nos encontramos con infinitas posibilidades para unificar personas y equipos laborales que se encuentran en distintas oficinas, ciudades o países. De este modo, podemos ingresar a un lugar de colaboración, donde se puede trabajar en conjunto con gente que está físicamente distribuida en lugares diversos.

Es cierto que una reunión realizada a través de Second Life puede no tener la calidad de una teleconferencia. Sin embargo, este espacio cuenta con un ambiente completo, realizado con tecnología 3D, donde uno tiene imagen, audio y texto, y que puede resultar muy viable para conectar más de dos puntos. Del mismo modo, puede resultar un espacio interesante para hacer una capacitación a distancia.

A su vez, para las empresas de servicios, Second Life puede resultar una herramienta adicional para mostrar a sus clientes prototipos y simulaciones de proyectos en marcha.

Por lo tanto, es probable que el éxito o fracaso de las empresas dentro del este mundo virtual pase por el encontrar estas vetas y oportunidades que la interoperabilidad a través de la tecnología en 3D ofrece y, una vez descubiertas, hallar el modo de explotarlas al máximo.

Conclusión de un Sabio anónimo

2008-07-08T10:54:00.002-03:00

"Como la velocidad de la luz es mayor que la del sonido, ciertas personas parecen brillantes antes... de que escuchemos las pelotudeces que dicen."

Edicion en español: :D
"Como la velocidad de la luz es mayor que la del sonido, ciertas personas parecen brillantes antes... de que escuchemos las gilipolleces que dicen."

Inteligencia interconectada en red, era de oportunidades

2008-03-05T07:32:00.005-02:00

No es sólo la interconexión en red de la tecnología, sino de la de los seres humanos mediante la tecnología. No es una era de maquinas inteligentes, sino de seres humanos que, mediante redes, combinan su inteligencia, conocimiento y creatividad para conseguir avances en la creación de riqueza y el desarrollo social.

Éste cambio esencial en el modo de canalizar la capacidad de innovación y creación de valor que tienen las empresas, la oleada de colaboración masiva ofrece enormes oportunidades. Las empresas pueden salir de sus cuatro paredes para sembrar las semillas de la innovación y recoger una abundante cosecha. De hecho, las empresas que entablan unas relaciones ágiles y basadas en la confianza con colaboradores externos están bien posicionadas para construir unos ecosistemas empresariales muy activos que crean valor con mayor eficacia que las empresas organizadas jerárquicamente.

Esta nueva forma de innovación y creación de valor se denomina producción entre iguales y describe lo que ocurre cuando masas de personas y empresas colaboran abiertamente para potenciar la innovación y el crecimiento en sus sectores. En su forma más pura, constituye una manera de producir bienes y servicios basada completamente en la autoorganización y en comunidades igualitarias de individuos que se unen de forma voluntaria para producir un resultado compartido. En realidad, la producción entre iguales combina elementos de jerarquía y autoorganización, y se fundamenta en principios meritocraticos de organización; en otras palabras, los miembros más cualificados y con más experiencia asumen el liderazgo y ayudan a integrar las aportaciones de la comunidad.

En muchas comunidades de producción entre iguales, las actividades productivas son voluntarias y no reportan beneficios monetarios. Son voluntarias en el sentido de que las personas hacen contribuciones a esas comunidades porque quieren y porque pueden. Nadie ordena a un trabajador que publique un artículo en Wikipedia o que aporte código al sistema operativo Linux. No reportan beneficios monetarios porque la mayoría de los participantes no se les paga por las contribuciones que hacen (al menos, no en forma directa) y los individuos determinan si quieren producir, qué producen y qué cantidad quieren producir. Sin embargo, que la gente no reciba un dinero por participar en producción entre iguales no implica que no se beneficien de otras maneras.

Por lo pronto, la producción entre iguales aprovecha motivaciones voluntarias de una manera que propicia la asignación de la persona adecuada a la tarea adecuada con mayor eficacia que las empresas tradicionales. La razón es la auto selección.

Las personas participan en comunidades de producción entre iguales por una amplia variedad de motivos intrínsecos y de interés propio, ya sea por diversión, altruismo, obtener status dentro de la comunidad para aspirar crecimiento profesional, etc etc.
Este tipo de producción funciona cuando se cumplen tres condiciones mínimas:

El objeto de la producción es información o cultura, una circunstancia que mantiene a un nivel bajo el coste de participación para las personas que contribuyen,
las tareas pueden descomponerse en porciones reducidas que los individuos pueden aportar con pequeños incrementos y con independencia de los demás productores (a saber, entradas de una enciclopedia o componentes de un programa informático) y
el coste de combinar esas porciones para obtener un producto final terminado, incluyendo aquí el liderazgo y los mecanismos de control de calidad, debe ser bajo.

En definitiva, la producción entre iguales funciona porque pueden hacerlo.

Esto es lo que está sucediendo ahora, no sabemos cómo evolucionará, la velocidad y la forma que tomará. De seguro, aportará muchos beneficios para todos y no será una bala de plata universal.

(Nota: Varias partes han sido tomadas del libro Wikinomics de Don Tapscott)

Buenas practicas - lecciones aprendidas en la especificaciones de requerimientos

2008-02-26T10:12:00.002-02:00

Definición
Un requerimiento es la condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo. Es la condición o capacidad que debe satisfacer o poseer un sistema o una componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto [IEEE610].

Recomendaciones / sugerencias para el documento de requerimientos
"La experiencia es la mejor escuela para escribir requerimientos adecuados"

- Wiegers

Oraciones con gramática, sintaxis y puntuación adecuada
Oraciones cortas y directas
Voz activa, imperativos: "el sistema debe hacer algo" y no "algo debe hacerse"
Usar los términos consistentemente y de acuerdo a la definición del glosario
No use sinónimos: no varíe el lenguaje para atraer al lector
Descomponga un requerimiento de alto nivel en detalle suficiente para clarificarlo y eliminar la ambigüedad
Use una forma consistente de redactar: "el sistema debe"+verbo
Especifique la acción que dispara el comportamiento del sistema
Evite el "debería", "podría" y condicionales
En "El usuario debe..." especifique al usuario: "El cajero debe..."
Presente información visualmente, las masas de texto no ayudan
Enfatice la información más importante

Términos ambiguos y su modificación

Término ambiguo	Formas de mejorarlo
aceptable, adecuado	Defina qué constituye la aceptabilidad y cómo el sistema la juzga
tanto como sea practicable	No deje en manos de los desarrolladores determinar qué es practicable.
al menos, como mínimo, no más que, no exceder	Especificar los valores mínimos y máximos aceptables
Entre	Defina si los puntos extremos están o no en el rango
depende de	Describa la naturaleza de la dependencia. ¿Otro sistema provee input a este sistema, debe instalarse otro sistema antes que su sofwtware sea ejecutado o su sistem depende de otro para ejecutar algún cálculo o servicio?
Eficiente	Defina como el sistema usa eficientemente recursos, cuan rápidamente ejecuta operaciones o como es de fácil para la gente usarlo
rápido, veloz	Especifique la mínima velocidad aceptable a la que el sistema ejecuta alguna acción
Flexible	Describa las formas en la que el sistema debe cambiar en respuesta a condiciones cambiantes o necesidades del negocio
mejorado, mejor, más rápido, superior	Cuantifique cuanto mejor o más rápido constituye una mejora adecuada en un área funcional específica
incluyendo, incluyendo pero no limitado a, y así sucesivamente, etc. tal como	La lista de ítems debería incluir todas las posibilidades. De otro modo no podría usarse para diseño o testeo
maximice, minimice, optimice	Establezca los valores máximo y mínimo aceptable para algún parámetro
normalmente, idealmente	Describa también el comportamiento del sistema bajo condiciones anormales o no-ideales
Opcionalmente	Clarifique si se trata de una opción del sistema, del usuario o del desarrollador
razonable, cuando es necesario, donde sea apropiado	Explique como se produce este juicio
Robusto	Defina como el sistema maneja las excepciones y responde a condiciones operacionales no esperadas
transparente, suave, grácil	Traduzca las expectativas del usuario en caracterísrticas observables del producto
Varios	Establezca cuantos o proveea las cotas mínima y máxima del rango
no debería	Establezca los requerimientos positivos, diciendo que hará el sistema
estado del arte	Defina qué significa
Suficiente	Explique con cuanto de algo se establece la suficiencia
soporte, disponible	Defina exactamente que funciones debe ejecutar el sistema que soporten alguna capacidad
Amistoso, fácil, simple	Describa las características del sistema que alcanzarán las necesidades de uso del usuario y las expectativas de usabilidad

Características de una buena especificación de requerimientos - factores de calidad de una especificación de requerimientos

Correcta
No ambigua
Completa
Consistente
Rankeada / Clasificacion por importancia
Verificable
Modificable
Traceable
Independiente del diseño
Concisa / Breve
Organizada
Anotada

Correcta
Una especificación de requerimientos es correcta "sí y sólo si todo requerimiento formular en ella es uno que el software debe satisfacer"

No ambigua
Una especificación de requerimientos no es ambigua "sí y sólo si todo requerimiento formulado en ella tiene una sola interpretación".
Ello requiere que al menos cada característica del producto final se describa con un único término.
Debe evitarse toda afirmación ambigua:
"Todos los clientes tienen el mismo campo de control"
"Todos los archivos son controlados por un bloque de control de archivo"
El lenguaje natural es fuente de ambigüedades.

Completa
Una especificación de requerimientos es completa "sí y sólo si incluye los siguientes elementos:
Todos los requerimientos significativos que impone al software
Todas las respuestas del software a todas las clases posibles de inputs
Todas las etiquetas y referencias a las figuras, tablas y diagramas de la especificación de requerimiento y las definiciones de los términos y unidades de medida"
Este atributo es el más difícil de definir y detectar violaciones, por lo que hay que dedicarle tiempo y trabajar a conciencia.

Consistente
(Hablamos de consistencia interna)
Una especificación de requerimientos es internamente consistente sí y sólo si ningún subconjunto de requerimientos está en conflicto.
Tipos de inconsistencias
Comportamiento conflictivo: dos partes especifican diferentes y conflictivos: estímulos para inducir una respuesta, respuestas a un mismo estímulo y condición.
Términos conflictivos: dos términos diferentes se utilizan para definir lo mismo
Características conflictivas: dos partes requieren rasgos contradictorios
Inconsistencia temporal: dos partes requieren comportamientos temporales contradictorios.

Rankeada / Clasificacion por importancia
Que cada requerimiento tenga una identificación que indica la importancia. Se los puede clasificar, por ejemplo, en "Esenciales" (el software no es aceptable sin éstos), "Condicionales" (pueden mejorar el software, pero no es inaceptable si está ausente) u "Opcionales" (esa función puede o no estar presente).
Que cada requerimiento tenga una identificación de la estabilidad. La estabilidad se puede expresar en términos del número de cambios que se esperan.

Verificable
Todo requerimiento incluido en ella es "verificable", es decir que exista un proceso finito y efectivo en costo con el que chequear que el sistema a construir satisface el requerimiento.
En general los requerimientos ambiguos no son verificables.
Ejemplos de requerimientos no verificables:
- El producto debe trabajar bien
- El producto debería tener una buena interfase
- El programa no debe entrar nunca en un loop infinito
- El output del programa debe estar habitualmente dentro de los 10 segundos
Ejemplos de requerimientos verificables
- A partir de producido el evento X, se obtendrá el output del proceso: debe estar dentro de los 20 segundos el 60% de las transacciones y dentro de los 30 segundos el 99% de las transacciones.
- Algunas de las fuentes de no verificabilidad son las ambigüedades, problemas no resolubles y cantidades no medibles.

Modificable
Cualquier cambio puede hacerse: fácilmente, manteniendo la "completitud" y consistentemente.
Requiere tener una organización coherente y fácil de usar, no ser redundante.

Traceable / Rastreable
Si es claro el origen de cada requerimiento y facilita la referencia de cada requerimiento en futuros desarrollos o mejoras de la documentación.
Tipos de rastreabilidad: hacia delante y hacia atrás.
Beneficios:
- Importancia en operaciones y mantenimiento
- Claridad del origen de cada requerimiento
- Facilita negociar los requerimientos
- Facilita referenciar cada requerimiento individual establecido en la especificación de requerimientos

Independiente del diseño
No debe implicar una arquitectura específica de software o algoritmo, dado que no se debe limitar a esta instancia de una única alternativa de diseño. Hay excepciones aceptables.

Concisa / Breve
A igualdad de cualidades, la mejor es la mas corta

Organizada
Una especificación de requerimientos es organizada si los requerimientos que contiene son fácilmente localizables

Anotada
Las anotaciones a una especificación de requerimientos proveen guía al desarrollo de la organización del documento. Hay dos casos de anotaciones requeridas: necesidad y estabilidad

Tipos de requerimientos según las capacidades o características

Necesidades: Capacidades o características requeridas al sistema de software para resolver el problema. Posibles formas:
Funcionalidad
Comportamiento del sistema
Performance, tiempo de respuesta
Necesidades operacionales
Características de las interfaces de hw y sw.

Deseos: Capacidades o características de un sistema de software deseadas por los stakeholders, no son imprescindibles para resolver el problema. Posibles formas:
Funcionalidad extra
Comportamientos específicos del sistema
Características de la interfase del usuario
Algoritmos particulares

Expectativas: Capacidades o características del sistema de software esperadas por los stakeholders. A menudo no explícitas, y por ello se pierden fácilmente. Posibles formas:
Aspectos específicos del dominio, funcionalidad
Confiabilidad
Características de la interfase con el usuario
Características de performance

Referencias
[IEEE610] Definición IEEE-Std-610 (1990)

Snoop Update 08 - Evento para desarrolladores (Argentina)

2008-02-25T09:57:00.001-02:00

El 16 de abril de 2008 en el Paseo La Plaza (Buenos Aires, Argentina) se realizará uno de los eventos mas importantes de Argentina para desarrolladores y técnicos. El evento tiene como objetivo difundir los últimos avances en la tecnología de Software. Algunos motivos por los que vale la pena asistir al evento:

Tiene contenidos especializados.
Las presentaciones no responden a un fabricante de software en particular (son “agnósticas”)
Esta pensado para transmitir conocimiento.
Los contenidos son de uso práctico. Contenidos específicos y de utilidad práctica.
Brinda capacitación a los asistentes.
Será acorde a la realidad del mercado local (Argentina)
Sesiones paralelas de tecnología y desarrollo a cargo de los líderes y personalidades de la industria.
Contarán con personalidades de reconocimiento internacional, como en los eventos anteriores.
Y no menos importante, el evento es Gratuito, solo tienes que registrarte en su Web.

En paralelo con este evento, se está organizando el UPDATE 4 CIO'S, un espacio en donde se expone cómo la tecnología de la información satisface las necesidades actuales de los negocios, a través de flexibilidad y adaptación. Esta conferencia se reunirán los referentes de la industria para compartir sus experiencias sobre las últimas tendencias del mercado de IT. Mas información: Snoop Update 08

Practicas ágiles en contextos distribuidos (Parte 2)

2008-02-24T00:50:00.005-02:00

Introducción

En la entrega anterior se presentó cómo y porqué las metodologías ágiles y las prácticas relacionadas, pueden ser de ayuda en los proyectos offshore, donde el desarrollo está ubicado en países donde los costos suelen ser menores. En esta entrega completamos las prácticas y lecciones aprendidas.

Best practices para la gestión de proyectos Offshore

En la entrega anterior se presentaron las prácticas de "Distributed Continuou

s Integration", "Script Test: Ayudar a comprender los requerimientos", "Bug-fixing first" y "Wiki". A continuación se explicarán las siguientes:

Múltiples vías de comunicación
Embajadores
Nearshore Pilot
Tutorial + FAQ = Documentación on-deman
Simulación de ambiente
Gestión del Team
Regular Short Status Meeting & Short Iterartions
Nosotros!
Proceso de aceptación
Diferencias de zona horaria

Múltiples vías de comunicación

Al trabajar de forma remota, los pequeños errores de entendimiento rápidamente se transforman en grandes problemas.

En los equipos de desarrollo distribuido, los responsables deben prestar atención a las prácticas de comunicación, que, por lo general, omiten sin consecuencias negativas en el desarrollo local. Es muy importante emplear una modalidad efectiva de comunicación, y disponer de diferentes tipos de canales.

Hoy en día, existen gran cantidad de herramientas de comunicación que pueden utilizarse en los proyectos offshore, pero la más habitual, y también la más eficaz, en la comunicación persona a persona es la mensajería instantánea (MSN Messenger, Yahoo Messenger, GTalk, etc.), que permite hacer preguntas y respuesta de un modo veloz.

Existen otras opciones, como las conferencias telefónicas, indispensables para las comunicaciones de grupos, o para cuando la información que se necesita es mucha; o las videoconferencias, menos utilizadas.

En lo que se refiere a la comunicación escrita, el correo electrónico es el más empleado, aunque es fundamental el uso de la wiki, para propiciar el ambiente colaborativo, publicando toda la información que puede resultar útil al equipo.

El teléfono debe ser utilizado sin problemas y sin que los costos cohíban su uso por parte de los integrantes del equipo. Actualmente, gracias al avance tecnológico, con el Protocolo de Voz sobre Internet (VoIP) se reducen considerablemente los costos de la comunicación "verbal".

Entonces la combinación de estos dos medios mitiga ampliamente los efectos de la distancia. En una conversación, cuando hay problemas de comprensión, si una cosa no se entiende por voz, se lo escribe!

Cada canal de comunicación debe ser usado en el momento necesario a fin de garantizar la máxima cohesión de todo el equipo.

Embajadores

Los responsables de los proyectos deben tratar de construir relaciones humanas personales dentro de los equipos. Ninguna herramienta de comunicación, es mejor que una linda visita.

Tanto al inicio del proyecto, como de forma regular (cada 6 u 8 semanas), resulta muy útil que representantes de los equipos mantengan alguna reunión "cara a cara".

La práctica ambassador (embajadores) prevé un intercambio recíproco de embajadores de las dos partes.

Los embajadores pueden ser los mismos project leaders, o arquitectos y/o desarrolladores, en función del contexto y de la razón de la visita.

Esto permite conocerse mejor, entender el contexto recíproco, el modo de trabajar y posiblemente detectar mejoras en el proceso y/o comunicaciones.

Nearshore Pilot

Esta práctica, cuando estructuralmente es posible, prevé una prueba piloto del proceso de externalización en nearshore de una parte de la aplicación, antes de pasar todo a offshore.

La elección de una aplicación piloto que posea una importancia empresarial de grado bajo o medio limitará los efectos de cualquier problema inicial que pueda surgir con el proceso de externalización offshore. Cuando este proceso se haya consolidado, también se puede considerar la posibilidad de llevar a cabo otros proyectos offshore sin pasar por esta prueba.

En síntesis, la prueba piloto permite una mayor facilidad de startup, setup y tunning del proceso que cuando se pretende hacerlo directamente en offshore.

Tutorial + FAQ = Documentación on demand

En función del contexto del proyecto, hay diferentes tipos de documentación que son muy útiles disponer para que los desarrolladores de offshore se familiaricen con el producto a extender o modificar. Ejemplos de los tutoriales a los que se hace referencia van desde pequeños documentos específicos del negocio que deban aprender, hasta las reglas de codificación que deben emplearse para el proyecto.

Cuando el equipo offshore reside en un país donde se habla otro idioma, hay que tener en cuenta la traducción de la documentación. Este paso "teóricamente" obvio, a veces no es tenido en cuenta en la planificación. Además hay que considerar el caso en el cual escasea, es insuficiente y/o falta, entonces la primera actividad es hacerla, y después realizar la traducción.

La documentación así traducida permitirá el start-up del equipo offshore.

Para ayudar o agilizar la toma de conocimiento del software del proyecto, en algunas circunstancias es útil disponer de una demo (prototipo) y/o tutorial práctico.

El eventual "gap de know how" entre los dos niveles de documentación puede ser mitigado en modo colaborativo e incremental mediante la creación sobre la Wiki de una sección de FAQ (Frequently Asked Questions).

Cada pregunta por parte de un miembro del team offshore debe ser escrita en la Wiki y tener la correspondiente respuesta del equipo onsite.

Si se aplica en modo riguroso y continuo, la práctica trae en modo natural e incremental una actualización sistemática de la documentación y reducida ad hoc por las exigencias del team offshore.

Los "enemigos" de esta practica son el uso no disciplinado de las herramientas como la mensajeria instantánea y el teléfono, donde la información, una vez "consumida" y no publicada en la Wiki es perdida, por lo que se debe concientizar su uso.

Simulación de ambiente

Cuando un desarrollo se realiza en offshore, en muchas ocasiones el proyecto debe interactúar con otros sistemas y/o fuentes de datos. Para ello es necesario disponer de una buena conectividad y utilizar canales seguros para mantener la seguridad e integridad de los datos que se transmiten.

Figura 5 - Aplicaciones offshore que acceden a datos onsite vía VPN

Esto requiere el acceso por parte del equipo offshore a los data store onsite mediante una Virtual Private Network (VPN), es decir una línea de comunicación dedicada virtualmente.

Una VPN es una red privada que utiliza un medio de transmisión público y compartido como puede ser por ejemplo Internet. Los mensajes de la VPN transitan sobre la red pública oportunamente cifrados y mediante protocolos seguros como IP Security, PPTP, etc.

Es fundamental tener en cuenta las posibles indisponibilidades de la red y/o de las eventuales carencias de calidad de conexión. Se necesita hacer mitigar estos inconvenientes, de modo que no afecten, o afecten lo menos posible, el trabajo offshore.

Figura 6 - Local DB + Host Mock + Security Mock

Una alternativa es la simulación de los ambientes (Mock Environment). A continuación se presentan algunas posibles prácticas:

Local DB

Para las aplicaciones en las cuales es necesario recuperar datos de una BD, sería acertado replicar la base, y que el equipo offshore tenga su propia base donde acceder. Será una tarea del equipo onsite construir las DLL de definiciones y los relativos scripts SQL para su carga (populate). Esto permite al team offshore trabajar en forma independiente del ambiente onsite.

Host Mock

La capa de integración debe "simularse" (loopback locale), fingiendo el acceso al host y restituyendo los datos de test oportunamente configurados.

De esta manera es posible desarrollar las partes de la aplicación, sin necesidad de acceder al host. Es importante que tal operación se realice mediante configuraciones y de ningún modo programado (hard code).

Security Mock

En ciertos casos es necesario disponer de un Security Mock, es decir una "seguridad fingida", que permita la ejecución de la aplicación sin tener que validar la seguridad definida en el ambiente del cliente.

Este caso puede considerarse, como un caso particular del anterior. En cierto modo, cuando se quiere que la aplicación que se esta desarrollando contemple directivas de seguridad (por ejemplo permisos de acceso), y es necesario consultar el esquema de seguridad (cualquiera fuere y se encuentre fuera del alcance del proyecto), entonces se deben poner los controles en forma de configuración (no programático, hard code) para su simulación durante el período de desarrollo.

Gestión del Team

Uno de los primeros puntos que deben analizarse es distribución entre los equipos offshore y los onsite. Ciertamente, no resulta fácil establecer una regla general. Se estima que una buena forma de repartirlos es un 30% local y un 70% offshore. Esto no quiere dar por regla que estos porcentuales son los mas utilizados, como siempre todo depende del contexto y del proyecto, por ejemplo si se quiere implementar una solución de integración, en el que el aspecto funcional tiene gran importancia, el tamaño del equipo onsite debería aumentar, por ejemplo 40/60.

Por otro lado, en un proyecto (sobretodo offshore) no es una buena practica que el líder del proyecto "local" gestione directamente los recursos offshore.

Es conveniente que la estructura organizativa prevea que el Project Leader onsite sea ayudado por un Offshore Team Leader para la coordinación de los desarrolladores.

El Offshore Team Leader resulta una especie de "Proxy" del Onsite Project Leader, ayudándolo a entender / relevar / comunicar / asistir frente a eventuales problemas del proyecto (retrasos, incomprensiones, errores, etc.).

Figura 7 - Gestión del team

Por otro lado, se recomienda no relegar los equipos offshore meramente a las funciones de desarrollo, sino que se aconseja implicarlos en otras actividades, esto garantiza una comunicación más fluida, una mayor motivación y, además, una alta productividad, ya que se reduce la dependencia de los equipos locales. De la misma forma también es necesario balancear los roles de los equipos, un "anti-pattern" en tal sentido es, por ejemplo, tener un solo "Gurú" de un lado, dificultando el crecimiento del team del otro.

La creación de figuras análogas ayuda a crear una ambiente de trabajo colaborativo y a evitar una actitud de superioridad por parte de uno u otro equipo.

Figura 8 - Mismos roles en ambos lados

Regular Short Status Meeting & Short Iterartions

Las metodologías ágiles promueven regularmente reuniones breves para todo el equipo de desarrollo (scrums en Scrum, stand-up meeting en XP, etc.).

Esto es muy importante también en un proyecto offshore en el cual se necesita tener en cuenta además de la distancia física, las diferencias horarias.

Se necesita que la reunión de realice en un horario que tenga en cuenta las respectivas exigencias del trabajo (por parte de cada team).

Por otro lado es importante también subdividir el proyecto en iteraciones breves.

Tener hitos cercanos permite tener controles frecuentes y, relevar y gestionar primero cuantos errores y/o incomprensiones surgieran, prevenir es mejor que curar!

Nosotros!

La parte remota del grupo no debe ser vista por la parte onsite como "los que desarrollan", y de la misma forma, el equipo onsite no debe verse por parte del equipo offshore como "los que definen y controlan". Si bien la separación de roles y actividades existe, debe mantenerse un clima de cooperación con la mayor cohesión posible. Tratar que los equipos onsite y offshore, hablen siempre de "nosotros" (sin importar la ubicación física donde se encuentren, y no hacer diferencia, "ellos y nosotros".

Proceso de aceptación

Uno de las motivaciones principales del offshore es la reducción de costos garantizando un adecuado nivel cualitativo.

Para poder garantizar un adecuado nivel cualitativo es importantísimo tener claro los criterios de aceptación y de mediciones, de tamaño y esfuerzo, del proyecto.

Es recomendable especificar en cada proceso (sobretodo en el ámbito offshore) el proceso de aceptación de los entregables del producto de software antes de entregárselo al cliente.

Por ejemplo, el proceso que se puede aplicar a un proyecto, puede prever el control de la documentación y el código. Para el control de código se aplican los criterios de quality assurance a nivel de audit code, code coverage y test.

A nivel de audit code (código y naming convention) no deben estar presentes errores a nivel ERROR o WARNING en el producto de software.

A nivel de code coverage el porcentaje de cobertura de los test (a nivel de clase, método, statement y bloques) no debe ser inferior al 75%. A nivel de test debe estar presente, en todo momento, un test por cada bug declarado resuelto y deben estar presentes, y documentados, los test relevados y los acceptance test acordados con anticipación.

El procedimiento de aceptación debe ser riguroso y por sobre todo, repetible.

Para esto, una buena práctica es buscar de formalizar los pasos que componen tal procedimiento (por ejemplo, reporte en la Wiki, documento Word, tabla del Excel, etc.).

Diferencias de zona horaria

Administrar el cambio horario no es trivial.

Existen básicamente dos estrategias para manejar las diferencias de zona horaria. La primera es separar a los equipos por actividad, por ejemplo, tener gerentes de producto y de aseguramiento de calidad en la empresa y desarrolladores en el exterior (para describir las funciones principales. No olvidar las recomendaciones expuestas sobre la Gestión del Team). Esta organización permite implementar un ciclo en el que los desarrolladores implementan arreglos y nuevos requisitos mientras sus contrapartes están durmiendo y viceversa. Por ejemplo, con un cambio horario de 4 horas (por ejemplo Argentina y España), cuando el equipo argentino inicia a trabajar, el equipo español está a la mitad de la jornada de trabajo (y posiblemente en el break del almuerzo).

De un modo pragmático, se necesita buscar subdividir la jornada del equipo onsite, dedicando la primera parte para gestionar la actividad y crear elementos útiles para el team offshore para la tarde, y la segunda a seguir/colaborar con el equipo offshore.

El segundo enfoque es dividir los proyectos en bloques y tratar de asignar cada bloque a una ubicación, delegando la mayor cantidad de funciones posibles a esta ubicación. El segundo enfoque obliga a una mejor comunicación y por lo tanto sirve mejor al desarrollo ágil, pero ambos funcionan y muchas veces no existe otra opción.

Si bien es sencillo decirlo, no es propiamente trivial llevarlo a la práctica.

Conclusiones

Seguramente la gestión de un proyecto offshore requiera elevar la competencia de proyect management para buscar y gestionar procesos adaptados a los alcances prefijados: son de hecho diversos factores que pueden ralentar u obstaculizar el correcto desarrollo del proyecto, afectando los beneficios económicos y de escalabilidad ligados al desarrollo offshore.

El offshore introduce costos y riesgos extras, respecto a una gestión de proyecto onsite.

La posibilidad de miscommunication y/o misunderstanding en un proceso offshore es superior (distancia, diferencias horarias, cultura, idioma, etc.) y se necesita atenuar con rigor (aun mas rigor que aquel que deberíamos en un proyecto onsite) con el empleo de las practicas explicadas, con el fin de minimizar tales riesgos.

Es necesario ser buenos mediadores para sobrepasar y mitigar las eventuales dificultades del idioma y la cultura; además, hay que tener la actitud justa y una buena dosis de flexibilidad.

Es importante tener bien presente la necesidad de tener una buena comunicación, también desde un punto de vista tecnológico, previendo una buena conectividad (conexión VPN, línea telefónica, etc.) y utilizando las herramientas disponibles.

En este artículo se han presentado algunas importantes prácticas y lecciones aprendidas, útiles para la gestión de procesos offshore, tomado de la literatura actual y nuestra experiencia, en Snoop Consulting.

Referencias

[Brooks, 1987] Frederick P. Brooks, Jr., "No silver bullet: Essence and accidents of software engineering", Computer, vol. 15, no. 1, pp. 10-18, Abril 1987.
[DXP] Michael Kircher, Prashant Jain, Angelo Corsaro, David Levine. "Distributed eXtreme Programming". Second International Conference on eXtreme Programming and Agile Processes in Software Engineering - XP2001. Cagliari, Sardinia, Italy. Mayo 2001.
[Fowler, 2002] Martin Fowler, Matthew Foemmel. "Continuous Integration". ThoughtWorks Inc, 2002. (http://www.martinfowler.com/articles/continuousIntegration.html)
[Fowler, 2006] Martin Fowler. "Using an Agile Software Process with Offshore Development". Última actualización Julio 2006. (http://www.martinfowler.com/articles/agileOffshore.html)
[Rossini, 2006] S. Rossini, "Le metodologie agili e i progetti offshore" MokaByte 108 Junio 2006

Practicas ágiles en contextos distribuidos (Parte 1)

2008-02-24T00:41:00.005-02:00

Introducción

En este artículo veremos cómo y porqué las metodologías ágiles y las prácticas relacionadas, pueden ser de ayuda en los proyectos offshore, donde el desarrollo está ubicado en países donde los costos suelen ser menores.

En primer lugar se presenta una breve introducción a las metodologías tradicionales y a las ágiles; a continuación se explicará en qué consiste un proyecto offshore, junto a sus modos de contratación y dificultades existentes, en comparación a los proyectos onsite; para seguir con una reseña de los métodos ágiles adaptados a este contexto; y finalizar con la descripción de las prácticas ágiles y lecciones aprendidas útiles para la gestión de procesos offshore.

Metodologías tradicionales y ágiles, mejores prácticas

Una metodología de desarrollo es un la conjunción de métodos que especifican quién debe hacer qué cosa, cuándo debe hacerse, estableciendo un conjunto de roles (el quién), actividades (la cosa) y un ciclo de vida que establece las diferentes fases.

El desarrollo de software es riesgoso y difícil de controlar, más aún en contextos offshore. Prueba de ello es que existen muchas metodologías que inciden en aspectos del proceso de desarrollo. Por una parte tenemos aquellas más “tradicionales”, que llevan asociado un marcado énfasis en el control del proceso, mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema tradicional para abordar el desarrollo de software, ha demostrado ser efectivo y necesario en proyectos de gran envergadura (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales, donde las necesidades de los clientes son muy cambiantes, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad.

Bajo este escenario, ha surgido una corriente en la industria del software que considera que las necesidades de los clientes son muy cambiantes. En pos de esto surgen metodologías que parecen contradecir la visión tradicional, por estar especialmente orientadas para proyectos pequeños, con plazos reducidos, requisitos volátiles, y/o basados en nuevas tecnologías, por lo que las metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación, que a pesar de ello, no renuncia a las prácticas esenciales para asegurar la calidad del producto.

Figura 1 – Prácticas ágiles “transversales” a las metodologías

Los métodos ágiles más conocidos y empleados son: eXtreme Programming, Scrum, Crystal Methods, Feature Driven Development, Dynamic Systems Development Method, Adaptive Software Development.

Lo que estos métodos tienen en común es su modelo de desarrollo incremental (pequeñas entregas con ciclos rápidos), cooperativo (desarrolladores y usuarios trabajan juntos en estrecha comunicación), directo (el método es simple y fácil de aprender) y adaptativo (capaz de incorporar los cambios). Las claves de los métodos ágiles son la velocidad y la simplicidad. De acuerdo con ello, los equipos de trabajo se concentran en obtener lo antes posible una pieza útil que implemente sólo lo que sea más urgente; la prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software que le aporte un valor. En este momento se espera el feedback del cliente y se dan la bienvenida a los cambios solicitados, interpretándolos como un avance en la comprensión y luego satisfacción del cliente.

Por lo dicho podemos concluir que en las metodologías tradicionales, en primer lugar se estudian bien los requisitos del producto para después estimar y planificar las actividades y los recursos necesarios para planificar su ejecución. Y en las metodologías ágiles, por su carácter adaptativo, el producto es realizado progresivamente, entregando partes del software totalmente funcionales en cada una de sus iteraciones, considerando en forma natural los ajustes que surgieran en el transcurso del tiempo.

La gestión de los procesos de desarrollo, sin un adecuado soporte metodológico, llevará a costos y elevados riesgos de gestión, sobretodo si se aplican a proyectos de gran envergadura.

Está de más decir que en la práctica, no existe un proceso de desarrollo universal, aplicable a todo proyecto [Brooks, 1987]. Las características del equipo de desarrollo, el dominio de aplicación, el tipo de contrato, la complejidad y envergadura del proyecto, etc., todos estos factores hacen necesario adaptar nuestra metodología de desarrollo.

Existen contextos en los que el uso de procesos de desarrollo de software ágil permanece cuestionable. Algunos ejemplos son los grandes equipos de desarrollo (más de 20 personas trabajando en un proyecto independiente), sistemas en los que la predicción es primordial (aplicaciones de vida crítica) y los entornos burocráticos. No se analizarán la aplicación de las prácticas en estos contextos. Igualmente, es posible utilizar las Best Practices en un modo integrado y transversal a la metodología en si misma que se emplee.

Offshore

La presión por reducir costes y concentrarse en las actividades de mayor rendimiento de la inversión (ROI), ha obligado a las empresas a buscar soluciones para alcanzar este objetivo, manteniendo los niveles de servicio actuales. Una de estas fórmulas, conocida como offshore, es la externalización de servicios a países más económicos, como la Argentina.

El proceso de externalización del proceso de desarrollo toma el nombre de Business Process Outsourcing (BPO). Que es la relocalización de funciones de procesos de negocios en proveedores de servicios, ya sea interno o externo a la empresa. BPO en español se traduce como "Externalización de Procesos de Negocios". Tal término fue concebido a mediados de los años 90 y toman popularidad en los últimos años, gracias a la explosión de los negocios de Internet.

Las principales ventajas del offshore son:

Nivel de servicios y calidad igual o superior, acceso a recursos inmediatamente disponibles y altamente cualificados. Generalmente las empresas que brindan servicios de offshoring invierten, para ser competitivas, en nuevas tecnologías, tanto de Software como de Hardware

Disminución real de los costes, especialmente en actividades de trabajo intenso.

Price stability: estabilidad del costo del proyecto.
Escalabilidad

Turnos de noche y velocidad en la entrega.

Oportunidad para que las empresas se centren en competencias clave, traspasando las actividades de menor importancia a terceros.

New business Partner: el offshore lleva a tener nuevos business Partners

Figura 2 – Equipos offshore y onsite

Existen distintas tipologías de proyectos offshore, principalmente podemos dividirlas en dos categorías:

Fix Price & Time Box (Hitos): proyecto de precio fijo donde el proyecto de refiere a una oferta “llave en mano”, definiendo los objetivos y alcances del proyecto y el equipo offshore debe entregar el trabajo completo al cliente. Para el cliente el proceso de desarrollo lo ve como un proceso de caja negra.
Collaborative projects: proyectos colaborativos, en los cuales el equipo offshore colabora con el desarrollo del proyecto en forma conjunta con el equipo onsite.

Offshore: Consecuencias

Lo primero que debe considerarse en el caso de un proyecto offshore, en base a los principales principios de las metodologías ágiles, es que el principio de la proximidad física (face-to-face) “desaparece”.

Con la dispersión física de las personas involucradas en el proyecto, la aplicación de las prácticas ágiles fundamentales, como es el stand-up meeting y la convivencia del mismo espacio de trabajo, se tornan, en principio, inaplicables.

En un proyecto offshore la comunicación se encuentra afectada a causa de:

Dispersión geográfica
Cambio horario
Idioma
Diferencias culturales
Calidad tecnológica de la conectividad

¿Offshore: pueden ayudar las practicas ágiles?

En la sección anterior se listaron las principales dificultades que la externalización offshore conlleva, la pregunta fundamental resulta por tanto, cómo y si las practicas ágiles pueden ser de ayuda al proceso de desarrollo.

La adopción creciente de procesos en offshore, y la adopción de metodologías ágiles para el caso de equipos distribuidos en un contexto internacional ha llevado a las mismas metodologías ágiles a “adaptarse” (Agile Offshore Software Development o en el caso del mismo XP con el Distributed eXtreme Programming [DXP].

En el caso de AOSD, se basa en las Best Practices de XP (Continuous Integration, Strong Quality, Short iterations, etc.), RUP (notación UML para formalizar las especificaciones) y Open Source (Herramientas colaborativas y practicas asociadas (JUnit, NUnit, HttpUnit, etc.), todo esto aplicado en el contexto de proyectos offshore.

Distributed Extreme Programming (DXP)

DXP es una adaptación de XP, adecuado a la gestión de proyectos offshore.

El foco de la metodología DXP es “corregir / adaptar” la gestión de las practicas que requerían el acercamiento físico y que debían adaptarse al contexto de los proyectos offshore.

Practicas XP	Cercania fisica	Practicas DXP
Planning game	Si	Distributed Planning Game
Continuous Integration	Si	Distributed Continuous Integration
On-Site Customer	Si	Virtual On-Site Customer
Pair programming	Si	Remote Pair Programming
Small Releases	No
Metaphor	No
Simple design	No
Testing	No
Refactoring	No
Collective ownership	No
40-hour week	No
Coding Standards	No

El esfuerzo para amoldar la metodología fue principalmente destinado a las practicas de Planning game, Continuous Integration, On-Site Customer y Pair programming, para buscar adaptarlas al contexto distribuido, que deben ser eficientes y colaborativas.

Con este fin aparecieron herramientas que minimizan la sensación de “alejamiento” físico, y “virtualizan” el acercamiento de las personas.

DXP introduce un nuevo valor al proceso, la paciencia. La paciencia y la tolerancia, la paciencia frente a los problemas tecnológicos (por ejemplo la baja calidad de las conexiones, problemas en las redes, ruido en las comunicaciones telefónicas, etc.) y la tolerancia por las diferencias culturales.

Best practices para la gestión de proyectos Offshore

A continuación se describirán algunas prácticas y lecciones aprendidas, útiles para la gestión de los procesos offshore.

Éstas prácticas / lecciones aprendidas son el producto de la experiencia que hemos recolectado en Snoop Consulting en los últimos años, combinada con la literatura de referencia (por ejemplo [Fowler, 2006], [Rossini, 2006]) que específicamente en este tema no abunda.

Las prácticas y las lecciones aprendidas que se explicarán en esta primer parte del artículo son las siguientes:

Distributed Continuous Integration
Script Test: Ayudar a comprender los requerimientos
Bug-fixing first
Wiki

En la próxima entrega se explicarán:

Múltiples vías de comunicación
Embajadores
Nearshore Pilot
Tutorial + FAQ = Documentación on-deman
Simulación de ambiente
Gestión del Team
Regular Short Status Meeting & Short Iterartions
Nosotros!
Proceso de aceptación
Diferencias de zona horaria

Distributed Continuous Integration

La Integración Continua (Continuous Integration) es una práctica de XP que pone énfasis en el hecho de tener un proceso de construcción y testeo completamente automático, que permita al equipo modificar, compilar y testear un proyecto varias veces en un mismo día.

Todas los integrantes del equipo deben integrar su código con la última versión estable por lo menos una vez al día.

Martin Fowler [Fowler, 2002] afirma que el desarrollo de un proceso disciplinado y automatizado es esencial para un proyecto controlado, el equipo de desarrollo está más preparado para modificar el código cuando sea necesario, debido a la confianza en la identificación y corrección de los errores de integración. Con el proceso de Integración Continua la mayor parte de los bugs de un sistema se manifiestan en el mismo día en el que se integran los módulos intervinientes, reduciendo drásticamente los tiempos para determinar el problema y resolverlo, cada vez que se realiza la integración, los que la hacen deben asegurarse que todas las pruebas se ejecutan correctamente, para que el nuevo código sea incorporado definitivamente.

Hacer builds regularmente permite tener la posibilidad de obtener feedback continuo y actualizaciones del desarrollo offshore. Tal monitoreo permite controlar y seguir el progreso del proyecto, y anticipar eventuales errores y/o discrepancias; nos proporciona indicadores de la evolución real del código.

Existen varias herramientas que ayudan a realizar esta tarea, tal es el caso de Microsoft Team Foundation, CruiseControl, CruiseControl.NET, etc.

La práctica de Integración Continua puede ser también de fundamental ayuda en los procesos Offshore: Integración Continua Distribuida (Distributed Continuous Integration)

Figura 3 - Distributed Continuous Integration

Para la Integración Continua Distribuida es importante tener una muy buena conectividad a fin de evitar las largas esperas en los procesos de construcción (build). Es una buena práctica, en general, que el servidor donde se realizan los build se encuentre cerca del equipo de desarrollo principal, que generalmente es el de offshore.

Por otro lado en los proyectos colaborativos donde no tenemos centralizada la fuerza de trabajo, podemos considerar el hecho de disponer el repositorio de código en cluster.

Script Test: Ayudar a comprender los requerimientos

Cuanto más grande es la distancia, mas ceremonia hay que poner en la comunicación de los requerimientos. Una forma de ayudar a la comprensión de los requerimientos, es comunicar, además, los test de aceptación (Acceptance Test).

Dichos test ayudan a entender mejor el requisito y/o el diseño a implementar, disminuyendo la posibilidad de malos entendidos o incompresibilidad (respecto al requisito), más que a representar un “objetivo concreto” para el desarrollo offshore.

Estos test agilizan a su vez el uso de Test Driven Development (TDD): la práctica de desarrollo guiada por tests.

Siguiendo la practica TDD, se desarrolla en primer lugar el código de testeo de la funcionalidad de interés, y luego el código aplicativo que tal función implementa.

Esta práctica permite:

Aclarar mejor el requisito
Dar al desarrollador offshore un concreto objetivo a conseguir.
Atenuar el uso de TDD en el equipo offshore (RTDD – Remote Test Driven Development)

Esta practica no siempre es posible implementarla, todo depende de cómo este constituido el equipo onsite.

Bug-fixing first

Puede decirse que las dos tareas de desarrollo más comunes son la de corregir bugs e implementar nuevas características. Es muy útil seguir la práctica de comenzar primero por el desarrollo correctivo (corrección de bugs).

La actividad de bug-fixing requiere más lectura de código que desarrollo nuevo, y es una manera óptima de familiarizarse con el producto de software y el proceso metodológico.

Antes de corregir una anomalía se deben revisar uno o más casos de test (test de unidad como por ejemplo JUnit, NUnit o HttpUnit) que pondrán en notoriedad el error a corregir.

El error será considerado solucionado cuando la ejecución del test, desarrollado previamente, resulte exitosa.

TDD permite el desarrollo natural e incremental de una suite de test que permiten por un lado la verificación del código desarrollado, y por el otro, la posibilidad de verificar la no regresión frente a las intervenciones al software.

Wiki

Hay varias formas de compartir información, una de ellas con el uso de Wikis, que por su facilidad de instalar, usar, su esencia colaborativa y que sólo se necesita un browser, es la que empleamos en nuestros proyectos.

Cualquier información común debe ser puesta aquí, información pública del proyecto, como requerimientos, guías de diseño, instrucciones de build, notas del progreso, FAQ, HOW-TO, Best Practices, lecciones aprendidas, Tips&Trices, etc.; cualquier cosa que deba ser escrito para que el equipo tome conocimiento.

Las Wiki, por naturaleza, no son estructuradas; es importante que el equipo la emplee con criterio para mantenerla estructurada y de fácil consulta. Es muy recomendable que alguna persona tenga el rol de “jardinero”, para ir controlando y depurando la información generada. Una Wiki no estructurada, o en la que no se encuentre la información fácilmente, perjudica en gran parte sus beneficios.

Figura 4 - Pantalla de un proyecto en la TikiWiki

Referencias

[Brooks, 1987] Frederick P. Brooks, Jr., "No silver bullet: Essence and accidents of software engineering", Computer, vol. 15, no. 1, pp. 10-18, Abril 1987.

[DXP] Michael Kircher, Prashant Jain, Angelo Corsaro, David Levine. "Distributed eXtreme Programming". Second International Conference on eXtreme Programming and Agile Processes in Software Engineering - XP2001. Cagliari, Sardinia, Italy. Mayo 2001.

[Fowler, 2002] Martin Fowler, Matthew Foemmel. “Continuous Integration”. ThoughtWorks Inc, 2002. (http://www.martinfowler.com/articles/continuousIntegration.html)

[Fowler, 2006] Martin Fowler. “Using an Agile Software Process with Offshore Development”. Última actualización Julio 2006. (http://www.martinfowler.com/articles/agileOffshore.html)

[Rossini, 2006] S. Rossini, "Le metodologie agili e i progetti offshore" MokaByte 108 Junio 2006

Java vs .Net

2008-02-24T00:09:00.002-02:00

By Esteban Lorenzano and Leonardo Miaton (Enero 2007)

El lenguaje Java surgió en 1997 enfocado, fundamentalmente, al creciente mundo de Internet a través de los applets. Sin embargo, no fue hasta que pasó del lado del cliente al del servidor que adquirió verdadera importancia.
Las emergentes tecnologías orientadas a producir contenidos dinámicos (concretamente los “Servlets” y luego los “JSPs” ), permitieron crear un conjunto de componentes para el desarrollo de aplicaciones completas que se ejecutan del lado del servidor, enviando al cliente únicamente el resultado de las operaciones realizadas.
En este sentido, fue fundamental el enfoque original de la plataforma Java: "write once, run anywhere" (‘escribe una vez, corre en cualquier lado’) que permitió que los servidores de aplicaciones Java funcionen en las más variadas infraestructuras. Hay versiones de Java para prácticamente cualquier sistema operaoperativo/hardware actuales (IBM AIX, HP-UX, Solaris, Linux, Windows, etc.)
.NET, por su parte, surgió en 2001 como la respuesta de Microsoft a la creciente popularidad de Java y sus arquitecturas para el desarrollo de aplicaciones empresariales web, beneficiándose de la experiencia de Java, pero añadiéndole características propias. A diferencia de su competidor, el enfoque que .NET sigue, es la interoperabilidad e intercambiabilidad de los lenguajes en los que se escriben las aplicaciones. Es decir: se puede escribir en varios lenguajes, que incluyen C++, Visual Basic, Java y el nuevo lenguaje de Microsoft, C#.
A continuación, basados en el creciente interés del mercado informático, realizaremos un análisis comparativo de las fortalezas y debilidades de ambas, en cuanto a modelo de ejecución y arquitectura de aplicaciones.

Articulo para descargar.

Metodos Agiles y Disciplinados

2008-02-23T23:55:00.002-02:00

By Lionel Barrabino and Leonardo Miaton (2007)

Todas las empresas aspiran a incrementar su competitividad, produciendo más rápido, mejor y con menores costes lo que implica una mejora o evolución continua de sus procesos de desarrollo de software.

En un primer momento las notaciones de modelado y posteriormente las herramientas, pretendieron ser “La Solución" para el éxito en el desarrollo de software. A fines de los noventa había ya gran cantidad de tipos de procesos y modelos. Algunos de los más relevantes eran el modelo en cascada o lineal-secuencial, su variante con fases superpuestas, el de construcción de prototipos, el de desarrollo rápido (RAD), el incremental, el modelo en espiral básico, el de desarrollo concurrente, modelos iterativos o evolutivos (basados en componentes, por ejemplo) y otra gran cantidad de variantes, donde cada una se originaba a partir de la crítica o en la percepción de las limitaciones de otra.

Sin embargo, las expectativas no fueron satisfechas. Esto se debía, en gran medida a que las metodologías de desarrollo no habían evolucionado. Poco sirven las buenas notaciones y herramientas si no se proveen marcos para su aplicación. Así, en los últimos diez años, organismos y corporaciones han desarrollado gran cantidad de estándares de metodologías de desarrollo: Modelo de Madurez de la Capacidad (CMM), derivaciones de ISO9000, BootStrap, TickIt, SDCE, Trillium...

Articulo completo para descargar.

Patterns for Personalized Web Applications

2008-02-23T23:29:00.000-02:00

By Daniel Schwabe, Gustavo Rossi, Juan Danculovic and Leonardo Miaton. Proceedings of EuroPLoP 2001

Abstract: In this paper we present some patterns we mined in Web applications that present some kind of personalized structure or behavior. We first introduce the growing need to include personalization features in Web applications and present a taxonomy for reasoning about design structures for personalization. Finally, we present 4 personalization patterns: Link Personalization, Content Personalization, Structure Personalization and Remote Personalization.
View or download: www.lifia.info.unlp.edu.ar/papers/2001/Schwabe2001b.pdf

Putting Hypermedia Patterns to Work: a Case Study

2008-02-23T23:21:00.000-02:00

By Fernando D. Lyardet, Barbara Mercerat, Leonardo Miaton. (1999)

Abstract: This paper we present an example of a redesign of an existing website using OOHDM methodology and how patterns helped to easily improve a website by correctly identifying the different design issues. Scenario: a government website for small companies program.

View or download: uts.edu.au/~dbl/Hy...etHT99Workshop.pdf