Historia de las metodologías

Los Orígenes (1940-1960)
La década de los 40 marca el inicio de la primera generación de computadoras y con
ellas la serie de programas y sistemas que éstas requieren para funcionar, (Rivas, Corona,Gutiérrez & Hernández, 2015). Según Garcés & Egas (2015), las primeras prácticas de desarrollo no obedecían a una metodología, los llamados programadores se abocaban a desarrollar sus códigos una vez que comprendían los requerimientos de sus clientes.
Aún hacia finales de los 50, la producción del software era “totalmente artesanal y en
ella no habían metodologías definidas, lo que acarreaba multitud de problemas.” Carballar (2009). Estos primeros empirismos se enfocaban en la tarea de codificar, más que comprender, diseñar o documentar los requerimientos de los usuarios.
Para la época, se inicia el empleo masivo del hardware y la complejidad de las tareas que realizan los equipos computacionales existentes va en aumento, imprimiendo esa complejidad a las tareas de programación, se hizo necesario estandarizar y simplificar dichas actividades, lo que da cabida a los leguajes de programación. Una primera generación es llamada lenguaje de máquina, seguido de una segunda denominada lenguaje ensamblador. La tercera generación o lenguajes de programación de alto nivel, simplifica aún más los procesos
de codificación puesto que las instrucciones son comprensibles por el programador casi como si fuesen leguajes naturales. (Garcés & Egas, 2015).
Aunque se disponían de importantes técnicas de codificación para la época, clientes y usuarios en una parte importante de los desarrollos no quedaban satisfechos con los sistemas, pues sus necesidades no estaban definidas con claridad en una fase de análisis previo.
“Ante esta perspectiva se vio la importancia del análisis y del diseño en el desarrollo
de un sistema. Ahora se empieza a hablar de analistas programadores y analistas de
sistemas.” (Carballar, 2009); esta diferenciación empieza a marcarse hacia mediados de los años 50.
Aún ante estos iniciales pero significativos avances, los resultados finales eran
impredecibles. No se tenía una manera clara de controlar los avances de los proyectos, aunque se estructuraban equipos de trabajo, no existían fases diferenciables ni productos intermedios para poder realizar verificaciones. Los desarrollos tomaban curso sin mediciones, para un director era casi imposible tomar decisiones. Según Carballar (2009), ante este panorama, la detección tardía de defectos era casi inevitable, en la mayoría de los casos cuando se estaba probando el código o aún peor, cuando el sistema se encontraba en producción, por lo que los desarrollos resultaban costosos.