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.