UML, DSL, y Microsoft, parte 2

En refuerzo de lo dicho antes, encuentro a Tad Anderson, escribiendo en .NET Developer´s Journal, que en septiembre de 2007 habla de las decisiones de Microsoft sobre UML, y su respaldo a DSL, afirmando que en dos años, no tuvo oportunidad ni medios de usar el set incluído en VSTS:
Over the past 2 years I have had the VSTS Architecture version installed and I have not used the DSL tools once on a project
Las razones muestran un camino que hoy parece estar remontándose:

A few years ago Microsoft decided to cut off its nose to spite its face.The war on UML started with the DSL movement.Although Microsoft still claimed to see UML as an essential tool, they stopped trying to compete with the rest of the market and tried to lead us down a new path that did not include UML.
With Rosario around the corner (a very big corner) the emphases is on Application Life-cycle Management (ALM).I think that is great. But the claim that their DSL tools will support the essential design documents is once again WRONG!!!! The DSL tools currently supported are the ones they are going to depend on again in the future.
Over the past 2 years I have had the VSTS Architecture version installed and I have not used the DSL tools once on a project. I have looked at them several times, but I always found SPARX Enterprise Architect (EA) easier to use to make meaningful artifacts. Microsoft did try to save a little face by saying they do support and suggest UML for domain modeling.
But there suggestion was to model in Visio (UML 1.2 or 1.4??), forward engineer the model to code and then open it up in their DSL class modeler. That is just plain dumb when tools like Enterprise Architect exist. Yes, Microsoft is partnering with SPARX now, but the ALM movement just confuses things because it introduces tools that step all over SPARX EA tools that support ALM, except for UML. Go figure.?.?.

Y concluye, tras relacionar el modelado con el marco en que lo usaría:

Microsoft’s ALM push will probably be good for project managers, but Microsoft still does not get that they are continuing to ignore the architect.

No está de más leer su nota completa. Es más contundente que lo que aquí extracto.

Leyendo a Matsumoto

Un aspecto relevante de la conferencia sobre Software Product Lines de 2007 fue el aporte de Yoshihiro Matsumoto. Decía la nota introductoria de SPLC 2007:

Yoshihiro Matsumoto is Adviser of ASTEM Research Institute of Kyoto. He started his career in Toshiba Corporation in 1954, where he took initiative in the applications of software to real time control systems and in building Toshiba Software Factory for those domains. After he spent 35 years in Toshiba, he switched to academic field and served a professor at Kyoto University, Osaka Institute of Technology, and Musashi Institute of Technology. He received Dr. Eng. degree from the University of Tokyo, and Fellow in 1982/Life Fellow in 2004 both from the IEEE.

Es notable el desconocimiento común sobre la actividad y logros de investigadores y profesionales japoneses en software, si nos atenemos a los medios usuales de difusión de noticias tecnológicas, aunque esto vale también en menor medida para la actividad de investigadores europeos. Lo más usual en las publicaciones de noticias tecnológicas es la atención hacia papeles de trabajo con orientación comercial, donde suele haber mucha hojarasca...Más profundamente, es probable que este desconocimiento provenga del distinto modelo de actividad en Estados Unidos y Europa, frente al japonés. En el caso de éstos últimos, el patrón de desarrollo es el de grandes empresas con investigadores empleados o academicos e institutos asociados. En el caso de Occidente, es mucho mayor el número de emprendimientos individuales o de pequeñas empresas, aunque también pese la acción de grandes conglomerados empresarios y estatales.
Como una confirmación de esta situación, Matsumoto ha logrado mención en el último tiempo gracias a su colaboración con Microsoft en la aplicación de ideas de Greenfield en Microsoft Japón (1 y 2). Pero su trabajo de investigación y de implementación sobre Factorías de Software y el sustrato que implica, tiene más de treinta años (cerca de cuarenta en realidad), siempre en Toshiba , y luego en la Universidad de Kyoto. En estos días, sigo su keynote en SPLC 2007, y su presentación sobre la Factoría de Software de Thosiba. Matsumoto trabajaba por una, y la denominaba como tal, tan temprano como 1977; y si me atengo a sus afirmaciones de 2007, basados en preparativos iniciados a finales de los sesenta. Volveremos sobre ésto.

Software Factory en Wikipedia

Hoy, por primera vez, encuentro una variación notable en el contenido del concepto Sofware Factory en Wikipedia. Luego de un prolongado proceso de cuestionamiento, parece haber tomado el rumbo correcto. Finalmente, las observaciones críticas de múltiples colaboradores concluyeron en acción, en el modo en que era de esperar: se eliminó la ambiguedad del concepto, se asignó el contenido anterior a una segunda acepción en el marco de Microsoft .NET, y se comenzó a redactar un verdadero artículo sobre el tema, dejando la versión .NET en lugar aparte, donde sus adeptos podrán seguir elaborando sus ideas, o incluso eliminarlas, como ya ha pasado con algunas de sus afirmaciones iniciales sobre Software Factory y sus relaciones con el diseño basado en modelos.
Es especialmente alentador observar que el trabajo colaborativo en Wikipedia tiende a resultados correctos en su evolución histórica. Durante meses, existieron advertencias de Wikipedia sobre el carácter tendencioso de la primera definición, acompañadas de observaciones específicas en los comentarios. Todavía hoy el artículo se inicia con una advertencia sana: This article or section is in the middle of an expansion or major revamping. You are welcome to assist in its construction by editing it as well.

En fin, ahora hay que ocuparse del verdadero tema, que por cierto es más que importante, más que lo que en este momento determina su definición redefinida.

Sin embargo, no me coinciden las fechas de actualización: la última versión que recuerdo es la que se puede ver en The Internet Archive con fecha 30 de marzo de 2007. La historia de revisiones comienza a establecer cambios mayores en febrero, aunque mi impresión es que estos cambios han aparecido mucho más cercanamente, durante mayo. ¿Será que mi caché me jugó una mala pasada? (¿O quizá no entienda correctamente cómo se procesa el mecanismo de manejo de revisiones de Wikipedia?). El caso es que el artículo, que a mi entender hasta hace no mucho más que tres o cuatro días era el núcleo de la definición de Software Factory, es ahora la nueva versión .NET, con fecha de inicio en 25 de mayo.

Factoría de Software no es solo outsourcing

