Aplicaciones de las Redes Sociales

Cuando oimos el término red social siempre se nos viene a la cabeza algo como Facebook o MySpace, y lo asociamos inmediatamente a sitios donde colgar fotos, crear grupos de amigos, etiquetar gente, etc. Pero las redes sociales son una herramienta muchísimo más poderosas que todo eso y existen muchísimas aplicaciones que las emplean con una perspectiva profesional o empresarial.

Por poner un ejemplo, LinkedIn. Se trata de una red social orientada a profesionales, donde un usuario puede crearse un perfil, adjuntando su currículum vitae, experiencia profesional, aficiones, etc., de tal forma que se puedan establecer contactos directos en la búsqueda de puestos de trabajo de profesionales para una empresa. Así mismo, existen miles de expertos en la propia red que pueden ayudar al usuario a resolver cualquier cuestión que ataña a un ámbito profesional. Tiene más de 25 millones de usuarios, entre los que se encuentra hasta Bill Gates.

Otra buena muestra es Unience, una aplicación basada en redes sociales que pretende ayudar en la toma de mejores decisiones de inversión en bolsa, así como de ser un punto de encuentro y referencia para la comunidad financiera. Su éxito está basado en que ésta es una de las comunidades más solidarias a la hora de compartir información, muestra de ello la multitud de foros existentes para tal fin. Inicialmente estaba formada por sólo un millar de usuarios, con un perfil experto en las finanzas, pero posteriormente se está ampliando con nuevos usuarios. Otra de las ventajas que proporciona es que no sólo hay opiniones, sino también datos objetivos, como estadísticas, análisis detallado de la cartera de inversiones de cada individuo, etc., comparando su estado con el de otros o incluso con el Ibex 35, lo cual dota de un valor añadido importantísmo al sitio.

La medicina, otro de los campos en auge en esto de la web social, también cuenta con numerosas redes sociales. Una de ellas es iMedix, que proporciona un buscador a los usuarios para poder obtener información relevante, escogida de diferentes fuentes existentes en la red, según nuestros criterios de búsqueda. En este mercado, como no podía ser de otra manera, han irrumpido con fuerza los dos grandes gigantes de Internet, Google y Microsoft, con Google Health y HealthVault. El primero de ellos pretende que cada usuario tenga, de forma online, su historial médio, almacenando en el mismo cualquier información relativa, como vacunas, operaciones, enfermedades padecidas, etc. A su vez, pretende ampliar sus servicios, ofreciendo la posibilidad de compartir la propia información con otros usuarios, así como proporcionar un buscador de médicos especializados y una aplicación para contactar con los mismos. En el caso de HealthVault, se trata de un administrador de historiales médicos que permite a los usuarios y a sus doctores, almacenar y consultar todo el historial clínico de forma online y segura, asegurando la privacidad de los datos de los propios internautas.

Por último vamos a hablar de una de las vertientes más extendidas de las redes sociales: el turismo. En este caso de Turismo 2.0, una red en la que los distintos usuarios pueden introducir imágenes, vídeos, recomendaciones o preguntas acerca de distintos destinos, así como chatear de forma directa con otras personas en busca de consejos. A su vez, las personas registradas en este sistema podrán crear blogs individuales donde postear sobre sus experiencias o, incluso tener un lugar donde anunciarse, en caso de formar parte del sector hostelero. Se trata de una de las redes más populares en cuanto a viajes se refiere y promete ser un referente en este sector.

Como veis las redes sociales no se limitan únicamente a Tuenti, sino que pueden tener otras finalidades de otra índole, con un perfil mucho más profesional.

Ah, finalmente comentaros que, el otro día, charlando con una amiga experta en RRHH me comentó que muchísimas empresas, en sus procesos de selección de personal, consultan en las redes sociales para ver y comprobar el verdadero perfil del candidato... así que tened cuidado con vuestro Facebook.

Los Patrones de Diseño Java EE (II)

Vamos a continuar con el anterior post en el que hablábamos sobre los patrones de diseño de Java EE, recordando que quedaban por detallar la Capa de Negocios y de Integración.

Capa de Negocio

Esta es la capa que presenta un mayor número de patrones, algo bastante razonable porque es aquella que se encarga de la gestión de toda la lógica de negocio de la aplicación Java EE.

• Business Delegate: Un objeto de la capa de presentación llama a métodos remotos de los objetos de la capa de negocio, se produce una búsqueda del elemento requerido, generando posteriormente una llamada al servicio en cuestión.
• Transfer Object: Encapsula la serialización de un objeto que debe ser traspasado por la red. El flujo de ejecución que sigue comienza con la realización de la petición para, a continuación, crear el objeto Transfer Object que encapsulará el traspaso del objeto requerido por el cliente.
• Session Facade: Crea una fachada para encapsular las complejas interrelaciones de los distintos elementos de negocio, proporcionando un servicio uniforme y manejando el flujo de ejecución de los subelementos.
• Aggregate Entity: Encapsula la creación de un Bean de entidad compuesto por otros Beans de entidad.
• Transfer Object Assember: Es una combinación del Transfer Object y el Session Facade. El primero lo emplea para serializar el objeto, mientras que el segundo llevar a cabo la encapsulación de la creación de un objeto compuesto por otros.
• Value List Handler: Maneja la ejecución de sentencias SQL, empleando para ello Beans de Sesión.
• Service Locator: Utilizado para abstraer toda la utilización de JNDI (Interfaz de Nombres y Directorios de Java) y de la creación de cualquier contexto inicial de complejo, además de para la encapsulación de búsqueda o creación de los objetos Home y EJB.

Capa de Integración

• Data Access Object (DAO): Crea un objeto que es un medio para el acceso a la Base de Datos de la aplicación, de forma que se abstraen y encapsulan todas las operaciones relacionadas con el tratamiento del acceso a datos.
• Service Activator: Se utiliza para recibir peticiones y mensajes asíncronos por parte del cliente, buscando el elemento de negocio que contiene el método que se ha de invocar.
  

Por último vamos a enumerar una serie de ventajas e inconvenientes que presentan este tipo de patrones de diseño.

Ventajas

• Estandarización de la solución y consecuente posibilidad de reutilización.
• Mejor aprovechamiento de las características la POO.
• Interoperabilidad de los patrones.
• Aumento del rendimiento a medio plazo.
• Diseño de la aplicación de forma robusta.
• Adaptada a posibles modificaciones y nuevas adiciones.

Inconvenientes

• Necesidad de análisis y estudio previo de los distintos patrones.
• Incremento del tiempo de desarrollo.
• Posible ligero aumento del coste del proyecto.

Arquitecturas Orientadas a Servicios: SOA

La Arquitectura Orientada a Servicios (SOA – Service Oriented Architecture) es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos de software de usuario. Se trata de una arquitectura de software ágil que permite la creación y/o el cambio de los procesos de negocio desde la perspectiva de las TI de forma ágil, a través de la composición de nuevos procesos utilizando las funcionalidades de negocio que están contenidas en la infraestructura de aplicaciones actuales o futuras.

