Ingeniería de Software

Gestión de proyectos para novatos

2011-12-31T15:30:00.000+01:00

Sé que en un post escrito el día 31 de diciembre se debería hacer retrospectiva del año, pero hay veces que es mejor tener una cierta perspectiva, que solo el tiempo te da, para analizar todas las aristas de una historia, por eso he decidido escribir sobre otras cuestiones.

Recientemente un amigo que se disponía a encarar su proyecto fin de carrera, después de tenerlo bastante tiempo parado, me pidió consejos que le sirvieran para encarar con éxito los trabajos a realizar. Se trataba de un proyecto para un cliente real, y externo a la Universidad. A partir de aquí me pareció que podría ser interesante escribir sobre ello, ya que podría haber otras personas en su misma situación, también podría interesarle a nuevos freelances, que nunca se han enfrentado en solitario a todas las fases de un desarrollo de software, o a jefes de proyecto juniors.

La mayoría de cuestiones que voy a escribir pueden resultar obviedades, pero en este tipo de tareas hay que ser muy metódico, disciplinado y ordenado, por lo que es muy importante tener estas ideas presentes.

Desde el punto de vista de la gestión de proyectos, éstos tienen las siguientes fases:
• Iniciación,
• Planificación,
• Ejecución,
• Seguimiento y Control, y
• Cierre.

Dirigir un proyecto por lo general implica:
• identificar requisitos,
• abordar las diversas necesidades, inquietudes y expectativas de los interesados según se planifica y efectúa el proyecto,
• equilibrar las restricciones contrapuestas del proyecto que se relacionan, entre otros aspectos, con:

el alcance,
la calidad,
el cronograma,
el presupuesto,
los recursos y
el riesgo.

Podría extenderme mucho si tuviera que detallar cada unos de los subprocesos y las herramientas para llevar a cabo con éxito estos procesos, pero no es objeto de este artículo. En este artículo quiero dar un enfoque muy ágil que evite la mayoría de los problemas que llevan a un proyecto de desarrollo software al fracaso.

La iniciación debe comenzar con una reunión de arranque de proyecto, o una reunión de toma de requisitos iniciales. Una reunión debe tener una hora de inicio, una hora de fin, y unos objetivos claros. Es responsabilidad del jefe de proyecto marcar los tempos de la reunión. En este sentido, es importante tener seguridad en uno mismo, al fin y al cabo, tu eres el experto, y llevas preparada la reunión.

Afrontándolo desde un punto de vista ágil, a medida que transcurre la reunión hay que pensar en las pantallas, formularios... detectar qué posibles problemas pueden surgir, y adelantarse a ellos. Tu opinión tiene que oirse como la de un experto. Hay ocasiones en el que el usuario no tiene claro lo que quiere, o no sabe detallarlo, o no sabe que la tecnología le permite optimizar procesos. El jefe de proyecto debe convertirse en el socio tecnológico del cliente, asesorarle y orientarle.

A partir de un requisito, un experto detecta reglas, validaciones, restricciones, los campos que tendrían las tablas en la base de datos, y las relaciones entre ellos (o en los objetos si se opta por el paradigma de orientación a objetos). Es importante definir también los requisitos en negativo (lo que el sistema no debe permitir), así como los requisitos no funcionales relativos a usabilidad, políticas de seguridad, matrices de compatibilidad de navegadores o sistemas operativos... Es vital definir bien los requisitos, para no propagar errores al resto del desarrollo.

Es muy importante cerrar bien el alcance. No se puede cerrar un proyecto sin alcance... siempre parecerá inacabado. En este sentido, sería conveniente plantear en siguientes fases pruebas de aceptación del sistema, que definan objetivamente cuando el proyecto se ha terminado.

En el momento de la recogida de requisitos, se debe pensar en un entregable base completamente funcional. Los adornos y "florituras", es conveniente derivarlos a una segunda fase. A medida que la reunión avance, sobretodo si hay más de una persona, irán pidiendo más y más funcionalidades, algunas accesorias y no imprescindibles para el funcionamiento base de la aplicación. Hay que equilibrar los intereses de los participantes, y detectar las partes críticas para el proyecto. Just in time: ocúpate solo de tu problema de ahora... el de después ya tendrás tiempo para solventarlo en el futuro.

En el caso de que a estas alturas aun no haya precio cerrado, el cliente tendrá mucho interés en saber cuánto le va a costar. Mi consejo es no dar nunca un precio en caliente. Esto debe hacerse de manera meditada, junto con el equipo que vaya a participar en el proyecto, haciendo estimaciones temporales, asignación de recursos...

Un objetivo importante de la reunión debe ser sensibilizar al propio cliente de lo importante que es para el éxito del proyecto que le dedique tiempo para pruebas, validaciones... al fin y al cabo es su proyecto, y nuestro interés es entregarle un aplicativo que realmente sea de su gusto.

Al finalizar la reunión, es importante redactar un acta con los participantes, temas tratados y compromisos adquiridos, a ser posible con fecha de cumplimiento. Lo que se habla queda en el aire... estas serán tus armas para defenderte dentro de x meses, cuando el cliente no se acuerde de lo hablado (o no quiera acordarse).

A partir de los requisitos, que podemos modelar como historias de usuario, si estamos trabajando con metodología Scrum (por ejemplo: como administrador de la plataforma puedo dar de alta a otros usuarios), sería conveniente diseñar la interfaz de usuario (no es necesario que se entregue con la línea gráfica). Se trata de un pequeño esquema de cómo se mostraría la información y los campos de los formularios, con su navegabilidad... esto después de las iteraciones que sean necesarias, debe ser validado por el cliente.

Tus pasos iniciales deberían ser cerrar la propuesta de una arquitectura. ¿Qué piezas has decidido utilizar o integrar?, ¿por qué esas y no otras?, tienes que dominar esto, o el cliente te pillará en un renuncio. Todo el mundo tiene amigos a quién preguntar, tu opinión de experto podría quedar en entredicho.

Para la fase de programación o desarrollo puro, podemos utilizar Scrum, con Sprints de dos semanas. Es importante que al finalizar el Sprint seas tu mismo el que muestre el entregable (o el equipo que lo ha desarrollado), y las funcionalidades implementadas. Utilizando Scrum, conseguirás no tener un desfase grande en tiempo y no defraudarás las expectativas del cliente, porque él irá viendo paso a paso lo que se está construyendo, y podrá opinar desde el principio sobre ello.

En la disciplina de la gestión de proyectos hay mucha teoría. Yo he intentado darle un enfoque práctico a partir de mi experiencia a lo largo de los años. El aprendizaje debe ser continuo. Si pensáramos que ya lo sabemos todo, no podríamos mejorar, ni evolucionar. En este sentido, al 2012 le pido cometer nuevos errores, y no repetir los anteriores.

Feliz 2012 a todos.

Reflexiones sobre el desarrollo de aplicaciones móviles

2011-12-07T20:00:00.000+01:00

Ahora mismo existen distintos mercados diferenciados dentro de las aplicaciones móviles. Hace relativamente poco tiempo, las empresas que desarrollábamos aplicaciones móviles, buscábamos realizar un solo desarrollo multiplataforma, y que valiera para el mayor número de dispositivos posible. Esto se intentaba mediante tecnología Java J2ME. En este post hice una pequeña introducción.

El coste de desarrollar estas aplicaciones era altísimo, ya que siempre había que realizar adaptaciones para sacar el mayor rendimiento de cada dispositivo, y aun así no se conseguía. Cada fabricante instalaba una máquina virtual distinta, había particularidades a la hora de gestionar cada pila de Bluetooth... toda una odisea.

Actualmente hay distintas plataformas diferenciadas y las empresas optan por desarrollar aplicaciones nativas para cada plataforma. Los clientes suelen pedir que la aplicación funcione en distintas plataformas, para así llegar al mayor número de usuarios posibles. Si las empresas desarrolladoras no tienen el know how para desarrollar la aplicación en las plataformas requeridas, se suelen buscar alianzas para completar los servicios ofrecidos. Pero el planteamiento es utilizar tecnología nativa para cada puerto de la aplicación.

El mercado mundial actual, en cuanto a smartphones se refiere, lo copan las plataformas Android, iPhone, y Blackberry. Aun hay un parque bastante amplio de dispositivos Symbian pero, además de estar en el límite de lo que hoy denominamos smartphones, están en claro retroceso. Para ilustrar estas afirmaciones, podemos ver el artículo de Poder PDA basado en las estadísticas de Gartner del tercer trimestre de 2011. Cabe reseñar que Windows Phone 7, actualmente tiene una cuota de mercado bastante pequeña probablemente motivada por lo tarde que llegaron al mercado.

Blackberry tradicionalmente ha tenido una cuota de mercado amplia en dispositivos de empresa. La larga duración de la batería (cuando trabajamos, no nos podemos permitir el lujo de agotar la batería en 4 horas, sobretodo si estamos desplazados), su correo push, la seguridad (Blackberry implementa por omisión distintos protocolos de seguridad), o cuestiones relacionadas con la usabilidad (teclado qwerty físico, muy apropiado para escribir muchos correos), son factores que han influido en que las empresas eligieran Blackberry. Otro motivo importante, que no tiene que ver con la tecnología, y sí con el canal de distribución, es la apuesta que realizan las operadoras con respecto a los terminales que facilitan. Si Vodafone, o Movistar en España optan por favorecer la distribución de un modelo concreto, influirá decisivamente en las estadísticas de cuota de mercado. Esto último puede que sea factor clave en el avance de iPhone en usuarios de empresa.

Hasta la fecha, la mayoría de proyectos de desarrollo Blackberry que hemos llevado acabo en el Departamento de Ingeniería de Software de Soltel IT Solutions estaban orientados a soluciones empresariales, es decir desarrolladas por la empresa, para la empresa (modelo de negocio B2B). Sin embargo hemos recibido peticiones de proyectos Android y iPhone, cuyo usuario final, es el consumidor de a pie (modelo de negocio B2C). Esta separación, cada vez es menos evidente, ya que iPhone se está extendiendo en el entorno empresarial, y Blackberry ha intentado acercarse al gran público con dispositivos de gama media, como la Curve y aplicaciones como Blackberry Messenger, con gran aceptación entre los más jóvenes.

Android mantiene una cuota relevante en el mercado. Hay factores que han influido en que proliferen aplicaciones de esta plataforma, como por ejemplo, el ser una apuesta de Google, haber dispositivos potentes de varios fabricantes como HTC y Samsung, ser nativo Java, tener un SDK (Software Development Kit) abierto, con grandes facilidades para publicar en Android Market...

No podemos perder de vista la alianza subscrita entre Microsoft y Nokia (dispositivos Nokia con sistema operativo Windows Phone). En mi opinión, más allá de la calidad del producto, han llegado muy tarde, y puede que ya no haya pastel que repartir.

El mundo de la tecnología es cambiante. El pasado es hace dos años, y el futuro es dentro de un minuto. Esto se acentúa en la tecnología móvil, donde los cambios son constantes. Una empresa experta en desarrollo de software para móvil, no puede permitirse el lujo de no conocer las plataformas más importantes que copan el mercado, aunque estas queden fuera de su stack tecnológico. Por otro lado las librerías y frameworks que los fabricantes ponen a disposición de desarrolladores hacen que el escalón entre el desarrollo de una aplicación móvil y una web o de escritorio se reduzca.

No todo el mundo vale

2011-10-31T14:36:00.000+01:00

Desde la división de ingeniería de software de Soltel IT Solutions, buscamos perfiles para formar parte de nuestro equipo. Lo que buscamos no es fácil de encontrar, pero lo que ofrecemos, tampoco.

¿Qué buscamos?

Buscamos perfiles que no desentonen técnicamente con los que actualmente conforman nuestro equipo.

Esto no es poco, ya que es un equipo que desde 2008 ha sufrido poca rotación, y tiene bastante experiencia en el desarrollo de aplicaciones dentro de nuestro stack tecnológico. Además, y al contrario que lo que puede ocurrir en otras empresas, necesitamos que los técnicos sean resolutivos en los avatares que suelen surgir dentro de un desarrollo, desde instalación y configuración del entorno, hasta la puesta en producción. Es por ello que la gente que trabaja con nosotros suele estar muy bien preparada.

En España suele ser habitual tener que cambiar de categoría para poder subir el salario. En nuestro departamento, no obligamos a nadie a hacerse Analista o Arquitecto si lo que le gusta es programar. También es cierto que en EEUU el concepto de desarrollador es más amplio, ya que el mismo perfil tiene capacidades de análisis, arquitectura, y programación. Esto es lo mismo que requerimos nosotros. Se trata de evaluar a partir de indicadores objetivos que nos señalan en qué rango salarial debe encontrarse un desarrollador. Estos indicadores recogen desde buenas prácticas a tareas que, en una empresa convencional, realizaría un arquitecto, o un analista, y son capaces de medir el nivel de madurez que tiene un técnico. Como comentaba, nosotros trabajamos con el concepto más amplio de desarrollador.

