La teoría está cerca de los científicos y matemáticos. Las máquinas y circuitos, cerca de los ingenieros y técnicos. Los lenguajes de programación, sistemas operativos, e ingeniería de software, cerca de los computines.

Ahora recién, en la parte cinco de esta serie, vamos a comenzar a llegar a la sociedad. Con la interfaz de usuario.

Para darle instrucciones a la máquina, con estos lenguajes que ya hemos nombrado, en un principio había que literalmente recablearla, de manera que la lógica formase parte de sus principios.

Más adelante, se incorporaron interruptores, donde el operador iba seteando instrucción por instrucción.

Vinieron entonces las tarjetas perforadas, que nos acompañaron hasta los setenta. Los programadores preparaban cajas de tarjetas que eran recibidas por un operador del computador. Este operador iba entregando al computador cada trabajo (job) secuencialmente, y luego de varias horas se podía ir a buscar el resultado (o el error dado por la máquina). Estos jobs tenían control total sobre la máquina.

Llegaron entonces, con el desarrollo de los sistemas operativos, los ambientes interactivos, con teclado y pantalla. Los programadores de esa época estaban maravillados de poder apretar la tecla ‘a’ y ver inmediatamente un caracter ‘a’ en pantalla.

Esta forma de interactuar era por medio de una interfaz de línea de comando (shell), como la bien conocida de MS-DOS. Si nuestros padres alcanzaron a ver tarjetas perforadas (yo nunca he visto una), fuimos nosotros quienes podemos decir que trabajamos con línea de comando.

Esta shell recibe los comandos de la persona que está usando el computador (desaparece o disminuye el rol de un operador), y los transfiere a la máquina, por ejemplo así:

curl “http://en.wikipedia.org/wiki/Pipeline_(Unix)” | \
sed ‘s/[^a‑zA‑Z ]/ /g’ | \
tr ‘A‑Z ’ ‘a‑z\n’ | \
grep ‘[a‑z]’ | \
sort ‑u | \
comm ‑23 — /usr/dict/words

Esa instrucción encadena seis programas.

En los ochenta, sobretodo gracias a Apple, llegan las interfaces gráficas de usuario (GUI). Aparecen elementos (widgets) tales como botones, ventanas, cuadros de texto, barras de desplazamiento, cursor y mouse. Como que recién desde este momento, podemos decir que la interfaz de usuario está a un nivel de acceso masivo al público.

Ahora vemos terminales de autoconsulta (TAC), kioskos virtuales y sistemas de búsqueda de novios en las multitiendas, por ejemplo. En casi todos los puestos de trabajo hay un computador de escritorio con aplicaciones que usan GUI.

Esto ha sido posible gracias al poder de las tarjetas de video, evolución de los monitores (de monocromáticos a VGA y superiores), y capacidades de los sistemas operativos.

Una de las gracias de Microsoft es que universalizó la GUI. Todos esperamos ver un menú en nuestras aplicaciones donde la ayuda está a la derecha y aparece apretando F1. Todos esperamos que exista un menú ‘archivo’ con opciones abrir, guardar, imprimir. Esta consistencia en la interfaz ha logrado masificar el uso de estas aplicaciones.

Sigamos. A finales de los noventa, comenzaron las aplicaciones web. En un principio emularon las aplicaciones con ventanas, con botones, campos de texto y barras de desplazamiento, pero la arquitectura web había restringido la interactividad al exigir comunicación con un servidor para refrescar la página.

Apareció entonces el concepto de las aplicaciones dinámicas, con el uso de los lenguajes de script, que se ejecutan en el cliente web. Y lo último de la moda es AJAX, que simplemente es una técnica donde se puede actualizar una aplicación web sin necesidad de refrescar la página completa.

Hoy usamos estas aplicaciones para ver nuestra cuenta corriente, para pagar nuestras cuentas, para mandar correo electrónico, para escribir blogs, para subir fotos, para consultar enciclopedias, para hacer búsquedas. Son realmente masivas, de uso diario y frecuente.

¿Qué vendrá después? Saldremos de las superficies bidimensionales de las pantallas, con tecnología 3D; los dispositivos de bolsillo como los PDA serán cada vez más comunes; eventalmente integraremos tecnología en organismos biológicos.