Este comentario está motivado por las reflexiones de Mancarf, que conocí a propósito de un comentario suyo en otra entrada anterior, no del todo relacionada con lo que vamos a conversar. Tratando de conocer a quien efectuara un comentario a una entrada mía sobre factorías de software, entré a sus propias ideas sobre este tema. Manuel pone el acento, hasta donde leí (me falta completar la lectura), en la relación entre las factorías y el outsourcing. Más de una vez me pareció que era necesario aclarar este punto, que creo que está confuso. Aunque mejor es decir que se trata de una ambiguedad; Que el outsourcing se base en general en la idea de factorías, es una consecuencia. Estoy seguro que Manuel comparte este punto de vista también...

La idea básica que está detrás de la factoría, es la de construír el software de una manera análoga a como se construye un producto en la industria. Las empresas de manufacturas tiene una larga y madura experiencia en cómo producir, partiendo de patrones comunes, elaborando kits de componentes, reutilizando partes, estandarizándolas para que un proveedor pueda entregarlas, definiendo mediciones de tiempos, entre muchas técnicas; y ésto tanto en la fase de diseño y planificación de una nueva línea, como en la producción en masa del producto definido. Y lo mismo sucede con los proyectos de ingeniería que aplican procedimientos y componentes bien definidos, para generar un producto cuasi único, tal como un puente, un edificio, un barco.
Así, cuando los precursores hablaron de fábricas de software, pensaban en estas similitudes: en la mejora de cada aspecto de la construcción de software, para lograr procesos repetibles, medibles, usando componentes o patrones reutilizables, de tal forma que el proceso sea confiable, y económico. En su primera época, el interés estaba enfocado en el desarrollo propio, en grandes empresas o instituciones. Sólo ha evolucionado hacia una cercanía con el outsourcing en años más o menos recientes, en la medida que India, Irlanda, Brasil, Europa del Este y otros, pudieron convertir el diferencial de costo en un negocio conveniente.

¿Cómo veo a las factorías de software?: En efecto, como un requisito para ofrecer outsourcing; esto puede ser un buen negocio para algunos países, o dentro de un país, aprovechando nichos de mercado. Y aquí coincido con Manuel en cuanto a los límites que este esquema puede tener.
Pero el software como construcción industrial, como factoría, es una idea más general, y es en ese terreno en el que realmente me interesa. A condición de que un emprendimiento sea del porte adecuado, tanto por tamaño, como por su perdurabilidad, probablemente la generalidad de los proyectos podrían y deberían afrontarse utilizando prácticas y recursos típicos de una factoría.
Considero que en estos casos, las investigaciones sobre Lineas de Producto Software (SPL), así como las investigaciones sobre desarrollo basado en modelos (MDD), deberían ser una fuente de recursos a ser revisada y adoptada. Dados los auxiliares metodológicos, recursos y herramientas que hoy existen desarrollados, no es viable desconocerlos y omitirlos.

Nota: He mencionado la excelente y breve descripción que hace el ESI sobre MDD, que, siendo parte de su página de presentación, tiene el riesgo de estar disponible para leer ahora, pero no dentro de un año o dos. En previsión, un pequeño resúmen existe en estas páginas.
Sobre SPL, MDD, DSM y DSL, mucho se ha apuntado aquí. Solo es cuestión de buscar.

Integración contínua (Continuous Integration)

Aplicado a Plex, un artículo en curso de elaboración en la wiki toma uno de los puntos de particular interés no sólo en este caso, sino en general en las distintas variantes de generación de código a partir de modelos o directivas de alto nivel. El artículo parte del papel escrito por Martin Fowler sobre Integración Contínua, y examina lo que Plex cubre, y lo que le falta para lograr el objetivo: un equipo de trabajo desarrollando cada uno su parte, e integrándola a un repositorio común, con un proceso definido de resolución de conflictos, compilación, testeo, implementación (Any individual developer's work is only a few hours away from a shared project state and can be integrated back into that state in minutes. Any integration errors are found rapidly and can be fixed rapidly.This contrast isn't the result of an expensive and complex tool. The essence of it lies in the simple practice of everyone on the team integrating frequently, usually daily, against a controlled source code repository).
Las observaciones del autor del artículo (John Bell) apuntan a la necesidad de extender la integración del proceso de construcción de tal forma que sea posible tener control sobre todos los elementos participantes del proceso, y de todos los estados hasta su implementación. Difiero con Bell en cuanto a que es posible tomar más control del proceso partiendo de los recursos que hoy se disponen. Estoy de acuerdo en que este mayor control no está incluído en el producto mismo.
Estos aspectos son los que, en términos generales, hacen interesantes las ideas de Jack Greenfield sobre su Software Factory, más allá de su final concreción. Creo que existen más ideas estimulantes en la descripción genérica de su idea, que en cómo se la ha implementado.
Estaremos esperando el desarrollo ulterior del artículo en la wiki...

Bob Bemer sobre Software Factories

Volviendo al parcial artículo sobre el concepto de Software Factories en Wikipedia, rescato la dirección del antiguo papel de Bob Bemer sobre el tema. Bemer murió en 2004, y su espartana página desapareció al poco tiempo. Hoy Wikipedia no menciona este papel entre sus logros, pero afortunadamente existe The Internet Archive, que obra como un repositorio universal. Allí se puede consultar todavía lo que Bemer recordaba, así como la génesis de su página, desde 2000 hasta su muerte.
Para quien quiera corregir la entrada de Wikipedia.

Software Factories, una visión más objetiva que podríamos poner en Wikipedia

Sin buscar mucho, éste artículo sobre factorías de software, podría reemplazar con todos los honores al actual existente en Wikipedia. Me gustaría saber si el ajuste pudiera ser cuestionado o borrado (en la historia del artículo parece haber algunos forcejeos). Se ve aquí lo importante que Software Factories no toma en cuenta en Wikipedia en inglés:

A lo largo de la historia de la Ingeniería del Software ha aparecido repetidamente el concepto de fábrica con diferentes matices que se han ido adoptando de acuerdo a la propia evolución de la tecnología y los procesos software. En la actualidad el término ha vuelto a tomar relevancia en el sector de la industria del software, debido a las especiales condiciones socio económicas, tecnológicas y de madurez de la ingeniería del software; no obstante no debemos olvidar que, como se muestra en la Tabla 1, el concepto de fábrica software goza de una gran madurez y antigüedad.

