Voy a continuar aquí la serie «Introducción a los conceptos de Software Factory» que comencé en mi blog anterior con las entradas:
Me permito taer aquí un fragmento de un post anterior para definir el concepto:
<cita>
Software Factory
Si se le hubiese llamado de otra manera nos habriamos visto forzados a realizar un esfuerzo mental para averiguar y tratar de entender de que se trata este concepto pero desgraciadamente esta palabrita «Factory» nos habilita a pensar cualquier cosa. Las analogías que encontramos por todos lados con fabricas de zapatos, electrodomésticos y autmóviles terminan de confirmar nuestras fantasias mal fundadas. No son pocos los que creen que se trata de hacer software como si de automoviles se tratara, simplemente ensamblando algunas partes hechas en una linea de montaje y automatizando, robots mediantes, los detalles como el color de la pintura y otros. Bueno, no es así. (sic)
Distingamos entre Software Factory como paradigma y como instancia. Como paradigma, es una alternativa a los métodos actuales de construcción que intenta resolver los 5 problemas planteados en el post anterior ([Software Factories] Introducción (Parte 1)) cuando las aplicaciones a construir comparten características comunes. Como instancia (SCSF por ejemplo), un Software Factory es un conjunto de herramientas, procesos tailorizados, frameworks, patrones y modelos (por lo general embebidos en los frameworks y/o herramientas integradas del IDE) y otros contenidos que usan para trabajar sobre una Linea de Productos.
</cita>
En esta entrada intentaré echar un poco de luz sobre software factory como paradigma sin caer en la definición de paradigma. Como paradigma, software factory es una manera distinta de pensar, analizar, diseñar, organizar, construir y gestionar el desarrollo de software con el propósito de sortear las 5 razones del fracaso de los proyectos de software en la actualidad:
- Razón 1 – One-off development
- Razón 2 – Monolithic systems and increasing systems complexity
- Razón 3 – Working at low levels of abstraction
- Razón 4 – Process immaturity
- Razón 5 – Rapidly growing demand for software systems
Desde este punto de vista, SF produce o mejor dicho propone, un cambio radical en la manera hacer las cosas. Que cosas? TODAS!
<opinion>
Puesto que todas las razones, salvo la razón 4 «Process immaturity», se producen en mayor o menor medida por un escazo nivel de reutilización de tangibles y que además se encuentran demasiadas analogías con industrias con foco en la «producción intensiva» y no en el «desarrollo intensivo», sumado a conceptos un poco futuristas como el de «Software Supply Chains» es que se cae en la creencia de que SF es solo reutilización de código en cualquiera de sus formas: fuentes y/o binarios como librerias, componentes, frameworks, application blocks, paquetes, assemblies, funciones traidas con copy/paste, ws o cualquier otra.
</opinion>
En cuanto al aspecto más cercano al código, este paradigma intenta cumplir con lo que la OOP nunca cumplió del todo: la reutilización!. Todavia me acuerdo de «las clases son totalmente reutilizables!!!» si claro, solo que son dependientes del contexto por lo que en realidad es el contexto lo realmente reutilizable por lo que se las agrupó en librerias, componentes, frameworks o llamense como quieran. Además de que solo aquellas que son de un uso muy genérico y muy granulares las que se pueden reutilizar en la actualidad, todavía sigo sin encontrar una clase factura, cliente, orden de pedido, reclamo y tantas otras que necesito para mis desarrollos que pueda reutilizar.
El encapsulamiento, la fina granularidad y muchos tipos de impedancias encontradas entre OOP y otros componentes también son atacados por este paradigma.
En cuanto al análisis, diseño, comunicación con los clientes y generación de código, SF toma lo mejor de MDA mientras que intenta solucionar mediante los reutilizables, DSLs y extensiones de los IDEs las falencias de CASE, acercando el análisis y el diseño a un contexto específico (determinado en gran medida por la linea de productos). No más diagramas genérico a validar por un cliente que no los termina de entender (a veces yo tampoco), ni más código genérico de mala calidad producido por herramientas CASE de terceros, basta de tanta libertad a los desarrolladores, basta de pensar y de hacer (de mil maneras distintas) todo de nuevo, desde los gráficos hasta el código.
En cuanto a la organización de los desarrolladores, o quizás de los conocimientos y habilidades, SF reconoce que no son todos iguales y distingue aquellos con mayor conocimiento técnico y del dominio del problema, quienes construyen los SF, de aquellos quienes lo utilizan y enriquecen con su feedback.
Por último en este artículo, vuelvo sobre las metodologías. Aquí también SF plantea una alternativa y me cito de nuevo:
<cita>
(sic) el tema de las metodologias cuyo problema resumia como «o (son) muy formales o (son) muy ágiles». Greenfield y Short plantean (lo que a muchos nos parece obvio) que existen dos tendencias extremas con sus pros y contras. A diferencia de lo que uno podría esperar, Greenfield y Short no creen que una metodología más formal sea más MADURA, por el contrario, entienden que son inmaduras por extremistas.
(sic)(sic)(sic)…(otros cuantos sic)…(sic)(sic)(sic)
La clave es preservar la agilidad mientras se mantiene la posibilidad de escalar la complejidad introducida por el tamaño y la distribución geográfica de los proyectos. Lo verdaderamente importantes es como esta posibilidad va tomando forma real mediante la implementación del paradigma de Software Factories.
Los autores siguen diciendo que el problema de las metodologias formales es que son demasiado abstractas en el sentido que para poder utilizarse deben ser tailorizadas a cada proyecto o necesidad particular. La idea detrás de esta crítica, que no lo es tal, es tailorizar los procesos a una familia de productos concreta.
Es decir, enfocar los procesos hacia las tareas puntuales de todo el ciclo de vida de una familia de productos (sic). Así, por ejemplo, debería por cada actividad facilitarse los recursos necesarios como wikis, links a documentación importante (sic), información de contactos, guias específicas (instructivos) sobre como realizar tarea, checklists aplicables a la tarea, estilos de codificación, detalles de cual/es es/son el/los próximo/s paso/s en el desarrollo, herramientas, políticas, (sic). Todo esto debería estar integrado al IDE y en lo posible automatizado.
</cita>
continuará…..
Lucas Ontivero
Lucas, muy buena la serie de posts de Software Factories. Confieso que me costo darme cuenta que habías cambiado de blog en el medio, pero al final pude leer las 3 partes que conforman la introduccion completa al tema.
En nuestra empresa hace un tiempo venimos discutiendo el tema de las metodologias y los procesos, ya que en la practica se nos presentan varias de las problematicas que vos planteas y realmente no estabamos encontrando un marco conceptual que nos permitiera encararlas a todas de forma exitosa.
Es decir, somos una empresa acreditada CMM y eso nos da unas cuantas ventajas en varios aspectos que mencionas en tus posts. Tenemos un marco de trabajo formal que nos previene de grandes errores o desviaciones y facilita el mantenimiento de las aplicaciones desarrolladas, pero por otro lado, al pasar de un proyecto a otro, en muchos casos tenemos escasa reutilización, no solo de codigo o componentes, sino de personas y conocimiento de negocios.
Intuitivamente nos empezamos a dar cuenta que el problema pasa por plantear que nuestra especialización es el «Desarrollo de Software» en su sentido mas amplio. Como si desarrollar soft para un banco fuera lo mismo que para una fabrica (anti especializacion vertical).
Hasta ahora, investigando un poco, la respuesta formal que habíamos encontrado pasaba por el modelo de «software factories», el cual estas introduciendo en tus posts. Si bien la implementacion practica del modelo es algo que personalmente considero todavia esta medio verde (creo que Carlos Zanini planteo algo similar al respecto), me parece que por ahi va a venir la respuesta a este tipo de problematicas.
Felicitaciones por el blog y espero seguir leyendo posts de semejante nivel.
Un abrazo.
Pablo
Hola Pablo, gracias por los halagos a mis posts y gracias or leerme, no sabia que visitabas.
Le diste justo justo al punto, no todo el mundo lo ve claro a la primera y es por eso que escribo esta serie para explicar lo conceptual mas que lo práctico porque entiendo que eso es lo que puede influir en la manera de pensar el desarrollo de software.
Probablemente mi próxima entrada sea sobre el concepto de linea de productos que es el escenario o la condición para la implementación de un SF.
Saludos.
Lucas
Buenas …
pues mas q interesantes los posts; y Pablo tiene razon, actualmente las herramientas están medio «verdes» para comenzar a crear una SF; pero es cuestion de animarse !!! creo q se puede crear una base muy buena donde apoyarse para comenzar a industrializar el desarrollo de Software y a partir del mismo comenzar a crear las herramientas que necesitemos. (un defecto muy grande que arrastran las herramientas actuales es la falta de contadores para medir las metricas de la produccion :S).
Saludos
Hola ElBruno,
Gracias por lo que dices de mis post, la verdad es que para mi que te leo siempre es un honor.
Lo que pienso es que en realidad lo que está verde es el conocimiento de la teoría subyacente a SF que requiere un cambio paradigmático profundo. Esto lleva a un cambio cultural en las organizaciones en las que se implementan y afecta a todos y a todo.
La pregunta es: como vamos a hacer las cosas de ahora en mas? luego, como resultado de la respuesta, y después de cambios en la manera de consevir el desarrollo de software y en un cambio cultural, surgirán las herramientas y ahora si afirmamos: estan medio verdes si señor.
Un abrazo.
Esta entrada es parte de la serie "Introducción a los conceptos de Software Factory" que hasta