Evolucin de la ingeniera de software

El software a nivel mundial se empieza a desarrollar en la dcada de los 40; El acto

de programar estas mquinas en los aos 40 tena poco de soft y mucho de hard,
dado que se realizaba primero mediante la manipulacin del propio cableado y
luego mediante instrucciones en tarjetas de cartn perforado (elementos fsicos
todos)[1].
En ese momento, el reto mayor era programar los algoritmos para que los
computadores hicieran los clculos, procesos y reportes que se requeran para las
diferentes funciones.
Fue a mediados de la dcada de los 60 y hasta 1985 que se genera la crisis del
software. Esta crisis se evidencia en el estudio del Standish Group (Reporte del
Caos), en donde se muestra que solo el 16% de los proyectos de software son
exitosos. En general, los proyectos de software tuvieron fuertes sobrecostos y los
tiempos fueron varias veces ms altos de los planeados. Adicionalmente, los errores
en el software llevaron a prdidas en las empresas e incluso de vidas. En este
momento, nace la conciencia que desarrollar es mucho ms que codificar: se le
hace nfasis a la calidad. Dentro del concepto de calidad, cabe la definicin
intuitiva que el software no contenga errores, pero tambin incluye el hecho que los
proyectos cumplan los tiempos y los costos planeados.
A este tema hay que sumarle el avance que ha tenido la tecnologa y el concepto de
sistemas de informacin. Inicialmente, los programas eran una cola de programas
a ejecutar, uno detrs de otro, en donde la salida de uno era la entrada del otro.
Actualmente los sistemas de informacin estn orientados a la interaccin con el
usuario, con respuestas en tiempo real y fuerte integracin con otros sistemas,
dentro de la misma empresa o fuera de ella. La interconexin es cada vez mayor,
aumentando los riesgos de seguridad, los caminos posibles de utilizacin del
software y por tanto la probabilidad de errores en las aplicaciones.
La crisis del software lleva a la necesidad de crear e implantar metodologas de
software. Se ve por ejemplo, que las revistas de la ACIS desde 1977 se refieren
principalmente a algortmica y mquinas de cmputo. Es slo hasta 1985, que hay
un artculo de Alberto Garca sobre la Metodologa CIFI Uniandes para el
desarrollo de sistemas de informacin, en donde se incluyen las fases basados en

la metodologa de Tom de Marco, de Anlisis de la situacin actual, Diseo lgico,

Diseo fsico, Programacin, Implantacin y Operacin y mantenimiento[3],
bsicamente en un concepto cascada puro (llama la atencin que no existe la fase
de Pruebas).
Empiezan a nacer las empresas de desarrollo de software lo que implica adems
que se deben encontrar formas de contratacin de software, sobretodo desarrollos
a la medida. Si bien, se crean varias empresas de software, tambin se encuentran
fuertes fracasos en los proyectos y tambin en las empresas. Estos fracasos se
deben a que las contrataciones son a precio fijo, en donde la mtrica del trabajo a
realizar no es clara, adems del problema de la calidad de software hace que en
varias ocasiones la correccin de errores genere ms errores, o que haya errores
que realmente son cambios en requerimientos. Como se tiene un enfoque cascada,
los errores slo se detectan en la ltima fase del desarrollo; estos errores en varias
ocasiones se refieren a problemas de diseo, o imprecisiones de requerimientos. Al
ser detectados al final, se debe volver a hacer mucho del software, e incluso se
cancelan los proyectos por la cantidad de trabajo perdido que habra que
desarrollar nuevamente. Esto conlleva a que las empresas de software tengan
fuertes riesgos y en la mayora de las ocasiones se quiebran en menos de 5 aos.
Las metodologa cascada evoluciona al mtodo en V, donde se recalca la
importancia de pruebas e incluye cuatro estados de pruebas: Unitarias,
Integracin, Sistema y Aceptacin. Empieza entonces la especializacin de las
tareas: requerimientos, diseo, pruebas. Sin embargo, las empresas estn
dispuestas a asumir la inversin requeridas para pruebas? Ya ahora, no slo se
necesitan ingenieros que desarrollen, tambin ahora hay ingenieros que slo se
dedican a pruebas. Se requiere tambin infraestructura y herramientas para
efectuar el control de calidad de forma adecuada.
Cuando los sistemas eran programas a ejecutar uno tras otro, el concepto de
requerimientos era ms claro y controlable, ya que se deba especificar que dadas
unas entradas, se realiza un procesamiento y produce una salida. Por ese motivo, se
realizaba un control de calidad en donde se realiza una verificacin de la
produccin de la operadora[2], de forma aleatoria, como si fuera el control de
calidad de una fbrica de medicamentos.

