La Crisis del Software 1960's y 1970's.

El término “Crisis del Software” fue acuñado a principios de los años 70, cuando la ingeniería de software era prácticamente inexistente. El término expresaba las dificultades del desarrollo de software frente al rápido crecimiento de la demanda por software, de la complexidad de los problemas a ser resueltos y de la inexistencia de técnicas establecidas para el desarrollo de sistemas que funcionaran adecuadamente o pudieran ser validados.
La percepción de que esta crisis existía empezó a mediados de los años 60. Una de las primeras referencias al término, y de las más notables, fue hecha por E.W.Dijkstra, en el discurso que pronuncio durante la entrega del premio Turing en 1972.
En este trabajo abordaremos por que se produjo esta crisis,  y cuál fue el camino adoptado para resolverla, o minimizar sus efectos de algún modo.




CAUSAS DE LA CRISIS DEL SOFTWARE

Durante finales de los años 50 i principios de los 60, la potencia computacional de las maquinas era bastante limitada. Es por esto que los programas que se desarrollaban eran “simples” desde nuestro punto de vista actual. Seguían un proceso de desarrollo bastante artesanal, sin una metodología o un camino a seguir para su desarrollo. En esta época se solían usar los lenguajes de bajo nivel para el desarrollo de Software.
Pero a finales de los 60, la potencia de las maquinas empezó a aumentar de forma considerable. Empezaron a aparecer los lenguajes de programación de alto nivel, y las maquinas necesitaban programas mucho más complejos de los desarrollados hasta la época. En definitiva, fue un salto tremendo en cuanto a potencial de hardware, que no fue acompañado por un salto en el desarrollo de software.
En esta época, se empezó a concebir el Software como producto, y se empezaron a desarrollar algunos proyectos para que funcionaran en las máquinas de la época. Pero aparecieron importantes problemas: los productos excedían la estimación de costes, había retrasos en las entregas, las prestaciones no eran las solicitadas, el mantenimiento se hacía extremadamente complicado y a veces imposible, las modificaciones tenían un coste prohibitivo…en resumen, se desarrollaba software de mala calidad, ya que la técnica utilizada para desarrollar pequeños programas para maquinas con mucho menos potencial se quedaba desfasada, y muchas veces este software acababa en el olvido. Como ejemplo, podemos ver este gráfico del año 1979, en el que se recoge la inversión en desarrollo de sistemas software en ese año ($6.8 Millones),y como acabó ese software
Fuente: Apuntes Ingeniería del Software de Gestión. “Tema 1: Software e Ingeniería del Software”
Una de las principales causas de todo esto, si no la principal, era el enfoque dado al proceso de desarrollo de software, el cual era malo e incluso a veces era inexistente. En este proceso, solo ¼ del tiempo de desarrollo se dedicaba a las fases de análisis, diseño, codificación y pruebas, y más de ¾ del tiempo se dedicaba a correcciones y mantenimiento. Es evidente que dedicándole sol ¼ del tiempo a las primeras fases, se arrastran errores graves, sobre todo procedentes de las fases de análisis y diseño, lo que dificultaba muchísimo la implementación, produciendo constantes paradas y retrocesos para revisar este análisis/diseño.
Para que nos hagamos una idea, el conjunto de las fases de análisis y diseño abarcaban el 8% del tiempo total de desarrollo de software. Además casi el 80% de los errores se producían en estas dos fases, con lo que se incrementaba el coste de corrección de errores conforme evolucionaban las fases de manera bestial. Con estos indicadores estaba claro que algo estaba fallando y que el proceso de desarrollo de software necesitaba un cambio radical.


INGENIERÍA DEL SOFTWARE, LA SOLUCIÓN.