Otros de los factores que intervienen decisivamente en el éxito de un equipo de desarrollo de software es el buen ambiente. Nuestra filosofía de trabajo, Ubuntu, ayuda a que entre nosotros reine el buen "rollo" (permitidme la expresión). Es por esto que tenemos que ser muy cuidadosos y no introducir ningún elemento que distorsione el ambiente de la oficina, por lo que el carácter del candidato debe encajar con el de los integrantes del equipo.

La palabra "equipo" está intencionadamente remarcada en negrita en el párrafo anterior. Se puede ser muy bueno técnicamente, tener capacidades de análisis y arquitectura, una interlocución válida con clientes, y ser un crack en cuanto a cumplimiento de estándares y buenas prácticas, pero el concepto de "equipo" pesa y mucho para nosotros. El proceso de construcción de software no es un acto individual, así que el comportarse como un equipo es una obligación. Ser un equipo conlleva sacrificio, colaboración, y sobretodo solidaridad. El equipo tiene unos objetivos comunes, los fracasos no son individuales, sino de todo el equipo. Es fundamental que los miembros del equipo tengan ilusión por sacar el proyecto común adelante. Los retos son ilusionantes, y los sacrificios deben merecernos la pena.

Buscamos gente a la que le apasione la tecnología. Hay personas que no tienen capacidad de sacrificio, y que lo que anhelan es acabar la jornada laboral a la hora que le corresponda y olvidar cualquier problema que haya en un proyecto, sea cual sea la situación de este. Obviamente, desde el departamento intentamos que los proyectos no tengan desviaciones, todos marchen según la planificación, y proteger sobremanera a los integrantes del equipo. Desgraciadamente, esto no siempre ocurre, pese a que es el propio equipo el que planifica sus entregas, como ya escribí en este artículo sobre Scrum. Obviamente el compromiso por los plazos propuestos y la profesionalidad del equipo debe prevalecer sobre una desgraciada planificación. Por otro lado, a veces nos encontramos con factores ajenos al trabajo técnico que pueden obligarnos a hacer un sobreesfuerzo. Como he comentado intentamos minimizar el número de complicaciones, pero valoramos que el equipo se comporte como tal cuando esto ocurra.

Nos gusta la gente que en su tiempo libre participa en Comunidades de Software libre, lee noticias tecnológicas, sigue blogs técnicos, en definitiva, como comentaba anteriormente, nos gusta que la gente que trabaja con nosotros sea apasionada de la tecnología. Nos encanta la gente que llega con propuestas o iniciativas para mejorar cualquier faceta de nuestra vida profesional. Sabemos que todo el mundo no tiene esta capacidad, y que esta forma de vivir requiere de más esfuerzo que cumplir un horario en una megaconsultora.

En los tiempos que corren, se está produciendo una selección natural de empresas. Solo las más fuertes supervivirán. Creo que es bueno que tomemos nota sobre esto los profesionales del sector, porque de igual manera solo los más fuertes sobrevivirán.

¿Qué ofrecemos?

En nuestro equipo ofrecemos la oportunidad de trabajar en un proyecto de departamento de lo más ilusionante, en el que gracias a nuestra capacidad, temperamento y perseverancia estamos superando la crisis. Un sitio donde se respira buen ambiente, donde los trabajadores no son un número, gozan de flexibilidad en todos los sentidos, y su opinión cuenta. Ofrecemos la posibilidad de aprender y trabajar con un equipo multidisciplinar de alto nivel, y poder aumentar tu salario sin dejar de hacer lo que te gusta. Ofrecemos estabilidad. Te ofrecemos formar parte de nuestra familia.

Viaje a Polonia

2011-10-28T20:37:00.001+02:00

Polonia es uno de los países que están dentro de los planes de internacionalización de Soltel. En septiembre surgió la oportunidad de realizar una misión comercial, y no quisimos desaprovechar la ocasión para enseñar allí nuestro producto de gestión de multas a través de dispositivo móvil, SolKar.

Antes de hacer negocios en un país resulta esencial realiza tareas de prospección del mercado. Se trata de conocer de primera mano una serie de cuestiones, como por ejemplo, costumbres, legislación laboral, formas de pago, impuestos,... estas y otras cuestiones pude conocerlas de primera mano durante mi estancia en Polonia.

Polonia actualmente ya está recibiendo muchísimos millones de euros en concepto de fondos estructurales europeos, por lo que el país está experimentando una transformación a todos los niveles. Solo hay que darse una vuelta por el KPT (Parque Tecnológico de Cracovia), para ver como han proliferado las empresas del sector IT.

Probablemente Polonia tenga que recorrer el mismo camino que recorrió España cuando éramos nosotros los beneficiarios de este tipo de fondos. Por ello, las empresas españolas podemos aportar mucho a las empresas y administración polacas. Tenemos el Know How, tenemos las aplicaciones, ¿por qué construir de nuevo la rueda?

Gestor documental Alfresco vs sistema de archivos

2011-09-27T18:12:00.000+02:00

En muchas ocasiones, antes incluso de tener que justificar por qué implantar Alfresco y no otro gestor documental, debemos argumentar a nuestros clientes qué ventajas les aporta usar Alfresco sobre su habitual forma de trabajo, que es, casi siempre, utilizar carpetas en el sistema de archivos de un servidor.

Estos son los argumentos que solemos dar en Soltel:

- Facilidad de explotar la documentación desde otras aplicaciones. Alfresco tiene una API potente a través de la cuál podemos sacar el máximo partido de éste cuando lo integramos con otras aplicaciones.

- Acceso a la información desde cualquier lugar, a cualquier hora y desde múltiples dispositivos (PC, Dispositivos móviles, Tablets, etc.). Toda la información que necesitamos se encuentra en la red y debidamente protegida. Solo necesitamos una conexión a internet. Ya no hacen falta ni VPNs, ni escritorios remotos.

– No es necesario el acceso al sistema operativo anfitrión, evitando que usuarios puedan visualizar aplicativos o información que no le corresponden.

– Permite la creación de usuarios y asignar permisos de visión de documentación sin necesidad de crear usuarios en el dominio ni asignar permisos sobre el sistema de archivos.

– Permite versionado de información sin necesidad de recurrir a aplicativos de terceros.

– Facilita la copia de seguridad.

– Facilita la búsqueda de información. Este argumento es uno de los más importantes ya que la manera en la que indexa los contenidos Alfresco, propicia búsquedas muy rápidas, que por tanto ahorran tiempo a nuestros clientes.

– Custodia documental. Aumenta la seguridad de la documentación, los archivos se suben al gestor documental no al sistema de ficheros por lo que los archivos no quedarían por ejemplo infectados por virus en caso de que el sistema operativo se infecte.

– Posibilidad de envío de documentos seguros por correo electrónico, enviando la url del documento. Sólo los usuarios con acceso podrán visualizar el documento.

– Facilita el trabajo en equipo. Subir documentación, versionarla y compartirla con las personas que trabajan en el mismo equipo facilita el flujo de la información dentro de la empresa.

– Centralización de la información. La información se centraliza en una única herramienta lo que evita la casuística común de que cada usuario tiene la información en su equipo.

– Alfresco es software OpenSource y cuenta con una reputada comunidad lo que garantiza la calidad del producto, por ello ha sido implantado en gran cantidad de organizaciones como gestor documental.

– Reducción de costes. Ya no es necesario trabajar con documentación física, todo queda almacenado en el gestor documental.

- Posibilidad de crear flujos de trabajo sobre un documento.

- Con Alfresco se puede automatizar, mediante plantillas, la creación de estructuras que se repiten en el tiempo, por ejemplo, la documentación de calidad de los proyectos.

¿Aun no usas Alfresco para gestionar los documentos de tu empresa?, ¿a qué estás esperando?

¿Por qué usar un software BPM?

2011-05-13T19:23:00.000+02:00

A partir de mi artículo sobre el BPM Bonita Open Solution, he recibido multitud de consultas relacionadas más con el uso de software BPM en general que con Bonita en particular. Es por ello que me he decidido a escribir este post.

¿Qué es BPM?

Según Wikipedia: Se llama Gestión de procesos de negocio (Business Process Management o BPM en inglés) a la metodología empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión de los procesos de negocio, que se deben modelar, organizar, documentar y optimizar de forma continua. Como su nombre sugiere, BPM se enfoca en la administración de los procesos dentro de una organización.

Un software BPM da soporte completo al ciclo de vida de un proceso de negocio: análisis, modelado, ejecución y monitorización de los procesos.

Una vez está funcionando el software, es una secuencia estructurada de tareas, algunas de las cuales pueden realizarse en paralelo. Lo que se conoce como Workflow.

Por tanto es un concepto que se asocia a gestión empresarial, estrategia, flexibilidad, y por qué no, agilidad (reconfigurar los procesos).

¿Por qué usar un software BPM?

Porque permite a las empresas definir formalmente sus procesos, analizar los tiempos que tardan en ejecutarse, tener visibilidad en tiempo real de todo lo que está ocurriendo en la empresa, detectar los overhead, los cuellos de botella, desviaciones y procesos redundantes...

Un software BPM debe permitir la redefinición de procesos de manera ágil y efectiva. Por tanto supone someter a las empresas a procesos de mejora continua. Ante una posible revisión de la estrategia, la redefinición de procesos, no sería dramática.

Las aplicaciones basadas en BPM también reducen las tareas humanas pudiendo ejecutar procesos de manera automática. La automatización conlleva una reducción de errores humanos.

Las organizaciones que optan por la implantación de BPMs consiguen:
- Mejorar la atención y servicio al cliente.
- Minimizar el tiempo requerido por los participantes para acceder a la documentación, aplicaciones y bases de datos.
- Incrementar el número de actividades ejecutadas en paralelo.
- Mejorar la participación y colaboración de todo el personal en los procesos.
- Optimizar los recursos personales y físicos.
- Mejorar la gestión y supervisión de la empresa.
- Reducir errores.
- Vertebrar las integración del resto de herramientas corporativas.

Con todo ello, se consiguen los objetivos finales de las empresas, que son aumentar beneficios y reducir costes.

Liferay Hispano

2011-05-10T13:47:00.004+02:00

Acaba de salir a la luz lo que pretende ser la nueva comunidad Liferay para hispano hablantes.

Las secciones más interesantes que se incluyen en esta primera versión Beta son:

- Foro
- Descargas (hace falta registro para visualizar el contenido)
- Noticias

Podéis acceder a través de los siguientes enlaces:
www.liferayhispano.com
www.liferayhispano.es
www.liferayhispano.org

¿Por qué Yii Framework?

2011-05-06T22:40:00.001+02:00

En Soltel presumimos de tener una actitud innovadora, que nos obliga a probar las distintas tecnologías que van llegando al mercado, y que ajustándose a nuestro stack, puedan mejorar en algo nuestros desarrollos.

Una vez analizado el framework o librería, lo probamos en proyectos internos que nos permitan conocer con más detalle sus características. En este trabajo de campo es donde realmente se decide si es interesante o no añadir el framework a nuestro stack, y con ello ofrecerlo en los desarrollos que realizamos para nuestros clientes.

En este proceso, llevábamos bastante tiempo buscando un framework PHP que realmente aportara valor y se adecuara en tiempos de desarrollo, rendimiento y arquitectura a lo que necesitamos ofrecer en nuestros proyectos. Ya habíamos descartado frameworks como Prado, por ser bastante pesado y tener una arquitectura demasiado compleja.

Con Yii, sin embargo, nos hemos llevado una agradable sorpresa. Yii es un framework PHP, libre (licencia BSD), basado en programación orientada a objetos y que implementa el patrón de diseño MVC (Modelo-Vista-Controlador) el cuál es ideal para la programación Web. Fue diseñado por el creador de Prado, por lo que ha evitado los errores cometidos en la implementación de este framework.

Puede ser utilizado para todo tipo de aplicaciones Web. Es adecuado para desarrollar aplicaciones de gran tráfico como portales, foros, sistemas de administración de contenidos (CMS),... gracias a sus soluciones de caché sofisticadas.

Con las opciones de caché activadas, Yii puede soportar nueve veces más peticiones por segundo que Prado. Dejando al margen el caché, sigue ofreciendo mejores prestaciones (en este caso Yii multiplica por cuatro las peticiones que puede soportar Prado).

Otro de los motivos por los que Yii es tan rápido es gracias a la carga perezosa de funcionalidades en memoria. Es decir, las librerías no se cargan hasta que se tienen que utilizar. Esta técnica ha posibilitado que Yii de excelentes prestaciones en los distintos benchmarks realizados.

Otra de sus características es que viene integrado con jQuery y con una serie de widgets Ajax que el desarrollador puede ampliar a su gusto para mejorar la usabilidad y la experiencia del usuario.

Yii soporta generación automática de servicios web basados en complejos WSDL, así como estándares para internacionalización I18N y localización L10N.

Nos proporciona soporte para crear y ejecutar pruebas unitarias y funcionales basadas en PHPUnit y Selenium.

El desarrollo de una aplicación consta de tres pasos:

1. Creación de la base de datos
2. Generación del código PHP
3. Personalización del código.

Este framework nos permite generar el código de la capa de acceso a base de datos así como la capa vista a partir de las tablas de la base de datos. Yii incorpora una poderosa herramienta, Yiic, que nos permite generar los CRUD de todas las tablas de nuestra aplicación sin tener que escribir una sola línea de código. Después de este paso solo nos queda personalizar el código generado por Yii para adaptarlo a los requisitos de nuestra aplicación.

