CAPÍTULO 2

Ingeniería del Software

08/12/21 Ing. Paola Pesántez Cabrera

AGENDA
• Tareas profesionales
• Cursos recomendados
• Introducción
• Principales áreas involucradas
– Implementación de Sistemas de Software
– Metodologías de Desarrollo
– Diseño arquitectónico de sistemas
– Pruebas sobre el software
– Medición y Usabilidad del software
• Aplicaciones
2
Tareas Profesionales (I)
• El Ingeniero de Software es un profesional con sólidas
bases metodológicas en el desarrollo de software a
pequeña y gran escala, en la tecnología de inteligencia de
negocios y en las principales herramientas de
programación, así como en la interacción con los líderes de
la organización.
• Podrá además definir alcances, costos, tiempos, recursos y
factibilidad para un proyecto de software, así como
proponer soluciones de software, globales o parciales, que
permitan el control de los procesos, la mejora en el proceso
de toma de decisiones o soluciones innovadoras para la
industria y el entretenimiento.
• Puede laborar solo o formando parte de un equipo de
trabajo multifuncional, polifuncional o multiprofesional.

3
Tareas Profesionales (II)
Será capaz de desempeñarse en cualquiera de los roles involucrados
en un proceso de desarrollo de software como:
• Administrador de proyecto
• Líder de proyecto
• Analistas de Requerimientos: Trabajarán con el cliente
desglosando en requerimientos separados lo que éste desea.
• Diseñadores: Generan una descripción a nivel de sistema de lo
que éste debe hacer.
• Programadores: Escriben las líneas de código que implementan
lo que los requerimientos especifican.
• Probadores: Ayudan a detectar defectos que los programadores
pasan por alto.
• Entrenadores: Enseñan a los usuarios cómo se utiliza el sistema.
• Bibliotecarios: Preparan y almacenan los documentos que se
usan durante la vida del sistema.

4
Tareas Profesionales (III)
• Habilidades para:
– Trabajar como parte de un equipo en el desarrollo y evolución
de productos de software.
– Comprender, aplicar y comunicar el proceso para determinar las
necesidades del cliente y traducirlos a requisitos de software.
– Conciliar objetivos en conflicto, considerando compromisos con
las limitaciones de costo, tiempo, conocimiento, sistemas
existentes y de las organizaciones involucradas.
• Actitudes de:
– Liderazgo en equipos de trabajo multidisciplinarios.
– Perseverancia en la solución de problemas.
– Capacidad de mantenerse actualizado en su área de trabajo.
– Responsabilidad y ética en su desempeño profesional.
– Conducta emprendedora e innovadora.
– Aprendizaje autodidacta.

5
Tareas Profesionales (IV)
Siendo sus competencias:
• Gestionar el proyecto software y el uso de las TIC's aplicando
políticas y procedimientos que garanticen seguridad, control y
evaluación de la información cumpliendo con el marco legal
vigente nacional e internacional.
• Desarrollar proyectos software aplicando el proceso software
utilizando estándares y métricas internacionales que garanticen
la calidad de los productos generados, liderando grupos de
trabajo con creatividad, eficiencia, eficacia y responsabilidad
profesional.
• Validar y verificar los productos software.
• Analizar, diseñar y administrar bases de datos, definir políticas de
seguridad, respaldos y recuperación de las mismas, garantizando
su confidencialidad, integridad y disponibilidad.
• Administrar las redes de datos a través de técnicas y
herramientas de soporte para tecnologías libres y propietarias en
diferentes plataformas, aplicando algoritmos de optimización.
6
Cursos Recomendados
• Ciencias básicas
• Introducción a la Informática
• Programación
• Bases de datos
• Sistemas Operativos
• Sistemas de Información
• Lenguajes de Programación
• Ingeniería de Software
• Sistemas de Información Gerencial
• Sistemas de Gestión Empresarial
• Programación Web
7
Introducción
• Ingeniería de software es la disciplina o área de la
informática que ofrece métodos y técnicas para
desarrollar y mantener software de calidad.
• Trata con áreas muy diversas de la informática y de
las ciencias de la computación, abordando todas las
fases del ciclo de vida del desarrollo de cualquier
tipo de sistemas de información y aplicables a
infinidad de áreas: negocios, investigación científica,
medicina, producción, banca, control de tráfico,
meteorología, derecho, Internet, etc.

