PTC compra MKS

Otro cambio de manos en la industria del software: PTC compra MKS, la empresa canadiense dedicada a herramientas de manejo de ciclo de vida del software. MKS es (o fue) un actor importante en el mercado de iSeries (o AS400, o System i, o como se llame), a través de Implementer y otras herramientas asociadas. A su vez, Implementer fue un producto comprado a Silvon (1998), diseñador originario del producto. MKS con esa compra integró una cartera de productos orientados al soporte del  ciclo de vida de desarrollo de software, que fuera el núcleo de su actividad desde su inicio. Su desaparición (o absorción, para ser más exacto) concentra un poco más la industria, como viene sucediendo desde el 2000 aproximadamente.
Aunque de esto hace ya algunos años, he tenido contacto con la empresa, que heredó, con la compra a Silvon de Implementer, el producto de administración de cambios (MKS-CM Connector) para 2E (hoy CA 2E). Su cambio de propietario traerá cambios de estrategias y partidas en el personal (diseñadores, ingenieros, comerciales) que harán su futuro un poco más anónimo y genérico. Es que ALM es un mercado de commodities...
Para los seguidores de Plex y 2E, CM First, base de Webclient, soporta un producto de administración de cambios para el iSeries (Matchpoint) que también deberá reacomodar sus cargas ante el cambio de guardia de uno de sus competidores.

Brad Appleton sobre Software Product Lines

Brad Appleton, que es una autoridad en administración de configuración y versionamiento, ha comenzado a enfocarse en Software Product Lines, con la particularidad de aportar el enfoque de la configuración, que debería ser un punto importante del problema. En el último tiempo ha dedicado al menos dos artículos en su blog:
Software Product-Line Architecture and Product-Families, dedicado a presentar brevemente el tema, pero apuntando al aspecto de la configuración.
Commonality and Variability Management, dedicado a presentar un aspecto central, el manejo de los aspectos comunes y las variaciones, con referencias a algunos papeles que discuten el problema en detalle.
Hoy simplemente quería destacar la participación de Appleton. En otro momento volveremos sobre el tema, como seguramente lo hará él mismo: Unir SPL con SCM es algo que se produce naturalmente.

CM Crossroads sobre trazabilidad

La última actualización de noticias de CM Crossroads agrupa varios artículos sobre Trazabilidad publicados durante Agosto. Este concepto impacta en la calidad y confiabilidad con que se manejen los procesos de construcción de software. No está de más dedicarles un tiempo. Los artículos son:
Traceability and Auditability: Definiciones, especialmente sobre auditorías.
Traceability and Auditability: Satisfying your Customers: Más detallado sobre trazabilidad

One of the most common queries in our shop is: What went into a build? This may seem like an innocent question, or to some who know better, it may seem like a terribly complex question.

When we ask what went into a build, we ask the questions:

• What problems were fixed?
• What problems are outstanding?
• What features have been added?
• What requirements have been met?
• Which updates (i.e change packages) went into the build?
• Which files were changed?
• How have run-time data configuration files changed?

Why is this so common a query in our shop? Well first of all our ALM toolset makes it easy to do. But secondly, when something goes wrong, we want to isolate the cause as quickly as possibly. If a new delivery to a customer introduces a problem they didn't previously have, we ask: What changes went into this build as compared to the customer's previous release build? We then screen these based on the problem and more times than not isolate the cause quickly. Even more frequently, if the system integration team, or verification team, finds a problem with an internal build, we go through the same process and isolate the cause quickly. By having a sufficiently agile development environment that packages a couple of dozen or so updates into each successive build, we're able to pinpoint new problems and hopefully turn them around in a few minutes to a few hours. Finally, we need to produce release notes for our customers. This type of query is the raw data needed by the technical writer to produce release notes. It's also the raw data needed by our sales team to let prospects know what's in the new release, or what's coming down the pipe.

Traceability & Auditability: Do you really know what went into production?: La relación de la trazabilidad con la puesta en producción del software:

Change management has two main objectives. The first is to provide support for the processing of changes, typically initiated via the service desk. Such processing includes change identification, analysis, prioritizing, planning for their implementation, decisions for their rejection or postponement, and decisions for their integration in new product releases. The second objective is traceability (i.e., to make it possible to list all active and implemented changes). It should also be possible to track the modifications of different items due to a specific change. (e.g. Part of the ITIL Knowledge database.)