Viendo el camino directo al precipicio que estaba llevando el desarrollo de software, había que tomar medidas para solucionarlo. Y esas medidas se llamaron “Ingeniería del Software”.
La Ingeniería del Software, según R.Pressman, es “Una disciplina que integra métodos, herramientas y procedimientos para el desarrollo de SW de computador”. Es decir, es una disciplina que intenta racionalizar el proceso de desarrollo de software y establecer unas pautas a seguir para el desarrollo que minimicen tiempo, esfuerzo, y coste de desarrollo y maximicen la calidad del software.
Después de esta crisis, se intentaron establecer estas pautas, aplicándolos a algunos proyectos y aumentando la inversión. En 1991 se hizo un estudio para comprobar los resultados de la aplicación de estos métodos, y los resultados fueron bastante buenos. El 52% de los proyectos se terminaron con éxito, frente al 2% del año 1979  y el 31,1% se terminó con algunas modificaciones respecto a lo acordado inicialmente, frente al 3% del año 1979.  Pero el resultado más espectacular se obtuvo en los proyectos abandonados. En 1991 sólo se abandonaron el 16,2% de proyectos, frente al casi 76% del año 1979. Una reducción increíble de casi el 60% que no hacía mas que confirmar la bondad de estos métodos aplicados al proceso de desarrollo de software. Había nacido una nueva disciplina, la Ingeniería del Software,
Para hacernos una idea mas concreta de lo que abarca la Ingeniería del Software (cosa que nos ayudará a entender porque fue la solución a esta Crisis del Software), debemos de centrar nuestra explicación en que la I.S busca principalmente software de calidad, que es aquel software que cumple los requisitos funcionales y de rendimiento establecidos previamente y consta de unos estándares de desarrollo bien documentados. Además todos sus factores de calidad deben cumplirse y tener un buen seguimiento durante todo el proceso de desarrollo (características operativas, capacidad de soportar cambios y adaptabilidad a nuevos entornos). Y por último, se incorporan al proceso nuevos modelos de desarrollo y modificación del ciclo de vida, nuevos paradigmas de programación, etc.…que hacen que el desarrollo de software sea mucho mas metodológico y estructurado, disminuyendo así notablemente fallos y correcciones costosas.
Como ejemplo de que la ingeniería del software es en la actualidad imprescindible, la revista inglesa “Private Eye” dio detalles sobre importantes proyectos de software que han dado malos resultados. Entre ellos destacan los del servicio de ambulancias Asinfor de Londres, el servicio de sanidad regional de Wessex, la Sociedad para los derechos de autor y el sistema de manejo de equipajes del aeropuerto de Denver.
Por último, os dejo unas viñetas, muy vistas pero no por ello menos buenas, que resumen en unas pocas imágenes la gran problemática del desarrollo del software.




 

Fuente: histinf.blogs.upv.es

La Crisis del Software, la guerra de las metodologías y el desarrollo del software

Realizado por: Diana Nogueda Anaya

Hoy en día oímos hablar de computadoras potentes que hacen maravillas, con la mejor velocidad, procesador, memoria, etc,. Sin embargo poco o nada nos detenemos a pensar que hay detrás de todos esos fierros que hace que funcione, sin pensar que para llegar a la construcción del todo lo que implica una computadora hubo un previo análisis y diseño, en este sentido nos referimos al software que en otras palabras es valido decir que no tiene sentido los equipos sin programas.

Así es como el análisis y diseño de sistemas se torna un tema de interés en  donde muchas cosas cotidianas tuvieron un previo estudio para su construcción, así entonces  el tiempo aplicado al análisis es consecuencia del tiempo de mantenimiento del sistema construido.

La “crisis del software” nos muestra la lenta evolución que ha tenido la industria del software que data cerca de 30 años. En la OTAM1 en los años de 1967 y 1968 se hicieron dos reuniones con el fin de resolver este problema en donde difícilmente resulta ponerse de acuerdo y optar por un estándar completamente definido. Las fases que se han tratado a través de los años hasta la fecha son las siguientes:

Primera Fase.  Los Albores ( 1945-1955) :

             Programar no es una tarea diferenciada del diseño de una máquina.

            Uso del Lenguaje máquina 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. Innovación Conceptual ( 1970-1980 ) :

             Fundamentos de Programación.

             Verificación de Programación.

             Metodologías de Diseño.

Quinta Fase. El Diseño del Problema ( 1980-200? ) :

             Entornos de programación.

             Especificación Formal..

             Programación Automática.

En ocasiones, el diseñador al escoger entre la variedad de lenguajes, técnicas, métodos y otros, prefiere hacer las cosas como mejor le convenga y sacar el diseño lo más pronto posible lo cual resulta ser una decisión nada acertada, que más que ayudar en tener un sistema lo más pronto posible funcionando resulta un sistema poco funcional donde abundará la generación posterior de errores.

