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.

El modelo asincrónico: un artículo en Developer.com

Durante décadas el modelo generalizado y frecuente de construír software fue sincrónico: pudiera ser distribuído, pero en cierto modo todo actuaba como si un supremo director condujera armoniosamente todos los hilos. Qué lo cuestionó primero, es asunto de revisión de fechas. Pero dos elementos ofrecieron otras posibilidades: las colas de datos (o mensajes), y los componentes distribuídos abiertos, especialmente lo que CORBA inició. Hoy SOA es un elemento a punto de integrarse a nuestro trabajo por largo tiempo. Aquí hay una hojeada a características y problemas de nueva generación.

La evolución tecnológica está basada en criterios científicos?

Mr X (no puedo averiguar ahora quién es) escribe en el artículo que se puede enlazar desde el título de este comentario, ideas que seguramente alguna vez también se le ocurrieron: ¿hay que estar siempre en la última ola?. Cuántas veces la aparición de un nuevo concepto se debe simplemente a la necesidad de una compañía de salir a competir y tomar control de un segmento de mercado? Cuántas veces nos hemos visto obligados a adoptar una tecnología determinada simplemente porque devino la única disponible? Cuántas veces, por el lado contrario, una idea brillante quedó en un cajón porque una compañía mayor la compró y envió a vía muerta? Cuántas buenas ideas no son compradas?
Mr X apunta a OO en su crítica, dedicándole un artículo en particular, pero el criterio es ampliamente aplicable. No estamos ante un proceso de evolución racional, científica, sino ante un proceso de evolución darwinista, en el que la calidad de una idea es solo parte del asunto, y otra parte no menor es el tamaño del capital que respalde un concepto. Escrito en 2001, el contenido es aún más aplicable hoy, en que la aguda concentración del mercado de IT lleva a una situación en que la tecnología es casi totalmente empresa-dependiente. Por ejemplo, qué hace tan distinto al concepto de Software Factory, que no le permita actuar en común con MDA?...o más aún,
serían tan ácidas las críticas de Greenfield, Short y otros, en un escenario distinto?
En palabras de Mr X:

Some may suggest that the chaotic fluctuations are necessary for progress. Since the merit of ideas cannot be readily quantifiable, the only remaining choices are stagnation or trial-and-error to find the better products or technologies. Given that stagnation is not the way of America, the remaining choice is trial-and-error.

I don't fully agree with that. In my opinion, the merit of new concepts, languages, and paradigms should be required to be exposed to tough and open scrutiny before it could be heavily promoted as an improvement. Of course, this cannot easily be enacted into law.

Thus, the only solution may be education about the hype process. If people realized that they are being bamboozled to forever ride the tech-hype treadmill, then people may be less likely to be suckered in. I should point out that it is not any evil plot by one group, just a side-effect of active capitalism. Rather than throw the baby out with the bath water, let's clean up the bath water a bit.

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.

Las raíces de la Orientación a Objetos

H.S. Lahman dedica en su Weblog, algunos interesantes párrafos a las raíces que condujeron a la visión Orientada a Objetos, y a las etapas de evolución de la construcción del software. No es la primera vez que menciono a Lahman, uno de los constructores de MDA, pero sólo ahora caigo en la cuenta de que es un verdadero pionero (primera aplicación en 1957!). Por lo tanto, participante de toda la evolución del desarrollo de software, y voz competente para hacer una mirada de valoración. Lahman destaca las ventajas, y lo revolucionario que resultó, la aparición del paradigma de análisis, diseño y programación estructurada:

The first systemmatic attempt to eliminate hackers appeared in the form of Structured Programming that provided a collection of good practices for writing 3GL code. That was quickly followed by Structured Design and Structured Analysis, both of which introduced more abstract graphical representations of programs. The dominant design technique became top-down functional decomposition where the solution was started with a very simple and general statement of the problem solution and then one successively decomposed that solution into more detailed levels. Each statement of functionality was collected as a node in an inverted "tree" whose lowest leaves were logically indivisible.

