Está en la página 1de 7

La Crisis del Software Origen

Aunque no hay concenso, el origen del termino se atribuye a dos conferencias organizadas por la OTAN en 1967 y 1968. Ambas conferencias fueron convocadas para tratar la llamada "Crisis del Software". El cual es hasta hoy un problema no resuelto. Primera Fase. Los Albores ( 1945-1955) : Programar no es una tarea diferenciada del diseo de una mquina. Uso del Lenguaje mquina y emsamblador. Segunda Fase. El Florecimiento ( 1955-1965 ) : Aparecen una multitud de lenguajes. Es posible hacer todo. Tercera Fase. La Crisis ( 1965-1970 ) : Desarrollo Inalcanzable de grandes programas. Ineficiencia, errores, coste impredecible. Nada es posible. Cuarta Fase. Innovacin Conceptual ( 1970-1980 ) : Fundamentos de Programacin. Verificacin de Programacin. Metodologas de Diseo. Quinta Fase. El Diseo del Problema ( 1980-200? ) : Entornos de programacin. Especificacin Formal.. Programacin Automtica. Otro Panorama de La crisis del software

Muchos observadores han caracterizado los problemas asociados con el desarrollo del software como una "crisis". Esta palabra se define en el diccionario de Webster como "un punto decisivo en el curso de algo". Sin embargo no ha habido un punto decisivo sino un lento cambio evolutivo. En la industria del software hemos tenido una "crisis" que ha estado con nosotros cerca de 30 aos y eso es una contradiccin para el trmino. Actualmente ya se ha alcanzado la etapa de crisis en el software de computadoras. Lo que realmente tenemos es una afliccin crnica. La palabra "afliccin" se define en el Webster como "algo que causa pena o desastre", y la palabra "crnica" se define como "muy duradero o que vuelve a aparecer con frecuencia ; continuando indefinidamente". Entonces, es ms preciso decir que es una afliccin crnica en vez de utilizar el trmino de crisis. Muchas de las causas de la crisis del software se pueden encontrar en una mitologa que surge durante los primeros aos del desarrollo del software. Hoy la mayora de los profesionales competentes consideran a los mitos como actitudes errneas que han causado serios problemas, siendo stos hbitos difciles de modificar.
http://www.angelfire.com/space/equipo_5/neo/crisis.htm

La crisis del software 1960-1970 Antecedentes. Aos 1960s En estos aos se desarrollan docenas de lenguajes que surgan en empresas y universidades. Algunos como JOVIAL, MAD, NELLIAC, ALGOL-W, BASIC, etc., eran de propsito general. Otros eran de propsito especfico, como SNOBOL (tratamiento de cadenas de caracteres), APL (procesamiento de matrices numricas), GPSS (simulacin) o los derivados de LISP (cmputo simblico). Sin embargo, no existan criterios claros para comparar la bondad relativa de tales propuestas. La programacin cientfica se haba adherido a FORTRAN, la empresarial a COBOL y cada rea de aplicacin dispona de su propio lenguaje. El uso de lenguajes de alto nivel permiti dividir entre diez el esfuerzo humano de programacin. Pero las mquinas demandaban tambin programas ms grandes. A mediados de la dcada, y auspiciada por el desarrollo del hardware, surge la denominada multiprogramacin, que consiste en que el sistema operativo aprovecha los

tiempos muertos de un programa para ejecutar otros programas. El OS/360 de IBM (1964) es el primero que ofrece esta facilidad. Los perifricos son tpicamente entre mil y cien mil veces ms lentos que la unidad de proceso. Se llaman tiempos muertos a los que un programa ha de esperar a que se complete una operacin de entrada - salida.

Problemas introducidos por la concurrencia Los programas que simulan la ejecucin paralela de varias tareas en un procesador se denominan concurrentes. En 1964 nadie era consciente de los problemas a los que podan dar lugar: errores no deterministas, corrupcin de los datos compartidos, interbloqueos, etc. El OS/360 alcanz ms de un milln de lneas de cdigo y trabajaron en l hasta 500 programadores a la vez. Este conjunto de circunstancias condujo a un sonado fracaso que marc a partir de entonces la historia de los lenguajes: un retraso de dos aos, 500 millones de dlares en lugar de los 40 millones presupuestados, y multitud de errores cuyo nmero no conseguan disminuir las sucesivas versiones. El caso de IBM fue el ms espectacular, pero en esa poca se dieron muchos otros casos de proyectos fallidos. En la mayora de ellos, el nmero de instrucciones a escribir alcanzaba cifras de varios cientos de miles. Se hizo evidente que la tecnologa del momento no poda hacer frente con fiabilidad a sistemas ms all de las cien mil lneas de cdigo.