Yii cuenta con una documentación muy completa y en varios idiomas, además de una comunidad muy activa.

Estamos a punto de entregar nuestro primer proyecto desarrollado con Yii Framework, y la experiencia es más que satisfactoria. Por todo ello, Yii se ha ganado un lugar privilegiado dentro de nuestro stack tecnológico.

Trabajando en Equipo: Filosofía Ubuntu

2011-04-29T20:03:00.000+02:00

Uno de los parámetros fundamentales para el éxito de un equipo es su filosofía de trabajo. En esto el director puede influir, pero como en todo lo que se hace en equipo, se necesita la contribución de cada miembro.

Una buena forma de empezar el día es dando gracias por lo que tenemos. Realmente somos unos afortunados por poder trabajar en lo que nos gusta, por estar rodeados de un grupo fantástico de profesionales de los que se puede aprender constantemente.

La pregunta que me hago a diario es:

¿Cómo puedo contribuir a mejorar este lugar de trabajo?

Por eso es un proceso que nunca termina. Siempre hay que buscar como mejorar. En este sentido hemos detectado una serie de parámetros que contribuyen a la mejora del ambiente de trabajo, y por tanto en los resultados que se obtienen. A saber:

Confianza: esto no es algo que se regala, esto es algo que se gana día a día gracias a la responsabilidad y la profesionalidad demostrada. Si hay algún miembro del equipo que no goza de la confianza de los demás, el equipo tiene una debilidad.

Triunfo personal: espero que cada uno triunfe, porque el éxito de cada persona, redunda en el bien del grupo. Necesitamos gente con hambre y ganas de mejorar, aunque sin perder de vista que el éxito del grupo está por encima del individual.

Honestidad: política de transparencia total. Todo el mundo está al tanto de lo que se cobra por cada proyecto, las horas que hay presupuestadas, y lo que supone en dinero los retrasos. Se trata de ser honesto con uno mismo, y con el compañero.

Reconocimiento y recompensa: Hay que agradecer y celebrar los logros individuales, porque suman en los objetivos colectivos.

Respeto: Hay algunos profesionales que merecen respeto, pero todas las personas deben ser respetadas como tal, aunque no merezcan ser respetados como profesionales. Por tanto el respeto personal debe estar por encima de todo. Las formas son importantes. Las malas formas te hacen perder la razón de inmediato. No hay nada que no se pueda decir con educación y respeto.

Comunicación: Hay que estar abiertos a la crítica. Es la única forma de mejorar, y ser conscientes de nuestras carencias. No solo hablamos de nuestra vida en el trabajo, sino de nuestra vida personal. Abrirnos a los demás es un buen ejercicio que repercute en el buen ambiente. Quiero saber qué les interesa a mis compañeros, qué les importa (familia, aficiones, metas...). Obviamente, respetamos a los que no quieran abrir su vida al resto (volvemos al párrafo anterior: respeto). Mi reto en este sentido es escuchar más y hablar menos.

Diálogo: No imponemos nuestros criterios haciendo valer nuestro rango o cargo. Aquí importan los argumentos.

Flexibilidad: Como hemos comentado antes, tenemos "confianza". El confiar en la responsabilidad y la profesionalidad del resto de compañeros, nos permite ser flexibles. Somos personas, no un número de trabajador.

Si queréis profundizar más en esta filosofía de trabajo, podéis leer el libro Ubuntu, de Stephen Lundin y Bob Nelson. Se trata de una fábula sobre la filosofía africana del trabajo en equipo basada en el concepto de hermandad, y que se corresponde totalmente con nuestra filosofía de trabajo.

Haciendo Métrica v3 un poco más ágil

2011-04-22T19:48:00.009+02:00

Para seguir este post, quizás sea interesante leer estos otros antes:
- Métrica v3 vs Metodologías Ágiles
- Scrum para Dummies

Soy consciente de que es más beneficioso no tener que realizar este tipo de adaptaciones, y trabajar directamente con metodologías ágiles, pero algunas veces nos vemos obligados a ello por los requerimientos del cliente de trabajar con otro tipo de metodologías más pesadas (sobretodo si es Administración Pública), y no por ello vamos a renunciar a una forma de trabajar (internamente, en este caso) que nos ha traído grandes beneficios.

En este post voy a aportar el enfoque que le damos a estos proyectos en la División de Ingeniería de Software de Soltel.

Me centraré en la adaptación que realizamos en fase de análisis, y su posterior aprovechamiento en las distintas fases del desarrollo. Los más puristas dirán que lo que hacemos no es Scrum, ya que ni tenemos alta implicación del cliente, ni podemos enseñarle "producto" desde la primera iteración. Coincido, así que en este caso, no lo llamaremos Scrum.

El documento de análisis en Métrica v3 es el ASI (Análisis del Sistema de Información). Creo que lo más conveniente es empezar apuntar las actividades y artefactos que tiene nuestro ASI:

Catálogo de Requisitos:
Requisitos Funcionales

Requisitos de Información

Restricciones y Reglas de Negocio

Requisitos No Funcionales

Catálogo de casos de uso:
Modelo de Casos de Uso

Especificación de Casos de Uso

Modelo de Clases de Análisis

Matrices de Trazabilidad

Peticiones de cambio

Como observamos, todo estos componentes nos van a generar muchísimo trabajo, por lo que debemos optimizar al máximo para reaprovechar todo lo que podamos. Empezaremos por los Requisitos Funcionales.

¿Qué pasa si escribimos los requisitos funcionales como si fueran historias de usuario? Métrica no es prescriptiva al respecto, por lo que al final se traduce a un problema de granularidad. Nuestros requisitos funcionales conformarán nuestro Product Backlog. Así, cuando termine la fase de análisis, podremos estimar los sprints, y empezar a usar Scrum.

Por otro lado, merece la pena invertir tiempo en los Requisitos de Información. Si los describimos bien, automáticamente tendremos el Modelo de Clases de Análisis.

Al final, cada equipo de trabajo debe buscar la forma de trabajar que más le aporte, aunque no le podamos poner el cartelito con el nombre de la metodología de moda. A nosotros esta pequeña adaptación nos ha servido.

¿Y tu?, ¿cómo haces Métrica v3 más ágil?

Bonita Open Solution, mi BPM

2011-03-22T20:16:00.007+01:00

En la División de Ingeniería de Software de SOLTEL estamos ultimando los trámites para hacernos partners de Bonita Open Solution. Como podréis imaginar este tipo de decisiones estratégicas no se toman a la ligera, y son fruto de un minucioso análisis de las distintas soluciones BPM (Business Process Management) que hay en el mercado.

Dado que nuestro stack está fundamentado en tecnologías Opensource, desde un principio descartamos modelos comerciales como Tibco (Staffware), Savvion, Lombardi,
PegaSystems, Appian, Global 260, o los de grandes fabricantes como Oracle o IBM. También nos encontramos con algunos "falsos" Open Source como Intalio, Active Enpoints, Shark.

Por otro lado, tampoco nos valía un simple framework del tipo ODE, OpenWFE. Bonita no es un framework, es una solución completa:

Bonita Studio: diseñamos y desarrollamos los procesos. Nos permite dibujar el negocio y la capa web. Está basado en Eclipse.

Bonita User Experience: es la capa web, desplegaremos y veremos los procesos desarrollados con Bonita Studio. Se divide en dos partes independientes, formularios de los procesos y un portal genérico que es la cuenta User Experience Inbox. Es un punto de acceso central para que los usuarios puedan ejecutar sus tareas y procesos.

Engine: donde se ejecutan los procesos. Bonita Execution Engine. 100% Java y se apoya en la BD para ejecutar los procesos.

Una de las virtudes fundamentales de Bonita es que ahorra costes en el desarrollo, y por tanto repercute en el precio final del proyecto.

Su interfaz gráfica es muy intuitiva, y podemos modelar y orquestar procesos de negocio a alto nivel de manera eficiente y ágil. A los usuarios de Eclipse les resultará bastante familiar, ya que el componente Designer está basado en este IDE. De hecho recientemente ha ganado el premio de mejor herramienta de modelado basada en Eclipse.

Por otro lado tampoco es desdeñable la posibilidad que nos ofrece de realizar transacciones, autenticación basada en roles y ciclo de vida de aplicaciones.

Otra ventaja es sin duda su arquitectura J2EE que nos permite por ejemplo usar la solución en cluster.

Por supuesto, cumple con el estándar BPMN (esto es importante, ya que durante nuestro análisis descartamos otros productos que prometían bastante, como jBPM, pero con un nivel de cumplimiento de estándares muy bajo, a día de hoy, en este sentido).

Pero como buen producto Open Source, su virtud principal es su Comunidad, activa y participativa, y que ha desarrollado múltiples conectores que permiten una integración inmediata con muchísimas herramientas, y facilitan la interoperabilidad de sistemas, es decir, nos ayuda a completar el puzle que es un proyecto basado en la integración de piezas maduras de Software Libre. Como no podía ser de otra forma, nosotros ya hemos realizado nuestro pequeño aporte a la Comunidad con este conector.

Dado que ya hemos terminado nuestro primer proyecto serio con Bonita, y que durante las dos últimas semanas hemos recibido el training oficial de Bonita Soft, nos hallamos en un inmejorable escenario para, en breve, contribuir con más conectores a la Comunidad.

En este video podemos intuir la potencia que tiene la herramienta:

Quiero terminar con la frase de mi amigo Olivier Delcroix: "Ahora ya sabéis porqué se llama Bonita. Porque es la solución BPM más sexy del mercado". ;-)

Ecosistemas Software

2010-04-15T10:15:00.009+02:00

A continuación podéis ver parte de la entrevista que me hizo la revista especializada en el sector Cibersur, y que fue publicada en Abril de 2010. En ella hablamos de Ecosistemas Software.

Concursos Públicos: Una oferta ganadora

2009-06-23T21:08:00.009+02:00

Últimamente me he encontrado bastante ocupado diseñando ofertas para concursos de la Administración Pública, más en concreto para un par de Consejerías de la Junta de Andalucía, para el Ministerio de Trabajo, y he ayudado a un compañero en algunas para Ayuntamientos.

He sacado algunas conclusiones al respecto. Quizás el título del post pueda resultar engañoso, porque no voy a dar las claves de una oferta ganadora. Más bien pretendo hablar de las claves que pueden hacer a tu oferta perdedora, si no las tienes en cuenta.

La primera criba para saber "si vamos o no vamos" es leer con atención el pliego, tanto en su parte administrativa-económica, como en la técnica. Se pueden descartar multitud de pliegos si exigen una certificación administrativa superior a la que tenemos, si exigen certificados de Calidad que no poseemos (en nuestro caso, con el AENOR ISO 9001, solemos tener bastante), o si por la redacción del pliego se puede detectar que este concurso ya está "cocinado". En nuestro argot, "cocinado" quiere decir que ya tiene ganador de antemano. ¿Cómo saber si un concurso ya está cocinado? este es un tema bastante complicado y que daría para escribir muchísimo, de momento lo dejaremos para otra ocasión. Solo destacaré que fijarse en los puntos valorables es una comprobación elemental aunque por supuesto, no es la única que hay que hacer.

De hecho, el estar "cocinado" es el primer motivo por el que no ir a un concurso. Hay otros motivos que si el concurso lo merece se pueden solventar formando UTE con otra empresa.

Uno de los apartados valorables que suelen tener los concursos de Informática es la metodología. Si el concurso es de sistemas o contiene lotes referentes a sistemas, debería aparecer metodología ITIL, si el concurso es de desarrollo, deberá aparecer Métrica v3. ¿Dónde encajan aquí las metodologías ágiles? pues creo que encajan de manera artificiosa, o directamente no encajan. Lamentablemente esta tendencia no ha llegado aun a las Administraciones Públicas. Así que:

- ITIL: Microinformática, Sistemas...
- Métrica v3: Desarrollo.

Hay que adecuar las metodologías a lo que ya hay en el Organismo (Consejería, Ministerios, Ayuntamiento...). Para esto evidentemente tienes que tener alguien "dentro" que te informe, o simplemente llamar, intentar convocar una reunión,... Este tipo de conocimientos se suelen valorar mucho.

Si el concurso es de desarrollo, hay que tener en cuenta las políticas de Software Libre (en el caso de la Junta de Andalucía, y muchos Ayuntamientos).

Un plan de calidad, una buena planificación, y afinar con las mejoras propuestas son detalles que no deben faltar en una buena oferta.

La elaboración de la oferta requiere mucha dedicación (casi 24x7), mucha concentración, y si hay alguien que te lleve todo el tema burocrático-administrativo, miel sobre hojuelas (es una barbaridad la cantidad de "papeleo" que te exigen, y por detalles absurdos te puedes quedar fuera, a no ser que sea subsanable). De un concurso a otro siempre hay puntos que mejorar, así que gracias a la experiencia adquirida cada vez las ofertas son mejores. Por otro lado, hay mucho de copia y pega en cuanto a clausulas de confidencialidad, presentación de la empresa...

