Simplificando los principios de análisis , diseño e implementación de portales. Cercando las necesidades de cada cliente. Afrontando los deseos de los desarrolladores. Luchando por un enfoque ágil arquitectónico.

contenedor Metodologías Ágiles

Bases

Bases

Brqx: 
El objetivo es olvidarnos de todos los modelos usados para crear clases , patrones y objetos de los lenguajes de 3ª y 4ª Generación.

Vamos a incorporar un nuevo nivel de abstracción.

Nos vamos a centrar más en las necesidades del cliente y vamos a intentar hablarle en su mismo lenguaje, es por ello que no vamos a hablar de términos como BBDD o servidor que él no tiene por qué conocer.

Vamos a reinventar la informática con lo ya inventado hace años. A reconducir el desarrollo, a reanimar los proyectos. El objetivo es dejar de una maldita vez de reinventar la rueda.

Presentaremos un modelo de análisis que esté al alcance del usuario / cliente y del desarrollador. Que sea fácil de entender para cualquier persona sea o no del mundo de la informática.

Vamos a mostrar una metodología ágil, y sí, aquí en España para el mundo. Con objeto de reeducar y reconducir los desarrollos del planeta.

Les presento la metodología ágil de desarrollo propuesta por Brqx.

Brqx Arquitecturas - Metodologías Ágiles.

Partida

G1

a.- Efoque Metodologías ágiles

En cualquier intento de análisis siempre hay una base. Siempre debe existir un modelo donde la reflexión continua en el mismo permita optimizarlo, mejorarlo, cambiarlo, eliminarlo.

Esta premisa es un indicio de libertad. Y precisamente el parámetro más importante en un modelo ágil, en un modelo totalmente basado en software libre es ese, libertad.

Esta libertad va acompañada a la participación con "nombre".

Debido a que no hay corporaciones y si las hay sus intenciones no son ni pueden ser las de apropiarse de dicho producto, cualquier aporte al mismo es mundialmente reconocido y personalizado.

Ya no va a ser tu jefe o tu empresa quién se lleve todo tu mérito. Ni tu decano de la Universidad.

Entramos en un modelo que vuelve a premiar la individualidad, pues todos somos distintos y no todos tenemos la misma capacidad.

Es un modelo donde, al contrario de lo que ocurre en una absurda sociedad que nos ha tocado vivir, los intermediarios no tienen valor. Aquí los héroes son los que crean no los que utilizan a esos creadores para revender ese producto.

Sin duda este aspecto requiere un análisis más hondo, pero no es la finalidad de esta web hacer una crítica social.

En su lugar recomendamos visitar http://sociedadactual.com.

Vamos a resumir las palabras : libertad, individualidad, producto. Pero podemos añadir algunas más : cooperación, calidad, sociedad. Todas ellas irán teniendo cabida y su momento en los variopintos e interesantes temas que vamos a tratar de exponer.

G2

b.- Lo único permanente es el cambio. Aportación de Zuttoien

A continuación exponemos la visión de partida de Zuttoien , obtenida de : El desarrollo ágil toma vuelo a la industria.

La premisa, que es la base de la filosofía oriental, se está aplicando al mundo de la computación. Se trata del Desarrollo Ágil de Software, es decir, una manera de programar más liviana y sencilla. En el mundo lleva casi una década y, en la Argentina, se está comenzando a aplicar en los últimos tres años, tiempo suficiente para liderar la iniciativa en el mercado hispanohablante.

“Se entiende como desarrollo ágil de software a un paradigma de desarrollo de software basado en procesos ágiles. Estos procesos de desarrollo, conocidos anteriormente como metodologías livianas, intentan evitar los burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados. Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto”, define Wikipedia.

Nokia y Yahoo son dos de las empresas multinacionales que fueron pioneras en el tema del desarrollo ágil. Impusieron una forma de desarrollar que rápidamente fue adoptada por otras compañías, de igual o mayor peso en la industria, como Microsoft, Siemens, Google, y Sun Microsystems, entre otros. A nivel local, Liveware, Sabre, la filial argentina de Intel y la gerencia de sistemas de la ANSES son algunas de las firmas que están impulsando el cambio de paradigma a la hora de programar.

“El desarrollo ágil de software surgió como respuesta a los problemas del desarrollo tradicional para planear y cumplir con los proyectos. Los resultados de la manera tradicional eran que no se cumplían los plazos, los productos no eran los esperados, los proyectos no terminaban nunca. Entonces, se advertía una diferencia muy grande entre lo que el usuario, el cliente, pagaba y el resultado final que obtenía”, explica a IT Business Diego Fontdevila, docente de la Universidad de Tres de Febrero (UNTREF), impulsor de la movida ágil en Buenos Aires.

G3

c.- Concreciones. Aportación de Zuttoien

A continuación exponemos las concreciones , obtenida de : El desarrollo ágil toma vuelo a la industria.

Una de las maneras de resolver estos problemas es el desarrollo ágil de software que implica no planear ni predecir tanto sino lograr que el proyecto se lleve a cabo y se vayan cumpliendo los plazos de acuerdo a objetivos sencillos", añade Fontdevila.

Como en la filosofía oriental, se trata de ir creando un producto a medida que los cambios, constantes y permanentes, van imponiendo el ritmo del negocio y de la vida de una empresa.

“La idea de este tipo de desarrollo se concentra en dar una respuesta rápida al cliente, cuya necesidad está por encima de lo formal y de ahí se desprenden las distintas herramientas y técnicas de seguimiento de pasos o ideas marco”, expresa, por su parte, Esteban Zuttoien, vicepresidente de Liveware Argentina.

Como en el tai chi chuan o en el yoga, las premisas que mueven el desarrollo ágil se definen entre la concentración, trabajo en equipo, la integración y el cambio. Así las define Fontdevila.

El primer punto es concentrarse en hacer software más que en la documentación sobre cómo hacer software.

El segundo aspecto es recuperar el foco en el trabajo de personas que participan: las máquinas son herramientas pero el trabajo es intelectual de modo que es necesario poner énfasis en la capacidad de la gente”.

El tercer eje es integrar al cliente que va a usar el sistema con el equipo de desarrolladores porque más que un contrato se trata de un trabajo a concretar de manera conjunta. Esto se logra de cerca, es decir, trabajando en el mismo espacio físico.

Y el cuarto punto es tener en cuenta el cambio. En el desarrollo tradicional prima la planificación como garantía para obtener un resultado. Pero el método ágil dice que hay que adaptarse al cambio para satisfacerlo. Eso implica que, cuando se avanza, sigue siendo requisito fundamental analizar y revisar lo hecho para ver si responde al requerimiento del cliente, del negocio”, insiste el académico de la UNTREF.

Mientras, para entender la aplicación a los casos concretos, Zuttoien destaca que “ayuda a las empresas a definir sus objetivos para sus procesos de negocios.

Primero se hace una evaluación del área de Sistemas, de los clientes, de la demanda, que implica a su vez un conjunto de respuestas para dar al cliente. Esto quiere decir también que no hay que usar las mismas herramientas para todos los problemas”.