Sntomas: Baja Calidad del Software. El software no es fiable y necesita de un mantenimiento permanente. Tiempo y Presupuesto Excedido. El software se entrega muy a menudo con retrasos y con unos costes superiores a los presupuestados. Confiabilidad Cuestionable. A menudo el software es imposible de mantener, carece de trasparencia y no se puede modificar ni mejorar. El software a menudo no satisfaca los requerimientos deseados.

Los proyectos fueron inmanejables, con un cdigo difcil de mantener. La crisis del software fue dirigida por la implementacin de varios procesos y metodologas.

Baja Calidad del Software. Tiempo y Presupuesto Excedido. Confiabilidad Cuestionable. Altos Requerimientos de Personal para desarrollo y mantenimiento.

La crisis Abundando en este estado de cosas, empez tambin a tomar forma la idea de que sera deseable un lenguaje que sirviera para todo. ste debera disponer de una buena notacin matemtica para la expresin de clculos numricos, de suficientes facilidades para la descripcin de datos, una entrada/salida verstil y eficiente, y mecanismos para la creacin de estructuras dinmicas semejantes a las de LISP. Tambin debera tener algunas caractersticas de los lenguajes especializados, tales como el tratamiento de cadenas de caracteres o facilidades para la multiprogramacin. En este contexto, se aborda el diseo de dos nuevos lenguajes: PL/I y ALGOL 68. PL/I lo dise IBM para su mquina 360: inclua ideas de FORTRAN, de COBOL, punteros, excepciones y primitivas para la concurrencia. Su principal problema era su volumen y falta de ortogonalidad. En realidad era una acumulacin de construcciones de muy diverso tipo y su interaccin no estaba clara en muchos casos. En palabras de E. W. Dijkstra (1972), usar PL/I es como pilotar un avin con 7.000 mandos distintos. PL/I no tuvo xito entre sus potenciales usuarios a pesar de los esfuerzos de IBM por difundirlo. A peticin de stos, tuvo que desarrollar y soportar compiladores de FORTRAN y COBOL para la serie 360. ALGOL 68, fue obra del grupo de trabajo WG 2.1 de la IFIP (International Federation for Information Processing). Su principal objetivo de diseo fue la ortogonalidad: ALGOL 68 constaba de pocos elementos primitivos que se podan combinar entre s casi sin restricciones. Por ejemplo, dispona de cinco tipos bsicos y de cinco modos distintos de formar tipos compuestos a partir de tipos ms simples: vectores y matrices, registros, uniones, punteros a elementos de un tipo t, y funciones de un tipo t1 en un tipo t2. El lenguaje result bastante incomprensible y muy difcil de implementar. Su impacto en la programacin del momento fue mnimo.

El reconocimiento oficial de la crisis se llev a cabo en una conferencia internacional en Garmisch (Alemania), en octubre de 1968, patrocinada por la OTAN. El trmino crisis del software se acu en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software y con l se etiquetaron los problemas que surgan en el desarrollo de sistemas de software. Sus organizadores le dieron el provocativo ttulo de Software Engineering con el fin de evidenciar la ausencia de una verdadera Ingeniera del Software basada en mtodos cientficos probados, como los de ingenieras ms asentadas. En la misma conferencia se utiliz por primera vez el trmino "ingeniera del software" para describir el conjunto de conocimientos que existan en aquel estado inicial.

La salida de la crisis Quizs la aportacin de ALGOL 68 a la historia de los lenguajes fuera la de colaborar a su pesar en la bsqueda de soluciones. Algunos investigadores que marcaron la dcada de los 70, tales como C. A. R. Hoare y N. Wirth, se apartaron del WG 2.1 ocupado en la definicin de ALGOL 68 y crearon un nuevo grupo, el WG 2.3, sobre metodologa de la programacin. Pensaron que se impona un periodo de reflexin antes de abordar el diseo de nuevos lenguajes. stos deberan reflejar una metodologa adecuada para la concepcin de programas y no a la inversa. Pero esa metodologa estaba an por hacer. El espritu de los mtodos y lenguajes que se estaban buscando se puede resumir en una sola palabra: humildad. Se necesitaban lenguajes ms simples cuyas construcciones fueran completamente comprendidas, y sistemas de tipos ms exigentes que eliminaran la mayor cantidad de errores posibles durante la compilacin.