En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado.
A diferencia de arquitecturas orientadas a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para la comunicación entre nodos, los servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación; permitiendo el uso en cada nodo de lenguajes de programación heterogéneos y obligando a únicamente coincidir en el contrato entre nodos con necesidades de comunicación.

SOA define las siguientes capas de software:

• Aplicaciones básicas, que son sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad.
• De exposición de funcionalidades, donde las funcionalidades de la capa aplicativas son expuestas en forma de servicios (Servicios Web).
• De integración de servicios, facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración.
• De composición de procesos, que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio.
• De entrega, donde los servicios son desplegados a los usuarios finales.

Los beneficios que puede obtener una compañía que adopte el modelo de arquitectura SOA son:

• Optimización de los tiempos de modificación en los procesos.
• Accesibilidad para migrar a distintos modelos de negocio, tales como los basados en tercerización o colaborativos.
• Capacidad de integración de distintas tecnologías en una sola lógica de negocio.
• Posibilidad de modificación de elementos de la capa de aplicación de la arquitectura sin afectar a otros procesos de negocio.

SaaS

Vamos a hablaros de un paradigma muy de moda en la actualidad de las TICs, SaaS (Software as a Service).

Software as a Service (Software como Servicio) propugna a un modelo de distribución de software en la que se sumistra, a parte del propio sistema, otra serie de servicios como soporte técnico, help desk o mantenimiento. La ventaja que ofrece es que el software requerido se distribuye y aloja en Internet, por lo que el usuario no necesita en ningún momento instalarlo en su computadora personal; y todo lo referente al mismo, datos, sesión, son guardados en un servidor externo proporcionado por la compañía que oferta sus servicios. La gran ventaja que ofrece esto es que se puede alcanzar cualquier segmento de mercado con esta distribución, ya sea una corporación grande, un usuario estándar o una pequeña empresa.

Este tipo de arquitecturas se denominan multi-tenant o multipropietario, en las que sobre un único recurso operan múltiles usuarios que son dueños, por así decirlo, del mismo.

Este modelo presenta numerosas virtudes, como que el acceso, distribución y gestión del propio software a través de la red, lo cual le dota de una disponibilidad muchísimo mayor.

Otro aspecto interesante es que el uso de la aplicación se lleva a cabo en servidores centralizados, en vez de estar alojados en sitios del propio cliente, con lo cual el acceso al mismo se realiza a través de la Web.

También resulta interesante comentar que los datos son guardados en un servidor externo, con lo cual el cliente no requiere de grandes capacidades de almacenamiento en caso de trabajar con grandes volúmenes de información (metadatos, etc.). Así mismo, esto garantiza también que se tendrá siempre copias de seguridad de los mismos, derivando esa responsabilidad en la compañía suministradora, sin tener el cliente que preocuparse de ello.

El modelo de distribución se basa en que la propia compañía suministradora ofrece los servicios de mantenimiento y soporte. Ello conlleva que se tiene en un mismo sitio toda la información, procesamiento y lógica del negocio, algo que a las compañías TIC’s beneficia mucho, pues desaparece ese concepto (en muchos casos realidad) de la dispersión y falta de integración y comunicación entre los distintos procesos del negocio.

SaaS lleva implícito que decrezca la inversión inicial, lo que conlleva un menor riesgo, al poder utilizar el software sin tener que realizar una inversión inicial en máquinas y software para el funcionamiento óptimo de la aplicación. Esto supone un beneficio importante para los directores de la empresa contratante.

Así mismo, este modelo tiene la fortaleza de que todas las actualizaciones y nuevas funcionalidades se pueden tener de manera inmediata, sin necesidad de esperar a que las nuevas versiones estén disponibles, o se tengan que instalar, amén de que no se requerirá personal alguno dedicado a esta tarea. Se dispondrá de todas las actualizaciones y mejoras de manera inmediata.

La empresa centra su esfuerzos en su negocio, realmente se externalizan los sistemas hasta el punto de no dedicar esfuerzos en la elección y mantenimiento de los sistemas. No obstante, siempre requerirá atención del departamento TI pero en mucha menor medida.

Por último, señalar que la aplicación sigue el prototipo “uno-a-muchos”, que viene a determinar que el propio producto es realizado por una empresa y distribuido y utilizado por muchos clientes.

Los Patrones de Diseño Java EE (I)

En un post anterior ya hablamos de los distintos patrones de diseño existentes, que respondían a soluciones para una serie de problemas que se repetían con cierta frecuencia en los sistemas de información. Sin embargo la creciente demanda de desarrollo de aplicaciones empresariales en entorno web ha hecho que sea necesaria una definición de un nuevo conjunto de soluciones enfocadas a este ámbito: los patrones de diseño JEE (Java Enterprise Edition).

Se dividen en cinco capas: Cliente, Presentación, Negocios, Integración y Recursos, de las cuales nos centraremos en las tres centrales, pues son las que presentan un mayor interés de cara al desarrollo de sistemas con orientación empresarial.

En el siguiente esquema se muestran los distintos patrones y las relaciones que se establecen entre ellos. Seguidamente pasaremos a comentar el primer grupo, el correspondiente a la Capa de Presentación.


Capa de Presentación

• Decorating Filter/Intercepting Filter: Maneja varios tipos de peticiones que requieren un procesamiento determinado; especialmente aplicado a procesos de validación de sesión.
• Front Controller: Acepta todas las peticiones de un cliente y las direcciona a los manejadores apropiados.
• View Helper: Encapsula la lógica de acceso a bases de datos en beneficio de la capa de presentación.
• Composite View: Elemento de la Vista compuesto por otros elementos del mismo tipo.
• Service to Worker: Similar al MVC, emplea dos subpatrones, el Front Controller para el Controlador y el View Helper para la Vista.
• Dispatcher View: Similar al MVC y al anterior, pero el Controller no realiza acciones sobre el Helper.

En un post posterior continuaremos la descripción de las dos capas que restan, la de Negocio y la de Intregración.

Patrones Arquitectónicos: el MVC

Las arquitecturas lógicas para el diseño de aplicaciones web se dividen entre dos patrones o modelos: el Cliente-Servidor y el MVC (Modelo-Vista-Controlador). La primera, más tradicional y clásica en sistemas con un tiempo de vida largo, y la segunda, más de moda en la actualidad por el paradigma que propone. Para este post nos vamos a centrar en esta última, dado que su uso está extendidísimo y es la más indicada para aplicaciones web.

El patrón MVC o Modelo-Vista-Controlador basa su robustez en que la lógica de la interfaz de usuario varía mucho más rápido que la lógica de negocio y almacenamiento, con lo que pretende separar las capas, de tal forma que un cambio en una de ellas no tenga un impacto elevado en otra. Está dividida en tres capas o niveles:

Modelo: gestiona los datos y la lógica del negocio.

