Historia de la ingeniería del software

Desde sus inicios en la década de 1940, el campo del desarrollo de software ha progresado hasta transformarse en una disciplina que abarca la creación y el mantenimiento de programas, el diseño de patrones, así como la optimización del rendimiento y la calidad. La noción de "calidad" se relaciona con diversos aspectos como la facilidad de mantenimiento, estabilidad, velocidad, legibilidad y seguridad del software, entre otros. También engloba cualidades más subjetivas, como una interfaz gráfica intuitiva, la idoneidad de la solución ofrecida y la satisfacción del usuario final o cliente correspondiente.

IBM 360 mainframe

El desarrollo de software de primera categoría implica diversos procesos, como la planificación general, la aplicación de principios y prácticas sólidas para la codificación y la evaluación de las soluciones implementadas. Además, abarca aspectos más amplios como la gestión del ciclo de vida del software, la adecuada configuración del equipo de trabajo, la planificación y cumplimiento de plazos, la cultura laboral, así como las políticas de contratación. Todos estos elementos son fundamentales en el ámbito de la ingeniería de software.

Visión general editar

Hay una gran cantidad de áreas en las que es notable la evolución de la ingeniería de software:

  • Surge como profesión: A principios del año 1980,[1]​ emerge la ingeniería de [software].[2]
  • Procesos: Los procesos se han convertido en una gran parte de la ingeniería de software y son aclamados por su potencial para mejorar el software, y duramente criticados por su potencial para constreñir a los programadores.
  • Coste del hardware: El coste relativo del software frente al hardware ha cambiado sustancialmente en los últimos 60 años. Cuando los mainframes eran costosos y requerían una gran cantidad de personal de soporte, las pocas organizaciones que los compraban también tenían los recursos para financiar proyectos de ingeniería de software a la medida, grandes y costosos. Los computadores son ahora mucho más numerosos y mucho más potentes, lo que tiene varios efectos en el software. El mercado más grande puede soportar grandes proyectos para crear software comercialmente, como los hechos por empresas como Microsoft. Las máquinas baratas permiten a cada programador tener un terminal capaz de una compilación bastante rápida. Los programas en cuestión pueden usar técnicas como la recolección de basura, que los hacen más fáciles y rápidos de escribir. Por otro lado, menos organizaciones están interesadas en emplear programadores para grandes proyectos de software a medida, y en su lugar utilizan software comercial tanto como sea posible.

La era pionera editar

El desarrollo más importante fue que las nuevas computadoras que salían —cada uno o dos años— hacían obsoletas a las ya existentes. Los ingenieros de software tenían que volver a escribir todos sus programas para que se ejecutaran en las nuevas máquinas. Los programadores no tenían equipos en sus escritorios y tenían que ir a la “sala de máquinas”. Las tareas se ejecutaban al inscribirse para el tiempo de la máquina o por el personal operativo. Las tareas se ejecutaban utilizando tarjetas perforadas como entrada en el lector de tarjetas de la máquina y se esperaba a los resultados devueltos en la impresora.

El campo era tan nuevo que la idea de gestión por horario era inexistente. Era casi imposible hacer predicciones de la fecha de finalización del proyecto. El hardware del computador era específico para la aplicación. Las tareas científicas y de negocios necesitaban diferentes máquinas. Debido a la necesidad de traducir frecuentemente el software viejo para atender las necesidades de nuevas máquinas, se desarrollaron lenguajes de orden superior como FORTRAN, COBOL y ALGOL. Vendedores de hardware regalaban sistemas de software gratis, puesto que no se podía vender hardware sin software. Algunas compañías vendían el servicio de programación de software personalizado, pero no había empresas especializadas en software.

La noción de reutilización floreció. A medida que el software fue haciéndose libre, las organizaciones de usuarios comúnmente lo liberaron. Grupos como Share, el grupo de usuario científico de IBM, ofrecían catálogos de componentes reutilizables. La academia todavía no enseñaba los principios de las ciencias de la computación. La programación modular y la abstracción de datos ya se utilizaban en programación.

De 1950 a 1960: Los orígenes editar

El término ingeniería de software se acuñó por primera vez entre la década de 1950 y principios de los años 1960. Los programadores siempre habían sabido sobre ingenierías civiles, eléctricas y de computadores, y debatían qué podría significar la ingeniería para el software.

El Comité de Ciencias de la OTAN patrocinó dos conferencias[3]​ sobre ingeniería de software en 1968 (Garmisch, Alemania — ver informe de la Conferencia) y en 1969, que dio al campo su impulso inicial. Muchos creen que estas conferencias marcaron el inicio oficial de la profesión de la ingeniería de software. El software, como se ha visto, no surge con los equipos electrónicos -aunque es con ellos que adopta el nombre-, ya está presente desde el empleo de ábacos o sumadoras mecánicas. Sin embargo, en estos casos, el software no se encuentra incorporado en el equipo.