También me gustaría hablar de la ley no escrita: "Por mucho tiempo que tengas, siempre habrá nervios y prisas de última hora". Esto es así. Es como en los exámenes de la Universidad, en los que tu estimas el tiempo que te queda para llevarlo bien preparado, por ejemplo una semana. Si te dieran una semana más, te seguiría faltando una semana para llevarlo perfecto. No te preocupes, no hay ofertas perfectas, pero es bueno que seas crítico con tu trabajo. La siguiente te saldrá mejor.

Podría dar muchos más detalles, pero creo que no procede que se hablen de ciertas cosas en un blog. Creo que con lo escrito os podéis hacer una idea sobre la licitación...

Administración Electrónic@ para Dummies

2009-06-10T22:49:00.002+02:00

Este post trata de ser una introducción para aquel que no tenga ni idea de lo que es la Administración Electrónica, y desconozca las plataformas disponibles en la Junta de Andalucía.

La Administración Electrónica supone una oficina virtual para realizar todos los trámites propios de la Administración Pública. Dicha oficina, se entiende que está implementada a través de medios electrónicos e informáticos, que garantizan la validez jurídica y la seguridad.

La Ley 11/2007 de Acceso Electrónico de los Ciudadanos a los Servicios Públicos (LAECSP) reconoce el "derecho de los ciudadanos a relacionarse con las Administraciones Publicas por medios electrónicos" y, junto a ello, establece la "obligación de las Administraciones Públicas de rediseñar sus procedimientos y dotarse de los medios técnicos necesarios para que el ejercicio del nuevo derecho sea plenamente efectivo".

Como consecuencia de esta ley, en la Junta de Andalucía se han desarrollado y mejorado algunas plataformas destinadas a conseguir que el ciudadano pueda realizar "electrónicamente" todos los procedimientos que hacía mediante "papel", presencialmente. De esta forma, el usuario percibirá transparencia sobre los procesos, y una mejora en la calidad de los servicios que la Administración le proporciona.

La tónica general de estas plataformas es que se pueden utilizar en cualquier entorno, independientemente de las herramientas y lenguajes usados para su desarrollo, y su uso es libre y gratuito para cualquier Consejería u Organismo de la Junta o Administración Pública que lo solicite. Algunas de estas plataformas son:

- W@nda:Pretende integrar todas las tramitaciones dentro de la Junta de Andalucía. Es una herramienta que permite al usuario tener una interfaz única en su relación con la Administración, y conocer el estado de su trámite. Dado lo heterogéneos que pueden ser los trámites dentro de una administración tan grande, este proyecto engloba a otros que permiten la integración.
- Trew@: Está englobado dentro del proyecto W@nda. Es el motor de tramitación, es decir el Workflow común para todos los procesos de la administración.
- @Firma: Plataforma corporativa de autenticación y firmado digital a través de certificados digitales.
- Port@firmas: Centraliza en un único punto la firma de documentos electrónicos procedentes de distintos trámites soportados por diferentes aplicaciones.
- @ries: Establece un Registro de Entrada y Salida unificado para toda la Junta de Andalucía.

Como se puede observar todas estas herramientas están pensadas para ser transversales a toda la administración, proporcionando homogeneidad, puntos únicos de acceso, e interoperatividad entre organismos y sistemas de información. Estas herramientas, poco a poco están sustituyendo a la verticales de cada Consejería, en su mayoría desarrolladas como proyectos a medida que nacen y mueren en el propio Organismo. Considero que es muy interesante este concepto de reutilización, que en la teoría permitirá a las Administraciones ahorrar costes. Otra cuestión para debatir sería el grado de aceptación del ciudadano con respecto a estas herramientas. De esto precisamente, habla en este post Manuel Recena.

Conociendo iPhone/iPod Touch

2009-06-03T00:43:00.002+02:00

Después de algunos posts sobre movilidad, hay algunos de vosotros que me habéis preguntado por la programación del iphone y iPod Touch.

Las plataformas más usuales son Symbian (Nokia, Sony Ericsson, PSION, Samsung, Siemens, Arima, Benq, Fujitsu, Lenovo, LG, Motorola, Mitsubishi Electric, Panasonic, Sharp), Rim (Blackberry), Windows Mobile (varios fabricantes, como HTC, Samsung, HP), Google Android (HTC, Samsung), iPhone OS (iPhone / iPod Touch). Con Java, podemos desarrollar aplicaciones para Symbian, Rim, Android (con su SDK) y Windows Mobile. Cierto es que para Windows Mobile, por ejemplo, yo prefiero usar .NET, siempre que no tengamos como Requisito No Funcional que la aplicación sea desarrollada en software libre. Para el iPhone resulta muy complejo el desarrollo en Java, más por problemas de licencia, que por cuestiones técnicas. Por ello, lo mejor es usar Objective-C.

Particularidades del iPhone / iPod Touch

- Pantalla con resolución de 480x320px
- Una sola aplicación capta el foco, las demás permanecen cerradas.
- Memoria RAM escasa. Hay que tener presente que hay que liberar recursos cuando no hacen falta (en Java este proceso es automático)
- Hardware adicional: GPS, acelerómetro, teléfono...
- Es posible acceder a datos PIM: correo, contactos,...

Aplicaciones para iPhone: AppStore
En el AppStore se pueden encontrar todas las aplicaciones para iPhone. Se trata de un gran repositorio de programas.
En él, se pueden encontrar aplicaciones gratuitas y de pago (en este caso, el 30% de cada venta va a parar a Apple), y funciona de forma similar a como lo hace iTunes, generando un beneficio de 430 millones de dólares y realizándose más de 1000 millones de descargas.

Para poder publicar en AppStore hay que tener una licencia de desarrollador que viene a salir por unos 80 euros. La aplicación que desarrollemos deberá cumplir las Condiciones de Uso, que en ocasiones es bastante restrictiva, por ejemplo, se han desestimado aplicaciones por suponer competencia de la análoga de Apple.

Arquitectura

Foundation Framework son las clases básicas para programar, común al Macintosh y al iPhone / iPod.

Cocoa Touch Framework gestiona, entre otras cosas, los eventos y la interfaz táctil. Es exclusiva a iPhone / iPod.

Objective-C es parecido a ANSI C, pero su sintaxis está extendida a Orientación a Objetos. Se trata de un lenguaje muy expresivo, para hacernos una idea, esta sería la declaración de un método:

-(NSArray *) listaCiudadesMayoresDe: (NSNumber *)kilometros delPais: (NSString *)pais;

No existe el control de acceso a los métodos, ya que todos son "public".
Otra particularidad del lenguaje es que todos los objetos vienen referenciados por su puntero. Por tanto tendremos que prestar especial atención a reservar memoria y liberarla cuando ya no sea necesaria.

Esto solo son las bases para el que quiera adentrarse en este mundo del desarrollo de aplicaciones para iPhone, que es bastante peculiar, comparado con la programación del resto de plataformas.

Introducción a J2ME

2009-05-26T23:56:00.002+02:00

J2ME es la plataforma enfocada a la aplicación de la tecnología Java en dispositivos electrónicos con capacidades computacionales y gráficas muy reducidas, tales como teléfonos móviles, PDAs o electrodomésticos inteligentes. Esta edición tiene unos componentes básicos que la diferencian de las otras versiones, como el uso de una máquina virtual especial (debido a que requiere sólo unos pocos Kilobytes de memoria para funcionar) en vez del uso de la JVM clásica, inclusión de un pequeño y rápido recolector de basura y algunas otras diferencias. Es una buena opción en software libre para movilidad.

Este esquema, puede considerarse un poco simplista, ya que cada plataforma está orientada a distintos ámbitos de aplicación, pero en cualquier caso nos sirve para poder afirmar que J2ME usa hasta 37 clases provenientes de java.lang, java.io y java.util (J2SE). La principal diferencia es aportada por las clases de javax.microedition (que están en J2ME, pero no en J2SE).

Entorno de Ejecución J2ME

La arquitectura externa de un entorno de ejecución J2ME está compuesta por:

Sistema Operativo

Máquina virtual

Configuración

Perfiles

Una configuración es el conjunto mínimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos CLDC (Connected Limited Device Configuration) o CDC (Connected Device Configuration).

La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en cuanto a capacidad gráfica, cómputo y memoria. Un ejemplo de éstos dispositivos son: teléfonos móviles, buscapersonas (pagers), PDAs, organizadores personales, etc. Esta configuración funciona sobre máquinas virtuales Java, Kilo Virtual Machine (KVM).

La CDC está enfocada a dispositivos con más recursos, como decodificadores de TV digital, navegadores GPS, PDAs, etc. Esta configuración funciona sobre máquinas virtuales Java, Compact Virtual Machine (CVM).

Ya hemos dicho que CLDC está orientado a dispositivos con ciertas restricciones. Algunas de éstas restricciones vienen dadas por el uso de la KVM, necesaria al trabajar con la CLDC debido a su pequeño tamaño. La mayoría de teléfonos ya tienen su propia KVM, si bien, nos hemos encontrado algunos problemas para elegir la máquina virtual para PDAs con Windows Mobile. En algunos modelos ya vienen preinstaladas las KVM Esmertec JBED, pero no se comporta bien con algunas librerías. Yo desde la experiencia, recomendaría la IBM J9 CLDC/MIDP. No es gratuita, pero el coste por unidad, si se compran más de 100 licencias, ronda los 9 dólares.

El caso es que yo no desarrollaría aplicaciones CLDC para PDAs, ya que sería desaprovechar la potencia de cálculo que tienen estos dispositivos. Sin embargo, algunas veces debemos hacerlo para conseguir portabilidad con distintas plataformas móviles (RIM-Blackberry, Symbian,...)

Mi experiencia con CDC se reduce a la programación sobre PDAs. Para ello he usado la máquina virtual de IBM J9 CDC, de coste similar a la CLDC. También he tenido resultados satisfactorios con la CrEME (que tampoco es gratuita). Los dispositivos con Windows Mobile no suelen llevar máquina virtual Java CDC instalada de serie.

Los Perfiles se extienden sobre las Configuraciones, y suponen una capa de especificaciones para un conjunto específico de dispositivos del mercado.

Los perfiles entre otras cuestiones se encargan del mantenimiento del ciclo de vida, interfaces de usuario, gráficas, manejo de eventos,...

Para CLDC:

- PDA Profile: PDAs gama muy baja (Palms antiguas).
- Mobile Information Device Profile MIDP: Se encarga de la semántica y control de la aplicación, interfaz de usuario, persistencia, trabajo en red, temporizadores. Aplica a teléfonos móviles, PDAs... Actualmente es el único perfil para CLDC disponible. Las aplicaciones desarrolladas con este perfil reciben el nombre de MIDLET.

Las aplicaciones son visualmente pobres, pero se pueden enriquecer con librerías gráficas sobre este perfil, como Sun LWUIT, o Kuix. Estas librerías ya tendrán su post más adelante, ya que considero que son fundamentales para poder desarrollar aplicaciones atractivas para Blackberry, o Nokia, por ejemplo.
En este tipo de aplicaciones, no se puede usar bases de datos, así que se usan almacenes de datos, llamados RMS.

Para CDC:

- Foundation Profile: Incluye gran parte de J2SE, pero excluye interfaz gráfica AWT y Swing.
- Personal Profile: Soporte gráfico AWT. Requiere Foundation Profile.
- RMI: Requiere Foundation Profile. Subconjunto de J2SE RMI.

La línea de separación entre aplicaciones CDC, y aplicaciones de escritorio de PCs es cada vez más fina. De hecho, nosotros hemos desarrollado aplicaciones para PDAs con SWT como interfaz gráfica, y tan solo cambiando el jar por el apropiado para Windows XP, o Linux, por ejemplo, obtenemos la aplicación análoga para estas plataformas.
En aplicaciones de este tipo se puede hacer uso de bases de datos, como HSQLDB, Apache Derby, DB4o,...

Creo que entender correctamente estos conceptos es imprescindible para aquel que quiera adentrarse en el mundo de la Java Movilidad J2ME, tanto para poder realizar propuestas técnicas-económicas, como para consultorías, o desarrollos.

Venta en Gradas

2009-05-19T00:10:00.001+02:00

Venta en Gradas fue el proyecto que me mantuvo ocupado (muy ocupado) durante el verano pasado. El objetivo era que los asistentes a un partido de fútbol pudieran realizar pedidos desde sus asientos en las gradas del Ramón Sánchez-Pizjuán.

Actualmente, varios operarios repartidos por las gradas, portan PDAs y mediante una interfaz sencilla e intuitiva realizan pedidos de productos asociados a una zona del estadio, una fila y un asiento. Simultáneamente se imprime un ticket-resguardo para el cliente (a través de una impresora portátil bluetooth que lleva cada operario) con estado pendiente, y un ticket análogo en la impresora de la barra más próxima. En ésta se prepara el pedido, que otro operario lleva a la Zona-Fila-Asiento indicados. En el momento de entregar el pedido, se realiza el intercambio de tickets, quedándose el cliente con el que tiene estado "entregado".

La arquitectura de la aplicación es la siguiente:

El software del cliente se desarrolló en .NET C#, y se usó una base de datos SQL Server Compact Edition v3.5. Se utilizaron componentes IntTheHand.Net para implementar la impresión por bluetooth en la impresora portátil. El canal de comunicación puede ser wifi, GPRS, HSDPA...