8
Ingeniería de Software
• Estudio de los principios y metodologías para el
desarrollo y mantenimiento de sistemas software
(Zelkovitz, 1978) .
• Aplicación práctica del conocimiento científico al
diseño y construcción de programas y a la
documentación asociada requerida para desarrollar,
operar y mantenerlos ( Bohem, 1976).
• Establecimiento de los principios y métodos de la
ingeniería a fin de obtener software de modo
rentable, que sea fiable y trabaje en máquinas
reales (Bauer, 1972).

9
Que es el Software ?
Programas de cómputo y su documentación asociada
• Productos genérico
– Productos que son producidos por una organización
para ser vendidos al mercado.
• Productos hechos a medida
– Sistemas que son desarrollados bajo pedido a un
desarrollador específico.
• La mayor parte del gasto del software es en productos
genéricos, pero hay más esfuerzo en el desarrollo de
los sistemas hechos a medida.
10
Características de los Productos de Software

• Mantenibles
– Debe ser posible que el software evolucione y que siga
cumpliendo con sus especificaciones.
• Confiabilidad
– El software no debe causar danos físicos o económicos en
el caso de fallos.
• Eficiencia
– El software no debe desperdiciar los recursos del sistema.
• Utilización adecuada
– El software debe contar con una interfaz de usuario
adecuada y su documentación.

11
2.3.1

IMPLEMENTACIÓN DE
SISTEMAS DE SOFTWARE
El Proceso de Software
• Conjunto estructurado de actividades requeridas para
desarrollar un sistema de software.
C – Análisis y definición de requerimientos: que debe hacer el
I
software y cuales son sus especificaciones de desarrollo.
C
– Diseño: transformación del problema en una solución
comprendiendo el hardware y software concretos.
L
– Desarrollo: del sistema de software.
O
– Pruebas: verificar que el software hace lo que el cliente
D pide.
E – Instalación: entregar el sistema al usuario y asegurar su
operabilidad
V – Mantenimiento: reparar fallos en el sistema cuando sea
I descubiertos, cambiar/adaptar el software a las demandas.
D
A

13
Características del proceso
• Entendible
– Se encuentra el proceso bien definido y es entendible?

• Visible
– El proceso es visible al exterior?

• Soportable
– Puede el proceso ser soportado por herramientas CASE?

• Aceptable
– El proceso es aceptado por aquellos involucrados en el?

14
Características del proceso (II)
• Confiable
– Los errores del proceso son descubiertos antes de que se
conviertan en errores del producto?

• Robusto
– Puede continuar el proceso a pesar de problemas inesperados?

• Mantenible
– Puede el proceso evolucionar para cumplir con los objetivos
organizacionales?
• Rapidez
– Que tan rápido puede producirse el sistema?

15
Problemas en el Modelo del Proceso

• Normalmente, las especificaciones son incompletas o

anómalas.
• No existe una distinción precisa entre la especificación,
el diseño y la manufactura.
• Solo hasta que el sistema se ha producido se puede
probar.
• El software no se puede remplazar siempre durante el
mantenimiento.

16
2.3.2

METODOLOGÍAS DE
DESARROLLO
Evolución del Software

• 1.-Son tarjetas perforadas

• 3.- bajo costo de pc
• - sistemas distribuhidos.- comienzan a trabajar en red
•
18
 Metodologías de Desarrollo de Software

• Conjunto de pasos y procedimientos que deben

seguirse para el desarrollo de software.

• Conjunto de filosofías, fases, procedimientos, reglas,

técnicas, herramientas, documentación y aspectos de
formación para los desarrolladores de SI. [Maddison,
1983]

• Conjunto de procedimientos, técnicas, herramientas y

soporte documental que ayuda a los desarrolladores a
realizar nuevo software.

19
¿Por qué aplicar una metodología? (Beneficios)

• Con una metodología se intentan cubrir tres

necesidades principales:
– Sistemas de mayor calidad
– Proceso de desarrollo (modelo de procesos)
definido  productos intermedios en cada fase 
mejor planificación y gestión del proyecto
• desarrollos más rápidos.
• recursos adecuados.

– Proceso estándar en la organización  facilidad de

cambios de personal. Contratación del personal
20
 Paradigmas de las metodologías de desarrollo