La programacin estructurada Dijkstra afirma (Notes on Structured Programming, Univ. Eindhoven 1966) que la mente humana es incapaz de razonar en presencia de un nmero excesivo de detalles y que la claridad de un razonamiento es inversamente proporcional a la cantidad de elementos que intervienen en l. La explicacin ltima de los fracasos de los grandes proyectos de desarrollo de software estaba, segn l, en la transgresin de esta limitacin.

Se abordaban programas voluminosos, con lenguajes con construcciones inseguras y la nica herramienta disponible para convencerse de la ausencia de errores era la ejecucin del programa en unos cuantos casos de prueba. El testing, o prueba de programas, afirma Dijkstra, es muy til para mostrar la presencia de errores, pero nunca para demostrar su ausencia. Para convencerse de la correccin, hay que razonar sobre el texto del programa. El movimiento de la programacin estructurada parte de la aceptacin con humildad de estos hechos y aboga en consecuencia por lenguajes mucho ms modestos que los existentes en ese momento, y por construcciones lo ms simples posibles que faciliten la tarea de razonamiento. Una de las construcciones consideradas en ese sentido ms peligrosas es la instruccin goto, que hace posible por ejemplo saltar fuera de un bucle o a un punto arbitrario de un procedimiento. En general, se pueden crear lazos en el flujo de control que no estn anidados unos dentro de los otros. C.Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin para la eliminacin de "GoTo" y la creacin de la programacin estructurada. En 1968 los programadores se debatan entre el uso de la sentencia GoTo, y la nueva idea de programacin estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribi su famosa carta "GoTo Statement Considered Harmful" en 1968. La programacin estructurada aboga por construcciones necesariamente anidadas, y con un nico punto de entrada y otro de salida del control: 1. La composicin secuencial S1; S2 de dos instrucciones S1 y S2. 2. La composicin condicional if B then S1 else S2. 3. La composicin iterativa while B do S.

Hoare dio en 1969 los axiomas lgicos de estas tres construcciones. Basados en la lgica de predicados de primer orden, establecan las reglas para la verificacin matemtica de los programas. Por primera vez se dispona de un conjunto de leyes que permitan razonar con todo el rigor sobre la correccin de un programa escrito en un lenguaje de alto nivel. Ms an, este razonamiento era independiente de cualquier implementacin del lenguaje y de cualquier computador en que se ejecutara el programa. La verificacin formal de programas se desarrolla notablemente durante la dcada de los 70, impulsada sobre todo por E. W. Dijkstra. Propone la tcnica de derivacin formal, en la que la verificacin gua el diseo: primero se establecen los predicados que han de satisfacerse en ciertos puntos del programa (en

especial los invariantes de los bucles) y luego se deduce sistemticamente un programa que los satisface. De este modo, los programas resultantes son correctos por construccin. Complementario de las tcnicas de verificacin es el desarrollo de programas mediante refinamientos sucesivos (N. Wirth, 1971): 1. Los programas se disean por niveles de abstraccin decrecientes. 2. En cada paso se refina una accin no elemental, que da lugar a un pequeo programa en el que aparecen acciones de ms bajo nivel. 3. A su vez, cada una de ellas se refina en otros textos ms detallados y as hasta llegar a las acciones elementales del lenguaje de programacin. La ventaja del mtodo es que, en cada paso, el programador concentra su atencin en un pequeo nmero de detalles.

Programacin estructurada = ausencia de go-to + refinamientos + verificacin formal La primera publicacin sobre programacin estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens. El primer libro sobre mtrica de software fue publicado en 1977 por Tom Gilb. El primer libro sobre anlisis de requisitos apareci en 1979. (*)En efecto, se refiere a la dificultad de escribir correcta, entendible y verificablemente los lenguajes de programacin.

La crisis del software Muchos se han preguntado: Porqu lleva tanto tiempo terminar los programas? Porqu es tan elevado el coste? Porqu no podemos encontrar todos los errores antes entregar el software a nuestros clientes? Porqu nos resulta tan difcil constatar el progreso conforme se desarrolla el software?