De 1960 a 1980: La crisis del software editar

La ingeniería de software fue estimulada por la llamada crisis del software de las décadas de 1960, 1970 y 1980, que identifica muchos de los problemas de desarrollo de software. Muchos proyectos de software sobrepasaron el presupuesto y el tiempo estimados. Algunos proyectos causaron daños a la propiedad, otros proyectos causaron pérdidas de vidas.[1] La crisis del software originalmente se definió en términos de productividad, pero evolucionó para enfatizar la calidad. Algunos utilizan el término de crisis del software para referirse a su incapacidad de contratar programadores suficientemente calificados.

  • Costo y desbordamiento de presupuesto: El sistema operativo OS/360 fue un ejemplo clásico. Este proyecto que duró una década[cita requerida], desde los años 1960, finalmente produjo uno de los más complejos sistemas de software de ese tiempo. El OS/360 fue uno de los primeros de grandes proyectos de software (1000 programadores).[cita requerida] En el libro The Mythical Man-Month, Fred Brooks afirmó que cometió un error multimillonario por no desarrollar una coherente arquitectura de software antes de iniciar el desarrollo.
  • Daños a la propiedad: Los defectos de software pueden causar daños a la propiedad. Escasa seguridad de software permite a hackers robar identidades, costando tiempo, dinero y reputaciones.
  • Vida y muerte: Los defectos de software pueden matar. Algunos sistemas embebidos en máquinas de radioterapia fallaron de una manera tan catastrófica que administraron dosis letales de radiación a pacientes. La más famosa de estas fallas es el incidente de Therac-25.

Peter G. Neumann ha mantenido una lista contemporánea de problemas de software y desastres.[1] La crisis del software ha estado desvaneciéndose de vista, porque psicológicamente es extremadamente difícil permanecer en modo de crisis durante un período prolongado (más de 20 años). No obstante, el software - especialmente el software incorporado en tiempo real - sigue siendo arriesgado y omnipresente, y es crucial no ceder en complacencias.

En los últimos 10-15 años, Michael A. Jackson ha escrito extensamente sobre la naturaleza de la ingeniería del software, ha identificado la fuente principal de sus dificultades como la falta de especialización y ha sugerido que sus marcos de problema proporcionan la base para una “práctica normal” de la ingeniería del software, un requisito previo si la ingeniería de software quiere convertirse en una ciencia de ingeniería. (Michael Jackson, “Ingeniería e ingeniería de Software” en S Nanz ed, el futuro de la Ingeniería de Software, Springer Verlag 2010; Michael Jackson, marcos de problema: Análisis y estructuración de los problemas de desarrollo de Software; Addison-Wesley, 2001).

De 1985 a 1989: Decaimiento de la creación de software editar

Durante décadas, solucionar la crisis del software fue de suma importancia para investigadores y empresas productoras de herramientas de software. El costo de propiedad y mantenimiento del software en la década de 1980 fue dos veces más caro que el propio desarrollo del software. Durante la década de 1990, el costo de propiedad y mantenimiento aumentó en un 30% con respecto a la década anterior. En 1995, las estadísticas mostraron que la mitad de los proyectos de desarrollo encuestados estaban operacionales, pero no eran considerados exitosos. El proyecto de software sobrepasa su estimación en tiempo en el 50%. Las tres cuartas partes de todos los grandes productos de software son entregados al cliente con tales fallas que no son usados en absoluto, o no cumplen con los requerimientos del cliente.

Proyectos de software editar

Aparentemente, cada nueva tecnología y práctica de la década de 1970 a la de 1990 fue pregonada como una bala de plata para resolver la crisis del software. Herramientas, disciplina, métodos formales, proceso, y profesionalismo fueron promocionados como balas de plata:

  • Herramientas: Especialmente enfatizaba que las herramientas: programación estructurada, programación orientada a objetos, herramientas CASE, el lenguaje de programación Ada, documentación y estándares eran promocionados como balas de plata.
  • Disciplina: Algunos expertos argumentaron que la crisis del software era debido a la falta de disciplina de los programadores.
  • Métodos formales: Algunos creían que si las metodologías de ingeniería formal fueran aplicadas al desarrollo de software, entonces la producción de software sería una industria tan predecible como otras ramas de la ingeniería. Abogaron que había que demostrar que todos los programas eran correctos.
  • Proceso: Muchos abogaron el uso de procesos definidos y metodologías como el Modelo de Capacidad y Madurez.
  • Profesionalismo: Esto llevó a trabajar en un código de ética, licencias y profesionalismo.