1968	Aparece por primera vez el término “fábrica de software”
1969	Primera fábrica de software: Hitachi Software Works
1975	Fábrica software de la Systems Development Corporation
1976	Fábrica software de NEC
1977	Fábrica software de Toshiba
1979	Fábrica software de Fujitsu
1985	Fábrica software de Hitachi y de NTT
1987	Fábrica software de Mitsubishi

Tabla1. Primeros hitos en la historia de las fábricas de software

En este artículo haremos un recorrido por las principales etapas y conceptos que han ido marcando el término fábrica software, así como las principales empresas en implementar dichas estrategias, de lo cual puede obtenerse una importante visión y comprensión a la hora de constituir y evolucionar tanto fábricas como departamentos dedesarrollo en la época actual.

1. Años 70 y 80: origen de las fábricas de software

El término se acuñó en el año 1968, a la vez que otros tan famosos como el término reutilización (propuesto por McIlroy de AT&T en la famosa conferencia de ese año de la OTAN sobre Ingeniería de Software). En efecto, la primera vez que se cita “fábrica de software” es en un position paper presentado en el congreso IFIP (International Federation of Information Processing) del año 1968 por Bemer, quien afirmaba que los gestores de software no disponían de entornos adecuados: Bemer señalaba también que es imposible que los programadores hagan buen software simplemente bajo supervisión humana, mientras que “una fábrica, sin embargo, tiene más que supervisión humana. Mide y controla la productividad y calidad. Se mantienen registros financieros para coste y planificación”.

Fue Hitachi la primera empresa que utilizó el término “fábrica” en 1969 cuando fundó Hitachi Software Works.

Por otra parte en EEUU, la Systems Development Corporation (que formaba parte de Rand Corporation) estableció la segunda fábrica de software entre 1975-1976, llegando a registrar esta denominación.

Durante los años setenta y ochenta en Japón se siguieron instalando fábricas de software: NEC en 1976, Toshiba en 1977, Fujitsu en 1979 y 1983, Hitachi en 1985, NTT en 1985 y Mitsubishi en 1987.

2. Años 90: CASE, reutilización y procesos

Durante los noventa surgen diferentes aproximaciones a las fábricas de software

2.1. Fábricas basadas en Entornos de Desarrollo Integrados

A finales de los ochenta y principios de los noventa se implantó la primera generación de herramientas CASE (M Piattini & Daryanani, 1995), y los denominados Entornos Integrados de Desarrollo de Software (conocidos por sus siglas inglesas ISDE, Integrated Software Development Environments), y los Entornos de Ingeniería del Software orientados al Proceso (PSEE, Process-centered Software Engineering Environment)

En este caso, el contexto lo constituyen grandes empresas europeas, fabricantes de ordenadores, desarrolladoras de software y universidades.

El objetivo que se persigue es producir una arquitectura y un marco de trabajo para los ISDE. La estrategia utilizada es la de adaptar el entorno de soporte, creando una instancia de la fábrica en la organización de desarrollo. El modelado de procesos se pretenden estandarizar y soportar mediante herramientas automáticas.

2.2. Fábrica de componentes basadas en experiencia

Esta es la experiencia desarrollada en el SEL (Software Engineering Laboratory) de la NASA por Basili (V. R.Basili, 1989, , 1993; V. R. Basili, Caldiera, & Cantone, 1992), con el fin de experimentar con nuevas tecnologías en entornos de producción. Nace con el triple objetivo de mejorar la eficacia del proceso, reducir la cantidad de re-proceso y reutilizar los productos de ciclo de vida.

Ejemplos reales de factorías de experiencia son el SEL (Software Engineering Laboratory) del Goddard Space Flight Center de la NASA, el SEC (Software Experience Center) de DaimlerChrysler, o el EPIK (Engineering Process Improvementand Knowledge Sharing) de ICL.

2.3. Fábrica de software basada en la madurez de procesos

El contexto de esta aproximación lo constituye el modelo CMM, patrocinado por el Departamento de Defensa de EEUU con el fin de evaluar a los subcontratistas. El objetivo es crear un marco para la mejora de procesos software que permitan conseguir un proceso predecible, fiable y auto-mejorable que produzca software de alta calidad.

2.4. Fábrica de software basada en la reutilización

(Griss, 1993) señala que una reutilización efectiva requería más que tecnología para bibliotecas y código, y que utilizar sólo la metáfora de la biblioteca limitaba los resultados de la reutilización, la solución pasaba por familias de soluciones relacionadas. Este experto propone combinar la noción de fábrica de software de los años anteriores con la idea de los sistemas de fabricación flexible para dar lugar a la “fábrica de software flexible” en las que se construyen las partes para trabajar juntas y además se optimiza la producción de componentes y el ensamblado de productos con el fin de decrementar el reproceso de ingeniería. Enfatiza en prestar atención a los estándares de construcción, certificación y pruebas, haciendo trabajar de manera conjunta las guías de diseño y los procesos cuidadosamente afinados.

2.5. Fábricas de renovación de software