Aún seguimos hablando de esta crisis del software y desafortunadamente profesionistas siguen sin hacer uso de metodologías o herramientas CASES que actualmente existen en le mercado y con las cuales nos alejan de ciertos mitos que suelen escucharse y se extienden en tres partes: los de gestión, los del cliente, y los del desarrollador.

De forma general estos mitos2 son:

• Ya tenemos el mejor libro para construir software,
• lo ultimo en computadora para desarrollar,
• poco importa la planificación,
• solo basta conocer el problema de forma general,
• si requiere un cambio el sistema el software fácilmente lo hará,
• hasta que se ponga en uso el programa se ve la calidad de este,
• solo es necesario entregar el programa funcionando.

Quizá hemos escuchado otros mitos sin embargo no se debe hacer caso omiso a estas reflexiones, es decir no basta tener el mejor libro si no se usa o no es el adecuado, ¿para que nos servirá la computadora más potente cuando podemos sacarle mayor provecho a una herramienta CASE?, además lo importante que es planificar y analizar el problema que se quiere modelar o sistematizar, documentarlo, etc. Finalmente todo esto será consecuencia de la calidad del software desarrollado e implentado.

No hay un camino fácil hacia la calidad del software. Por tanto es importante conocer los beneficios y las limitaciones del software y así relacionar las técnicas y metodologías para aplicar. En muchos aspectos, construir un sistema software es similar a desarrollar una teoría matemática3. La matemática, como la construcción de software, se puede enseñar, incluyendo los principios generales que ayudan a los estudiantes con talento a producir resultados brillantes; pero no hay enseñanza que pueda garantizar el éxito.

No todos los enfoques de estilo recetario están condenados al fracaso. Si se restringe suficientemente el dominio de la aplicación hasta quedarse con un conjunto básico de problemas patrón, entonces es posible definir un proceso de enseñanza paso a paso; esto ha ocurrido en algunas áreas de procesamiento de datos económicos y administrativos, en donde los metodólogos han identificado un pequeño numero de esquemas de solución que son ampliamente aplicables.

El destino eventual de tales esquemas es ser subsumidos en paquetes de software o en bibliotecas reutilizables. Pero tan pronto como se amplia un poco el dominio de problema, ningún enfoque simplista funcionara bien; ante esta situación el diseñador debe utilizar sus mejores capacidades de imaginación. Un método podrá servir de ayuda a través de pautas generales, a través del ejemplo de diseños previos que han tenido éxito y también del ejemplo de lo que no funciona pero claro no mucho más.

El campo de la metodología de desarrollo de software no es nuevo. Sus orígenes se pueden remontar a la famosa carta de Dijkstra Go To Statement Considered Harmfull4 y las publicaciones subsiguientes han seguido sus estándares.

Ciertamente, es relativamente fácil legislar sobre construcción de software, pero es grande el peligro de producir reglas inútiles, poco meditadas, o incluso dañinas.

De acuerdo a las clases de “Ingeniería de software” han surgidos diversas metodologías algunas utilizables en la actualidad otras poco acertadas que han dejado de aplicarse, sin embrago de todas y cada una de ellas se han tomado técnicas o procesos surgiendo otras más complejas o más utilizables en el desarrollo del software

Entre los métodos de análisis Orientado a Objetos que han sobresalido algunos en determinado tiempo y otros más que hasta la fecha se siguen usando se listan los siguientes, mostrados por orden aproximado de aparición.

El método de:

1. Coad-Yourdon,OMT,
2. Shaker-Mellor,
3. Martín-Odell,
4. Booch,
5. OOSE,
6. OSA,
7. Fusion,
8. Syntropy,
9. MOSES y
10. SOMA.

A partir de estos métodos, hoy día escuchamos hablar de otros que prometen ser mejor (OPEN y el UML) ya que están basados y además surgieron de los conocimientos y experiencia de varios de los autores de los métodos ya mencionados.

 

Hasta este momento hemos visto la importancia del uso de técnicas y metodologías para el desarrollo del software pero ante todo el propósito sería que este sea funcional y que cumpla con cierta calidad y no solo crear sin tener bases sólidas para hacerlo.