By extending the Service Desk into ALM, traceability will not only include configuration items (CIs) in production, but will also provide the capability to link to all application development artifacts to be able to perform end-to-end impact analysis, including the scope of the resolution of the problem under analysis.

Audit Trails, Traceability - Because Sometimes Things Go Wrong: La trazabilidad en el seguimiento de problemas

Any time we make a change to production, there is the risk that something will go wrong. Risk is a fact. The only way to eliminate risk is to never do anything. (But of course, that is not an option.) So we are left with actions we can take to mitigate those risks. Configuration Management (CM) is mainly about risk mitigation. Everything we do in CM is designed to reduce the likelihood that things will go wrong, or to reduce the adverse impact when they do go wrong. CM helps us to avoid many failures, and to recover quickly from those few that we can't avoid. But how do audit trails and traceability fit into this picture? Traceability doesn't prevent errors, and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools?
On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.
Answering 6 Questions
Both auditing and traceability are mechanisms that are designed to answer the six questions: who, what, when, where, why, and how. For example:

• Who made the change? Who authorized it? Who knew about it?
• What exactly was changed? And what was not changed?
• When was the change made (especially relative to other activities)?
• Where was the change made (e.g. what platform, repository, location)?
• Why was the change made? What triggered the change or motivated the person?
• How was the change made? What precisely was done and not done? How was information about the change captured and communicated?
  

Y especialmente: The Trouble with Tracing: Traceability Dissected: Una buena descripción de su valor y aspectos negativos

Eight Reasons for Traceability

If traceability is so much work, and if the return-on-investment is so hard for so many to see, then why do we bother? Or rather, why should we bother? Other than obvious contractual obligation, legal liability, or the fact that various CM and software engineering tomes declare “thou shalt have traceability,” what real needs does it serve? What does it let me do that I couldn’t otherwise do very easily? Several reasons commonly given are:

1. Validate we built what the customer actually agreed to pay us to build, that we built the “right thing” and that we “did things right” when building it
2. Verify that we delivered every file and feature/fix that we said we would, and nothing that we said we wouldn’t
3. Identify and isolate a set of changes that were made, and be able to either back-out the change from an existing version, and/or reintroduce the change to other versions
4. Assess the impact upon the design, code, tests and other aspects of the system for a proposed change-request (this in turn helps us determine effort, risk, cost, and the other affected groups)
5. Maintain an audit trail about who did what, when, where, why and how - so we can prove what we should and shouldn’t be held accountable for when the customer, or management or some other formal authority demands to know, or claims that we didn’t something we shouldn’t have, or for invalid reasons
6. Capture everything necessary to identify exactly what was delivered and repeat the steps necessary to reproduce it again
7. Report status of our activities to the customer and to management for the features and fixes that we are currently working on, so they can evaluate the progress and risks in delivering the project
8. Retrace our steps regarding something we did poorly, or that we simply didn’t know to pay attention to before, so we can identify root causes and learn how to prevent and/or correct it in the future

Those are all some pretty good reasons. Does that really justify why some of us have to maintain a traceability matrix? Is that really the most effective way?

Even agile development is in favor of tracing tests to features, which is extremely straightforward when one is doing test-driven development (TDD). When it comes to tracing requirements through to design and code, images of manually maintained traceability matrices that are hopelessly effort-intensive and never quite up-to-date seem to spring to mind.

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...

Más sobre Aldon

IT Jungle publica un reportaje a David McGovern, de Marlin Equity, donde responde a preguntas sobre la empresa (Marlin) y sobre los planes acerca de Aldon. Si Aldon es buen negocio y da dividendos, progresará...

Marlin is interested in acquiring mature businesses that we think have strong management teams and are in consolidating industries. We look at businesses where revenues are driven either by having a mission-critical product or system, or brand power, or another defensible position. Despite the technology background that I have and the deals that we have done to date, we are focusing on three verticals. Technology will be the broadest and probably the most frequent area, but we are about to sign up a consumer deal and we are also focusing on healthcare businesses. Generally speaking, we are industry agnostic, so long as the company meets a certain profile for us.
(...) We expect to build out with Aldon in a very similar way that we have built out in ERP software. We feel very strongly that the iSeries portion of the market is not going anywhere any time soon[1], and more particularly around the product set, Aldon has a very dominant or strong position within the iSeries, and they also have products that surround that, which positions the company well for growth and which are not just geared for iSeries customers only. There's a lot of opportunity to sell into Unix, Linux, and Windows environments where the customer might be iSeries-centric, but also operates these other environments. There is also a large installed base of iSeries customers where you can upsell additional products.