Y aquí surge una arista que no se debe desconocer. En el desarrollo de software ágil se impone como una nueva manera de programar, más ágil, porque no exige los mismos pasos que el desarrollo tradicional. Pero no es un reemplazo de una metodología por otra lisa y llana sino que hay casos en los que es posible aplicarla y otros, en los que no. Un par de ejemplos servirán para entender este punto.

Una tendencia en la industria del software a nivel local es certificar en CMMi, una especie de diploma de calidad de los procesos de desarrollo.

El ejecutivo de Liveware subraya que “en donde la agilidad se puede aplicar hay que hacerlo, como llegar a certificar en CMMi.

Las metodologías ágiles pueden ayudar a alcanzar ciertos objetivos. O, por ejemplo, si hay que desarrollar una red de personas con un sistema de mensajería. En ambos casos se tratan de desarrollos sencillos donde la metodología ágil aplica sin inconvenientes”.

Pero cuando hay que programar sistemas complejos, como el que procesa la información que surge de un tomógrafo, no hay metodología ágil que valga.

En ese caso, es necesario recurrir al esquema tradicional, donde la documentación, los plazos, representan esfuerzos de trabajo con la posibilidad de que el producto no se termine en tiempo, pero sí en forma.

El problema se centra, en definitiva, en qué construir para cada cosa en particular.

La metodología ágil requiere de una gran disciplina porque por más que no se genere mucha documentación, es fundamental tener orden.

Y sobre este punto es sobre el que hay una gran confusión en el mercado”, añade Zuttoien.

G4

d.- Precios agiles y plazos metódicos. Aportación de Zuttoien

A continuación exponemos la exposición final del valor del desarrollo ágil , obtenida de : El desarrollo ágil toma vuelo a la industria.

¿Es más barato programar con la metodología ágil?

¿Es más rápido terminar un proyecto con este sistema que con el tradicional?

Depende de si la elección por el desarrollo ágil fue correcta o no. “Las metodologías ágiles son más baratas en el sentido de que el foco es más chico. Por ello, no se recomienda aplicar esta modalidad de desarrollo cuando hay grupos de 200 personas distribuidas. Son metodologías más livianas porque hay menos costos de organización -apunta Fontdevila. “Pero requiere aprendizaje, planificación y disciplina”, coincide Zuttoien.

“Lo que no requiere complejidad es más barato. Pero, si se trata de crear un sistema complejo con esta metodología tal vez termine siendo más caro porque el costo del retrabajo es alto, es decir, la implementación rápida implica que haya varias correcciones en el camino”, agrega el vicepresidente de Liveware.

En cuanto al tiempo, los desarrollos bajo este concepto se advierten como más cortos, aunque al final termine demandando casi lo mismo que algo creado según el método tradicional. “Con el desarrollo ágil se entregan cosas identificables cada dos o tres semanas, entonces los resultados se dan en mucho más rápido. La ventaja es que se adapta a los tiempos que hoy exigen en las compañías”, manifiesta.

No obstante, la capacidad de saber en qué momento aplicar qué tipo de metodología será el punto a tener en cuenta para que esta modalidad, en boga, no sea una moda, sino una manera de enriquecer el trabajo de programación local.

G5

e.- Desenfocados. Orientación al Conocimiento. Brqx.

Sin duda este artículo de Esteban Zuttoien y Fontdevila sea de lo mejorcito que se puede encontrar en Internet en relación a Metodologías ágiles.

El enfoque que se hace lo considero "incompleto". Sin duda es un buen punto de partida, y una buena exposición en cuanto a los riesgos existentes y forma de proceder.

Pero el verdadero espíritu de una metodología ágil es la cooperación. La sensación de que el producto no va a depender sólo de nosotros y que ese mismo producto es y debe ser un bien universal.

Es por ello que supera los límites de una empresa, el verdadero éxito de las metodologías ágiles es la orientación de los resultados a un enfoque colaborativo.

Enfatizar los beneficios en la sociedad e indirectamente asociar el éxito de la empresa en los servicios ofrecidos en relación a la implantación y uso de excepcionales productos.

Sea esa mírada al conocimiento compartido la columna vertebral de una metodología ágil.

Improving the Software

Changing the World

Brqx.

Soluciones

G1

a.- Enfoque soluciones. Soluciones actuales.

Hemos iniciado la ruta, se ha presentado los distintos escollos de la misma y ahora debemos encauzar este trepidante viaje haciendo hincapié en los distintos parajes que vamos a encontrar.

Veamos las soluciones en la interminable carrera del software. Ese mismo producto que entre todos debemos certificar.

La idea de una certificación y una arquitectura más ágil es minimizar esfuerzo y recursos en todas las etapas de la arquitectura.

¿ que ocurre si todos certificamos ?

Sin duda es una verdad universal que un trabajo hecho por muchos indirectamente implica una reducción del trabajo realizado por cada uno de esos muchos.

La solución es entonces, un trabajo conjunto entre todos con objeto de buscar un producto que nos aporte esa funcionalidad deseada indirectamente por cada uno de los usuarios de un sistema.

Pero hay más puntos importantes y algo más técnicos donde debemos ahondar.

Veamos la creacción del producto. En esa misma producción hay distintas etapas, etapas de requisitos, etapas de desarrollo, etapas de evaluación o certificación y etapa de usabilidad del mismo.

¿ Qué son los requisitos ?

Palabra algo técnica para la sección, pero debemos hablar de los mismos. Se trata de lo que queremos que haga el sistema.

Y aquí debemos introducir un principio universal con finalidad de simplicidad : "keep it simple, stupid" - Hazlo simple, idiota -.

Es por ello que debemos simplificar y minimizar los requisitos y la forma de expresarlos.

Una vez disponemos de los requisitos, llega la hora de conseguirlos, el proceso de desarrollo. Y sin duda es más facil conseguir un todo si disponemos de las partes.

Ahí entra el modelo de componentes, son las partes que debemos considerar a la hora de crear ese todo, cuanto más reutilización hagamos de esas partes más fácil será crear un todo más acorde a los requisitos indicados.

Por tanto, también debemos minimizar los componentes, de forma que auto-aceptemos componentes funcionales y enfoquemos el problema en la reutilización y adaptación de los mismos unido a un mínimo número de componentes nuevos.

Como partimos de un modelo simple, donde la filosofía es intentar cercar las necesidades de la sociedad y facilitar su entendimiento y su utilización, indirectamente vamos a minimizar los recursos necesarios para el mantenimiento y explotación del modelo.

Sí, es la tercera etapa, el mantenimiento de los sistemas.

Por tanto, resumiendo buscamos este modelo de mínimos y máximos :

1.- Miniminzar requisitos

2.- Minimizar componentes

3.- Minimizar recursos

1.- Maximizar la usabilidad

2.- Maximizar la libertad

3.- Maximizar la calidad

¡¡ Qué palabras más bonitas !!

Este mundo está "re"naciendo.

Eduquémoslo para que sea un gran "adulto".

Brqx.

G2

b.-El Equipo Libre: La confianza en el modelo - Enfoque Arquitecturas Libres

El modelo presentado nos permite sentar las bases de cómo debe ser nuestra elección.

Sin duda nos está enseñando qué no debemos hacer. El objetivo no debe ser coger algo , cambiarlo y no compartirlo. Creerse que dispones de un conocimiento que te da una ventaja competitiva en ese momento.

