El tratamiento post-mortem de un proyecto

Mike Gunderloy dedica un artículo en Developer.com al cierre post-mortem de un proyecto, considerándolo con razón una herramienta de importancia en su manejo en el tiempo, denominándo la técnica "memoria institucional".

Though the name is well-established by now, "postmortem" has somewhat unfortunate connotations. The purpose of a good software postmortem isn't to carve up the corpse of a collapsed software project so as to assign blame for failure (though in dysfunctional organizations postmortems get used this way anyhow). Rather, the goal is to build up an institutional memory and develop a set of best practices that work for your own organization by meticulously recording what went right and wrong over the course of a project.
(...)
The difference between an organization with a culture of postmortems and one without can be dramatic. This is probably in part because of the good effects of postmortems, and in part because companies that lack the discipline to perform postmortems tend to be at a rather chaotic level of practice. When postmortems are institutionalized, you'll find people saying things like "we organize our source code tree this way, because we've found in the past that it works well" or "we stopped using that particular risk assessment practice because it just wasn't giving us any useful information." Without postmortems, developers are more likely to invent techniques as they go along, without much regard for what may or may not have worked in the past - and more likely to be surprised when something fails for the second (or third, or tenth) time.
(...)
Software postmortems, performed consistently, are a key part of bringing a development organization from chaos to smooth, repeatable functioning. In fact, if your development efforts are completely disorganized, postmortems can be a great way to start turning things around, because they will help you identify and keep the good parts while finding and throwing out the bad parts. If you're not already using this essential tool, it's never too late to start.

Gunderloy da nueve sugerencias para su elaboración:
Planear las actividades:

People need to have time to think without being thrown immediately into the next project. The postmortem should be a scheduled activity, with time for a meeting of the team to discuss the lessons learned and time for someone (or some group) to write the postmortem report

No dejar pasar mucho tiempo:

Don't let memories fade by scheduling the postmortem too long after the end of the project. Ship the software, have the celebration, and then roll right into the postmortem, rather than waiting for a convenient break in the action (which never comes, anyhow) a month or two later

Registrar los detalles:

Part of the postmortem report needs to be a recital of the details of the project: how big it was, how long it took, what software was used, what the objectives were, and so on. This is not padding, but a way to help people looking for applicable experience in the future. If you build up a library of dozens of postmortems, a team about to embark on a 5-person, 6-month effort can use the project details to look for similar projects that the organization has tackled in the past

Involucrar a todos los participantes:

You need to collect them all to really understand what worked and didn't.

Registrar tanto los aspectos exitosos como los fallos:

It's easy for a postmortem to degenerate into a blame session, especially if the project went over budget or the team didn't manage to deliver all the promised features. But people need to hear positive messages as well as negative ones, and they need to hear what things are worth repeating as well as which things are worth avoiding in the future.

No debe ser un argumento de penalizaciones:

If you want honest postmortems, management has to develop a reputation for listening openly to input and not punishing people for being honest. And the way to get that reputation is by not punishing people.

Establezca un plan de acción:

The written postmortem should make recommendations of how to continue things that worked, and how to fix things that didn't work. Remember, the idea is to learn from your successes and failures, not just to document them

Hágalo disponible:

If you're the one responsible for producing one, you should consider sending out an e-mail at the end of the process saying something like, "The XYZ project postmortem is finished and available at \servershare. We recommend that future teams do a, b, and c and avoid d, e, and f. For more details, feel free to read our whole postmortem."

Software Factory según Chillicoder

Martín Trejo, autor de Chillicoder , dedicó en julio de este año un artículo a Factorías de Software, que tiene la virtud de describir las condiciones que impulsan hacia formas más "industriales" de construír software. Y también una introducción a los recursos desplegados por Microsoft en este terreno, particularmente Guidance automation Toolkit. Continuará...

En Bloginnova:I+D en Finlandia, analizada en Bruselas

El próximo 10 de noviembre se celebra en Bruselas un seminario sobre los recientes instrumentos finlandeses y de la UE orientados a generar un entorno próspero de investigación y desarrollo (I+D) e innovación.
El seminario fue inaugurado por Anita Lehikoinen, Directora del Departamento de Educación y Política Científica en el Ministerio finlandés de Educación, quien habló sobre la estrategia de enseñanza superior de Finlandia como un requisito previo para el rendimiento del país en I+D e innovación, y sobre la necesidad de internacionalizar la estructura de investigación de Finlandia.
El Presidente de la Academia de Finlandia, el Profesor Raimo Vayrynen, también se hizo eco del reto de la «internacionalización», y señaló los recientes esfuerzos de la Academia y Tekes, la Agencia finlandesa de financiación de la Tecnología e Innovación, para situar el sistema finlandés de investigación en la arena mundial.