Actualmente, el software se refiere principalmente a interaccin con el usuario, con

gran cantidad de caminos y fuerte integracin con otras aplicaciones. Esto hace
que haya mayor posibilidad de funcionalidades, pero tambin mayor posibilidad de
error en las aplicaciones. Se requieren pruebas de lo nuevo, pruebas para
demostrar que no se da lo que antes funcionaba, y pruebas de lo que ahora se
llama No funcional.
No funcional? Qu es esto? Se refiere a las caractersticas del sistema que no son de
procesamiento, validaciones, ni salidas del sistema sino referentes a temas
llamados tcnicos. Estas caractersticas se solucionan a travs de buenos diseos,
que cimentan la Arquitectura del Software.
En resumen, la crisis unida con la evolucin del software genera varios conceptos
que se trabajan ahora en la ingeniera de software: las metodologas, los procesos
de software y el software para desarrollar software. Se incluyen en las formas de
desarrollo, disciplinas adicionales a la codificacin, como lo es Anlisis y
especificacin de requerimientos, Pruebas, Gerencia de proyecto, Arquitectura de
Software, despliegue e incluso ahora temas como Arquitectura Empresarial y
Modelamiento de Negocio.
Se crean modelos para medir la madurez del proceso de producir software, como lo
son CMM, CMMI y SPICE. Llama la atencin que CMM nace desde la necesidad de
un cliente (el departamento de defensa de EEUU) sobre el xito de sus proyectos de
software. Y es que son varios los clientes que han tenido grandes prdidas de
dinero y de tiempo originados por proyectos que nunca salen a produccin, o que
salen mucho ms tarde de lo planeado (supe incluso del caso de un proyecto
planeado en dos aos, que dur catorce aos en desarrollarse!!).
Nacen procesos y metodologas como Metrica 3, PSP, TSP, RUP, MSF, EUP entre
otros. Estos procesos tienen como base principal definir las disciplinas que hay que
tener en cuenta dentro del desarrollo de software. Pero al momento de
implementarlas, en algunas ocasiones, clientes y empresas de software los juzgan
como muy pesados y llenos de documentacin. Conozco varios casos en que se
contrataron proyectos con RUP, y despus de varios aos lo nico que se produjo
fueron modelos y documentos.

Se genera entonces la corriente de las metodologas giles, que tienen su base en el

manifiesto gil, en donde se prefieren: Individuos e interacciones sobre procesos y
herramientas, Software funcionando sobre documentacin extensiva, Colaboracin
con el cliente sobre negociacin contractual, Respuesta ante el cambio sobre seguir
un plan. Esta corriente promete que los desarrollos se realizan ms rpido y con
buena calidad. En estas corrientes se identifican muchos ms sabores como son
Scrum, XP, Kanban, OpenUP, AUP, EssUP, FDD, Lean Software Development,
entre otros.
Sin embargo, tambin se genera una nueva necesidad: debido a la integralidad de
las aplicaciones y el acceso por medio de redes, las nuevas aplicaciones exigen
fuertes requerimientos no funcionales de seguridad, por lo que nace la corriente de
Desarrollo Seguro. El desarrollo seguro consiste en una serie de reglas en el
proceso de desarrollo de software para que el software sea de buena calidad y
cumpla los requerimientos de forma adecuada, y reglas a validar para que la
aplicacin tenga buena arquitectura y baja susceptibilidad a ataques de seguridad
por medio de la red.