[1] Luego corrije: lo que quiso decir:

[Timothy Prickett Morgan, el autor del reportaje]: That has been my experience too at IT Jungle. But can I give Marlin some advice? Can we not say that the System i or iSeries market is not going anywhere? There are obviously two different connotations to that phrase. . . . and this is how my kids are going to get to college.

David McGovern: We certainly agree that the iSeries market is not going away. We think that the iSeries market is going somewhere.

Aldon adquirida por Marlin Equity Partners

Aldon, uno de los tres o cuatro líderes en la oferta de herramientas de administración de cambios, configuración y versionamiento en el mercado de ISeries (AKA AS400), anunció en estos días su adquisición por una sociedad dedicada a las inversiones (Marlin Equity Partners) como parte de un paquete de compras más o menos orientadas a fortalecerse en el mercado de ERP´s: CMS y XKO.
Un adecuado comentario sobre la operación en System INetworks:
Chris Maxcer dice sobre este tipo de adquisiciones:

There are two common ways that private equity firms look to make a profit when they purchase software companies:

1. They buy a company, remove much of the staff, reduce operational costs by slashing marketing and sales, and end up with a product or maintenance revenue stream that is suddenly highly profitable — for a short period of time, at least, before the company's dwindling assets get split, sold, or fall off the face of the earth. Sometimes, when this happens, the company puts on a joyous face of rapture over the acquisition as a way to hide the impending destruction realignment.
2. They buy a company, sometimes beleaguered and sometimes not, and start growing it by pumping in investment dollars in the form of product enhancements, additional acquisitions to supplement existing products, or go-to-market teams. Sometimes they, too, make layoffs and eliminate inefficiencies, but most definitely it's with an eye toward a bigger future that will eventually take the new company public or lead it to a new sale that returns the invested amounts, along with a tidy profit, in a 3-to-5-year time frame.

Aldon, a leading software change-management System i-focused vendor, is most definitely the second.

But How Do You Know?

Initial acquisitions, under both common formats, often appear the same to the outside world, but in the first method noted above, the company simply can't keep up the charade for more than a few months. They say they are interested in growth, but there's no evidence of growth — no acquisitions, no real or compelling product enhancements, and certainly no new products.

In the second, the company buys other companies, enhances products, pours development into new products, works out better go-to-market strategies, and hires new talent. In addition, the company stays in touch with the relevant media outlets in its market and is eager to talk about its new efforts, the results, and to share its excitement for the both the market and what the company is up to.

Qué perspectivas? Sólo en base a los proyectos previos a la adquisición:

"We've been the largest provider of change-management systems in the System i marketplace, and what we want to do is provide our System i customers with more things as they are moving into new technology areas," Magid says[Dan Magid, ex CEO, que se mantiene como consultor dentro de la nueva sociedad]. "The marketplace for the traditional System i management is pretty mature, but the marketplace for the things they are doing around their System i applications, building web interfaces and web applications around their iSeries code or building Windows interfaces or putting services that talk to their traditional iSeries applications . . . that is changing and moving forward very rapidly. We want to be able to provide our customers with solutions in that kind of arena."
Specifically, Aldon is looking into potential testing tools, business process automation tools that help companies work through the business process changes that coincide with new software application rollouts, build process tools for the open source environment, and tools that manage non-DB2 database changes.
"Our strategy is to be like an ERP system for the IT application development and management organization," Magid says.

En años pasados, MKS y Softlanding pasaron también por procesos de adquisición que sin duda lo potenciaron en el primer caso (desde su orígen en Silvon) y lo mantuvieron en el segundo. Probablemente suceda lo mismo en este.

Manejo de Configuración e ISO9001

Sigo ordenando notas antiguas: este artículo fue publicado también en Methods & Tools, en su número Summer 1999. Escrito por Robert Bamford y William J. Deibler II, de SSQC, compara los puntos de vista sobre Manejo de Configuración del software (CM) de IEEE (Institute of Electrical and Electronics Engineers), ISO (International Organisation for Standardisation), y SEI(Software Engineering Institute). Partes 1, 2 y 3. Buen artículo y excelente bibliografía.

Una guía para el testeo de paneles