Java marcha a GPL

Stefan Tilkov, como varios otros, adelanta el anuncio del paso de Java a GNU General Public License v2 (GPLv2). Una gran noticia, de primera importancia para los próximos tiempos.
Algunas repercusiones en Tim Bray, InfoQ, Barrapunto, y especialmente, en Sun.

OOPSLA sobre Domain-Specific Modeling

Juha Pekka Tolvanen anuncia en mda-discussion, que están disponibles los procedimientos y presentaciones del Workshop de OOPSLA sobre Domain-Specific Modeling.

Surgimiento y declinación de CORBA (Michi Henning)

Este artículo tiene varios meses de publicado, pero su análisis sigue siendo válido, no sólo porque es retrospectivo, sino también porque se pueden deducir conclusiones vistas a futuro, especialmente en cuanto a la posibilidad de construír estándares apoyados en consorcios de la industria.
Resumiéndolo a cuatro palabras:
CORBA 2.0 se inició con éxito y popularidad al resolver el problema de desarrollo en sistemas heterogéneos:

It provided a standardized protocol and a C++ language mapping, with a Java language mapping following in 1998. This gave developers a tool that allowed them to build heterogeneous distributed applications with relative ease. CORBA rapidly gained popularity and quite a number of mission-critical applications were built with the technology.

La aparición de Java, por un lado, y el crecimiento acelerado de la Web, presentaron un desafío a la consolidación del estándar:

CORBA provided a Java language mapping, but it did nothing to cooperate with the rapidly exploding Web. Instead of waiting for CORBA to deliver a solution, companies turned to other technologies and started building their e-commerce infrastructures based on Web browsers, HTTP, Java, and EJB (Enterprise JavaBeans).

El estándar resultó complicado de utilizar frente al nuevo escenario:

Many of the APIs were complex, inconsistent, and downright arcane, forcing the developer to take care of a lot of detail. In contrast, the simplicity of component models, such as EJB, made programming a lot simpler (if less flexible), so calls for a CORBA component model became louder and louder.

CORBA resultó además caro y de lento aprendizaje:

Commercial CORBA implementations typically cost several thousand dollars per development seat, plus, in many cases, runtime royalties for each deployed copy of an application. This limited broader acceptance of the platform—for many potential customers, CORBA was simply too expensive.
The platform had a steep learning curve and was complex and hard to use correctly, leading to long development times and high defect rates. Early implementations also were often riddled with bugs and suffered from a lack of quality documentation. Companies found it difficult to find the expert CORBA programmers they needed.

Por otra parte, Microsoft no apoyó CORBA, y desarrolló su propio estándar, con pérdidas por ambos bandos:

Microsoft never embraced CORBA and instead chose to push its own DCOM (Distributed Component Object Model). This kept much of the market either sitting on the fence or using DCOM instead, but DCOM could not win the middleware battle either, because it worked only on Windows.

La aparición de XML transformó el escenario:

Another important factor in CORBA's decline was XML. During the late '90s, XML had become the new silver bullet of the computing industry: Almost by definition, if it was XML, it was good. After giving up on DCOM, Microsoft wasn't going to leave the worldwide e-commerce market to its competitors and, rather than fight a battle it could not win, it used XML to create an entirely new battlefield. In late 1999, the industry saw the publication of SOAP. Originally developed by Microsoft and DevelopMentor, and then passed to W3C for standardization, SOAP used XML as the on-the-wire encoding for remote procedure calls.
SOAP had serious technical shortcomings, but, as a market strategy, it was a masterstroke. It caused further fragmentation as numerous vendors clambered for a share of the pie and moved their efforts away from CORBA and toward the burgeoning Web services market. For customers, this added more uncertainty about CORBA's viability and, in many cases, prompted them to put investment in the technology on hold.

El colapso de la burbuja de Internet, produjo un efecto mortal en CORBA:

The industry's financial collapse drove many software companies out of the market and forced the survivors to refocus their efforts. The result was significant attrition in the number of commercial CORBA products. Before the collapse, several vendors had already dropped or deemphasized their CORBA products and, after the collapse, more followed.

