http://www.angelfire.com/space/equipo_5/diana/crissoft.

htm

La Crisis del Software, la guerra de las metodologas y el
desarrollo del software.

Realizado por: Diana Nogueda Anaya

Hoy en da omos 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 detrs de todos esos fierros que hace que funcione,
sin pensar que para llegar a la construccin del todo lo que implica una
computadora hubo un previo anlisis y diseo, 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 anlisis y diseo de sistemas se torna un tema de inters
en donde muchas cosas cotidianas tuvieron un previo estudio para su
construccin, as entonces el tiempo aplicado al anlisis es consecuencia del
tiempo de mantenimiento del sistema construido.

La crisis del software nos muestra la lenta evolucin que ha tenido la industria
del software que data cerca de 30 aos. En la OTAM
1
en los aos de 1967 y 1968
se hicieron dos reuniones con el fin de resolver este problema en donde
difcilmente resulta ponerse de acuerdo y optar por un estndar completamente
definido. Las fases que se han tratado a travs de los aos hasta la fecha son las
siguientes:

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.

En ocasiones, el diseador al escoger entre la variedad de lenguajes, tcnicas,
mtodos y otros, prefiere hacer las cosas como mejor le convenga y sacar el
diseo lo ms pronto posible lo cual resulta ser una decisin nada acertada, que
ms que ayudar en tener un sistema lo ms pronto posible funcionando resulta un
sistema poco funcional donde abundar la generacin posterior de errores.

An seguimos hablando de esta crisis del software y desafortunadamente
profesionistas siguen sin hacer uso de metodologas 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 gestin, los del
cliente, y los del desarrollador.

De forma general estos mitos
2
son:
Ya tenemos el mejor libro para construir software,
lo ultimo en computadora para desarrollar,
poco importa la planificacin,
solo basta conocer el problema de forma general,
si requiere un cambio el sistema el software fcilmente 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 ms potente cuando podemos
sacarle mayor provecho a una herramienta CASE?, adems 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 fcil hacia la calidad del software. Por tanto es importante
conocer los beneficios y las limitaciones del software y as relacionar las tcnicas y
metodologas para aplicar. En muchos aspectos, construir un sistema software es
similar a desarrollar una teora matemtica
3
. La matemtica, como la construccin
de software, se puede ensear, incluyendo los principios generales que ayudan a
los estudiantes con talento a producir resultados brillantes; pero no hay enseanza
que pueda garantizar el xito.

No todos los enfoques de estilo recetario estn condenados al fracaso. Si se
restringe suficientemente el dominio de la aplicacin hasta quedarse con un
conjunto bsico de problemas patrn, entonces es posible definir un proceso de
enseanza paso a paso; esto ha ocurrido en algunas reas de procesamiento de
datos econmicos y administrativos, en donde los metodlogos han identificado un
pequeo numero de esquemas de solucin 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, ningn enfoque simplista funcionara bien; ante esta
situacin el diseador debe utilizar sus mejores capacidades de imaginacin. Un
mtodo podr servir de ayuda a travs de pautas generales, a travs del ejemplo
de diseos previos que han tenido xito y tambin del ejemplo de lo que no
funciona pero claro no mucho ms.

El campo de la metodologa de desarrollo de software no es nuevo. Sus orgenes
se pueden remontar a la famosa carta de Dijkstra Go To Statement Considered
Harmfull
4
y las publicaciones subsiguientes han seguido sus estndares.

Ciertamente, es relativamente fcil legislar sobre construccin de software, pero
es grande el peligro de producir reglas intiles, poco meditadas, o incluso dainas.

De acuerdo a las clases de Ingeniera de software han surgidos diversas
metodologas 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
tcnicas o procesos surgiendo otras ms complejas o ms utilizables en el
desarrollo del software

Entre los mtodos de anlisis Orientado a Objetos que han sobresalido algunos en
determinado tiempo y otros ms que hasta la fecha se siguen usando se listan los
siguientes, mostrados por orden aproximado de aparicin.

El mtodo de:
1. Coad-Yourdon,OMT,
2. Shaker-Mellor,
3. Martn-Odell,
4. Booch,
5. OOSE,
6. OSA,
7. Fusion,
8. Syntropy,
9. MOSES y
10. SOMA.

A partir de estos mtodos, hoy da escuchamos hablar de otros que prometen ser
mejor (OPEN y el UML) ya que estn basados y adems surgieron de los
conocimientos y experiencia de varios de los autores de los mtodos ya
mencionados.

Hasta este momento hemos visto la importancia del uso de tcnicas y
metodologas para el desarrollo del software pero ante todo el propsito sera que
este sea funcional y que cumpla con cierta calidad y no solo crear sin tener bases
slidas para hacerlo.

La produccin de software, una actividad en estado preindustrial, esencialmente
creativa y artesanal, por consecuencia difcilmente automatizable, sufre un
llamado vaci de productividad relativa
5
y requiere la racionalizacin al menos
del complejo entorno, por ahora mayoritario, de los sistemas de informacin (SI)
para la gestin de las organizaciones, privadas o pblicas.

Estas entidades siguen desarrollando mayoritariamente sus SI con recursos
propios; es decir, especializan un departamento de su organizacin
como proveedor informtico interno de los otros departamentos clientes (sin que
entre ambos actores suela haber otro contrato que un acuerdo tcito).

El estudio de las experiencias para incrementar la calidad y seguridad de
implantacin 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 clsico enfoque extensivo lleva a
estudiar el micro ciclo de cada SI aislado, y est creciendo en importancia y
complejidad con la extemalizacin del proveedor de SI y con la consecuente
formalizacin de su contrato con el cliente.

Con este enfoque mencionado es posible concluir que en la ingeniera se busca la
calidad; es decir, la ingeniera del software es la produccin 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, reutilizacin o reusabilidad y compatibilidad, aadio en
1995: fiabilidad, portabilidad y eficiencia), para finalmente hacer una declaracin
de principios de calidad de software a modo de decgolo
6
que por docentes
universitarios que se dedican a la disciplina de ingeniera de software y
descontado, los analistas y en los productos que crean. En esta especie de
decgolo, Meyer denomin los factores externos de calidad y cuya consecuencia
es la tarea central de la construccin de software orientado a objetos.

En general todos deseamos que los sistemas de software sean rpidos, fiables,
fciles 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 slo por profesionales de la
informtica que tienen acceso al cdigo fuente.

En ltima instancia, slo 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 grficos tardan aos en cargarse
o si la introduccin de datos errneos 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 diseadores y los implementadores deben
aplicar tcnicas internas no son un fin en si mismas, sino un medio para alcanzar
las cualidades externos que finalmente ser a travs de los factores internos.

As entonces concluyo que a pesar e no existe un estndar de la metodologia a
seguir al momento de desarrollar, el propsito de la ingeniera del software es
encontrar modos de construir software de calidad.




1
http://www-gris.det.uvigo.es/~jose/doctorado/introduccion/sld003.htm
2
http://www.uag.mx/66/Crisis.htm
3
Bertarnd Meyer, Construccin de software orientada a Objetos, pag. 629
4
La instruccin go to considerada novicia
5 Universidad Autnoma de Quertaro, Maestra en Ciencias Computacionales, Facultad de Informtica
Especialidad: Ingeniera de Software, Tcnicas y Metodologas en la produccin de Software
6
Aunque no es definida as por Meyer, se entiende que constituyen formalmente un Decgolo de la calidad
del Software, y asi proponer su aceptacin por la comunidad informtica: Decgolo de la calidad de
Software de Meyer