de software
• Modelo de proceso: desarrollo del software
– Fases y subfases, actividades,
tareas (actividades elementales).
• Procedimientos:
– Define la forma de llevar a cabo las tareas.
– Vínculo de Comunicación entre usuarios y
desarrolladores.
– Combinación de herramientas y técnicas que, juntas,
dan como resultado un producto particular.
• Productos:
– Obtenidos como resultado de seguir un Procedimiento.
– Pueden ser Intermedios o Finales.
21
 Paradigmas de las metodologías de desarrollo
de software (II)
• Técnicas:
– Se utilizan para aplicar un procedimiento. Es un
procedimiento formal para producir algún
resultado.
– Pueden ser Gráficas y/o Textuales
– Determinan el formato de los productos resultantes
en cada tarea.
• Herramientas de software:
– instrumento sistema automatizado para realizar
algo de la mejor manera posible.
– Proporcionan soporte a la aplicación de las
Técnicas.
22
¿Qué es un método de desarrollo de software?

• Definición alternativa de (Sommerville 2002)

“Un método de ingeniería de software es un enfoque
estructurado para el desarrollo de software cuyo
propósito es facilitar la producción de software de
alta calidad de una forma costeable.” .

• Todos los métodos se basan en la idea de modelos

gráficos de desarrollo de un diseño del sistema y en
el uso de estos modelos como un sistema de
especificación o diseño.

23
Metodologías - Clasificación

ENFOQUE TIPO DE FORMALIDAD

SISTEMA

ESTRUCTURADOS
Orientados a procesos
Orientados a datos GESTIÓN NO FORMAL
Jerárquicos
No jerárquicos
Mixtos

OO TIEMPO REAL FORMAL

24
Metodologías Estructuradas
• Proponen la creación de modelos del sistema que
representan:
– Los procesos
– Los flujos , lo q hace dentro del los procesos
– La estructura de los Datos flujos manejan datos
de una manera descendente
(top-down).
Esta visión se puede enfocar
en los procesos, en lo datos
o en ambos.

25
Metodologías Estructuradas Orientadas a
Procesos
• Fundadas sobre el modelo básico:

• Se enfocan en la parte del proceso.

• Autores: DEMARCO, GANE&SARSON, YOURDON
• Especificación estructurada basada en:
– Diagramas de flujo de datos (DFD). Del sistema
– Diccionario de Datos. Describe los datos
– Especificaciones de Procesos. Entrada proceso salida
• Se apoyan en técnicas gráficas para obtener:
– Especificación estructurada (tiene q ser secuencial)
– Modelo gráfico, particionado, descendente y jerárquico
de los procesos del sistema y de los datos utilizados por
éstos. 26
 Metodologías Estructuradas Orientadas
a Datos Jerárquicos
• Fundadas sobre el modelo básico: entrada/proceso/salida.
• Autores: JACKSON, CAMERON, WARNIER
• Se definen las estructuras de datos y a partir de estas se
derivan los componentes procedimentales:
– La estructura de control del programa debe ser
jerárquica y se debe derivar de la estructura de datos del
programa.
– El proceso de diseño consiste en definir primero las
estructuras de los datos de entrada y salida, mezclarlas
todas en una estructura jerárquica de programa y
después ordenar detalladamente la lógica
procedimental para que se ajuste a esta estructura.
– El diseño lógico debe preceder y estar separado del
diseño físico.

27
 Metodologías Estructuradas Orientadas
a Datos No Jerárquicos
• Los datos son el corazón del S.I. El modelo esta formado por
el conjunto de entidades básicas y las interrelaciones entre
ellas.
• Autor: MARTIN y FINKELSTEIN
• Cuatro etapas:
– Planificación: construir una arquitectura de la
Información y una estrategia que soporte los objetivos
de la organización.
– Análisis: comprender las áreas del negocio y determinar
los requisitos del sistema.
– Diseño: establecer el comportamiento del sistema
deseado por el usuario y que sea alcanzable por la
tecnología.
– Construcción: construir sistemas que cumplan los tres
niveles anteriores.
28
 Metodologías Orientadas a Objetos
• Cambio en los principios de las metodologías estructuradas:
– Estructurado: Examinar el sistema desde las funciones y
tareas.
– OO: Modelado del Sistema examinando el dominio del
problema como un conjunto de objetos que interactúan
entre sí.
• Objetos: Encapsulan Funciones + Datos
• Enfoques:
– “Revolucionarios” o “Puros”: La OO se entiende como
un cambio profundo de las metodologías estructuradas
que se ven como obsoletas. OOD (Booch), CRC/RDD
(Wirfs-Brock)
– “Sintetistas” o “Evolutivos”: Análisis y Diseño
Estructurado se consideran como la base para el
desarrollo OO. OMT, UML
29
 Tiempo Real