Es un grave error, pero dispones de la libertad para hacerlo. No quiero entrar en las distintas licencias que igual ni siquiera te permiten hacerlo (GNU GPL , GNU LGPL, etc).

Pongámonos en el peor caso, tienes la posibilidad de cambiar ese contenido.

Partiendo de esa base, es como si consiguieses un buen delantero para tu equipo. Igual hasta tienes suerte y marca un gran tanto. Puede ser. ¿ Pero qué opciones tienes aún así de ganar ese partido de 11 contra 1000 ?

¿ Cuanto tiempo tardará el Equipo Libre en remontarte ese gol ? Crees que esa nueva funcionalidad que estás aportando va a tardar mucho en ser competida , incluso superada por el equipo libre ?

¿ Tan bueno te crees ? ¿ Tan buenos os creéis ? Sinceramente, las respuestas son obvias.

La sociedad ya está cambiando y es hacia una metodología libre donde todo el planeta está a su favor para mejorarla y se mejora compartiendo ese conocimiento.

Y los ganadores somos todos. Pierden los multimillonarios con sus multi-fortunas que serán un poquito más pequeñas.

Ganamos todos, habrá una mejor música, no sólo la que se promocione para venderse. Habrá una mejor medicina, será mas fácil luchar contra el cáncer. Será posible hacer motores más óptimos.

Se minimizará cada vez más las diferencias entre marcas, todos usaran modelos libres, por tanto , todos estarán obligados a sacar lo mejor de cada uno para obtener esa ventaja comparativa.

Pero lo mejor, TODOS TENEMOS OPORTUNIDADES. En el modelo actual, super coorporativista y totalmente globalizado NO HAY OPORTUNIDAD CASI NADIE.

Viva la libertad. Fuera las patentes. Viva el Copyleft.

Copyleft

Cultura Copy Left

G3

c.- Software libre - No es software gratis

Hay un gran incógnita en razón a las ventajas del software libre y los objetivos del modelo.

Casi todo el mundo sólo ve una vertiente, gratis , free, no me cuesta dinero, cualquiera puede conseguirlo.

De esta frase quizás, la palabra más importante es "cualquiera" pues en ese cualquiera está incluidos todos los posibles interesados en mejorarlo.

El software libre no es gratis, si tiene un coste residual su obtención, pero tanto su mantenimiento como su aprendizaje no son gratuitos. Todo tiene su coste.

No quiero entrar a analizar esta situación, pero si indagan un poco verán que los estudios realizados al respecto en cuanto a implantación o no de metodologías libres y propietarias, tienen costes parejos.

Esa no debe ser la baza que incline la balanza hacia el software libre. Nunca lo pretendió.

Es más bien la calidad, la libertad, la capacidad de adaptación, el auto-reconocimiento y la individualidad. Hay muchas más acepciones, pero vamos a cortar aquí para centrarnos mejor en las ya descritas.

La calidad es su principal baza. Cada vez son mejores las aplicaciones libres que las propietarias, cada vez su rendimiento, su funcionalidad es mejor y el factor fundamental es que estos parámetros siempre van en aumento.

La capacidad de adaptación es otro de los factores determinantes a la hora de enfocar una solución, pues es más sencillo cambiar algo cuando lo ves. Se imaginan cambiar la organización de una habitación a oscuras. E incluso saltándose la vigilancia del portero. Es surrealista, mejor hacerlo de día y publicado anteriormente en una revista. Eso es libertad.

Y ese parámetro es otra de las grandes bazas y a su vez de los grandes peligros del software libre y donde debe siempre primar la actuación conjunta de toda la comunidad.

Esa libertad nos permite si no nos gusta lo actual cogerlo y cambiarlo. El problema de esta actitud es que si luego se mejora lo que hemos cambiado puede implicar un trabajo perdido. Es por ello que debe primar la colaboración y en vez de cambiarlo por nuestra cuenta, proponer esos cambios y que se trabaje en conjunto en una versión más completa y mejor para todos.

Otro de los parámetros que debe ser valorado es el auto-reconocimiento y la individualidad. Sin duda se trata de uno de los aspectos menos promulgados del software libre, pero también debemos resaltarlo.

La sociedad nos cuadricula y nos aporta una sensación de inferioridad. Siempre prima la marca, prima tu jefe, tu proyecto, ¿ Y tu ?

A nivel de sofware libre ya no es así, en esta linea se habla de personas, tu trabajo queda identificado y es mucho más valorado que lo que te valoran normalmente en tu empresa.

Aparte estás aportando a la comunidad, al mundo, como los inventores de las matemáticas, han sido para todos, sin duda es ese tipo de aportaciones lo que realmente nos ha hecho crecer como especie, y por supuesto lo que nos ha permitido seguir orgullosos de lo que somos capaces de aportar y crear en conjunto.

Porque los creadores del mundo debemos ser todos, los creadores del software también.

Brqx.

G4

d.- Mashups. Compartición de soluciones.

Nos adentramos en algo que ya conocemos todos, es otra de las características del modelo cooperativo que estamos creando. Aquí tenemos una referencia técnica genial en la wikipedia :

Mashup

Mashups - Pilares Web 2.0

Pero vamos a hacer un enfoque más didáctico. Más sencillo.

El objetivo de esta técnica es compartir la generación de contenido con otros contenidos ya creados. Por ejemplo, y es el ejemplo más famoso de mashup. Si tenemos un listado de direcciones. Si además ponemos un mapa de esa dirección y ese mapa lo obtenemos de Google, Yahoo, etc, ya tenemos nuestro mashup, donde compartimos el esfuerzo de nuestra aplicación con un componente ya creado.

Hay muchas otras vertientes y enfoques prácticos, pero al final volvemos al modelo de componentes, la diferencia es que en este caso son componentes distribuidos. Lo que más adelante ahondaremos en lo que sería el mundo SOA.

Pero ya que ha salido el termino, debemos explicarlo. Y lo tenemos en el día a día, en tu propia casa.

Tu en tu casa dispones de agua caliente, gas natural, tv por cable. Pero todos esos servicios no los creas tu. No dispones de un calentador para el agua. Es un servicio que te solucionan otros.

En el software ocurre igual, en vez de crearlo tu todo, lo que haces es utilizar servicios que te proporcionan otros.

Y un servicio no es más que una forma de presentar un componente o una serie de componentes utilizados para crear ese servicio.

G5

e.-Modelo de componentes - Reenganche de arquitecturas ágiles

De la misma forma que hablé de los scripts en particular y de la informática en general, enfocando las tecnologías actuales como un reajuste de una tecnología y una información ya conocida hace muchos años, un modelo web orientado a componentes sería una adaptación a las metodologías actuales de aquellos conceptos de POO casi ya olvidados en el mundo web.

Se puede enfocar una aplicación web metafóricamente como la creación de un nuevo modelo de crear aplicaciones, ese modelo ha tenido sus momentos de crisis, pero actualmente hay multitud de opciones para intentar fusionar una metodología web y una metodología de creación de componentes.

Ahora bien, volvemos a los parámetros de confianza, ¿ en qué componentes confiamos ?