• Accede a la capa de almacenamiento de datos. Independencia del modelo con el sistema de almacenamiento.
• Define las reglas de negocio, la funcionalidad del sistema.
• Registro de las vistas y controladores de la aplicación.

Vista: presentan la información del sistema al usuario y generar los eventos de la interacción con éste.

• Captura eventos del usuario y se los envía al sistema a través del controlador.
• Recibe mandatos del controlador y muestra información al usuario.

Controlador: recibe eventos del usuario, invoca servicios ofrecidos por el modelo y selecciona la vista adecuada para presentar los resultados.

En la siguiente figura se aprecia la interacción entre los distintos componentes. Hay versiones o apreciaciones del MVC en las que se permite la conexión entre la Vista y el Modelo, sobre todo para operaciones muy simples que apenas tengan complejidad o impacto en la lógica del sistema. Nosotros creemos que, si es precisamente un patrón que trata de separar estas capas de negocio, es mejor que no existan tal relación, teniendo que pasar todas las peticiones a través del Controlador. Y este argumento se refuerza en las aplicaciones Web, donde la Vista suele estar distribuida y existe un altísimo grado de concurrencia en el acceso a los datos del sistema.

Por lo anterior, el flujo de control que sigue este patrón es:

1. El usuario interacciona con la interfaz (Vista) y genera un evento.
2. El controlador captura dicho evento y lo gestiona.
3. El controlador accede al Modelo y lo actualiza.
4. El controlador invoca la Vista necesaria para presentar los nuevos datos al usuario.

En función de la tecnología en la que estéis desarrollando el diseño existen numerosos frameworks para implementar el MVC, por ejemplo Struts para Java, CakePHP para PHP y Spring.NET para .NET.

Un estándar para la Gestión de Proyectos: el PMBOK

En este post vamos a hablar de uno de los más (si no el más) importantes estándares de Gestión de Proyectos. El PMBOK (Project Management Body Of Knowledge) aglutina una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro del campo de la Gestión de Proyectos. Fue desarrollado por PMI (Project Management Institute) y proporciona una serie de fundamentos para este área funcional, aplicables a proyectos de múltiple índole: software, ingeniería, construcción...

Postula que un proyecto exitoso va a ser consecuencia de la colaboración y conflictos entre el equipo de gestión o dirección y el de trabajo, y para muestra, una de las frases introductorias del libro: "Buenas prácticas no quiere decir que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos: el equipo de dirección del proyecto es el responsable de determinar lo que es apropiado para cada proyecto determinado".

Concibe que es en los propios miembros del equipo de trabajo (Gestor de Proyectos y responsables) en los que reside el conjunto de conocimientos (Body of Knowledge) que se han de aplicar para dirigir un proyecto, representando un conjunto vivo, amplio y que es fruto de la unión entre experiencia, estudio y desarrollo. Por ello, la finalidad del PMBOK no es la de proporcionar nueve pasos básicos para el éxito en la gestión de un proyecto, ni pretende mostrar disciplinas, experiencias y técnicas que pueden ayudar a conseguirlo, sino que identifica un subconjunto de éstas que dan lugar a buenas prácticas de ingeniería.

El PMBOK propone cinco procesos básicos y nueve áreas de conocimiento comunes a la mayor parte de los proyectos. Los procesos interactúan a través de un proyecto o fase, y son descritos en base a: Inputs (documentos, diseños,...), Outputs (documentos, productos de ingeniería,...) y aquellas herramientas y técnicas que, aplicadas a las entradas, dan lugar a las salidas.

Los procesos son: Inicio, Planificación, Ejecución, Supervisión y control, y Cierre. No representan fases rígidas ni excesivamente estructuradas, pero básicamente responden al modelo "planear, hacer, revisar y actuar".


Las nueve áreas de conocimiento identificadas en el PMBOK son:

1. Gestión de la Integración de Proyectos.
2. Gestión del Alcance en Proyectos.
3. Gestión del Tiempo en Proyectos.
4. Gestión de la Calidad en Proyectos.
5. Gestión de Costos en Proyectos.
6. Gestión del Riesgo en Proyectos.
7. Gestión de Recursos Humanos en Proyectos.
8. Gestión de la Comunicación en Proyectos.
   
9. Gestión de la Procura (Logística) en Proyectos.

Esperamos que este post os haya servido para tener una visión global más amplia de un campo tan complejo como la Gestión de Proyectos y que comprobéis que ésta no es una tarea trivial, sino que requiere no sólo de mucho conocimiento, sino también de experiencia.

Por último, deciros que aquí tenéis disponible la última versión del estándar en castellano, publicada en 2004.

Los Ciclos de Vida del Software (II)

Vamos a continuar la labor comenzada en el post anterior acerca de los distintos modelos de ciclos de vida de software.

Ciclo de vida PROTOTIPADO

Este modelo se basa en la realización continua de diversos prototipos, cada vez más refinados, a partir del conjunto inicial de necesidades del cliente, de tal manera que los entragables van aumentando en su complejidad, con el fin de incrementar la comprensión que tiene del sistema tanto el usuario como el desarrollador.


Su principal ventaja es ese control continuo que se tiene sobre el producto que se está desarrollando, porque está supervisado y guiado por el propio cliente, que va modificándolo a su parecer, con lo que se evita la entrega de sistemas que, al final, no satisfacen las necesidades reales del usuario.

En su contra, estas características pueden hacerle débil, porque el cliente puede exigir plazos más cortos al ver sistemas en "pseudofuncionamiento", creyendo que son los finales. Algo similar puede ocurrir en el equipo de desarrollo, que puede caer en el relajamiento y descuido del compromiso de calidad adquirido.

Ciclo de vida EN ESPIRAL

En este modelo las actividades se conforman en una espiral, representando cada bucle un conjunto determinado de actividades. Éstas no están fijadas a priori, sino que se van eligiendo en base a los distintos análisis de riesgos que se van elaborando en las sucesivas iteraciones, comenzando siempre por el último bucle efectuado.

Cada bucle empieza identificando los objetivos, las alternativas y las restricciones del ciclo. Una vez evaluadas las alternativas respecto a los objetivos y teniendo en cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado, empezar a plantear el próximo.

El segundo paso es evaluar las diferentes alternativas que se plantean teniendo en cuenta los objetivos a conseguir y las restricciones impuestas. Frecuentemente,este paso identifica las áreas de incertidumbre del proyecto con sus correspondientes riesgos. Si existen riesgos, el siguiente paso conlleva la formulación de una estrategia efectiva en coste (utilizando prototipos, simulación, bancos de prueba, cuestionarios para los usuarios...) para resolverlos.

El tercer paso consiste en revisar los resultados del análisis de riesgos, y el cuarto paso en planificar la fase posterior. Una vez realizado el primer ciclo se volvería a empezar, modificando los requisitos y reformulando los objetivos, estrategias, alternativas, etc.