Y lo más importante, las reflexiones de Henning sobre el estándar:

Technical excellence is not a sufficient prerequisite for success but, in the long term, it is a necessary prerequisite. No matter how much industry hype might be pushing it, if a technology has serious technical shortcomings, it will eventually be abandoned. This is where we can find the main reasons for CORBA's failure.

Henning puntualiza los problemas de CORBA:
Complejidad (en el desarrollo de las APIs, en el uso del lenguaje C++, complejidad de tipos usados, especificaciones innecesarias)
Falta de servicios disponibles, Seguridad, Versionamiento, los puntos especialmente señalados:

CORBA's unencrypted traffic is subject to eavesdropping and man-in-the-middle attacks, and it requires a port to be opened in the corporate firewall for each service. This conflicts with the reality of corporate security policies. (Incidentally, this shortcoming of CORBA was a major factor in the rise of SOAP. Not having to open a port in the corporate firewall and sending everything via port 80 was seen as a major advantage, despite the naïvete of that idea.) The OMG made several attempts at specifying security and firewall traversal for CORBA, but they were abandoned as a result of technical shortcomings and lack of interest from firewall vendors.
(...)
Deployed commercial software requires middleware that allows for gradual upgrades of the software in a backward-compatible way. CORBA does not provide any such versioning mechanism (other than versioning by derivation, which is utterly inadequate). Instead, versioning a CORBA application generally breaks the on-the-wire contract between client and server. This forces all parts of a deployed application to be replaced at once, which is typically infeasible. (This shortcoming of CORBA was another major factor in the rise of SOAP. The supposedly loosely coupled nature of XML was seen as addressing the problem, despite this idea being just as naïve as funneling all communications through port 80.)

La lista de defectos técnicos es más minuciosa, pero no quisiera terminar repitiendo el contenido del artículo, aunque sigo pensando que es mejor esto que perderlos, ya que los textos en Internet suelen ser movidos de ubicación.

Pero Henning destaca otro aspecto del declinamiento de CORBA, que es repetido a través de la corta historia de la construcción de software: la idoneidad o capacidad de la institución promotora del estándar. ¿Evolución a través de la investigación académica? ¿de un consorcio de la industria? ¿de una combinación de empresas, instituciones de educación e investigación? ¿la introducción de nueva tecnología por parte de una empresa?
CORBA contó con el soporte de OMG. Qué critica Henning:

The OMG is an organization that publishes technology based on consensus. In essence, members vote to issue an RFP [Request for proposal]for a specification, member companies submit draft specifications in response, and the members vote on which draft to accept as a standard. In theory, this democratic process is fair and equitable but, in practice, it does not work:

There are no entry qualifications to participate in the standardization process. Some contributors are experts in the field, but, to be blunt, a large number of members barely understand the technology they are voting on. This repeatedly has led to the adoption of specifications with serious technical flaws.

RFPs often call for a technology that is unproven. The OMG membership can be divided into roughly two groups: users of the technology and vendors of the technology. Typically, it is the users who would like to expand CORBA to add a capability that solves a particular problem. These users, in the hope that vendors will respond with a solution to their problem, drive issuance of an RFP. Users, however, usually know little about the internals of a CORBA implementation. At best, this leads to RFPs containing requirements that are difficult to implement or have negative performance impact. At worst, it leads to RFPs that are little more than requests for vendors to perform magic. Instead of standardizing best existing practice, such RFPs attempt to innovate without prior practical experience.

Vendors respond to RFPs even when they have known technical flaws. This may seem surprising. After all, why would a vendor propose a standard for something that is known to suffer technical problems? The reason is that vendors compete with each other for customers and are continuously jostling for position. The promise to respond to an RFP, even when it is clear that it contains serious problems, is sometimes used to gain favor (and, hopefully, contracts) with users.

Vendors have a conflict of interest when it comes to standardization. For vendors, standardization is a two-edged sword. On the one hand, standardization is attractive because it makes it easier to sell the technology. On the other hand, too much standardization is seen as detrimental because vendors want to keep control over the features that distinguish their product from the competition.