The impact of SA/SD/SP was enormous. Defect rates dropped from 150/KLOC to 5/KLOC. In addition, productivity for large projects where multiple programmers had to coordiante efforts improved greatly. Instead of 1000 programmers working for 10 years to produce 1 MLOC, 200 programmers could do the same job in 2-5 years

Lahman describe a la vez cuáles fueron los puntos débiles del diseño estructurado, indicando especialmente dos, vinculados al mantenimiento del código estructurado: la modificación de variables de estado en puntos no determinados del código, y las dependencias jerárquicas:

There were a lot of problems that led to the Maintainability Gap but they could be broadly categorized as having two root causes: uncontrolled access to state variables and hierarchical implementation dependencies. State variable access was primarily a defect problem as data was modified in unexpected ways at unexpected times during execution. That resulted in additional test and repair cycle time when one modified existing code because it was difficult to predict how changes would affect untouched code that happened to access the same data.

Hierarchical implementation dependencies resulted in the legnedary "spaghetti code". That was because the leaf nodes in the functional decpomposition tree were at a very fine level of abstraction -- essentially arithmetic or logical operators in the 3GL. It was simply too tedious to cobble together lengthy sequences of such atomic operations to do complex tasks. However, the higher-level nodes in the functional decomposition tree quite conveniently captured such sequences as descendants. Since this nodes were systemmatically derived they had defined functional semantics. That allowed them to be reused (i.e., accessed by "clients" in different parts of the application that happened to need the same sequence of leaf oeprations).

That sort of reuse through accessing higher-level functions was a boon to developers and led to the notion of "procedural development" because it made excellent use of the core characteristic of 3GLs, block structuring around procedures. The problem, though, was that the functional decomposition "tree" now became a lattice where each node potentially had multiple ancestors (clients) as well as multiple descendants. It was that fanout of dependency that led to spaghetti code.

The dependencies existed because in top-down functional decomposition the lower-level functions are extensions of their parent higher-level function. That is, the specification of the higher-level function included the specifcation of the lower-level functions. Thus any contract between the client and the higher-level function dependend upon the specification of the entire descedant tree of functions. So if one changed the specification of a lower-level function, the specification of all of its higher-level ancestors was also changed.

That was no problem so long as the access structure was a pure tree. That's because the change was probably triggered by a need to change the specification of a higher-level function and implementing the fix in the lower-level function was simply the easiest place to do it. However, when one has a lattice, the higher-level functions have multiple clients. If only one client wants the change, the other clients may be broken by the change. Worse, there can be a client at any level of ancestry in the tree, so the change may break clients that are not even direct clients of the original higher-level function. The result was a disaster for maintainability because every change for one client could potentially break a host of other clients. Fixing things to keep all clients happy often resulted in major surgery to the tree or very complex parameterization that complicated the functions.

Podríamos decir que aún hoy estas observaciones son ampliamente verificables, sin hablar de que (lo puedo decir por Argentina y Chile) podemos encontrar con cierta frecuencia sistemas construídos bajo éste paradigma, o documentados con el método. Si me extendiera un poco más, encontraría que existen centros de estudio que aún lo enseñan como método a aplicar...

Veintiseis años con nosotros

Veintiseis años con nosotros. Casi toda una vida. Casi todos nuestros recuerdos, y el estímulo del pensamiento. Le debo su visión del matrimonio, y todos los argentinos le debemos dos guerras menos. No está su presencia por primera vez, y ahora me resulta difícil escuchar su voz grabada.

Luc Alex Florent Gabi, Ndje: Patrones de Diseño y Componentes