Como veis hay mútiples alternativas... en nuestro proyecto casi todos optamos, en un principio, por un modelo en cascada, algo que viene determinado por los distintos hitos y entregables que hay que cumplir, pero creemos que va mutando en un modelo híbrido, puesto que se van realizando distintas etapas de manera disjunta con el fin de obtener una mayor productividad y, casi siempre, debido a los rechazos por parte del cliente.

Los Ciclos de Vida del Software (I)

En este post vamos a hablar de los distintos ciclos de vida que se pueden aplicar en el desarrollo de un proyecto software. El ciclo de vida es el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software, y que abarca desde su concepción hasta su retirada.

Para este artículo nos vamos a centrar en los cuatro que consideramos principales o más importantes: cascada, incremental, prototipado y en espiral.

Ciclo de vida en CASCADA ("Waterfall")

Este modelo es el más antiguo de cuantos vamos a comentar y resulta especialmente sencillo de gestionar. Se basa en varios principios, como que una nueva fase no puede comenzar hasta que no se termine la anterior, que para poder pasar de una fase a otra se han de haber cubierto todos los objetivos de la predecesora o que al final de cada fase se pueda revisar el estado del proyecto por parte de los stakeholders.


Por contra presenta, habida cuenta de su longevidad, algunos inconvenientes. Uno de ellos es que no refleja el proceso real del desarrollo del software, porque muy raramente un proyecto sigue un flujo secuencial, sino que siempre hay iteraciones. Otro es que el paso por todo el ciclo es lento y pesado, porque requiere que se finalice una fase para pasar a la siguiente, y por último, requiere de mucha paciencia por parte del cliente, porque no posee un prototipo de su sistema hasta los últimos compases del proyecto.

Ciclo de vida INCREMENTAL

Este modelo satisface la necesidad de una secuencia no lineal de los pasos de desarrollo. En el modelo incremental se va creando el sistema software añadiendo componentes funcionales al sistema (llamados incrementos). En cada paso sucesivo, se actualiza el mismo con nuevas funcionalidades o requisitos, es decir, cada versión o refinamiento parte de una versión previa y le añade nuevas funciones. El sistema software ya no se ve como una única entidad monolítica con una fecha fija de entrega, sino como una integración de resultados sucesivos obtenidos después de cada iteración.


Se ajusta a entornos de alta incertidumbre, por no tener la necesidad de poseer un conjunto exhaustivo de requisitos, especificaciones, diseños, etc., al comenzar el sistema, ya que cada refinamiento amplía los requisitos y las especificaciones derivadas de la fase anterior.

Así mismo, constituyó un avance sobre el modelo en cascada, pero también presenta problemas. Aunque permite el cambio continuo de requisitos, aún existe el problema de determinar si los requisitos propuestos son válidos. Los errores en los requisitos se detectan tarde y su corrección resulta tan costosa como en el modelo en cascada.

En el siguiente post os hablaremos de los otros dos que nos hemos dejado en el tintero...

¡Facebook quiere comprar Twitter!

Según una información publicada en el diario económico norteamericano Financial Times, Facebook ha ofrecido la cantidad de 500 millones de dólares, unos 390 millones de euros, por Twitter.

También según la propia noticia, Twitter es una de las empresas de Internet que más interés despierta entre inversores e internautas, pues ofrece un sistema de comunicación muy rápido, sencillo y útil, unido esto a que puede empotrarse en cualquier portal y admite múltiples configuraciones y personalizaciones.

Así mismo, es curioso el medio de pago ofrecido por Facebook a la compañía de microbloggin, pues pretende llevarlo a cabo a través de la cesión de acciones de la propia compañía compradora.

Por último, señalar que el fundador de Twitter, Bizz Stone, ha recalcado que su deseo expreso de que ésta siga siendo un ente independiente y que no quiere ningún tipo de cesión de derechos ni nada similar.

Esta noticia da una noción de la magnitud que Twitter ha adquirido en la comunidad internauta, pues el crecimiento que ha experimentado en su corta vida ha sido realmente gigantesco.

Open Social

¿Os habéis planteado alguna vez si existiera algo similar a Internet pero con Redes Sociales? Sí, sí, una especie de "red de redes" sociales... ¡Pues existe! Y se llama Open Social.

Y, como no podía ser de otra manera, quién si no, Google está detrás de todo ello. El objetivo de esta iniciativa es el de proveer un conjunto de API’s comunes que tiene como finalidad el proporcionar un recurso para el desarrollo de aplicaciones con fines sociales, pudiendo establecer conexiones y consultas con distintas redes sociales. De esta forma se puede tener acceso desde un único recurso a múltiples redes, con lo que la cantidad de información al alcance del usuario aumenta de manera exponencial.

Su infraestructura gira en torno al establecimiento de dos tipos de usuarios: los sites o Contenedores y las empresas o Desarrolladores que la emplean como base para la creación de aplicaciones.

Para el primero de ellos se cuenta con un repositorio casi inagotable de información, habida cuenta de los integrantes de la plataforma: Engage.com, Friendster, hi5, Hyves, imeem, LinkedIn, MySpace, Ning, Oracle, orkut, Plaxo, Salesforce.com, Six Apart, Tianji, Viadeo y XING. Para hacernos una idea de la magnitud de estos sites, exponemos algunos datos que darán una visión más clara de ello: MySpace (alrededor de 190 millones de usuarios), Orkut (unos 62 millones de usuarios), LinkedIn (aproximadamente 11 millones de usuarios) y Oracle (2ª mayor empresa de desarrollo de software del mundo, únicamente por detrás de Microsoft).

El objetivo principal de esta iniciativa es que cualquier sitio web de contenido social pueda implementar la API y dar cabida en él a aplicaciones sociales de cualquiera de los partners de Open Social, con lo que se pueda crear una red virtual empleando recursos de varios de ellos.

La API en sí se divide en tres módulos:

• Profile and Friends Information: datos del perfil de usuario y amigos del mismo.
• Activities: conjunto de actividades llevadas a cabo por el usuario (subir fotos, histórico de contactos, etc.).
• Persistence Data API: datos de todas las aplicaciones adscritas a Open Social. Dota de persistencia a esta capa de la aplicación, evitando la pérdida de datos.

Esperamos que esta información haya despertado vuestro interés por las redes sociales, un instrumento que va muchísimo más allá de simples repositorios de fotos o de sitios para hacer amigos.

Recomendaciones para el Diseño

Sumergidos como estamos en la fase de Diseño queremos continuar con la iniciativa surgida en el Análisis y mostraros algunas recomendaciones o impresiones que cada uno hemos tenido en el desarrollo de este punto y que esperamos que puedan resultar útiles para este o próximos Diseños de Sistemas de Información.

Antes de comenzar, simplemente recalcar que se trata del punto, creemos, más importante de todo este proyecto, pues va a dar lugar a una definición detallada del futuro sistema a implementar, incluyendo todas las pautas que los desarrolladores tendrán que tener en cuenta para esa tarea.

"Basarte en tus propios conocimientos sobre las diferentes tecnologías que se pueden utilizar, ya que aunque siempre se puede hacer un trabajo de investigación previo sobre una tecnología que no se conozca, el resultado nunca va a ser igual que si ya has utilizado esa tecnología para el diseño en otras ocasiones."