Para el servidor se desarrolló un Java Restlet que recoge los pedidos (XML), los inserta en una base de datos MySQL 5 (a través del framework Ibatis), y envía el pedido a la impresora de barra asociada. Si se produjera algún error (falta de papel, tapa de impresora abierta...), se recogería por el servidor, y se notificaría a la PDA correspondiente.

Por último se programó una aplicación web en PHP, que a través de consultas a la base de datos del servidor, ofrece al administrador todo tipo de estadísticas sobre las ventas (producto más vendido, partido en el que más se ha vendido,...).

Después del trabajo realizado, fue muy gratificante poder leer esto en la web del Sevilla F.C.. El pasado 28 de abril, pude leer en ABC el artículo Aperitivos Telemáticos donde vuelve a aparecer. Como comprenderéis, como "padre de la criatura", el orgullo es tremendo, y espero que pronto lo podamos usar en otros estadios y en todo tipo de espectáculos.

Scrum para Dummies

2009-05-12T23:57:00.012+02:00

Introducción
Scrum es un marco de referencia para desarrollo ágil de productos. Esta metodología se puede aplicar a procesos de producción de distintos sectores, yo me centraré en el de Desarrollo de Software.

Desarrollo tradicional vs Desarrollo Ágil

Especialización vs Equipo Multidisciplinar
Fases vs Solapamiento
Requisitos detallados vs Visión del producto
Seguimiento del plan vs Adaptación a los cambios

Las metodologías tradicionales se ven como una carrera de relevos, en el que cada miembro es responsable de una fase, y hasta que no se termina una fase, es imposible comenzar las siguientes.
En cambio, las metodologías ágiles son más como un partido de Rugby, en el que el empuje conjunto del equipo es importantísimo para el éxito. De hecho, Scrum significa melé.

Ya comparé en un post anterior estos dos tipos de metodologías.

¿Por qué Scrum?

El cliente puede ver resultados desde el primer momento.

Se ahorra el tiempo que en las metodologías tradicionales se dedica en conseguir especificaciones y documentaciones exhaustivamente documentadas.

Se hace equipo: comunicación contínua, se reparten éxitos.

El cliente interviene en todas las fases del proyecto.

Se reducen los riesgos por retrasos acumulados, entregas que difieren de lo que el cliente esperaba, y por tanto influye de manera decisiva en el éxito del proyecto.

Es una metodología sencilla y nada rígida. Se puede complementar con otras. Por ejemplo, nosotros la combinamos con eXtreme Programming.

¿Qué se necesita para aplicar Scrum?

Actores: usuarios con distintos tipos de roles.

Product Owner: Representa la voz del cliente. Escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
Scrum Master: Protege al equipo de distracciones y de otros elementos externos (presiones no razonables,...). Elimina obstáculos que alejen al grupo de la consecución de objetivos del sprint. No es el líder del grupo, ya que el grupo se autogestiona.
Equipo: Tiene la responsabilidad de entregar el producto.

Product Owner, Scrum Master, y Equipo, son roles llamados "Cerdo". También hay roles "Gallina", que no forman parte de Scrum (Cliente, Usuario, Manager).

Product Backlog o Pila de Producto:

Traducción poco afortunada, por cierto, ya que no sería una estructura "pila", es más bien una lista ordenada y priorizada de Historias de Usuario. Es confeccionada por el Product Owner o el Cliente.

Las Historias de Usuario son requisitos a muy alto nivel de lo que debe hacer la aplicación. Por ejemplo: Como administrador quiero dar de alta un usuario en el sistema.

Estimación:

El Scrum Master y el Equipo estiman cada una de las Historias de Usuario del Product Backlog. Para ello, cada miembro del Equipo, dispone de una baraja Scrum, que contiene los valores: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinito, ?. Estos valores son llamados Puntos de Historia y sirven para valorar el "esfuerzo" necesario para desarrollar cada "Historia de Usuario". Los valores de la baraja sigue una sucesión de Fibonacci aproximada, y redondeada. No nos interesa afinar demasiado, sobretodo en los valores más altos, ya que son los más susceptibles de desviarse. Los Puntos de Historia nos sirven para comparar Historias. Es decir, si dos Historias están estimadas en "5", nos costará el mismo esfuerzo (aproximadamente) llevarlas a cabo, y seguramente se tarde lo mismo en ser concluidas, pero de "tiempos" hablaremos más adelante.

Si una Historia está estimada con valores altos, 100 o infinito, seguramente deberá ser dividida en varias Historias "más pequeñas". El infinito se suele usar cuando una Historia no está suficientemente definida, y normalmente conlleva una rescritura de la Historia por parte del cliente o el Product Owner.

El Equipo debe discutir y debatir cada uno de las estimaciones, y llegar a un acuerdo sobre los Puntos de Historia de una Historia de Usuario.

Normalmente, después de las estimación, el Cliente, ayudado por el Product Owner, debe priorizar las tareas, sabiendo lo que "tardan" en realizarse las tareas (aunque sea por comparación).

Las estimaciones son muy aproximadas, solo se concretan cuando se van a realizar durante el Sprint.

Sprint:

Es un ciclo de producción dentro de un desarrollo iterativo e incremental. Una vez tenemos el Product Backlog estimado y priorizado, se procede a decidir las Historias que se van a resolver durante el Sprint, dependiendo de los Puntos de Historia que "cuesten" las Historias, valga la redundancia. El Sprint es un periodo de tiempo que suele variar de una semana a un mes. En nuestro caso el Sprint es de dos semanas.

El número de Puntos de Historia, que se resuelve en un Sprint suele aumentar a medida que el equipo se va conociendo, y va madurando. En los comienzos de los proyectos, se pueden producir desviaciones en el número de Puntos de Historia que se resuelven en un Sprint, por falta de experiencia, falta de conocimiento del grupo,... estas desviaciones deben tenerse en cuenta cuando se plantee el número de Puntos de Historia que se deben resolver en futuros Sprints. Por ejemplo, si he estimado que el equipo va a resolver 40 Puntos de Historia en un Sprint, y solo resuelve 20, en el futuro Sprint, se estimará un número cercano a los 20 Puntos de Historia.

Las Historias de Usuario que se van a resolver durante el Sprint, se colocan en el Sprint Backlog. Se priorizan por el Product Owner, y solo el Scrum Master puede modificar su orden durante el Sprint.

Durante el Sprint es conveniente organizar un Tablón de Trabajo con las Historias ordenadas por: Tareas a realizar, Tareas en Ejecución, Tareas Finalizadas.

El número de Puntos de Historia que se llevan a cabo por Sprint se denomina Velocidad, y de aquí podemos extraer el tiempo.

Para medir el rendimiento solemos realizar un gráfico Burndown:
- Eje de abcisas: Sprints
- Eje de ordenadas: Número de Puntos de Historia

Daily Scrum:

Reunión diaria (durante el tiempo que dure el Sprint) de cinco minutos de duración (en ningún caso debe exceder de diez minutos) en el que cada miembro del equipo debe responder a las siguientes preguntas:

¿Qué has hecho?
¿Qué prevés hacer hoy?
¿Qué impedimentos te has encontrado?
¿Qué necesitas de otro miembro del equipo?

Cada miembro se debe dirigir al Equipo, no al Scrum Master ni a ningún otro miembro en concreto.
Lo que necesite de otro miembro del equipo, se debe solicitar, anotar, pero no discutir durante la reunión. Eso implicaría una duración mucho mayor.

Presentación del Producto:

A la finalización del Sprint, se hace una revisión, que en ningún caso excederá de dos horas.

Al llegar a este punto, debemos tener "algo" que el Cliente o el Usuario pueda ver y tocar. En esta reunión, suelen asistir el Product Owner, el Scrum Master, el Equipo y personas que podrían estar involucradas en el proyecto. El Equipo es quién muestra los avances realizados en el Sprint.

Se le presenta al Cliente la parte de producto terminada.

Restrospectiva:

Se realiza una reunión informal, normalmente fueras de las oficinas, en el bar por ejemplo, donde se plantean los inconvenientes tenidos durante el desarrollo del Sprint, así como las mejoras posibles para trabajos futuros.

Nosotros solemos salir media hora antes los viernes de finalización de Sprint, con objeto de poder realizar la Retrospectiva, que aun siendo trabajo, debe llevarse a cabo en ambientes informales.

Huelga Ingeniería Informática

2009-05-05T23:48:00.004+02:00

Son varios los compañeros (y sin embargo amigos ;-)) que me llevan pidiendo mi opinión sobre las reivindicaciones de la Ingeniería Informática desde hace algún tiempo. Ya me "he dejado querer" bastante, así que en este post, intentaré expresarme de la manera más clara posible.

Como titulado, pienso que a nivel académico, la Ingeniería Informática se debe tratar como el resto de Ingenierías. Si bien, creo que hay muchas carencias en los temarios que se imparten, y la Universidad debería adaptar el currículo, para que los titulados salieran con algunos conocimientos, que en mi opinión, son indispensables. Sobre los contenidos que deberían recogerse se podría escribir mucho, y me lo pongo como tarea para futuros posts. En éste, me quiero extender sobre las competencias y atribuciones profesionales del Ingeniero Informático. En cuanto al nivel académico parece que los Directores y Decanos, ya tienen bastante controlado el tema.

En primer lugar, y para los despistados, me gustaría aclarar que los conceptos competencias y atribuciones no son sinónimos. Las fichas de competencias son las áreas de conocimiento en las que un determinado titulado debería ser "competente". Las atribuciones profesionales, reguladas por ley (que no por plan de estudios), no se refieren a conocimientos de personas con un determinado título, sino a atribuciones profesionales específicas de personas que desempeñan una determinada profesión. Es decir, las atribuciones tienen un carácter legal (responsabilidad), y las fichas de competencias un carácter académico (conocimientos). La Ingeniería en Telecomunicaciones tiene competencias en informática, y me parece lógico, lo que no es lógico es que la Ingeniería Informática no tenga fichas de la propia informática. Pero eso, como he comentado antes, parece que ya lo tienen bastante amarrado los directores y decanos. En cuanto a las atribuciones, no existen. Otra de las inexactitudes que he escuchado es que la Ingeniería Informática va a desaparecer. Ya hay nuevas titulaciones adaptadas a Bolonia, que serán homologables con las antiguas.

Actualmente la Escuela te da herramientas para desarrollar aptitudes, que si no se siguen trabajando, se quedan en nada. En igualdad de condiciones, me quedaría con un titulado... pero en igualdad de condiciones. Es decir, no se puede pretender ser jefe de proyectos sin "estar en el mundo". Cuando un cirujano acaba su larga carrera, tiene que seguir continuamente formándose. Con un Ingeniero Informático debe ocurrir lo mismo. Este mundo evoluciona día a día.

Hay sitio para titulados como analistas, arquitectos, jefes de proyectos... y soy de la opinión de que no hay que pasar por todos los escalafones (aunque esto ayudaría bastante). Lo que sí está claro es que se tiene que demostrar ser válido y estar formado en las disciplinas que va a desarrollar profesionalmente, y eso a priori no lo garantiza un título por sí mismo. Miedo me daría que una aplicación crítica fuera liderada y gestionada por un titulado sin más conocimientos que los adquiridos durante la carrera, y sin experiencia.

Los titulados que viven aparte de lo que requiere el mundo laboral, los proyectos reales y tangibles, e ignoran la importancia que tiene ejercer y no quedarse solo en conceptos teóricos aplicados a nada, y pese a haber aprendido a resolver problemas complejos (que es lo que más valoro de mi paso por la Escuela), luego no los resuelven en su día a día, no deben tener cabida en los puestos altos de las empresas. Eso sí, pueden estudiar unas oposiciones, y hacerse funcionarios o profesores. Es tan importante saber "lo que uno sabe" como saber "lo que uno no sabe", y creo que ese es el problema de algunos titulados que viven de espaldas al mercado. No saben "lo que no saben".

Yo lo veo como una matriz DAFO de la vida: ¿Cómo explotar mis puntos fuertes?, ¿Cómo frenar los débiles?, ¿Cómo frenar las amenazas?, ¿Cómo aprovechar las oportunidades? A partir de ahí me marco objetivos, y acciones para llegar a esos objetivos, aunque tenga que trabajar muchas más de 40 horas a la semana (alguno seguro que se escandaliza). Con esto quiero decir, que el título no debería servir para que un profesional poco preparado accediera a puestos donde demostrara su incapacidad, ni para que el titulado se relajara y no tuviera que formarse y adquirir experiencia en las distintas materias que va a necesitar en su día a día.

Es verdad que como consecuencia de estudiar una carrera tan dura, el titulado entra más tarde en la carrera profesional (por regla general), pero no es menos cierto que la progresión del titulado (si aprovecha las aptitudes aprendidas) será más rápida. De hecho, los conocimientos en "tal o cual" frameworks son importantes, pero no más que la capacidad de análisis, algoritmia, resolutividad... Se tarda mucho menos en dominar un framework que en aprender a razonar (muchos no lo conseguirían nunca). Esto es lo que me demuestra la experiencia.