Limpiando notas antiguas, encuentro mucha información de interés que pasaré aquí para no perder (y a del.icio.us). En Methods & Tools, destaco un artículo sobre testeo de GUI's(1) , (2) y (3)(año 2000), así como el autor, Barry Dorgan, que deja disponibles otros artículos en su página. Dorgan integra el grupo Software.Testing (1) y (2).
Lateralmente, de la información de Software.Testing, dos o tres sitios vinculados a testeo de software para agendar, especialmente TestingFaqs, y Software Configuration Management FAQ de Dave Eaton.

Manejo de Configuración desde el punto de vista de CMMI

Eric Mariacher publica un pequeño trabajo sobre el manejo de configuración y administración de cambios, en el contexto de CMMI. Es decir, de cómo la actividad del manejo de configuración y administración de cambios son fundamentos para un proyecto de mejora y sistematización de los procesos de construcción de software.
El papel fue presentado en CM Crossroads, el sitio dedicado al estudio de este tema, en el foro abierto para la construcción de un cuerpo de conocimientos en CM (CM Body of Knowledge, CMBoK). Luego de una larga demora técnica, el proyecto comienza a moverse. Puede revisarse el foro, y la wiki básica.

Control de cambios explicado por Jim Johnston

Johnston explica en dos artículos en CM/Crossroads, acompañado de gráficos y de algunos de los papeles de registro, distintos escenarios de control de cambios y configuración, útiles para armar un camino de control de cambios para quien lo necesite. Parte I; Parte II

Serena Software cambia de manos

Serena Software, uno de los participantes fuertes en el software de administración de cambios, cambia de manos, pasando todo su paquete accionario a Silver Lake Partners.

"Our decision to partner with Silver Lake to take the company private represents the culmination of a thorough review of our standalone plan and strategic alternatives and we believe this is the best value proposition for our shareholders", dice su jefe ejecutivo, Mark Woodward.

Parecería ser la renuncia a proseguir en el proyecto independiente. Se simplifica el campo?

Las herramientas de configuración y el ciclo de vida del software

La administración de cambios: Lo que inicialmente tuvo un alcance limitado al manejo del código fuente, con un ciclo corto de administración entre un repositorio de código y los objetos en producción, evoluciona y se ajusta más cada año a principios industriales (ingeniería de software) para la construcción de software. El artículo de Michel Sayko enlazado en el título de la nota quizá no diga algo muy nuevo, pero tiene la virtud de exponer en cierto modo el estado actual del manejo de la configuración del software (SCM), al presentar la disciplina como una parte central del manejo del ciclo de vida, y destacar la capacidad de definir procesos de trabajo a través de los cuales se aplique el control de cambios. En sus palabras:

Early configuration management tools provided version control for source code files. By versioning source code files, changes made by one developer to one file could be preserved. Other developers could take these versions, modify them, and create new versions. The ability to version files became a prerequisite for team development. Over time, SCM tools offered integrated defect tracking since testing during the software development lifecycle identified bugs that needed to be fixed. Next came workflow automation. Tool vendors added process models and workflow engines to their SCM tools so that an organization could model and execute its software development process. Process items could model the activities that are at the core of software development lifecycle, such as gathering requirements, specifying features and functionality, designing, coding, and testing. A workflow engine could move each process item though a sequence of states as the activity modeled by the process item progressed. Over time, process modeling capabilities in the tools evolved. Today, SCM tools can model complex development processes. SCM tool users have come to expect flexible and extensible process models that can be adapted easily as an organization’s processes change. In addition, SCM tools users now look for an integration between requirements management and core SCM features. The need to ensure that a software system satisfies an evolving set of requirements is what drives this integration. Customer expectations and government regulations now make traceability from requirements to source code files a requirement for the software development lifecycle.

Popkin pasa a ser parte de Telelogic

Continuando la concentración mundial de empresas dedicadas al software, ahora le tocó el turno a Popkin, la compañia que desarrolló System Architect. ¿De qué manera verlo? Desde un punto de vista positivo, implica el reconocimiento y nuevas oportunidades al diseño basado en modelos, en manos de Telelogic, una empresa dedicada a la integración de aplicaciones (EAI). Desde otro punto de vista, es otro esfuerzo basado en el entusiasmo y el convencimiento que es absorbido.
...Algunos días después...(30 de mayo)
El comentario de www.methodsandtools.com supone que Popkin alcanzó un socio...