"No sólo es necesario realizar un buen diseño de la base de datos que va a albergar toda la información del sistema, sino que hay que ser totalmente estricto en el desarrollo de las tablas de la base de datos para que estas concuerden con la realidad que se pretende capturar, tanto en el ámbito de su descripción, como en el del tipo de los diversos parámetros que contienen."

"Cuando vayas a realizar el diseño de un sistema de información, lo primero que debes tener presente es que el proceso de diseño incluye concebir y planear algo en la mente, un dibujo, modelo o croquis, y que tu opción de resolución debe proporcionar una idea completa de lo que es el software, enfocando sus funcionalidades, comportamientos y dominio de datos, desde el punto de vista de la implementación. El diseño debe ser una guía que puedan leer y entender el equipo encargado de desarrollar el código y las personas encargadas de probar y mantener el software. Por ello, debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente."

"A la hora de desarrollar la explotación de los componentes del sistema, es recomendable ir realizando el trabajo sobre subsistemas cuya funcionalidad este recogida de forma clara y concisa, para obtener un buen diseño."

"En el momento de la definición de clases y métodos, hay que tener siempre en cuenta que el sistema puede ser desarrollado por gente que desconozca por completo la aplicación, con lo que los nombres y documentación utilizados han de ser descriptivos y reflejar de manera clara cuál es su funcionalidad, así como cualquier parámetro que se pueda necesitar."

Ojalá estos pequeños trucos os sirvan de ayuda y puedan serviros de guía de cara a futuros proyectos.

La importancia de... la gestión de la relación con el cliente: el CRM

Como ya habréis podido comprobar tras estos dos meses de trabajo, una de las partes más complejas de la gestión de un proyecto es el trato con el cliente. Existen múltiples estrategias para la captación y administración de clientes, pero hoy nos vamos a centrar en una que está muy de moda en la actualidad y que parece ser que da buenos resultados: el CRM.

El CRM (Customer Relationship Management o Administración de la Relación con los Clientes) es una estrategia que permite a las empresas identificar, atraer y retener a sus clientes, además de ayudarles a incrementar la satisfacción de éstos y a optimizar así la rentabilidad de sus negocios. Hablamos, por tanto, de CRM como estrategia, lo que implica no sólo disponer del software adecuado que te permita gestionar las relaciones con los clientes, sino que además, supone un cambio en los procesos de la empresa y la implicación de todos los empleados de la misma para que esta estrategia tenga éxito. Así mismo, el CRM no sólo hace referencia a esta estrategia, sino también a los sistemas informáticos que le dan soporte.

Si nos centramos en las TIC puras, el CRM es un software para la administración de la relación con el cliente, dando soporte a la gestión de esta tarea, a los procesos de venta y publicidad y marketing, y que puede dar una visión al cliente de múltiples aspectos del proyecto, como el grado de avance del mismo, el estado de diversas tareas, etcétera.

La gran ventaja de un CRM es que permite acceder a la información de forma centralizada y el cambio de datos se realiza “una sola vez”.

Beneficios de tener un CRM:

• Aumento de las ventas.
• Reducción de costes.
• Se graba la información una vez.
• Compartir información es inmediato.
• Toda la compañía conoce dónde encontrar información sin perder tiempo buscándola.
• Satisfacción del cliente, ya que quien le atienda conoce todo su histórico de relación.
• Toda la compañía sabe más sobre ellos mismos y la actividad empresarial.
• El negocio se gestiona mejor ya que se dispone de datos para tomar decisiones.
• Se entienden mejor los canales de venta.
• Se identifican los comerciales más eficientes.

Como habréis visto esta estrategia empresarial incide en un notable valor añadido en este factor clave que es, dentro de la gestión de proyectos, la administración de la relación con el cliente.

Patrones de Diseño UML (II)

Como ya introdujimos en el anterior post sobre Patrones de Diseño, éstos pueden dar solución a múltiples problemas que se presentan de forma recurrente durante la fase de diseño de distintos Sistemas de Información, y que permiten definir algunos estándares para abordar estos inconvenientes de una forma más directa, facilitando de manera notable la labor del Diseñador.

Descripción de los patrones

Patrones de creación

• Abstract Factory: proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.
• Builder: separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.
• Factory Method: define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.
• Prototype: especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
• Singleton: garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.

Patrones estructurales

• Adapter: convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.
• Bridge: desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.
• Composite: combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
• Decorator: añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
• Facade: proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
• Flyweight: usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
• Proxy: proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.

Patrones de comportamiento

• Chain of Responsibility: evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.
• Command: encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.
• Interpreter: dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
• Iterator: proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
• Mediator: define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.
• Memento: representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.
• Observer: define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
• State: permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.
• Strategy: define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
• Template Method: define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.
• Visitor: representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.

Un ejemplo de uso

En este caso nos vamos a basar en el patrón Observer para la explicación del uso de los patrones. Nos hemos decidido por éste porque está considerado casi vital en las arquitecturas que siguen el MVC (Modelo-Vista-Controlador), que es la que empleamos nosotros en el proyecto. Esto es así porque estos sistemas varían mucho en tiempo de ejecución y se han de capturar de alguna forma todos los eventos que suceden, con el fin de que el sistema se actualice con la mayor brevedad posible. En el supuesto actual, se suscriben 'listeners' a los objetos que pueden disparar eventos, para hacer esto de la forma más óptima posible.

Vemos como el Sujeto tiene una lista de Observadores adscrita, que según vaya capturando eventos irán notificando al primero qué ha sucedido para que éste cambie su estado.

Como podéis ver se requiere de un elevado grado de abstracción y se generan muchísimas más clases, pero el funcionamiento global es mucho más eficiente y las soluciones aportadas son óptimas.

La importancia de... una buena metodología para la revisión

Hace unos días, hablando con una compañera, me comentaba algunas de sus vivencias en la asignatura. La que más me impactó fue, sin duda ninguna, que era ella la que, en su grupo, se encargaba de integrar cada una de las partes de cada documento, realizadas por los distintos miembros del grupo, así como de revisar el documento final. Aparte de la enorme carga de trabajo que ello supone, creemos que lleva implícito, de forma inevitable, una peor calidad en las revisiones, por aquello de que ven más catorce ojos que dos, lo que repercute en tener que realizar más modificaciones, y por ende, más versiones de los documentos.

La experiencia a lo largo del desarrollo del proyecto ha ido modificando nuestra forma de realizar las revisiones. Al principio, dada la corta extensión de los documentos, cada miembro del grupo llevaba a cabo una revisión del texto en su totalidad, lo cual generaba siete archivos diferentes, con infinidad de comentarios que luego había que integrar en el definitivo. Ello suponía, además, que muchas veces los propios comentarios chocaban entre ellos, produciéndose inconsistencias y dudas acerca de qué era lo que de verdad queríamos reflejar en el documento. Al ver que esta metodología incidía en una carga de trabajo extra muy grande y que los resultados obtenidos eran simplemente normales, decidimos cambiar.