Por tanto, no le quitaría las fichas de competencias a la Ingeniería en Telecomunicaciones, y por supuesto crearía las fichas pertinentes para la Ingeniería Informática (se está en ello). En cuanto a las atribuciones, dejaría que el mercado fuera libre, para evitar que la empresa en España compitiera en desventaja con las del extranjero, donde no existe regulación (al menos en los países más importantes). La entrada indiscriminada de titulados sin experiencia en los puestos más cualificados de una empresa, como consecuencia de una hipotética regulación, y de la demanda de estos puestos, sería muy negativo para las TICs (ITs en otros sitios) españolas.

Lenguajes: Pasado, Presente y Futuro

2009-04-27T01:51:00.008+02:00

Escribo este post al hilo del artículo que he leido en dosideas.com. En él, se habla de las habilidades que debería tener un programador para tener un currículum relevante en los próximos cinco años:

1. Uno de los "3 Grandes" (Java, .NET, PHP)
2. Aplicaciones Ricas de Internet (RIA - Rich Internet Applications)
3. Desarrollo web
4. Servicios web
5. Habilidades humanas
6. Un lenguaje de programación dinámico y/o funcional
7. Metodologías ágiles
8. Conocimiento de dominio
9. "Higiene" de desarrollo
10. Desarrollo móvil

A partir de este artículo, estuve debatiendo con algunos compañeros y saqué algunas conclusiones que quiero plasmar aquí.

Pienso que el artículo es un poco mejorable, dada la arbitrariedad con la que se han escogido los conocimientos a adquirir. De hecho, muchas de esas habilidades hay que tenerlas en el presente (yo cumpliría de 9 a 10).

Me voy a centrar en el punto 1, uno de los "3 Grandes" (Java, .NET, PHP). Antes de hablar de "grandeza", habría que definir el criterio de comparación. Si la grandeza es la demanda de programadores en términos absolutos (no porcentajes), esos si son los tres grandes lenguajes, sin lugar a dudas. Pero lo son ahora. De hecho, en 1999, por ejemplo, no lo eran, y puede que dentro de cinco años no lo sean.

En 1999, Java y PHP estaban en el punto que están hoy Python y Ruby, y .NET no existía. Por entonces se demandaba C++, Oracle Forms, Delphi y Visual Basic. Erróneamente hay gente que piensa que la demanda de Cobol era grandísima, cuando era muy similar a la que hay ahora, Software Legacy y mantenimiento de aplicaciones críticas (como por ejemplo las de los bancos). Es verdad que por entonces los lenguajes dinámicos orientados a web (PHP y ASP) experimentaron un fortísimo crecimiento.

Si miramos al futuro, ya hay mucho camino recorrido gracias a las aportaciones de los distintos tipos de lenguajes al mundo del desarrollo de software. Creo que el futuro de Python es muy prometedor, ya que además de reciclar aspectos que ya hacía bien Java, aporta sencillez y un incremento en el rendimiento de los desarrolladores que usan este lenguaje. Python va a crecer en proporción a lo que Google siga apostando por él. Sin embargo creo que Ruby se quedará en el camino por muchos motivos (soporte, complejidad, madurez, anarquía...).

Hay gente que opina que PHP es anárquico y ha sido ampliamente aceptado, pero, ¿qué aporta Ruby sobre PHP? PHP demostró que se podían hacer sitios webs dinámicos, multiplataforma, y en software libre de forma muy sencilla. Lo que aporta Ruby sobre PHP aun no lo he descubierto.

También los hay que opinan que Java es el nuevo Cobol o el nuevo C++, y yo vuelvo a discrepar. En cierta medida es más que Cóbol por el número de aplicaciones que se han desarrollado (más allá de su criticidad). Además, el código Java es mucho más mantenible, gracias a la arquitectura de tres capas (aunque el patrón es independiente del lenguaje, las aplicaciones Cobol eran desarrolladas por matemáticos y físicos que ignoraban los patrones de diseño y otras técnicas de ingeniería del software), pudiéndose incluso cambiar la interfaz gráfica quedando la lógica de negocio y/o el dominio como capas que se pueden mantener o no de manera independiente.

Sinceramente Cobol nunca ha aportado gran cosa. Si no estuviera implantada como solución corporativa de los bancos, no nos acordaríamos ni de su nombre.

En cuanto a C++ revolucionó sobretodo la parte gráfica de las aplicaciones. Su orientación a objetos era artificiosa por culpa de la retrocompatibilidad con C (Ansi C está totalmente contenido en C++). Depurar un error a causa de un "puntero loco", podía consumir semanas, y eso sin contar que nunca estabas totalmente seguro de que el arreglo no conllevara efectos colaterales. Realmente el lenguaje "pata negra", y que sigue siendo requerido en muchas empresas (sobretodo de microelectrónica) es el C.

Aportaciones de Java al mundo del desarrollo software:

Java no se ha quedado estancado, se ha adaptado a la programación Orientada a Aspectos (más allá de la orientación a objetos con el framework Spring, por ejemplo), y tiene la comunidad de desarrolladores más amplia del mundo.

Además Java abarca: aplicaciones de escritorio, web, móviles y servicios. Es decir, se puede hacer todo.

Si a eso, le sumamos su aportación en el mundo de la Orientación a objetos (fue el primer lenguaje OO puro y que funcionara), persistencia de objetos (Hibernate, IBatis, JPA), ORM (Hibernate), servicios web (REST, SOAP con Axis), frameworks gráficos (SWT, RCP, AWT, Swing), frameworks MVC (Struts), frameworks web (JSF, Struts, Struts2), adaptación total a UML, pruebas unitarias (JUnit, Testng), logeo en consola (Log4J), dos fantásticos IDEs libres multilenguaje (Netbeans y Eclipse), y todo ello multiplataforma (de manera transparente al programador), podemos concluir que la aportación de Java al mundo del desarrollo software es muy superior a lo que pudo aportar en su día, Cobol, y C++.

Mercado actual

Ahora mismo el 60% de los proyectos que nos llegan son en Java (Web + Movilidad). Me ha sorprendido ver como PHP ha crecido hasta el 30% en época de crisis. Me gustaría encontrar una explicación a este crecimiento (quizás como consecuencia de los CMS Drupal y Joomla que han alcanzado un grado altísimo de madurez). Sin embargo los proyectos en .NET se han reducido. Esto puede tener sentido como consecuencia del coste de licencias, y debería de paliarse con Mono (plataforma para desarrollo libre de aplicaciones .NET), pero no termina de hacerse su hueco, pese a que C# me parece un muy buen lenguaje.

Me gustaría tener demanda en Python, para poder tener algo de tiempo para formarme, pero actualmente no la hay (en mi caso particular, y en Andalucía en general).

Futuro

Dentro de cinco años seguirá habiendo trabajo para desarrolladores PHP y Java.

El desarrollador mejor formado, y más maduro, debe abarcar varios lenguajes y frameworks, eso le dará una perspectiva y una experiencia superior al que solo domine un lenguaje. Esa ha sido mi experiencia personal.

Creo que cada vez será menos importante "con qué se programe", el paradigma al que se tiende es Software as a Service (SaaS) - Cloud Computing (aquí hay una primera aproximación). Apuesto por SOA (arquitectura orientada a servicios), donde lo importante son los servicios y la interoperatividad, no el software de las "tripas".

Oracle compra Sun

2009-04-20T20:51:00.018+02:00

Noticia muy importante, y muy inesperada, al menos para mí:

Oracle ha comprado Sun. Se esperaba que lo hiciera IBM, que al mantener una doble línea (software libre y privativo), la operación se interpretaba como una gran apuesta de IBM por el software libre. Tras consumarse la operación de Oracle, que como todos sabemos, apuesta por la venta de productos por licencia, la historia cambia radicalmente.

Tendremos que estar muy atentos a los próximos movimientos. En mi opinión puede ocurrir lo siguiente:

Que Oracle vaya retirando progresivamente el soporte de Sun a sus tecnologías (Java, MySQL, LWUIT, Netbeans…). En ese caso podría ocurrir:

- Que algunas administraciones públicas cambien su política de software libre y se adapten a software privativo. En mi opinión, esto es improbable, pero de suceder, deberíamos apostar por software propietario más maduro, como .NET, por ejemplo.

- Que los nuevos proyectos se sigan realizando en software libre (Python, PostgreSQL, por ejemplo). En ese caso, deberíamos adaptarnos a estas tecnologías, como está haciendo Google.

Que Oracle entre de lleno en el mundo del software libre. En ese caso, ¿qué harían con MySQL, principal competidor actual de Oracle? ¿Cómo afectaría esto a lo que escribí aquí?

Bases de Datos: Pasado (Oracle), Presente (MySQL), Futuro (¿db4o?)

2009-04-20T20:50:00.001+02:00

En los últimos tiempos, tanto el gobierno británico como el alemán han apostado firmemente por invertir en Software Libre realizando progresivamente migraciones de sus sistemas propietarios.

En mi visita al Delivery Center de Accenture en Málaga, me aseguraban que las licencias de software propietario se habían encarecido un 25 por ciento en 2008. Costes en software propietario que ya eran bastante elevados en 2007.

Unos de los productos propietarios más ampliamente extendidos, incluso donde se ha apostado decididamente por Software libre, es el sistema de gestión de bases de datos Oracle. Sus virtudes principales son su robustez, su seguridad, y su soporte. Sus principales defectos son su lentitud, su complejidad y la gran cantidad de recursos que consume. A estos defectos habría que añadir su alto coste, tanto de licencias, como de mantenimiento, requiriendo personal formado específicamente para administrar este tipo de base de datos.

Creo que el fin de la época dorada de Oracle ha llegado. Actualmente hay una gran oferta de SGBDs "libres" que no tienen los defectos de Oracle, y cuyas virtudes se adaptan a lo que se necesita en la mayoría de sistemas de información que desarrollamos. Quizás no llegan a la potencia de Oracle, pero tampoco lo necesitamos, y además nos ofrecen otras prestaciones, como velocidad, o sencillez, que suponen un ahorro de costes extra.

Seguirá habiendo bases de datos Oracle, al igual que aun hay muchísimo trabajo para los programadores de Cobol, ya que hay aplicaciones críticas, cuya migración es difícil de asumir, pero pienso que no será adoptada en la mayoría de nuevos desarrollos.

Pienso que una buena solución es desarrollar con MySQL, sobretodo desde que fue comprada por Sun, y adquirió mayor madurez. Es fácil de instalar, de mantener, los requisitos del sistema para su funcionamiento son mínimos, es rápida, estable... "es todo lo que necesito" y es Software Libre. ¿Qué más se puede pedir?

La mayoría de desarrollos actuales para la Junta de Andalucía se están realizando con MySQL, aunque en Madeja (Marco de Desarrollo de la Junta de Andalucía) recomienden PostgreSQL (ya sabemos como es la política de desarrollo de las Administraciones Públicas...).

Al igual que MySQL es el presente, no creo que sea el futuro, o al menos no lo será el MySQL que conocemos actualmente. Es más, no tiene sentido que usemos el paradigma de programación Orientado a Objetos, y luego tengamos que realizar mapeos para convertir los objetos a registros, aunque para ello haya frameworks como Hibernate, que suponen una caja negra para el desarrollador en lo que a mapeo se refiere. Hibernate no deja de ser un "artificio", aunque cada vez ofrezca más funcionalidades, como el caché de segundo nivel, gestión de sesiones... pero que tienen un coste, sobretodo en rendimiento. Además, estas funcionalidades deben ser asumidas, en su mayor medida, por el SGBD.

En mi empresa hemos asumido desarrollos usando un SGBD orientado a objetos, db4o, que tiene un sistema de licenciamiento idéntico al de MySQL (licencia dual GPL/comercial). Los resultados han sido muy buenos. Es una base de datos ligera, sencilla y rápida, no usamos SQL sino operaciones sobre los objetos a persistir. Con db4o conseguimos no tener que duplicar el modelo de datos del dominio de la aplicación, es decir, no existe el diagrama E/R (todo son objetos). No tenemos que sacrificar rendimiento como ocurre cuando usamos un ORM. Lo podemos usar en una PDA, en un dispositivo con Android, en un sistema Windows, Linux... Es un sistema bastante novedoso, y aun tiene un largo camino por recorrer, pero, por ahí deben ir "los tiros".

Nota post post:
No sé como puede afectar esto a lo que he expuesto.

La otra pata de la Carrera Profesional

2009-04-14T23:35:00.001+02:00

El pasado 13 de Marzo, estuve hablando con Javier Rubio, Director General de MP Sistemas, sobre los Objetivos de Maduración del Equipo de Desarrollo de Soltel.

Durante la reunión, tuve la oportunidad de mostrarle la matriz DAFO de nuestro equipo (Debilidades, Amenazas, Fortalezas, Oportunidades). Estuvimos debatiendo sobre nuestro escenario previo, indicadores, acciones, objetivos, aplicados a los desarrolladores del equipo.

Después de explicarme, tuve la oportunidad de escuchar atentamente sus consejos. Todo lo habíamos orientado a la técnica y tecnología. Lo cual es condición necesaria en una empresa que se dedica al sector TIC (IT en otros sitios del mundo), pero no suficiente. Me estuvo contando su experiencia en varios proyectos, en los que las aportaciones de un líder con alto nivel de conocimiento en distintos modelos de negocio (biología, derecho, farmacia), habían sido definitivas para la consecución del éxito en el desarrollo.