Buscando materiales de Componentes y Patrones de Diseño, encontré el sitio de Ndje...Un colega camerunés con referencias a ambos temas, y mucho más. Es un descubrimiento, que tendré que ir investigando en las próximas semanas. En el tema de componentes, le pasa lo que que sucede con Cetus: curiosamente, Componentes, una arquitectura que fue el tema de discusión obligado hasta hace no más de tres o cuatro años atrás, desarrolló una nube de papeles describiendo sus virtudes por parte de los mayores competidores del mercado, pero hoy, no menos de la mitad de ellos son inhallables. Incluso, algunas de las empresas que los sustentaron. Otras empresas de pronto mudaron su arquitectura, y en muchos casos hoy sostienen J2EE o Servicios Web, lo que en definitiva es una continuidad lógica de los componentes. Bien, el asunto es que a Ndje le pasa lo que a Cetus: la mitad de los enlaces a documentos que pudieran ser de sumo interés, ya no apuntan a donde se espera. Si se tiene paciencia, muchos de esos papeles se pueden encontrar todavía, recurriendo a los Archivos del sitio.
Sin embargo, no deje de visitar Componentes, Patrones (con un manual de OOD incluído) , y Lenguajes

SOA y MDA

Si le interesa SOA (Service Oriented Architecture), puede encontrar algunas presentaciones de interés en la Conferencia de IDC UK 2005. Particularmente, una presentación estudiando cómo MDA puede servir en un entorno de arquitectura de servicios. (Tomado originalmente del grupo Soa en Yahoo ).

OO: el desafío de "Muchos a Muchos"

Costin Cozianu trae a discusión un desafío del SQL y las bases de datos relacionales hecho al mundo de Orientación a Objetos: resolver en forma sintética algunas acciones sobre una relacion de muchos a muchos (en el ejemplo, usuarios asociados a grupos -un usuario en más de un grupo-). El enlace al problema en el título de esta nota.
El desafío:

• Model the relationship between Users and Groups (many to many)
• For all domain objects (Users and Groups), handle:
  • creation of new objects
  • updating of existing objects
  • deleting of existing objects (including cascading: if a group is deleted, any relationships are invalidated)
• Querying for a set of objects which match a simple but arbitrary condition
• Creating a relationship between any two instances
• Removing a relationship between any two instances (including deletion as a result of deleting a member of the relationship)
• Navigating the relationship both ways in better than linear time
• If solution is not SQL, supply the entire implementation.
• Make it thread safe and deadlock safe (this is functionality provided out of the box by SQL DBMSes).

El objetivo: "demostrar que SQL mantiene funcionalidad que no está rápidamente disponible, ni trivialmente implementable" en ambientes OO:

The challenge was intended to demonstrate that SQL has useful functionality that is not readily available, nor trivially implementable in OO environments. This is in contrast to claims of OO developers (DbasGoneBad, PrevalenceLayer, etc) that if we could only get SQL databases out of the picture then we'd have all milk and honey. Since many books on OO talk quite a lot and quite without substance about OO "relationships" (aggregation, composition, ownership, directionality, etc), and since I know from experience that managing OO relationships is a frequent source of bugs in OO programs, I put this challenge with the intent to make some OoWeenie?s out there painfully aware of the limitations of their own tools. In particular this page debunks a pervasive misconception (see quotes in ObjectRelationalPsychologicalMismatch) that RelationalModel is not as good at representing "relationships" as object models. Which claim should be judged ridiculous on the face of it, but it is amusing how many "important names" in the OO camp make it.

Java y C++, errores históricos?

El 3 de mayo de 1997, Bertrand Meyer escribió en un grupo Google:

Ten years ago or so, when object technology first captured the industry's attention, projects moved en masse to C++. This was not the right decision. Not that everything was bad with C++ (then it would not have attracted so many
people); it was simply not appropriate for serious software engineering. C++ was a transition technology, useful to make C developers and their managers object-aware, but not appropriate for the development of durable, high-quality software systems. Interestingly enough, this was clear to many people; virtually
every object-oriented expert would privately concede that C++ was an inadequate solution - but carefully refrain from saying so in public, for fear of appearing to go against the tide.
This is happening again with Java. Once again we have an approach that has some major contributions to make but is hyped as the solution to everything - and is not. (sigue...)