• Sistemas que controlan un ambiente recibiendo datos,
procesándolos y devolviéndolos con la suficiente rapidez
como para influir en dicho ambiente en ese momento.
• Características:
– Gestión de procesos concurrentes.
– Manejo de interrupciones y prioridades.
– Comunicación y sincronización entre tareas.
– Respuesta oportuna ante eventos externos.
– Datos continuos o discretos.
• Metodologías:
– Ampliaciones a la notación del análisis estructurado.
– Metodologías OO para Sistemas Tiempo Real.
30
 Principales Metodologías - MERISE
• Ministerio de Industria Francés. Primera versión: 1972-1976
• FASES: orientada a datos no jerárquicos
1. Estudio preliminar
• Análisis de situación actual.
• Propuesta de solución global.
2. Estudio detallado
• Definición funcional de la solución.
3 . Implementación
• Distribución de datos y tratamientos.
• Codificación y verificación de los programas.
4 . Realización y puesta en marcha
• Implementación de medios técnicos (materiales).
• Implementación de medios organizativos (formación del
personal, lanzamiento de la aplicación).
31
 Principales Metodologías – SSADM (orientada a datos
elementos y procesos)

• Gobierno británico. Primera versión: 80’s

1. Énfasis en los usuario (requisitos y participación).

2. Definición del proceso de producción (qué hacer, cuándo y
cómo).
3. Tres puntos de vista: Datos, eventos y procesos.
4. Máxima flexibilidad en herramientas y técnicas de
implementación.
• Proporciona un conjunto de procedimientos para llevar a cabo el
análisis y diseño.

32
 Principales Metodologías – METRICA
orientada a datos jerarquicos y no gerarquicos

• Administración Pública Española. Primera versión: 1989.

• Fases:
– 0 . Plan de Sistemas de información
– 1 . Análisis de Sistemas
– 2 . Diseño de Sistemas
– 3 . Construcción de Sistemas
– 4 . Implantación de Sistemas
• Metodología estructurada en fases, módulos,
actividades, tareas para el desarrollo del sistema;
productos obtenidos en cada tarea.
• Se enfoca directamente en el desarrollo y no soporta
tareas como gestión de proyectos, de configuración o
calidad.
33
Principales Metodologías – PROCESO UNIFICADO

34
 Adaptación de la metodología
• No existe una metodología “universal” o “ideal”
– Metodologías diferentes tienen distintas áreas donde
son aplicables
• Metodologías OO son adecuados para sistemas
interactivos, pero no para sistemas en tiempo real
con requisitos severos.
• La metodología está condicionada por el tamaño y
estructura de la organización, y el tipo de aplicaciones.
• “No es razonable pensar que dos organizaciones
utilicen la misma metodología sin realizar cambios
sobre ella”.
35
2.3.2.2

MODELOS DE DESARROLLO
DE SOFTWARE
Modelos de Desarrollo de Software
• Representación formal o simplificada del proceso de software.
• Modelos Genéricos:
– Modelo de Cascada: Separar en distintas fases de especificación
y desarrollo.
– Modelo V: Variación del modelo anterior que demuestra cómo se
relacionan las actividades de prueba con el análisis y diseño.
– Desarrollo Evolutivo: La especificación y el desarrollo están
intercalados.
– Prototipado: Permite que todo o algunas partes del sistema se
construyan para comprender o aclarar algunos aspectos.
– Especificación Operacional: Los requerimientos del sistema son
evaluados o ejecutados en una forma que demuestra el
comportamiento del sistema.
– Modelo de Transformación: Intenta reducir las oportunidades
de error eliminando pasos del desarrollo.

37
Modelo de Cascada
Definición de
Requerimientos

Diseño del Software

y del Sistema

Implementación y
Prueba de unidades

Integración y Prueba
del Sistema

Operación y
Mantenimiento

38
Modelo V

Análisis de Operación y
Requerimientos Mantenimiento

Prueba de Aceptación
Diseño del Sistema

Prueba del Sistema

Diseño del Programa

Pruebas Unitarias y
de Integración

Codificación

39
Desarrollo Evolutivo
Actividades
Concurrentes

