Seguridad en aplicaciones web

Para completar las referencias a Read y Fogie, su artículo sobre la seguridad en aplicaciones web, en general. Constituye una guía concisa y básica de los problemas usuales que se deben resolver en una aplicación web, desde el punto de vista de la seguridad. Yendo un poco más lejos, es extensible a todo tipo de aplicaciones. En resúmen:

* ExpandUnexpected Input
* ExpandAdministrator Error
* ExpandAccount Control and Management
* Expand Ensuring Data Availability Compliance with WebWatchBot
* ExpandXSS Explored
* ExpandXSS Evolved
* ExpandLearning How to Burp – The Web Application Testing Proxy
* ExpandCode Injection Explained new

Inyección de código explicada

Jonathan Read y Seth Fogie, en Informit, dentro de su Security Resource Center, describen lo que es code injection:

Code injection is a way to place software code into a computer system or program by exploiting unchecked assumed inputs. When a program assumes only a certain input will occur and does not protect against different inputs being made, problems can occur. Code injection provides a way for hackers to gain access to data, modify data and corrupt code that they normally could not affect.

Cómo pueden pesar presupuestos y descuidos en el diseño:

Wikipedia has a great list of dangerous assumptions made by software developers. They are as follows:

• assuming that metacharacters for an API never occurs in an input
• assuming punctuation like quotation marks or semi-colons would never appear
• assuming only numeric characters will be entered as input
• assuming the input will never exceed a certain size
• assuming that numeric values are equal or less than upper bound
• assuming that numeric values are equal or greater than lower bound
• assuming that client supplied values set by server (such as hidden form fields or cookies), cannot be modified by client. This assumption ignores known attacks such as Cookie poisoning, in which values are set arbitrarily by malicious clients.
• assuming that it is okay to pick pointers or array indexes from input
• assuming an input would never provide false information about itself or related values, such as the size of a file (*).

Software developers need to be very aware that not everyone will use their software as intended. They also need to be aware that even accidental code injection can take place. Accidental code injection can occur when someone uses characters such as quotation marks and punctuation in their name. A user could accidentally corrupt a whole database without realizing it. Software that is vulnerable to accidental bugs like this should never be used. It could never withstand a deliberate attack by a proper hacker.

Remito al corto artículo y su ejemplo para el caso.

En el marco de mi uso de Plex, una de las razones de apoyarme en los patrones de Websydian para el diseño web, es que los patrones de despacho de solicitudes de páginas incluyen rigurosamente, entre otros aspectos de control de seguridad, el control de code injection, de una forma tan simple como lo es heredar de un patrón. Pero esto es materia de otra nota...

Bases de datos relacionales y diseño Orientado a Objetos

Como periódicamente sucede, el dos de noviembre comenzó otro debate sobre el mapeo de datos (persistencia) entre RDB y OO en Google Groups. Como siempre, a medida que se desarrollan, aumenta su interés
El planteo inicial es muy simple:

I am wanting to create an application that is for time management and I
want most of the data to be on my webservers database, but in creating
my OO 'client' I really want to create a good design.
(...) how do people go about designing and storing the data once it has been
retrieved from the database? Do you keep it as records, or when you get
the data, do you create collections of objects which represent the data
which you have obtained from your database?

Frans Bouma, defensor de Object Role Modeling (ORM):

It's IMHO always a good idea to start with a design for your abstract
datamodel. This is a level above E/R, so it can have inheritance etc.
For the technique, please check http://www.orm.net (Object Role
Modelling, formely known as NIAM)
This gives you a good idea which entities are identifyable within your system, their attributes and their relations with other entities. Once you've modelled this out, you can go in several directions: you can pick this model and turn it into a domain model (thus a class model) and simply get an o/r mapper of your liking and store the entities into a physical datamodel matching your domain model.
You can also pick it up and create a physical data model in a database with it and use it as well for your entity classes, which are then consumed by your application logic.

Lahman propone:

(...) when you know what object attributes need to be persisted, define a suitable Data Model for the database. The RDB Data Model and the solution's Class Model will typically be different for non-CRUD/USER applications because they need to be optimized differently.
Finally, provide a subsystem for the application that maps between the two views. The interface to the DB Access subsystem is defined by the time management solution's need to obtain and store data to initialize and save objects. The DB Access subsystem then maps those requests into SQL queries or whatever that are appropriate for the Data Model.
Typically, on the solution side one will have factory objects to instantiate the solution's objects. Those factory objects will request the appropriate data from the DB Access to do the instantiation and initialization. Conversely, when it is time to save attributes from the solution objects, some object extracts the relevant attribute values sends them off to the DB Access subsystem to be stored.

Lahman desarrolla más su planteo acotando una respuesta de Andy:

>>Solving a time management problem is a quite different subject matter
>>than persisting the relevant data. Solve the time management problem in
>>you application first. Then, when you know what object attributes need
>>to be persisted, define a suitable Data Model for the database. The RDB
>>Data Model and the solution's Class Model will typically be different
>>for non-CRUD/USER applications because they need to be optimized
>>differently.

> I agree with the solution, but I really think one is talking about a
> Persistant Storage Engine (PSE) rather than perhaps an OO database. A
> PSE can often be implemented using an object schema or RDB model.

That's fine. In fact, it is one of the advantages of the approach I proposed. It really doesn't matter to the time management problem solution whether the data is persisted in an RDB, an OODB, flat files, or clay tablets. The persistence mechanisms are fully encapsulated in the DB Access subsystem. So one could regard the DB Access subsystem I proposed as being a PSE from the perspective of the problem solution.
Among other things, that allows one to change one's mind about how the data is stored without having to touch the problem solution in any way. All one needs to do is replace the DB Access subsystem underneath the same subsystem interface.
Another advantage is reuse. Once one starts to abstract a DB Access subsystem for, say, the RDB paradigm, one quickly realizes that the abstractions are things like Schema, Table, Tuple, Query, etc. that are quite generic. So one can reuse the DB Access subsystem across applications with relatively little extra effort. (All one needs is an identity mapping between the problem solution and the RDB artifacts, which is easily described in configuration data for a particular application.) In fact, RAD IDEs are based upon exactly that sort of problem-independent reuse.
People tend to discount swapping paradigms as an advantage because RDBs have dominated for 2+ decades. However, I've personally watched the paradigm for persistence changing from paper tape/punched cards to flat sequential disk to ISAM to CODASYL to RDBs to OODBs (in at least some niches). Each shift required major surgery for huge amounts of legacy code because the persistence mechanisms were not encapsulated. And each paradigm shift was regarded as the last possible -- until some new technology appeared. So I wouldn't bet against another paradigm shift in the future just because RDBs have been around awhile.
I would also argue that modern RDB or OODB engines are not as portable as the vendors would have us believe. Each vendor has their own SQL extensions or whatever. And they each have their own unique quirks that need to be addressed in the way the data is accessed for optimal performance. So even when one just changes vendors within the RDB paradigm or the OODB paradigm, one may have to do some tweaking and that should be isolated from the problem solution code.

La discusión suele extenderse...Si la relación entre bases de datos relacionales y diseño orientado a objetos le afecta, es de interés agendarse el link.

Irlanda: atando cabos

Prosiguiendo con un comentario previo, tres lecturas recientes permiten ver más detalle sobre la transformación irlandesa.
En primer lugar, los puntos de vista de Juan Freire y otras personas que luego se suman a sus comentarios, en una referencia a Irlanda comparada con España (en particular, Galicia).
En segundo lugar, un congreso promovido por Universia e Intel en Dublín, en enero de este año (llamado "Transforming Spanish Universities for the Knowledge Society", en inglés).
Y finalmente, un artículo de Andrés Pedreño, también en Universia, que aporta cifras y puntualiza los principales resortes del crecimiento irlandés.