Con estas revulsivas ideas se inició una discusión valiosa, con decenas y decenas de participantes, algunos de ellos fundamentales, como Bjarne Stroustrup o el mismo Bertrand Meyer con sólidos argumentos, que, cualquiera sea la posición de cada uno, sirve para aprender. Estamos en 2005, y la línea de discusión sigue: C++ y Java siguen en foco, sus puntos débiles son conocidos, y Eiffel también sigue en un segundo plano de adopción...
Si le interesa seguir la línea de discusión, o aportar su criterio...
http://groups-beta.google.com/group/comp.object/browse_frm/thread/2c6139ce13be9980/649217656063dab8

Un problema de arquitectura?

Un artículo de Builder.com (link en el título de esta nota), recoje la crítica de James Gosling, de Sun, sobre la decisión de Microsoft de soportar C y C++ en el esquema de ejecución de .NET . Gosling, "padre del lenguaje Java", dijo en Sydney en la primera semana de febrero, que esto crea un agujero de seguridad, y que éste es "one of the biggest and most offensive mistakes that they could have made", uno de los más ofensivos errores que hubieran podido cometer. ¿Por qué?:

(...) the security hole is based upon the fact that several features of the older languages are ambivalent with regards to security: "C++ allowed you to do arbitrary casting, arbitrary adding of images and pointers, and converting them back and forth between pointers in a very, very unstructured way.
(...) Gosling is concerned about "unsafe" code, which is produced by traditional languages like C and C++. Unsafe code is old code that does not strictly follow the rules of type safety that .NET defines, and this sort of code requires additional permissions to execute.
(...) An important point is that the so-called unsafe code does have the potential to run faster than "managed" code due to some languages' ability to include machine-specific features that may sacrifice platform portability for speed.

Charles Sterling, del lado de Microsoft, sostiene que .NET define distintas clases de código, dentro de las cuales el "código manejado" o "administrado", corre bajo el control de .NET y sus reglas de seguridad. Sterling reconoce que el código "inseguro" tiene la ventaja de estar adecuado a la plataforma, por lo que puede correr más rápido en una plataforma específica. Así, la decisión de usar código seguro o inseguro, es una decisión de cuánto riesgo se quiera aceptar:

the choice between the two platforms is all about risk: if developers are willing to "accept the risk" of unsafe code then they may gain access to "the best performance system on the planet."

Más sobre educación primaria: reportaje a Juan Carlos Tedesco

La Nación publica un reportaje a Juan Carlos Tedesco, especialista en educación, que refirma y describe en mayor detalle el empobrecimiento de la educación básica en Argentina, apuntando al desinterés de los dirigentes, y la importancia del soporte de la familia y la sociedad. Frente a la indolencia y la confianza en que "ya se solucionará", es importante su opinión sobre qué es tocar fondo:

-¿En América latina hay que tocar fondo para advertir que un área necesita ser fortalecida?

-Ojalá fuera así. A veces ni siquiera tocando fondo se ha hecho. Si no, no estaríamos donde estamos. Porque uno podría decir que aquí hemos tocado fondo varias veces. ¿Qué significa tocar fondo? Cuando volvió la democracia, después de tantos años de dictadura, desaparecidos, uno pensaba que habíamos tocado fondo. La experiencia demostró que no. Tuvimos que sufrir otra crisis profunda, la de 2001, igual que en otros países de América latina. Esto tiene que ver con el umbral de tolerancia que tenemos. Y nuestros umbrales de tolerancia han descendido mucho. Uno podría haber dicho hace muchos años que la Argentina no iba a tolerar un índice de desempleo mayor del siete por ciento.
Llegamos al 20 por ciento y se lo toleró. ¿Podemos tolerar tener el 50 por
ciento de la población por debajo de la línea de pobreza? ¿Cuál es el fondo?
América latina y la Argentina tienen que entender que tenemos que levantar mucho los umbrales. Hay que reaccionar antes de que sucedan estas cosas.

La educación básica es el futuro (hay que decirlo todavía?)

