Fábricas de Software - la otra visión

Cuando oímos el término fábricas de software generalmente nos imaginamos un espacio enorme con largas filas de desarrolladores que se extienden hasta el infinito con lámparas colgando sobre cada línea y el incesante repiqueteo de las teclas.

Pero es solo imaginación. La propuesta para hacer realidad es muy diferente. Jack Greenfield es su artículo "The Case for Software Factories" expone las razones que motivan la aparición de las fábricas de software. La incesante demanda de software, aún y cuando es una de las actividades más riesgosas en términos de tiempo y dinero, requiere de nuevos modelos de construcción de aplicaciones. Esta necesidad en ascenso requiere de una fuerza de trabajo que sea cada vez más productiva y se señala que el modelo de "maestro-aprendiz" que ha prevalecido no será capaz de generar los ejércitos de desarrolladores y que aún teniendolos más que demostrado queda que la solución no es agregar y agregar personal a los proyectos.

La industria del desarrollo de software ha pasado por esto antes y lo ha intentado resolver de muchas maneras (CASE, metologías formales, OOP, etc) pero llega el momento en que son rebasadas por la realidad y es necesaria una revolución en lo más profundo para continuar en el negocio.

Cada una de las revoluciones anteriores han ido aumentando el nivel de abstracción con el que trabajamos. Se ha ido desde bit por bit a lenguajes, de funciones a clases y métodos, de programatico a declarativo. Se puede representar esto como una torre en la que el siguiente piso permite manipular conceptos más abstractos, más despegados del hardware que el piso anterior. Sin embargo existe una diferencia de velocidad entre el avance de la plataforma, es decir el hardware, y las herramientas. Estamos en un punto donde las herramientas y procesos de desarrollo se han quedado estancadas y atrás en relación a la capacidad de cómputo disponible y sobre todo de las exigencias de los consumidores.

Haciendo un símil muy recurrido con la industria de la electrónica, Greenfield hace una comparación dura y directa: los chips actuales no se construyen transistor por transitor, ya existen componentes predefindos que sirven de base y que sin esfuerzo permiten tener en el mercado los productos demandados por los consumidores.

La pregunta de oro es ¿se puede automatizar el desarrollo de software de la misma manera? Se dice que sí y de hecho ponen como muestra SQL y las bases de datos. Mediante una estandarización se ha conseguido beneficios como la integración de datos y cierto nivel de independencia que consiguen hacer el acceso a datos más fácil y consistente. También se refieren a las interfaces gráficas. Al final se identifican algunos patrones recurrentes:

• La repetición en la construcción de aplicaciones se identifican abstracciones reutilizables que se documentan y se aprovechan en desarrollos subsecuentes.
• Después se construye un framework o engine para implementar estas abstracciones y patrones. Esto permite construir aplicaciones simplemente creando instancias, adaptando, configurando y conectando entre sí los componentes de este fx.
• Finalmente se define un conjunto de herramientas y lenguajes para automatizar el proceso de construcción. Con esto se consigue reaccionar más rapidamente a los cambios ya que mucho del esfuerzo es automatizado y puede regenerse sin mucho esfuerzo.

Otras industrias aumentan su capacidad de producción moviendose a un proceso de manufactura en lugar del proceso artesanal individual o en pequeños grupos. En el proceso masivo se arman variantes de un mismo producto usando piezas genéricas de distintos proveedores y existe maquinaria para los procesos más simples y repetitivos. Se estandarizan procesos, diseños, empaque usando líneas de producto para facilitar la reutilización sistemática y al final, cadenas de suministro. Para poner en concreto lo anterior pénsemos en la industria automotriz. Hacen una implementación donde existen productos con algunas variantes (estándar, equipado, lujo) y se producen rápidamente (120 autos en 8 horas) y un rango de precios adecuados para su mercado.

Se han hecho analogías entre el software y otros bienes. Finalmente se reconoce que el software es similar a productos físicos o tangibles resultado de otros tipos de ingeniería tales como puentes, edificios y computadoras. Sin embargo existen importantes diferencias que le otorgan al software caraterísticas únicas. Al ser un ente lógico, abstracto, sin representación física, los costos se concentran en el desarrollo más que en la producción y debido a que el software no se desgasta ni acaba, su calidad depende de cualidades abstractas como fiabilidad y consistencia en lugar de durabilidad y resistencia.

El poder reutilizar componentes, cuyo desarrollo es caro, debe hacerse en un marco que permita aprovecharse en más de un producto dentro de un dominio (usar un mismo motor en más de un modelo de auto).

La reutilización sistemática da lugar a economías de escala y de alcance (scope) que son bien conocidas y aprovechadas en otras industrias. Las economias de escala aparecen cuando múltiples instancias identicas de un mismo producto se fabrican en masa en lugar de individualmente. A partir de un diseño original se crean prototipos (diseño), se refinan mediante procesos de ingeniería (desarrollo) y finalmente se fabrican masivamente (producción) mediante maquinaría o línes de producción de bajo costo (obreros) para satifacer la demanda. En el modelo de la economia de alcance se utilizan las mismas prácticas, procesos, herramientas y materiales para diseñar y crear prototipos de productos similares que se comercialzaran con algunas variantes.

La industria de software presenta importantes diferencias con las industria automotiva o electrónica pero se pueden encontrar algunas similitudes.

• En el mercado de consumo masivo como aplicaciones de escritorio en el cual sistemas operativos y suites de oficina se producen en grandes cantidades, el sofware se comporta como una economia de escala, similar a la industria automotriz.
• En el mercado empresarial en el que aplicaciones de negocio verticales no consiguen producirse masivamente, el software se comporta como una economia de alcance tal como la industria de la construcción.

¿Cómo se implementan estas prácticas de industralización en el desarrollo de aplicaciones? Si bien no existe una respuesta definitiva ya se están realizando esfuerzos para complementar los ambientes de desarrollo existentes. Microsoft dentro de su producto Visual Studio Team System ha aprovechado los esfuerzo que se han venido realizando en el equipo de Patterns & Practices. El resultado de esta estrategia se llama Guidance Automation Toolkit que es una extensión de Visual Studio 2005 que permite a los arquitectos y desarrolladores aprovechar los gadgets incluidos en los software factories para automatizar tareas claves del desarrollo desde el ambiente de Visual Studio.

Recientemente se han dado a conocer algunas software factories entre las que se incluyen la Smart Client Software Factory y la Mobile Client Software Factory. También existen otras factories que están desarrollo, por ejemplo la Web Service Factory que justo acaba de anunciar un último Community Drop.

En el Arquitecture Journal se publico el artículo A Software Factory Approach To HL7 Version 3 Solutions que fue el detonante para interesarme por este tema debido a que en el trabajo tenemos un área que procesa mensajes de HL7 mediante WebLogic Integration.

Finalmente, Haaron González expusó ayer en la Comunidad.NET del D.F. el tema Fábricas de Software de Cientes Inteligentes, lástima que olvidé la fecha y no pudo asistir.

Finito.