Freire comenta a Tom Friedman, que resume en educación, bajos impuestos, búsqueda de empresas globales, acuerdo interno, los resortes del cambio de Irlanda:
Thomas Friedman ha publicado un artículo en The New York Times, The End of the Rainbow, donde explica las causas del cambio radical que he llevado a Irlanda de ser un país pobre en 1960-70 (tras siglos de penurias) a ser el segundo país europeo en renta per cápita. El inicio del proceso está en la ayuda financiera de la UE, pero lo realmente relevante fue como se gastaron estos cuantiosos fondos. Ramón Sangüesa comenta el artículo en Reflexiones inseguras y pone de manifiesto como las claves del éxito irlandés contrastan con el caso español.

Friedman acaba su artículo con una receta simple:

• Make high school and college education free;
• make your corporate taxes low, simple and transparent;
• actively seek out global companies;
• open your economy to competition;
• speak English;
• keep your fiscal house in order;
• and build a consensus around the whole package with labor and management

then hang in there, because there will be bumps in the road - and you, too, can become one of the richest countries in Europe.

Freire compara el uso de los fondos europeos dado por Irlanda, con lo que hiciera Galicia, y por extensión, España:

Hace unos meses en Galicia se abrió un cierto debate en los medios de comunicación sobre el modelo irlandés y su comparación con el caso gallego. La pregunta era clara: Irlanda y Galicia son similares en tamaño y población (y hasta comparten una cierta leyenda de un origen celta :-), las dos han recibido grandes ayudas económicas de la UE durante décadas y ... los resultados han sido radicalmente distintos. Irlanda se ha convertido en la vanguardia de Europa mientras Galicia sigue en el furgón de cola (y sólo remonta algo su renta per cápita por razones demográficas).
El debate, desde mi punto de vista, fue estéril. Todos los comentarios parecían coincidir en que si Irlanda lo consiguió, Galicia podía hacer lo mismo. Mi opinión es totalmente contraria. Lo que hizo Irlanda lo sintetiza Friedman. ¿Ha hecho Galicia alguna de esas tareas? No.
En nuestro caso, las inversiones se han dirigido básicamente a crear infraestructuras y subsidiar sectores poco innovadores y con escaso futuro. Como ejemplo, mientras en Irlanda las infraestructuras internas siguen siendo muy escasas (viajar de Dublín a la costa oeste es aún hoy en día toda una aventura), sus conexiones con el resto del mundo son muy buenas (lo que les permite desarrollar redes logísticas eficientes y facilitar los flujos internacionales de trabajadores cualificados). En Galicia, tenemos extraordinarias carreteras, autovías y autopistas interiores que conectan sitios con escasa actividad económica (que no precisan de ese despliegue, por muy cómodo que nos resulte), pero sigue siendo una aventura el transporte al resto de España (excepto quizás a Madrid, desde hace poco tiempo) y a destinos internacionales. Y eso en las infreaestructuras (la clásica obsesión española), no hablemos ya de educación, impuestos, transparencia, competencia, etc.

En los comentarios a la nota de Freire, se destacan dos puntos: impuestos y acuerdo laboral:

(...) La clave está en la reforma de los impuestos y los salarios que hicieron los irlandeses a partir de finales de los ochenta. De forma negociada con los sindicatos y los empresarios se consiguió bajar los impuestos y los salarios, y aumentar la inversión privada. Desde entonces han seguido haciendo reformas en el mismo sentido de favorecer la libertad económica. Las empresas tienen una carga impositiva del 12.5%, cuando la media europea es del 30%. Irlanda tiene un gasto "social" per capita muy por debajo de la media europea.
En Galicia en cambio parece que nadie hace nada si no es con subvenciones de la Xunta. Están subvencionadas desde las ovejas hasta las empresas de electrónica, pasando por los aerogeneradores que destrozan nuestro paisaje. Y las subvenciones vienen de los impuestos que lastran a la gente que sí es productiva.

Toda la discusión, incluyendo los comentarios y referencias, es de interés no sólo español, sino iberoamericano. Un comentario sobre el nivel de "globalización" de los dirigentes empresarios pudiera ser suscripto para muchos otros casos, por un argentino (cambie aquí "argentino" por el país de su preferencia):

(...) después de dedicarme tres cuartos de hora a explicar porque la quinta infraestructura (la de internet) es importante para el desarrollo y explicar las prestaciones, servicios y aplicaciones que se han desarrollado en Corea del Sur, un alto directivo de una empresa del sector eléctrico me dijo "Muchas gracias por la información, no estaba al día de que Corea, hubiera hecho todo esto" (primera sorpresa, pero ahora viene LA sorpresa) " nunca hubiera pensado que *un país del Tercer Mundo* (!!!!!) pudiera hacer todo esto".

El congreso de Universia: Se trató de un encuentro destinado a estudiar y promover "la aplicación de las nuevas tecnologías en la Universidad en las áreas de infraestructuras, administración universitaria y enseñanza a distancia a través del e-learning", promovido por la institución junto con Intel, desde su sede irlandesa, y varias universidades. El hecho de realizarse en Irlanda implicó la discusión de lo que destaca al país, a través de funcionarios y catedráticos. Pueden verse en detalle los contenidos de las presentaciones y ponencias en el sitio de la conferencia. El aspecto importante de este congreso es la difusión de este modelo entre autoridades de universidades españolas y latinoamericanas, y entre estas últimas particularmente. Entre ellas, la Universidad Nacional de Córdoba, con experiencia en emprendimientos de colaboración entre las empresas y la universidad (Cluster tecnológico de Córdoba), y la Universidad Tecnológica de Buenos Aires.
El impacto de esta experiencia se puede medir en las palabras de Uriel Cukierman, participante en representación de la UTN Buenos Aires:

Poco sabía yo de Irlanda antes de iniciar el viaje. Más allá del tan mentado "boom" de la industria de las TIC?s, sólo venían a mi memoria músicos como U2 o Enya, la famosa cerveza Guinness o el no menos irlandés licor Baileys
(...)
Seguramente han existido otras razones no menos importantes que los argentinos no debiéramos perder de vista, como los son las reglas de juego ciertas y estables, el fomento de la inversión extranjera en general y el de la industria de IT en particular, pero a un universitario le suenan como música en los oídos las aseveraciones en el sentido de que la mejor y más productiva inversión es aquella que se dedica a la educación

El reportaje completo puede consultarse en Universia de Argentina. Como es sabido que las noticias son muy volátiles en Internet, transcribo las palabras de Cukierman a propósito de la inversión en conocimiento:

¿Qué rol jugó la universidad para el desarrollo tecnológico de Irlanda

Solo para ratificar lo hasta aquí expuesto, permitime tener en cuenta lo expresado en tal sentido por Andrés Oppenheimer en un libro de reciente publicación ("Cuentos chinos: El engaño de Washington, la mentira populista y la esperanza de América Latina").

¿Qué dice en concreto este periodista?.

Según el autor, "otros factores claves de las políticas de Irlanda para atraer las inversiones extranjeras fueron el apoyo estatal a la investigación universitaria? ?Irlanda se propuso como política de Estado atraer a las principales empresas de computación del mundo".

De ahí la necesidad de invertir en educación?

Oppenheimer es claro. Dice que "para poder abastecerlas con mano de obra calificada, los sucesivos gobiernos invirtieron fuertes sumas en las décadas del ochenta y noventa para estimular las carreras universitarias de ciencia y tecnología, creando dos nuevas universidades y dándoles más dinero a las existentes.

¿Y cuál fue el resultado que deberíamos imitar en la Argentina?

