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

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