¿ Confiamos en los componentes de Microsoft ?

¿ En .Net ?

¿ Nos hemos olvidado ya de los pantallazos azules?

¿ De esas clases interminables ? ¿ De los mil servipacks que son necesarios para que nuestro sistema esté preparado para .Net ?

¿ Confiamos en Java ?

¿ En sus mil versiones y sus mil problemas ?

¿ En esas trazas de error de 10 páginas ? ¿ En su estructura abismal de clases sin control alguno ?

Sinceramente, los informáticos ya no confiamos ni en los sistemas de Bill Gates ni en los sistemas que nos propone Sun.

¿ Y qué significa todo eso ?

De momento si confiamos en Google. Si, de momento.

Al menos, sin duda, están enfocando una manera más adecuada de alcanzarnos como usuarios.

¿ Y en qué más podemos confiar ?

Les diría que en el Software libre.

¿ Y por qué confiar en aplicaciones basadas en software libre ?

Veamos, imaginemos un equipo de Fútbol, sí. Un equipo que tiene el mejor colombiano, el mejor inglés, el mejor brasileño, el mejor italiano, el mejor americano, el mejor español, etc..

Y hay otro equpo que es , por ejemplo, Alemania con los mejores jugadores Alemanes. Podéis extrapolarlo a cualquier tipo de actividad, por ejemplo la programación.

¿ Realmente pensáis que es mejor el equipo Alemán ?

¿ Tan buenos creéis que sois /son los alemanes ?

Pero es que la comparativa es aún más aclarativa.

Lucharían 11 jugadores alemanes contra 1000 jugadores del mundo.

¿ qué probabilidades tienen de victoria ?

Pues esa es la situación actual, donde además, todos formamos el equipo del mundo y entre todos luchamos contra las corporaciones que no nos dejan participar de su información.

¿ Cuanto creéis que durará la lucha ? ¿ Qué perspectivas le dáis a todos ellos ?

Sin duda nos tienen sujetos con el hardware. Todos tenemos que comprarnos nuestro nuevo móvil, portátil, radio del coche, etc.

Pero con el software no es así, y es que el mejor programa para crear esa radio lo estamos haciendo entre todos.

Viva la libertad, Viva el software libre. !!!

Brqx 2010

Desarrollo

G1

a.- Calidad en el desarrollo - el modelo libre

Estamos acostumbrados a ver continuamente como la calidad de los proyectos y los productos es bastante baja.

La utilización de perfiles no adecuados unida a la movilidad laboral y la autodepresión individual hacen que el desarrollo corporativo sea bastante precario.

Todos los informáticos día a día vemos un sistema que no quiere cambiar, no adepta mejoras y quiere que todo sea para ya y no le importa como se haga.

Este modelo planteado es opuesto al modelo libre. En el modelo libre sólo puede primar una cosa : calidad.

Pues como todos somos responsables de ese producto, todos podemos aportar nuestra percepción al mismo y, por supuesto, todos tenemos la capacidad de cambiarlo.

¿ qué pasa si el cambio es peor ? Por lo general no puede ocurrir, pues para llegar a hacer un cambio hay que demostrar que puedes mejorarlo, sino entre todos no te vamos a dejar cambiarlo.

Pero incluso si lo has podido cambiar y es peor. La solución es simple, no se usará tu cambio y se descartará, por tanto ni a ti te conviene hacer un cambio que empeore el producto.

A su vez como es un trabajo en el colaboramos todos, pues es mucho más fácil que vaya adaptándose a las necesidades y requisitos de toda la comunidad.

Por tanto esa misma comunidad va a conseguir que cada vez la calidad de los productos libres sea mayor, porque a su vez va en beneficio de todos nosotros.

G2

b.- Enfoque Componentes - Dejar de reinventar la rueda

Hemos planteado la realidad de la calidad de los productos libres, pero debemos ahondar ahora en la elaboración de dichos productos.

En la abstracción funcional que permite adquirir una visión superior y ser capaces de construir modelos , a priori, cada vez más complejos, aunque indirectamente deben compartir los mismos criterios de simplicidad que los modelos más sencillos que se encuentran definidos.

Vamos a enfocar un modelo de componentes. Para ello vamos a centrarnos en lo que es un componente y lo que es un contenido, pues el objetivo final es conseguir crear componentes con contenido.

Pero no quiero entrar en el aspecto técnico del tema ni en su utilización conceptual en productos.

Vamos a ahondar en los principios a seguir en la elaboración de nuevos componentes y en la creación de nuevos productos.

Sin duda el primer acercamiento está claro. Siempre intentar reutilizar algo creado antes de volver a crear algo parecido. El típico principio de "Volver a inventar la rueda si ya está inventada".

Por desgracia llevamos más de 20 años como informáticos inventando y reinventando ruedas.

¿ Por qué las inventabamos ? Porque no nos enseñaban que existían, porque las compañias propietarias de dichas ruedas se las guardaban para ellos. Pero ahora, en un modelo libre, disponemos de todas las ruedas necesarias.

Pero hay otro parámetro que debemos considerar, y es tan simple como la vida misma.

Podemos verlo mirando los objetos que tenemos alrededor. Son los objetos que forman nuestra habitación. Pero el diseñador del piso, no necesita saber nada de esos objetos, es decir, se abstrae de los mismos para hacer el diseño tiendo en cuenta ese piso, a su vez el arquitecto de urbanismo, no necesita saber como es el piso, se abstrae del mismo y se centra en los edificios, y así podríamos seguir.

G3

c.- Analisis práctico - Enfoque del negocio - Lo entiende el cliente

Hasta el momento siempre el documento de análisis de una aplicación era algo técnico. Un documento que estaba fuera del alcance de los usuarios. Se complicaban demasiado los procesos y los tecnicismos utilizados.

Se intentaba hacer un enfoque hacia el desarrollo más que a los que un usuario o cliente entiende. Ha sido un error y únicamente ha aportado complejidad al producto lo que a su vez ha tenido como conclusión un decremento masivo de la calidad del mismo y una inclusión también masiva de niveles intermedios entre los clientes y los desarrolladores finales.

De forma que por un lado ha empobrecido y menospreciado el valor de los creadores y también ha creado un sin fín de desconfianza entre los clientes y los llamados "vende motos" que ni saben del producto ni saben los problemas que puede tener, pero al final son los que tratan con ellos.

En fin, un despropósito continuo que ha sido una de las claves del fracaso del software corporativo.

Buscando soluciones y adoptando un enfoque del negocio, vamos a plantear un sistema ágil y fácil, sin complejidad por completo, con objeto de minimizar esos requisitos que ya planteamos al principio.

Por tanto aportaremos una forma de hacer documentos más ágil, más cercana, más corta, más sintética pero a su vez sencilla.

Les invitamos a consultar el modelo que proponemos.

Es una revolución , es un cambio absoluto en todos los paradigmas del software donde , ante todo, se lucha por la sencillez.

G4

d.- Diseño orientado a componentes

Queremos buscar una forma de simplificar los desarrollos, con esa simplificación conseguimos independizar este documento del código final e incluso en muchas ocasiones aislarlo completamente.