La revista América Economía , (número 293) trae en su portada un artículo sobre la educación básica en América Latina, con observaciones a un informe de la OCDE, que muestra muy pobres resultados de la enseñanza en general:

Los bochornos se sucedieron en diciembre cuando se publicaron los resultados de las dos pruebas internacionales más importantes de calidad educativa. El primero fue cuando la Organización para la Cooperación y Desarrollo Económico (OCDE) publicó los últimos resultados del Programme for Internacional Student Assessment. Conocido como el Pisa, el programa consiste en la aplicación de exámenes de conocimiento a entre 4.500 y 10.000 alumnos de 15 años de cada país participante. En total, 415.000 niños fueron evaluados por sus aptitudes en matemáticas, capacidad de lectura, ciencias y resolución de problemas. En su última versión, participaron los 30 países de la OCDE y 11 países voluntarios. México tomó parte como miembro de la alianza. Brasil y Uruguay, como voluntarios. El resultado no pudo haber sido peor para nuestros representantes regionales: los tres pelearon los peores lugares del ranking. Y en todas las variables estudiadas.

Es un déjà vu de lo sucedido con el Pisa 2000. Entonces, los cinco países latinoamericanos evaluados (Argentina, México, Chile, Brasil y Perú) se repartieron consecutivamente los últimos lugares, junto a Macedonia. En el informe presentado entonces por la OCDE, los países latinoamericanos destacaron por su mínima comprensión de lectura, alto nivel de repitencia y la enorme disparidad entre la capacidad de lectura de los estudiantes de familias pobres y con recursos. Los mismos puntos se destacan este año.
(...)
De la tendencia tampoco escapa Chile, el país de la región que ha puesto más esfuerzos para llevar a cabo una reforma educativa desde los 90. En diciembre se publicó el Estudio Internacional de Tendencias en Matemáticas y Ciencias 2003 (TIMSS, su sigla en inglés), otra prueba internacional que evalúa la calidad de enseñanza. Chile, el único país latinoamericano examinado, obtuvo magros resultados. No sólo alcanzó la posición 39 entre los 46 países participantes: lo preocupante es que el nivel de progreso fue mínimo frente a los resultados obtenidos en la versión anterior del TIMSS, de 1999.

Qué se afirma en el artículo:

• Aumenta la masa de estudiantes en nivel primario y medio en todo el continente, pero no aumentan los recursos dedicados, ni el nivel curricular.
• En las comparaciones mencionadas, los países que más avanzan, son los que tenían ya antes mejor nivel educativo, con lo que se ensancha la distancia entre los casos americanos y el resto.
• En muchos casos los estudiantes no entienden lo que leen, y se confunden con nociones básicas de matemáticas.
• Aumenta la diferencia de resultados entre alumnos de bajos recursos y de altos o medianos.
• La enseñanza está divorciada de los requerimientos de la vida real, en particular del trabajo y las empresas.
• En muchos casos, los recursos se orientan hacia la enseñanza privada, en lugar de ir a la pública (se menciona a Brasil), creando mayor diferencia entre la enseñanza pública y la privada.
• La desigualdad es aún mayor entre grupos raciales y étnicos.
• Los educadores se ven como empleados públicos, y adoptan los vicios de la burocracia.
• A los distritos pobres nadie quiere ir a trabajar, por lo que los alumnos quedan en manos de los menos experimentados o capacitados, por descarte.
• No es posible establecer un consenso de continuidad de un plan de mejora de la educación, y los planes cambian cada vez que los gobiernos cambian.

Una anécdota contada al inicio da la real dimensión del problema:

Un empresario de Rio Grande do Sul, Brasil, estaba a punto de estampar la firma que cambiaría de nivel su negocio de calderas. Había convencido a una empresa estadounidense para invertir dinero en su planta. No obstante, el inversionista extranjero le puso una condición inesperada: antes de poner un dólar, todos los empleados de la fábrica debían tener educación secundaria completa. El empresario gaúcho no sólo no lo podía creer. Tampoco lo podía cumplir: muchos de sus empleados tenían apenas entre cuatro y cinco años de escolaridad. Al ver cómo el negocio del año se escapaba de sus manos, no le quedó más que rendirse ante la evidencia: sin educación no hay competitividad.