Un dato que grafica todo: según cifras oficiales, allá los estudiantes de computación aumentaron de 500 en el año 1996 a 2 mil en 2003, por ejemplo.

Finalmente, los números y precisiones de Andrés Pedreño, interesado en sacar conclusiones aplicables a España:
Impuestos:

Algunos quieren ver en el éxito del modelo irlandés la sustancial reducción de la tasa de impuestos que pasó en los últimos años del 53% al actual 35%. Esta reducción impositiva coincide con el logro de una tasa media de crecimiento del 5,6% y un crecimiento del 50% en los empleos que en los últimos 18 años ha permitido a Irlanda saltar desde la 22ª a la 4ª posición en el ranking de prosperidad de la OCDE. Incluso se va más allá al subrayar los hipotéticos efectos de una política fiscal que pone menos énfasis en las rentas del trabajo y los beneficios que en el consumo. Este equilibrio entre impuestos directos e indirectos motivaría a trabajadores y empresarios a incrementar la producción del sistema

Estrategia conciente de construcción de un nicho de exportaciones:

Irlanda es una de las economías con una mayor orientación de su crecimiento hacia la exportación. El 85% de su producción manufacturera se exporta. La tasa de crecimiento real media de sus exportaciones crece al 15,9 % anual, siendo la más alta de todos los países de la OCDE.
El Irish Industrial Development Authority (IDA) ha desempeñado un importantísimo papel en el éxito de la competitividad exportadora irlandesa y en la atracción de empresas claves de ámbito mundial. La mayor parte de los expertos señalan esta decisiva contribución en el desarrollo económico de Irlanda en estos últimos años.
El IDA identificó que la emergente industria del software en los ochenta era la apuesta estratégica y que Irlanda podía definir una política activa de atracción a través de las ventajas asociadas a la existencia de una mano de obra joven y muy cualificada. Esta política vería sus frutos con la atracción de empresas como Intel en 1989, a la que seguirían otras compañías líderes de ámbito mundial

Educación:

Irlanda tiene, según el IMD World Competitiveness Report (2004), uno de los mejores sistemas educativos del mundo. Casi un millón de personas forman parte de su sistema educativo a tiempo completo.

Respuestas del sistema educativo a las necesidades de competitividad de la economía por países

Irlanda ....................7.40
Holanda ...................6.56
Bélgica ....................6.30
Francia ....................5.75
USA .........................5.74
Reino Unido .............4.59
Alemania ..................4.21
España .....................3.80
Fuente - IMD World Competitiveness Yearbook, 2005

Estos resultados no se han producido al azar. El gasto en educación se ha incrementado un 150% en Irlanda desde 1985. La proporción de personas con estudios universitariosentre 25-34 años es la segunda de Europa y la 4ª de toda la OCDE. El actual output de unos 2000 graduados/año en informática de Irlanda –con una población de tres millones de habitantes- es equivalente al de toda Alemania.

Nadie duda que la estrategia del crecimiento económico irlandés se basa en una decidida apuesta por un conjunto de políticas educativas a favor de la competitividad y las nuevas tecnologías, debiendo superar el coste de restricciones tales como deficientes carreteras, ausencia de transporte público, elevado precio de la vivienda, sistemas de pensiones o sanidad deficientes, etc.

Apuesta por la tecnología:

Para sostener su estrategia de crecimiento el gobierno irlandés también ha venido dando decididos pasos a favor del desarrollo de las TIC, que podemos resumir en:

• Liberalización del mercado de las telecomunicaciones.
• Fuerte inversión en infraestructura de banda ancha.
• La introducción más favorable para el desarrollo del comercio electrónico de todos los estados de la Unión Europea.

Entre los proyectos más singulares es el que fue denominado Dublín Digital District Project. Una regeneración urbanística con las tecnologías más vanguardistas en torno a Internet y las empresas de tecnología. Este futurista distrito digitalde 9,6 km cuadrados proyecta crear 7.000 empleos en alta tecnología y combina artes tradicionales – cine, diseño gráfico, música publicidad- con nuevas tecnologías basadas en la computación para la creación de contenidos digitales y su envío a través de teléfonos, televisión e Internet. Hoy el proyecto, no exento de dificultades, se redefine como el Digital Hub.

Un país puede transcurrir trescientos años en la pobreza, y poblar la tierra de pastores inmigrantes, pero un día puede decidir cambiar...quizá al principio en forma imperceptible, hasta que un día amanece otro. Encontraremos nosotros nuestro camino, antes que otras calamidades nos afecten definitivamente?

Chile mencionado por Dr Dobb's

La publicación Dr Dobb's dedica un artículo a los proyectos y esfuerzos para colocar a Chile como plataforma de outsourcing de corporaciones de todo el mundo. A la conocida presencia de Yahoo en Santiago de Chile, David Gardner agrega la entrada de Tata Consulting:

Chile views itself as a potential IT outsourcing tiger, and while it has been working hard to convince U.S. companies of its outsourcing expertise, it may have found a surprising supporter -- India's outsourcing giant Tata Consulting Services (TCS.)
"TCS likes Chile because we are in the same time zone as the U.S.," said Constanza Donoso, a representative of the Chilean Economic Development Agency, in a brief interview. "Tata provides financial services to U.S. customers from Chile."

Gardner destaca el incremento en fondos para investigación y desarrollo:

The new drive, said Donoso, comes from the country's new President Michelle Bachelet, who has pledged that Chile will increase its research and development spending by 50 percent. The country is setting aside $200 million this year from mining taxes to invest in high technology; the figure is likely to grow to $350 next year, officials said.

Varias compañias, particularmente estadounidenses, establecieron servicios en Chile:

Several U.S.- and Europe-based companies have located service operations in Chile's major cities primarily to serve Latin American customers. These include Delta Air Lines and Air France reservations operations as well as customer service units run by Citigroup, JPMorgan, Unilever and Zurich Financial Services.
Particularly prized are U.S. technology companies, which will carry out sophisticated research and development in Chile. Synopsys, a California-based provider of semiconductor design, has opened its first design center in Latin America in Santiago. It plans to expand the software engineering group to 60 by 2009.
Yahoo has established an Internet Research Lab where the PhDs it has hired develop mathematical algorithms that will facilitate Internet searching. General Electric's International Center of Excellence in Chile has hired many software developers. Software AG, a German company with a large presence in the U.S., develops enterprise software for government and businesses from its XML operation in Chile.
Businesses are increasingly attracted to Chile's high literacy rate (96 percent) and the growing number of Chileans who speak English (7 to 8 percent), Donoso said.

Acoto por mi parte, que, como en otros aspectos, es destacable el esfuerzo conciente y concertado puesto en marcha para lograr este objetivo. Como en otro artículo se apunta, Chile debe mejorar en varios frentes sin embargo para poder concretar un buen resultado de carácter más o menos permanente: la existencia de trabas administrativas a la operación de actividades extranjeras, poca existencia de servicios de respaldo, no mucha difusión de lenguas extranjeras -a pesar de lo indicado en el artículo-. Sin embargo, Chile no ha dejado de obtener buenos resultados, uno tras otro, a fuerza de continuidad y claridad de objetivos.

Un informe sobre fatiga mental en educadores argentinos

Infobae publica hoy un informe de la Escuela de Trabajo Social de Universidad Nacional de Córdoba impulsado por la Unión de Educadores de la Provincia de Córdoba para conocer el estado de salud de los docentes. Si bien puede ser calificado de parcial, aporta números que incluso lateralmente son de interés, y que debieran servir para mejorar la preparación de estadísticas sobre el sector.
El problema:

"uno de cada cinco de los más de 55 mil educadores en actividad", presentan síntomas de burn out o "cabeza quemada".
Se trata de un síndrome de cansancio emocional, despersonalización y falta de realización profesional que afectan la tarea educacional.
La patología, común entre los cirujanos y profesionales expuestos a altos grados de tensión, implica la pérdida de recursos emocionales para enfrentar el trabajo.

Los números:

El 21,7 por ciento de los docentes presentó síntomas de cansancio, fatiga, manifestaciones psíquicas y físicas y sensación de no poder dar más de sí.
El 27,5 por ciento manifestó actitudes negativas, distantes y cínicas hacia sus alumnos.
El 20,8 por ciento presentó bajo rendimiento y autoestima y sensación marcada de frustración.
(...)
Los docentes que presentan síntomas de burn out son mayoritariamente mujeres, de entre 31 y 50 años con más de 161 alumnos a cargo y con una antigüedad de entre 11 y 15 años.

Subrayo el último número: ¿más de ciento sesenta y un alumnos a cargo? ¿qué significa eso?¿que un maestro/profesor atiende mensualmente una clase/dos o tres clases de ese promedio aproximado de alumnos? ¿que recorre cuatro escuelas semanalmente?¿y esa cifra supera al diez por ciento de los educadores?.

Steven Kelly, DSL, y Charles Simonyi

Steven Kelly, participante en OOPSLA como miembro de MetaCase, comenta a Simonyi, quien comenta a las herramientas DSL:
He asked a good question:

"If DSLs are so useful, and so incredibly efficient, and have been around for so long, why isn't everybody already programming this way?" He gave three answers:

* building good languages is hard
* designing parsable languages can be hard
* building editors for the language is expensive"

Responde Kelly:

I'd agree with the first, but graphical DSMs and a meta-tool like MetaEdit+ or GME have solved the latter two problems over ten years ago. One of the questions at the end pointed this out to him. For the first, good tools can help, but the real answer is simply that building a language is a task for an expert developer. It's hard even then, but it's doable and is the best possible use of the expert's knowledge and skills.

Kelly discute también el enfoque de Simonyi para su propio desarrollo:

Intentional have changed the name of their future product to "Domain Workbench", borrowing consciously from Martin Fowler's term "Language Workbench" (and you can look at MetaEdit+ Method Workbench for a possible hint of where the lovable jackal got that particular piece of carrion). The main focus is on providing different views on the same program -- different projections of the same tree-like representation of the program in their repository.
I'm all for different representations (my first work on MetaEdit+ was building the Matrix Editor). But Intentional's idea is to be able to switch between different representations on the fly, and that's not a good idea. The human brain pays a significant cost each time the format shifts in that way -- just like switching between two spoken languages. Additionally, we build up maps in our mind of our code, and automatically laid out code breaks some of those maps -- even more so if you switch between several different representations.

Sobre Metacase: Metaedit+

Booch necesita secretarios

Si usted tiene tiempo, es buen conocedor de OOD y patrones, maneja bien el inglés, y es analítico para trabajar, tiene una magnífica oportunidad de participar en un proyecto valioso: Grady Booch no puede abarcar sólo su proyecto, y ha lanzado una invitación a colaborar con él, en su Handbook.

El futuro del diseño, en veinte años

Volviendo a Lambda, the ultimate, Peter Van Roy escribe dos líneas sobre el futuro del diseño, sugiriendo vías de evolución, y proponiendo un modelo:

What will programming look like in 20 years? Maybe it will be based on a "definitive language" like the speculations of the article Convergence in language design: a case of lightning striking four times in the same place (FLOPS 2006). Such a language will have a layered structure and its handling of concurrency is important. (Whether it is dynamically or statically typed is of absolutely no importance, BTW.)

How will we program with such a language? Maybe we will program with feedback loops, as explained in Self management and the future of software design (FACS 06). This seems to be one way to handle complexity, the inevitability of software and hardware faults, and managing global behavior of a system. I am coordinating a new project, SELFMAN, that is looking at this.

Extraído del papel de Van Roy mencionado:

We propose to build self-managing software systems as sets of concurrent agents interacting by means of asynchronous events and implemented using a component model with first-class
components and component instances. In this framework, self-managing systems are built as hierarchies of interacting feedback loops. The first design rule is that the whole system (except perhaps a small kernel) should be inside a feedback loop.
Feedback loops interact through two mechanisms, stigmergy (shared environment parameters) or management (one loop controls another). The feedback loop structure is designed to provide a desired global behavior. This behavior should also be predictable from the loop structure. We relate this proposal to two other architectures, namely the Erlang fault-tolerance architecture and the subsumption architecture for implementing intelligent behavior.
These ideas are being realized in SELFMAN, a project in the European 6th Framework Programme that started in June 2006 [27]. We intend to elaborate these ideas into a programming methodology together with an implementation. It should be as easy to program with and reason about a feedback loop as it is for an object or a component. We will design and formalize a component model that is based on the Oz kernel language extended with elements from the Fractal model.
We will use this component model as the basis of a programming model along the lines of Section 5 and implement this model in Mozart [26,9,13,23]. We will build a feedback loop architecture on top of this implementation and use it to implement a self-managing replicated transactional storage service.

Otros puntos de vista en la misma línea pueden verse en Paradigmas.

Eric Kimberling: buen material sobre implementación de ERP´s

Eric, miembro de Panorama Consulting Group LLC, colabora frecuentemente con IT Toolbox, un sitio excelente para conocer, aprender e investigar sobre el desarrollo e implementación de aplicaciones de empresa (lo que abarcan usualmente las siglas ERP, Enterprise Resource Planning, y EAI, Enterprise Application Integration).
En el último tiempo, son destacables sus artículos "The hidden costs of ERP", y "Why Are ERP Projects Always Over Budget?", centrados en el manejo de la implementación de estas aplicaciones verdaderamente complejas.
Sobre costos ocultos:

1) Internal company resources to make decisions on ERP requirements, help with system design, and perform testing. Aside from a full-time core team, most ERP projects require the involvement of 3-5 part-time subject matter experts for each full-time core team member.

2) Internal or external resources to manage data conversion, interface development, and report generation. Getting the system implemented is a huge milestone, but not if you haven't converted data or built the right interfaces and reports.

3) Employees to support communications, training material development, and training deployment activities. Many assume that the implementation consultants will handle this, but company employees also need to provide much of their time in helping develop materials and deploy training.

4) Time that senior management is involved in decision-making and conflict resolution. In a perfect world, employees across all office locations and geographies would be able to make decisions that everyone agrees with and that is best for the business overall. Unfortunately, in reality, senior management is often required to make decisions on behalf of the business, prioritize business needs, and provide strategic direction to ensure the project is aligned with overall business goals. There are costs associated with this time, and it should be quantified accordingly.

5) Design of business processes, particularly if the project involves a large, multi-national company with fragmented operations. ERP presents an opportunity to standardize and globalize operations across multiple locations, so arriving at a common operating model takes time and resources. It should not be assumed that the software itself will provide all the answers; business users need to decide how they are going to best leverage ERP to run their operations in the future.

6) "Backfilling" project team members with contract or other employees to manage day-to-day activities for the project team members who are no longer able to commit to their usual day-to-day jobs. It shouldn't be assumed that the business will continue to run as normal without replacing people that are devoting their time to the project.

7) Travel and expenses for team members, particularly if dealing with a global project. Project budgets should assume at least 15% of total consulting costs for travel, then double this amount to account for internal project team travel.

Sobre el incumplimiento de plazos y presupuesto:

1) Ensure executives outside of IT are involved in the vendor evaluation and planning process. Having more executives involved will help the management team identify all the hidden costs and benefits of implementing ERP.

