1) El documento habla sobre la historia del desarrollo de software y la crisis del software. 2) La crisis del software se refiere a la dificultad de escribir programas libres de defectos, comprensibles y verificables debido a la complejidad y cambios requeridos. 3) La crisis incluyó proyectos que no terminaban a tiempo, no cabían en el presupuesto, tenían baja calidad o no cumplían las especificaciones.

1. HISTORIA
CRISIS
METODOLOGÍA DE DESARROLLO

2. La historia del software como se ha visto, no surge con los equipos electrónicos, esta, está presente
desde el empleo de ábacos o sumadoras mecánicas. Sin embargo, en estos casos, el software no se
encuentra incorporado en el equipo. Es aportado por el operario. La máquina analítica de Charles
Babbage, incidentalmente, tuvo su software, y fue una amiga de éste, la legendaria lady
Lovelace, quien aportó el software que no se llegó a usar, dado que la máquina nunca se completó.
En el ENIAC el control de las operaciones estaba parcialmente integrado en el equipo. Dicho control
era realizado por un circuito que requería un alambrado específico para cada aplicación.
Imaginemos lo engorroso que resultaba realambrar el circuito cada vez que cambiaba el uso del
ENIAC.
Hasta este momento, no se percibía una diferencia sustancial entre el equipo y el control de las
operaciones. El concepto de programa de control almacenado en memoria, aportación
popularmente atribuida a John Von Neumann, precipitó el desarrollo de software. En éste se
perfilaron dos tendencias de desarrollo: los programas de aplicación y los de servicio. Estos últimos
tenían como propósito facilitar el desarrollo de programas a partir de programas. Algunos
programas de servicio fueron simples cargadores que permitieron emplear notaciones como el octal
o hexadecimal más compactas que el binario. Otros como los ensambladores simplificaron más el
proceso al reemplazar las notaciones numéricas con los símbolos mnemónicos que aportaron para
describir a cada instrucción de la máquina. El siguiente paso significativo fue la traducción de
fórmulas, que permitió el desarrollo de la historia del software y la descripción de los algoritmos con
el empleo de expresiones algebraicas.

3. Dicha traducción se realiza con programas que se denominan compiladores, generan programas que
al ejecutarse producen los resultados. Es importante destacar que en tanto los programas de
aplicación saturaron los recursos de los equipos, imponiendo sus requerimientos en cuanto a
velocidad, precisión en la aritmética y capacidad en los almacenamientos; los programas de servicio
repercutieron en la evolución de la arquitectura de los equipos (hardware). Entre las aportaciones
más notables, podemos citar el empleo de pilas y el reemplazo de referencias físicas por lógicas.
Con la pila (Push Down List), se da lugar al manejo recursivo de los procesos. Por ejemplo, esto
ocurre en una oficina administrativa, cuando se pospone la solución de un problema para resolver
otro de mayor exigencia.
El problema original se suspende y se aborda nuevamente cuando el de mayor exigencia ya ha sido
resuelto. Con el reemplazo de referencias físicas por lógicas, se obtuvo un incremento más real que
virtual de los recursos disponibles. Almacenamientos secundarios, registros operacionales, memoria
virtual, memoria cache e hizo translapes (overlay), son algunas de las técnicas que emplean este
concepto. El efecto es similar al de las operaciones bancarias nominales con que las instituciones de
crédito prestan varias veces su capital. Los elementos aportados por los programas de servicio, al
interrelacionarse configuran el sistema operativo con el cual se administran los recursos disponibles
en las computadoras y se establecen líneas de producción para el proceso de programas con una
mínima participación del operario: la automatización de la automatización. En los principios de la
historia del software, los sistemas operativos brotan como extensiones de los lenguajes.
Posteriormente, el fenómeno se invierte de modo que los sistemas operativos configuren el
ambiente en el que se desempeñan las aplicaciones y los programas de servicio.

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

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

6. CONCEPTOS GENERALES
HISTORIA
CARACTERÍSTICAS ESENCIALES
CLASIFICACIÓN

7. Metodología: Conjunto de procedimientos, técnicas, herramientas y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software.
Tarea: Actividades elementales en que se dividen los procesos.
Procedimiento: Definición de la forma de ejecutar la tarea.
Técnica: Herramienta utilizada para aplicar un procedimiento. Se pueden utilizar
una o varias.
Herramienta: Para realizar una técnica, podemos apoyarnos en las herramientas
software que automatizan su aplicación.
Producto: Resultado de cada etapa.