Telelogic in Acquisition Mood The Swedish company Telelogic has announced the acquisition of Popkin Software, the US based editor of System Architect for $ 45 million in cash. Popkin's revenues for 2004 were $ 19.1 million and it had currently 108 employees. Telelogic has also launched a bid to buy Focal Software. With 26 employees, Focal Software develops and sells web-based solutions for decision support in product development and project portfolio analysis. Founded in 1983, Telelogic has currently more than 750 employees. Its main products are DOOR, a tool for requirements management, TAU dedicated to design, implementation & tests and SYNERGY for configuration management. With these acquisitions, Telelogic completes its product portfolio and expand its market opportunities. In this relatively good year for software development tools vendors, you can expect other acquisitions or mergers. In this case, Jan Popkin has found for his company a partner that will allow him to develop its product.

Thoughts on Software

Thoughts on Software
...De Shayne Wissler, quien también ofrece una herramienta de administración de cambios en Ouray Sofware. Uso libre a cambio de información de testeo.

Los amantes del código bien temperado

Hace poco, buscando otros asuntos, me dí con una discusión acerca del uso de "Obsydian", en la que alguien quería conocer experiencias de su uso, y alguien (no me interesa mencionar otros datos, porque no es el caso la persona) envió la siguiente contestación:

Personalmente no he trabajado con obsydian. Fui contratado para desarrollar y mejorar unas aplicaciones. Estas estaban desarrolladas con Obsydian. Realmente las hice de nuevo ya que la cantidad de códigos que mete la herramienta, es imposible hacer mantenimiento si no utilizas la herramienta. Como cualquier herramienta para programar (la que utilice genera código rpg) debe tener la mayor cantidad de posibilidades o rutinas para que estas sean efectivas, lastimosamente al desarrollar o crear el programa introduce todas estas rutinas aunque no se utilicen en programa desarrollado. Los programadores de otra instalación que desarrollan con obsydian me dijeron que era fácil de utilizar y rápido para crear programas. Me di cuenta que no eran programadores con experiencia en RPG y los rete a que ellos utilizando obsydian y yo programando en la manera tradicional quien terminaban primero, no aceptaron el reto. En una tercera instalación fui contratado (soy programador independiente) para desarrollar unos programas para mantenimiento de unas bases de datos, las cuales habían sido desarrollados con Obsydian, la verdad no se por que no utilizaron la herramienta para los programas de mantenimento. En el desarrollo de los programas se necesito cambiar las bases de datos. Yo propuse cambiar las bases de la manera tradicional, directamente en las DDS en el PDM, por alguna razón el analista no quiso y utilizo la herramienta para el cambio de las bases de datos, la verdad es que fue muy bonito la cantidad de pantalla y pantallitas de windows que se abrieron para cambiar y introducir un campo nuevo en la base de datos, y creo que mi hijo que no sabe programar para el As400 con esta herramienta la habría hecho, yo le dije que yo habría hecho el cambio en menos tiempo, mucho menos, pero bueno el era que el mandaba.
Conclusión si eres buen programador y tratas de crear un estándar en la programación, lo documentas bien, puedes reciclar estos códigos una y otra vez no necesitas una herramienta. Las personas que han corregido en alguna ocasión mis programas me han dicho lo fácil que resulta dar mantenimientos a estos, ya que cuando has visto uno se puede decir que ya los vistes todos. Las herramientas son buenas si quieres contratar gente sin experiencia y que vienen del mundo de ventanas.