Vendors sometimes attempt to block standardization of anything that would require a change to their existing products. This causes features that should be standardized to remain proprietary or to be too vaguely specified to be useful. Some vendors also neglect to distinguish standard features from proprietary ones, so customers stray into implementation-specific territory without warning. As a result, porting a CORBA application to a different vendor's implementation can be surprisingly costly; customers often find themselves locked into a particular product despite all the standardization.

RFPs are often answered by several draft specifications. Instead of choosing one of the competing specifications, a common response of OMG members is to ask the submitters to merge their features into a single specification. This practice is a major cause of CORBA's complexity. By combining features, specifications end up as the kitchen sink of every feature thought of by anyone ever. This not only makes the specifications larger and more complex than necessary, but also tends to introduce inconsistencies: Different features that, in isolation, are perfectly reasonable can subtly interact with each other and cause semantic conflicts.

Major vendors occasionally stall proceedings unless their pet features make it into the merged standard. This causes the technology process to degenerate into political infighting, forces foul compromises, and creates delays. For example, the first attempt at a component model was a victim of such infighting, as was the first attempt at a C++ mapping. Both efforts got bogged down to the point where they had to be abandoned and restarted later.

Estas características pudieran adscribirse a múltiples consorcios. Henning especifica éste para OMG:

The OMG does not require a reference implementation for a specification to be adopted. This practice opens the door to castle-in-the-air specifications. On several occasions the OMG has published standards that turned out to be partly or wholly unimplementable because of serious technical flaws. In other cases, specifications that could be implemented were pragmatically unusable because they imposed unacceptable runtime overhead. Naturally, repeated incidents of this sort are embarassing and do little to boost customer confidence. A requirement for a reference implementation would have forced submitters to implement their proposals and would have avoided many such incidents.

En fin, el análisis de Henning puede verse lateralmente como una historia de CORBA, pero centralmente como una reflexión sobre las intrincadas vías de evolución de la tecnología. Henning dice: "Open source innovation usually is subject to a Darwinian selection process". Sin duda, debemos extender la afirmación al conjunto de procesos de innovación.

José Canosa: la ciencia y la universidad deben cambiar

Lo que sigue es una nota de José Canosa, publicado en Ideas, suplemento de Libertad Digital. Creo que merece que se publique completo, no limitándolo a una referencia, que quizá no sea visitada.
El contenido de la nota debiera ser leído no sólo por españoles, sino también por muchos otros.
Sigue el artículo, completo:

La revolución pendiente de la universidad y la ciencia españolas
Por José Canosa

Estudios recientes muestran la ineficacia de los esfuerzos españoles por lograr un nivel universitario y de desarrollo científico y tecnológico equiparable al de los países desarrollados de nuestro entorno.

Muchos de ellos se centran en cuestiones cuantitativas: presupuestos dedicados a las universidades públicas, porcentaje del PIB empleado en I+D, número de investigadores, estadísticas de graduados y doctores egresados de las universidades, etcétera. Pero las causas fundamentales del atraso secular español son otras: el control político de la universidad y la empresa científica, el régimen funcionarial de los profesores universitarios y de los investigadores de los organismos públicos de investigación (OPI) y el concepto medieval y burocrático de los estudios y títulos universitarios oficiales.

Los sistemas universitarios y científicos de nivel internacional se rigen por valores universales que transcienden todas las culturas. Los más importantes son la independencia plena del poder político y los sistemas estables de autogobierno universitario.

Hay que llevar a cabo una reforma radical y realista que permita implantar gradualmente en España un sistema universitario y científico de nivel internacional. El sistema nuevo debe basarse en sólidos precedentes y en experiencias históricas de éxito, tanto en España como en otros países. Los esfuerzos actuales para reformar un sistema burocrático, disfuncional, politizado y medieval recuerdan a los de Gorbachov por hacer más competitivo y abierto el sistema comunista.

Los datos siguientes ponen de manifiesto la importancia de la calidad de las universidades. Entre públicas y privadas, en España hay más de 70. En Suiza hay 10, todas públicas, de las que sólo cinco son investigadoras. España tiene 143.881 publicaciones en el Science Citation Index del Institute for Scientific Information (ISI), para el sexenio 1994-1999; Suiza tiene 89.176 en el mismo período. Sin embargo, el número de científicos suizos que figuran entre los autores más citados en las revistas científicas y técnicas internacionales se eleva a 74; España cuenta con 11 (datos del ISI). Por otra parte, el promedio de patentes suizas registradas por año en Estados Unidos en el quinquenio 1997-2001 fue de 1.519; el promedio español fue de 154 (United States Patent and Trademark Office, USPTO).

