[Software Factories] Introducción (Parte 1)

Hace un tiempo que estoy estudiando sobre Software Factories, mas precisamente, leyendo los libros: "Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools" de Jack Greenfield y Keith Short y "Practical Software Factories in .NET: From Theory to Practice—A Primer, Reference, and Case Study" de Gunther Lenz y Christoph Wienands. Ademas de leer todo lo que diga "Software Factories" en google.

Según sitan todas las fuentes, y en especial referencia al CHAOS Report, son muy pocos los proyectos de desarrollo de software que se consideran exitosos (alrededor del 30%) mientras que el 50% tuvo problemas de irse del presupuesto, tiempo de entrega y calidad. La porción restante fueron cancelados durante el ciclo de vida del desarrollo. El informe le asigna una minúscula importancia a los aspectos técnicos aislados como causal de los fracasos en la terminación e implementación exitosa de los proyectos aunque es evidente que ellos se deben a la manera en que se construye el software, y esta es una tarea eminentemente técnica. Es decir, si se simplificara dramáticamente la tarea de desarrollo seguramente la calidad, la productividad, los costos y tiempos de entrega se dispararían a niveles mas deseables que los actuales. Y esto es un problema de "como se hace" (Técnica).

Haciendo una comparación entre nuestra industria y otras de diciplinas ingenieriles mas maduras como la mecánica, electrónica y/o civil, Jack Greenfield y Keith Short dicen que fallamos al desarrollar software porque:

Razón 1 - One-off development
Cada proyecto se construye desde CERO e independientemente de otros sistemas similares. Los Assets (no encuentro una palabra mejor pero llamemosles componentes o mejor "tangibles") de estos sistemas no se crearon con el prop'osito de ser reutilizables. Esto encuentra varias razones:

• hacer algo reutilizable requiere una IDENTIFICACION y ANALISIS de aquellas características comunes que puedan servir en un futuro cercano.
• hacer algo reutilizable requiere que se DISEÑE con ese propósito en mente,
• que se CONSTRUYA,
• que se VERSIONES y MANTENGA,
• que se DOCUMENTE (si no se documenta no es reutilizable por más que se cumpla todo lo anterior)

En otras palabras, hacer un tangible reutilizable es una inversión que hay que analizar.

Una de las formas de reutilización mas común en la actualidad es la dupla copy/paste, que desde mi punto de vista es la peor práctica de todas. Mejores resultados tenemos en la reutilización de componentes en binario o ILs como el Framework .NET, Componentes COM/Activex, los paquetes Java y las .lib en C sin perjuicio de crear nuestros propios binarios para reutilizarlos en esa forma.

Otro problema con la reutilización de fuentes es que el código es mas facil escribirlo que leerlo y eso hace que al leerlo, al no tener la documentación de este (casi nunca la tenemos), al no estar pensado para reutilizarlos facilmente y al no sernos "agradable" la "estética" del código, se nos cruce el pensamiento "Por dios! quien hizo esta porquería!?. Hay que hacerlo de nuevo". Esto es reinventar la rueda. Más allá del hecho de si servía o no, el tema es que habrá dos fuentes con multitud de características similares que bien podrian haberse hecho de una manera mas inteligente.

Razón 2 - Monolithic systems and increasing systems complexity
Los sistemas monolíticos son aquellos en los que sus componentes están fuertemente acoplados y no permiten tratarlos de manera sistemática porque un cambio en una parte produce la necesidad de hacer cambios en muchos de los componentes con los que se relaciona. El problema se observa con mayor claridad al tener que mantener, extender y adaptar el sistema a los cambios en los requerimientos post

implementación. Como contrapartida de los sistemas monolíticos tenemos los sistemas pluggeables.

Razón 3 - Working at low levels of abstraction
Este tema ya lo toqué en otros post sobre Domain Specific Language y NBusiness. Veamos como se desarrolla un software: Nos llegan los requerimientos de nuestro Program Manager/Team Leader y, despues de las reuniones de rutina, en que nos comentan hasta como se peina el cliente, empezamos con un pequeño brainstorn personal o con algún grosso amigo (hoy en dia esto lo hacemos casi desde CERO).

