[en] The term "software engineering" began to be used towards the end of the 1960s to refer to the area of knowledge being developed around the problems with the software of the time. During that period, the spectacular growth in demand for increasingly complex computer systems, associated with an immature computing sector (connected entirely to electronics) and with a lack of methods and resources, led to what is known as the "software crisis" (a phrase coined by Edsger Dijkstra) from 1965 to 1985. During this time, many important projects far exceeded their budgets and estimated deadlines, some of which were so critical (airport control systems, medical equipment, etc.) that their implications extended far beyond the million-pound losses that they generated. The software crisis ended not so much because of improvements in project management but partly because it is unthinkable to be in a crisis for more than twenty years and partly because progress was being made in design processes and methodologies. Thus, between 1985 and the present, tools, methodologies and technologies emerged that claimed to be the definitive solution to the problem of planning, cost prevision and quality assurance in software development. Of these tools, structured programming, object-oriented programming, aspect-oriented programming, CASE tools, ADA programming language, documentation, standards, CORBA, web services, and UML language, among others, were all acclaimed at the time as being the solution to software engineering problems, the so-called "silver bullet". And each year, new ideas and initiatives emerge with this aim. Naturally, some people will have laid the blame on programmers for their undisciplined or anarchic developments. Ignorance and the occasional unusual case merged to create a false image of the programmer that still exists even today. Although they are often the "sufferers" of some of these methodologies or their poor implementation, it is logical that, as an active participant of the project, more recent methodologies are beginning to take them into account. Alongside the development of tools, efforts have been made to incorporate formal methods into software development, based on the argument that if developments are formally tested to do what is required, the software industry will be as predictable as other branches of engineering. Besides Métrica v3 (launched by the Secretariat of the Higher Computing Council) and extreme programming, which we will see in more detail later on, there are many other methodologies and processes, such as RUP (Rational Unified Process, developed by Rational Software Corp., now a division of IBM), SSADM (Structured Systems Analysis and Design Methodology, developed by the British Government) or the method of evaluating the development capacity of equipment or companies known as CMMI (Capability Maturity Model Integration). Cost prediction methods like COCOMO and function points are also often used. There have been many recent initiatives in this field and they extend to the entire software process. The more academically-minded favour a structure of components, services and object-oriented or aspect-oriented in implementation, but the development of tools to help us represent and share these designs is just as relevant, as is appreciating the effort and value added to the finished product. It is truly a fascinating area in the sense that seminars, leading consultants and small laboratories are all innovating day in, day out to come up with good ideas.

[es] El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985. Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados; algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, etc.) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y en las metodologías. Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, la previsión de costes y el aseguramiento de la calidad en el desarrollo de software. Entre las herramientas, la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada "bala de plata" (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello. Por supuesto, también ha habido quien ha culpado a los programadores por su indisciplina o anarquía en sus desarrollos. La ignorancia y algunos casos excéntricos contribuyeron a crear una imagen falsa del programador, que hoy en día aún perdura. Aunque muchas veces él es el "sufridor" de alguna de estas metodologías o de una pobre implementación de las mismas, parece lógico que, como participante activo en el proyecto, las metodologías más modernas empiecen a tenerle más en cuenta. En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería. Entre las metodologías y los procesos, además de Métrica v3 (promovida por la Secretaría del Consejo Superior de Informática) y eXtreme Programming, que veremos en detalle más adelante, destacan muchos otros como RUP (rational unified process, desarrollado por Rational Software Corp., ahora una división de IBM), SSADM (structured systems analysis and design methodology promovido por el Gobierno británico) o el método de evaluación de la capacidad de desarrollo de los equipos o empresas conocido como CMMI (capability maturity model integration). Paralelamente, suelen usarse también métodos de predicción de costes como COCOMO o los puntos de función. Las últimas iniciativas en este campo son múltiples y se extienden a lo largo de todo el proceso relacionado con el software. Los más académicos se inclinan por una estructura de componentes, servicios, con orientación a objetos o a aspectos en la implementación; aunque también es igual de significativo el desarrollo de las herramientas que nos ayuden a representar y compartir estos diseños, así como a valorar el esfuerzo y el valor que añaden al producto final. Es realmente un campo fascinante, donde tanto en los seminarios o en las grandes consultoras, como en los pequeños laboratorios se innova cada día y se presentan buenas ideas.