Si adoptamos un enfoque de componentes ya utilizados, conseguimos una simplificación absoluta en la identificación de los distintas soluciones.

Sea esa simplificación la que consigue que un documento de diseño sea sencillo y totalmente enfocado al modelo de componentes.

Queremos proponer un modelo orientado a un gestor de contenidos, pero ese mismo modelo propuesto debería ser adaptable a cualquier otro producto que se pudiese enfocar como un sistema de componentes.

Ese sistema de componentes permitirá conseguir independizar casi totalmente el modelo de la implementación final en código.

En nuestro caso nos basaremos en Drupal como producto adopta casi por completo un modelo conceptual de componentes , donde con la especificación de esos mismos componente y las acciones pertinentes entre ellos podremos llegar a especificar más del 90% de los posibles comportamientos de una web.

Este mismo modelo debería ser auto suficiente para implementar un supuesto desarrollo y a su vez debería permitir a cualquier equipo de desarrollo que conozca Drupal, poder interpretar correctamente los requisitos exactos que requiere el negocio.

Debido a que siempre hay aspectos cuya complejidad excede un planteamiento tan generalista como el indicado, este modelo de diseño dispone de un apartado para esos "proceso complejos", donde queda siempre abierto a cualesquiera formatos como algoritmos o pseudocódigos que permitan a su vez indicar el correcto comportamiento de ese proceso en cuestión.

Comentar además que este modelo de diseño es una base y se deberá ampliar en razón a los posibles componentes utilizados, como puede ser una incipiente introducción a nivel de servicios.

G5

e.- Caches, Lenguajes Interpretados v$ Compilados - La verdad práctica

Durante muchos años el enfoque de la programación ha ido siempre ligado a la compilación para optimizar el código y acercarlo a cómo lo debe interpretar el procesador para que sea lo más optimo posible.

Sin duda habrá sectores donde esa necesidad de rendimiento absoluto sea primordial. Pero también es verdad que hay otros muchas situaciones donde no es tan importante el rendimiento de cualquier petición sino más bien del conjunto de peticiones.

Ahí es donde entramos en dos conceptos fundamentales, por un lado la viabilidad cada vez mayor de los lenguajes interpretados y por el otro la aparición de otro componente primordial en la computación, los mecanismos de caché.

El objeto es que aunque el tiempo y los recursos necesarios para generar una petición sean altos, una vez generada, pueda ser regenerada con unos recursos exponencialmente más bajos que la primera generación.

Así ocurre en un lenguaje interpretado, la primera vez que se llega a ejecutar, su rendimiento es bajo, pero una vez ya se ha ejecutado y está almacenado de alguna forma su resultado , el rendimiento puede ser igual de bueno que si ya estuviese compilado el código.

Si unimos este parámetro a otros conceptos como transparencia, capacidad de modificación, facilidad de integración, portabilidad, etc, tenemos como conclusión que el uso de lenguajes interpretados tiene y tendrá una aceptación cada vez mayor en la sociedad.

Son todo ventajas y realmente hay muy pocos entornos en los cuales no se puedan utilizar este tipo de técnicas.

Si además de utilizar los mecanismos comentados para generar peticiones, a su vez lo unimos a unos mecanismos adicionales de caché, conseguimos disminuir aun más las diferencias de rendimiento entra aplicaciones.

Es el primer ejemplo de un modelo cooperativo.

G6

f.- Modelos colaborativos ( delegación funcional ) -- no tiene por que hacerlo todo un sólo producto. --

Adentrados por completo en el modelo de componentes, podemos apreciar las distintas responsabilidades de los mismos. Lo que indirectamente nos lleva a las relaciones o colaboraciones entre componentes.

Hablamos del modelo colaborativo, en éste modelo un componente para cumplir una de sus funcionalidades requisa o utiliza a otros componentes.

De esta manera podemos ver que las responsabilidades de un producto estarán ligadas a las de los componentes que lo componen, de forma que la perspectiva y los objetivos del mismo pudieran estar totalmente ligados al comportamiento de N componentes relacionados.

Este ejemplo llevado al mundo libre lo podemos ver en Drupal. Se ha hablado mucho de rendimiento y seguridad, entre otros parámetros en las aplicaciones web.

Drupal delega esos parámetros en otro componente : el servidor web y los opcodes u otros mecanismos aceleradores.

Pero a su vez también busca colaboración, dispone y crea nuevos componentes que incrementen funcionalidad relacionando e integrando el producto con ellos.

Y qué ventaja conseguimos con un modelo colaborativo, que cualquier mejora, cualquier cambio en el conjunto de componentes mejora indirectamente a cualquier otro componente relacionado.

Esta sucesión interminable de abstracciones tiene una implicación directa en el continuo crecimiento funcional del producto y en la auto mejora proporcionada por cualesquiera componentes intervinientes, ya sean o no de Drupal.

G7

g.- Los requisitos - Orientacion al modelo libre

A la hora de enfocar y plantear los requisitos o necesidades de una aplicación, siempre debemos tener en cuenta el modelo que los engloba.

Hasta ahora siempre los requisitos seguían un modelo lineal, donde todo lo que se ha pedido se debía conseguir.

En este modelo no se partía que igual había requisitos que ya estaban solucionados u otros que de momento eran imposibles.

Se debía hacer un esfuerzo adicional absurdo, por supuesto para llegar a cumplir todos los requisitos solicitados por un ignorante cliente, normalmente mal enfocado por el "vende motos" correspondiente.

En un modelo libre no debería ser así. Debemos partir de una mentalidad más abierta y con un grado muy alto de confianza en el modelo.

De forma que habrá requisitos que se puedan solventar y habrá otros requisitos que se aconseje aplazar.

Siempre buscando un equilibrio en el esfuerzo actual realizado para la obtención de los mismos.

Tenemos ejemplos directos en la sociedad, donde se ha visto que según se ha incrementado el nivel tecnológico pues se han podido acometer proyectos totalmente utópicos hace tiempo.

Es por ello que debemos priorizar los requisitos y no considerar imprescindible el cumplimiento de 100% de los mismos, sino afrontar el éxito de un proyecto en razón a ponderaciones relacionadas con la prioridad del requisito.

En este punto entramos en el apartado de los presupuestos condicionales o abiertos. En software libre habrá muchas ocasiones donde no se pueda hablar de proyecto cerrado.

Por tanto podemos clasificar los requisitos en tres grupos:

- Requisitos necesarios

- Requisitos postponibles

- Requisitos universales

El tercer grupo parece nuevo, y podría llamarse requisitos derivados, pero cambiaría el enfoque. La idea es hacer a la comunidad cada vez más protagonista, de forma que consigue por si misma imponer requisitos no solicitados a un proyecto, hablamos de los requisitos universales.

Estos requisitos, aún sin ser solicitados directamente por el negocio, debemos considerarlos y darles un alto peso, pues acercarán la aplicación a las necesidades tanto del negocio como de toda la comunidad.

Testing

G1

a.- Hacia los test automatizados

Hemos sentado la premisa que la certificación del producto lo hacemos todos. A su vez también hemos establecido las abstracciones como una de las claves del avance de la informática.

En paralelo a esas abstracciones, podemos ver la automatización como una de las calves del avance de la sociedad.