Cuando tenemoslas ideas y los documentos y llega la hora de hecharle mano al código (en este caso ejemplifico con c# pero podría ser cualquier lenguaje: VB, Java, SQL, XSLT, etc) comenzamos así:

using System.IO;
:
:

public class Product
{
private string productName;
public string Name
{ get {...} set {...} }

La pregunta es: puede ser esta la manera más natural de especificar el comportamiento y las cualidades de un componente de catálogo de productos? No estaremos hilando demasiado fino? Es más, me atrevo a preguntar: no debería estar hecho ya por alguien más o es que acaso nadie nunca escribió un producto que trabajase con productos?. Está bien, acepto que para algo así falta mucho, que habria que estandarizar bloques de construcción y un montón de cosas más pero la pregunta inicial sigue en pie. Son los lenguajes de propósito general los adecuados para todos los casos particulares? Claro que no. Aquí es donde entran, entre otras cosas, los DSLs o Lenguajes específicos de un dominio.

Aclaro, como desarrollador siempre pienso en función de lenguajes de programación pero bien podrían ser lenguajes de empaquetado, de testings, de validación, de especificación de requerimientos o cualquier otro.

Como alternativa a este bajo nivel de abstracción se analizan una variedad inmensa de cosas, entre las que ya las DSL, como Model Driver development (MDD) y Model Driver Architectural (MDA). Todos con mayor o menor grado de relación con UML y su posibilidad, gracias a XML o mas precisamente XMI, de automatizar una gran cantidad de tareas de desarrollo como así también elevar el nivel de abstracción.

Este es sin dudas el tema mas interesante si se lo estudia en forma aisladas y es el que mas material tiene escrito (tanto que te cansa).

Razón 4 - Process immaturity
Alguién podrá pensar: "ah no!, ese problema nosotros no lo tenemos. Tenemos CMMI! jajaja". Bueno, la verdad es que esto es para vos también y se resume así: o demasiado formal o demasiado agil.

Veamos por qué:

Los mas agiles:
Ventajas:

• responden bien ante los cambios
• comunicación en lugar de documentación
• desarrollo y corrida en iteraciones pequeñas
• los requerimientos se validan continuamente gracias a una comunicación constante con el cliente
• continuamente se hace refactorin de las aplicaciones

Fallan:

• imposible de escalar a grandes proyectos o muy complejos.
• escaza documentación de la arquitectura crean problemas de soporte e integración
• equipos distribuidos

Los mas formales:
ventajas:

• tienen perfectamente establecidos los roles, artefactos y actividades activities
• hacen énfasis en los requerimientos, análisis y diseño
• la arquitectura se documenta con modelos

Fallan:

• Responden lento a los cambios
• perfectamente escalables a grandes proyectos o proyectos complejos

Existen muchas discuciones en torno a este tema. Cual es mejor?. La verdad es que en la práctica, esta elección muchas veces no es posible. Hay muchos aspectos a tener en cuenta además de los arriba mencionados que entran en juego y que condicionan una libre elección de la metodología. Por ejemplo: Si tengo grupos pequeños de gente muy capacitada (que no se me van a ir el mes que viene), expertos en temas puntuales, con experiencia, trabajando juntos, con clientes que confian en nosotros a los cuales podemos llamar o ver en cualquier momento, con proyectos relativamente pequeños; bueno, agil es la respuesta. Ahora, si tenemos clientes con distintos usos horarios, idiomas, o nuestro cliente es un gobierno extranjero, que no nos conoce, que quiere mas que una estimación un presupuesto ajustado, que puede hacernos una auditoría, si cotizamos en bolsa, si tenemos proyectos muy grandes, con mucha gente (que se nos va el mes que viene), o somos una pyme de una provincia del interior de un remoto pais que no conoce nadie llamado Argentina y queremos salir a vender nuestros productos por el mundo: bueno, no queda otra, entrá a http://www.sei.cmu.edu/.

Razón 5 - Rapidly growing demand for software systems
No solo que se incrementó la demanda de software sino que además va creciendo el tamaño y la complejidad del mismo. Los clientes de hoy solicitan funcionalidades o características que hace 2 o 3 años atras ni se les hubiera cruzado por la cabeza. Así que no piensen solo estriban siguiendo la metodología HP (Horse Programming)

Bueno, esto ya está mas largo que un post de Diegum prometo seguir con este tema en próximos post.

Lucas Ontivero