Puedo enumerar decenas de síntomas avalando este diagnóstico, sólo acudiendo a la memoria de hechos de Argentina; otros podrán hablar de sus países: por ejemplo, las reformas educativas. Desde que recuerdo, Argentina va de reforma en reforma, al menos una por cada cambio "filosófico" de gobierno (la dictadura militar de Onganía, el gobierno peronista de 1973, la nueva dictadura posterior, el gobierno radical, y el nuevo gobierno peronista) cada uno su reforma educativa, en donde los maestros deben aprender un nuevo sistema de enseñanza, y los estudiantes en transición pasan de un sistema de aprendizaje al otro durante su ciclo en curso. Y, debiera decirse, cada vez, un sistema más degradado.
En fin, Latinoamérica no parece querer comprender el problema. Contrariamente a lo que podemos observar en los países asiáticos, que potenciaron su educación básica con el aval y respaldo de sus comunidades completas, ya sea la familia que sigue la educación de sus hijos, el Estado que actúa con continuidad a pesar de los cambios de administraciones, los maestros que son competentes, o las empresas que apoyan la capacitación.
Seguimos participando de comunidades disociadas, que, al anteponer el interés particular o de grupo al colectivo, están conduciéndose indolentemente hacia el mayor suicidio posible: la degradación social.

Global Tester: SQA, Metodos de manejo de la Calidad

Jeff Nyman sostiene Global Tester, un sitio dedicado al manejo de calidad en la construcción de software, con énfasis en el testeo. Qué dice sobre el concepto:

GlobalTester is a repository of open content information regarding subjects related to Quality Assurance, Quality Control, and Quality Testing. To state what GlobalTester is, it is helpful to consider its goals. One goal of GlobalTester is to provide a wide variety of information about various aspects of a quality initiative that can be used in a variety of organizations that act to bring a product to market, whether that product is hardware, software, Web sites, or anything else within the domain of the Information Technology (IT) industry. On a practical side, a goal of GlobalTester is to be two things simultaneously: (1) a diverse toolbox and repository of methodologies, methods, and practices for a robust quality initiative, and (2) a testing solution framework that emphasizes a broad view of testing to include non-exectuable and executable elements of a development lifecycle and that seeks to promote ways of thinking as well as ways of doing. Another goal of GlobalTester is to be as independent as possible of different management structures, specific tools and software, and staffing realities so as to present a large selection of topics that one can pick and choose from based on relevance and interest.

Qué dice sobre sí mismo Jeff:

Any time a site like this pops up it is logical and prudent to ask what makes the author of the site (and its contents) claim to be an expert in the field that they are talking about. In my case the answer is: absolutely nothing. In general, there is nowhere that I will claim to be an "expert", whatever that truly might be in the context of Quality Assurance. In fact, like everyone else in the industry, I am in a constant state of learning. Thus, even when I learn something there is always the corollary that tells me I have a lot more to learn. The only claim I will categorically make is that I am an individual that is committed to Quality Assurance in my professional life (and even my personal one to a large extent) and that I am committed to disseminating as much information as I can about Quality Assurance to the widest possible audience. I also make the claim that anything I present on this site has had the potential to save me a lot of time and effort at various organizations with which I have been employed. Perhaps more importantly, anything I present on this site has led to improvements in the overall quality efforts and initiatives of which I have been a part.

Adhiero a su punto de vista...( también puedo decir, "especialista en nada, e interesado en todo")

Un Blog de Arquitectura de Software

IASA (International Association of Sofware Architects) mantiene un blog más o menos institucional, que puede servir como enlace rápido a sus novedades. IASA es un reciente emprendimiento destinado a discutir conceptos de la arquitectura, de un modo abierto y no sujeto a posiciones tomadas. No dejar de visitarlo...
(El blog, enlazado en el título de esta nota, como en general sucede)