Esa misma automatización se debería aplicar a los procesos de software, de manera que no sólo el creador es el que decide cómo se debe comportar, sino que además decide cómo se debería probar ese comportamiento y auto-suministra métodos para llevar esas comprobaciones a cabo.

Al final siempre el creador es el más interesado en que su producto funcione bien. Por tanto el objetivo de esta creación es hacia la automatización de las pruebas, que el 90% del comportamiento del aplicativo sea predecible y comprobado automáticamente. Y a su vez seamos el resto de la comunidad los que identifiquemos ese 10% restante.

Pero siempe será mejor que sea el 10% y no el 90%. Sin duda la creación de estos test automatizados es una referencia directa a la calidad del producto.

A su vez es otra indicación hacia la in necesidad de entornos de pruebas o certificación, debido a que esas mismas pruebas se harán automáticamente.

Lenguajes como perl disponen de miles de test automatizados y ya Drupal está siguiendo el mismo camino, donde los desarrolladores, no sólo hacen el módulo en cuestión sino a su vez indican y generan una serie de test que debe pasar ese módulo.

Se trata sin duda de la correcta interpretación del proceso de pruebas, donde el que decide cómo se debe probar es el más indicado, por tanto quién ha realizado el componente.

G2

b.- Evaluación mundial del código (descarte entorno certificación)

En la misma linea ya definida, en el momento en el que se consiga una auto comprobación de los componentes generados, desaparece la necesidad de que haya equipos humanos comprobando esos componentes.

Es la misma idea de las cadenas de producción que supusieron la revolución industrial. En el momento en el que tenemos una máquina que hace el trabajo, desaparece la persona.

Esa misma filosofía ahonda actualmente en los múltiples entornos de certificación o pruebas de aplicaciones.

Pero si lo enfocamos a nivel de evolución social, no es nada malo, se descartan labores rutinarias y permite que realmente se enfoque el tiempo y los recursos en labores de conocimiento.

El objetivo más allá de certificar el funcionamiento de los componentes deberá ser conocer esos mismos componentes y certificar el buen uso de ellos y aconsejarlos siendo una referencia de información.

Por tanto si bien es cierto que desaparece la necesidad de entornos de certificación. Directamente aparece una nueva necesidad, una necesidad tan antigua como la propia especie : La necesidad del conocimiento.

En el momento en el que se incrementa el número de componentes debe aparecer una serie de departamentos , de asociaciones, de entidades, etc.

Que permitan clasificar y jerarquizar los mismos, con objeto de buscar ese ideal de simplicidad social.

Aparecen los entornos de calidad y los modelos de arquitectura de componentes.

A partir de este momento el objetivo no es crear sino saber utilizar lo que ya está creado. De forma que uno de los principales papeles de cualquier informático es el estudio continuo de metodologías y posibles componentes aportados por la sociedad.

Porque, en el modelo libre, esos componentes SON DE TODOS. Aprovechémoslo y sigamos haciendo grande nuestra especie. Pues lo mejor que tenemos es la capacidad de pensar, idear, interpretar y sentir.

Viva el Software Libre

Vivan las personas

Viva la libertad

Despliegue

G1

a.-Multiples entornos - Viabilidad de cambio

Una vez que disponemos de un producto, la comunidad dispone de distintas formas de interactuar sobre ese producto.

La primera de ellas es la utilización completa y continua del producto, de forma que es difícil llegar a cambiarlo y los cambios conllevan costosas adaptaciones para mantener la información actualizada.

Otro segundo enfoque es disponer de un producto con muchas funcionalidades disponible pero sin capacidad de cambio y en paralelo disponer de el mismo producto en continuo crecimiento. De forma que para casi cualquier funcionalidad se utiliza la versión inicial , pero hay otros entornos en continuo desarrollo.

Una vez que ya se ha desarrollado ese entorno se actualiza la versión inicial.

Este proceso que se puede ver complejo y difícil, utilizando un modelo de componentes coherente tiene aplicación casi inmediata.

Es por ello que llegar a disponer de N entornos paralelos con similitudes entre los mismos adquiere puntos de simplicidad muy altos.

Pero tiene otra ventaja, que es disponer de entornos vivos. Entornos donde cualquier cambio en los mismos está abierto a la comunidad.

G2

b.-Entornos vivos - Live Environments

Es totalmente factible que todos los entornos involucrados en un proceso de creación de una producto sean visibles.

¿ Por qué ocultarlos ? ¿ Por qué no ocultarlos ?

En otros modelos, la ocultación de información era esencial para el éxito del producto, de forma que obteníamos ventajas comparativas al disponer de una funcionalidad que no tiene la competencia.

En el modelo libre, no hay competencia, pues es de todos, por tanto, ¿ por qué ocultar el desarrollo ? ¿ Para qué dificultar su obtención ? De ninguna manera se pretende frenar el crecimiento del software libre.

Pues cuanto más inclusión social tenga , más funcionalidad tendrá y mejor será el producto.

Es por ello, que cualquier versión puede y debe estar visible y disponible. Ya serán otros los que decidan no usarla o usarla, no entrar o entrar.

Pero hay más ventajas, aportamos siempre toda la funcionalidad a la comunidad. Continuamente estamos entregando nuestro granito para que otros añadan su granito y consigamos una playa para todos.

¿ Y si todas las playas fuesen libres ? Ese debe ser el objetivo que todas esas maravillas que aún no conocemos sean libres, estén accesibles, sean conocidas aún sin estar terminadas.

¿ Pero y qué pasa con lo que se creó y ya no se usa ? ¿ Qué hay de la memoria histórica ? ¿ De lo que era hace años ? También es un aspecto a considerar, disponemos de la capacidad necesaria para tener esos entornos visibles también.

A su vez entramos en los conceptos de evolución de entornos, tenemos la capacidad de vislumbrar cómo han crecido , cómo eran, y cómo serán.

Esa capacidad de exploración y esa funcionalidad exquisitamente operativa sólo se puede plantear en un mundo libre.

Comunidad

G1

a.-Cooperacioón empresarial y compartición de conocmiento

Hasta el momento sólo veíamos empresa a nivel de competencia. Lo que tiene uno nunca lo comparte con los otros.

En el modelo libre, este concepto cambia. Las empresas deben enfocar su valía en razón de los servicios ofrecidos y del conocimiento obtenido de los productos, pero nunca de la venta de los propios productos libres.

Entonces entra en juego el concepto de cooperación. A la empresa le interesa que su producto cada vez sea mejor y a la empresa le interesa conocer cada vez mejor ese producto porque van a ser esos valores direrenciativos los que van a vender como servicios.

Este es el modelo libre a nivel empresarial, se vende conocimiento y se venden servicios, pero indirectamente se aporta ese mismo conocimiento en intentar mejorar el producto y en la ayuda a transmitir las funcionalidades del mismo.

Es por ello que los avances de una empresa que apuesta por software libre son avances para la sociedad.

¡ Tengámoslo en cuenta ! Están creciendo para todos, y todos nos vamos a ver beneficiados de su éxito.

Apostemos por empresas libres.

Apostemos por software libre.

G2

b.-Colaboración mundial. Lucha múltiple. Crecemos entre todos - Aportamos entre todos