8. AÑO METODOLOGÍA
1968 Conceptos sobre la programación estructurada de
DIJKSTRA
1974 Técnicas de programación estructurada de
WARNIER y JACKSON
1975 Primeros conceptos sobre diseño estructurado de
MYERS y YOURDON
1977 Primeros conceptos sobre análisis estructurado
GANE y SARSON
1978 Análisis estructurado: DEMARCO y WEINBERG.
Nace MERISE
1981 SSADM (versión inicial)
Information Engineering (versión inicial)
1985 Análisis y Diseño estructurado para sistemas de
tiempo real de
WARD y MELLOR
1986 SSADM Versión 3

9. AÑO METODOLOGÍA
1987 Análisis y Diseño estructurado para
sistemas de tiempo real de
HATLEY y PIRHBAY
1989 METRICA (versión inicial)
1990 SSADM Versión 4
1993 METRICA Versión 2
1995 METRICA Versión 2.1

10. •Los resultados finales son impredecibles
•No hay forma de controlar lo que está sucediendo
Desarrollo Convencional (Sin Metodología) en el Proyecto
•Los cambios organizativos afectan negativamente
al proceso de desarrollo
•Programación estructurada
•Diseño estructurado
•Análisis estructurado
Desarrollo Estructurado •Especificaciones funcionales:
•Gráficas
•Particionadas
•Mínimamente redundantes

11. La esencia del desarrollo orientado a objetos es la identificación y organización de conceptos del
dominio de la aplicación y no tanto de su representación final en un Lenguaje de programación.
CARACTERÍSTICAS ASPECTOS POSITIVOS
•Se eliminan fronteras entre
•Son interactivas e
fases debido a la naturaleza
Incrementales.
iterativa del desarrollo
•Fácil de dividir el sistema en
Orientado al objeto.
varios subsistemas
•Aparece una nueva forma de
independientes.
concebir los lenguajes de
•Se fomenta la reutilización de
programación y su uso al
componentes.
Incorporarse bibliotecas de
clases y otros componentes
reutilizables.
•Hay un alto grado de iteración
y solapamiento, lo que lleva a
una forma de trabajo muy
Dinámica.

12. •Existencia de reglas predefinidas
•Cobertura total del ciclo de desarrollo
•Verificaciones intermedias
•Planificación y control
•Comunicación efectiva
•Utilización sobre un abanico amplio de proyectos
•Fácil formación
•Herramientas CASE
•Actividades que mejoren el proceso de desarrollo
•Soporte al mantenimiento
•Soporte de la reutilización de software

13. Estructuradas Orientadas a Objetos Para Sistemas de Tiempo Real
O. Procesos Mixtas
O. Datos
Jerárquicas No Jerárquicas

14. FASES DEL ANÁLISIS ESTRUCTURADO
Método de DeMarco Método de Gane y Sarson
Especificación: 1. Construir el modelo físico 1. Construir el modelo lógico
•Diagramas de Flujo de Datos actual (DFD físico actual) actual
•Diccionario de Datos 2. Construir el modelo lógico (DFD lógico actual)
actual (DFD lógico actual) 2. Construir el modelo del nuevo
•Especificaciones de procesos
3. Crear un conjunto de modelos sistema: elaborar una
físicos alternativos especificación
4. Estimar los costes y tiempos estructurada y construir un
de cada opción modelo
5. Seleccionar un modelo lógico de datos en tercera forma
Metodología de Yourdon/Constantine 6. Empaquetar la especificación normal que exprese el contenido
•Realizar los DFD del sistema de
•Realizar el diagrama de estructuras los almacenes de datos.
•Evaluar el diseño 3. Seleccionar un modelo lógico
•Preparar el diseño para la implantación 4. Crear el nuevo modelo físico
del
sistema
5. Empaquetar la especificación

15. JERARQUICOS NO JERARQUICOS
• La estructura de control del (Ingeniería de la
programa debe ser jerárquica Información)
y se debe derivar de la •Planificación: construir una
estructura de datos del arquitectura de la Información
programa y una estrategia que soporte
• El proceso de diseño los objetivos de la
consiste en definir primero las organización
estructuras •Análisis: comprender las
de los datos de entrada y áreas del negocio y
salida, mezclarlas todas en determinar los requisitos del
una estructura jerárquica de sistema
programa y después ordenar •Diseño: establecer el
detalladamente la lógica comportamiento del sistema
procedimental para que se deseado por el usuario y que
ajuste a esta estructura sea alcanzable por la
• El diseño lógico debe tecnología
preceder y estar separado del •Construcción: construir
diseño físico sistemas que cumplan los tres
niveles anteriores

16. “Revolucionarios” o “puros” “Sintetistas” o “evolutivos”
Manejo de interrupciones Datos continuos o discretos
Gestión de procesos concurrentes
Respuesta oportuna ante eventos externos Comunicación y sincronización entre tareas