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

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

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

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

G4

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

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

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

G2

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

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

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

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Array

Desarrollo

G1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Esa ruta es el path, ese path permite una forma de localización por parte de los motores de búsqueda.

G6

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

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) 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) 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

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

Quicktabs

G2

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

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

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

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

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

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

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

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

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 04-Mar-2015 - 12:12:06 * - - - * Carga: 5.1131 ==> segundos - Mem:310.25 Mb/12732M