Seguramente en este punto ya estáis cansados de escuchar que el modelo libre lo "modelamos" todos. Somos todos partícipes del mismo y creadores de sus componentes.

Pero a su vez, en una sociedad movida por los intereses, debemos considerar interesadamente cada uno de nosotros y en función de sus posibilidades la aportación que tiene el modelo para él y de que forma le interesa ayudar a ese modelo.

Hablamos de las donaciones, todos sabemos ya el fenómeno wikipedia y todos somos responsables de su éxito y nos aprovechamos del mismo. Se terminó la época en la que tenías que comprarte una enciclopedia para saber cosas. Se terminó esa sociedad donde el conocimiento más exacto no estaba al alcance de todos.

Hoy en día wikipedia es la mejor enciclopedia y ese éxito es de todos. Pero el éxito también es una responsabilidad. Los servidores que utilizan wikipedia, las personas que lo mantienen necesitan un aporte económico. Todos y cada uno de nosotros, como empresas y particulares, debemos considerar de qué forma podemos ayudar a este y a tantos otros proyectos.

Ya hay muchas empresas que han apostado por el mundo libre. Desde luego que estas empresas van a ayudar a que la filosofía libre siga triunfando.

Ahora es el momento en el que todos nos involucremos en un proyecto que sólo va a en favor de nosotros mismos. De nuestra especie. De nuestra individualización. De nuestra propia satisfacción.

Viva el mundo libre.

Fuera patentes.

Viva el software de calidad.

Adelante sociedad... SIGAMOS CAMBIANDO EL MUNDO.

Arquitectura

G1

En un modelo totalmente orientado a la re utilización de componentes, sin duda los requisitos también deben estar en consonancia. ¿ Qué significa esto ? Pues que habrá muchos requisitos generales para aplicaciones que ya vengan cubiertos por el sólo hecho de utilizar tal módulo o tal componente.

Por ejemplo requisitos de autenticación ya vienen solucionados al usar el core de Drupal. En este aspecto a su vez hay multitud de módulos relacionados que permiten satisfacer casi cualquier tipo de autenticación del mercado, desde contribuciones que atacan a productos propietarios hasta la implementación de cualquier estándar como puede ser OpenId.

Incluimos a continuación un posible listado de requisitos "auto" cubiertos. Los agruparemos por funcionalidades. Como ejemplo podemos tratar la funcionalidad de Autenticación al sistema.

brqx_requisitos_02_especificos_cliente.gif

Para los requisitos no cubiertos por la núcleo de requisitos "auto-cubiertos", indicaremos explícitamente las funcionalidades pedidas. El objetivo es que haya un documento de requisitos auto cubiertos para cualquier portal que respete la arquitectura y una pequeño subconjunto de requisitos específicos para cada Portal.

El objetivo es que el conjunto de requisitos que diferencien un portal de otro sea mínimo y se convierta en un documento manejable y ágil tanto para desarrollo como para el propio cliente.

G2

La idea del modelo de análisis propuesto es enseñar un documento que pueda entender perfectamente el cliente. Donde no haya tecnicismos y los vocablos utilizados reflejen únicamente la complejidad de su negocio.

Cualquier sistema, por complejo que sea se puede reflejar con la figura superior. Disponemos de una serie de peticiones de usuario que son satisfechas por el sistema. A su vez disponemos de N funcionalidades que utiliza el sistema. Encauzado en una arquitectura de componentes donde entre todos permiten un funcionamiento eficiente y seguro. Y todo ello secundado por una envolvente de aspecto.

Brqx_Estudio_Analisis_2010.gif

La navegación por el mismo y sus consecuencias se minimizan por completo. Simples figuras de Cuadros o Redondeles nos indican el funcionamiento interno de cada acción. Los cuadros mostrarán su resultado en otra interfaz y los círculos, en cambio, no cambiarán de perspectiva para el despliegue de su información.

brqx_miscaramelitos_2010_captura_800.png

A su vez, de forma visual mostraremos las N pantallas que intervienen en el flujo de navegación del portal.

brqx_miscaramelitos_2010_captura_admin_800.png

Ahondaremos en la simplificación y en la funcionalidad mínima en función del negocio y la absoluta facilidad y gestión ágil y visual en las facetas de administración.

Se indica cada una de las funcionalidades y su descripción. Se indicarán a continuación las acciones que tendrá cada funcionalidad.

brqx_Analisis_Funcionalidades_Drupal_2010.gif

Describimos todos los roles e indicamos relaciones con las funcionalidades y las acciones en el sistema

brqx_Analisis_Roles_Drupal_2010.gif

Indicamos los distintos tipos de datos, su descripción y su representación, de una forma totalmente simple de manera que el cliente pueda entender y participar en la composición de los contenidos.

brqx_Analisis_Tipos_Drupal_2010.gif

Habilitamos posibilidad de incorporar complejidad adicional mediante procesos complejos.

brqx_Analisis_Procesos_Complejos_Drupal_2010.gif

Como pueden ver se trata de una arquitectura extremadamente simple cuyo fin es servir de enlace entre la mentalidad del cliente y los problemas de su negocio y los componentes, roles ,funcionalidades y representaciones de los mismos que se hará en la aplicación.

G3

El objetivo del documento es definir y explicar los conceptos y diagramas usados en las variopintas facetas involucradas en la arquitectura, de forma que se pueda aplicar directamente en el producto final. En éste caso, el producto seleccionado es Drupal.

Podemos comprobar las asociaciones entre funcionalidades definidas y los componentes con los cuales conformaremos esas funcionalidades.

brqx_diseno_01_navegacion_tabla_navegacion.gif

Exponemos a continuación las taxonomías, su explicación, ejemplo y relación con los tipos definidos.

brqx_diseno_02_taxonomias.gif

Continuamos con los distintos componentes, su representación y su ejemplificación.

brqx_diseno_03_componentes_tipos_de_usuario.gif

Hemos visto como queda totalmente definido sin lugar a confusiones la representación e implementación de cualquier Tipo de Usuario o Taxonomía definida

A continución propondremos un modelo para poder representar procesos con algún tipo de complejidad añadida. Los hemos denominado "Procesos Complejos en la arquitectura.

brqx_diseno_04_procesos_grafos_complejos.gif

Entramos en el universo de versiones Drupal. Indicamos una simple representación de módulos y temas utilizados en el futuro portal.

brqx_diseno_05_modulos_y_temas.gif

Como bien ha quedado explicado en la arquitectura, cada módulo define componentes en la misma, a su vez también nosotros creamos componentes para cambiar la visualización o representación de Tipos de usuario y otros objetos en pantalla. Drupal aporta dos poderosos métodos de visualización. Vistas y Plantillas.

Cada Vista incluye su parametrización y su formato como se puede comprobar en las siguientes tablas.

brqx_diseno_06_plantillas_y_vistas.gif

Las vistas nos aportan una potencia asombrosa, permitiendo parametrizarlas para poder relacionar completamente contenidos al estilo E/R de BBDD. Las posibilidades en este campo de Drupal son ilimitadas.