Un texto para mantener siempre a mano

Cómo ser un programador...Por si no lo conocía, debiera leerlo y tenerlo a mano. Un breve escrito, "How to be a programmer" desarrolla recomendaciones acerca de cómo escribir código, documentarlo, estimar tiempos, manejar un equipo y participar en él, testear, y , en general, las actividades diarias del trabajo de una persona y un equipo dedicados al desarrollo de código.
Robert Read, su autor, lo presenta así:

To be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible.
In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one. This is very subjective and, therefore, this essay is doomed to be personal and somewhat opinionated. I confine myself to problems that a programmer is very likely to have to face in her work. Many of these problems and their solutions are so general to the human condition that I will probably seem preachy. I hope in spite of this that this essay will be useful

DSDM: Un sitio excelente en castellano sobre MDA

Este no será un verano con vacaciones...Tengo una pila tan grande de asuntos pendientes, que lo convierten en la época del año de actividad más intensa. Así, pasé por alto un correo enviado por la lista del grupo de trabajo MDD-MDA donde anuncian la nueva página creada para soportar la iniciativa en nuestra lengua. Correo del 30 de noviembre del año pasado! Con la disculpa por el tiempo transcurrido, quiero recomendar la página como la mejor sistematización de materiales, investigadores, organizaciones y cualquier otra clase de recursos que ayuden a comprender y avanzar en el estándar del desarrollo de software dirigido por modelos. Como señalé en otra nota, quisiera destacar la fuerte presencia de las universidades españolas en el estudio de MDA, así como en servicios Web.

Otro enfoque sobre la construcción de Software

Programación orientada a Lenguajes (LOP), defendido por Sergey Dmitriev, de JetBrains, explica otro paradigma para construír software. Una concepción cercana a la propuesta por Charles Simonyi: Programación Intencional.
Dice Dmitriev:

The motivation behind LOP goes something like this: I want to be able to work in terms of the concepts and notions of the problem I am trying to solve, instead of being forced to translate my ideas into the notions that a general-purpose language is able to understand (e.g. classes, methods, loops, conditionals, etc.). To achieve this, I need to use domain-specific languages. How do I get them? I create them.

I have begun development of a universal platform (the Meta Programming System) for designing domain-specific languages along with their supporting tools and environments. It will allow programmers to define languages as easily as they can write programs today. The platform will fully support LOP, giving programmers the freedom to use the most suitable language for each part of their programs, rather than tying them down to one fixed general-purpose programming language.

For me, the most serious problem is that there is a very long gap between when I know exactly how to solve a problem and when I have successfully communicated this solution to the computer as a program. I can explain the problem and solution to another programmer in a matter of hours, but encoding this solution into the computer takes much longer. This is because with a programmer I can use natural language which is very rich, but for the computer, I must use a general-purpose programming language which is much less expressive. Programming languages today have only tens of notions that can be expressed. A natural language has tens of thousands of notions which can be expressed succinctly. So, to explain a program to another programmer, I can just express very high-level ideas, but for the computer, I must express every single step and every detail. In mainstream programming, most of the time spent ‘programming’ is really just finding ways to express natural language concepts in terms of programming level abstractions, which is difficult, not very creative, and more or less a waste of time.

Una definición rápida del concepto de programación orientada a lenguajes, en el papel de M.P.Ward:

The approach starts by developing a formally specied, domain-oriented, very high-level language which is designed to be well-suited to developing this kind of program. The development process then splits into two independent stages: (1) Implement the system using this middle level language, and (2) Implement a compiler or translator or interpreter for the language, using existing technology. The approach is claimed to have advantages for domain analysis, rapid prototyping, maintenance, portability, user-enhanceable systems, reuseof development work, while also providing high development productivity.

Una crítica a LOP, que entrega más visión de contexto, en el Blog de Chris Nelson. Apuntada por el mismo Dmitriev.

Software Factory versus MDA