El siguiente intento, y hasta ahora el último, consiste en la técnica de las revisiones cruzadas. Esto viene a definir que cada miembro del equipo revisará una parte del documento, siempre excluyendo la que él haya realizado (esto es algo básico, porque en ese punto se pierde objetividad), y luego se juntará todo en una sesión de integración con todos los componentes del grupo. Esta versión ha sufrido un leve cambio, pasando a llevarse a cabo por parejas en vez de forma individual, de tal manera que dos personas revisan cada parte, lo cual hace que se gane en calidad y que, sin repercutir en un trabajo enorme, se consigan unas versiones finales más refinadas.

Creemos que esta última metodología, a pesar de que puede que no produzca unos documentos tan refinados como la primera, es mejor dado que tanto la carga de trabajo individual como grupal se ve disminuida notablemente, incidiendo en una mayor disponibilidad de tiempo para poder llevar a cabo otras tareas del proyecto.

¿Cómo lo hacéis vosotros?

Patrones de Diseño UML (I)

Inmersos como estamos en la fase de Diseño, vamos a hablar un poco sobre algunas técnicas que se pueden emplear para optimizar esta actividad, dando así al desarrollador un esquema mucho mejor de cara a la implementación del sistema.

En este post vamos a comenzar a hablar sobre los Patrones de Diseño UML, algo que todos ya conoceréis y que, a pesar de que su uso conlleva un leve trabajo extra conceptual, facilitan notablemente esta tarea.

Según el libro de Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software, un Patrón de Diseño es "una solución simple y elegante a un problema específico y común del Diseño Orientado a Objetos (DOO)". Así mismo, se apostilla que "son soluciones basadas en la experiencia y cuya fiabilidad está demostrada".

Este paradigma viene dado por detección de la repetición constante de problemas en los distintos diseños de Sistemas de Información, lo que conlleva que se defina una colección de patrones que reflejen las soluciones óptimas para cada uno de esos problemas. No es un concepto trivial de entender, requiere un proceso de estudio previo y asimilación, pero una vez que se supera dicho ciclo, los diseños creados en base a patrones presentan un mayor grado de flexibilidad, modularidad y reutilización.

Los patrones se dividen en tres grupos generales:

• Patrones de estructura: describen como las objetos pueden ser combinados formando estructuras complejas y nuevas funcionalidades. A su vez se dividen, en un segundo nivel en:

1. Estructural de la clase: Proporcionan interfaces más útiles mediante herencia.
2. Estructural del objeto: Creación de objetos complejos mediante objetos individuales para formar grandes estructuras.

• Patrones de creación: tratan de la forma de instanciar los objetos.

1. Creacional de la clase: Instanciación de la clase mediante herencia.
2. Creacional del objeto: Patrones más escalables y dinámicos.

• Patrones de comportamiento: definen la comunicación entre los objetos.

1. Comportamiento de la clase: distribuyen el comportamiento entre clases mediante herencia.
2. Comportamiento del objeto: analizan la comunicación entre objetos interconectados.

A continuación, se ve el diagrama con los distintos patrones y cómo interactúan entre ellos.



En otro post comentaremos brevemente la funcionalidad de cada uno de los patrones así como un pequeño ejemplo de uso de uno de ellos.

Palmadita en la espalda

Ya ha concluido la primera fase del concurso de blogs... La verdad es que la competencia está siendo muy dura y todos los blogs que participan en el concurso tienen un gran nivel, con lo cual esto no está siendo nada fácil. Ello, además, supone un trabajo extra bastante considerable a la ya de por si fuerte carga de trabajo de la asignatura, por lo que hay momentos en los que cuesta continuar, pero hay que admitir que que te reconozcan un trabajo motiva, y motiva muchísimo, para no detenerse.

No queríamos dejar pasar la oportunidad de felicitar a todos nuestros compañeros que también estén llevando a cabo esta ardua tarea de mantener un blog, y animarles a que sigan trabajando, que esto no ha hecho más que empezar y que lo importante es ser constante y trabajar duro.

¡Mucho ánimo a todos!

19-N

Esta mañana ha tenido lugar un acontecimiento que, esperemos, haga reflexionar a más de uno. Nos hemos concentrado más de tres mil personas frente al Ministerio de Ciencia e Innovación y hemos dejado claro que no nos vamos a quedar callados mientras continue esta tropelía.

Como muestra de que este acto ha tenido calado y repercusión, echad un ojo a estos enlaces, donde los medios se hacen eco de nuestra protesta:

El Mundo (1)
El Mundo (2)
20 Minutos

A continuación, os dejamos una muestra gráfica de lo que ha sido la concentración, adornada con algunas de las frases que se han coreado...

"Es teleco el que no bote, eh"

"Telecos, cabr...es, robais atribuciones"


"Uno cero uno, o todos o ninguno"

"Cero uno cero, fuera zapatero"

"Os vamos a tirar el servidooooooooor"

"Zapatero, somos ingenieros"

"Ingenieria informatica: no compila"



"Regulación, de la profesión"



En fin... esperamos haber contribuido un poquito a la causa y a que, de una vez por todas, tengamos reguladas nuestras competencias.

Desde aquí os animamos a que nos ayudéis a recordar todas aquellas cosas que nos hayamos dejado en el tintero... ¡Ánimo!

La importancia de... la gestión del cambio

Tras dos Informes Quincenales de Seguimiento nos vamos dando cuenta de la importancia de la Gestión de Proyectos y de la Gestión de Cambios, así como las desviaciones que, en base a múltiples factores, se producen en los proyectos informáticos.

Planificar bien es relativamente complejo, pero planificar y gestionar un proyecto sin desviaciones es, cuanto menos, una quimera. De ahí la importancia de saber gestionar y tratar los cambios que se van produciendo, llevando a cabo constantes replanificaciones, basadas siempre en la experiencia del desarrollo de proyectos. La desviación siempre va a estar ahí, pero de esta manera, atajándola fase a fase, se puede minimizar, consiguiendo un deterioro menor tanto en lo referente a términos de tiempo como de costes.

Según el reporte elaborado por Standish Group, todo un referente en el estado de los proyectos de software, "Extreme Chaos", los proyectos se clasifican en tres tipos:

• finalizado con éxito: si se completa a tiempo, dentro de presupuesto y cumpliendo con todas las características y funciones especificadas.
• no satisfactorio: el proyecto se completa y es operacional, pero con desviación en presupuesto y tiempo y con menos características y funciones de las que fueron especificadas inicialmente.
• finalizado con fracaso: proyecto cancelado antes de completarse.

En la tabla siguiente puede verse el porcentaje de proyectos exitosos, y su evolución en el tiempo:


Como se puede apreciar, el porcentaje de exitosos va aumentando, pero aquellos proyectos que conluyen con desviaciones no merman, lo cual muestra a las claras que las metodologías empleadas no son tan efectivas ni eficientes como debieran ser.