Estos datos demuestran la ceguera de los esfuerzos españoles a la hora de mejorar la calidad del gran número de universidades del país.

El objetivo español debe ser conseguir un número reducido de universidades investigadoras de nivel internacional, y este proceso debe comenzar con una universidad privada sin fines de lucro y con una universidad pública. Éstas serán como faros que iluminarán el camino a otras universidades.

A principios de los 50 se fabricaron los primeros coches en la fábrica SEAT de Barcelona; mientras, Corea estaba inmersa en una guerra que dejaría el país en ruinas. Hoy, Corea exporta coches con marcas y tecnología propias a todo el mundo, mientras que España ensambla los coches de las multinacionales extranjeras. Corea es, asimismo, una potencia mundial en electrónica.

Vista nocturna de la capital de Corea del Sur, Seúl.¿Qué es lo que explica estas diferencias? La visión y la voluntad de los dirigentes del Gobierno y la industria coreanos. Conscientes de las deficiencias de su sistema educativo, en el que las universidades estaban sujetas a rigideces tradicionales y al control de la burocracia estatal, a finales de los 60 el Gobierno decidió crear un nuevo instituto de postgrado especializado en ciencias aplicadas y tecnología, el Korea Advanced Institute of Science (KAIS).

El Gobierno de Corea pidió ayuda al americano; éste mandó a Fred Terman a evaluar el proyecto del KAIS y asesorar al Ejecutivo de Seúl. Terman (1900-1982) es universalmente reconocido como el padre de Silicon Valley y el principal impulsor de la excelencia mundial de la Universidad de Stanford.

En 1971 Terman presentó el informe final de su equipo a los gobiernos coreano y americano. Fue recibido muy favorablemente por Seúl, que puso en práctica sus recomendaciones con rapidez y entusiasmo. Nada se interpuso en el camino: ni tradiciones coreanas ancestrales e intocables, ni "títulos oficiales", ni que el Jefe del Estado firmara los nombramientos de catedráticos, ni otras lindezas medievales análogas. Una de las primeras y más fuertes recomendaciones de Terman fue que el KAIS se liberase del control del Ministerio de Educación.

Los graduados del actual Korea Advanced Institute of Science and Technology se emplean en todos los sectores de la economía nacional, pero sobre todo en la industria. Desde 1981 han fundado más de 360 compañías de alta tecnología.

En aproximadamente la misma época (a finales de los 60) comenzó el despegue de Irlanda, un país conocido durante siglos por su emigración, sus poetas trágicos, sus hambrunas y sus guerras civiles. En menos de una generación Irlanda ha logrado un PIB per cápita superior al de Alemania, Francia y el Reino Unido. Este milagro se basó, entre otras cosas, en la universalización de una educación universitaria gratuita de calidad. Y Gobierno, sindicatos y empresas acordaron un programa de austeridad fiscal, con impuestos corporativos bajos, y otras medidas para la atracción de inversión extranjera.

Los resultados fueron extraordinarios: hoy operan en Irlanda 9 de las 10 multinacionales farmacéuticas más importantes, 16 de las 20 mayores compañías de instrumentos médicos y 7 de las 10 primeras firmas de software.

Esto contrasta con lo que sucede en España, que cuenta con unos 23.000 becarios de investigación (estudiantes de doctorado e investigadores postdoctorales). Todos los estamentos implicados, el Gobierno, las universidades y los becarios, aceptan que la inmensa mayoría de estos futuros doctores están condenados al paro, a menos que el Gobierno les dé empleos públicos. Esto sólo puede hacerse estableciendo veinte universidades más o cuadriplicando el número de investigadores en el Consejo Superior de Investigaciones Científicas, o con una combinación de ambas medidas. De ahí las continuas manifestaciones reivindicativas de estos becarios, que reclaman, desde el comienzo de sus estudios de doctorado, contratos con el Ministerio de Educación con derecho a paro.

La ministra de Educación, Mercedes Cabrera.¿Es posible que España salga de este agujero? Por supuesto, si hay la visión y la voluntad política y empresarial de hacerlo. En primer lugar, hay que eliminar las leyes orgánicas sobre universidades, de una imbecilidad manifiesta, que recogen conceptos inútiles y medievales como el de título "oficial".