2) Take your time during the ERP evaluation and project planning phase of the process. Too many companies rush into ERP as if the world is going to end without it, and they don't take the time to clearly lay out their business requirements, thoroughly evaluate the various vendors, and plan for a successful project. Any company that is serious about making their ERP project successful should spend at least 3-6 months on the selection and planning process, and possibly even more for companies that take longer to make decisions or are over $200 million in revenue.

3) Develop an actionable, realistic business case. A business case should be used for more than just convincing top management to approve the project. It should also be used to identify and manage operational business benefits and key performance indicators during and after the implementation.

4) Develop a realistic project plan and implementation timeframe. It may seem obvious that you won't know your true costs until you develop an implementation plan, but too many companies try developing an estimate before a plan has been identified. This is a huge recipe for a significant cost overrun.

5) Be open to the fact that it might not be time for ERP. Many may find this concept blasphemous, but even companies with the most manual processes and outdated technologies may not be suited for ERP. Perhaps a better and more cost-effective solution will help, such as business process improvements, best of breed software, etc.

Pero también son valiosos los comentarios de los lectores:
Sobre los costos ocultos, Yangoh dice:

The hidden costs have a lot to do with something like "putting the cart before the horse" syndrome. The industry norm is to engage ERP systems integrators and implementation consultants to help speed up the goal of "going life" without having any cultural revolution. The work culture may have to be changed drastically in order to adopt the new ERP systems.
It is definitely important to have SCM management education and training priot to ERP implementation, so that the business processes may have to be re-designed, improved and fine-tuned.
Due to the costs of consulting on a per man-day basis, in a lot of cases, it is not uncommon to try to reduce the number of man days to "going life". In many instances the life span of the ERP systems implemented with the compressed and expedited project timeframe can become very short, simply because more often than not the key users may revert to their old ways of doing things if the system does not suit them.
If only enterprises have the proper SCM education and training prior to purchasing a major ERP systems, then the costs of business transformation may be reduced drastically. It can also be true that sometimes it may not be necessary to change the systems at all, if only proper business process systems synchronisation (www.mpicsdb.blogspot.com) has been sorted out.
The other problem is the obsession with brand name ERP rather than going for the best in class or best of breed application solutions. In any case, operations management is still perceived as an art, so many enterprises can try new business practices but with the entrenched deep-rooted time-tested culture and processes.
The people factor is the least priority with some implementers forcing their way through the configuration of the ERP systems without getting the buy-ins and the approval of the key users.
If we use ERP as the enabler, then getting the business processes sorted out and synchronised should be the top priority besides looking at the opportunity for simplification and standardisation.

Sobre el exceso en presupuesto, Doug Hadden

I wonder whether the ERP industry suffers from the "blame the victim syndrome". Don't get me wrong, this advice is realistic. But, the solution to the ERP implementation problem seems to be generic - how to run large complex projects. Project Management 101. Isn't there something that the ERP vendors themselves can do to reduce the risk of going over budget?
Every time an ERP vendor reacts to a failed or late implementation, they point out that the customer's schedule was unrealistic - there weren't enough trained staff members - business processes presented by the client weren't accurate - there wasn't a long enough testing period (and so on). All of these are absolutely correct - in context to the ERP vendor's business model. When will these vendors smarten up and find ways to reduce the risk? Or, are they making too much money to change and upset the value chain? Possibly they are too focused on features or integrating acquisitions rather than worrying about usability, time to results, sustainability etc. Perhaps making ERP more complex increases switching costs. Don’t you wonder what would happen if ERP companies spent as much on simplification as they do on marketing?
On the other hand, to what extent are the victims responsible for predatory behavior? There’s more than enough evidence that ERP implementations are fraught with danger to know that vendors leverage hyperbole during the sales process. How can any responsible organization enter into an ERP contract without knowing these well-publicized risks?

La educación en Argentina

Las cifras de la educación son bastante aceptables, vistas por sí solas; consultando las estadísticas de la UNESCO sobre Argentina, los números muestran un país bien preparado. En estos días, justamente, un informe destaca sus aspectos positivos en el contexto latinoamericano. Sin embargo, para cualquiera que conozca las cifras más de cerca, esto no puede conformar, ni mucho menos.
Dado que el Ministerio de Educación redacta un proyecto de Ley de Educación, es ahora la época oportuna de puntualizar problemas y ofrecer soluciones. En los próximos meses, se irán acumulando aquí apuntes que puedan servir en algo. Quizá sean sólo impresiones, pero esperando que a alguien le interesen y se sume.
Para comenzar por algún lado, quisiera remitir a los dos artículos escritos antes sobre Chile, en los que se menciona la educación más de una vez. Algunos de los elementos que valoro allí no son mensurables en un párrafo de una ley, o no veo cómo lo serían: por ejemplo, la preocupación nacional por el resultado del exámen de aptitud que habilita para la Universidad, tanto de los estudiantes de escuela media, que sus últimos dos años están masivamente dedicados a su preparación, así como a enterarse de las distintas oportunidades que ofrecen las universidades o escuelas de formación terciaria, como de las escuelas, que desarrollan planes orientados a preparar para el exámen, o los padres, que siguen de cerca esa preparación.
Releyendo lo que escribo, creo que sí se pueden decantar elementos para una ley:

• El exámen nacional es obligatorio (en algún momento trataré el español). No es viable entrar a una universidad estatal sin pasar por ese exámen, que establece prioridades en base al puntaje y las vacantes disponibles. Se establecen listas de espera de los matriculados que se resolverán por el orden de precedencia de los resultados.
• Los últimos dos años tienen un aspecto de preparatorio para la admisión: así, una serie de actividades están programadas para capacitar, por un lado, y para hacer conocer la oferta de estudios. Existen dos o tres ensayos del exámen durante este período.
• Las escuelas son valoradas en base a los resultados de sus alumnos. Existe un ranking de calidad de las escuelas que es leído por todos.
• El rendimiento de las escuelas no sólo se sigue por este medio, sino por examinaciones periódicas de establecimientos y educadores.
• Las universidades ofrecen sus servicios en las escuelas; no esperan pasivamente la inscripción, sino que salen a dar a conocer sus especialidades.

Aquí no estoy hablando de la calidad del contenido de esa enseñanza, que no conforma ni a los propios chilenos, sino de la vía en la que se construye. Considero que sobre una base racional, el contenido es mejorable. Pero una base caotica desperdicia el trabajo.
Soy conciente que un exámen es limitativo, y que es muy cuestionado en Argentina. Pero sin un exámen de admisión se produce un período muy estéril inicial, que es bien conocido por el caso de la Universidad de Buenos Aires, obligada a mantener una estructura especial (el CBC-Ciclo Básico Común) para atender a miles de postulantes en una primera etapa que se supone que es orientativa: el trabajo que debiera cubrirse en el período anterior. Pensar en un curso de un año que sea nivelador, es ocultar el problema de la insuficiencia del período previo. De todas formas, puede tomarse al CBC como un exámen de ingreso, algo que pudiera servir para proponer un plan que mejorara el período de transición hacia estudios superiores o especializados.

Los números de las estadísticas marcan rasgos gruesos del nivel de instrucción, pero no conforman cuando se conoce la sociedad: no hablan en detalle de la calidad, ni de la profundidad de los conocimientos adquiridos. De esto hay que seguir hablando, y proponiendo...

Conferencia anual de JAOO

Para tener en cuenta: reunión 2006 de la European Conference on Java and Object Orientation. Suele reunir personas y materiales de verdadero interés. Especialmente, vale esto para el blog de la Conferencia

Parque tecnológico de la Universidad Austral y Taurus

