[ca] L'expressió enginyeria del programari es va començar a usar al final de la dècada dels seixanta per a expressar l'àrea de coneixement que es desenvolupava entorn de les problemàtiques que oferia el programari en aquell moment. En aquella època, el creixement espectacular de la demanda de sistemes de computació cada vegada més i més complexos, associat amb la immaduresa del mateix sector informàtic (totalment lligat a l'electrònic) i amb la falta de mètodes i recursos, va provocar el que es va denominar la crisi del programari (en paraules d'Edsger Dijkstra) entre els anys 1965 i 1985. Durant aquella època, molts projectes importants superaven amb escreix els pressupostos i dates estimats, alguns dels quals eren tan crítics (sistemes de control d'aeroports, equips per a medicina, etc.) que les seves implicacions anaven més enllà de les pèrdues milionàries que causaven. La crisi del programari va passar, no tant perquè va millorar la gestió dels projectes, sinó en part perquè no és raonable estar en crisi més devint anys i en part perquè es feien progressos en els processos de disseny i metodologies. Així doncs, des de 1985 fins avui dia, han anat apareixent eines, metodologies i tecnologies que es presentaven com la solució definitiva del problema de la planificació, previsió de costos i assegurament de la qualitat en el desenvolupament de programari. Entre les eines, la programació estructurada, la programació orientada a l'objecte, als aspectes, les eines CASE, el llenguatge de programació ADA, la documentació, els estàndards, CORBA, els serveis web, i el llenguatge UML (entre d'altres) van ser tots anunciats en el seu moment com la solució dels problemes de l'enginyeria del programari, l'anomenada bala de plata (per silver bullet). I encara més, cada any sorgeixen idees i iniciatives noves encaminades a això. Sens dubte, també hi ha hagut qui ha culpat els programadors per la seva indisciplina o anarquia en els desenvolupaments. La ignorància i alguns casos excèntrics van contribuir a crear una imatge falsa del programador, que avui dia encara perdura. Encara que moltes vegades ell és el "patidor" d'alguna d'aquestes metodologies o d'una implementació pobra d'aquestes, sembla lògic que, com a participant actiu en el projecte, les metodologies més modernes comencin a tenir-lo més en compte. En combinació amb les eines, també s'han fet esforços perquè incorporin els mètodes formals al desenvolupament de programari, argumentant que si es prova formalment que els desenvolupaments fan allò que s'hi requereix, la indústria del programari serà tan predictible com les altres branques de l'enginyeria. Entre les metodologies i processos, a més de Métrica v3 (promoguda per la Secretaria del Consell Superior d'Informàtica) i la programació extrema, que veurem detalladament més endavant, destaquen molts altres com ara RUP (rational unified process, desenvolupat per Rational Software Corp., ara una divisió d'IBM), SSADM (structured systems analysis and design methodology, promogut pel Govern britànic) o el mètode d'avaluació de la capacitat de desenvolupament dels equips o empreses conegut com a CMMI (capability maturity model integration). Paral·lelament, se solen usar també mètodes de predicció de costos com COCOMO o els punts de funció. Les darreres iniciatives en aquest camp són múltiples i s'estenen per tot el procés relacionat amb el programari. Els més acadèmics s'inclinen per una estructura de components, serveis, amb orientació a l'objecte o a aspectes en la implementació; encara que també és igualment significatiu el desenvolupament de les eines que ens ajuden a representar i compartir aquests dissenys, i també a valorar l'esforç i el valor que afegeixen al producte acabat. És realment un camp fascinant, en què tant els seminaris com les grans consultores com els laboratoris petits innoven cada dia i presenten bones idees.

[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.