Versión
Especificación Inicial

Descripción Desarrollo Versiones

del sistema Intermedias

Versión
Validación
Final

40
Prototipado

Lista de Lista de Lista de

Revisiones Revisiones Revisiones

revisar revisión del

prototipo usuario/cliente

Prototipar los Prototipar el Prototipar el

Sistema Probar
Requerimientos Diseño

Requerimientos del
Sistema Sistema
(a veces informal) Entregado

41
 Especificación Operacional

Ejecutar y
revisar

Especificación Especificación
Operacional Transformada PRUEBA
(Orientada al problema) (Orientada a la implementación)

Requerimientos del
Sistema Sistema
(a veces informal) Entregado

42
Modelo de Transformación

Comparar con
requerimientos; REGISTRO FORMAL DEL
actualizar cuando DESARROLLO
se necesite
Secuencia de transformaciones
con su justificación
Transformación
n…

Transformación
2

Especificación Transformación
PRUEBA
Formal 1

Requerimientos del
Sistema Sistema
(a veces informal) Entregado

43
Problemas y Riesgos con los Modelos
• Cascada.
– Alto riesgo en sistemas nuevos debido a problemas
en las especificaciones y en el diseño.
– Bajo riesgo para desarrollos bien comprendidos
utilizando tecnología conocida.
• Prototipado.
– Bajo riesgo para nuevas aplicaciones debido a que
las especificaciones y el diseño se llevan a cabo paso
a paso.
– Alto riesgo debido a falta de visibilidad

• Evolutivo.
– Alto riesgo debido a la necesidad de tecnología
avanzada y habilidades del grupo desarrollador.
44
Modelo de Proceso de Espiral
Evaluar alternativas,
Determinar objetivos identificar y resolver
alternativas y riesgos
restricciones Análisis de
Riesgos
Análisis de
Riesgos

Análisis de
Riesgos Prototipo
Prototipo Operacional
Análisis Prototipo 3
de Proto 2
REVISIÓN Riesgos tipo 1
Simulaciones, modelos y benchmarks
Plan de requerimientos
Concepto de
Plan del ciclo de vida
Operación Requeri
mientos de Diseño Diseño
SW del Detallado
Plan de Validación de Producto Codificación
Desarrollo Requerimientos
Prueba de
Plan de Integración Diseño Unidades
Prueba de
y Prueba V &V
Prueba de Integración
Planificar la
Aceptación Desarrollar y verificar
siguiente fase
Servicio el siguiente nivel
del producto

45
Modelo de Espiral
• Ventajas
– Centra su atención en la reutilización de componentes y
eliminación de errores en información descubierta en fases
iniciales.
– Los objetivos de calidad son el primer objetivo.
– Integra desarrollo con mantenimiento.
– Provee un marco de desarrollo de hardware/software.
• Problemas
– El desarrollo contractual especifica el modelo del proceso y
los resultados a entregar por adelantado.
– Requiere de experiencia en la identificación de riesgos.
– Requiere refinamiento para uso generalizado.
46
Visibilidad del Modelo
MODELO DE PROCESO VISIBILIDAD DEL PROCESO

Modelo de Cascada Buena visibilidad, cada actividad

produce un documento o resultado

Desarrollo Evolutivo Visibilidad pobre, muy caro al producir

documentos en cada iteración.

Modelos Formales Buena visibilidad, en cada fase deben

producirse documentos.

Desarrollo orientado a la reutilización Visibilidad moderada. Importante

contar con documentación de
componentes reutilizables.

Modelo de Espiral Buena visibilidad, cada segmento y

cada anillo del espiral debe producir un
documento.

47
2.3.3

PRUEBAS SOBRE EL
SOFTWARE
Introducción – Términos Utilizados
• Verificación de Software: Determinar si los
productos de una fase dada satisfacen las
condiciones impuestas al inicio de la fase.
– ¿Estamos construyendo correctamente el
producto?
• Validación de Software: Evaluación de un sistema o
uno de sus componentes durante o al final de su
desarrollo para determinar si satisface los
requisitos.
– ¿Estamos construyendo el producto correcto?

