Documentos de Académico
Documentos de Profesional
Documentos de Cultura
© Isdefe
c/ Edison, 4
28006 Madrid.
Diseño y fotomecánica:
HB&h Dirección de Arte y Edición
Infografía de portada:
Salvador Vivas
Impresión:
Closas Orcoyen S.L.
ISBN: 84-89338-10-8
Depósito legal: M- -1996
Printed in Spain - Impreso en España.
3
4
INGENIERÍA DE SISTEMAS DE SOFTWARE
5
PRÓLOGO
ÍNDICE GENERAL
1. LA COMPLEJIDAD DE LOS SISTEMAS DE SOFTWARE 13
1.1. Introducción 14
1.2. El papel de los recursos software en sistemas complejos 15
1.3. Una perspectiva histórica 17
1.4. Enfoques complementarios de los sistemas de software 19
1.5. Caracterización de los sistemas de software 24
1.5.1. Características relevantes de un sistema de software 25
1.5.2. La utilidad de un sistema de software 28
1.5.3. El valor añadido del software 30
1.6. Ingeniería de sistemas de software 31
1.7. Resumen 32
3. TECNOLOGÍAS DE SOFTWARE 73
3.1. Introducción 74
3.2. Concepto de tecnología de software 75
3.3. Panorama de los componentes tecnológicos 81
3.3.1. Notaciones 83
3.3.2. Marco de razonamiento sobre el sistema en desarrollo 85
3.3.3. Métodos de desarrollo 87
3.3.4. Herramientas de soporte: entornos de desarrollo 89
3.3.5. Directrices de aplicación industrial 96
3.3.5.1. Componentes reutilizables 97
3.3.5.2. Consolidación del conocimiento previo 98
3.4. Ejemplos de tecnologías de software 98
3.4.1. Tecnologías de desarrollo estructurado 99
3.4.2. Tecnologías orientadas a objetos 102
3.5. Resumen 104
REFERENCIAS 205
BIBLIOGRAFÍA 211
GLOSARIO 215
12
INGENIERÍA DE SISTEMAS DE SOFTWARE
13
1
La complejidad
de los sistemas
de software
14
INGENIERÍA DE SISTEMAS DE SOFTWARE
1.1. Introducción
Basta echar una ojeada a nuestro alrededor para ver cómo estos
sistemas de software están teniendo una importancia creciente,
responsabilizándose de los éxitos y fracasos de muchos sistemas
basados en ellos y siendo también responsables de los éxitos y fracasos
de las empresas que los construyen o utilizan.
• La génesis (1965-1975).
Ligada a la crisis de la programación se plantea la necesidad
de controlar el proceso de desarrollo. Se definen modelos de
ciclo de vida como una referencia en la que enmarcar las activida-
des requeridas (se analizarán en el Capítulo 2). El concepto de
ciclo de vida en cascada surge de la necesidad del Departamento
de Defensa de EE.UU. de disponer de una documentación
normalizada para todas las etapas del desarrollo y poder con-
trolar en base a ella a los suministradores de productos software.
18
INGENIERÍA DE SISTEMAS DE SOFTWARE
• La consolidación (1975-1985).
El control de las actividades de desarrollo debería permitir
gestionar el proceso. Durante esta etapa aparecen métricas
para estimar a priori el coste o el tamaño del sistema; se difunde
el uso de métodos de desarrollo. Con ello, el programador se
convierte en analista, diseñador o gestor. Se vislumbra la idea
de ingeniero (software).
A) La infraestructura de ejecución.
Todo sistema de software requiere un procesador que
interprete o ejecute sus instrucciones y el apoyo de otros
programas que le ofrezcan una serie de servicios útiles
(como los ofrecidos por el sistema operativo).
B) El proceso de desarrollo.
No todos los sistemas de software se conciben y desarrollan
de la misma manera. Su desarrollo, desde las primeras ideas
sobre lo que deberían hacer y las restricciones de operación,
hasta su entrega al usuario, pasan por una serie de fases. A
estas fases, junto con las que siguen una vez entregado el
producto al usuario hasta su retirada del mercado se les
denomina globalmente ciclo de vida.
C) La evolución.
La atención sobre un sistema de software no termina cuando
se entrega al usuario; de hecho, comienza un largo proceso
en el que el sistema es mantenido con el fin de adaptarlo a
las necesidades, reparar o completar la funcionalidad reque-
rida y, sobre todo, asegurar que sigue siendo útil en el entorno
de ejecución.
D) El dominio de la aplicación.
Muchos sistemas de software comparten una misma
problemática con otros sistemas similares o pertenecientes
al mismo tipo de aplicación. Por ejemplo, los sistemas de
23
La complejidad de los sistemas de software
1.7. Resumen
2
Modelos de ciclo
de vida
36
INGENIERÍA DE SISTEMAS DE SOFTWARE
2.1.2. La organización
• Definición de requisitos.
• Diseño.
• Implementación.
• Transferencia del producto.
• Evolución.
2.3.2. Diseño
2.3.3. Implementación
2.3.5. Evolución
PRINCIPALES Determinar el entorno operativo Construcción del modelo lógico Construcción del modelo físico Diseño de módulos Instalación
Pruebas de integración
Pruebas de sistema
ENTREGABLES Documento de requisitos de Documento de requisitos Documento de diseño Documento de diseño detallado Documento de transferencia
usuario (DRU) software (DRS) arquitectónico (DDA) (DDD) SW
Manual de usuario
PRINCIPALES
aprobación aprobación aprobación aprobación
hitos DRU DRS DDA DDD
El desarrollo del sistema pasa por una serie de ciclos en los que
tanto el conocimiento del sistema a realizar como el propio sistema
van avanzando hasta obtener el producto final. En la última espiral se
prosigue con un desarrollo convencional al haberse eliminado las
incertidumbres en las espirales anteriores.
La idea clave detrás del modelo es asegurar que los aspectos menos
conocidos o más críticos sean realizados antes, en la suposición de que
de poco sirve completar partes poco críticas si éstas pueden verse
modificadas o invalidadas por las partes críticas. El uso de prototipos es
fuertemente promovido (aunque basado en prototipos desechables). En
este sentido, el mismo Boehm indica que la característica esencial es la
orientación hacia la identificación y resolución de riesgos [9].
2.7. Resumen
3
Tecnologías
de software
74
INGENIERÍA DE SISTEMAS DE SOFTWARE
3.1. Introducción
3.3.1. Notaciones
3.5. Resumen
4
Tecnologías
para desarrollo
de sistemas
de tiempo real
110
INGENIERÍA DE SISTEMAS DE SOFTWARE
4.1. Introducción
ciones y puede que con ello, sea más aceptado por el usuario final. En
un STR es necesario asegurar el cumplimiento de todos los plazos
siempre y no «casi siempre». Asegurar que estos plazos se cumplen
puede llevar a sacrificar prestaciones globales.
B) Método Statemate.
1) Notación SA/RT.
2) Notación Statemate.
4.4. Resumen
5
Gestión del
desarrollo
del software
146
INGENIERÍA DE SISTEMAS DE SOFTWARE
5.1. Introducción
D) Gestión de riesgos.
más amplia (un proceso formalmente verificado puede que no sea válido
al no satisfacer otros requisitos de adecuación que hayamos esta-
blecido).
1) Funcional.
2) Estructural.
f) manual de instalación,
b) Documentación de diseño.
5.4. Métricas
B) Complejidad estimada.
C) Robustez.
A) Análisis de riesgos.
B) Resolución de riesgos.
5.8. Resumen
6
La mejora
del proceso
y la adopción de
nuevas tecnologías
de software
188
INGENIERÍA DE SISTEMAS DE SOFTWARE
6.1. Introducción
6.4. Resumen
Referencias
206
INGENIERÍA DE SISTEMAS DE SOFTWARE
[14] Harel, D., Bitting the Silver Bullet, IEEE Software, 1993.
Bibliografía
212
INGENIERÍA DE SISTEMAS DE SOFTWARE
Glosario
216
INGENIERÍA DE SISTEMAS DE SOFTWARE