El 19 de octubre se presentó en Pilar, provincia de Buenos Aires, un nuevo parque tecnológico, promovido en este caso por la Universidad Austral y la empresa alemana Taurus. El anuncio del proyecto cuenta a su favor con la consistencia de otros proyectos anteriores, incluída la Universidad misma, que es una de las más recientes establecidas en Argentina. El proyecto en las noticias:
En CanalAr:

La inversión inicial demandará unos 14 millones de dólares, pero las autoridades de la universidad dijeron que ascenderá a unos 150 millones de dólares hacia el final del proyecto, que contó con la ayuda de Taurus, un reconocido operador inmobiliario a nivel mundial. La idea es que haya una excelente correlación entre la universidad, la empresa, la inversión privada y los programas públicos de desarrollo.
Débora Georgi, ministra de la Producción de la provincia de Buenos Aires, estuvo en la presentación y aseguró que esto representa una sinergia entre el crecimiento industrial y el avance tecnológico en el país. Al respecto, subrayó que en las cercanías de Silicon Valley, en Estados Unidos, se encuentra la Universidad de Stanford. De éste modo destacó la articulación de un proceso compatible con la necesidad del pequeño y mediano empresario orientado al sector de la investigación.
Con igual sentido, el rector de la Universidad Austral, José Alejandro Consigli, explicó: “Es un emprendimiento que acorta la distancia entre la universidad y la empresa porque permite una interacción con la demanda de investigación que tienen actualmente las empresas. Por esa razón, la institución facilita parte de su terreno para que los inversores construyan edificios que luego se alquilarán a las firmas que se instalen”.
El académico agregó: “El interés de una empresa que quiera participar en el proyecto es que va a tener profesores e investigadores. Contará también con algunos laboratorios de la universidad y con alumnos para realizar pasantías. Indudablemente, son carreras afines a las necesidades de una firma, pero no necesariamente. Habrá algunas que se instalen por los beneficios impositivos que otorga la Municipalidad de Pilar o la Provincia. Con el tiempo terminará constituyéndose en un polo tecnológico”.
Finalmente, Peter Merrigan, CEO de Taurus, afirmó: el Parque es una plataforma única que concentrará inversiones para toda la región y pone a la Argentina al nivel de las naciones más avanzadas. Al igual que otros ejemplos exitosos en el mundo, es la unión de esfuerzos que reunirán un capital intelectual muy valioso en la región, en un ámbito de seguridad, con la estructura edilicia y servicios de última generación”.

En Infobae:

El parque tecnológico, científico y empresarial que se construirá en 27 hectáreas del campus de la Universidad Austral en Pilar requirió una inversión inicial de 14 millones de dólares de parte de la empresa Taurus, que levantó 120 emprendimientos similares en Estados Unidos y Europa.
El proyecto fue presentado ante unos 300 empresarios de diferentes actividades, con la participación de la ministra de Producción de la provincia, Debora Giorgi y el rector de la Universidad Austral, José Alejandro Consigli.
Consigli destacó que el proyecto comenzó a gestarse en 2000, pero desde hace dos años el interés de Taurus, le dio un nuevo impulso, beneficiado además por el entorno de recuperación y crecimiento económico en el país.
El académico fundamentó la importancia de levantar un centro en el que "se desplieguen las sinergias entre la universidad y el sector empresarial" y enfatizó el apoyo que encontraron en el Estado, tanto a nivel municipal como provincial y nacional.
El presidente Néstor Kirchner envió una carta a las autoridades de la Universidad a quienes felicitó por la iniciativa y sostuvo que las acciones de investigación y desarrollo incrementan la competitividad de las empresas y apuntalan el crecimiento del país y de la región.
El proyecto ideado por Taurus prevé que en el segundo semestre de este año las primeras empresas ya podrán instalarse en el predio donde por ahora trabajan en el suelo y el despliegue de la infraestructura de servicios.
Si bien hoy se concretó la presentación formal, el presidente del Parque Austral, Fernando Ambroa, señaló que ya recibieron el interés de veinte empresas entre las que se cuentan multinacionales y nacionales dedicadas al desarrollo de software, telecomunicaciones satelitales, laboratorios medicinales y de la industria automotriz.
La intención es albergar hasta 100 empresas, con una inversión final del proyecto por 150 millones de dólares y prevén que se generarán al menos 8.000 empleos calificados.

En Clarín:

Ese predio podrá albergar a empresas de biotecnología, agroalimentos, automotrices o de software, entre otras especialidades, según comentó Fernando Ambroa, presidente del Parque. El directivo señaló que ya hay una veintena de empresas interesadas en sumarse al proyecto.
La inversión inicial de la obra —de unos 14 millones de dólares— va a provenir de la operadora inmobiliaria alemana Taurus, asociada a este emprendimiento. Esta firma debuta, así, en el mercado local aunque maneja negocios similares en Estados Unidos, Canadá y Europa. Es, por ejemplo, socia mayoritaria del Parque Tecnológico de Orlando, en EE.UU..
"En este caso, en el polo de Pilar, no hay venta", explicó Ramiro Julia, presidente de Taurus Argentina. "Las empresas alquilan el edificio, a un costo que es sustancialmente menor al de cualquier oficina en la Capital Federal y similar a los alquileres de la zona: unos 14 dólares el metro cuadrado", dijo.

En La Nación:

Al acto asistieron representantes de más de 300 empresas, entre ellos de Molinos, la farmacéutica Boehringer Ingelheim y Hewlett Packard. También estuvieron presentes autoridades municipales y provinciales que anunciaron ventajas impositivas para las empresas que se radiquen en el parque.
La ministra de Producción bonaerense, Débora Giorgi, anunció durante el acto la firma de un decreto por parte del gobernador, Felipe Solá, que declara de interés provincial la iniciativa.
También sostuvo que será acogido por la ley de promoción industrial de Buenos Aires, que aguarda ser sancionada en la Legislatura provincial y que acarrearía exenciones en el pago de sellos, ingresos brutos y rentas. Por último, destacó la necesidad de brindarles la posibilidad a las pymes para que se integren a estos emprendimientos. De esa forma, dijo, podrían acceder a tecnología y servicios que no pueden financiar por sí mismas. "Queremos que las pequeñas y medianas empresas se transformen en grandes y las grandes, en multinacionales", dijo.
A su turno, el intendente de Pilar, Humberto Zuccaro, anunció que las empresas que se instalen en el predio quedarán exentas del pago de la tasa municipal.
Mediante una carta, el presidente de la Nación, Néstor Kirchner, de gira por Bolivia, destacó el proyecto y señaló que el parque "se transformará en un espacio de investigación y desarrollo, mejorando así su competitividad y contribuyendo al desarrollo económico de nuestro país y de toda la región".
Juliá celebró la misiva del Presidente y tibiamente dejó entrever qué esperan de la Nación: "El apoyo del gobierno nacional a esta iniciativa es muy importante, porque los países ven estos proyectos como infraestructura estratégica y brindan créditos blandos o subsidios directos, como pasa en Uruguay o Brasil".

El parque se une así a otras iniciativas anteriores, en general emprendidas en colaboración entre Universidades estatales y sectores privados de la tecnología, como los de Tandil, Córdoba y Rosario. La Universidad Austral posee otras instituciones de punta, como la Escuela de Negocios, que, por ejemplo, permitió difundir APICS en Argentina.

Un blog finlandés activo en MDA y SF

Aali Likoski, desarrollador .NET en finlandia, mantiene en MSDN un activo blog, en la línea de Microsoft sobre Software Factories, pero con un punto de vista más abierto sobre MDA. Al menos, es lo que se puede concluír sobre sus entradas en inglés... (mi finés está en la lista de espera).

Al negocio del software en Argentina le faltan ingenieros...

En La Nación, el 12 de octubre:

Representantes de la industria informática y del Ministerio de Educación lanzaron ayer la segunda versión de la campaña para incentivar la inscripción de alumnos en las carreras universitarias de sistemas. Pese a que la industria tuvo un fenomenal desarrollo en los últimos años, el número de egresados e inscriptos en las carreras informáticas y afines no es suficiente para cubrir los puestos que las empresas requieren.
Actualmente, sólo un 5% de los estudiantes universitarios cursa carreras vinculadas con la tecnología.
(...)
Según las estadísticas del sector, la industria de desarrollo de software viene creciendo a un ritmo del 20% anual, en promedio, en los últimos tres años. En 2006 proyecta facturar $ 4800 millones, un 20% más que en 2005 y exportará por 300 millones. Actualmente, la industria de software emplea cerca de 50.000 profesionales. Además, ya hay trabajando 14.000 profesionales directamente para exportación de software.

Acciones que tensan las paradojas argentinas...En vísperas de una nueva ley de educación, sería fundamental planear las bases de políticas duraderas, de décadas de alcance, antes que golpes de timón en la tempestad.

Cómo MDA incrementa la productividad

Este comentario es una actualización de otro hecho en los inicios de este blog, sobre un análisis de productividad de Middleware Research, comparando un desarrollo utilizando una herramienta MDA contra otro equipo utilizando herramientas "estándar". Al volver sobre el tema a propósito de otra discusión, encontré que el enlace era inhallable. Concluyo que, a pesar de que fuera redundante, es preferible citar textualmente y desarrollar el comentario, en lugar de remitir al original. Es que Internet es demasiado fugaz, y las referencias y citas basadas en enlaces no son muy confiables. Trataré de tomar esta observación en el futuro. Y ahora, reponer el artículo...
The Middleware Research era una compañia dedicada, entre otras cosas, a la investigación y evaluación de software. Para el 2004, todavía aparecía como parte de The Server Side, pero hoy, siguiendo el enlace de su artículo, lo que se encuentra es esto:

As of November, 2004, The Middleware Company and its Middleware Research business unit have been discontinued. TheServerSide.com, TheServerSide.NET and related conferences are continuing operation as part of the TechTarget network. The Torpedo O/R benchmark has been moved to: http://www.torpedo-group.org, and the SOA Blueprints initiative now lives at: http://www.soacenter.com

Para quien le interese, todavía puede encontrar materiales disponibles en sus nuevos alojamientos. En el caso del informe de productividad de MDA, luego de varios intentos, lo localicé en el sitio de Compuware. Compuware, que también sufrió cambios desde 2004, no lo menciona como un papel destacado, quizá porque no cuadre enteramente con su producto -OptimaJ- al día de hoy.
Cuá era el propósito del estudio:

In the spring of 2003 The Middleware Company performed and published a study testing whether development tools taking a Model-Driven Architecture (MDA) approach increased the productivity of developers building a new J2EE application. That study found that MDA increased productivity 35% over a traditional, code-centric approach.
This study extends the examination to the realm of application maintenance. Two teams performed a set of typical and diverse enhancements to an existing application. One used an MDA -based tool, while the other team used a code-centric approach with a traditional enterprise-caliber integrated development environment (IDE).
The team taking the MDA approach completed the five enhancements 37% faster than the traditional team, in 165 hours versus 260. These results are well in line with those of the first study. As a result of this case study, The Middleware Company reinforces its recommendation that development shops interested in increasing their productivity evaluate MDA -based development tools for use in their projects.
(...)
This whitepaper compares the productivity of two development teams maintaining and upgrading an identical J2EE application. One team used a Model-Driven Architecture (MDA) approach to J2EE development. The other team used a traditional, code-centric development approach. The original application was a version of the familiar J2EE PetStore application, defined by a rigorous functional specification. The upgrades, which represented a range of typical enhancements, were defined by another rigorous specification. Both specs were reviewed by industry experts.

La herramienta medida fue OptimalJ, pero puedo asegurar que el esquema es válido con la mayor parte de los productos de su tipo, y allí reside el interés del estudio. El punto clave del estudio es su extensión al período de mantenimiento. Es aquí donde las ventajas de utilizar un esquema de desarrollo basado en modelado abstracto con generación automática de los resultados, se torna crecientemente productivo, tanto más cuanto más se expande el desarrollo en tamaño y tiempo. La condición es que la descripción del problema esté hecha en el nivel abstracto, y que existan herramientas que traduzcan en cada momento el modelo a código ejecutable.
Qué se comparaba:

(...) the basis for the specification used in this study is the well known PetStore
application4, a simple web-based J2EE e-commerce application. The baseline PetStore has the following functionality:
o User management and security. Users can sign into the system and manage their account.
o A Product catalog. Users can browse a catalog of pets on the web site (such as birds, fish or reptiles).
o Shopping cart functionality. Users can add pets to their shopping cart and manage their shopping cart in the usual ways.
o Order functionality. Users can place an order for the contents of their shopping carts.
o Web services. Users can query orders via a web service. We extended the PetStore to include this, since web services are an emerging area of interest.
From a technology perspective, the PetStore includes the following:
o A thin client HTML UI layer
o JSPs to generate HTML on the server
o JDBC SQL-based data access
o EJB middle tier components
o Ad-hoc database searching
o Database transactions
o Data caching
o User/Web session management
o Web Services
o Forms -based authentication

Our Maintainability Specification describes requirements for five major enhancements to the baseline application. Each focuses on a different combination of additions or changes, from new user features to business logic changes to integration with other applications.
The teams in this study implemented all of these enhancements :
1. Tracking pet maturation
2. Calculating shipping costs
3. Soliciting supplier bids for new inventory
4. Integrating with Amazon.com via its web service
5. Integrating with a mainframe application to track shipments

La comparación desde el punto de vista de la arquitectura:

Since the development work performed in this study built on that of the original one, many of the critical design choices were already in place. As the previous study describes in detail, both teams used J2EE design patterns extensively in their original work. On the MDA side, these patterns resulted from the implementation templates that translate the Platform-Specific Model (PSM) into code. The MDA tool automatically generated high-quality pattern code from the model. On the traditional side, the patterns stemmed from deliberate design choices and (for the most part) explicit coding. In fact, the previous study found that the traditional team actually used several more patterns than the MDA team.
Some of the design patterns used by both sides in the original application include:
o Session Façade
o Business Delegate
o Data Transfer Object (DTO)
o Model-View-Controller (MVC)
Additionally, the traditional team used these patterns in its original coding:
o Service Locator
o Data Access Objects (DAO)
o JDBC for Reading
In the current round, both teams expanded their use of patterns. On the MDA side, the newer version of OptimalJ incorporated patterns that the previous study’s version did not, particularly Service Locator and DAO. Since these additions resulted from changes to the implementation patterns, they stem from the MDA approach rather than this particular MDA tool. In fact the MDA team in the previous round could have added those patterns had they edited the templates themselves. On the other side, the traditional team used the EJB Command pattern in the legacy integration enhancement. All in all, in this round both teams used approximately the same set of design patterns.
In terms of overall design quality, the code produced this time compared favorably with that of the previous round. For new work that extended previous functionality, the two teams adhered to the same basic designs. The MDA models generated new code that was architecturally equivalent to the existing code.
And the traditional team continued their deliberate use of appropriate design patterns.
In terms of work that was substantially new – such as JMS, web service or legacy integration – the MDA approach continued to help keep architectural quality high. Two examples:
o When a web service or JCA integration was added to the model, the model generated not only the basic client stub classes, but also a stateless session bean and business façade wrapper to the stub.
o For writing a JMS producer, the MDA approach made it very easy to define a message data structure and tie it to the message-producing component, thus minimizing the amount of custom business logic actually required.
On the traditional side, the team had to consciously design and build the wrapper code for the various integration components . They did so with a level of quality comparable to that of the original application.