Esta funcionalidad es más común a cualquier otro CMS, pero por supuesto Drupal también dispone de objetos para modelar la distribución de contenidos en el portal. Los principales atractivos indicados son los Bloques, pero también tiene Paneles, Tabuladores y otras muchas variantes que incrementan de forma exponencial las posibilidades de implementación.

Nos centraremos en esta arquitectura en los Bloques. Indicamos la colocación de los mismos y comportamiento y origen de su funcionalidad.

brqx_diseno_07_bloques_y_temas.gif

Drupalizamos totalmente la forma de relacionar las funcionalidades aportadas por los módulos y los roles correspondientes.

Será la forma "casi exacta" en la que el producto nos permte visualizar y ajustar esta parametrización.

brqx_diseno_08_roles_y_acciones.gif

El poder de drupal a nivel de configuración de usuarios y gestión de roles y métodos de autenticación es también impactante. Dispone de funcionalidades para diferenciar visualización, permisos, acciones, todo ligado al rol correspondiente.

En la representación final, todos los contenidos Drupal los "envuelve" en lo que se llama tema ("theme" en Inglés)

A continuación proponemos una descripción de los temas indicados con una pequeña miniatura (thumb) de cada uno referenciando su origen y los componentes que incorpora.

brqx_diseno_09_pantallas_y_componentes.gif

Glosario

G1

Breadcrumb - Hilo de Ariadna

Se define breadcrumb o hilo de Ariadna como una cadena identificativa que refleja la situación del usuario dentro de la estructura del portal, de forma que pueda de manera ágil acceder a cualquier parte de la jerarquía correspondiente y se encuentre en todo momento focalizado en razón a su criterio de exploración.

Basado en la antigua mitología se ha acuñado el término evocando el hilo que Ariadna dejó a Teseo para que encontrase el camino de salida en el laberinto del Minotauro.

En un portal puede ser una solución de focalizar mejor la ruta actual, pero a su vez también puede implicar confusiones en sites de menor complejidad.

G2

Wysywig - Lo que ves es lo que coges

Se trata de un acrónimo inglés que referenciar cuadros de acciones que son fáciles de manejar e interpretar por parte del usuario.

La traducción inglesa es Lo que ves es lo que coges - What You See Is What You Get -.

A nivel de arquitectura web, estos wizards están más englobados en el concepto de editores que auto- generan código html.

Es una forma de auto-generar este código que tiene ventajas e inconvenientes.

G3

Captcha - Mecanismo detector presencia humana

Se trata de un mecanismo que nos permita interpretar un reto sólo accesible por personas humanas, con objeto de minimizar los accesos indeseados por robots de spam.

Esos mecanismos pueden ser situaciones de lógica, matemáticas o audio - visuales.

G4

Span - Contenido no deseado

Se trata de información no deseada recibida por parte de terceros.

Esa información puede utilizar el medio de correo electrónico, pero también puede ser recibida por cualesquiera métodos como formularios que permitan introducir información.

G5

Path - Ruta del contenido

Los contenidos que se presentan en portales tienen la posibilidad de ser identificados no sólo con su nombre, sino con una ruta jerarquizada que identifique inequívocamente dicho contenido.

Para entender ese concepto debemos plantear el formato de una dirección web: .

Dependiendo del portal en cuestión puede confundirse el dominio con la ruta real del contenido.

Por tanto lo mejor es verlo como un “todo” la ruta es la dirección exacta de ese contenido en la web, incluyendo su dominio.

G6

Tittle - Título del contenido / nodo

Aparte del path para identificar un contenido tenemos otro parámetro que es el título.

Se trata de una forma de referenciar el contenido.

Este título puede ser estático, es decir, es generado por una persona y también dinámico o parametrizado, de forma que se autogenera en razón a una serie de propiedades del contenido.

G7

SEO

Acrónimo de "Search Engine Optimization" u Optimización para Motores de Búsqueda.

Se entiende por SEO cualquier técnica de desarrollo web que tenga como objetivo mejorar la posición de un determinado sitio web en la lista de resultados de los motores de búsqueda web.

G8

SMO

(SMO) o el "Social Media Optimization" es un término que se utiliza para obtener la visibilidad social de una web mediante medios sociales como son podcast, video blogs, agregadores de noticias, blogs, redes sociales, plataformas de networking, etc…

G9

SEM

(SEM) son las siglas de "Search Engine Marketing" y engloba todo lo relativo al marketing y la publicidad enfocada a sistemas de búsqueda en Internet.

G1

Component - Componente

Se define componente como una agrupación de objetos físicos o lógicos relacionados con la arquitectura Drupal, de forma que dichos componentes se puedan organizar y certificar.

Así mismo podemos incluir en este conjunto los siguientes ítems:

+ Componentes físicos ( ficheros o estructuras de ficheros ) :

- Módulos

- Temas

- Plantillas (contemplates)

- Logos

- Iconos

+ Componentes lógicos ( definidos por la arquitectura Drupal ) :

Módulos ( un módulo puede definir n submódulos en la jerarquía Drupal )

Temas (un tema puede definir varios temas)

Otros componentes que detallaremos a continuación son :

Tipos de usuario

Taxonomías

Bloques

Vistas

Paneles

Menús

Tabuladores

G2

Core - Núcleo de Drupal

Se trata de la estructura física y lógica que nos aporta una versión de Drupal.

Es decir los componentes y la funcionalidad aportados por el propio producto.

G3

Blocks - Bloques

Se trata de componentes visuales que permiten organizar los contenidos de un portal.

Estos bloques pueden ser auto definidos automáticamente por módulos propios de Drupal y creados por parte del usuario.

G4

Themes - Temas

Se define tema como una envolvente de contenidos del portal.

Es decir, una serie de parámetros que permiten transformar la apariencia física del portal sin cambiar su contenido.

Los temas a su vez tienen distintas propiedades en razón a cómo interpretan la arquitectura aportada por Drupal.

G5

Views - Vistas

Una vista es una forma de representar un listado de contenidos.

Hay distintas formas de representar esos mismos contenidos que pueden ser proporcionadas por módulos o por el propio core de Drupal.

G6

Taxonomy - Taxonomías - Categorías

Son una serie de vocablos que cada uno contiene N términos que puede además disponer de una jerarquía y relaciones entre los mismos.

Se trata de una forma “especial” de organizar los contenidos.

G7

Menús

Los menús son componentes visuales que permiten jerarquizar opciones de un site.

Estos menús pueden ser obtenidos tanto por el propio core de Drupal como por la adicción de módulos externos.

G8

Comments - Comentarios

Se trata de una serie de contenidos con una estructura simple cuyo objeto es permitir la aportación popular de información relacionada con el contenido en cuestión.

Estos comentarios se organizan de forma lineal e incorporan propiedades especiales a los tipos de usuario a los que pertenecen.

G9

Icon - Icono

El icono es el simbolito que aparece a la izquierda de la URL en navegadores modernos.

Se trata de una pequeña imagen que ayuda a identificar el portal.

G10

Logo

El logo de un portal suele ser una imagen más grande que el icono, que puede ser transparente y permite estampar identificación de marca a un portal.

ZH 32c LAST TODAY 22-Jul-2014 - 17:25:22 * - - - * Carga: 5.8816 ==> segundos - Mem:189.25 Mb/12732M