En TheServerSide.net existe una discusión en curso de interés sobre el valor del estándar de Arquitectura conducida por Modelado (MDA). Sólo en varios días podré acotar opiniones sobre el conjunto de la discusión, particularmente en cuanto al "versus", la factoría. Por el momento, quisiera solamente remarcar algunos aspectos señalados por Jack Greenfield, como puntos débiles del estándar. Jack no avala en general MDA, aportando argumentos que en mi criterio no veo como opuestos. Prometo releer varias veces sus razones, hasta encontrar por qué algunos de sus puntos pudieran considerarse "contradictorios". Por ejemplo, Jack cuestiona la idea de independencia de la plataforma:

The primary stated goal of MDA is platform independence. While some insulation from platform technology changes is no doubt achievable, I do not believe it is feasible to produce secure, usable, reliable, performing and supportable software from specifications that take no platform dependencies of any kind into account

Sin embargo, esta afirmación parece ignorar la existencia de dos niveles de modelado, el Platform Independent Model (PIM), y el Platform Specific Model (PSM). Creo que es cuestión de tiempo el que un PSM pueda generar código suficientemente específico para una plataforma dada, como para satisfacer los reclamos de Greenfield acerca de la necesidad de especificar el código. Pero, por si lo leí mal, lo releeré diez veces en estos días...
De todas formas, más allá de estas críticas, que releeré, están sus observaciones, que podrían tomarse como una lista de tareas a realizar:
Relacionado con el ciclo de vida:

• MDA says nothing about how models should be integrated with requirements, architecture, frameworks, patterns, code, configuration files, and other key development artifacts in the context of a development process. Surely, the failures of CASE in the 80s and 90s should tell us that genuinely seamless integration between code and models is an absolute requirement for success in model driven development. Any methodology that claims to explain how models should be used to develop software must prescribe robust solutions at the critical interfaces between models and other mediums of specification and implementation.
• MDA says nothing about how models or metadata derived from models should be used to automate specific tasks across the software life cycle, such as debugging, testing, deployment, version control and configuration management, operations and maintenance. Surely, these activities are as important, if not more so, than generating implementations? To be effective, a model driven development methodology should describe a holistic approach to automating the rest of the software life cycle.

Sobre el UML:

According to the OMG's official definition of MDA, MDA is a way to develop applications in UML. (There are two other competing but unofficial definitions of MDA, as described in a blog posting by Steve Cook, one that advocates the use of MOF based languages, not UML, as the medium of model driven development, and one that advocates the use of UML as a first class programming language that is compiled directly into executables. Of the three definitions, the MOF based one is the closest to the approach that we have taken with software factories and DSLs.). This is a large topic that I will take up in subsequent blog postings, even though it is already covered at length in the book. The point, for those who can’t wait, is that as a methodology for developing software in UML, the effectiveness of MDA is limited to the effectiveness of the UML as a language for model driven development, a task it was not designed to support.

Este asunto continuará...

En dos palabras, una declaración de principios

A propósito de una pregunta circunstancial, Christopher Smith define, en poco más de dos párrafos, la razón por la que los generadores de código devendrán la forma predominante de construír software. Frente a la nube de desarrolladores y dirigentes de IT que prefieren la construcción de código basados en su escritura directa ("handcoding"), la diferencia la hace la productividad:

I'm a Plex true believer. I was on vacation last week and I ran into a guy that works for Red Hat as a kernel developer. We had a discussion about system vs. application programming. He was rather dismissive of code generators. This also seems to be true of most Java developers.

(the following applies to experienced Plex developers) If you can tolerate 10 times more time to develop your application, fewer features, less consistency, 10 times more bugs due to lazy coding and you just absolutely need the source code to do it your way, you can squeeze 5% to maybe 10% more efficiency out of your application. Big Fat Deal.

The learning curve is steep and long but the payoff is big.

You need fewer SMART developers. Most shops try to just have fewer CHEAP developers and never realize any benefits.

Dicho en EDGE, el foro de usuarios de Allfusion Plex.