UNIVERSIDAD DE GUAYAQUIL

NOMBRE: MARVIN ABEL RAMIREZ DE LA CRUZ

CURSO: SOS.MA 1-1

FECHA: 31 DE OCTUBRE DE 2018

ASIGNTURA: Introducción a la Ingeniería en Software

DOCENTE: Ing. Yelena Chávez

INVESTIGACION:

La crisis del software

Y el software en la actualidad.

2018-2019
 2

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 ensamblador

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.
 3

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 mitos son:

 Ya tenemos el mejor libro para construir software,

 lo último 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.
 4

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:
 5

 Coad-Yourdon,OMT,
 Shaker-Mellor,
 Martín-Odell,
 Booch,
 OOSE,
 OSA,
 Fusion,
 Syntropy,
 MOSES y
 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
 6

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.
 7

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

El Software en la Actualidad

El desarrollo de Software, es posiblemente una de las áreas que van avanzando a pasos
agigantados con el paso del tiempo, pero también con mayor discreción, si bien es cierto
que hoy la sociedad puede disfrutar de una gran cantidad de software con muchísimas
funciones, esta nunca se percata de la existencia del desarrollo del software como tal, para
la sociedad el software hoy en día es importante para poder subsistir, sin importar de
donde provenga.

Incluso las personas están tan acostumbrados a hacer uso de diversos tipos de software,
que sin ellos el cambio sería sumamente radical en sus vidas.

Bibliografía.

https://okhosting.com/blog/la-importancia-del-software-en-la-sociedad/

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

http://www-gris.det.uvigo.es/~jose/doctorado/introduccion/sld003.htm

http://www.uag.mx/66/Crisis.htm