La primera universidad científica de Europa, Cambridge, ha nombrado a Emilio Artacho, un físico con el doctorado por la Universidad Autónoma de Madrid (UAM), senior lecturer y fellow de Clare Hall, uno de sus institutos de estudios avanzados. Cambridge no requirió que los gnomos de un ministerio "convalidasen" los títulos del Dr. Artacho para evaluarlo profesionalmente. Por el contrario, si la UAM quisiera ofrecer una cátedra a un doctor de Cambridge, el proceso no podría ni comenzar antes de que los gnomos del Ministerio de Educación español "convalidasen" el título de Cambridge, un proceso arcano que puede durar más de dos años.

Hace un año el Ministerio de Educación tenía en trámite la convalidación de más de 30.000 títulos universitarios. No es broma. Este ministerio controla, con normas del BOE, el progreso de un estudiante en sus estudios de doctorado para decidir si se le renueva la beca. Es verdad. No se les ocurre transferir a la universidad los fondos para que los profesores asuman su responsabilidad natural.

En segundo lugar, hay que abolir el estatus de funcionario para los profesores e investigadores de futura contratación. En una reunión reciente de la Fundación CYD, presidida por Ana Patricia Botín, cuyos objetivos son promover la mejora de la universidad en España, Lluís Ferrer, rector de la Autónoma de Barcelona, manifestó: "Es una vergüenza que todavía haya títulos universitarios oficiales". Luego, sobre el problema del funcionariado, dijo: "Tenemos un economista joven en la universidad que está considerado entre los tres mejores del mundo. Ha recibido tres ofertas de universidades americanas y, claro, no queremos perderlo. Con el sistema actual, su sueldo está fijado por su categoría en el escalafón, y no puede cambiarse".

El rector recurrió a empresarios catalanes, que pusieron sobre la mesa el dinero suficiente para garantizar la permanencia del joven economista. "Esto lo pude hacer una vez, pero claro, no podré resolver nuevos casos de esta manera", adviritó.

Otro ejemplo de los efectos perversos del funcionariado. Juan Ignacio Cirac (flamante premio Príncipe de Asturias de Investigación) es un físico español que hasta hace poco era profesor de la Universidad de Innsbruck. Considerado uno de los mejores teóricos de óptica cuántica, varias universidades públicas españolas trataron de contratarlo, pero no aceptó por la imposibilidad de negociar sobre su salario y otras condiciones. Cirac es ahora director del Instituto Max Planck de Óptica Cuántica, en Múnich.

O sea que, por un lado, no hay medios jurídicos ni económicos para contratar a las promesas jóvenes españolas y, por otro, se ponen 450 millones de euros para el Centro Nacional de Investigaciones Cardiovasculares (CNIC), bajo el mando de una figura de 63 años residente en Nueva York que no tiene ninguna posibilidad de crear una institución de excelencia, tarea que lleva décadas. Piensa volver a España dentro de dos o tres años para ponerse al frente de la institución. Entre tanto, el CNIC ha acordado transferir 5 millones de euros para financiar los Valentín Fuster Laboratories del hospital Monte Sinaí de Nueva York: el plan Marshall al revés.

Dado el marco legislativo actual, en que el Estado se reserva la facultad de otorgar los títulos universitarios oficiales, la única manera de despegar es creando una universidad privada investigadora de nivel internacional que otorgue exclusivamente títulos propios, siguiendo el precedente de escuelas de negocios como IESE, Icade y Esade, las cuales han alcanzado una reputación internacional. Esto les permite atraer estudiantes extranjeros, hasta el punto de que más del 60% de los graduados del IESE no son españoles.

Debido a sus altos costes, un país sólo puede mantener un número muy reducido de universidades investigadoras de nivel internacional. Para establecer una base científica sólida que sirva al despegue tecnológico de un país, dos o tres universidades son suficientes, como muestran los casos de Suiza, Irlanda y Corea.


JOSÉ CANOSA, doctor en Física Aplicada por la Universidad de Harvard, fue investigador en el Centro Científico de IBM en Palo Alto.
Copyright Libertad Digital SA. Juan Esplandiu 11-13, 28007 Madrid.

El ranking de Universidades de Jiao Tong

La Universidad Jiao Tong, de Shanghai, elabora desde hace unos años, una evaluación de las mejores universidades del mundo, desde la mejor hasta el puesto quinientos. No es el único ranking existente, pero es suficientemente valioso, considerando que los principales indicadores están basados en la calidad académica de sus educadores, y los logros de sus alumnos:

We rank universities by several indicators of academic or research performance, including alumni and staff winning Nobel Prizes and Fields Medals, highly cited researchers, articles published in Nature and Science, articles indexed in major citation indices, and the per capita academic performance of an institution.
For each indicator, the highest scoring institution is assigned a score of 100, and other institutions are calculated as a percentage of the top score. The distribution of data for each indicator is examined for any significant distorting effect; standard statistical techniques are used to adjust the indicator if necessary.
Scores for each indicator are weighted as shown below to arrive at a final overall score for an institution. The highest scoring institution is assigned a score of 100, and other institutions are calculated as a percentage of the top score. An institution's rank reflects the number of institutions that sit above it.
Esta es la tabla de criterios:

Criteria	Indicator	Code	Weight
Quality of Education	Alumni of an institution winning Nobel Prizes and Fields Medals	Alumni	10%
Quality of Faculty	Staff of an institution winning Nobel Prizes and Fields Medals	Award	20%
	Highly cited researchers in 21 broad subject categories	HiCi	20%
Research Output	Articles published in Nature and Science*	N&S	20%
	Articles in Science Citation Index-expanded, Social Science Citation Index	SCI	20%
Size of Institution	Academic performance with respect to the size of an institution	Size	10%
Total			100%

Si bien es conveniente leer todas las listas (las quinientas mejores, las cien mejores por continente), el cuadro que resume la participación de países, asociada con su población y su producto bruto nacional, permite tener una visión global de la distancia que separa al mundo desarrollado del resto de la comunidad internacional. No obstante, en el conjunto aparecen países cuya posición implica sin duda un esfuerzo notable por elevar la calidad de la educación y preparación de sus habitantes, así como la ausencia notable de otros:
Este es el cuadro comparativo:

	Top 100	Top 500	Population*	GDP*
USA	53.5%	33.4%	4.6%	28.4%
UK	10.9%	8.6%	0.9%	5.1%
Japan	5.9%	6.4%	2.0%	11.2%
Germany	5.0%	8.0%	1.3%	6.6%
Canada	4.0%	4.4%	0.5%	2.4%
France	4.0%	4.2%	0.9%	5.0%
Sweden	4.0%	2.2%	0.1%	0.8%
Switzerland	3.0%	1.6%	0.1%	0.9%
Netherlands	2.0%	2.4%	0.3%	1.4%
Australia	2.0%	3.2%	0.3%	1.5%
Italy	1.0%	4.6%	0.9%	4.1%
Israel	1.0%	1.4%	0.1%	0.3%
Denmark	1.0%	1.0%	0.1%	0.6%
Norway	1.0%	0.8%	0.1%	0.6%
Finland	1.0%	1.0%	0.1%	0.5%
Russia	1.0%	0.4%	2.3%	1.4%
Belgium	0.0%	1.4%	0.2%	0.9%
China	0.0%	1.8%	20.4%	4.7%
South Korea	0.0%	1.8%	0.8%	1.6%
Spain	0.0%	1.8%	0.7%	2.5%
Austria	0.0%	1.4%	0.1%	0.7%
China-Hong Kong	0.0%	1.0%	0.1%	0.4%
China-Taiwan	0.0%	1.0%	0.4%	0.7%
Brazil	0.0%	0.8%	2.9%	1.5%
Singapore	0.0%	0.4%	0.1%	0.3%
Argentina	0.0%	0.2%	0.6%	0.4%
Mexico	0.0%	0.2%	1.6%	1.6%
New Zealand	0.0%	1.0%	0.1%	0.2%
South Africa	0.0%	0.8%	0.7%	0.5%
Ireland	0.0%	0.6%	0.1%	0.4%
Czech	0.0%	0.2%	0.2%	0.3%
Greece	0.0%	0.4%	0.2%	0.5%
Hungary	0.0%	0.4%	0.2%	0.2%
Poland	0.0%	0.4%	0.6%	0.6%
India	0.0%	0.4%	17.0%	1.7%
Chile	0.0%	0.2%	0.3%	0.2%
Egypt	0.0%	0.2%	1.1%	0.2%

Universia apunta varios de los informes de evaluación existentes a nivel internacional, con mención especial de algunas existentes en el mundo iberoamericano. Puede consultarlos en su sitio.