La producción de software, una actividad en estado preindustrial, esencialmente creativa y artesanal, por consecuencia difícilmente automatizable, sufre un llamado vació de productividad relativa5 y requiere la racionalización al menos del complejo entorno, por ahora mayoritario, de los sistemas de información (SI) para la gestión de las organizaciones, privadas o públicas.

Estas entidades siguen desarrollando mayoritariamente sus SI con recursos propios; es decir, especializan un departamento de su organización como proveedor informático interno de los otros departamentos clientes (sin que entre ambos actores suela haber otro contrato que un acuerdo tácito).

El estudio de las experiencias para incrementar la calidad y seguridad de implantación de nuevos sistemas ha llevado así a un enfoque intensivo de estudio del megaciclo de vida del conjunto de los SI en las entidades.

Paralelamente a este nuevo enfoque intensivo, el clásico enfoque extensivo lleva a estudiar el micro ciclo de cada SI aislado, y está creciendo en importancia y complejidad con la extemalización del proveedor de SI y con la consecuente formalización de su contrato con el cliente.

Con este enfoque mencionado es posible concluir que en la ingeniería se busca la calidad; es decir, la ingeniería del software es la producción de software de calidad.

Bertrand Meyer ha plasmado en sus numerosas obras, de modo que los cinco primeros principios originales de 1988 que son los Factores externos (Correcion, robustez, extensibilidad, reutilización o reusabilidad y compatibilidad, añadio en 1995: fiabilidad, portabilidad y eficiencia), para finalmente hacer una declaración de principios de calidad de software a modo de decágolo6 que por docentes universitarios que se dedican a la disciplina de ingeniería de software y descontado, los analistas y en los productos que crean. En esta especie de decágolo, Meyer denominó los factores externos de calidad y cuya consecuencia es la tarea central de la construcción de software orientado a objetos.

En general todos deseamos que los sistemas de software sean rápidos, fiables, fáciles de usar, legibles, modulares, estructurados y así sucesivamente. Pero estos adjetivos describen dos cualidades diferentes. Por una parte, se consideran cualidades tales como la velocidad o la facilidad de uso, cuya presencia o ausencia en un producto de software puede ser detectada por sus usuarios. Estas propiedades pueden ser denominadas factores de calidad externos.

Otras cualidades aplicables a un producto de software, como la modularidad o legibilidad son factores internos, perceptibles sólo por profesionales de la informática que tienen acceso al código fuente.

En última instancia, sólo importan los factores externos. Si se usa un navegador Web o se vive cerca de una planta nuclear controlada por computadora, importa poco que el software sea legible o modular si los gráficos tardan años en cargarse o si la introducción de datos erróneos hace explotar la planta. La clave para obtener los factores externos radica en los internos: para que los usuarios disfruten de las cualidades  visibles, los diseñadores y los implementadores deben aplicar técnicas internas no son un fin en si mismas, sino un medio para alcanzar las cualidades externos que finalmente será a través de los factores internos.

Así entonces concluyo que a pesar e no existe un estándar de la metodologia a seguir al momento de desarrollar, el propósito de la ingeniería del software es encontrar modos de construir software de calidad.

Crisis del Software

La crisis del software se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca flexibilidad.
Es un término informático acuñado en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software, de la cual nació formalmente la rama de la ingeniería de software. El término se adjudica a F. L. Bauer, aunque previamente había sido utilizado por Edsger Dijkstra en su obra The Humble Programmer.
Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.
Además, no existen todavía herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa. Este hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo llevará un proyecto, ni cuánto personal será necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecución.
Por último, las aplicaciones de hoy en día son programas muy complejos, inabordables por una sola persona. En sus comienzos se valoró como causa también la inmadurez de la ingeniería de software, aunque todavía hoy en día no es posible realizar estimaciones precisas del coste y tiempo que necesitará un proyecto de software.
Englobó a una serie de sucesos que se venían observando en los proyectos de desarrollo de software:

• Los proyectos no terminaban en plazo.
• Los proyectos no se ajustaban al presupuesto inicial.
• Baja calidad del software generado.
• Software que no cumplía las especificaciones.
• Código inmantenible que dificultaba la gestión y evolución del proyecto.

Aunque se han propuesto diversas metodologías para intentar subsanar los problemas mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido estimar de manera fiable el coste y duración de un proyecto antes de su comienzo.