49
Términos Utilizados (II)
• Pruebas (test): «una actividad en la cual un sistema o uno
de sus componentes se ejecuta en circunstancias
previamente especificadas, los resultados se observan y
registran y se realiza una evaluación de algún aspecto».
• Caso de Prueba (test case): «un conjunto de entradas,
condiciones de ejecución y resultados esperados
desarrollados para un objetivo particular».
• Defecto (defect, fault, «bug»): «un defecto en el software
como, por ejemplo, un proceso, una definición de datos o
un paso de procesamiento incorrectos en un programa».
• Fallo (failure): «La incapacidad de un sistema o de alguno
de sus componentes para realizar las funciones requeridas
dentro de los requisitos de rendimiento especificados ».

50
Términos Utilizados (III)
• Error (error): La diferencia entre un valor calculado,
observado o medido y el valor verdadero,
especificado o teóricamente correcto.
– Un defecto
– Un resultado incorrecto
– Una acción humana que conduce a un resultado
incorrecto .

51
Recomendaciones
• Cada caso de prueba debe definir el resultado de salida
esperado.
• El programador debe evitar probar sus propios
programas, ya que desea demostrar que funcionan sin
problemas.
• Al generar casos de prueba, se deben incluir tanto datos
de entrada válidos y esperados como no válidos e
inesperados.
• Las pruebas deben centrarse en dos objetivos:
– Probar si el software no hace lo que debe hacer.
– Probar si el software hace lo que no debe hacer, es
decir, si provoca efectos secundarios adversos.

52
El Proceso de Prueba

53
Técnicas de Diseño de Casos de Prueba
• Utilizamos técnicas para conseguir una confianza aceptable en
que se detectarán los defectos existentes.
• Equilibrio entre los recursos empleados y la confiabilidad de los
casos de prueba.
• Elegir los casos de prueba que puedan representar a los demás.
• La elección no debe ser al azar.
• Existen tres enfoques para el diseño de casos de prueba:
– El enfoque estructural o de caja blanca
– El enfoque funcional o de caja negra
– El enfoque aleatorio consiste en
utilizar modelos (en muchas
ocasiones estadísticos) que
representen las posibles entradas
al programa para crear a partir de ellos los casos de prueba.

54
Ejecución de las Pruebas

55
Ciclo de Vida de Pruebas

56
Pruebas de Unidad
• Puede abarcar desde un módulo, a un
grupo de pocos módulos o un programa
completo.
• Las pruebas de unidad suelen ser
realizadas por personal de desarrollo.
• Utilizar el enfoque práctico ya visto.

57
Pruebas de Integración
• Ligadas a la forma prevista de integrar los distintos
componentes del software hasta contar con el
producto global que debe entregarse.
• Tipos de Integración
– Incremental (ascendente y descendente): Se
combina el siguiente módulo que se debe
probar con el conjunto de módulos que ya están
probados
– No Incremental: Se prueba cada módulo por
separado y, luego, se integran todos de una vez
y se prueba el programa completo.
58
Pruebas del Sistema
• Verifica:
– Cumplimiento de todos los requisitos
funcionales, considerando el producto software
final al completo, en un entorno de sistema.
– El funcionamiento y rendimiento en las
interfaces hardware, software, de usuario y de
operador.
– Adecuación de la documentación de usuario.
– Ejecución y rendimiento en condiciones límite y
de sobrecarga.

59
Pruebas de Aceptación
• Objetivo
– Comprobar si el producto está listo para ser
implantado para el uso operativo en el entorno
del usuario.
• Características
– Participación del Usuario.
– Está enfocada hacia la prueba de los requisitos
de usuario especificados.
– Está considerada como la fase final del proceso
para crear una confianza en que el producto es
el apropiado para su uso en explotación.
60
2.3.4

MEDICIÓN Y USABILIDAD
DEL SOFTWARE
Bibliografía
[1] DR. PEDRO MEJÍA ÁLVAREZ,“Ingeniería de Software
Diseño, construcción y mantenimiento de sistemas de
software grandes”, CINVESTAV-IPN, México, Septiembre
2003.
[2] JAIME OYARZO ESPINOSA, “Ingeniería del Software”,
Universidad de Alcalá.
[3] J.M. MARTÍNEZ, L. LÓPEZ, B. CASTAÑO, J.A. MALPICA, J.R.
HILERA y J.A. GUTIÉRREZ, “Metodología de Desarrollo de
Sistemas de Información”, Ed. Universidad de Alcalá, 1995.
[4] KENDALL, K.E. & KENDALL, J.E., “Análisis y Diseño de
Sistemas”, Ed. Prentice-Hall, 1995.

62