Estuvo muy bonito eso de tener lenguajes para poder pedirle a la máquina que haga lo que uno quiera. ¿Qué se le puede pedir a la máquina que haga?

En un principio, calcular. Los científicos querían calcular trayectoras, para aplicaciones militares / aeroespaciales, modelos estocásticos, modelos de optimización, simulaciones, fuerzas y tensiones en estructuras.

Pronto se dieron cuenta de algo. El hardware evolucionaba mucho más rápido que lo que le podían sacar provecho con el software. ¿Por qué? Porque el desarrollo de aplicaciones no le alcanzaba el ritmo.

Los sintomas: Proyectos que no lograban sus metas de tiempo, costo y calidad. Proyectos cancelados, abortados, o que entregaron bastante menos de lo prometido.

Era necesario reconocer que las prácticas de desarrollo a la fecha no eran disciplinadas. En el tiempo de los gurús, unos pocos especialistas realmente eran capaces de programar las máquinas. Hacer depuración era todo un arte. Y nadie ‘de la oficina’ era capaz de intervenir en esa área técnica.

Pasó el tiempo de los gurús, había más programadores, las máquinas eran más baratas, pero el estado del arte de los equipos de programadores no estaba a la altura de las necesidades. Pronto aparecieron proyectos con decenas, cientos, y miles de participantes, y todos se preguntaban ¿cómo administro estos proyectos para lograr las metas? En 1968 a esto se le denominó la Crisis del Software.

Los interesados en superar esta situación comenzaron a trabajar en lo que hoy se conoce como ingeniería de software.

¿De qué se hace cargo esta disciplina? De dos cosas: a) de los aspectos técnicos de desarrollar software. b) de los aspectos administrativos de desarrollar software.

Aspectos técnicos

Responde a las siguientes preguntas: ¿cómo entender lo que necesita el cliente? ¿cómo especificar estas necesidades de una manera tal que los especialistas puedan desarrollar software? ¿cómo diseñar software a partir de estas especificaciones? ¿cómo desarrollar software? ¿cómo verificarlo y validarlo? ¿cómo ponerlo en marcha? ¿cómo operarlo y mantenerlo?

Esas preguntas abarcan el ciclo de vida del software. Para realizar esas actividades, nacieron los procesos de software, y se adaptaron los diversos paradigmas de desarrollo (estructurado, orientado a objetos, funcional, etc.).

De particular interés hoy es un tema de la arquitectura de software: el reuso. ¿Cómo organizar el software en diversas unidades (componentes), de tal manera de no tener que escribirlas siempre desde cero? Las respuestas sucesivas fueron el linkeo estático, el linkeo dinámico (las DLL), frameworks como MFC, y luego elementos más autónomos, como OLE y COM. Con la llegada de las redes, comenzó a nacer el concepto de componentes distribuidos, con RPC, CORBA, y DCOM. Todo esto evolucionó a lo que hoy conocemos como arquitectura de servicios, con .NET y J2EE.

Aspectos administrativos

Son más genéricos, y responden a preguntas tales como ¿cómo administro uno o varios proyectos? ¿cómo capacito al personal? ¿cómo gestiono la calidad? ¿cómo administro las distintas versiones de lo que se está desarrollando? ¿cómo hago monitoreo y control de los proyectos? ¿cómo adminsitro a proveedores?

En los ’80 se consensuó que el problema central en la crisis del software es administrativo, no técnico. Por ello se desarrolló lo que hoy se conoce como CMMI, que es un modelo de buenas prácticas para obtener una unidad de desarrollo de software cuyos proyectos terminan en tiempo y costo, a un nivel de calidad conocido y predecible, y que mejora en el tiempo.

Todo lo conversado hoy está sistematizado en lo que se llama el Software Engineering Body of Knowledge.

En la medida que todos tienen un computador a la mano, y que se puede conseguir herramientas de desarrollo gratuitas, prácticamente cualquiera puede ser hoy desarrollador de software. Un profesor de la universidad me decía una vez que, cuando le contaba a un apoderado del colegio que él trabajaba en el Departamento de Ciencia de la Computación, el otro respondió “ah, sí, mi hijo de segundo medio hace lo mismo”.

Este tipo de posibilidades abiertas hace que la superación de la crisis del software aún no sea una realidad para la mayoría de las empresas que desarrollan o mandan a desarrollar software.