Experiencias en una factoría de software

¿Cómo hacer software en estándares abiertos sin morir en el intento? Parece que las principales claves de la productividad en el desarrollo de software siguen siendo todavía las viejas recetas: planificar, prever y corregir.

Experiencias en una factoría de software

18 julio 2009

LA OPINIÓN DEL EXPERTO

A nadie escapa que el desarrollo de software en estándares abiertos es una tarea compleja, y aún más dificultoso si se hace cumpliendo con normas y estándares abiertos que aseguren la calidad del mismo. En software la complejidad puede significar el desarrollo de decenas de miles de líneas de código y el trabajo de decenas o centenares de personas que se reconocen creativos.

Desarrollar software requiere una gran inversión, un equipo de desarrolladores, testadores y jefes de proyecto, una comunicación clara con el cliente del que se tendría que obtener un documento de especificaciones y requisitos claro, una buena planificación que deje bien claro quién y cuando hace cada tarea, de qué forma y con qué finalidad para que se obtenga el producto requerido. Es por esto que no puede ser abordado de forma simplista.

¿Y qué es lo que quiere el cliente? Básicamente un software que le facilite la operatividad de su organización, que le permita un ahorro de costes en producción, que sea de fácil mantenimiento y susceptible de ser ampliado ante cambios de sus necesidades sin grandes desembolsos añadidos.

La calidad de software es la primera cualidad deseable de una aplicación. ¿Cuáles son los factores que determinan la calidad del software? Podríamos enumerar muchos: buscamos sistemas rápidos, fiables, fáciles de usar, modulares, estructurados, etc.

Los factores externos son perceptibles por el cliente. Los factores de calidad internos como modularidad, eficiencia o legibilidad son sólo perceptibles por los desarrolladores y técnicos, pero repercuten de forma directa en aspectos externos, detectables por el usuario, como corrección o robustez.

Factores determinantes

Un buen software es, ante todo, correcto. Es decir, sirve para realizar con exactitud sus tareas. Además, un software de calidad deberá ser extensible, robusto, funcional y, reutilizable.

Pues una de las primeras características de software en estándares abiertos radica en que trabajamos en un entorno orientado a la reutilización, donde el programador se concentra en desarrollar unidades o módulos de software que no solo sirvan para atender las necesidades del presente, sino que posibiliten un uso posterior y futuras modificaciones.

Otras cualidades exigibles son la portabilidad, es decir su facilidad para implantar los productos en diferentes entornos y su eficiencia --sinónimo de rendimiento-- para realizar la tareas usando los mínimos recursos posibles, entre otros.

Dentro de los factores de la calidad del software existen dos de gran importancia. Nos referimos a la modularidad y a la escalabilidad. Un software es modular cuando está construido por partes independientes e interconectadas entre sí. La modularidad permite la escalabilidad de los productos, es decir, que sea fácilmente ampliable, más fácilmente adaptable y reutilizable, más fácil de administrar, con capacidad para integrarse en otros módulos o sistemas.

Finalmente hay que referirse al reto que implica la evolución meteórica de la tecnología. Es imprescindible hacer referencia a la evolución, con todo lo que conlleva de nuevos desarrollos y de innovación. Estar en el vértice de uno de los movimientos generadores de crecimiento económico y de oportunidades empresariales es muy estimulante para quienes trabajamos con Open Source y los estándares abiertos.

Calidad y estándares abiertos

Por mi experiencia personal --y la de los desarrolladores de Intecna Soluciones--, para desarrollar software de calidad hay que utilizar estándares abiertos. Si dejamos al margen las ventajas de los estándares abiertos en cuanto a disponibilidad, lo más relevante desde el punto de vista de la calidad es que estamos utilizando especificaciones técnicas «normalizadas».

Es decir, controladas por una organización que se encarga de su desarrollo y que evolucionan a través de un proceso de maduración conducido por los principios de pragmatismo y eficacia. Los ejemplos nos resultan a todos familiares: HTTP, HTML, WAP, TCP/IP, XML, VoiceXML, por citar algunos.

Pero al mismo tiempo, trabajar con estándares abiertos nos plantea el reto de elegir entre las múltiples tecnologías disponibles y entre una gran diversidad de herramientas existentes para el desarrollo de un producto.

En este contexto estimo que la principal dificultad de quienes desarrollamos software en estándares abiertos radica en acertar en la elección de aquellos estándares que van a perdurar a través del tiempo, que mejor soportarán las modificaciones.