La integración de código heredado:
El equipo tradicional:

Receiving the stub classes for talking to the CICS application simplified the team’s task enormously. Without them, the team would have had to write that code by hand; lacking experience in COBOL programming or CICS connectivity, they undoubtedly would have found this experience arduous, time consuming and frustrating.
One problem hindering productivity had to do with the distribution of classes for deployment. Using a JCA adapter and accompanying RAR file encouraged the use of an EAR file for deployment. This caused several slowdowns as the team discovered that all non-EJB classes needed to be placed in a separate JAR
file from the EJB JAR and the WAR file so that they could be safely shared and correctly loaded by the class loader. This took considerable time to detect as crucial and then configure, however once accomplished, the deployment of changes was much swifter

El equipo MDA:

Connecting to a mainframe application through a JCA adapter proved remarkably easy. The teams were given an adapter for CICS applications and a piece of COBOL code containing the required record structure, as well as basic information about the target application and some rudimentary documentation.
After the JCA adapter was installed (a simple process), setting up the JCA client was much like defining a web service client:
o OptimalJ parsed the COBOL file much like a WSDL document to create the correct data structure (a custom DTO). This process also created the appropriated elements in the integration tier of the application model.
o The team had the product create corresponding data structures in the domain and application models.
o Generating the code model (EJB and web code) from the application model was straightforward.
o The default application again proved handy for testing.
Overall, the process was extremely quick and did not require any knowledge of COBOL.

En suma:

The challenge in this enhancement was much like the previous one: very little change to the data structures, some UI work, some business logic, but mostly integration. And the result was a comparably large difference between the two teams. Here the challenge centered almost exclusively on using JCA to send a query to a CICS application and get a result. The MDA team was able to add the JCA integration to their MDA model in almost exactly the same way as for a web service. This meant they could auto-generate the stub code without having to know anything about COBOL. And, as with the web services, they also auto-generated wrapper components. The entire effort was remarkably easy.
The traditional team, by contrast, did not have the benefit of a wizard to generate their stub code, so to keep the study’s focus on the differing approaches the team was given those classes . The remainder of their work centered on installing the JCA adapter and integrating the provided code into the application.

La comparación desde el punto de vista cuantitativo:

To complete all five PetStore enhancements took the MDA team 164.8 hours of development time, compared with 260.5 hours for the traditional team. This comes to a 37% improvement in productivity for the team using MDA.
This result is well in line with those of the previous study, which found a 35% productivity improvement for the MDA approach in building the PetStore application to the original baseline specification. The new result indicates that the MDA approach can offer similar productivity gains with respect to maintaining /
enhancing an existing application.

La comparación es particularmente interesante al bajar al trabajo diario de los dos equipos, enfocando las tareas y tomando decisiones. Quizá en su análisis detallado se encuentre el material de mayor interés, y la motivación para estudiarlo. Invito a hacerlo.

Irlanda, "Milagro Celta" comparado

Con una larga historia de emigración y pobreza, Irlanda evolucionó hasta convertirse en uno de los países de mayor interés en el mundo. Michel Moe dedica un breve artículo a enumerar y comparar las cifras de su crecimiento, relacionándolas con las de otros países emergentes, particularmente China e India. Sus cifras comparadas por producto bruto y uso y consumo de servicios dan una visión realista (por oposición) del grado de desarrollo de las dos economías gigantes.
(Sobre los límites de usar el producto bruto como medida, Wikipedia)

Historia viva del software

Scott Rosenberg inicia la publicación de materiales dedicados a la discusión de materiales importantes en la historia del desarrollo del software, con la particularidad de mantener una discusión abierta sobre cada ensayo o tema abordado:

This is the inaugural edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. This week we're talking about Frederick Brooks's The Mythical Man-Month

(...)

During the years I spent researching Dreaming in Code, I accumulated a veritable mountain of reading material on the topic of software development, the history of programming, project management and so on. (I even read much, though certainly not all, of it!) There is, plainly, a core set of books, documents and texts that trace the evolution of this subject; I also gathered some unusual obscurities and overlooked offshoots.

Only a small fraction of this material made its way into Dreaming in Code itself, which is a narrative tale of the ups and downs of one project, set in the context of the longer history of the field. I've been trying to figure out a good way to share my discoveries, spark some interesting discussion and contribute a lasting resource to the Web based on the work I've already done and the reading I continue to do.

Here's my plan: Every week I'm going to announce a topic — usually, a text or document, in many cases easily accessible online; a week later, I'll post some thoughts, notes and ideas about the topic, and open the floor in comments for you to throw your two cents in. If all goes well, together we'll build a handy annotated reading list for curious developers and interested outsiders — and maybe have some fun along the way.

Una nueva ley de educación en Argentina

En La Nación:

Una de las máximas responsabilidades que deberá asumir en poco tiempo más el Congreso de la Nación será la de analizar, debatir y sancionar la futura ley nacional de educación. La Argentina necesita dejar atrás la frustrante experiencia que se vivió con la llamada ley federal de educación, que fue aprobada por abrumadora mayoría en 1993, pero terminó por acarrearle a la comunidad educativa -y a la sociedad en su conjunto- más problemas que soluciones, en parte por desaciertos del propio texto normativo y en parte por equivocaciones en su aplicación.

El texto del Ministerio de Educación, según La Nación:

• restablecimiento del ciclo secundario como un ciclo único
• obligatoriedad de cumplir el ciclo secundario completo
• "procura superar las dificultades creadas por el excesivo fraccionamiento a que ha sido llevado el sistema educativo nacional, debido a las notorias disparidades que presentan las diferentes jurisdicciones"
• incorporación de tutores y coordinadores de cursos, cuya misión será acompañar a los jóvenes y orientarlos en su trayectoria escolar
• estructuración de procesos adecuados de orientación vocacional
• "el anteproyecto dispone que cada jurisdicción provincial o territorial deberá optar por una de las dos modalidades estructurales siguientes: o se adopta una duración de seis años para el nivel de educación primario y seis para el nivel secundario o se elige una duración de siete años para la primaria y cinco para la secundaria. Algunos observadores calificados de la problemática educativa opinan que el anteproyecto no debería autorizar esa opción. A juicio de esos especialistas, la ley debería optar lisa y llanamente por uno u otro régimen"
• se crea el Instituto Nacional de Formación Docente, que buscará garantizar una formación continua común en todo el país.

Debe tenerse en cuenta que para disminuír la deserción no alcanza con hacer obligatoria la enseñanza...Habrá que ver qué otros elementos se diseñan para hacer que la obligatoriedad no sea letra muerta. Es importante la institución de las tutorías, y el énfasis en la capacitación docente. Nuevamente, otros elementos deben acompañar al establecimiento de una institución.
Cada diez o quince años pasamos por una nueva ley de educación, con el mayor resultado visible de más confusión en el ejercicio de la enseñanza, nuevas dificultades en la terminación de estudios (quienes quedan en la frontera entre los dos sistemas encuentran dificultades para asimilar el cambio), y algo más de degradación en los resultados. Pero también, cada intento es una nueva oportunidad de planear un mejor sistema, que pueda torcer el rumbo hacia un resultado exitoso.

Ingeniería de Software como materia de estudio

El profesor Thomas Hillburn ofrece una lista de materiales orientados a formalizar una currícula para el estudio de Ingeniería de Software. Soporta en su sitio algunos materiales del SEI (Guidelines for Software Engineering Education, Specification for an introductory Software Engineering Curriculum). Particularmente, están disponibles muchos de los papeles de trabajo de la conferencia "Fronteras en Educación".