En 1986, Fred Brooks publicó su artículo No hay balas de plata, argumentando que ninguna tecnología individual o práctica jamás haría una mejora de 10 veces en la productividad dentro de 10 años.

El debate sobre las balas de plata rugía en la década siguiente. Defensores de Ada, los componentes y procesos continuaron años argumentando que su tecnología favorita sería una bala de plata. Los escépticos no estuvieron de acuerdo. Finalmente, casi todo el mundo aceptó que nunca se encontrará ninguna bala de plata. Sin embargo, afirmaciones sobre balas de plata saltarán de vez en cuando, aún hoy en día.

Algunos interpretan que no hay balas de plata significa que la ingeniería de software ha fracasado. Sin embargo, con otras lecturas, Brooks va a decir, "seguramente haremos progresos sustanciales en los próximos 40 años; un orden de magnitud en más de 40 años es casi mágico... ".

La búsqueda de una única clave para el éxito nunca funcionó. Todas las prácticas y tecnologías conocidas solo han hecho mejoras en productividad y calidad. A pesar de todo, tampoco hay balas de plata para cualquier otra profesión. Otros interpretan no hay balas de plata como prueba de que la ingeniería de software finalmente ha madurado y reconoce que los proyectos de éxito son debido al duro trabajo.

Sin embargo, podría decirse también que, en la actualidad, hay una gama de balas de plata, incluyendo metodologías livianas, calculadoras de hoja de cálculo, navegadores personalizados, motores de búsqueda en sitio, generadores de reportes de base de datos, editores de código y pruebas de diseño integrados, con memoria/diferencias/deshacer y tiendas especializadas que generan software de nicho, como sitios Web de información, a una fracción del costo de desarrollo de un sitio web totalmente personalizado. Sin embargo, el campo de la ingeniería del software parece demasiado complejo y diverso para una única "bala de plata" que sirva para mejorar la mayoría de los problemas, y cada problema representa solo una pequeña porción de todos los problemas de software.

De 1990 a 1999: Prominencia de Internet editar

El auge de la Internet condujo a un rápido crecimiento en la demanda de sistemas internacionales de despliegue de información y correo electrónico en la World Wide Web. Los programadores debían manejar ilustraciones, mapas, fotografías y otras imágenes, más animación sencilla, a un ritmo nunca antes visto, con pocos métodos conocidos para optimizar la visualización/almacenamiento de imágenes (como el uso de imágenes en miniatura).

El crecimiento del uso del navegador, corriendo en el lenguaje HTML, cambió la manera en que estaba organizada la visualización y la recuperación de la información. Las amplias conexiones de red condujeron al crecimiento y la prevención de virus informáticos internacionales en computadores con MS Windows, y la gran proliferación de correo basura se convirtió en una cuestión de diseño importante en sistemas de correo electrónico, inundando canales de comunicación y requiriendo de precalificación semiautomatizada. Sistemas de búsqueda de palabra clave evolucionaron en buscadores web, y muchos sistemas de software tuvieron que ser rediseñados, para la búsqueda internacional, dependiendo de las técnicas de posicionamiento en buscadores (SEO).

Fueron necesarios sistemas de traducción de lenguaje natural humano para intentar traducir el flujo de información en múltiples idiomas extranjeros, con muchos sistemas de software siendo diseñados para uso multilenguaje, basado en conceptos de diseño de traductores humanos. Típicas bases de usuarios de computadora con frecuencia pasaron de cientos o miles de usuarios a muchos millones de usuarios internacionales.

De 2000 al presente: Metodologías ligeras editar

La creciente demanda de software en pequeñas empresas ha llevado a la necesidad de métodos de desarrollo más eficientes y económicos. Una de estas tendencias ha sido el uso de prototipos rápidos, que buscan desarrollar un software funcional lo más pronto posible. Esto ha llevado al surgimiento de metodologías ligeras, como la programación extrema (XP), que tratan de simplificar el proceso de desarrollo de software, incluyendo la recolección de requerimientos y las pruebas de confiabilidad. Sin embargo, los sistemas de software muy grandes siguen utilizando metodologías más tradicionales y documentadas, mientras que los sistemas más pequeños optan por métodos más sencillos y rápidos para la gestión del desarrollo y mantenimiento de software, el almacenamiento y recuperación de información y la visualización.

Tendencias actuales en la ingeniería de software editar

La ingeniería de software es una disciplina joven y aún está en desarrollo. Las direcciones en que la ingeniería de software se está desarrollando incluyen:

Aspectos
Los aspectos ayudan a los ingenieros de software a lidiar con los atributos de calidad al proporcionar herramientas para añadir o quitar código repetitivo de muchas áreas en el código fuente. Los aspectos describen cómo todos los objetos o funciones deben comportarse en circunstancias particulares. Por ejemplo, los aspectos puede agregar control de depuración, registro o bloqueo en todos los objetos de un tipo particular. Los investigadores actualmente están trabajando para comprender cómo utilizar aspectos para diseñar el código de propósito general. Conceptos relacionados incluyen programación generativa y plantillas.
Ágil
El desarrollo ágil de software guía a los proyectos de desarrollo de software que evolucionan rápidamente con cambiantes expectativas y mercados competitivos. Los proponentes de este método creen que procesos pesados, dirigidos por documentos (como TickIT, CMM e ISO 9000) están desapareciendo en importancia.[cita requerida] Algunas personas creen que las empresas y agencias exportan muchos de los puestos de trabajo que pueden ser guiados por procesos pesados.[cita requerida] Conceptos relacionados incluyen la programación extrema, scrum y lean software development.
Experimental
La ingeniería de software experimental es una rama de la ingeniería de software interesada en la elaboración de experimentos sobre el software, en la recolección de datos de los experimentos y en la elaboración de leyes y teorías desde estos datos. Los proponentes de este método defienden que la naturaleza del software es tal que podemos hacer avanzar el conocimiento en software a través de solo experimentos.[cita requerida]
Model-driven
El diseño manejado por modelos desarrolla modelos textuales y gráficos como artefactos primarios de diseño. Hay disponibles herramientas de desarrollo que usan transformación de modelo y generación de código para generar fragmentos de código bien organizado que sirven como base para producir aplicaciones completas.
Líneas de productos de software
Las líneas de producción de software son una forma sistemática para producir familias de sistemas de software, en lugar de crear una sucesión de productos completamente individuales. Este método destaca una extensiva, sistemática, reutilización de código formal, para intentar industrializar el proceso de desarrollo de software.

El futuro de la Conferencia de ingeniería de Software (FOSE),[4]​ celebrada en ICSE 2000, documenta el estado del arte de SE en 2000 y lista muchos problemas a resolver en la próxima década. El FOSE sigue la pista de las conferencias ICSE 2000[5]​ y el ICSE 2007[6]​ y también ayudar a identificar el estado del arte en ingeniería de software.

La ingeniería de software hoy editar

La profesión está tratando de definir sus límites y contenido. El Software Engineering Body of Knowledge SWEBOK ha sido presentado como un estándar ISO durante 2006 (ISO/IEC TR 19759).

En 2006, la revista Money y Salary.com calificaron la ingeniería de software como el mejor trabajo en Estados Unidos en términos de crecimiento, paga, niveles de estrés, flexibilidad en horas y medio ambiente de trabajo, creatividad y lo fácil que es entrar y avanzar en el campo.[7]

Figuras prominentes en la historia de la ingeniería de software editar

  • Charles Bachman (nacido en 1924) es particularmente conocido por su trabajo en el área de bases de datos.
  • Laszlo Belady (nacido en 1928) el redactor jefe de la IEEE Transactions on Software Engineering en la década de 1980
  • Fred Brooks (nacido en 1931) conocido por el desarrollo del OS/360.
  • Peter Chen conocido por el desarrollo del modelo entidad-relación.
  • Edsger Dijkstra (1930–2002) desarrolló el marco para la programación adecuada.
  • David Parnas (nacido en 1941) desarrolló el concepto de ocultamiento de información en la programación modular.
  • Michael A. Jackson (nacido en 1936) experto en Ingeniería de software responsable del método de diseño de programa JSP; el método de desarrollo de sistema JSD (con John Cameron); y marcos de problema para el análisis y estructuración de los problemas de desarrollo de software.

Referencias editar

  1. "Software engineering ... has recently emerged as a discipline in its own right." Sommerville, Ian (1985s) [1982]. Software Engineering. Addison-Wesley. ISBN 0-201-14229-5. 
  2. Soteldo, Oriana. Definición de Software. Consultado el 12 de noviembre de 2017. 
  3. The NATO Software Engineering Conferences
  4. «Future of Software Engineering». Archivado desde el original el 23 de marzo de 2012. Consultado el 19 de agosto de 2012. 
  5. ICSE 2000
  6. ICSE 2007
  7. Kalwarski, Tara; Daphne Mosher, Janet Paskin and Donna Rosato (2006). «Best Jobs in América». MONEY Magazine. CNN. Archivado desde el original el 24 de octubre de 2007. Consultado el 20 de abril de 2006.  , "MONEY Magazine and Salary.com researched hundreds of jobs, considering their growth, pay, stress-levels and other factors. These careers ranked highest. 1. Software Engineer..."

Véase también editar

Enlaces externos editar