Al software en estándares abiertos le es aplicable aquello que dijo Darwin sobre las especies: «No sobrevivirán las más fuertes, tampoco las más inteligentes, lo harán aquellas que más se adapten al cambio».

Los vigilantes de la fuente

¿Cómo afronta una empresa de Open Technologies el desarrollo de software en estándares abiertos? En primer lugar, mediante vigilancia tecnológica. Todo desarrollador debe estar al día sobre la información existente en la comunidad, fundamentalmente sobre novedades tecnológicas, pero también sobre proyectos, posibles partners y normativas.

La vigilancia tecnológica nos permite utilizar proyectos y herramientas en estándares abiertos, probarlos, y ayudarnos a decidir, en suma, si optamos por crear nuevas herramientas para el producto que buscamos o nos inclinamos por trabajar sobre una tecnología preexistente.

Esto significa que todo programador de software en estándares abiertos está obligado a «no reinventar la rueda», a no perder el tiempo haciendo algo que ya está hecho. No en balde, uno de los beneficios que derivan de la vigilancia tecnológica es su contribución a acelerar el desarrollo de las soluciones, lo que nos permite dar un mejor tiempo de respuesta a las necesidades de los clientes, lo que sin duda es una ventaja sobre el software propietario.

En segundo lugar, una factoría de software se apoya en los laboratorios de pruebas y testeo de los aplicativos producidos con el fin de verificar, testear y analizar la funcionalidad y usabilidad de las aplicaciones, su comportamiento, etc.

Con las pruebas nos aseguramos la producción de un software de calidad, la satisfacción de los clientes y aumentar nuestras posibilidades de ser mejores que la competencia; pero además, testar los productos nos permite reducir costes, porque nos ayuda a prevenir errores y simplifica el mantenimiento posterior.

Dos cuestiones más nos parecen de fundamental interés. Por una parte, la investigación sobre nuevas herramientas y componentes, de los que existe una gran disponibilidad en los archivos y repositorios públicos y en listas de correos especializadas; por otra, la exigencia de interoperabilidad para todos los desarrollos.

Los modernos sistemas de información se diseñan en base a una arquitectura orientada a servicios (SOA) que permite modular la integración de los servicios y procesos de negocio. La piedra angular de esta integración es la plataforma de interoperabilidad, que permite la integración de servicios, organización de procesos y control operativo.

¿Cuáles podrían ser las claves de la producción?

En primer lugar, como ya he señalado con anterioridad, no volver a inventar la rueda. Hay que evitar el desarrollo de todo el software desde el nivel más inferior y optar por utilizar estándares, como ocurre en otras tecnologías.

Se impone realizar una buena selección de componentes. La ventaja de trabajar con estándares abiertos deriva de la posibilidad de disponer de «repositorios de software» donde partes de software ya estandarizadas puedan ser automáticamente seleccionadas, personalizadas, ensambladas e implantadas fácilmente como solución a una necesidad de desarrollo.

En tercer lugar, estos estándares deben ser abiertos y reutilizables. Ello nos permitirá crear aplicaciones robustas, adaptables y bajo presupuestos factibles.

En cuarto lugar, hay que aprovechar lo mejor de cada herramienta y diseñar en base a una arquitectura orientada a servicios (SOA).

En quinto lugar tendríamos que hablar de la metodología de trabajo, es decir cómo mejorar la producción, lo que nos plantea la necesidad de contar desde el principio con responsabilidades definidas y también, desde el punto de vista de los medios, con un repositorio central de componentes reutilizable y organizado.

Por supuesto ocupa un lugar destacado el equipo humano. ¿Cualidades que se requieren? Junto a un buen bagaje intelectual y laboral, un buen nivel de competencias emocionales entre las que figuran la creatividad, el optimismo, el trabajar en equipo, el saber adaptarse al entorno.

Finalmente considero imprescindible la aplicación de una política de mejora continua. El concepto deriva del sistema productivo justo a tiempo, que surge del intento de eliminar el desperdicio y simplificar la producción mediante la aplicación del método de prueba y error.

Con la mejora continua perseguimos optimizar permanentemente todos los niveles del desarrollo del software. Y también lo aplicamos en Intecna al finalizar un proyecto. Nos reunimos y reflexionamos sobre las experiencias que nos trasladan los que han participado en el desarrollo de un proyecto. Son las lecciones aprendidas.

Por Lourdes Calvo, directora Factoría Software Intecna Soluciones

Loading...
'); doc.close(); });