Encuentro en esta contestación dos motivos fundamentales. Uno, la inconsistencia en la adopción de una herramienta por parte de la empresa usuaria. Otro, el punto de vista del programador. Sin embargo, quizá ambos confluyan a una idea compartida: Una herramienta "generadora de código" no es confiable, y un programador lo puede hacer mejor. En definitiva, ¿cómo es posible que una empresa que usa una herramienta de cuarta generación, la reemplace por un trabajo manual, o por decirlo de la misma forma, de tercera generación? Aunque sin duda se pueden alegar defectos del producto, creo que es la escasa adhesion al concepto, lo que produce la actitud del propietario de la herramienta.
Este es un punto de vista recurrente con el que tropecé en muchas ocasiones, que trabó antes y ahora muchos intentos de racionalizar la construcción de software, y no sólo en este terreno, sino también en otros: herramientas para la administración de cambios y uso del diseño visual (uso de diagramas). En resumen, la idea básica es que en la construcción de software lo más importante es el trabajo personal, y que programar es un arte que no debe ser cedido a procedimientos automatizados.
En el pasado, he trabajado con colegas que desconfiaban del producto generado, y revisaban el código resultante, y lógicamente, lo criticaban tal como lo hace quien escribe arriba. Lo que aquí se pierde es el bosque, por destacar al árbol.
Lo que el programador que escribe no observa, es la diferencia en productividad y consistencia:
No advierte que no se trata de comparar un programa, sino el conjunto entero de aplicaciones que compondrían el patrimonio de la empresa en que estaba: Su proposición implica que cada programador escribirá su programa, siguiendo estándares tan durables como lo fue la adhesion a la herramienta 4GL de la que habla: un año después de que el programador freelance desarrollara sus programas con el estándar A, llegará el freelance siguiente, que impondrá el estándar B, y criticará al 4GL, y al A. Como bien se vió durante la crisis del año 2000, al cabo de 5 años de desarrollos, un gran número de programas ya no son reconocibles, llegando al extremo de que algunos objetos se ejecutan sin código fuente.
Como bien dice, "es imposible hacer mantenimiento si no utilizas la herramienta". De eso se trata justamente.
El programador desafía al equipo que usa el 4GL a una competencia. Seguramente les ganará en un programa y un DDS (definición de una estructura de datos RPG), porque en el 4GL, Obsydian en este caso, se definirán elementos "superfluos", y ello mediante el uso del IDE del producto. (Ah, qué tiempos aquellos en que escribíamos en la línea de comandos de la consola!). Lo que debiera el equipo desafiado, es proponerle competir en un proceso completo, durante un año. Allí veríamos la diferencia que existe entre un programador que modifica directamente un DDS, y otro que construye un repositorio integrado. La diferencia la veremos cuando haya que producir una modificación que impacte sobre 50 programas y 30 DDSs, o cuando deba agregar un nuevo proceso, y cambiar cinco tipos de datos.
El programador se burla del analista que se niega a cambiar directamente el DDS, y de las "pantallitas" que se usaron para cambiar un tipo de datos, como lo hace del equipo que utiliza un 4GL. Lo lamentable es que proliferen (y no sólo en el RPG, sino en cualquier ambiente), los desarrolladores que piensan de esta forma, y desacreditan a quienes se esfuerzan por construír con "esas tonterías" donde no se puede hacer un algoritmo elegante.
Pero aún más lamentable, es que una empresa que adquiere un producto de esta clase, no mantenga el estándar, y deje a medio camino la inversión volviendo atrás, al recurrir a programadores que interfieren el código desde fuera, como lo indica el caso comentado. O cuyos usuarios no están convencidos del valor de lo que están haciendo.
Existe un promedio de desarrolladores convencidos de que lo fundamental es escribir código, y ven a los 4GL con hostilidad, y su peso, sumado a las partes no interesadas en el predominio de herramientas CASE, hacen que el uso de estas herramientas sea mucho menor que lo que se pudiera recomendar.

Administración de Configuración y MDA

Charles Betz (Alphas0ng), en ERP for IT, febrero de 2004, se ocupa del manejo de la configuración del software, extendiendo su significado al seguimiento de todos los ítems constituyentes de un desarrollo dado. Puntualiza así el límite de muchas herramientas de control de cambios, enfocadas sólo en el código fuente, y eventualmente (agrego) en los objetos generados, y algunos artefactos relacionados (scripts, documentos del diseño y la implementación). El control de configuración debiera aplicarse sobre todo el ciclo de vida, idealmente por medio de la misma herramienta, y sobre el conjunto de los componentes del desarrollo. Cómo identificar un ítem y sus dependencias?. Alphasong apunta a los principios de MDA para la solución de este seguimiento. En sus palabras:

The point of using the OMG’s modeling standards are that they are languages with a precise representation, not merely diagramming standards. The standard XML format for OMG models is called XML Metadata Interchange, or XMI.
(...)

We have everything here we need to feed a configuration management system: objects with names and unique IDs, and a precise representation of their interconnections. Connections between servers and switches can be represented, between components and databases, and virtually anything else imaginable in the modern IT infrastructure. A competent XSLT programmer could convert this structure into whatever format a CMDB required; far preferable would be a CMDB that accepted this industry standard directly.

El autor denomina a esta visión Model Driven Configuration Management. Luego de leer su punto de vista, encontré esta discusión en los archivos de OMG, que me llevó a conocer el proyecto europeo Combine, destinado a conducir el desarrollo de componentes por medio de herramientas MDA. Cuál será su estado actual?