Es decir, si además de tener un alto nivel de empatía con el cliente, tenemos un conocimiento exacto de sus necesidades, de cómo se comporta su negocio, y cómo poder optimizar procesos, estaremos más cerca de ofrecerle un producto realmente útil. Para todo ello, obviamente, será necesario tener las capacidades técnicas para poder convertir el conocimiento, en un desarrollo tangible. Pero como comentaba antes, el conocimiento técnico no es suficiente.

Evidentemente, no podemos saber de todos los modelos, de todos los clientes. Eso supone adquirir conocimientos bastante heterogéneos, que los que tengan capacidad, podrán obtenerlos con el tiempo, la experiencia, la formación y sus inquietudes.

Es muy positivo tener indicadores para poder ponderar los avances técnicos de los desarrolladores. Sería genial tener un equipo con Nivel 4 (que indica la Excelencia Software en nuestro equipo), pero si eso no se acompaña de un valor añadido, nuestra mesa se queda coja. Solo seríamos productores eficientes, que no es poco, pero queremos más. Hay que conseguir diseñar unos indicadores en los que se valoren otros conocimientos, basados en las aptitudes y habilidades generales, que complementen nuestros actuales indicadores técnicos.

Estos indicadores, al igual que los técnicos, deben ser totalmente objetivos y medibles. A medida que se vayan superando escalones, cabe la posibilidad de que haya una separación del código. Aunque ahora nos apasione el desarrollo en si (en cualquiera de sus fases), parece probable que al ir madurando personal y profesionalmente, dejemos paso a nuevas generaciones que realicen el trabajo de base con ilusión y capacidad, y los trabajadores “maduros” vayan aportando otro tipo de valor a la empresa.

Portales Colaborativos II

2009-04-07T02:20:00.020+02:00

El pasado 20 de Marzo, estuve en el Seminario: "Gestión de Portales Colaborativos" que organizó Avante en sus intalaciones del Parque Tecnológico Cartuja 93. Ignacio Montoya García de Emergya, realizó una ponencia bastante interesante sobre la tecnología relacionada con el trabajo compartido Online.

En este post, hablaré sobre ello, y aportaré mi visión particular sobre el tema.

Según temática y/o objetivos podemos hacer la siguiente división:

- Portales horizontales (de carácter general): Facebook, Tuenti, Second Life,...
- Portales verticales (temáticos):

- Redes Profesionales: Xing, Neurona, Linkedln
- Redes de Blogs: Blogger, MySpaces, Weblogs, Teoriza
- Redes Comerciales: Ciao!, Ebay
- Redes de Imágenes: Flickr, Picasa, Natuba
- Redes de Participación Ciudadana: Participa en Andalucía
- ...

Del estudio realizado por The Coktail Analysis en 2008, se extrae que las redes sociales están en plena ebullición, y son usadas masivamente por los internautas, pero, ¿qué pasa con los Portales Colaborativos para entornos corporativos?

Hay varios estudios que indican lo beneficioso que es para la empresa este tipo de portales (reducción de costos, aumento de la productividad, mejora de la seguridad,...). Para no hacer demasiado tedioso el post, no entraré en los números, pero sí quiero comentar, que las mayores empresas del mundo (Google, Sun, Nike, IBM, Cisco), han implantado con éxito este tipo de software.

Existen varios productos para cada funcionalidad u objetivo que se desee cubrir, entonces, ¿por dónde empezamos?

Paso 0
- Definición de usuarios:

- Si los usuarios son los integrantes de la empresa: querremos obtener Comunicación, Cooperación, Comunidad (que son las tres "c" de las redes sociales).
- Si los usuarios son socios tecnológicos o agentes externos: querremos obtener Comunidad, Fidelidad, Vínculos.
- Clientes, posibles empleados, posibles socios: querremos obtener Visibilidad, Publicidad, Branding.

Paso 1
- Definición de funcionalidades:

- Blogs/Microblogging
- Sala Virtual Multiconferencias
- Sindicación RSS
- Calendarios
- Gestión de tareas y del tiempo
- Gestión de Contenidos
- Plataforma E-Learning
- Enlaces / Recursos compartidos
- Tablón de noticias / Anuncios
- Directorio de Perfiles
- Foros
- ...

Paso 2
- El proyecto:

- No hay una plataforma que lo englobe todo.
- Utilizar productos existentes y realizar labores de integración para no reinventar la rueda.
- La modularidad, nos puede proporcionar escalabilidad futura.
- Interoperatividad y uso de formatos abiertos.
- Apoyo de comunidades de desarrollo y soporte.
- Mejor si es con Software Libre.

En cuanto al desarrollo, se podría empezar desde cero, como hicieron en Meneame, o Facebook, pero lo recomendable es apoyarse en algún framework de desarrollo: Django (Python), JSF (Java), Zend (PHP), OpenSocial (framework de Google para portales sociales).

Si nos apoyamos en software que ya esté desarrollado, podemos usar como base un Gestor de contenidos (CMS).

¿Cuál escoger?
Para tomar esta decisión hay que dar respuesta a las siguientes preguntas:

¿Qué dominan mis técnicos?
¿Cuál es el que me ofrece más funcionalidades mediante módulos de serie?
¿Cuál tiene una implantación menos costosa?
¿Cuál tiene un mantenimiento menos costoso?
¿Cuál ofrece una mayor interoperabilidad con terceros?
¿Cuál tiene una mayor curva de aprendizaje?
¿Qué tecnología puede ser estratégica para la empresa?

En cuanto a características técnicas, nos podemos apoyar del comparador CMS Matrix

Actualmente hay 1040 entradas de CMSs para poder comparar.

¿Qué usaría yo para un portal colaborativo?

Dentro del equipo de trabajo pueden surgir dudas relativas a:

- Las vacaciones de un miembro, los días que estará fuera de la oficina, o reuniones. Es preciso tener agendas compartidas. Una buena opción sería usar Google Calendar.

- Los módulos que tiene un proyecto, las tareas que debe realizar cada miembro, o si hay errores por resolver. Es decir se necesita una herramienta para gestionar el proyecto. Nosotros actualmente usamos Trac, pero quiero evaluar Redmine.

- Dónde encontrar la información. Nosotros usamos una wiki (Soltelpedia) y una lista de correo, pero en nuestro portal colaborativo deberíamos incluir un gestor de enlaces como Delicious.

- Reuniones virtuales. Soltel es partner de Webex, que es una herramienta fantástica para video conferencias, escritorios compartidos...

- Gestión documental, para la que Alfresco es una buena solución.

- Programa central con el que integrar el resto de herramientas. Esto es el portal en sí, y teniendo en cuenta las características y necesidades que tiene un Portal Colaborativo (modularidad, escalabilidad,...), Liferay es el que mejor prestaciones ofrece, y además nos cubre las necesidades CMS. Ya hablé hace algunas semanas sobre ello.

Creo que si nuestro proyecto, tiene en cuenta todos estos factores, será exitoso. La empresa moderna reclama herramientas de este tipo, acorde con los tiempos que corren. Comunicación, colaboración, centralización, personalización son factores clave para mejorar la eficiencia a nivel individual y colectivo.

Portales Colaborativos I

2009-03-31T01:40:00.008+02:00

El concepto de portal convencional supone una plataforma donde se ofrecen contenidos, funcionalidad (búsquedas, inscripciones,...), publicidad...

Un Portal Colaborativo está influenciado por la filosofía Web 2.0:
- Los usuarios saben donde encontrar la información (está centralizada). Dependiendo del perfil se le mostrará una información u otra.
- Aúna los procesos de negocio de las organizaciones.
- Se fomenta el trabajo compartido Online.
- En definitiva, los usuarios son lo más importante.

En Soltel andamos enfrascados en el diseño y desarrollo de un Portal Colaborativo, que nos permita agilizar ciertos procesos y por supuesto, estamos trabajando para que "no se quede" en la empresa. Para ello, hacemos hincapié en la abstracción, modularización y en los servicios generales que debería tener para poder convertirlo en producto.

¿Qué debería tener un portal colaborativo?

- Un repositorio centralizado de todo tipo de documentos. Punto de acceso único a la información.
- Agendas compartidas.
- Sistema de gestión de incidencias.
- Herramientas de comunicación.
- ...

Claves del éxito

- Personalización (el usuario puede ver, por ejemplo, las vacaciones que le quedan).
- Comunicación (mensajería instantánea, videoconferencia,...).
- Transacciones (tareas, acceso a servicios).
- Integración con aplicaciones internas (ERPs, CRMs,...).

Ventajas

- Optimiza recursos informáticos.
- Reduce tareas redundantes.
- Mejora la comunicación integrada, el enfoque de las tareas y la supervisión.
- Reduce gastos TI.
- Mejora la seguridad.
- Conectividad de la información.

Dificultades

- Supone un cambio de paradigma en la forma de trabajar y de pensar del empleado.
- Hay que reestructurar los sistemas de información de la empresa.

Generación de Valor

El principal valor es el usuario. De nada sirve tener las infraestructuras tecnológicas mejores y más novedosas, si no son usadas masivamente por los usuarios.

Ley de Metcalfe: el valor de una red de comunicaciones aumenta proporcionalmente al cuadrado del número de usuarios del sistema (n²).

Factores a tener en cuenta

- La instalación debe ser sencilla.
- El sistema debe ser modular para favorecer la escalabilidad.
- Fácil uso.
- Uso de estándares abiertos.
- Arquitectura orientada a servicios (SOA), que favorezcan la interoperatividad entre las distintas tecnologías que coexisten en la empresa.
- Seguridad. Se trata de un sistema crítico en la empresa, así que debe ser seguro.
- Debe ofrecer multitud de servicios colaborativos, sin reinventar la rueda. Hay muchos que ya están implementados en Software Libre.
- Capacidad de adaptación al negocio.
- Debe tener un buen soporte y comunidades que lo apoyen.

En el siguiente artículo sobre Portales Colaborativos, hablaré de soluciones reales y aplicaciones existentes que pueden ser interesantes a la hora de confeccionar un Portal Colaborativo "Integral".

Métrica v3 vs Metodologías Ágiles

2009-03-25T00:58:00.003+01:00

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas.

Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla.

Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que al final nos puede arrojar más luz es: "¿para qué se va a usar?". Es decir, intentar buscar la solución que mejor se adapte a nuestro problema o escenario específico.

Métrica v3 vs Metodologías ágiles, no son una excepción. Yo tras haber usado las dos, tengo una opinión formada. Yo usaría Métrica v3 en las circunstancias que paso a exponer:
- Proyectos extremadamente grandes, donde es importante tener un análisis funcional suficientemente especificado.
- Proyectos en los que intervengan multitud de equipos de trabajo, donde la comunicación no siempre sea fácil.
- Proyectos con posibilidad de tener una rotación de personal alta.
- Proyectos encargados por clientes, que no tienen suficientemente claro lo que desean, ni lo que esperan.
- Proyectos con requisitos iniciales inestables, cuyos cambios puedan suponer un alto impacto, y grandes desviaciones en los plazos de un proyecto.
- Proyectos ejecutados por programadores muy "juniors".
- Proyectos en los que Métrica v3 es requisito no funcional del cliente (normalmente Administraciones Públicas).

Muchas de estas circunstancias vienen reflejadas en el Informe Chaos como causas de la mayoría de los fracasos en los proyectos de desarrollo software, y se pueden paliar de manera significativa mediante Métrica.

Es verdad que cada cambio introducido en los Requisitos Funcionales (FRQ), por ejemplo, puede suponer tener que realizar modificaciones en uno o varios, Requisitos de Información (IRQ), Restricciones o Reglas de Negocio (CRQ), en los Casos de Uso, e incluso en el Modelo de Datos, y mantener esto a menudo resulta tedioso y es costoso en tiempo, pero también nos proporciona:

- Unos requisitos estables.
- Una especificación detallada del proyecto, que puede llegar hasta la separación en numerosas tareas muy simples.
- Un análisis que el cliente debe validar, y que supone el "contrato" tanto para desarrolladores como para el propio cliente.
- Trazabilidad que nos indique el impacto y los costes que suponen una petición de cambio.

Por contra, es verdad que para los proyectos en los que no se den las circunstancias que he expuesto anteriormente, las técnicas ágiles, o una adaptación de estas (dependiendo del proyecto, experiencia y capacidad del equipo, cliente) nos pueden dar mejores resultados.

Visita a Accenture - Málaga

2009-03-16T23:49:00.006+01:00

El pasado miércoles 4 de marzo me desplacé a Málaga, junto con el gerente de Soltel, Julio Pérez. Más en concreto, estuvimos en el Parque Tecnológico de Andalucía. Estuvimos en Sequel... ya habrá tiempo de hablar sobre esto. En este post quiero hablar de mi reunión con Pedro García Navarro, responsable de procesos y de implantación de certificación CMMI de Accenture.

Pedro nos recibió muy amablemente, y nos enseñó las instalaciones del Delivery Center, que acoge a cerca de seiscientos trabajadores. Me llamó especialmente la atención el CPD, dónde tenían todo tipo de servidores para emular cualquier entorno (IBM, Sun...).

