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