De manera análoga, se pueden establecer una serie de factores que influyen, en mayor o menor medida, en el éxito de un proyecto, tales como la experiencia, la gestión de recursos humanos, el Jefe de Proyecto, etc. En el siguiente gráfico se puede apreciar el impacto que tiene cada uno en este aspecto.



Se aprecia como, tanto los Recursos Humanos (usuarios y Jefe de Proyecto) y su cualificación, como la confianza en el equipo de trabajo son los dos indicadores de éxito más importantes y que más van a marcar el devenir del proyecto. Este dato aporta una visión clara de lo importante que es la implicación de cada uno de los miembros del equipo, así como de un Jefe compentente. Esto nos puede servir para nuestro proyecto, porque, tal y como se puede ver, somos uno de los activos más importantes y que más podemos influir para terminarlo con éxito y con la menor desviación posible.

Twitter, ahora en tu DS

Trasteando un poquito por Internet nos hemos encontrado con DSTwitter, un nuevo cliente de la aplicación que nos ocupa diseñada para ser utilizada en la consola Nintendo DS. Además de las funcionalidades típicas de Twitter tiene un valor añadido: fue creado por Acdrtux, una empresa de diseño y desarrollo web española.

Presenta las siguientes características:

• Es multilingüe: acepta inglés, francés, italiano, alemán y castellano, configurándose automáticamene en función del firmware de la propia consola.
• Carga de avatares en formato GIF.
• Muestra el tiempo relativo de envío de cada twiteo, tal como hace el cliente web (hace X minutos, etc.).
• Uso de la conexión WiFi para enviar y recibir mensajes, con medidor de calidad de señal.
• Teclado táctil.
• Aceptado por twitter.com como cliente oficial de twitter.

No deja de ser una curiosidad más acerca de la aceptación y expansión de esta herramienta, y de la cantidad de ampliaciones, plug-ins y adaptaciones que se han realizado en base a ella.

Por último, si os lo queréis descargar, aquí tenéis el enlace:

Descargar DSTwitter

Ingeniería en Informática

Bueno, como todos habréis visto/leído/escuchado, se está llevando a cabo un proceso para desvirtuar nuestra profesión, no pudiéndose equiparar nuestro título (ni el de Ingeniería Química, con los que desde aquí nos solidarizamos) con los de las demás Ingenierías. Estaréis ya cansados de oir cosas, así que sólo queríamos dejaros un par de enlaces para que véais que la cosa se está moviendo y que hay un halo de esperanza.

Decano de Informática de la UPM

El Senado nos apoya

Y otro que hace un llamamiento a las movilizaciones y donde podéis encontrar mucha más información:

Más información

Luchemos y defendamos ésto que tanto y tanto esfuerzo nos está costando conseguir...

PD: Momento cumbre de la entrevista con el Decano de la UPM:

P. ¿Por qué no puede alguien que ha estudiado Matemáticas o Bellas Artes, por ejemplo, y tiene talento, trabajar de informático en una empresa que lo quiera contratar?

R. Le hago yo otra pregunta: ¿Por qué no puede hacer un puente ese señor?

P. Parece distinto.

En fin...

La importancia de... la motivación

Llevábamos ya tiempo queriendo hablar de algo que consideramos vital para cualquier trabajador, y por extensión, para cualquier ingeniero de software: LA MOTIVACIÓN.

El hombre, por el simple hecho de ser hombre (y eso se ve reforzado en nuestro amado país), trabaja mejor si está agusto, si está rodeado de un ambiente de trabajo agradable, si su trabajo se ve, no ya recompensado, sino valorado. Es algo inherente al propio ser humano, rendimos más si estamos mejor.

Leyendo un poquito sobre motivación de equipos de trabajo, creemos que se pueden establecer dos corrientes de pensamiento bien diferenciadas:

• El ingeniero, por el hecho de ser un profesional y recibir un sueldo por ello, ha de hacer su trabajo de la mejor manera posible.

• El ingeniero rinde más y genera más beneficios si se le valora el trabajo y si está motivado.

Nosotros, a título particular, nos identificamos más con esta última. Una persona motivada, contenta, y con ganas de hacer las cosas bien va a hacer siempre mejor su trabajo que otra que no tiene otra motivación que la de su rutina diaria y su sueldo a final de mes.

Es lícito comentar que por motivación no sólo se entiende una compensación de índole económica o material, sino que entendemos que va más allá. Porque muchas veces el reconocimiento del trabajo bien hecho, una felicitación por parte del cliente, una palabra de ánimo de tu Jefe cuando estás hundido,... motiva de una manera infinitamente mayor que cualquier regalo o retribución monetaria.

Y, sino, cuando llega el lunes o jueves y vas a tu revisión de IS3 hartito de tanto trabajo, medio asqueado, y ves que, de repente se hace la luz y te aprueban un par de documentos, ¿¿¿¿¡¡¡¡¿no te sientes otra vez a tope y con las pilas cargadas para seguir dándolo todo?!?!?

Las herramientas de modelado UML

Andamos liadillos con el diseño y, a pesar de haber decidido la herramienta a utilizar en la Oferta, se nos ocurre la idea de escribir un post acerca de este tema. Existen en el mercado multitud de suites para realizar diagramas UML, pero en casi todas hemos encontrado alguna pega.

Las principales taras van desde que el no soportar UML 2.x a realizar diagramas muy poco atractivos desde el punto de vista visual, pasando por mil pequeños detalles que a unos gustan más, y a otros, menos. Vamos a hablaros un poco de aquellas que hemos ido usando todos estos años y comentando un poco nuestras impresiones.

Por ejemplo, Altova UModel, una herramienta que soporta UML 2.x, que crea unos diagramas de componentes y de clases bastante atractivos visualmente, pero que no permite introducir componentes en el diagrama de clases (sólo deja paquetes) y los diagramas de Casos de Uso son realmente feos a la vista.

Por otro lado, dTinf Cake Studio, que no soporta UML 2.x, que es bastante pesado de manejar, por el control sobre relaciones, para mover entidades dentro de los diagramas, etc, pero éstos resultan bastante atrayentes.

Microsoft Visio. No sabemos si se podría introducir aquí, porque realmente no se basa en estándares UML, aunque permite realizar diagramas con tal lenguaje. A su favor tiene la gran facilidad de manejo, pues es muy intuitiva y no requiere apenas familiarización previa.

Rational Rose es quizá la herramienta más famosa y potente para modelado UML, es de IBM y tiene una gran aceptación a nivel mundial. La única pega que se le puede poner es que requiere de un conocimiento del entorno bastante avanzado para tener un manejo ágil del mismo.

Finalmente, nosotros nos hemos decidido por Enterprise Architect, que permite UML 2.x, sus diagramas son bastante atractivos y es moderadamente sencilla de manejar.

Por último, citar que existen muchas otras, como Telelogic, VisualParadigm, etc., que podréis usar, nosotros sólo os damos pistas para que probéis y, finalmente elijáis la que más os satisfaga.