Después estuvimos hablando sobre la certificación CMMI. Ellos tienen nivel 5, lo cuál no es nada fácil de conseguir. Carlos había combinado algunas herramientas ágiles, con técnicas más pesadas. Habrá un próximo artículo en el que enfrente técnicas pesadas con las ágiles.

Sabía que Pedro García había diseñado los indicadores de madurez de todos los centros Accenture del mundo, y dado que yo estaba elaborando el plan de maduración del Equipo de Desarrollo de Soltel para el Plan Estratégico de la Empresa, le pedí que conversáramos sobre ello, y saqué algunas conclusiones:

1. Lo importante son los procesos, por encima de las herramientas. Si se puede usar alguna herramienta automática, miel sobre hojuelas. Por ejemplo, y simplificando, lo importante es hacer pruebas del software. Se pueden hacer programando las pruebas unitarias con JUnit o Testng, pero lo imprescindible es que se hagan, aunque sea de forma manual.
2. Es positivo ordenar los indicadores y acciones, para mejorar esos indicadores, en niveles, tanto a nivel individual, como a nivel "equipo-comunidad", y que sean conocidos por los desarrolladores, para que ellos mismos sepan en que nivel están y que deben hacer para mejorarlo.
3. Durante 2009 cambiaré el proceso de Calidad ISO-9001 Aenor de Soltel para adaptarlo a nuestra nueva forma de trabajar. Nuestra nueva forma de trabajar nos debe llevar a producir con calidad y con poca desviación en los proyectos. Los procesos deben ser el vehículo hacia la calidad del software, no hacia la consecución del "sellito" de Aenor exclusivamente.
4. Estamos en el buen camino, y pronto obtendremos grandes frutos. Esta misma sensación fue la que obtuve cuando hablé con Manuel Recena (además de recibir otros buenos consejos que puse en práctica).

Portlets con Liferay

2009-03-10T23:11:00.004+01:00

El concepto de Portal que predomina en Internet, está asociado al de Gestión de Contenidos. Un Portal es mucho más, ya que puede ofrecer, de forma flexible, "trozos de programas", Portlets en el mundo Java, que se adapten a las necesidades o preferencias del administrador, o de cada usuario. De hecho, no todos los usuarios tienen por qué tener acceso (o haber elegido en sus preferencias) a todos los Portlets de un Portal.

Es decir, si queremos modularidad, flexibilidad, e incluso interoperatividad entre plataformas la solución basada en Portlets es óptima.

Como una imagen vale más que mil palabras, os invito a que probéis (los que no lo hayáis hecho ya), IGoogle.

A partir de IGoogle no es difícil imaginar un software empresarial, un ERP, un CRM, o una Intranet basado en Portales.

Pues bien, estos "trozos de código", tienen especificación Java: JSR-168, JSR-286 (Portlets versión 2.0) y el sitio que contiene los portlets, es un Portal.

Antes de desarrollar ningún Portlet, el proceso lógico es analizar qué Portales existen en el mercado, y ver qué prestaciones tienen. Entiendo que los que hemos estudiado alguna Ingeniería, este proceso de analizar la solución correcta para cada problema, lo tenemos interiorizado. Continuamente hacemos consultorías sobre tecnología (con esto no quiero decir que la gente que no haya estudiado una ingeniería sea incapaz de hacer una consultoría). Volviendo al tema, la consultoría que realicé sobre portales, valoraba los portales: LifeRay, JBoss Portal y JetSpeed (previamente se habían descartado otras soluciones, por no adaptarse a nuestros requisitos). No voy a entrar en los detalles de la consultoría, ya que habría para varios posts. Simplemente, os voy a comentar que las prestaciones de Liferay son espectacularmente superiores a las de sus competidores.

En mi empresa hemos apostado firmemente por esta tecnología, y hemos afrontado con éxito algunos portales basados en Liferay. Hemos integrado Liferay con Alfresco (gestor documental). Nuestro objetivo: ser referencia de Liferay en España, no solo para la empresa privada, sino para la Administración Pública. Y espero que pronto haya novedades al respecto...

Arquitectura J2EE - Patrón MVC

2009-03-04T00:33:00.002+01:00

El concepto de reutilización del software, no se ciñe solo a usar las mismas funciones, clases, o métodos para resolver problemas similares, sino que se extiende a otras fases del desarrollo del software como puede ser, como es el caso que nos ocupa en este post, la arquitectura.

En la reutilización a nivel de arquitectura interna, adquieren especial relevancia los patrones de diseño. En concreto, hoy quiero hablar del Patrón Modelo-Vista-Controlador. El MVC es un patrón muy usado en distintos tipos de aplicativos.

He escuchado comentarios de programadores, en los que asocian este patrón a J2EE, dado que hay varios frameworks que lo implementan, como por ejemplo Spring MVC, pero MVC, como el resto de patrones, no es exclusivo de una tecnología. De hecho en las primeras iteraciones de diseño, abstraemos la arquitectura de la tecnología de programación. En Soltel hemos adoptado este patrón en multitud de desarrollos de muy distinta naturaleza: movilidad J2ME, movilidad .NET, C#, y por supuesto en aplicaciones J2EE.

En nuestro día a día, no desarrollamos aplicaciones críticas, donde estaría prohibido usar este tipo de patrones. De hecho dudo que para una aplicación crítica se escoja Java como solución tecnológica.

Para aplicaciones J2EE, la mayoría de las veces, la arquitectura MVC satisface las necesidades de la aplicación. De hecho, creo que se ha constituido como estándar de facto, y si trabajas en proyectos para la administración pública en Andalucía, casi un estándar de iure, ya que en MADEJA (Marco de Desarrollo de la Junta de Andalucía), se recomienda su uso.

A grande rasgos, el patrón indica que se deben establecer tres componentes o capas en la arquitectura, y que cada una de estas, solo se comunica con la adyacente.

- Capa Vista: Responsable de la lógica de presentación y captura de datos de nuestro sistema al exterior y viceversa.
- Capa de Control: Responsable de la lógica operacional de negocio. Traslada las peticiones de la Capa Vista a la Capa de Modelo, y según la respuesta, la redirecciona o no a la Capa Vista. Carga objetos y opera con ellos.
- Capa Modelo: Básicamente contiene la lógica de negocio real, el dominio de la aplicación (VO: Value Object) con sus clases get y set, y los objetos de acceso a datos (DAO) que implementen las operaciones CRUD (Create, Read, Update, Delete). Esto a grandes rasgos, ya que dependiendo de la aplicación, además de los patrones VO y DAO, se puede incorporar un Façade. Esta capa interactúa o bien directamente (por ejemplo, mediante jdbc) o a través de la capa de persistencia, con servidores de bases de datos, LDAP...

Muchos de los frameworks J2EE ya implementan los mecanismos de comunicación entre capas siguiendo MVC.

Usar JSF o Struts para la Capa Vista, Spring para la Capa Controlador, y JPA con Hibernate para la Capa Modelo sería una de las soluciones a la arquitectura de una aplicación J2EE.

Ventajas del patrón
MVC nos aporta una construcción de software muy mantenible, en la que se pueden localizar de forma ágil los errores. Supone un diseño modular, y muy poco acoplado, favoreciendo la reutilización.
Por ejemplo, podemos realizar una interfaz gráfica de escritorio, y una web, que compartirían las capas Controlador y Modelo, y solo trataríamos como desarrollos distintos las dos capas Vista.

La necesidad de centralizar

2009-02-25T19:28:00.004+01:00

El desarrollo de software es una actividad en la que se requiere alta colaboración entre los miembros de un grupo. Me gustaría hablar de comportamientos grupales que pueden favorecer en el forjamiento de un "equipo", pero eso lo haré en algún post más adelante. En este quiero hablar de herramientas que permiten mejorar el rendimiento de un equipo mediante la centralización de recursos.

El Entorno:
Cuando comenzamos un proyecto, lo primero que nos planteamos es cuál va a ser nuestro entorno de desarrollo. La forma de trabajar sin centralización pasaría por: elegir IDE, bajarlo, añadirle plugins y configurarlo a nuestro gusto. Esto por cada miembro del equipo. En este proceso, se puede llegar a consumir mucho tiempo. Yo propuse en mi empresa el uso de Pulse. Pulse se puede definir como un repositorio de Eclipses, en el que se pueden crear perfiles de Eclipse preconfigurados, y compartirlos con miembros de un equipo. Si enriquecemos un perfil con un plugin, automáticamente todos los miembros del equipo podrán usarlo.

Yo diseñé tres perfiles: uno para programadores J2ME, otro para programadores J2EE, y otro para programadores PHP, y todos comparten herramientas comunes como Mylyn o Subversive de las que hablaré más adelante.

Las Librerías:
Antes de centralizar las librerías, teníamos un escenario un poco caótico. Las preguntas: "¿qué versión usas? y ¿de dónde se descarga?" eran muy habituales. Con Maven se solucionan estos problemas. Maven sirve para muchas otras cosas, pero aquí trato de exponer sus bondades como repositorio único de librerías.

El Código
Antes de trabajar en la empresa privada, he trabajado muchos años como freelance. En este mundillo, también es muy normal trabajar con algún compañero de la Escuela. Aun recuerdo lo complicado que era coordinarse: "no toques este archivo que lo estoy haciendo yo", "antes de unir nuestros códigos funcionaba", "se me ha borrado y no tengo copia de seguridad"...
Este problema queda totalmente resuelto con un repositorio de código y control de versiones. Yo soy partidario de Subversion por muchos motivos que ya iré desgranando más adelante. Con Subversion sabemos que desarrollador ha tirado cada linea de código y podemos mezclarlas con otras, desecharlas, o volver a una versión anterior. Para Eclipse existe el plugin Subversive que es un buen cliente de Subversion.

Las Tareas
Para desarrollar software es preciso completar una serie de tareas, y en las distintas iteraciones realizar un seguimiento de errores. Trac permite realizar un workflow completo de tareas (trabajo finalizado, reescalado...). Tiene fuerte dependencia de Subversion, pudiéndose incluso visualizar el código de éste. Además, me permite realizar otras tareas relacionadas con la gestión del proyecto o documentación. Para Eclipse existe el plugin Mylyn, que permite asociar cada commit en Subversion a una tarea en Trac.

El despliegue
Aparte de los respectivos despliegues que lleva a cabo cada programador en su entorno, hay que realizar una labor de integración contínua, donde se "centralice" el resultado del trabajo realizado por cada miembro. Desde Subversion se pueden automatizar despliegues en un servidor mediante Hudson, y programar pruebas unitarias, generación de documentación o un snapshot para el cliente.

El conocimiento
En mi empresa intentamos introducir un nuevo elemento de I+D en cada proyecto. Muy a menudo, hemos tenido el problema de tener que volver a investigar algo por motivos como: la persona que lo hizo ya está en otro departamento, la persona que lo hizo no se acuerda, y en ninguno de los casos quedó por escrito nada. Es decir, esa inversión en I+D se perdió como lágrimas en la lluvia. Había que centralizar el conocimiento, buenas prácticas, librerías propias, bugs conocidos, en alguna parte.
Realicé un análisis de qué herramienta nos aportaba más. Las opciones eran un foro, o una wiki. No voy a entrar en demasiados detalles, pero para nuestras necesidades, lo mejor sin duda era una wiki. Cuando mi amigo Dani me comentó que en Google usaban continuamente wikis "para todo" me reafirmé en que la decisión tomada era la correcta. Soltelpedia está desarrollado con MediaWiki, al igual que Wikipedia.

Como habéis podido comprobar es solo una pincelada en la que intento plasmar las ventajas de "centralizar". Quizás me anime a profundizar en futuros posts en cada una de estas tecnologías (instalación, configuración...). Por otro lado, se podría haber hablado de otras tecnologías que hacen lo mismo. Las que expongo eran las que, después de un exhaustivo análisis, mejor se adaptaban a las circunstancias de mi equipo y mis proyectos... y ya están dando sus frutos.

Nuevos retos que contar

2009-02-25T10:15:00.006+01:00

Llevaba ya mucho tiempo teniendo ganas de escribir sobre mi trabajo. Precisamente éste, me ha impedido hacerlo antes, pero son tan apasionantes los nuevos retos que tenemos en mi empresa, que merece la pena hacer un sobreesfuerzo para contar como los alcanzamos. Los escollos son altos pero la ilusión, implicación y capacidad por superarlos, lo son más. Estoy convencido de que estamos en el buen camino.

Pronto habrá nuevos contenidos...

2009-02-24T20:52:00.000+01:00

Mi nombre es Alejandro R. Caraballo, dirijo el área de Ingeniería de Software de Soltel IT Solutions. Me apasiona la tecnología en general y mi trabajo en particular. Planificar-Ejecutar-Medir-Iterar.

Llevaba ya mucho tiempo teniendo ganas de escribir sobre mi trabajo. Precisamente éste, me ha impedido hacerlo antes, pero son tan apasionantes los nuevos retos que tenemos en mi empresa, que merece la pena hacer un sobreesfuerzo para contar como los alcanzamos. Los escollos son altos, pero la ilusión, implicación y capacidad por superarlos, lo son más. Estoy convencido de que estamos en el buen camino.