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.