El infierno llegó

Comienza la parte, en nuestra humilde opinión, más dura de la asignatura: la fase de diseño. Cuando comenzamos a trabajar el ella nos dimos cuenta de lo complicado que es plasmar toda esa información que tenemos en lenguaje natural en un conjunto de diagramas que sirvan para describir la arquitectura del sistema.

Esta fase no consiste sólo realizar un diagrama de clases que refleje todas aquellas entidades que serán necesarias para que la descripción del sistema sea completa, sino que, comenzando a un alto nivel, será necsaria una definición de los distintos subsistemas que conformarán CLICKR, la comunicación entre ellos, sus características, etc. El pasado martes aquello parecía un hervidero. Primeramente se discutió sobre el patrón arquitectónico que emplear, que si un MVC tradicional, que si uno de capas... Luego, una vez que creíamos que teníamos solucionado un poco el asunto, llegó lo peor.

Y es que un diseño de bajo nivel no es algo trivial. Primeramente, y partiendo de la base de que la tecnología usada será Java, hemos de comentar que existen multitud de herramientas, librerías o tecnologías para implementar los distintos módulos, y desde aquí recomendamos encarecidamente que, a menos de que se conozca muy bien la citada tecnología, se desista de su uso, porque se va a perder un tiempo precioso en aprender algo que, probablemente luego pueda estar mal.

Nos volvimos locos en un mar tecnológico: que si JSP o JSF para la capa de presentación, que si Hibernate para el mapeo objeto-relacional, que si DAO para el acceso a la capa de datos, que si Struts para la implementación del Modelo-Vista-Controlador, que si Spring o EJB para la lógica del negocio, que si usar patrones de diseño tradicionales como Handler o Singleton, que si no usar nada de eso...

Lo dicho, mucha suerte y evaluad bien todas las alternativas antes de decantaros por ninguna, porque hay cosas realmente interesantes que pueden ahorrar bastante trabajo a la hora de implementar (nuestro enfoque tradicional), pero que pueden ser un suplicio para diseñarlas (nuestro enfoque actual).

¡Ánimo!

La importancia de... la gestión de los requisitos

Tras el post anterior, y un poco fastidiados por algunos cambios que tuvimos que hacer en el DAS provocados por modificaciones en el EVS, hemos estado buceando por Internet y hemos descubierto algo que antes nos parecía un horror y que ahora vemos como una ayuda bastante interesante y a tener en cuenta: las Herramientas de Gestión de Requisitos.

En un principio puede parecer una tarea tediosa, la de tener que introducir requisito a requisito en la aplicación, con todos los atributos que éstos tienen, las dependencias, etc. Pero muchas veces un requisito mal definido, una funcionalidad mal interpretada o, simplemente un cliente "especial", pueden hacer que se tenga que volver hacia atrás y haya que modificar el Estudio de Viabilidad, con los consiguientes trastornos que ello acarrea, porque un error en una fase crece exponencialmente conforme va avanzando el proyecto, y es entonces cuando te das cuenta de la dimensión del problema.

Este tipo de herramientas permiten realizar variaciones entre requisitos de software y de usuario, estableciendo la trazabilidad entre ambos, y manteniendo la consistencia, sin que la eliminación de uno pueda suponer una catástrofe en el resto. Así mismo se permite una gestión de los mismos, pudiendo variar sus atributos conforme va avanzando el proyecto, puesto que, por ejemplo, la estabilidad en un momento puede ser media y, con el tiempo, pasar a alta. Otro aspecto muy interesante a tratar es el del control de las matrices de trazabilidad, que se realizan y actualizan de manera automática con la simple inserción del requisito de usuario fuente con respecto al de software, lo cual evita una actividad bastante aburrida, ya que no sólo se ha de realizar la primera vez, sino que también la gestión y mantenimiento de la misma puede llegar a resultar exasperante. También existen herramientas que permiten visualizar el posible impacto que puede tener un cambio en el resto del proyecto, siendo tarea del Jefe del Equipo el evaluar si esa modificación es realmente asumible o el coste que va a tener implícito puede ser mayor que el beneficio de provoque.

Por último, citar algunas de estas herramientas, algunas de ellas de libre distribución, que pueden ser útiles para este tipo de trabajo: Caliber-RM, DOORS, SoftREQ, ReuseStudio, RTM Workshop, Requisite Pro, etc., y citar la aplicación desarrollada para tal fin por nuestro compañero Marcos en su PFC de ITIG: Requirements Management Tool. Una aplicación, desarrollada en formato Web, que es capaz de competir con gran cantidad de las suites existentes en el mercado.

Recomendaciones para el Análisis

Una vez prácticamente finalizada la fase de análisis (a falta de un par de modificaciones en el DAS), queremos plasmar cuáles son nuestras impresiones, así como dar algunos consejos que puedan ser útiles de cara a futuros Análisis de Sistemas de Información. Lo primero que queremos comentar es que, a pesar de que pueda resultar algo trivial, o incluso banal, esta fase es fundamental para nuestro proyecto, pues todo lo que hagamos ahora será la base del futuro sistema, con lo cual las decisiones que tomemos habrán de ser consistentes, pues un pequeño cambio en este punto puede suponer un cambio inasumible en fases posteriores.

A continuación os vamos a mostrar algunas de las recomendaciones que distintos miembros del equipo dan en base a su experiencia como Analistas:

"Realizad un gráfico de bajo nivel que contemple las distintas funcionalidades que posee el sistema, de tal forma que, posteriormente, la extracción de los distintos Casos de Uso resulte notablemente más sencilla y, por extensión, esto se vea reflejado también en la fase de obtención de requisitos."

"Revisad la descripción de los requisitos. Por un lado es fundamental comprobar que ésta describe correctamente la funcionalidad que se pretende plasmar, y por otro, se ha de intentar definir cualquier término que pueda presentar ambigüedad, con el fin de hacer que el cliente tenga una comprensión clara de lo que se dice y que tenga la sensación de que realmente se está entendiendo lo que él desea."

"Centrad el diseño conceptual en las funcionalidades básicas de la aplicación, sin preocuparse demasiado por las posibles variaciones que podría tener el diseño según la tecnología utilizada. Es muy importante que el diseño de clases (modelo conceptual) sea adaptable a cualquier tecnología."

"Se debe dedicar una gran cantidad de tiempo en realizar un análisis en profundidad de los requisitos, cubriendo todas las funcionalidades que se describieron en la oferta y que el cliente querrá que estén reflejadas en el futuro sistema."

"Sentaos tranquilamente y revisad que los distintos módulos del Análisis son consistentes. El trabajo en paralelo es fundamental, pero muchas veces cada uno interpreta las cosas de una manera y pueden aparecer errores que a la postre pueden resultar fatales. No es necesario mucho tiempo, pero sí estar seguros de que nuestra parte concuerda con las demás."

Bueno, esperamos que estos consejillos puedan seros de ayuda y que os eviten alguna versión de más.