Al acercarse el final de la década de los noventa se agudizaron aún más los clásicos problemas del mantenimiento de software (Polo, Piattini, & Ruiz, 2003), sobre todo por las conversiones de los programas existentes debido al “problema” del año 2000 y la introducción del euro. Surgen entonces otras “fábricas” denominadas “fábricas de renovación de software”, en las que entran los programas en una especie de línea de ensamblado, pasando por una secuencia de herramientas de transformación (Brunekreef (Brunekreef & Diertens, 2002).

En (van den Brand, Sellink, & Verhoef, 2000) se presenta incluso la generación de componentes para la fábrica de renovación de software: transformadores de código, re-generadores, re-estructuradores, migradores, etc.

2.6. Fábricas enfocadas a otras técnicas de gestión de la calidad

(Swanson, Kent, McComb, & Dave, 1991) destacan la aplicación de TQM (Gestión de Calidad Total) y reutilización, así como generadores de código y herramientas CASE, buscando la flexibilidad de las fábricas de software.

También en los noventa en Japón se trasladaron métodos de la fabricación de automóviles a las fábricas de software, como el proceso de desarrollo concurrente (Aoyama, 1996) que integra conceptos convencionales de proceso-producción con los sistemas de producción “esbeltos” (lean) y otras técnicas de gestión basadas en el tiempo. Estas técnicas lean persiguen la eliminación del desperdicio dentro de una organización, combinando la planificación y los sistemas de producción.

3. Años 2000: COMPONENTES, MODELOS y LÍNEAS DE PRODUCTOS

En los años 2000 se siguió perfeccionando las técnicas de las décadas anteriores, afianzándose la ingeniería basada en modelos, el desarrollo basado en componentes, las líneas de producto y los modelos de madurez de procesos.

Así en (Li, Li, & Li, 2001) se puede encontrar una propuesta más reciente de modelo de fábrica de software para organizaciones chinas, en las que (como se puede ver en la figura), se considera que una fábrica de software se expresa como (Correa, Werner & Zaverucha, 2000):

Fábrica Software = (Especificaciones de Gestión, Líneas de producto) x (Procesos, Personas, Técnicas)

Ya que se combina, desde el punto de vista directivo, la gestión de la calidad orientada a procesos, con el punto de vista técnico, de las líneas de producto basadas en tecnologías de componentes. En esta propuesta se integran ISO9000, CMM y PSP/TSP (véase (M. Piattini, Caballero, & García, 2006)).

(Greenfield, Short, Cook, Kent, & Crupi, 2004) de Microsoft vuelven a poner de moda a nivel internacional el concepto de fábrica de software como enfoque de desarrollo de aplicaciones en el que confluyen el desarrollo basado en componentes, el desarrollo dirigido por modelos y las líneas de producto software. Lenguajes Específicos de Dominio (DSL), patrones, armazones (frameworks), y herramientas (incluido código y metadatos) que permiten implementar el esquema para construir un miembro de la familia de productos.

Destaco en verde, al final, la referencia del artículo al concepto de Software Factories en la versión Greenfield/Microsoft. Como corresponde, ocupa la última parte del artículo, porque fueron los últimos en mencionarlo. Si se toma el trabajo de revisar el artículo original, se verá que la bibliografía es bastante más amplia que UN solo libro.
KybeleConsulting, la empresa que sostiene el papel, es originaria de la universidad Rey Juan Carlos, y sus autores, Javier Garzás y Mario Piattini, son conocidos estudiosos del tema.

Software Factory en Wikipedia: Cómo contaminar una enciclopedia

Mientras preparaba algunos cambios a mi página sobre modelado, quise incorporar la definición que Wikipedia tuviera sobre fábricas de software, en este caso, en su versión inglesa, que normalmente marcha más adelantada y detallada que la versión en castellano. Sorprendentemente, me encontré con un artículo parcial, orientado como una operación de márketing antes que como un intento desinteresado y objetivo por definir un concepto. Ninguna noción genética del concepto, ninguna referencia a otras visiones: una repetición de las mismas definiciones que se pueden encontrar en cualquier página de Microsoft, o de sus bloggers. Lo sorprendente es encontrar entre los constructores de la definición a Martinig, de Methods & Tools, y a Steven Kelly, de Metacase. No es sorprendente, por el contrario, encontrar a Jezz Santos.
Nadie puede cuestionar el interés de un entusiasta de un concepto por difundirlo o explicarlo, pero lo menos que se puede esperar, especialmente de personas que saben lo que hacen, es que mantengan la objetividad al explicar sus ideas. El enfoque dado por "Wikipedia" a Software Factories ignora completamente las discusiones iniciadas en la década de los 70, a Bob Bemer, a Hitachi y otras empresas japonesas, al SEI, ni a nada que no sea la visión que Microsoft descubriera en 2002/2003, treinta años después de que el concepto se forjara. En el colmo del (¿cómo llamarlo? ¿márketing infantilista?), la única referencia a otras ideas la dá éste párrafo:

Although the term "software factory" is used by Microsoft in association with their .NET Framework, "Software Factories" are much broader in use and application.

Por supuesto, ¿qué otras referencias podía tener el tema, que no fueran las dedicadas a Jack Greenfield, Keith Short, Steve Cook, Stuart Kent yJohn Crupi?

Steven Kelly nuevamente sobre Software Factories

Durante el mes de octubre, Steven Kelly publicó un par de notas en su blog que comparto en más de un aspecto. De una ya hemos hablado; la otra fue motivada por un artículo de Jack Greenfield en Methods & Tools, y retoma la discusión iniciada comentando a Jezz Santos: qué es primero, el problema o la solución.
El artículo de Greenfield es más explicativo que otros sobre su esquema, aporta algunos elementos de interés, pero también refuerza las dudas sobre el valor de su iniciativa. Pensaba pormenorizar algunos de sus conceptos, pero Kelly lo hace con claridad. Recomiendo leer su opinión, siguiendo el conjunto de la discusión, que incorpora referencias a Jezz Santos y Juha-Pekka, que completan la idea.

Jack does hint at more specialized factories than the earlier very generic "horizontal" factories he has tended to talk about. But the level of abstraction is not being raised much above how people currently code:

Known good patterns and practices in the target domain are harvested, refined and encoded into domain specific tools and runtimes. The tools are then used to rapidly select, adapt, configure, complete, assemble and generate solutions that use the runtimes.

Let's do a thought experiment. Imagine yourself back in time to when applications were built with assembly language. Which of the words that I've italicized above would indicate a radical shift upwards in the level of abstraction? E.g. if you can select among some existing chunks of assembly language -- nice maybe, but you're still working on the same level: you've not moved to third generation languages yet. Only the final verb, generate, accomplishes that change.

In the same way, insofar as Jack's article is a good description of Software Factories, it looks like their emphasis is more on small percentage improvements of existing ways of building software. That's a shame, especially given that earlier they seemed more focused on the DSL and generation elements that they share with Domain-Specific Modeling. The $64,000 question is: why this change of emphasis? Jack, Jezz, Prashant Sridharan and other MS people have all made comments along the lines that doing real problem-domain-based DSM has proven too hard for them. Why are they failing, when so many others are succeeding? For examples of success, just take a look at the articles from the upcoming 7th OOPSLA workshop on Domain-Specific Modeling (e.g. 24, 14 and 10 are all graphical DSL examples).

Steven Kelly sobre DSL´s y plataformas

Steven Kelly, de Metacase, abre una más que interesante discusión clarificadora en el terreno de las vías de contrucción de software, una que tiene que ver con las factorías de software. Esto vale un pormenorizado seguimiento, que no cabe por tiempo en una sola nota. Por lo tanto, ahora sólo quisiera destacar una o dos afirmaciones suyas a propósito de afirmaciones de Jezz Santos, que refuerzan mi impresión sobre las SF:

The task when creating a DSM language is thus to achieve the raise in the level of abstraction away from the bits and bytes of the implementation, and to offer a smooth, impedance-free mapping between the problem domain and the language. For both of those, we need to focus on the problem domain (the domain expert view) not the solution domain (the implementation in code).

(...) Let's look at a couple of other people's perspectives. First up, Microsoft's Jezz Santos:

If you understand the difference between problem domain and solution domain in software design, you will know that [software] factories are all about the solution domain. We are so far away from modeling problem domain and turning it into software just yet - forget it for now. It has proven impractical at this time, it is too big a step at this point, we need to evolve to that later.

If that really is the Microsoft party line then I'm seriously disappointed. Maybe Microsoft are "so far away" from a real raise in the level of abstraction, but others most certainly have proved that it's practical. Pushing out that kind of poor advice is a disservice to Microsoft's customers, dragging their modeling languages down to near the level of the code. Failing to raise the level of abstraction much was the key reason why Ordina only achieved a productivity increase of less than 20%, despite spending man-years on extending Microsoft's DSL Tools.

Maybe Microsoft are so focused on selling their platforms and frameworks that they are misled into thinking those are primary, and the customers' actual problems and needs are secondary? From a neutral point of view I'd have thought it would be self evident that problems come first, and solutions are dependent on the problems. There can be many different solutions, built with different technologies, that all solve the same problem. Only a technology vendor would take the technology as primary, and declare that all customer problems must be expressed in terms of that technology to be valid.

Kelly pone la discusión sobre construcción de software en buenas bases. Servirá, así como el material que se deriva de sus comentarios, para abrir aquí algunas líneas de pensamiento. Será en días y posts próximos...

Code Generation 2008

Me acerca Pedro Molina la recordatoria de que Code Generation 2008 abre la llamada a presentación de ponencias a la conferencia de tres días en Cambridge, UK. Esta reunión, continuidad de la muy sustanciosa de 2007, tiene la virtud de reunir a las distintas vertientes interesadas en la generación de aplicaciones por medios más abstractos y rigurosos que el heroísmo de los programadores. Desde su inicio, Code Generation tuvo un criterio abierto para reunir y clasificar a la diversidad de herramientas dedicadas a la generación de código. Sigue siendo hoy el mejor lugar para acudir en busca de fundamento teórico, estado de situación de las investigaciones, estado del mercado y evaluación de productos. La reunión de 2008 promete ser tan interesante como la de 2007, con la discusión de las líneas de acción que se abren a partir de los conceptos de arquitecturas dirigidas por modelo (MDA, Model Driven Architecture), lenguajes específicos de dominio (DSL, Domain Specific Languages), programación generativa, y líneas de producto software (SPL, Software Product Lines), siguiendo lo que están ocupando los intereses actuales, explicados en la llamada:

Call for Session Proposals
Submission Deadline - Friday January 18th 2008

We are currently seeking high-quality session proposals covering topics in model-driven software development (including Software Factories, Model-Driven Architecture (MDA), Domain-Specific Languages (DSLs), Generative Programming, Software Product Lines and related areas). Sessions could cover topics such as:

• Tool and technology adoption
• Code Generation and Model Transformation tools and approaches
• Defining and implementing modelling languages
• Domain Analysis and Domain Engineering
• Language evolution and modularization
• Meta Modelling
• Runtime virtual machines versus direct code generation
• Flexibility in code generation
• Approaches to code generation
• Approaches to combined development (partial code generation with partial handwritten code)

Real-world case studies based on any aspect of these and related approaches are particularly encouraged although more theoretical sessions are also welcome.

Una reunión que debe ser agendada, y una lista de participantes que debe ser seguida. Trataré de sistematizar los papeles relacionados con la reunión anterior en una próxima nota.
Es importante destacar al otro organizador del encuentro, Software Acumen, la empresa que ocupa a Mark Dalgarno, quien cumple una excelente labor explicando el valor de SPL.

Factorías de Software ¿Horizontales y Verticales? dos o tres apuntes más

No más sobre el artículo de Jezz, salvo dos o tres apuntes finales:

• Las líneas de Producto no pueden ignorar las variaciones de plataforma. La afirmación de Jezz acerca de este tema, constituye una importante limitación de SF, si así es (y así debe ser muy probablemente):

  Now, I don’t want to set the expectation that this mapping can or should be platform independent (such that MDA promotes) since, platform independence is a much larger challenge than technology or implementation independence. And one that practical software factories in general avoid. Platform independence requires platform independent architectures, and effective specific software factories will define successful platform specific architectures. Remember, software factories are very solution domain specific. Platform independent models are likely to be too abstract to become practically useful for product line development.

• La idea de concentrarse en "factorías horizontales" es una cuestión de mercado, legítima, pero que no representa todos las formas de entender los "core assets".
  
• La cuestión planteada sobre propiedad intelectual (tres capas de participantes) conduce a un tema que es importante, ineludible, y difícil de resolver con estas restricciones de plataforma y de marco base: la integración de "legacy assets".

En adelante, volvermos sobre estos temas, pero ya no alrededor del artículo de Jezz.

Una sutil variación sobre SFs...

Para seguir con la nota al pie de la primera entrada sobre el tema, estoy volviendo atrás en la agresiva campaña sobre Software Factories versus MDA/UML. Reviso el blog de Jack Greenfield, actualizado por última vez el 24 de noviembre de 2006. Encuentro allí que el papel mencionado sobre factorías en Visual Studio, ha desaparecido. Sí se encuentran la discusión 1 y el papel 2, el más usado durante un buen tiempo. A la vez, Keith Short publica en enero de 2006 su última entrada en su blog. Quizá Microsoft haya preferido desarrollar sus ideas sin las aristas irónicas sobre MDA y UML que todavía pueden verse en el sitio de Greenfield y Short.

Factorías de Software ¿Horizontales y Verticales? III

Volviendo una vez más sobre la nota de Jezz Santos, quisiera tomar uno de los puntos críticos observados por él sobre el modelo Software Factories: la variabilidad, que en definitiva es el punto fundamental, en su nota, que permite construír una "factoría vertical", basada en una "horizontal". Dice Jezz sobre el tema:

In order for a horizontal software factory itself to be reusable in multiple vertical domains (which is where it is ultimately destined for) there has to be some level of customization that allows it to be specialized towards any particular vertical domain. If we don’t allow this, then we simply can’t adapt a factory to create specific enough product lines, which means we are limited to the productivity we can achieve with it as a reusable asset. That’s not to say we can’t. We can do the product lines, but the overhead of doing so is much larger than it needs to be, because some things in the particular domain will either be common, or specific across the whole product line for that domain. Remember, the power of factories is in how specific they can be.

Y qué observa sobre la variabilidad disponible (en su criterio):

Verticalizing a factory today can seem impossible given the tool-sets we have at our disposal.
For most customizations of today’s factories you need to ‘crack open’ the factory and mess about with the source code internals of the recipes, DSL’s and the like. This is not a guided experience, and requires very deep technical knowledge of the factory, and deep technical VS extensibility skills. Not an easy ramp-up for those new to factories.
Extending a factory today is a function of what external interfaces the factory may expose today (if any at all!). For example the patterns & practices Web Service Software Factory does a good job of providing a number of extensibility points and interfaces, both via a programming model and configuration. But anything beyond what it supports at the programming API level, and you'll have to crack it wide open, effectively voiding the warranty and support policy of the factory. It’s wild-west country from there onwards.

Más adelante, de nuevo sobre sus posibilidades actuales:

(...) we would need a way of formally declaring the points of variability of the product architecture of a base (horizontal) factory. These declared points of variability could then be provided with default values/views/assets by the base factory. Or the factory may declare them ‘abstract’ requiring vertical factories to be built to subclass them and extend these points through customization interfaces.
We would then need a ‘customization authoring tool’ that we use to load the base factory into, and extend these pre-defined customization points with standard tools, that creates for us a set of customized assets output into a vertical factory in some form.
In this way we would not have to crack open a software factory any alter recipes or DSL’s just to predefine say, the data contracts of a web service product. Instead we can provide a simple subclass that hooks into a predefined point of variability customization interface and either provide fixed factory configuration, or extend the architecture of the product.
However, I feel this customization capability may be too far out for us right now. Instead we need to look at practical means today to achieve the same net effect (albeit a less guided experience).

Jezz insiste sobre este estado del problema en varios puntos, mientras examina las vías de "verticalizar", pero este es el planteo, sin entrar en más detalles...Sus palabras dan una sensación de inmadurez del esquema en su totalidad, con soluciones aún no retempladas para aspectos básicos de lo que debe conseguir (un poco distinto de las tajantes afirmaciones que en algunos papeles se observan).
Para tomar un poco de distancia de esta vista del problema, es conveniente releer cómo define variabilidad el SEI:

All architectures are abstractions that admit a plurality of instances; a great source of their conceptual value is, after all, the fact that they allow us to concentrate on design while admitting a number of implementations. But a product line architecture goes beyond this simple dichotomy between design and code–it is concerned with identifying and providing mechanisms to achieve a set of explicitly allowed variations (because when exercised, these variations become products). Choosing appropriate variation mechanisms may be among the product line architect's most important tasks. The variation mechanisms chosen must support

• the variations reflected in the products. The product constraints (see Core Asset Development) and the result of a scoping exercise (see the "Scoping" practice area) provides information about envisioned variations in the products of the product line–variations that will need to be supported by the architecture. These variations often manifest as different quality attributes. For example, a product line may include both a high-performance product with enhanced security features and a low-end version of the same product.

• the production strategy and production constraints (as described in Core Asset Development). The variation mechanisms provided by the architecture should be chosen carefully, so they support the way the organization plans to build products.

• efficient integration. Integration may assume a greater role for software product lines than for one-off systems simply because of the number of times it's performed. A product line with a large number of products and upgrades requires a smooth and easy process for each product. Therefore, it pays to select variation mechanisms that allow for reliable and efficient integration when new products are turned out. This need for reliability and efficiency means some degree of automation. For example, if the variation mechanism chosen for the architecture is component selection and deselection, you will want an integration tool that carries out your wishes by selecting the right components and feeding them to the compiler or code generator. If the variation mechanism is parameterization or conditional compilation, you will want an integration tool that checks the parameter values for consistency and compatibility before it feeds those values to the compilation step. Hence, the variation mechanism chosen for the architecture will go hand in hand with the integration approach (see the "Software System Integration" practice area).

Support for variation can take many forms (and be exercised many times [Clements 2002c, p. 64]). Mechanisms to achieve variation in the architecture are discussed under "Example Practices."

Products in a software product line exist simultaneously and may vary from each other in terms of their behavior, quality attributes, platform, network, physical configuration, middleware, and scale factors and in a multitude of other ways. Each product may well have its own architecture, which is an instance of the product line architecture achieved by exercising the variation mechanisms. Hence, unlike an organization engaged in single-system development, a product line organization will have to manage many related architectures simultaneously.

There must be documentation for the product line architecture as it resides in the core asset base and for each product's architecture (to the extent that it varies from the product line architecture). For the product line architecture, the views need to show the variations that are possible and must describe the variation mechanisms chosen with the rationale for the variation. Furthermore, a description–the attached process–is required that explains how to exercise the mechanisms to create a specific product. The views of the product architectures, on the other hand, have to show how those variation mechanisms have been used to create this product's architecture. As with all core assets, the attached process becomes the part of the production plan that deals with the architecture.

Respecto a los mecanismos de variación, transcribimos su definición:

Variation mechanisms (1): Jacobson, Griss, and Jonsson discuss the mechanisms for supporting variability in components (see the following table) [Jacobson 1997a]. Each mechanism provides a different type of variability. The variation of functionality happens at different times depending on the type. Some of these variation types are included in the specification implicitly. For example, when a parameter is used, the specification includes the specific type of component mentioned in the contract or any component that is a specialization of that component. In the template instantiation example below, the parameter to the template is Container, which permits variation implicitly via the Inheritance pattern. The Container parameter can be replaced by any of its subclasses, such as Set or Bag.

One aspect of variability that is important in a product line effort is whether the variants must be identified at the time of product line architecture definition or can be discovered during the individual product's architectural phase. Inheritance allows for a variant to be created without the existing component having knowledge of the new variant. Likewise, template instantiation allows for the discovery of new parameter values after the template is designed; however, the new parameter must satisfy the assumptions of the template, which may not be stated explicitly in the interface of the formal parameter. In most cases, configuration further constrains the variation to a fixed set of attributes and a fixed set of values for each attribute.

Types of Variation [Jacobson 1997a]
Mechanism	Time of Specialization	Type of Variability
Inheritance	At class definition time	Specialization is done by modifying or adding to existing definitions. Example: LongDistanceCall inherits from PhoneCall.
Extension	At requirements time	One use of a system can be defined by adding to the definition of another use. Example: WithdrawalTransaction extends BasicTransaction.
Uses	At requirements time	One use of a system can be defined by including the functionality of another use. Example: WithdrawalTransaction uses the Authentication use.
Configuration	Previous to runtime	A separate resource, such as file, is used to specialize the component. Example: JavaBeans properties file
Parameters	At component implementation time	A functional definition is written in terms of unbound elements that are supplied when actual use is made of the definition. Example: calculatePriority(Rule)
Template instantiation	At component implementation time	A type specification is written in terms of unbound elements that are supplied when actual use is made of the specification. Example: ExceptionHandler
Generation	Before or during runtime	A tool that produces definitions from user input. Example: Configuration wizard

Variation mechanisms (2): Anastasopoulos and Gacek expound on a somewhat different set of variation options that includes [Anastasopoulos 2000a]

• aggregation/delegation: an object-oriented technique in which the functionality of an object is extended by delegating the work it cannot normally perform to an object that can. The delegating object must have a repertoire of candidates (and their methods) and assumes a role resembling that of a service broker.
• inheritance: which assigns base functionality to a superclass and extended or specialized functionality to a subclass. Complex forms include dynamic and multiple inheritance, in addition to the more standard varieties.
• parameterization: as described above
• overloading: which means reusing a named functionality to operate on different data types. Overloading promotes code reuse but at the cost of understandability and code complexity.
• properties in the Delphi language: which are attributes of an object. Variability is achieved by modifying the attribute values or the actual set of attributes.
• dynamic class loading in Java: where classes are loaded into memory when needed. A product can query its context and that of its user to decide which classes to load at runtime.
• static libraries: which contain external functions that are linked to after compilation time. By changing the libraries, you can change the implementations of functions that have known names and signatures.
• dynamic link libraries: which give the flexibility of static libraries but defer the decision until runtime based on context and execution conditions
• conditional compilation: which puts multiple implementations of a module in the same file. One is chosen at compile time according to the appropriate preprocessor directives.
• frame technology: Frames are source files equipped with preprocessor-like directives that allow parent frames to copy and adapt child frames and form hierarchies. On top of each hierarchical assembly of frames lies a corresponding specification frame that collects code from the lower frames and provides the resulting ready-to-compile module.
• the ability of a program to manipulate data that represents information about itself or its execution environment or state. Reflective programs can adjust their behavior based on their context.
• aspect-oriented programming: which is described in the "Architecture Definition" practice area
• design patterns: which are extensible, object-oriented solution templates catalogued in various handbooks (for example, the work of Gamma and colleagues [Gamma 1995a]). We mentioned the Adapter Design pattern specifically as a variation mechanism earlier in this practice area.

La variabilidad es un aspecto central del desarrollo de Líneas de Producto, que es extensamente tratada en SPL, con definiciones precisas sobre cómo sostenerla. Más exactas que las que Jezz parece manejar. No lo cuestiono: SF seguirá madurando, construirá DSLs, y las inconsistencias tomarán un rumbo estable. Lo que no cuadra, es alguna publicidad tan terminante con otras formas de encarar el problema.

Factorías de Software ¿Horizontales y Verticales? II

Siguiendo la nota anterior...
El planteo de Factorías de Software sostenido por Microsoft contiene un componente que produce confusión, al denominar su iniciativa con las mismas palabras usadas durante mucho tiempo por distintos emprendimientos de desarrollo con criterios de rigor industrial. "Software Factory" implica un concepto de mayor alcance que el dado por el conjunto de recomendaciones y productos asociados a la idea por Microsoft. Pero existe un segundo componente en la definición que también resulta controversial: el desarrollo como líneas de producto (Software Product Lines, SPL, en los conceptos del SEI (Software Engineering Institute). En este caso, el concepto es central, y explícitamente indicado como base de las Software Factories por Jack Greenfield. Sin embargo, existen diferencias en el desarrollo práctico de las factorías, si nos atenemos a Jezz, y a lo que se puede ver en el sitio de MS. Al comienzo de su nota, Jezz declara una vez más la relación existente entre SF y SPL:

In order for a horizontal software factory itself to be reusable in multiple vertical domains (which is where it is ultimately destined for) there has to be some level of customization that allows it to be specialized towards any particular vertical domain. If we don’t allow this, then we simply can’t adapt a factory to create specific enough product lines, which means we are limited to the productivity we can achieve with it as a reusable asset. That’s not to say we can’t. We can do the product lines, but the overhead of doing so is much larger than it needs to be, because some things in the particular domain will either be common, or specific across the whole product line for that domain. Remember, the power of factories is in how specific they can be.

La vinculación es central en el libro de Greenfield, fundamento de esta iniciativa:

Recognizing and planning around these assumptions leads to defining families of similar solutions, and separating their common features, which make them similar, from their variable features, which make one member of the family different from the next. The common features are used to develop a custom process for building the members of the family, and of a set of reusable assets supporting the process. The variable features are used to drive parameterization, configuration, assembly and other techniques for accommodating the differences between the family members.
This is the thinking underlying the development of the components that are truly reusable, such as RDBMSs and GUI frameworks, although it may not have been recognized at the time by all of the people involved in building those components.
Work at the Software Engineering Institute (SEI) formalized this thinking in the concept of Software Product Lines. Software Product Line practices have been well established through many books, case studies and experience reports, and are widely accepted in the software engineering community.
Software Factories is a methodology for using domain specific languages and other technologies to automate Software Product Lines. They were developed by leveraging the work of David Garlan, as described in the book, in consultation with the authors of Software Product Lines at the SEI, and with other experts in related disciplines, such as pattern languages, generative programming and feature based development.[Comentado en su blog]

Por lo tanto, es razonable ver cuánto ayuda SF en ese terreno, así como deslindar el valor de la idea de Líneas de Producto Software más allá de la encarnación en el proyecto de Microsoft. Y vale lo mismo para las Factorías de Software. Es decir, es importante discernir que ambos conceptos no son necesariamente lo que Microsoft postule, y que pueden diverger. Que el concepto es del mayor interés, y que no tiene por qué acompañar el resultado que le dé a Microsoft, así como también las ideas de la empresa pueden contribuír al perfeccionamiento de la iniciativa. Como lo puede hacer MDA (Model Driven Architecture), aunque Jezz no desee entrar en esa discusión.
Más aún, es absolutamente legítimo suponer que el libro de Greenfield, que obra como sustento de SF (uno referencia al otro, mutuamente), sea aplicable con otro conjunto de herramientas que no sea Visual Studio Team System (VSTS), ni sus extensiones. Por esto mismo el concepto es interesante, conveniente de analizar, poniendo entre paréntesis los recursos concretos con que Jezz construye. ¿Es generalizable el tipo de problemas con que Jezz se encuentra? ¿O tienen que ver con su implementación de la idea de SPL?.
Sobre esto trataremos de escribir, con los limitados recursos de tiempo que disponemos. Si fuera posible, sería bueno presentar también otros puntos de vista que hoy existen sobre cómo resolver SPL.

Factorías de Software ¿Horizontales y Verticales?

Jezz Santos abre en su blog una dimensión de las factorías de software, versión Microsoft, que posiblemente sea una de las mejores maneras de cotejar las diferencias con el estándar MDA y otras variantes de desarrollo orientado por modelos. Desgraciadamente no tengo casi tiempo, lo que limita mis posibilidades de desmenuzar en detalle sus comentarios, pero trataré de releerlo, analizarlo, y luego apuntar algunas diferencias.
Para comenzar, se presenta el problema, en palabras de Jezz:

The title of this post would not mean anything if you didn't know what 'horizontal' and 'vertical' software factories were. In that case then for simplification, ‘Factory Verticalization’ merely means ‘Factory Specialization’. Ironically enough though, most of the factories being build today are ‘Horizontal Factories’, so specialization in these cases means ‘Factory Verticalization’.
In almost all my interactions with customers about factories I am constantly reminded that ‘verticalization’ is the one key principal aspects of software factories today which is largely going unaddressed (and poorly understood). I am convinced that there is a clear and immediate requirement that we need to deal with more effectively in the present. I go so far to say that without catering for Verticalization of any factory, would seriously limit the adoption of factories in the future. It is such an important aspect to provide for if we are to realize the full vision of product lines and asset reuse.

Inmediatamente, Jezz carga un poco más la definición:

Before I get into this lengthy discussion about different aspects of verticalization, I think I need to explain what we mean by 'Horizontal' and 'Vertical' software factories in order to set the right context for the discussion.
In software factories we use these terms (vertical and horizontal) in the respect as they use them to describe markets. In software development these terms are generally well understood to differentiate broad skill-sets (or more general capabilities) typically focused at particular technologies and platforms, from the skill-sets/capabilities applied to specific industry domains (e.g. finance, manufacturing, retail, etc). The intersection of these axes in software engineering, in theory at least, applies the expert technical solution people to build instances of solutions for particular vertical domains, under the guidance and knowledge provided by the industry domain experts. The assumption is that the horizontal assets (people and artifacts) can be reused (with some specialization) across many vertical domains - it’s really a synergy of the two axes.

Existen en este planteo dos aspectos para analizar:

1. ¿Software Factories representa un "mercado horizontal" para Microsoft?
2. ¿Qué distancia existe entre este concepto de lineas de producto, y el de Software Product Lines del SEI (para mencionar el centro que probablemente más trabaja sobre este punto)

Sobre el primer punto, así parecería demostrarlo el repositorio visible en Codeplex, (Microsoft patterns and practices, Software Factories), con cuatro casos desarrollados. Asimismo, las referencias de Jezz en su nota:

From a marketing perspective, if you can call it that (which is really isn’t), one of the primary reasons Microsoft currently releases only horizontal factories is that: at present, software factories are a new concept to the industry, and Microsoft is leading the charge here. It makes perfect sense that the first factories from Microsoft must have some large significance and impact and benefit to the existing marketplace. So they chose horizontal factories to tackle first

Sobre el segundo, las definiciones del SEI dicen algo distinto:

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.
(...) How is production made more economical? Each product is formed by taking applicable components from the base of common assets, tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance, adding any new components that may be necessary, and assembling the collection according to the rules of a common, product-line-wide architecture. Building a new product (system) becomes more a matter of assembly or generation than one of creation; the predominant activity is integration rather than programming. For each software product line, there is a predefined guide or plan that specifies the exact product-building approach.
(...) The common set of assets and the plan for how they are used to build products don't just materialize without planning, and they certainly don't come free. They require organizational foresight, investment, planning, and direction. They require strategic thinking that looks beyond a single product. The disciplined use of the common assets to build products doesn't just happen either. Management must direct, track, and enforce the use of the assets. Software product lines are as much about business practices as they are about technical practices.

A partir de aquí, conversaremos. Comenzando esta semana...

Nota: Esto es muy curioso...Desapareció del sitio de Microsoft el ítem sobre SF en Arquitecturas, y ya no se encuentra el enlace a la explicación difundida durante meses sobre el tema (http://msdn.microsoft.com/architecture/overview/softwarefactories/) . Tendré que buscar más (¿?)

Software Product Lines en CM Crossroads

Durante algún tiempo se desarrolló una conversación en CM Crossroads sobre Líneas de Producto en Software (SPL, Software Product Lines). Está congelada en este momento, pero vale la pena destacarla: SPL es en general el espacio de discusión más interesante actualmente, desde el punto de vista del software como industria, y quizá desde el punto de vista de la ingeniería de software. En general, SPL requiere poner en práctica conceptos fundamentales de la disciplina, o no habrá resultados. En el caso de esta discusión, SPL es discutido desde el punto de vista del manejo de los cambios.
SPL implica trabajar con patrones, componentes, aplicar normas de manejo de proyecto y de trabajo en equipo, definir claramente líneas de desarrollo, integrar herramientas, automatizar la generación de código, y mucho más. Tengo una línea de búsqueda abierta en del.icio.us sobre SPL, pero curiosamente es muy poco el material que recolecto. Probablemente se trate de que nadie le pone una etiqueta a estos conceptos; aunque justamente SPL o SF (Factoría de Software, Software Factory) definen en su título un conjunto de actividades no sólo aplicables a una organización que "fabrique software", sino que, con ciertas limitaciones, son aplicables a cualquier organización grande que construya su propio software. (O que delegue parte de su construcción, como en algún momento veremos).
Volviendo a CM Crossroads, son particularmente útiles las intervenciones de Mark Dalgarno, de quien hay más para comentar, Thiago Henrique Burgos de Oliveira, antes que nada para volver a destacar la importante experiencia brasilera en Factorías de Software, Brad Appleton, y Frank Guerino.
Appleton destaca un artículo de John D. McGregor en JOT, extendiendo la disciplina de Administración de Cambios (CM) a SPL.

Volveremos sobre esta discusión...