- La separación conceptual entre hardware e instrucciones permitió tratar el software como bien independiente.
- Entre los 60 y 70 se profesionaliza: crisis del software, ingeniería del software y cobro separado.
- Procesos y modelos (cascada, incremental, espiral) sostienen la calidad de un producto intangible.
Entender cuándo y por qué empezamos a tratar el software como un producto exige recorrer un camino que arranca con cálculos mecánicos y llega hasta los servicios en la nube. En pocas décadas hemos pasado de máquinas enormes con instrucciones físicas a programas intangibles que se licencian, se actualizan y se consumen incluso como servicio.
En este viaje vas a ver, con ejemplos y contexto histórico, cómo se separaron las nociones de hardware e instrucciones, qué detonó la idea de vender software de forma independiente, cómo se profesionalizó su producción y qué modelos de negocio y licenciamiento han marcado la industria, desde el software propietario al libre y el SaaS.
De la máquina al programa: del mundo físico a las instrucciones
Durante siglos los cálculos se automatizaron con artefactos físicos: del ábaco y mecanismos analógicos a máquinas como el telar de Jacquard, donde las tarjetas perforadas definían el comportamiento sin separar del todo estructura e instrucciones.
La separación conceptual empezó a cuajar con Charles Babbage y Ada Lovelace. Babbage concibió la máquina analítica como dispositivo programable y Lovelace describió cómo distintas tarjetas contendrían programas distintos; el germen de que el qué hacer podía diferenciarse del con qué se ejecuta.
El gran salto llegó en el siglo XX con Alan Turing y la arquitectura de von Neumann. Turing formalizó una máquina universal capaz de ejecutar cualquier algoritmo; von Neumann planteó almacenar programas y datos en la misma memoria, permitiendo cambiar instrucciones sin tocar el hardware.
Ya en los 40 y 50, los ensambladores y los lenguajes de alto nivel como Fortran y Cobol consolidaron la idea: cualquiera podía escribir un programa que corriese sobre familias de máquinas compatibles sin rediseñar la parte física.
Qué es software y qué abarca realmente
La palabra software se populariza a finales de los 50, y bajo esa etiqueta se agrupa todo lo intangible que procesa un sistema informático: programas, datos y su documentación asociada. John W. Tukey ya utilizó el término en 1957 en este sentido.
Esta noción va más allá del ejecutable: también son software los manuales, especificaciones, datos a procesar e información de usuario. Es, en definitiva, aquello no físico que da sentido y funcionalidad al hardware.
Tradicionalmente se clasifica en tres grandes tipos: software de sistema (sistemas operativos, controladores, utilidades y servidores), software de programación (editores, compiladores, intérpretes, enlazadores, depuradores e IDE) y software de aplicación (de negocio, educativo, médico, CAD, bases de datos, videojuegos, telecomunicaciones, etc.).
De añadido a producto: eras del software y el punto de inflexión
En la primera era, 1950‑1965, el software se veía como un añadido. Se programaba con enfoque de codificar y corregir, con poca o nula documentación, métodos escasos y prueba y error. El desarrollo era a medida y el mismo autor solía usar y mantener su programa.
La segunda era, 1965‑1972, marca el cambio decisivo: aparecen la multiprogramación y los entornos multiusuario, despega el tiempo real y se popularizan los primeros sistemas de gestión de bases de datos. Sobre todo, comienza a percibirse el software como un producto que puede distribuirse a cientos o miles de clientes, y arranca la llamada crisis del software al dispararse la complejidad y los costes de mantenimiento.
En este contexto nace formalmente la ingeniería del software en 1968, la disciplina que aplica criterios de ingeniería al diseño, construcción, operación y mantenimiento de programas. También emerge el lenguaje C en 1972 para sistemas de propósito general, con eficiencia y capacidad de bajo nivel.
La tercera era, 1972‑mediados de los 80, trae sistemas distribuidos, redes locales y globales, y el uso de microprocesadores. Surgen microordenadores y la informática personal, además de lenguajes como Basic que democratizan el aprendizaje y la programación.
En la cuarta era, 1985‑2000, se impone el impacto colectivo: redes globales, arquitecturas cliente‑servidor, tecnologías orientadas a objetos, sistemas expertos, redes neuronales e IA. Aparece Java a inicios de los 90 con orientación a objetos y portabilidad, e hitos como Deep Blue evidencian el salto de capacidad de cómputo y software, y productos como Microsoft Encarta ilustran la comercialización del software.
La quinta era, 2000‑actualidad, explota la web, los móviles y el dato masivo. La omnipresencia de Internet y los smartphones acelera la entrega continua, los servicios en la nube y la inteligencia artificial, haciendo del software la pieza central de la economía digital.
En paralelo, fabricantes como IBM pasaron de vender máquina y programas como un todo a cobrar separadamente el hardware y el software, y florecieron compañías dedicadas exclusivamente a crear y distribuir productos software. Este paso afianzó el software como bien comercializable, con licencias, actualizaciones y soporte propio.
Cómo se fabrica un producto software: procesos y modelos
Construir un producto fiable exige un proceso. La captura y especificación de requisitos marca el inicio: hay que elicitar, acordar y documentar lo que el sistema debe hacer y bajo qué restricciones, produciendo el ERS o Especificación de Requisitos Software.
Tras ello llegan las fases de diseño, codificación, pruebas, instalación y mantenimiento. Aunque los nombres puedan variar, estas etapas existen de forma flexible según la metodología adoptada. Y aquí entran los modelos de proceso.
El modelo en cascada o lineal secuencial plantea pasar por fases con poca vuelta atrás, algo útil en proyectos rígidos y de requisitos claros, aunque rara vez se aplica en su pureza. La práctica real incorpora realimentación entre etapas para ajustar diseño y requisitos cuando aparecen ambigüedades o cambios.
Para tener en cuenta la naturaleza evolutiva del software surgieron los modelos iterativo incremental y espiral. El incremental propone entregar versiones parciales pero operativas, cada una construida sobre la anterior, de forma que el cliente obtiene utilidad temprana y se reduce el riesgo de grandes retrabajos.
El modelo espiral de Boehm combina iteración con gestión explícita de riesgos. Define regiones de tareas como comunicación, planificación, análisis de riesgos, construcción y obtención de feedback, y ha inspirado variantes como el espiral Win‑Win, que introduce negociación de condiciones de victoria para cliente y proveedor.
Las cifras del sector evidencian el reto: una parte notable de grandes proyectos fracasa o sufre fuertes retrasos. A menudo no por problemas técnicos, sino por metodologías deficientes o mala gestión de requisitos y riesgos, de ahí la importancia de procesos disciplinares.
Del código a la entrega: artefactos, pruebas e instalación
Durante la programación, el producto adopta diversos estados. El código fuente es lo que escribe el desarrollador. Un compilador puede transformarlo en código objeto intermedio, que más tarde se enlaza con bibliotecas para generar el ejecutable. Si el lenguaje se ejecuta de forma interpretada, puede no existir código objeto ni ejecutable previo.
La depuración acompaña a la codificación, y tras ella llegan las pruebas formales. Las pruebas unitarias validan piezas pequeñas; las de integración verifican que módulos y subsistemas interactúan correctamente. Más adelante es habitual un periodo de beta test en condiciones reales, para cazar defectos que escaparon a fases anteriores.
La instalación traslada el software al entorno de destino: despliegue, configuración y verificación de operatividad. En productos complejos puede requerir especialistas y topologías distribuidas, mientras que en software de consumo existen instaladores guiados para el usuario final.
Llega después la fase más larga: el mantenimiento. Abarca cambios correctivos, perfectivos, adaptativos y evolutivos. La calidad del diseño y la documentación condiciona su coste; con documentación pobre, mantener puede salir tan caro como rehacer desde cero.
La evolución continua: leyes de Lehman
El software que se usa cambia o se degrada. Las leyes de la evolución de Lehman condensan observaciones sobre sistemas en uso: el cambio es continuo, la complejidad tiende a crecer salvo que inviertas en controlarla y la funcionalidad debe ampliarse para mantener la satisfacción del usuario.
Entre otras, recogen que la calidad disminuye salvo adaptación, que los procesos de evolución incorporan realimentación y que la organización alcanza niveles de desarrollo relativamente constantes. Estas hipótesis ayudan a planificar versiones y presupuestar esfuerzo en mantenimiento.
Requisitos: el corazón de lo que se construye
La ingeniería de requisitos aporta métodos y herramientas para comprender el problema, validar con el cliente y garantizar especificaciones. Se distinguen requisitos de usuario y de sistema, funcionales, no funcionales y del dominio, con subtipos como los organizativos o los externos legales y éticos.
Buenas prácticas incluyen definir el universo de discurso, preparar talleres de elicitación, priorizar objetivos y detectar ambigüedades. Hay múltiples enfoques: desde léxicos extendidos y escenarios hasta metodologías más ortodoxas cubiertas por estándares como IEEE 830‑1998 o marcos de mejora tipo CMMI.
Modelos de negocio y licenciamiento: del propietario al libre y el SaaS
Cuando el software se consolidó como producto, surgieron modelos de licenciamiento diversos. El licenciamiento propietario define condiciones de uso, cesiones de derechos y ámbito de validez. En contraste, permiten copiar, modificar y redistribuir, dando lugar a comunidades y ecosistemas abiertos.
Desde los 80 y 90 hubo guerras de estándares en sistemas operativos y plataformas: Unix y sus variantes, Windows, el auge del software libre con el proyecto GNU y Linux, y el refuerzo del papel del usuario eligiendo no solo hardware, sino también sistema y aplicaciones.
El salto más reciente en modelo de entrega es el software como servicio, SaaS. Sus raíces se remontan al tiempo compartido de los 60 con grandes sistemas, pero la popularidad moderna llega con Internet y la nube. Antes, en los 80, aparecieron los primeros CRM compartiendo la información del cliente, y en los 90 el crecimiento del software superó a veces al hardware disponible, empujando a volver a alojamientos centralizados.
Con el nuevo milenio, la combinación de web ubicua y datos en la nube hizo del SaaS una opción dominante: pagos por suscripción, actualizaciones continuas, escalado elástico y acceso independiente del dispositivo. Hoy convive con licencias tradicionales, modelos freemium, micropagos y publicidad.
Impacto económico y social: por qué importó convertirlo en producto
Tratar el software como producto independiente permitió especialización, economías de escala y cadenas de valor específicas. Empresas de software puro pasaron a valer más que muchos fabricantes de hardware, y los ciclos de vida, APIs y frameworks facilitaron ecosistemas completos de terceros.
Pero también afloraron riesgos. Un mal desarrollo puede tener costes millonarios o consecuencias graves: desde errores en sistemas de reservas que provocan pérdidas, a fallos en entornos críticos con alarmas falsas o decisiones equivocadas que impactan a personas. La profesionalización del proceso no es un capricho, es una necesidad.
En respuesta, la industria ha reforzado buenas prácticas, pruebas rigurosas y gestión de riesgos. En entornos de alto riesgo o seguridad, modelos como el espiral con foco en riesgos y estándares de calidad son especialmente adecuados; en otros, los enfoques iterativos e incrementales equilibran velocidad y control.
Para mantenerse útil, el producto software debe evolucionar con su entorno, adaptarse a nuevas plataformas, mejorar rendimiento, incorporar funcionalidades y responder a cambios regulatorios. Y, por supuesto, cuidar la documentación para que el mantenimiento no se convierta en un laberinto.
Todo este recorrido histórico, técnico y económico explica por qué hoy el software se vende, se licencia o se ofrece como servicio, con métricas de éxito, soporte, versiones y retirada planificada. La distinción hardware‑software es la base de cómo concebimos y comercializamos la tecnología moderna.
Mirando atrás se entiende que la transición a software como producto se fraguó entre los 60 y los 70, impulsada por la complejidad creciente, la necesidad de metodologías, el cobro separado frente al hardware y el nacimiento de empresas específicas. Desde entonces, lenguajes como Fortran, Cobol, C, Basic o Java, hitos como los microprocesadores, Internet, la informática personal y la IA, y modelos de proceso como cascada, incremental y espiral han consolidado una industria que hoy también vive en la nube y en el móvil.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.