MD 3013092013

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD
ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA

CONTENIDO DIDÁCTICO DEL CUSO: 301309 – DISEÑO DE SISTEMAS
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA
PROGRAMA DE INGENIERÍA DE SISTEMAS
301309 – DISEÑO DE SISTEMAS
MOISÉS DE JESÚS RODRÍGUEZ BOLAÑO
(Director Nacional)
SANTA MARTA
2013
TABLA DE CONTENIDO
INTRODUCCIÓN ............................................................................. 9
UNIDAD 1. INTRODUCCIÓN AL DISEÑO ................................................. 11
OBJETIVOS .............................................................................. 11
GENERAL .............................................................................. 11
ESPECÍFICOS .......................................................................... 11
COMPETENCIAS ......................................................................... 11
Capítulo 1. VISIóN GENERAL DEL DISEÑO DE SISTEMAS ........................... 13
Lección 1. CONCEPTO DEL DISEÑO ................................................ 14
Lección 2. OBJETIVOS DEL DISEÑO DE SISTEMAS ................................ 15
Lección 3. CARACTERÍSTICAS A DISEÑAR ......................................... 17
Lección 4. NIVELES DEL DISEÑO ................................................... 18
Lección 5. PROCESO DEL DISEÑO GENERAL DE SISTEMAS ...................... 20
Capítulo 2. MANEJO DEL PROCESO DE DISEÑO ..................................... 22
OBJETIVOS ............................................................................ 22
Lección 6. BOSQUEJOS Y PROTOTIPOS ........................................... 23
ii
Lección 7. MESA DE TRABAJO DE LOS DISEÑADORES............................ 27
Lección 8. CARPETA DE DESCRIPCIÓN DEL DISEÑO DEL SISTEMA .............. 28
Lección 9. SEGUIMIENTO DEL PROCESO DE DISEÑO ............................. 29
Lección 10. SELECCIÓN DE HARDWARE Y SOFTWARE ........................... 32
10.1 Determinación de los requerimientos de tamaño y capacidad ....... 32
10.2 Factores financieros ........................................................ 33
10.3 Mantenimiento y soporte ................................................... 34
10.5 Selección de software ...................................................... 34
Capítulo 3. MANEJO DE SISTEMAS DESARROLLADO POR USUARIOS FINALES ... 36
Lección 11. PARTICIPACIÓN DE LOS USUARIOS .................................. 36
Lección 12. RESPONSABILIDAD DE LOS USUARIOS EN EL DISEÑO .............. 37
Lección 13. RESPONSABILIDAD DEL ANALISTA DE SISTEMAS ................... 37
Lección 14. RIESGOS ASOCIADOS CON EL DESARROLLO POR PARTE DE LOS

USUARIOS ............................................................................. 38
Lección 15. Recomendaciones prácticas para el inicio del diseño e

implementación de un sistema de calidad ....................................... 39
ACTIVIDADES COMPLEMENTARIAS .................................................... 41
iii
Bibliografía .............................................................................. 44
ELECTRÓNICA ......................................................................... 44
Unidad 2. DISEÑO DE SISTEMAS ........................................................ 46
INTRODUCCIÓN ......................................................................... 46
OBJETIVOS .............................................................................. 46
GENERAL .............................................................................. 46
ESPECÍFICOS .......................................................................... 46
Capítulo 4. DISEÑO DE SALIDAS ...................................................... 48
Lección 16. OBJETIVOS, tipos de salida y objetivos del diseño de entrada . 50
16.1 TIPOS DE SALIDA ............................................................. 53
16.1.1. Tabular .................................................................. 54
16.1.2. Gráfica .................................................................. 54
16.2 OBJETIVOS DE DISEÑO DE ENTRADA ...................................... 55
Lección 17. DISEÑO DE SALIDA IMPRESA y DISEÑO DE SALIDA POR PANTALLA

......................................................................................... 55
17.1 Métodos para la salida impresa ........................................... 57
17.2 DISEÑO DE SALIDA POR PANTALLA ........................................ 57
iv
17.3 Diseño de Ventanas ......................................................... 60
Lección 18. CAPTURA DE DATOS, DISEÑO DE DOCUMENTOS Y VALIDACIÓN DE

ENTRADAS ............................................................................. 60
18.1. DISEÑO DE DOCUMENTOS .................................................. 62
18.1.1. Creación de formularios fáciles de contestar ..................... 62
18.1.2. Cumplir el propósito para el cual se diseñan ...................... 64
18.1.3. Garantizar que los formularios se contesten con precisión ..... 65
18.1.4. Hacer formularios atractivos ......................................... 65
18.2. VALIDACIÓN DE ENTRADAS ................................................ 65
18.2.1. Validación de las transacciones de entrada ....................... 66
18.2.2. Validación de datos de entrada ..................................... 67
18.3. Procesos de validación .................................................... 68
Lección 19. DEFINICIÓN DE INTERFACE, diseño de dialogo y estrategias de

dialogo ................................................................................ 69
19.1. Características de la interface ......................................... 70
19.2. Tipos de acciones en la interface ..................................... 70
19.3. DISEÑO DE DIALOGO ..................................................... 71
19.4. ESTRATEGIA DEL DIALOGO ................................................ 77
Lección 20. DIALOGO CON ENTRADA DE DATOS ................................. 80

v
20.1. Paginación y scrolling ...................................................... 81
20.2. Sistemas de Ayuda ......................................................... 85
Capítulo 5. DISEÑO DE ARCHIVOS .................................................... 87
Lección 21. DIAGRAMA DE ESTRUCTURAS DE DATOS ........................... 88
Lección 22. TIPOS Y MÉTODOS DE ORGANIZACIÓN DE ARCHIVOS ............. 90
22.1. MÉTODOS DE ORGANIZACIÓN DE ARCHIVOS ............................ 93
Lección 23. RESPALDO Y RECUPERACIÓN DE ARCHIVOS ........................ 95
23.1. Otras estrategias de respaldo y recuperación ......................... 96
Lección 24. DESARROLLO DE SISTEMAS EN UN AMBIENTE DE BASES DE DATOS

......................................................................................... 97
24.1. Abstracción de datos....................................................... 99
24.2. Modelos de los datos ...................................................... 100
Lección 25. ESTRUCTURACIÓN DE DATOS ....................................... 106
25.1. Normalización .............................................................. 106
25.2. Formas Normales .......................................................... 107
25.2.1. Primera Forma Normal (1FN) ....................................... 107
25.2.2. Segunda Forma Normal (2FN) ....................................... 107
25.2.3. Tercera Forma Normal (3FN) ....................................... 108

vi
25.2.4. Forma Normal de Boyce Codd (FNBC) ............................. 108
25.2.5. Cuarta Forma Normal (4FN) ......................................... 109
25.2.6. Quinta Forma Normal (5FN) ......................................... 109
Capítulo 6. DISEÑO PARA COMUNICACIÓN DE DATOS ............................ 110
Lección 26. REQUERIMIENTOS PARA SISTEMAS DE COMUNICACIÓN DE DATOS

........................................................................................ 111
26.1. REDES DE COMUNICACIóN ................................................ 117
26.2. Arquitecturas de red ...................................................... 119
Lección 27. DISEÑO DE SISTEMAS CONFIABLES ................................. 120
27.1. Enfoques de la confiabilidad ............................................ 120
27.2. Diseños fáciles de mantener ............................................. 121
Lección 28. GRÁFICAS DE ESTRUCTURAS DE PROGRAMAS, DISEÑO DE

SOFTWARE Y HERRAMIENTAS DE DOCUMENTACIÓN ............................ 121
28.1. Simbología .................................................................. 122
28.2. DISEÑO DE SOFTWARE .................................................... 122
28.3. HERRAMIENTAS DE DOCUMENTACIÓN ................................... 124
Lección 29. MANEJO DEL PROCESO PARA GARANTIZAR LA CALIDAD Y MANEJO

DE LAS PRÁCTICAS DE PRUEBA .................................................... 128
vii
29.1. MANEJO DE LAS PRÁCTICAS DE PRUEBA ................................ 129
29.1.1. Organización para las pruebas del software ...................... 129
29.1.2. Estrategia de prueba del software ................................. 130
LECCIÓN 30. manejo Y DISEÑO DETALLADO de objetos ....................... 133
30.1. DISEÑO DEL SISTEMA ...................................................... 134
30.2. DISEÑO DETALLADO DE OBJETOS ........................................ 135
ACTIVIDADES COMPLEMENTARIAS ................................................... 136
Bibliografía ............................................................................. 141
viii
INTRODUCCIÓN
1
Para determinar los requerimientos de sistemas, es necesario analizar los
hechos que se tienen a la mano. Las descripciones y la documentación
desarrollada como resultado del esfuerzo de búsqueda de hechos, se estudian
con la finalidad de evaluar el funcionamiento del sistema en uso y establecer
los requerimientos que debe cumplir un nuevo diseño. Las conclusiones
obtenidas durante esta actividad forman la base para la transición hacia el
diseño así como de otras actividades de desarrollo.
El diseño es una solución: la conversión de los requerimientos en formas que los

satisfagan. El diseño determina el éxito del sistema. A través del diseño se
puede tener gran influencia sobre la efectividad de un usuario, ya sea para el
manejo de transacciones o para la administración de la organización. Algunos
diseños son más efectivos que otros.
Al considerar los objetivos de diseño, se observa que éstos van desde el

satisfacer las necesidades de la empresa hasta el empleo eficaz de la tecnología
de cómputo. La esencia del diseño de sistemas es la selección y especificación
de las características de un sistema de información.
El diseño de sistemas tiene dos etapas:
El diseño lógico: comprende las especificaciones detalladas del nuevo sistema,

es decir aquellas que describen sus características: salidas, entradas, archivos,
1
Análisis y diseño de sistemas de información. James A. Senn. Segunda edición. México. 1992
9
bases de datos y los procedimientos, todo en forma que satisfaga los

requerimientos del proyecto.
Construcción física del sistema: produce el software, los archivos y un sistema

que funciona. Las especificaciones de diseño indican a los programadores lo que
el sistema debe hacer. Las personas que tienen la responsabilidad del diseño
deben determinar cuáles son los enfoques del diseño, cómo afectan a sus
proyectos y guiarse por ellos, incorporando al mismo tiempo creatividad e
innovación.
10
UNIDAD 1. INTRODUCCIÓN AL DISEÑO
OBJETIVOS
GENERAL
• Identificar el papel que cumple el diseño en el desarrollo de sistemas de

información.
ESPECÍFICOS
• Interpretar el concepto general de diseño.

• Identificar la evolución histórica del diseño de sistemas.
• Relacionar la importancia y los objetivos del diseño de sistemas.
• Presentar una vista del diseño general de sistemas y su papel en el
desarrollo de sistemas de información.
• Interpretar el concepto de sistema de información
• Examinar la importancia que tienen los usuarios en el diseño de sistemas.
• Relacionar la responsabilidad de los usuarios y del analista de sistemas en
el diseño de sistemas.
COMPETENCIAS
• El estudiante comprende e interpreta el concepto de “diseño de

sistemas”.
• El estudiante reconoce las especificaciones formales y detalladas de
diseño de sistemas que describan las características de un sistema de
información: entrada, salida, archivos, bases de datos y procedimientos.
11
• El estudiante identifica, reconoce y utiliza técnicas y principios de diseño

para el desarrollo de sistemas de información.
• El estudiante identifica y aplica las características y elementos del diseño
de salidas, los tipos de salidas y como presentar la información de salida.
de entradas y controles, validación de datos, diseño de documentos
fuente y de captura de datos para la entrada.
de diálogo en línea, que es una interface, estrategias del dialogo y del
diseño de dialogo con entrada de datos.
de archivos y uso de dispositivos de almacenamiento secundario.
de interacciones de base de datos y del diseño para comunicación de
datos.
• El estudiante identifica situaciones de contexto en las cuales debe aplicar
el diseño de sistemas.
12
CAPÍTULO 1. VISIÓN GENERAL DEL DISEÑO DE SISTEMAS
El diseño de sistemas es convertir los requerimientos en soluciones que los

satisfagan.
Los analistas de sistemas comprenden la recopilación de hechos y el análisis de

los mismos. El lector puede afirmar que el analista primero define y documenta
y después analiza. Las capacidades perceptivas del analista tienen influencia en
los resultados del análisis. Esta sección proporciona un marco de referencia que
es de gran utilidad para percibir las debilidades y requerimientos del sistema.
Así mismo, identifica las estrategias a seguir para satisfacer los requerimientos
establecidos, como base a la transición al diseño de sistema.
Cierta información tal como la finalidad de cada paso, la personalidad de los

empleados o el número de copias elaboradas de determinados documentos,
pueden parecer, a primera vista, como detalles de fondo que describen un
sistema pero que parecen ser críticos para su análisis. Después, durante el
análisis, a menudo se vuelven de gran importancia. Por ejemplo el aumento de
los costos de manos de obra o de la caída de los niveles son hechos que pueden
estar relacionados con desacuerdos que afectan de forma adversa a la
productividad y que conducen a la contratación de más personal. El número de
copias elaboradas en un documento puede ser el indicio de que pasos que están
omitiendo si algunas de las copias siempre se descartan sin que le hayan dado
uso alguno. También existe una relación entre el conocimiento que tienen los
individuos de los pasos específicos a seguir en un determinado flujo de trabajo
y la forma en que ellos efectúan dichos pasos.
13
LECCIÓN 1. CONCEPTO DEL DISEÑO
Antes de llegar a definir lo que es el diseño de sistemas, es importante

identificar el concepto general sobre diseño y lo que es diseñar.
Cualidades del diseñador
14
LECCIÓN 2. OBJETIVOS DEL DISEÑO DE SISTEMAS
El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante

el análisis en términos de aquella configuración que tenga más posibilidades de
satisfacer los objetivos planteados tanto desde el punto de vista funcional como
del no funcional.
15
Existen diferentes definiciones de lo que es el diseño de sistemas, entre las

cuales se pueden destacar:
Por tal razón, el diseño de sistema persigue los siguientes objetivos:
Generales Específicos
• Efectuar en forma correcta los procedimientos apropiados
• Presentar en forma apropiada y adecuada la información
Satisfacer los
• Proporcionar resultados exactos
requerimientos de
• Utilizar métodos de interacción apropiados
los usuarios
• Proporcionar confiabilidad
Especificar los • Describir las características de un sistema de información: entrada,

elementos de diseño salida, procedimientos, archivos, bases de datos.
lógico
Proporcionar las • Especificar los componentes y funciones con suficiente detalle para
especificaciones de construir el software.
software
• El diseño y su especificación debe estar en concordancia con estándares
Ajustarse a
de desarrollo así como con las reglas establecidas por la organización.
estándares de diseño
• Las buenas prácticas de diseño ergonómico deben contribuir a la
Fácil de usar efectividad y eficiencia del usuario.
16
LECCIÓN 3. CARACTERÍSTICAS A DISEÑAR
Los elementos que se deben tener en cuenta para el diseño son:
Elementos Características
• Se debe tener en cuenta para el diseño de salida:
• La información a presentar.
• Determinar la forma en que será presentada la información (visual,
impresa) y el medio de salida.
Diseño de salida
• Selección de formatos para la presentación de la información.
• Definir la distribución o disposición de información sobre el medo
de salida.
• Incluye:
o Los datos que se deben incluir
o Movimiento de datos
o Longitud de registros
Diseño de archivos
o Diseño de archivos
o Estructura de almacenamiento
o Tipos de archives
• Se debe determinar:
o Datos necesarios de la base de datos
o Relaciones entre datos
Diseño de bases de o Estructuras de los datos
datos o El modelo de datos
o Manipulación de datos
o Diseño de la base de datos
17
• Incluye:
o Captura de datos
o Validación de datos
Diseño de entrada o Medios de entrada de datos
o Disposición y codificación de datos
o Métodos de validación de datos
• Incluye:
o Validación de datos
Diseño de controles o Autorización y acceso de usuarios
o Seguridad
• Incluye:
o Procedimientos de entrada de datos
Diseño de procedimientos o Procedimientos para el manejo de errores
o Procedimientos de seguridad
• Incluye:
o Modularidad y fragmentación
o Acoplamiento
Diseño de software
o Cohesión
o Tamaño
LECCIÓN 4. NIVELES DEL DISEÑO
Como se ha planteado anteriormente, el objetivo del diseño es buscar

soluciones de diseño que satisfaga las necesidades que se establecieron durante
el análisis de sistemas.
18
En la siguiente figura se puede visualizar los diferentes niveles de diseño de

sistemas:
Sistemas de
Información
Aplicaciónes
Subsistemas
Subsistemas
Componentes
Los analistas de sistemas están involucrados desde el rediseño de un

componente de un sistema o de un subsistema hasta la creación y diseño de un
sistema de información. Independiente de cada uno de estos niveles, el
objetivo que persigue al analista de sistemas es buscar soluciones de diseño
para satisfacer las necesidades que se establecieron durante la fase del análisis
de sistemas.
19
LECCIÓN 5. PROCESO DEL DISEÑO GENERAL DE SISTEMAS
Según Burch-Grudnitski, el proceso del diseño general de sistemas comprende

las etapas que se ilustra en la siguiente figura:
20
Este proceso comprende:
El analista de sistemas conoce los requerimientos de los usuarios, el alcance del

sistema y los recursos disponibles (personas, dinero, máquinas, materiales,
métodos).
Las fuerzas de diseño se consideran y se ponderan para determinar el impacto

sobre los componentes estructurales y los diseños finales se crean diferentes
alternativas de diseño para tomar en cuenta diferentes funciones de
ponderación.
Con base en las fuerzas de diseño se pueden crear diversos diseños alternativos
que se someten a consideración de los usuarios.
El analista de sistemas presenta a los usuarios diversas alternativas de diseño,

entre las cuales se eligen algunas para ser evaluadas con mayor profundidad. La
presentación de diversas alternativas aumenta la probabilidad que se
implemente el diseño correcto.
Preparación del reporte de la propuesta del diseño general de sistemas
Una vez se ha elegido la propuesta del diseño general de sistemas, se prepara

un reporte final que tiene como objetivo comunicar a la gerencia de la
organización y a los usuarios la forma, a nivel general, en que el sistema
satisface los requerimientos.
El reporte de la propuesta del diseño general de sistemas debe contener:
21
• La(s) razón (es) que dieron inicio al trabajo, se debe incluir los objetivos específicos.
Relacionar los requerimientos originales de los usuarios y los objetivos con la propuesta
actual del diseño de sistemas.
• Preparar un modelo completo del diseño propuesto. En lo posible se deben incluir
alternativas de diseño, dentro de las cuales la gerencia pueda elegir.
• Mostrar todos los recursos requeridos para implementar y mantener cada alternativa.
• Identificar toda suposición crítica o problema no resuelto que pueda afectar al diseño
final de sistemas.
CAPÍTULO 2. MANEJO DEL PROCESO DE DISEÑO
El proceso de diseño es una guía general de los pasos que pueden seguirse para
dar al Ingeniero cierto grado de dirección para la solución de problemas. Los
diseñadores emplean un gran número de combinaciones de pasos y
procedimientos de diseño, pero no se puede decir que haya una combinación
óptima. El seguir las reglas estrictas del diseño no asegura el éxito del proyecto
y aún puede inhibir al diseñador hasta el punto de restringir su libre
imaginación. A pesar de esto, se cree que el proceso de diseño es un medio
efectivo para proporcionar resultados organizados y útiles.
OBJETIVOS
El objetivo del manejo del proceso de diseño es realizar los pasos necesarios
para que se desarrolle en forma apropiada el diseño.
22
LECCIÓN 6. BOSQUEJOS Y PROTOTIPOS
Se puede utilizar tres técnicas de análisis y diseño de sistemas que ayudan a

especificar los requerimientos de manera previa.
1. Bosquejo de componentes estructurales

Esta técnica permite reunir todos los componentes estructurales en una hoja de papel o en
una pantalla para cada alternativa de diseño, lo que permite que el analista tenga un
bosquejo y una vista general de todo el sistema.
23
Las alternativas de diseño se bosquejan para que los usuarios presenten sus comentarios y
reacciones y ofrezcan una retroalimentación a los analistas de sistemas. Estos bosquejos
ayudan a determinar elementos faltantes y permiten generar ideas de diseño adicionales.
Cada uno de los diseños finales posibles está contenido en una hoja de componentes
estructurales. Estas hojas se convierten en una parte principal del reporte de la propuesta
del diseño general de sistemas.
24
2. Bosquejo en papel
Esta técnica consiste en entregar una hoja de papel en blanco a los usuarios y se les pide que
bosquejen lo que desean como salida. Los usuarios bosquejan elementos como tablas y
diagramas y el contenido de la salida que desean.
Los bosquejos iniciales pueden ser incompletos, pero con el desarrollo de cada nuevo
bosquejo se da un aprendizaje interactivo. Con el paso del tiempo, se obtiene un nivel de
detalle a partir del cual se puede implementar el bosquejo final. Al final, los analistas de
sistemas, en cierto modo se pueden asegurar que los sistemas que implementen corresponden
a lo que los usuarios desean y necesitan.
25
3. Prototipos
Esta técnica permite que el usuario trabaje con una imitación del sistema que se va a
implementar. Este prototipo permite a los usuarios ver no solamente lo que van a recibir,
sino que también les da la oportunidad de hacer una prueba de manejo.
En la fase de Diseño, su propósito, es mostrar las ventanas, su navegación, interacción,

controles y botones al usuario y obtener una retroalimentación que permita mejorar el diseño
de interfaz.
Características:
• El prototipo es una aplicación que funciona

• Los prototipos se crean con rapidez
• Los prototipos evolucionan a través de un proceso iterativo
• Los prototipos tienen un bajo costo de desarrollo
Los prototipos tienen las siguientes etapas:
26
LECCIÓN 7. MESA DE TRABAJO DE LOS DISEÑADORES
Como se aprecia en la figura anterior, la mesa de trabajo de los diseñadores

integra las herramientas necesarias para analizar, diseñar, evaluar, documentar
e implementar un sistema de información. Todas las herramientas de trabajo
para llevar a cabo el proceso de diseño deben estar al alcance del analista de
sistemas.
Las herramientas del diseñador comprenden el uso de diferentes técnicas,

estrategias y modelos que permiten construir, almacenar, revisar
especificaciones, diseño de documentación, crear diversos diagramas,
elaboración de bosquejos y prototipos con el propósito de entregar la
propuesta general del diseño de sistemas.
Una vez se completa el diseño y la evaluación, se genera el código de

programas de aplicación de acuerdo a las especificaciones del diseño.
27
LECCIÓN 8. CARPETA DE DESCRIPCIÓN DEL DISEÑO DEL SISTEMA
El objetivo de este paso es documentar en forma completa las especificaciones

y los requerimientos del Sistema. Según James A. Senn, ésta carpeta contiene
los siguientes aspectos:
Elemento Características
Propuesta de Identificación de los objetivos, justificación y establecimiento de los
desarrollo requerimientos de la organización y de los usuarios.
Diagramas de flujo Descripción completa del sistema utilizando diagramas de flujo de
de datos datos.
Cuadros de Especificación de las entradas y salidas. Se detallan reportes,
despliegue documentos y pantallas.
Estructura de los Descripción de los datos contenidos en los archivos maestros. Se
registros especifican los diagramas relacionados con las bases de datos.
Descripción de los códigos que explican o identifican tipos de
Codificación
transacciones, clasificaciones y categorías de eventos o entidades.
28
Especificaciones de Descripciones gráficas (cuadros, tablas) de los módulos y

programas componentes del software junto con la interacción de cada uno.
Especificaciones de Planificación de procedimientos necesarias para la instalación y
procedimientos puesta en marcha del sistema, una vez terminado.
Cronogramas que indican los tiempos necesarios para el
Plan de desarrollo
desarrollo de las actividades.
Gastos anticipados para el desarrollo, implantación y puesta en
Costos
marcha del sistema.
LECCIÓN 9. SEGUIMIENTO DEL PROCESO DE DISEÑO
Pretende llevar y tener un avance del desarrollo del proyecto con relación a:
Tiempo de desarrollo: se debe dar respuesta a: ¿Cuánto tiempo tardará e

proyecto? ¿Qué actividades se deben tener en cuenta para mantener el
desarrollo del proyecto dentro de los tiempos planificados? ¿El proyecto se está
desarrollando de acuerdo a los tiempos especificados?
Costo de desarrollo: Los gastos del proyecto ¿se encuentran dentro de los
proyectado y planificado?
Aceptabilidad del diseño: El diseño: ¿Satisface los requerimientos de la

organización y de los usuarios? ¿El sistema está siendo construido con el diseño
propuesto?
29
Estimación y control del tiempo de desarrollo
Es importante que un proyecto se desarrolle a tiempo, y para que esto suceda

debe tener en cuenta las siguientes características:
• Una estimación cuidadosa de los requerimientos de tiempo.

• Un medio para monitorear el avance.
• Un medio para comparar el desempeño planeado con lo real.
• Información suficiente para enfrentar problemas que surjan
Las estimaciones son aproximaciones del esfuerzo necesario para producir el

sistema deseado.
Existen tres métodos para estimar el tiempo de desarrollo de un proyecto:
Método Características
Se basa en registros que se tienen del desarrollo de proyectos anteriores. Estos
registros contienen información sobre las características del proyecto, asignación
de tareas, requerimientos de tiempo y personal y los problemas encontrados en su
Histórico desarrollo. Cuando se proponen nuevos proyectos, estos registros sirven para
establecer una comparación y estimar el tiempo esperado de desarrollo. Este
método es útil cuando el proyecto nuevo es similar al proyecto desarrollado
anteriormente.
Este método no se basa en registros documentados y por el contrario se basa en la
Intuitivo experiencia del personal más antiguo, el cual estima, por medio de experiencias
personales, el tiempo de desarrollo esperado.
Este método permite identificar y cuantificar (de forma individual) los factores
Estándar más importantes que afectan el tiempo de desarrollo del proyecto (personal, el
sistema, complejidad del proyecto).
30
Las estimaciones del tiempo del proyecto comprenden dos tipos:
• Requerimientos de tiempo del proyecto

• Requerimientos de tiempo calendario
1. Requerimientos de tiempo del proyecto

Es el tiempo necesario para llevar a cabo: análisis, diseño, codificación, implementación
pruebas y puesta en marcha del sistema.
Se debe tener en cuenta:
• Estimación de los tiempos de actividad del sistema

• Identificación de las variables de desarrollo del programa
• Calculo de las estimaciones de tiempo de programación
2. Requerimientos de tiempo calendario

Se determina el calendario del proyecto (días, semanas, meses).
A menudo se utilizan los siguientes métodos:
• Diagramas de barras
• Diagrama de eventos críticos
• PERT
31
LECCIÓN 10. SELECCIÓN DE HARDWARE Y SOFTWARE
La selección y adquisición de hardware y software comprende una tarea más en

la actividad de un nuevo sistema. Comprende las actividades de:
• Formular las especificaciones del sistema

• Recibir y revisar las propuestas de los vendedores
• Realizar una selección
• Selección de hardware
10.1 DETERMINACIÓN DE LOS REQUERIMIENTOS DE TAMAÑO Y CAPACIDAD
Entre las características a considerar se tienen:
• Tamaño de memoria interna

• Velocidad del ciclo de sistema
• La capacidad de volumen total del sistema
• Número de canales para entrada, salida y comunicación
• Tipos y números de unidades de almacenamiento
• Puertos de comunicación
• Tamaño de disco
• Capacidad de almacenamiento auxiliar
• Apoyo del sistema y software de utilerías
• Medición y evaluación de sistemas de cómputo
• Se centra en las pruebas de equipo, y consiste en la aplicación de
programas para emular el trabajo real de procesamiento de un sistema.
• Compatibilidad de equipos
32
Se debe asegurar que el equipo cumpla con los niveles necesarios de calidad,
que se desempeñará igual al equipo original y que el proveedor ofrece garantías
y acuerdos de servicios.
10.2 FACTORES FINANCIEROS
La adquisición y pago de un sistema de cómputo se maneja por medio de uno de

los tres métodos siguientes:
Método Ventajas Desventajas

Arrendamiento • No se invierte ningún capital • La organización no tiene la
• No se requiere financiamiento propiedad del sistema cuando
• Los pagos son más bajos que por expira el arrendamiento
alquiler • Los arrendamientos son más caros
• Compromiso a corto plazo que la compra
• Poco control del cambio de equipo
Alquiler a largo • No se invierte ningún capital • La organización no es dueña de los

plazo • No se requiere financiamiento equipos
• Es fácil cambiar los sistemas • El costo es demasiado alto puesto
• Incluyen mantenimiento y seguro que el arrendador asume el riesgo
• Poco riesgo de obsolescencia
Compra • Es más barato que el • El costo inicial es alto
arrendamiento o el alquiler • Riesgo de obsolescencia
• Posibilidad de cambiar el sistema • Riesgo de quedarse con un equipo
• La organización tiene el control malo si la opción fue errónea
total • Responsabilidad total
33
10.3 MANTENIMIENTO Y SOPORTE
Por lo general se tienen:
Características
• Línea completa de hardware
• Productos de calidad
Soporte de hardware
• Garantía
• Necesidades completas de software

• Programación a la medida del cliente
Soporte de software
• Garantía
• Compromiso para programar

Instalaciones y • Capacitación en las instalaciones del comprador
capacitación • Asistencia técnica
• Procedimientos de mantenimiento rutinario

• Tiempo de respuesta específico en caso de emergencia
Mantenimiento • Préstamos de equipo de repuesto mientras se hace la
reparación
10.5 SELECCIÓN DE SOFTWARE
Es importante realizar un análisis de requerimientos de información de los

usuarios y los sistemas, antes de llegar a tomar la decisión si se compra, se
desarrolla o se subcontrata un software.
34
Ventajas Desventajas
• Respuestas específicas a las
necesidades especializadas del
• El costo inicial puede ser alto
negocio.
• Necesidad de contratar o trabajar
Crear software a • La innovación podría proporcionar
con un equipo de desarrollo
la medida una ventaja competitiva a la
• Mantenimiento continuo
empresa.
• Personal interno disponible para
dar mantenimiento al software.
• Enfocado en la programación, no en
• Refinado en el mundo comercial
los negocios
• Confiabilidad
• Debe funcionar con las
• Funcionalidad
características actuales
Comprar software • El costo inicial es más bajo
• Personalización limitada
comercial • Otras organizaciones ya lo usan
• El futuro del fabricante es incierto
• El software incluye soporte y
• Menor sentido de pertenencia y
capacitación
compromiso
• Pérdida de control de los datos

• Las organizaciones que no se sistemas, empleados y
especializan en sistemas de programaciones.
información se pueden enfocar en • Preocupación sobre la viabilidad
su misión financiera y estabilidad a largo
• No es necesario contratar, plazo de la organización
Subcontratación capacitar o retener muchos subcontratada
empleados de tecnologías de la • Preocupaciones sobre seguridad,
información confidencialidad y privacidad.
• No se gasta tiempo de empleados • Pérdida de la potencial ventaja
en tareas de tecnologías de la corporativa estratégica relativa a
información innecesarias innovación en las aplicaciones.
35
CAPÍTULO 3. MANEJO DE SISTEMAS DESARROLLADO POR USUARIOS

FINALES
Los sistemas desarrollados por los usuarios finales, al igual que cualquier otro
sistema, no tendrán éxito a menos que sean manejados y apoyados en forma
apropiada. De lo contrario, estos sistemas pueden ser dañinos para la
organización. Tanto usuarios como analistas, tienen responsabilidades en el
manejo de los sistemas desarrollados por los primeros.
Seguir lineamientos de diseño puede ser de gran ayuda para evitar problemas
en potencia en las aplicaciones desarrollados por los usuarios finales.
LECCIÓN 11. PARTICIPACIÓN DE LOS USUARIOS
Existen tres razones por las cuales la participación de los usuarios en el diseño
es fundamental:
36
LECCIÓN 12. RESPONSABILIDAD DE LOS USUARIOS EN EL DISEÑO
Los usuarios tienen la responsabilidad de:
LECCIÓN 13. RESPONSABILIDAD DEL ANALISTA DE SISTEMAS
“Los analistas, por sus parte tienen las siguientes responsabilidades:
37
LECCIÓN 14. RIESGOS ASOCIADOS CON EL DESARROLLO POR PARTE DE

LOS USUARIOS
• El empleo de especificaciones inexactas o de suposiciones incorrectas

con respecto a las actividades de la organización.
• La aplicación de fórmulas o modelos incorrectos
• El uso de información incompleta o desactualizada
• La selección de software inapropiado y que aún no ha sido probado
Según James A. Senn, los problemas que se pueden presentar son:
Para evitar estos riesgos es importante que la organización establezca

lineamientos de diseño, dentro de los cuales se puede tener en cuenta:
Descarga de archivos
La descarga de datos desde archivos o bases de datos permiten tener una uniformidad de
datos y además permite hacer uso eficiente del tiempo de las personas.
Evitar que los usuarios ingresen datos
Esto permite que los usuarios no ingresen errores en la base de datos o la alteración de los
que ya han sido validados.
Estandarización
Seguir estándares para datos, para el proceso de desarrollo y para las pruebas del sistema
permite obtener consistencia y uniformidad. Se asegura que los datos tengan el mismo
significado.
Documentación
Una buena documentación asegura una explicación de la forma en que opera el sistema y las
características del sistema.
38
Revisión de las especificaciones de diseño

La revisión permite definir que el sistema cumple con su finalidad y además que es Confiable.
Se debe hacer cumplir los estándares de diseño definidos por la organización.
LECCIÓN 15. RECOMENDACIONES PRÁCTICAS PARA EL INICIO DEL

DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE CALIDAD
Trabajar por etapas. Es decir, primero establecer el formato del Manual de

Calidad y luego completarlo de manera progresiva a medida que se van
evaluando los procesos, se completan las medidas de prevención, se escriben
los procedimientos de trabajo y se los lleva a la práctica. Entre tanto, los
procedimientos que ya se han completado se van haciendo cumplir y se produce
paulatinamente un avance progresivo en el diseño y aplicación del sistema de
calidad.
Esta tarea progresiva crea la percepción de que un sistema de calidad debe ser
permanentemente mejorado y actualizado a medida que aumenta la
experiencia a través del análisis de fallas y la adecuación de la planificación de
las actividades (criterio de mejora continua).
El nivel directivo debe estar convencido de las ventajas de implementar un

sistema de calidad y la conveniencia de hacer participar al personal.
En toda organización siempre existen algunos elementos de un sistema de

calidad natural (organización, procedimientos y registros) por lo que conviene
39
determinar primeramente qué cosas ya están hechas y listas para usar, cuáles
se deben mejorar y cuáles se deben crear, dado que conviene aprovechar el
material existente.
Antes de iniciar esta tarea se deben establecer prioridades. Conviene comenzar

por los procesos en los que las dificultades y problemas son mayores a fin de
mejorarlos mediante el diseño y puesta en práctica de procedimientos
adecuados.
Conviene también planificar en el inicio todas las actividades que se va a

realizar pero estableciendo prioridades y metas que se van a cumplir en etapas
sucesivas.
Es recomendable el trabajo en equipo haciendo reuniones periódicas para

discutir los resultados y las acciones futuras.
El análisis de las fallas es una herramienta para mejorar. Cada hecho que
impida realizar la tarea debiera considerarse una no-conformidad. En el
personal se debe crear una cultura de búsqueda de fallas a fin de utilizarlas en
la mejora continua.
40
ACTIVIDADES COMPLEMENTARIAS
Realice un ensayo sobre la importancia del diseño en los sistemas de

información. Y de la importancia del papel del analista en el proceso de diseño.
Elabore una hoja de diseño de bloques de construcción para los siguientes

sistemas:
• Cuentas por cobrar

• Alquiler de películas
• Biblioteca
Investigue y elabore un mapa conceptual sobre lo que para usted es el

“Diseño”.
Realice un mapa conceptual sobre la participación de los usuarios en el proceso

de diseño de sistemas.
Elabore un ensayo sobre la finalidad de la carpeta de diseño.
EJERCICIO
Un analista de sistemas planteo los siguientes comentarios con respecto al

objetivo de la organización de invitar a que los usuarios participen:
“La participación de los usuarios en el diseño de sistemas de información es un

tema que a menudo es difícil de tratar. Sin embargo, cada vez que nosotros lo
hemos intentado, encontramos que no es eficaz. Voy a dar varios ejemplos. En
varios proyectos, nuestros analistas desarrollaron bosquejos de los formatos de
41
entrada y salida que fueron dados a los usuarios de la aplicación. En cada caso,
los usuarios sugirieron modificaciones, las cuales nosotros hicimos. Los nuevos
bosquejos fueron regresados a los usuarios para su revisión. El resultado fue que
los cambios condujeron a más modificaciones. Cuando las realizamos todas, el
diseño final no era mejor que el original, pero ya habíamos perdido varias
semanas.
En otra ocasión, discutimos varias veces con los usuarios las funciones de un
sistema. Al final, nos quedamos con los requerimientos que propusimos en un
principio. Perdimos tiempo de desarrollo y no ganamos nada.
También señalaría otra dificultad. Supongamos que los usuarios sugieren

cambios significativos en el diseño que nosotros somos incapaces de efectuar
por limitaciones de índole técnica. En este caso, probablemente escucharemos
acusaciones señalando que la participación del usuario es sólo un gestor de que
no atenderemos sus sugerencias cuando ellos las hagan. Francamente no
podemos ganar.”
Analice los comentarios expresados por el analista y presente su posición con

argumentos sobre estos comentarios.
A la luz de estos comentarios, ¿es buena idea que los usuarios participen en el
diseño?
Elabore un mapa conceptual sobre la responsabilidad de los usuarios y del

analista en el manejo de sistemas desarrollado por usuarios finales.
42
EJERCICIO
Los gerentes de una organización determinan que los analistas de sistemas de la

organización supervisen el diseño y desarrollo de todas las aplicaciones de los
usuarios, ya sea que éstas se ejecuten en computadores o personales o sobre el
sistema de información con los que cuenta la organización.
La organización desea manejar el desarrollo de todas las aplicaciones e insiste

en la certificación de la confiabilidad del sistema como requisito indispensable
para permitir su uso cotidiano.
Un grupo de usuarios ha objetado la posición de la gerencia. El grupo afirma

que se perderán los beneficios que ofrecen las aplicaciones desarrolladas por
los usuarios si la gerencia instala procedimientos formales de diseño. Insisten en
que la administración del proceso lo sujetará a retrasos y traerá como
consecuencia un daño a la utilidad de estos sistemas. Por otra parte, también
recalcan que si el grupo de sistemas de información no desea ver una aplicación
diseñada o desarrollada, bastará que afirmen que representa un riesgo para las
bases de datos de la organización, para descartarla.
Analice la posición de los usuarios. ¿Está de acuerdo o en desacuerdo con los

planteamientos?
Elabore un documento de no más de dos páginas argumentando su decisión.
43
BIBLIOGRAFÍA
Burch-Grudfnitski. (2001). Diseño de sistemas de información. Teoría y

Práctica. México.
J., W. (1996). Análisis y diseño de sistemas de información. Madrid.
James, S. (1992). Análisis y diseño de sistemas de información. México.
K., L. (1992). Administración de los sistemas.
Kendall, K. &. (2005). Análisis y diseño de sistemas.
ELECTRÓNICA
http://www.monografias.com/trabajos7/sisinf/sisinf.shtml
www.webspacestation.com/software/standards.html
http://standards.ieee.org/
http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/teoriasistemas
.htm
http://www.monografias.com/trabajos11/teosis/teosis.shtml
http://www.isdefe.es/webisdefe.nsf/0/90BA5220EB675284C1256E55004943D6?
OpenDocument
44
http://www.monografias.com/trabajos21/sistemas-informacion-
organizacional/sistemas-informacion-organizacional.shtml
http://www.gestiopolis.com/canales2/gerencia/1/ddsluisart.htm
http://dssresources.com/history/dsshistory.html
http://dssresources.com/
45
UNIDAD 2. DISEÑO DE SISTEMAS
INTRODUCCIÓN
Los requerimientos de un sistema de información se trasladan en

especificaciones de diseño. El objetivo del diseño de un sistema de información
es asegurar que éste brinde apoyo a la actividad de la organización.
Las especificaciones de diseño describen las características del sistema, los

componentes o elementos del sistema y la forma en que se presentan ante el
usuario, por tal razón, los elementos a diseñar en un sistema de información
son: salida, archivos, bases de datos, entrada, controles y procedimientos.
OBJETIVOS
GENERAL
• Identificar el papel que cumple el diseño de sistemas de información.
ESPECÍFICOS
• Determinar los objetivos y las características importantes del diseño de salidas.

• Determinar los objetivos y las características importantes del diseño de entradas y
controles.
• Identificar las características del diseño del dialogo en línea.
• Identificar la importancia y las características del diseño de archivos.
• Determinar las características del diseño de base de datos.
• Determinar las características del diseño para comunicación de datos.
• Relacionar la importancia del aseguramiento de la calidad en el diseño de software.
46
• Identificar y determinar las características más relevantes del diseño orientado a

objetos.
47
CAPÍTULO 4. DISEÑO DE SALIDAS
El diseño de la salida de la computadora debe avanzar en una forma organizada

y bien pensada: tiene que desarrollarse correctamente mientras que al mismo
tiempo se garantice que cada elemento de la salida está diseñado para que las
personas encuentren que el sistema es fácil de emplear.
El término salida se utiliza para denotar cualquier información producida por un

sistema de información, ya sea impresa o en una pantalla. Cuando los analistas
diseñan la salida, ellos:
• Identifican la salida específica que es necesaria para satisfacer los requerimientos de

información.
• Seleccionan los métodos para presentar la información.
• Crean los documentos, reportes u otros formatos que contienen la información
producida por el sistema.
Los métodos de salida varían a través de los sistemas. Por ejemplo, algunos
métodos como el del reporte de inventario sobre la cantidad de mercancía, o el
del sistema de cómputo, o el que está bajo el control de un programa,
simplemente recuperan los datos de un dispositivo de almacenamiento (por lo
general, de un medio de almacenamiento secundario) y los presentan en forma
adecuada. En estos casos, si acaso, se realizan algunos cálculos debido a que los
datos ya existen y sólo es necesario recuperarlos. Otros tipos de salida quizá
requieran de un procesamiento sustancial antes de que los datos estén
disponibles para su uso. Por ejemplo, para producir como salida el costo de
fabricación de un producto, el sistema primero localiza las descripciones de
todas las partes utilizadas en el producto final y la cantidad necesaria de éstas
48
para fabricarlo. Después, se obtiene el costo de cada una. Finalmente, se

multiplican y totalizan los costos y cantidades de todas las partes para producir
la salida deseada. En este ejemplo, los pasos de procesamiento son mucho más
extensos que para el ejemplo del inventario, aunque ambos conjuntos de
información quizá tengan la misma importancia para los usuarios del informe de
inventarios.
Las especificaciones de entrada describen la manera en que los datos

ingresarán al sistema para su procesamiento. Las características de diseño de la
entrada pueden asegurar la confiabilidad del sistema y producir resultados a
partir de datos exactos, o también pueden dar como resultado la producción de
información errónea. Asimismo, el diseño de la entrada determina si el usuario
puede interactuar con el sistema de manera eficiente.
Este capítulo discute las responsabilidades que tiene el analista en el diseño de

las especificaciones de entrada. Las consideraciones que guían el diseño de la
entrada comienzan con el origen de los datos y continúan a lo largo de la
selección de métodos para trasladar la entrada en una forma que el sistema
pueda verificar su exactitud.
También se discute el diseño de documentos y formas para la recopilación de

datos antes .de enviar los a procesamiento.
El diseño del diálogo en línea debe tener en cuenta:
• La respuesta inmediata a las solicitudes de los usuarios: el usuario realiza una

solicitud al sistema y recibe una respuesta inmediata.
49
• Contacto directo entre sistema – usuario: el usuario hace uso del sistema para enviar y
recibir información.
LECCIÓN 16. OBJETIVOS, TIPOS DE SALIDA Y OBJETIVOS DEL DISEÑO

DE ENTRADA
La salida de información tiene los siguientes objetivos:
• Expresar información relacionada con actividades (pasadas,

actuales, proyecciones)
• Señalar eventos importantes, oportunidades, problemas o
d i
El contenido de salida y el método de salida
La salida se debe pensar de forma que cualquier información producida sea útil
para el usuario.
La salida se puede clasificar en:
Se necesitan diferentes tipos de tecnologías para producir diferentes tipos de

salida:
50
Método de Salida Ventajas Desventajas

• Costeable para la mayoría de • Podría ser ruidosa
las organizaciones • Problemas de
• Flexible en tipos de salida, compatibilidad con software
ubicación y capacidad • Puede requerir suministros
• Maneja grandes volúmenes de especiales y caros
Impresora
salida • Aún requiere intervención
• Puede llegar a muchos usuarios del operador
a bajo costo • Dependiendo del modelo,
• Altamente confiable con poco puede ser un poco lenta.
tiempo inactivo
• Interactiva • Requiere área para el
• Trabaja en línea, cableado y configuración
transmisión en tiempo real • Aún podría requerir
a través de redes documentación impresa
distribuidas ampliamente • Puede ser cara si se
• Silenciosa requiere para muchos
Pantalla de • Toma ventaja de la usuarios
despliegue capacidad de la
computadora para navegar
en las bases de datos y
archivos
• Adecuada para acceder a
mensajes que cambian muy
seguido
Salida de audio • Adecuada para usuarios • Su desarrollo es caro
51
individuales • Necesita una sala especial

• Adecuada para mensajes donde la salida no
transitorios interferirá con otras tareas
• Adecuada cuando el trabajador • Tiene aplicación limitada
necesita manos libres
• Adecuada si la salida es muy
repetida
• Su desarrollo es caro
• Tiene gran capacidad
• Es más difícil de actualizar
DVD, CD-ROM y CD- • Permite la salida multimedia
• Es más difícil de usar en una
RW • Se puede consultar con rapidez
red
• Es menos vulnerable a los daños
• Normalmente tiene baja

• Usa menos papel
resolución
• Se puede actualizar muy
Salida Electrónica • Es difícil darle un formato
fácilmente
(correo electrónico, fijo (correo electrónico)
• Se puede transmitir
faxes y páginas web) • Los sitios Web necesitan
masivamente
mantenimiento
• Se puede hacer interactiva
Fuente: Kendall y Kendall. Análisis y Diseño de Sistemas
Los factores que se deben considerar para la selección de la tecnología de

salida más adecuada son:
52
• Quién usará la salida de datos?

• Cuantas personas necesitan la salida?
• Dónde se necesita la salida?
• Cuál es el propósito de la salida?
• Cuál es la velocidad con que se necesita la salida?
• Con que frecuencia se accederá a la salida?
• Cuanto tiempo se almacenará la salida?
• Bajo qué regulaciones especiales se produce, almacena y distribuye la salida?
• Cuáles son los costos iniciales y finales del mantenimiento y suministro?
• Cuáles son los requerimientos ambientales para las tecnologías de salida?
16.1 TIPOS DE SALIDA
Abordando el tema de las salidas del sistema puede ser:
Según las circunstancias y los contenidos, la salida puede ser:
El contenido de la salida tiene su origen en las siguientes fuentes:
• Recuperación de un dispositivo de almacenamiento
53
• Transmisión desde un proceso o actividad del sistema

• Directamente desde una fuente de entrada
• ¿Cómo presentar la información?
La información puede ser presentada de forma:
16.1.1. TABULAR
Esta forma permite:
• Hacer uso de tablas

• Utilizar categorías para la presentación de la información
• Añadir fácilmente varios aspectos a la lista
• Presentar la información en forma detallada y organizada
• Colocar detalles sobre un reporte
• Evitar datos innecesarios
• Incluir subtotales y totales
16.1.2. GRÁFICA
Esta forma permite:
54
• Hacer uso de diagramas, mapas y graficas de alta calidad

• Proyectarse en pantallas de video
• Una presentación visual y efectiva de datos
• Mejorar la efectividad de los reportes
• Las gráficas son más eficientes para:
• Detectar y presentar tendencias o cambios en los datos
• Identificar relaciones de desempeño entre elementos
• Las gráficas son menos eficientes para:
• Determinar valores específicos para ciertos puntos dato
• Representar una pequeña cantidad de datos
16.2 OBJETIVOS DE DISEÑO DE ENTRADA
Con relación al ingreso de los datos, se presentan los siguientes objetivos:
LECCIÓN 17. DISEÑO DE SALIDA IMPRESA Y DISEÑO DE SALIDA POR

PANTALLA
La salida impresa es la presentación de informes o reportes con la información

absolutamente necesaria.
55
Las características que se deben tener en cuenta para el diseño de informes o

formularios incluyen:
Calidad, tipo y tamaño del papel

Los reporte varían en tamaño, pero los formatos estándar son:
• 9 ½ X 11 pulgadas
• 11 X 14 7/8 pulgadas
• 8 X 14 7/8 pulgadas
Sin embargo, la salida se puede imprimir en diferentes tipos de papel. Algunos reportes o
documentos requieren el uso de papel especial, por ejemplo, papel de seguridad para
impresión de cheques, documentos que deben llevar sellos oficiales u hologramas. Se puede
hacer uso de colores y diseños corporativos.
Uso de convenciones
Incluyen:
• Tipo de dato: alfabético, numérico, especial)

• Tamaño del formulario y la forma de indicar la continuación de datos y del formulario
• Información constante o fija: Esta información permanece igual cuando se imprime el
formulario
• Información variable: Esta información varía cada vez que se imprime el informe.
Atributos funcionales
Incluye:
• Encabezado o título del informe

• Número de página
56
• Fecha de elaboración
• Títulos de columna
• Agrupación de elementos
• Uso de subtotales
• Un informe se debe leer de arriba abajo y de izquierda a derecha.
17.1 MÉTODOS PARA LA SALIDA IMPRESA
Los diferentes métodos que existen para la impresión de informes o reportes

son:
• Impresora de caracteres de matriz de puntos – 40 a 1200 caracteres por segundo

• Impresora de chorro de tinta – 20 a 240 caracteres por segundo
• Impresora láser – 8 a 215 páginas por minuto
• Copias múltiples de la salida
• Copias sin papel carbón: Estas copias son especiales en cuanto un recubrimiento
químico especial se encuentra en la parte trasera de cada copia.
• Copias con papel carbón: Entre cada copia se coloca un papel carbón que se utiliza
solo una vez.
17.2 DISEÑO DE SALIDA POR PANTALLA
En el diseño de una salida en pantalla, primero que todo se debe tener en

cuenta las siguientes características de la pantalla:
57
1 Encabezados y títulos, que se colocan en la parte superior de la pantalla.
2 Contenido de la pantalla.
3 Mensajes e instrucciones, se pueden colocar en la parte inferior de la

t ll
4 Explicaciones sobre la información, en el cuadrante superior izquierdo.
Para facilitar el diseño de pantallas se pueden tener los siguientes

lineamientos:
• Mantener el informe en pantalla simple

• Ser consistente en la presentación
• Facilitar la navegación o movimiento del usuario entre la salida desplegada
• Crear un informe en pantalla de forma atractiva
En el diseño de una pantalla de salida se necesitan áreas para:
58
Menu
Títulos
Cuerpo
Mensajes de estado
Esta distribución es una sugerencia, puesto que el analista debe especificar el

contenido y distribución de cada formato y que sean únicos.
En el diseño de pantallas, también se deben incluir título y encabezados para

las columnas, los datos en cada columna se indican de la misma manera que
para la salida impresa.
De igual forma se debe, especificar en pantalla:
• La información de cómo continuar con la siguiente pantalla de información

• Cómo abandonar o salir del sistema
59
• Uso o funciones de teclas especiales

• Mensajes de error o acciones a seguir o realizar
• Información de forma consistente de página en página
17.3 DISEÑO DE VENTANAS
Las ventanas son subdivisiones de la pantalla que permite obtener y presentar

información al mismo tiempo.
El uso de ventanas, se facilita para:
• Presentar datos diferentes o conjuntos de reportes al mismo tiempo

• Cuando se necesita intercambiar información entre diferentes programas
• Mover información entre ventanas
Los criterios para el diseño de ventanas son:
• Títulos y encabezados
• Capacidad para el cambio entre ventanas
• Se debe indicar cual es la ventana activa
• Posibilidad de impresión independiente de las otras
ventanas
LECCIÓN 18. CAPTURA DE DATOS, DISEÑO DE DOCUMENTOS Y

VALIDACIÓN DE ENTRADAS
Se debe capturar solamente los datos que en realidad deben formar parte de la
entrada. Los tipos de datos que se proporcionan como entradas son:
Datos Variables Datos de identificación
60
Aquellos datos que cambian en cada Es el dato que identifica en forma única el
transacción. artículo que está siendo procesado.
Ejemplos: Ejemplo:
• Identificación de cada artículo Número único de identificación de un artículo

• Identificación del cliente, proveedor (llave)
Lo que no se debe requerir como entrada es:
Datos Constantes Datos que son los mismos para cualquier transacción.
Detalles que el
sistema puede Datos almacenados que el sistema puede recuperar de sus archivos
recuperar
Detalles que el
Son los resultados que se pueden producir al pedir que el sistema utilice
sistema puede
combinaciones de datos almacenados y proporcionados.
calcular
61
18.1. DISEÑO DE DOCUMENTOS
Los formularios son instrumentos que permiten obtener y capturar información

solicitada por los miembros de la organización.
Para el diseño de formularios es importante tener en cuenta los siguientes

lineamientos:
18.1.1. CREACIÓN DE FORMULARIOS FÁCILES DE CONTESTAR
Esto permite reducir errores, acelerar el ingreso de los datos y facilitar la

entrada de los datos. El diseño de un formulario minimiza el tiempo y el
esfuerzo que se dedica para contestarlo, para esto se puede dividir el
formulario en las siguientes secciones:
Encabezado: Incluye nombre y dirección de la organización

Identificación Y Códigos de identificación que permiten archivar el informe y acceder a
acceso: él posteriormente.
Instrucciones: Establece las condiciones de cómo debe contestarse el formulario y a
donde debe enviarse.
Cuerpo: Contiene los datos y la información que debe diligenciar el usuario
Firma Y Datos de la persona que diligencia el formulario
verificación:
Totales: Este espacio permite obtener el total o totalizar cantidades cuando el
formulario lo requiere
Comentarios: Resumen de comentarios
62
En el diseño de formularios son importantes los títulos, los cuales pueden ser de
los siguientes tipos:
Títulos con líneas:
Títulos debajo de la línea
Título en recuadro
63
Lista de verificación vertical
Lista de verificación horizontal
Título de tabla
18.1.2. CUMPLIR EL PROPÓSITO PARA EL CUAL SE DISEÑAN
64
Los formularios se deben diseñar, para cumplir con el propósito de registro,

procesamiento, almacenamiento y recuperación de información de las
organizaciones.
18.1.3. GARANTIZAR QUE LOS FORMULARIOS SE CONTESTEN CON

PRECISIÓN
El diseño de un formulario es importante para que los usuarios lo contesten de

forma correcta cada vez que se utilice y se recopile los datos necesarios,
precisos y confiables.
18.1.4. HACER FORMULARIOS ATRACTIVOS
Un formulario estético y ordenado atrae a los usuarios y los motivan a

contestarlos. El diseño y flujo apropiado contribuyen al atractivo de un
formulario. Es importante:
• Usar diferentes tipos de letra

• Separar categorías y subcategorías
• Separación de bloques con líneas gruesas y delgadas
18.2. VALIDACIÓN DE ENTRADAS
La validación de entrada es el conjunto de métodos que permiten detectar

errores en la entrada de datos. Validar la entrada es importante para asegurar
que se eliminaran con anticipación errores o problemas con los datos que se
ingresen. Se puede clasificar en:
65
VALIDACION
de las
de datos de
transacciones
entradas
de entrada
18.2.1. VALIDACIÓN DE LAS TRANSACCIONES DE ENTRADA
Esta validación de las transacciones de entrada, se realiza por software. Este

tipo de validación puede prevenir los siguientes problemas:
Enviar datos incorrectos
El sistema debe validar que los datos que se ingresan son los correctos.
Envió de datos por personas no autorizadas
El sistema debe verificar que los datos ingresados y que se envían son por personas
autorizadas, de igual forma, el sistema debe invalidar las transacciones cuando los datos han
sido ingresados por personas no autorizadas.
Ejecución de una acción inaceptable
66
Otro error que invalida las transacciones de entrada es que el sistema realice una función
inaceptable. En este caso no se debe permitir la creación de archivos ya existentes.
18.2.2. VALIDACIÓN DE DATOS DE ENTRADA
Las pruebas que se pueden utilizar para validar la entrada son:
De datos perdidos
Permite validar los datos para examinar si existe algún dato perdido. Consiste en verificar:
• Si el archivo contiene todos los datos clave.

• Casos excepcionales
• Entradas requeridas
De la longitud de campo correcta
Verifica que la longitud es la correcta para el campo. Verifica:
• Longitud de códigos
• Formatos requeridos
De la clase o composición
Verifica si los campos de datos que están compuestos por un formato especial se cumplen.
Del rango o racionalidad
Verifica si los datos se encuentran dentro del rango aceptable. Se incluye en estos la
validación de rangos de fecha ( de 1 a 31 días; de 1 a 12 meses)
De valores inválidos
La comprobación de estos valores se hace únicamente cuando hay unos cuantos valores
67
válidos. Es el caso de M= Masculino, F=Femenino

De referencia cruzada
Se usa cuando un elemento tiene una relación con otro.

De comparación con los datos almacenados
Consiste en comparar los datos recibidos con datos que se tienen almacenados. Por ejemplo:
comparar la cantidad de artículos solicitados con los artículos en existencia.
Creación de códigos de autovalidación
Se utiliza para asegurar la precisión de datos, especialmente en números o códigos de

identificación y consiste en usar un dígito de verificación en el propio dígito.
18.3. PROCESOS DE VALIDACIÓN
Cada campo se debe validar hasta que sea válido o se haya descubierto un
error. El proceso para la prueba de datos es la siguiente:
1 Verificar si hay datos perdidos

Verificar la sintaxis: verificar la longitud de los datos de entrada, su clase y
2
composición
Prueba de semántica: incluye: prueba de rango, razonabilidad o valor y validación del
3
dígito de verificación.
La validación de un solo campo se hace con un SI…ENTONCES… SI-NO, pero

también existe validación por medio de expresiones regulares. A continuación
se relaciona una serie da caracteres que se usan para validación de expresión
regular:
Código de carácter Significado usado en una validación de expresión regular
68
\d Representa un dígito de 0 a 9
\D Representa cualquier carácter que no sea un dígito del 0 al 9
\w Representa cualquier carácter alfanumérico
\W Representa cualquier carácter no alfanumérico
. Representa cualquier otro carácter excepto los caracteres que
representan un salto de línea
[caracteres] Hace coincidir el rango de caracteres
[a-z][A-Z][0-9] Acepta cualquier letra o dígito
[^caracteres] Hace coincidir cualquier otra cosa a parte de caracteres
[^char-char] Hace coincidir cualquier otra cosa fuera del rango de caracteres
[^a-z] Acepta cualquier cosa excepto letras en minúsculas
{n} Hace coincidir exactamente n ocurrencias del carácter que preceda al
símbolo
{n,} Hace coincidir por lo menos n ocurrencias del carácter
\s Cualquier carácter de formateo por espacio en blanco (tabulación,
línea nueva, retorno)
\S Representa cualquier carácter que no sea un espacio en blanco
\b Marca el inicio y el final de una palabra.
\B Marca la posición entre dos caracteres alfanuméricos o dos no-
alfanuméricos
LECCIÓN 19. DEFINICIÓN DE INTERFACE, DISEÑO DE DIALOGO Y

ESTRATEGIAS DE DIALOGO
Una interface es la frontera entre el usuario y el sistema. La meta del analista y

diseñador de sistemas es diseñar interfaces que permita a usuarios y
organizaciones conseguir la información que necesitan. Por tal razón, un
diseñador debe conseguir los siguientes objetivos al diseñar la interfaz:
69
• Hacer coincidir la interfaz de usuario con la tarea: Se debe introducir, cambiar o

recuperar datos, moverse entre las diferentes funciones del sistema
• Hacer eficiente la interfaz de usuario: Permite que los usuarios realicen acciones o
actividades de procesamiento de manera eficiente, se debe permitir solicitar y desarrollar
actividades de igual forma se debe facilitar el uso eficiente a usuarios novatos.
• Proporcionar a los usuarios la información necesaria: resultados que se generan como
respuesta a una entrada proporcionada por el usuario.
• Generar consultas utilizables: Generar informes y consultas con la información necesaria y
pertinente para el usuario.
19.1. CARACTERÍSTICAS DE LA INTERFACE
Incluye:
Dispositivos Permiten introducir y recibir datos. Entre los más comunes se tienen:
teclado, ratón, pluma óptica, scanner, pantalla sensible al tacto, pantalla
sensible a la voz, lectores de código de barras.
Diálogo Guía al usuario y conduce a la interacción entre el usuario y el sistema.
Métodos y Permite organizar la información para ser mostrada en el sistema en línea.
patrones para Se debe tener en cuenta:
mostrar la
información • Forma en que se estructura el área física del monitor
• Métodos para destacar, mostrar y señalar datos
• Posibilidades para lectura de la información mostrada
19.2. TIPOS DE ACCIONES EN LA INTERFACE
Los tres tipos de acciones que se llevan a cabo en la interface de un sistema

son:
70
19.3. DISEÑO DE DIALOGO
71
Los puntos clave para diseñar un buen diálogo son:
Comunicación significativa
El sistema debe presentar la información con claridad al usuario.
• Títulos apropiados para cada pantalla

• Minimizar el uso de abreviaciones ?
?
• Proporcionar retroalimentación útil

• Desplegar significados de códigos
• Desplegar los datos en formatos editados (formatos fecha, hora)
• Detalles de teclas de función
• Formatos del cursor en diferentes acciones
• Descripciones de gráficos utilizados
• Uso de líneas de estado
• Sistemas de ayuda de fácil uso
• Despliegue de sugerencias
• Uso de botones de comando
• Edición de datos, para su verificación
Linea de estado
72
Acción mínima del usuario

• Un buen diálogo minimiza el número de pulsaciones del teclado requeridas.
• Codificar códigos en lugar de palabras completas en los campos de entrada.
• Uso de listas desplegables de datos
• El sistema puede desplegar información descriptiva que se almacena en un archivo
determinado
• Proporcionar caracteres de edición
• Utilizar caracteres de formateo o campos con formato predefinido
• Usar valores predeterminados
• Uso de casillas de verificación
• Uso de botones de opción
• Uso de cuadros de diálogo
• Proporcionar menús sensibles
• Diseñar consultas de registros
• Proporcionar pulsaciones detectado
para seleccionar opciones de menú desplegables.
Funcionamiento normal y consistente

• El sistema debe ser consistente en su juego de pantallas y en los mecanismos para
controlar el funcionamiento de las pantallas en las diferentes aplicaciones.
• Localizar títulos, fecha, tiempo y menajes de retroalimentación en los mismos lugares en
todas las pantallas.
73
• Salir de cada programa mediante la misma función u opción del menú.
• Cancelar una transacción de forma consistente usualmente mediante la tecla ESC.

• Obtener ayuda de forma estandarizada. Tecla de función F1.
• Estandarizar los colores usados para todas las pantallas. Los mensajes de error
normalmente se despliegan en rojo. Se debe mantener el mismo color de fondo de
pantalla para todas las aplicaciones
74
• Estandarizar el uso de iconos para funciones similares.
• Usar terminología consistente en la pantalla de despliegue.
• Proporcionar una forma consistente para navegar entre los diálogos
• Usar alineación, tamaño y color de fuente consistentes
En el diseño del diálogo también es importante tener en cuenta los diagramas

para diálogos.
75
Diagramas para diálogos

Un diagrama para diálogos, es un mapa que presenta las secuencias que se pueden llevar a
cabo en un sistema y cómo iniciar las acciones.
Ejemplo:
76
19.4. ESTRATEGIA DEL DIALOGO
Diálogo por menú

Un menú es una lista de las funciones disponibles en el sistema, para que el usuario pueda
elegir entre ellas.
El usuario debe ser capaz de invocar cualquier opción del menú oprimiendo: una única
tecla, una combinación posible de teclas o haciendo clic.
Los diálogos de menú también se pueden diseñar para utilizar otros dispositivos de
interface como:
• Pantallas sensibles al tacto

• Pluma óptica
• Mouse
Las opciones del menú se pueden presentar con una sola palabra (dialogo de palabras
77
clave), con la que el usuario comprenda el propósito de la función.
En los sistemas que usan el Mouse (ratón), se utilizan mucho los menús pull-down (una
opción presenta un menú de alternativas).
Cuando existe un conjunto amplio de alternativas de las cuales se puede escoger, se

utilizan los menús anidados.
Los menús deben estar anidados cuando se da una o más de las siguientes condiciones:
• El número de alternativas es demasiado grande como para utilizar un único menú.
Cada opción depende de la anterior
Un sistema necesita una serie de opciones que, en forma progresiva, especifican más
detalles acerca de la aplicación.
78
Diálogo por medio del teclado

Por medio de este diálogo, el usuario llama a las actividades de procesamiento tecleando
un comando que entiende el sistema. Las tres formas de diálogo mediante teclado son:
• Forma de comando único. El analista determina una serie de palabras que son
comandos y que el usuario teclea y que el sistema asocia con la realización de un
proceso específico. Por ejemplo: se pueden crear un comando AÑADIR para introducir o
añadir un registro en el sistema.
• Forma de comando nemónico: consiste en el uso de abreviaturas de frases largas. Por
ejemplo: al teclear CCGO, comenzaran las acciones de los procesamientos “compilar,
cargar y ejecutar”.
• Forma de lenguaje natural: Los usuarios aplican su propio vocabulario o juego de
palabras u operaciones. Con la forma de lenguaje natural el sistema rastrea las frases
e identifica palabras clave.
Diálogo por pregunta / respuesta

Se basa en la presentación de preguntas al usuario y donde la respuesta guía el proceso
resultante. Las respuestas pueden tener el formato:
• Sí / No: ¿Desea imprimir el informe?

• Narrativas:
• ¿Qué propiedades desea revisar?
En esta forma de diálogo, el analista debe prever cualquier posible respuesta.
79
LECCIÓN 20. DIALOGO CON ENTRADA DE DATOS
Un formato para entrada de datos es una forma o bosquejo que muestra la

información a introducir, para esto es importante tener en cuenta:
• Títulos y encabezados en la pantalla

• Etiquetas que identifique los datos a introducir
• El área de entrada de datos puede estar señaladas por áreas en blanco, espacios
destacados
• El cursor debe desplazarse al siguiente dato una vez se ha introducido la información.
• Se debe sugerir el orden de los datos
• Se debe sugerir la secuencia de movimiento hacia arriba, hacia abajo, hacia delante o
hacia atrás en la pantalla.
El uso de formas, formatos o formularios sugiere un orden natural y lógico de información.
En la edición de datos, se debe tener en cuenta el diseño de: teclear los datos a almacenar,
hacer correcciones de errores tipográficos, y el almacenamiento de datos. Se debe
proporcionar una forma para que los usuarios digan cuáles son los registros a editar, se debe
decir en forma breve al usuario que debe hacer.
En el borrado de registros se debe proporcionar una forma en la que el usuario indique el

registro que desea borrar.
El uso de ventanas en los sistemas en línea y en el diálogo son de gran importancia, por eso se
debe proporcionar las siguientes áreas de ventanas:
80
Título Identifica el titulo de la pantalla, función o aplicación en ejecución

Instrucciones Le dice al usuario cómo introducir datos, elegir un proceso o salir del
sistema
Principal de texto Comprende la captura de datos o procesos alternativos
Navegación y menú Indica al usuario como moverse entre pantallas y menús
Errores Contiene mensajes de información y control.
20.1. PAGINACIÓN Y SCROLLING
Una página es una pantalla de información. La paginación se utiliza cuando la

información no se puede mostrar en una sola pantalla.
En su diseño se debe tener presente:
• El usuario puede ir hacia delante y hacia atrás en las páginas.

• Se debe identificar que pantalla se muestra, por medio de números de páginas.
• Se debe guiar al usuario a través de la información
El scrolling (las líneas de datos se desplazan hacia arriba y hacia abajo) se

utiliza para rastrear líneas específicas de listados lo que permite que el sistema
sea capaz de accesar rápidamente la información.
Al diseñar pantallas para scrolling se debe tener en cuenta:
81
Titulo pantalla
Encabezado
Scroll bar
< Back Next > Cancel
• Especificar qué datos deben aparecer en el scrolling

• Encabezados fijos en la pantalla
• Mensajes fijos
• Mensajes y comentarios
Los mensajes y comentarios son la forma de comunicación del sistema con los
usuarios.
Error critico
Mensaje o comentario de advertencia
Mensaje o comentario informativo
?
? Mensaje o comentario pregunta / respuesta
Los mensajes tienen los siguientes objetivos:
• Indicar el estado de un proceso

• Indicar que se ha detectado un error
• Solicitar al usuario que elija una acción
• Verificar que una acción elegida sea correcta
82
Mensajes de estado
• Informan al usuario sobre el progreso de un proceso específico.
• Informe al usuario sobre número de registros examinados
• Porcentaje de procesamiento terminado
• Número de registro consultado o examinado
• Mensajes de acciones que se llevan a cabo: “imprimiendo documento”,
“archivo transmitido”, “conexión establecida”.
Mensajes de error
Reportan equivocaciones o eventos inesperados que ha detectado el sistema. Abarcan
información desde el hardware, software o datos.
De igual forma se deben asociar mensajes de error en las pruebas de validación:
83
• Datos fuera de rango

• Datos con formato incorrecto
• Falta de datos
• Cuando se genera un mensaje de error se debe pedir que el usuario lleve a cabo una
acción.
Mensajes de solicitud de acciones

Son mensajes breves que dicen al usuario qué acción llevar a cabo y cuándo.
Mensajes de verificación de acciones

Se debe responder a todo comando introducido, ya sea por la iniciación inmediata de la
acción solicitada o mostrando un mensaje conciso.
Se debe diseñar mensajes para informar a los usuarios de:
• Borrar archivos
• Borrar registros del archivo maestro
• Solicitar la finalización de un proceso
• Solicitar la salida del sistema
• Solicitar la finalización de la comunicación con otro lugar.
84
20.2. SISTEMAS DE AYUDA
Los sistemas de ayuda tienen los siguientes objetivos:
• Auxiliar al usuario a completar una tarea tan rápido como sea posible
• Realizar una acción, proporcionando respuestas a preguntas como:
• ¿Cómo llevo a cabo…?
• ¿Cómo hago…?
Un sistema de ayuda se puede diseñar de las siguientes formas:
85
Una tecla específica siempre debe estar programada para llamar a la Ayuda. La
tecla F1 siempre se reserva para llamar la función de ayuda, al oprimir esta
tecla el usuario debe recibir un auxilio independientemente de la función a
consultar.
86
CAPÍTULO 5. DISEÑO DE ARCHIVOS
Incluye decisiones con respecto a la naturaleza y contenido del propio archivo,

como si se fuera a emplear para guardar detalles de:
• Transacciones
• Datos históricos
Entre las decisiones que se toman durante el diseño de archivos, se encuentran

las siguientes:
• Los datos que deben incluirse en el formato de registros

contenidos en el archivo.
• La longitud de cada registro, con base en las
Los archivos también denominados ficheros (file); es una colección de

información (datos relacionados entre sí), localizada o almacenada como una
unidad en alguna parte de la computadora.
Los archivos son el conjunto organizado de informaciones del mismo tipo, que
pueden utilizarse en un mismo tratamiento; como soporte material de estas
informaciones.
Los archivos como colección de datos sirven para la entrada y salida a la

computadora y son manejados con programas.
Los archivos pueden ser contrastados con Arrays y registros; Lo que resulta
dinámico y por esto en un registro se deben especificar los campos, él número
87
de elementos de un arrays (o arreglo), el número de caracteres en una cadena;

por esto se denotan como “Estructuras Estáticas”.
En los archivos no se requiere de un tamaño predeterminado; esto significa que

se pueden hacer archivos de datos más grandes o pequeños, según se necesiten.
Cada archivo es referenciado por su identificador (su nombre.).
El manejo de gran cantidad de datos es la consecuencia del aumento de

información que se maneja en el transcurso de nuestras vida y más aun en el
mundo empresarial, al incrementar todo este volumen de información que
diariamente se puede acumular en el manejo de una empresa u organización se
hace necesario organizarla para poder encontrar resultados rápidos y óptimos
en el momento de utilizarla.
Debido a esta necesidad en los años setenta, para manejar toda esta
información surgen las bases de datos, en la cual se integran archivos
individuales para poder ser compartidos por todos los usuarios de la empresa.
El diseño de la base de datos es de gran importancia en el manejo de la

información, ya que tiene como principal objetivo que los datos almacenados se
puedan utilizar por una gran numero de aplicaciones.
LECCIÓN 21. DIAGRAMA DE ESTRUCTURAS DE DATOS
Los diagramas de estructura de datos es una técnica que permite mostrar los
requerimientos lógicos de las estructuras de datos de una aplicación o sistema.
Los objetivos de estos diagramas son:
88
• Verificar los requerimientos de información

• Describir los datos asociados con las entidades
• Mostrar la relación entre entidades
• Comunicar los requerimientos de datos
• Construir un modelo lógico del sistema que facilite la comprensión del mismo.
Los diagramas de estructuras de datos, utilizan una notación básica la cual está
representada por:
El uso de los diagramas de estructuras de datos requiere que el analista haga

preguntas acerca de cada entidad, teniendo en cuenta:
• ¿Cuáles son los campos que identifican de manera única la entidad?

• ¿Qué otros datos describen los atributos de la entidad?
• ¿Por qué medio se accesará la información acerca de la entidad?
Fases para la construcción de la estructura de datos
89
LECCIÓN 22. TIPOS Y MÉTODOS DE ORGANIZACIÓN DE ARCHIVOS

90
Al diseñar un sistema es importante tener presente el diseño de los siguientes

tipos de archivos:
Archivo Maestro
Contiene todos los registros de una determinada base de datos, cada uno de las cuales
consiste en un conjunto de campos de longitud variable. Cada registro se identifica con un
número único, asignado automáticamente el cual se denomina: Número del archivo maestro o
MFN (iniciales de Master File Number).
Para tener un acceso rápido a cada registro del archivo maestro, se asocia al archivo maestro
un archivo especial denominado "Archivo de referencias cruzadas", que es en realidad un
índice que suministra la ubicación de cada registro en el archivo maestro. El archivo maestro
debe ser actualizado periódicamente.
También existe un archivo maestro histórico que refleja la historia de los eventos que
afectan a una entidad particular.
Archivo de transacciones
Es un archivo temporal, en donde se registran las operaciones que se realizan en un periodo
determinado. Una vez transcurrido este se realiza la actualización del archivo maestro y se
reinicializa el de transacciones.
Los archivos de transacciones se utilizan para actualizar los archivos maestros.
91
Archivo de tablas
Un archivo de tablas contiene datos que se utilizan para calcular otros datos o más
parámetros de desempeño.
Los archivos de tablas contienen datos de referencia utilizados en el procesamiento de

transacciones y actualización de archivos maestros.
Archivo de reportes
Es aquel que se utiliza para notificar la ocurrencia de errores o casos especiales en la
operación de un sistema. Ocasionalmente contiene también los resultados finales de los
procesos.
Archivo de respaldo
Es una copia de:
• Un archivo maestro
• Un Archivo de transacciones
• Un archivo de tablas
Garantizando que se dispone de un duplicado si algo le ocurre al archivo original.
92
22.1. MÉTODOS DE ORGANIZACIÓN DE ARCHIVOS
Determinan cómo se almacenan, localizan y recuperan los registros de un

sistema. La forma en que se organizan los registros dentro de un archivo en
particular, repercutirá en la agilidad y velocidad de las consultas, es por esto
que existen diferentes métodos de organización donde las necesidades de
consultas establecerán la utilización de uno u otro método.
Organización Secuencial
Es una organización que consiste en almacenar y recuperar datos en forma contigua (uno tras
otro). Para acceder al registro n deben procesarse los n-1 registros previos. Una de las
ventajas que ofrece esta organización es el buen aprovechamiento que se hace del medio de
almacenamiento, así como la facilidad (relativa) en su implementación y el bajo costo de
operación al no requerir de un medio de almacenamiento direccionable.
Para leer un archivo secuencial, el sistema siempre comienza al principio del archivo y lee un
registro a la vez hasta llegar al registro deseado.
Los archivos secuenciales no utilizan llaves de registro físico, los registros se acceden por su
orden de aparición en el archivo por medio de una llave de búsqueda. Se realiza un proceso
de comparación y búsqueda continua hasta alcanzar el final del archivo.
93
Por ejemplo,
Organización de acceso directo

La organización directa de archivos permite el acceso aleatorio de los registros de los
archivos.
Este método solicita al sistema que establezca dónde se almacena un registro. Los archivos de
acceso directo son archivos con llave. Asocian un registro con un valor llave específico y un
lugar particular de almacenamiento. Todos los registros se almacenan mediante las llaves en
las direcciones en vez de posiciones; si el programa conoce la llave del registro, puede
determinar la dirección de localización de un registro y recuperarlo en forma independiente
de los demás registros del archivo.
El uso de la llave del registro como la dirección de almacenamiento se llama

direccionamiento directo. El direccionamiento directo debe tener un conjunto de datos con
las siguientes características:
El conjunto de llaves. Las llaves de los registros corresponden con los números de las
direcciones de almacenamiento; existe una dirección de almacenamiento en el archivo para
cada valor real o posible de la llave y no hay valores duplicados de la llave
Organización Indexada
Este tipo de organización de archivos utiliza archivos de índice separados para localizar
registros.
Un archivo secuencial indexado está formado por dos archivos:
94
• Un archivo que contiene los datos clasificados y ordenados por un campo llave
• Un archivo que tiene una serie de índices utilizados para el acceso de los datos.
Por ejemplo:
Mediante ésta organización, se permite el acceso a los archivos en forma secuencial como
aleatoria. La ventaja de éste método de organización es su flexibilidad.
LECCIÓN 23. RESPALDO Y RECUPERACIÓN DE ARCHIVOS
Consiste en la definición de métodos y procedimientos de copias de seguridad

para todos los archivos de datos. Las copias de seguridad se utilizan para
recuperar los datos cuando los archivos originales se pierden o se destruyen.
Todos los archivos maestros y de transacciones deben copiarse periódicamente

en cintas u otros dispositivos de almacenamiento.
Procedimientos de respaldo para archivos en cinta magnética
Este sistema de respaldo se conoce como procedimiento de reconstrucción de

archivos de abuelo – padre – hijo. Con este procedimiento se disponen de tres
versiones de un archivo, así:
95
De ésta forma, se almacenan en tres sitios diferentes, tres versiones del archivo
maestro y las versiones anterior y actual del archivo de transacciones.
La recuperación de un archivo perdido, sólo requiere volver a ejecutar la

corrida de actualización.
Procedimientos de respaldo para archivos en disco magnético
En muchos sistemas existe la ventana de respaldo entre el ciclo interactivo

diario y el ciclo nocturno de procesamiento por lotes. Esta ventana de respaldo,
consiste en el vaciado en discos magnéticos de sistemas que operan las 24
horas. Estas ventanas de respaldo pueden durar de 40 o más minutos y se
realizan una o dos veces al día.
En sistemas de tiempo real en línea, las estrategias de respaldo implican

conservar una versión previa de la base de datos además de una bitácora de
transacciones. Los procedimientos re recuperación son:
De avance (rollforward): utiliza un vaciado previo de la base de datos y una

bitácora de transacciones para recuperar el estado actual de la base de datos si
ésta se perdió.
De regreso (rollback): este procedimiento se utiliza, si se debe restablecer un

estado anterior de la base de datos debido a que el estado actual de la misma
es inválido
23.1. OTRAS ESTRATEGIAS DE RESPALDO Y RECUPERACIÓN
96
1. Vaciado y registro completos en bitácora de las transacciones de entrada

Consiste en realizar una copia completa de toda la base de datos en un medio de respaldo
(cinta magnética). Se incluye también todas las transacciones de entrada, con indicadores de
tiempo y algunos parámetros re modificación.
2. Archivo diferencial
Contiene cambios y actualizaciones a la base de datos principal. La base de datos principal no
se modifica. Este archivo se debe almacenar en un medio distinto y confiable. La base de
datos principal contiene imágenes previas de los registros, de manera que el procedimiento
de regreso es bastante sencillo y el vaciado frecuente del archivo diferencial facilita el
procedimiento de avance.
3. Respaldo y recuperación dual
Consiste en un respaldo en línea. Se proporcionan dos copias completamente separadas de la
base de datos al actualizar ambas simultáneamente. Una copia se almacena en las
instalaciones propias, mientras que la otra copia se almacena fuera de las instalaciones. Este
enfoque de respaldo, hace innecesario los vaciados periódicos o copiados incrementales de los
archivos.
LECCIÓN 24. DESARROLLO DE SISTEMAS EN UN AMBIENTE DE BASES

DE DATOS
Los sistemas de bases de datos se diseñan para gestionar grandes cantidades de

información.
Existen distintos objetivos que deben cumplir los Sistemas de Base de datos:
97
98
24.1. ABSTRACCIÓN DE DATOS
Para que el sistema sea útil, si debe recuperar los datos eficientemente. Los
tres niveles de abstracción de datos son:
99
24.2. MODELOS DE LOS DATOS
Bajo la estructura de la base de datos se encuentra el modelo de datos. El

modelo de datos es una colección de herramientas conceptuales para describir
los datos, las relaciones, la semántica y las restricciones de consistencia. Los
diferentes modelos de datos que se han propuesto se clasifican en tres grupos
diferentes:
Modelos Lógicos Basados en Objetos

Los modelos lógicos basados en objetos se usan para describir los datos en los niveles
conceptual y de visión. Se caracterizan porque proporcionan una capacidad de estructuración
bastante flexible y permiten especificar restricciones de datos explícitamente.
100
a. Modelo Entidad-Relación
El modelo E-R (Entidad-Relación) es un modelo de datos conceptual de alto nivel y que se

suele utilizar bastante en el diseño de bases de datos. Se basa en una percepción del mundo
real que consiste en un conjunto de objetos básicos denominados entidades y relaciones, y se
desarrolló para facilitar el diseño de bases de datos.
El modelo E-R crea un modelo de la realidad que se asimila a la realidad que queremos
modelar, y lo hace de forma que es independiente de la implementación posterior,
ofreciendo un alto nivel de abstracción, y siendo una herramienta gráfica fácil de
comprender.
El resultado del modelado E-R es un diagrama E-R que representa una estructura lógica
general de la base de datos.
Ejemplo
b. Modelo Orientado a Objetos
Este modelo se basa en la percepción de una colección de objetos.
Un objeto se caracteriza por tener:
101
Corresponde a los valores que toman un conjunto de propiedades

1. Estado
instancia
2. Comportamiento Es llevado a cabo mediante una serie de operaciones o

operan sobre el objeto, y que se denominan métodos.
Los objetos que tienen el mismo tipo de propiedades y el mismo comportamiento son
agrupados en clases. Dichas clases se organizan en un diagrama o jerarquía de clases, en el
que las clases pueden estar relacionadas mediante relaciones de asociación o mediante
relaciones de herencia. La herencia permite la definición de clases a partir de clases
existentes heredándose a las nuevas clases las propiedades y el comportamiento de las clases
existentes, cumpliéndose también que todos los objetos de una subclase también es objeto de
su superclase.
La única forma en la que un objeto puede acceder a los datos de otro objeto es a través de
los métodos de este objeto. Esto se denomina envío de mensajes al objeto. De esta forma, la
interfaz de llamada mediante los métodos de un objeto define la parte visible, mientras que
la parte interna del objeto (variables y código de los métodos) no es visible externamente. De
esta forma se tienen dos niveles de abstracción.
Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos
importantes de la programación orientada a objetos:
Encapsulación: Ocultar datos del resto de los datos, impidiendo así accesos incorrectos o
conflictos.
Herencia: Reusabilidad del código.
Polimorfismo: Sobrecarga de operadores o de métodos.
102
Clase A
Clase B
Clase C Clase D Clase E
Modelos Lógicos Basados en Registros

a. Modelo Relacional
Éste es el modelo más utilizado para modelar problemas reales y administrar datos
dinámicamente.
El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los
datos:
Su idea fundamental es el uso de "relaciones". Estas relaciones podrían considerarse en forma

lógica como conjuntos de datos llamados "tuplas".
Esto es pensando en cada relación como si fuese una tabla que está compuesta por registros
(las filas de una tabla), que representarían las tuplas, y campos (las columnas de una tabla).
En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia. Esto
tiene la considerable ventaja de que es más fácil de entender y de utilizar para un usuario
103
casual de la base de datos. La información puede ser recuperada o almacenada por medio de
"consultas" que ofrecen una amplia flexibilidad y poder para administrar la información.
El lenguaje más común para construir las consultas a bases de datos relacionales es SQL,
Structured Query Language o Lenguaje Estructurado de Consultas, un estándar implementado
por los principales motores o sistemas de gestión de bases de datos relaciónales.
Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización
de una base de datos.
b. Modelo de Red
En éste modelo un mismo nodo puede tener varios padres (algo no permitido en el modelo
jerárquico).
Éste modelo ofrece una solución eficiente al problema de redundancia de datos, pero aun así,
la dificultad que significa administrar la información en una base de datos de red, ha
significado que sea un modelo utilizado en su mayoría por programadores más que por
usuarios finales.
Colecciones de registros y las relaciones entre datos se representan mediante enlaces

dirigidos.
104
c. Modelo Jerárquico
Una base de datos jerárquica es un conjunto de registros lógicamente organizados en una

estructura de árbol invertido. En este modelo los datos se organizan en una forma similar a
un árbol, en donde un nodo padre de información puede tener varios hijos. El nodo que no
tiene padres se le conoce como raíz, y a los nodos que no tienen hijos se les conoce como
hojas.
Una de las principales limitaciones de este modelo, es su incapacidad de representar

eficientemente la redundancia de datos.
Los registros se organizan como colecciones de árboles, en lugar de grafos dirigidos.

Modelo físico
El modelo físico opera al más bajo nivel de abstracción y describen cómo se almacenan los
datos, el formato de los registros, la estructura de los ficheros y los métodos de acceso.
El modelo físico requiere de asignaciones de tareas precisas por lo que se hace dependiente
tanto del hardware como del software. Por lo tanto los diseñadores de bases de datos deben
tener un conocimiento detallado del hardware y del software utilizado para poder ejecutar
el diseño de la base de datos.
105
LECCIÓN 25. ESTRUCTURACIÓN DE DATOS
Un buen diseño de base de datos debe ser acorde con las estructuras de los
datos. El proceso que permite evaluar y diseñar bases de datos bien
estructuradas y sin redundancia de datos se conoce como Normalización.
25.1. NORMALIZACIÓN
La normalización es un proceso en el cual se va comprobando el cumplimiento

de una serie de reglas, o restricciones, por parte de un esquema de relación;
cada regla que se cumple aumenta el grado de normalización del esquema de
relación; si una regla no se cumple, el esquema de relación se debe
descomponer en varios esquemas de relación que sí la cumplan por separado.
Ventajas de la normalización
• Evita anomalías en inserciones, modificaciones y borrados.

• Mejora la independencia de los datos.
• No establece restricciones artificiales en la estructura de los datos.
La normalización funciona mediante una serie de etapas denominadas Formas

Normales.
Un esquema de relación está en una determinada forma normal si satisface un

cierto conjunto de restricciones.
106
25.2. FORMAS NORMALES
Nota: En este item, se referencia la información que es importante en el diseño de bases de datos y
que se debe tener en cuenta como diseñadores. Los temas aquí tratados corresponden al curso de Base
de datos, para ampliar éstos se recomienda la consulta del material: Figueredo Luna, John Alejando.
Bases de datos básico. Universidad Nacional Abierta y a Distancia. UNAD. 2005
25.2.1. PRIMERA FORMA NORMAL (1FN)
Describe la forma en la cual:
• Todos los atributos de clave están definidos.

• No existen grupos repetidores en la tabla. Es decir, cada
intersección de fila/columna puede contener uno y sólo un valor,
no un conjunto de valores.
25.2.2. SEGUNDA FORMA NORMAL (2FN)
Una relación se encuentra en segunda forma normal cuando:
107
Dependencia funcional: Consiste en identificar que atributos dependen de

otro(s) atributo(s).
Es decir, cada tabla que tiene un atributo único como clave, está en segunda
forma normal.
25.2.3. TERCERA FORMA NORMAL (3FN)
Una relación se encuentra en tercera forma normal cuando:
Consiste en eliminar la dependencia transitiva que queda en una segunda forma

normal, se habla de dependencias transitivas cuando existe más de una forma
de llegar a referencias a un atributo de una relación.
25.2.4. FORMA NORMAL DE BOYCE CODD (FNBC)
Una relación se encuentra en FNBC si y sólo sí:
108
Determinante: Uno o más atributos que, de manera funcional, determinan otro

atributo o atributos. En la dependencia funcional (A, B) -->C, (A, B) son los
determinantes.
25.2.5. CUARTA FORMA NORMAL (4FN)
Un esquema de relaciones R está en 4FN con respecto a un conjunto D

de dependencias funcionales y de valores múltiples sí, para todas las
dependencias de valores múltiples en D de la forma X->->Y, donde X<=R y Y<=R,
se cumple por lo menos una de estas condiciones:
25.2.6. QUINTA FORMA NORMAL (5FN)
Un esquema de relaciones R está en 5FN con respecto a un conjunto D de

dependencias funcionales, de valores múltiples y de producto, si para todas las
dependencias de productos en D se cumple por lo menos una de estas
condiciones:
La quinta forma normal tiene que ver con tablas que pueden dividirse en
subtablas, pero que no pueden reconstruirse.
109
CAPÍTULO 6. DISEÑO PARA COMUNICACIÓN DE DATOS
Los sistemas de información hoy en día implican una interactividad y

transmisión de datos entre diferentes dispositivos y/o sistemas que se deben
compartir en la red.
110
Para un analista de sistemas es importante tener en cuenta ciertos elementos al

momento de analizar y diseñar sistemas de información que impliquen
comunicación de datos.
La calidad debe ser un factor de importancia y preocupación para los analistas y

diseñadores de sistemas de información. Se corre un gran riesgo cuando se
decide emprender proyectos de sistemas sin un enfoque de calidad definido.
Los enfoques para un aseguramiento de la calidad mediante la ingeniería de

software son:
1 Diseñar sistemas y software con un enfoque
2 Documentar el software con la herramienta
3 Probar, mantener y auditar el software
Los analistas y diseñadores de sistemas deben ser conscientes del compromiso

de las empresas hacia la administración de la calidad total.
En muchas aplicaciones es esencial la necesidad de flexibilidad en el de los

distintos objetos que intervienen en el diseño del desarrollo de un aplicativo.
El manejo de objetos le facilita al usuario final no solo la interacción con el

sistema, sino que convierte a este en una herramienta amigable, confiable y en
la que se podrá confiar para una toma de decisión.
LECCIÓN 26. REQUERIMIENTOS PARA SISTEMAS DE COMUNICACIÓN DE

DATOS
111
Se debe tener en cuenta los siguientes componentes:
Es el medio por el que se transmiten los datos a su destino. Se dividen en:
1.
Canales de
comunicación
Las características de cada tipo de canal influyen en:
Velocidad
Costo
Distancias de transmisión
2. Siempre que se transmiten datos, deben existir elementos de interconexión
entre los computadores y los medios de transmisión o canales.
Dispositivos de
control de Los dispositivos más comunes son:
comunicación
112
El analista de sistemas debe enfatizar por qué y cuándo especificar estos

dispositivos en el diseño de un sistema.
Los canales de comunicación y los dispositivos de control de comunicación,
necesitan de una serie de reglas que permitan a éstos comunicarse entre sí.
Estas reglas reciben el nombre de protocolos y permiten a los distintos
dispositivos comunicarse entre sí de tal forma que cada uno pueda enviar y
recibir señales comprensibles y válidas.
Un protocolo debe realizar las siguientes funcionalidades:
Permitir localizar un ordenador de forma inequívoca.
3. Permitir realizar una conexión con otro ordenador.
Protocolos de Permitir intercambiar información entre ordenadores de forma segura,

comunicación independiente del tipo de máquinas que estén conectadas.
Proporcionar un indicador constante de que los datos están siendo recibidos

y comprendidos o bien que no están siendo recibidos o que llegan en forma
desordenada.
Solicitar la retransmisión de los datos erróneos.
Cuando se habla de protocolos es importante tener en cuenta las siguientes

características en el diseño:
113
Existen muchos protocolos. A pesar de que cada protocolo facilita la

comunicación básica, cada uno tiene un propósito diferente y realiza
distintas tareas. Cada protocolo tiene sus propias ventajas y sus
limitaciones.
Algunos protocolos sólo trabajan en ciertos niveles OSI. El nivel al que

trabaja un protocolo describe su función.
Los protocolos también pueden trabajar juntos en una jerarquía o

conjunto de protocolos. Al igual que una red incorpora funciones a cada
uno de los niveles del modelo OSI, distintos protocolos también trabajan
juntos a distintos niveles en la jerarquía de protocolos. Los niveles de la
jerarquía de protocolos se corresponden con los niveles del modelo OSI.
Jerarquías de protocolos
Una jerarquía de protocolos es una combinación de protocolos. Cada nivel

de la jerarquía especifica un protocolo diferente para la gestión de una
función o de un subsistema del proceso de comunicación. Cada nivel tiene
su propio conjunto de reglas. Los protocolos definen las reglas para cada
nivel en el modelo OSI así:
Aplicación Inicia o acepta una petición

Presentación Adiciona información de formato, presentación y cifrado
Sesión Adiciona información del flujo de tráfico para determin
Transporte Adiciona información para el control de errores
Red Se adiciona información de dirección y secuencia al paqu
Enlace de datos Adiciona información de comprobación de envío y prepa
física
Físico El paquete se envía como una secuencia de bits
114
A continuación se referencia los protocoles en correspondencia con su nivel:
Aplicación
Trabajan en el nivel superior del modelo de referencia OSI y

proporcionan interacción entre aplicaciones e intercambio de datos
APPC (Comunicación avanzada entre programas)
Trabaja en el nivel de presentación del modelo OSI. Sin

embargo, también se considera un protocolo de transporte
porque APPC utiliza el protocolo LU 6.2 que trabaja en los
niveles de transporte y de sesión del modelo OSI.
FTAM (Acceso y gestión de la transferencia de archivos)
Un protocolo OSI de acceso a archivos

X.400 Un protocolo CCITT para las transmisiones internacionales
de correo electrónico.
X.500 Un protocolo CCITT para servicios de archivos y directorio
entre sistemas.
SMTP (Protocolo básico para la transferencia de correo)
Un protocolo Internet para las transferencias de correo

electrónico.
FTP (Protocolo de transferencia de archivos)
Un protocolo para la transferencia de archivos en Internet.

SNMP (Protocolo básico de gestión de red)
Un protocolo Internet para el control de redes y

componentes.
Telnet Un protocolo Internet para la conexión a máquinas remotas
115
y procesar los datos localmente.

SMBs (Bloques de mensajes del servidor) de Microsoft y
clientes o redirectores
Un protocolo cliente/servidor de respuesta a peticiones.

NCP ( Protocolo básico de NetWare) y clientes o redirectores
Un conjunto de protocolos de servicio.
AppleTalk Conjunto de protocolos de red de Apple.

y
AppleShare
AFP (Protocolo de archivos AppleTalk)
Protocolo de Apple para el acceso a archivos remotos.

DAP (Protocolo de acceso a datos)
Un protocolo de DECnet para el acceso a archivos.

De transporte
Facilitan las sesiones de comunicación entre equipos y aseguran que los

datos se pueden mover con seguridad entre equipos.
TCP El protocolo de TCP/IP para la entrega garantizada de datos
en forma de paquetes secuenciados.
SPX Parte del conjunto de protocolos IPX/SPX de Novell para datos
en forma de paquetes secuenciados.
NWLink La implementación de Microsoft del protocolo IPX/SPX.
NetBEUI (Interfaz de usuario ampliada NetBIOS)
Establece sesiones de comunicación entre equipos (NetBIOS) y

proporciona los servicios de transporte de datos subyacentes
116
(NetBEUI).
ATP (Protocolo de transacciones Apple Talk) y NBP (Protocolo de
asignación de nombres)
Protocolos de Apple de sesión de comunicación y de

transporte de datos.
De Red
Proporcionan lo que se denominan «servicios de enlace». Estos protocolos

gestionan información sobre direccionamiento y encaminamiento,
comprobación de errores y peticiones de retransmisión. Los protocolos de
red también definen reglas para la comunicación en un entorno de red
particular.
IP El protocolo de TCP/IP para el encaminamiento de paquetes.
IPX El protocolo de Novell para el encaminamiento de paquetes.
NWLink La implementación de Microsoft del protocolo IPX/SPX.
NetBEUI Un protocolo de transporte que proporciona servicios de
transporte de datos para sesiones y aplicaciones NetBIOS.
DDP (Protocolo de entrega de datagramas): Un protocolo de Apple
Talk para el transporte de datos.
26.1. REDES DE COMUNICACIÓN
El diseño de una red de comunicaciones implica la elección de:
• Un topología
• Una arquitectura
• Topologías de red
La topología de red, es la disposición física en la que se conecta una red de

computadores. Las redes pueden ser en:
117
Anillo Las estaciones se conectan formando un anillo. Cada estación está

conectada a la siguiente y la última está conectada a la primera.
Cada estación tiene un receptor y un transmisor que hace la función
de repetidor, pasando la señal a la siguiente estación del anillo.
Árbol
En este tipo de red, los nodos están colocados en forma de árbol. La
conexión en árbol es parecida a una serie de redes en estrella
interconectadas.
Malla
Cada nodo está conectado a uno o más de los otros nodos. De esta
manera es posible llevar los mensajes de un nodo a otro por
diferentes caminos.
Bus
Todos sus nodos se encuentran conectados directamente a un enlace
y no tiene ninguna otra conexión entre nodos.
Estrella
Todas las estaciones están conectadas por separado a un centro de
comunicaciones, concentrador o nodo central, pero no están
conectadas entre sí.
Las nuevas redes sin cables hacen posible que se pueda conectar a
Red inalambrica una red local cualquier dispositivo sin necesidad de instalación. La
norma IEEE 802.11b dio carácter universal a esta tecnología que
wi-fi
permite la conexión de cualquier equipo informático a una red de
datos Ethernet sin necesidad de cableado, que actualmente se
puede integrar también con los equipos de acceso ADSL para
Internet.
Celular La topología celular está compuesta por áreas circulares o

hexagonales, cada una de las cuales tiene un nodo individual en el
118
centro.
La topología celular es un área geográfica dividida en regiones

(celdas) para los fines de la tecnología inalámbrica. En esta
tecnología no existen enlaces físicos; si lo hay ondas
electromagnéticas.
26.2. ARQUITECTURAS DE RED
Una arquitectura de redes es un conjunto de protocolos y niveles que dan una

solución completa a sistemas de Telecomunicaciones o Teleinformática.
Algunas arquitecturas son:
• OSI
• TCP/IP
• XNS
• Red de sistemas distribuidos, DNS
• Arquitectura de red de sistemas, SNA
• Arquitectura de red distribuida, DNA
• AppleTalk
• Arquitectura Novell IPX
• Arquitectura IBM & Microsoft
En una arquitectura se detallan:
119
Rutas de transmisión
Protocolos
Medidas de seguridad
Métodos de interconexión
LECCIÓN 27. DISEÑO DE SISTEMAS CONFIABLES
Un sistema es confiable sino produce fallas costosas o peligrosas al usarse de

manera normal.
27.1. ENFOQUES DE LA CONFIABILIDAD
Existen dos niveles de confiabilidad.
El sistema cumple con los requerimientos correctos
Los resultados reales que entrega el sistema al usuario
La confiabilidad a nivel de diseño es posible si el analista lleva a cabo un

detallado levantamiento de los requerimientos del sistema.
Un error aparece cuando el sistema no Una falla es la aparición de un error del

produce los resultados esperados. software, con un cierto peso de seriedad.
120
Existen tres enfoques para la confiabilidad:
Enfoque Característica
Prevención de errores Previene la ocurrencia de errores en el software
Detección y corrección de Reconoce los errores cuando se les halla y se corrige el error o
errores el efecto del error de forma que el sistema no falla.
Tolerancia a errores Capacidad de un sistema para seguir funcionando cuando
Se produce un error en parte del sistema.
27.2. DISEÑOS FÁCILES DE MANTENER
Un sistema tiene una vida promedio de 4 a 6 años, por lo que hace necesario el
mantenimiento continuo de los sistemas. Es por esto, que los analistas deben
garantizar que la necesidad del mantenimiento se controle por medio del
diseño y de pruebas y que la capacidad para llevar a cabo ese mantenimiento se
asegure mediante adecuadas prácticas de diseño.
Para reducir la necesidad de mantenimiento, es importante tener en cuenta los

siguientes criterios:
• Definir con gran precisión los requerimientos del usuario

• Diseñar y desarrollar la documentación del sistema
• Usar métodos para el diseño de la lógica del procedimiento
• Hacer uso de herramientas y técnicas
LECCIÓN 28. GRÁFICAS DE ESTRUCTURAS DE PROGRAMAS, DISEÑO DE

SOFTWARE Y HERRAMIENTAS DE DOCUMENTACIÓN
121
Los diagramas de estructura son una herramienta de diseño que muestran

gráficamente las relaciones entre los módulos de un programa. Muestra
además, cuáles módulos interactúan dentro del sistema y los datos que se
comunican entre varios módulos.
Los diagramas de estructura son una herramienta que permiten ayudar al

analista a desarrollar software que cumpla los objetivos del buen diseño de
software.
28.1. SIMBOLOGÍA
Rectángulo Identifica los módulos del programa

Flechas Indican las llamadas a los módulos
Flecha pequeña con un circulo hueco Denota transferencia de parámetros
Flecha pequeña con un circulo lleno Identifica información de control. Se describe el
tipo de información transferida
28.2. DISEÑO DE SOFTWARE

122
Los principios que deben guiar el diseño del software son:
Modularidad y fragmentación
El software se divide en componentes nombrados y abordados por separado, llamados
Módulos que se integran para satisfacer los requisitos del sistema.
Acoplamiento
Es el grado de interdependencia entre los módulos; depende del número de parámetros que
se intercambian para su comunicación.
El objetivo que se debe conseguir es minimizar el acoplamiento, o lo que es lo mismo, hacer

que los módulos sean tan independientes como sea posible, aunque esto no siempre se
consiga. Un bajo acoplamiento entre los, módulos indica que se ha hecho una buena
descomposición del sistema, aunque esto no ocurre siempre.
Un bajo acoplamiento es deseable por las razones siguientes:
Cuantas menos conexiones existan entre dos módulos, menos oportunidad habrá de que
aparezca el «efecto onda» (un defecto de un módulo, puede aparecer afectando a otro).
Se desea tener posibilidad de cambiar un módulo con el mínimo riesgo de tener que cambiar
otro, se trata de que cada cambio realizado afecte lo menos posible a otros módulos.
Mientras se esté manteniendo un módulo, es deseable no necesitar preocuparse en los

detalles internos (código) de cualquier otro módulo.
Cohesión
Es la medida de la fuerza o relación funcional de los elementos de un módulo, entendiendo
por elementos a la sentencia o grupo de sentencias que lo componen, a las definiciones de
datos o a las llamadas a otros módulos.
Un módulo coherente ejecuta una tarea sencilla en un programa o procedimiento y requiere

poca interacción con otros procedimientos que se ejecuten en otras partes del programa.
123
Extensión de control
Hace referencia al número de módulos subordinados al módulo que hace la llamada. Limitar
la extensión de control de 5 a 7 módulos.
Tamaño
Número de instrucciones que componen a un módulo. Limitar el tamaño de forma que la
función de todo el módulo se centre en un solo propósito.
Uso compartido
Uso de un módulo por otros módulos. Evitar la duplicación permitiendo que los módulos sean
llamados por otros que necesitan la función de cada uno.
28.3. HERRAMIENTAS DE DOCUMENTACIÓN
El analista y diseñador de sistemas debe hacer conciencia sobre la importancia

y las ventajas que se obtienen al documentar claramente un sistema y de la
trascendencia que este trabajo tiene para cada organización.
La documentación tiene los siguientes objetivos:
Documentar un sistema tiene las siguientes ventajas:

124
• Acortar la cantidad de horas requeridas por las nuevas personas que se

agreguen al equipo de trabajo para que aprendan el sistema antes de realizar
el mantenimiento
• Nos ayudan cuando surgen problemas
• No se depende de una persona o un grupo reducido de personas para realizar
modificaciones al software
• Reglas para documentar sistemas

• Creación de Estándares: Nombres, simbología y metodología
• Documentar cada una de las etapas del ciclo de vida de sistemas
• La documentación debe ser realizada por el equipo de desarrollo (analistas, diseñadores,
desarrolladores, programadores)
• Organizar la información por carpetas: Administrativa, Usuario, Proyecto
¿Qué se debe documentar en cada etapa?
Etapa Documentación
• Detección y definición del problema que motiva la creación de un sistema
de información automatizado
• Identificación de usuarios y funciones
• Planteamiento del problema organizacional
• Nombre del proyecto
• Planteamiento de una o varias soluciones al problema
Análisis
• Objetivo del sistema
• Alcance funcional
• Características generales
• Contribución a la solución
• Estimación del costo de adquisición de cada una de las soluciones y
definición de las condiciones en las cuales se desarrollarán e implantaran.
125
• Costo de desarrollo
• Costo de implantación
• Requerimientos
• Restricciones
• Evaluación de las alternativas de solución para determinar cuál de ellas es
la mejor opción
• Análisis de Costo-Beneficio
• Estudio de Factibilidad
• Diagramas:
• De contexto
• Flujos de datos
• Diccionario de datos
• Tiempos de desarrollo
• Diseño de interfaces, entradas y salidas

• Diseño de la base de datos: lógico y físico
Diseño • Creación del prototipo
• Definición de los tipos de pantallas
El desarrollo de una aplicación no es otra cosa que la elaboración de los

programas de que consta un sistema de información y en términos generales
en esta etapa se deben definir los archivos de inicio, se deben desarrollar los
módulos correspondientes los cuales deben ir documentados en forma clara y
precisa.
Desarrollo
Aparte de la documentación interna de los programas, se deben generar dos
documentos al culminar esta etapa, dichos documentos son:
El manual • Debe tener una descripción general de lo que es el

de la sistema, debe contener detalles de su construcción e
126
Aplicación instrucciones de su manejo o funcionamiento. Como

mínimo el manual de la aplicación debe contener los
siguientes temas:
• Objetivo General de la aplicación.
• El alcance.
• Arquitectura del Sistema.
• Especificaciones Generales del Sistema.
• Especificaciones Técnicas del Sistema.
• Modelo E-R
• Diccionario de Datos
• Definición de módulos
• Mapa general de la aplicación.
• Definición de variables de acceso
• Especificaciones de Manejo del Sistema.
• Proceso de Instalación
• Cómo Iniciar el Sistema.
• Cómo Terminar el Sistema.
• Cómo obtener ayuda en línea
• Descripción de la Barra de Herramientas. Descripción
de la Barra de Menú.
• Ayuda en Línea.
• Tiene como propósito dar una visión rápida de lo que es la

aplicación y estará ubicado en el directorio \Manuales de
cada aplicación, debe contener:
Ficha
• Nombre de la Aplicación
Técnica
• Área(s) Usuario(s)
• Autores y/o Responsables de la aplicación
• Fecha de liberación de la aplicación
127
• Herramientas de Desarrollo utilizadas

• Ubicación de los Archivos Fuentes
• Ubicación de la base de Datos, especificando ruta, nombre
del Servidor y nombre de la base de datos.
• Nombre de Usuario y su correspondiente Password para
mantenimiento.
• Nombre del archivo que contiene el menú de navegación de
la aplicación.
• Ubicación de los manuales del sistema.
• Manuales del usuario
• Documentación de resultados de las pruebas con:

• Datos ejemplo
Pruebas
• Datos reales
• Entrenamiento a usuarios
Implantación • Plan para la conversión del sistema anterior al sistema nuevo
LECCIÓN 29. MANEJO DEL PROCESO PARA GARANTIZAR LA CALIDAD Y

MANEJO DE LAS PRÁCTICAS DE PRUEBA
Se usan cuatro niveles de aseguramiento de la calidad:
128
29.1. MANEJO DE LAS PRÁCTICAS DE PRUEBA
29.1.1. ORGANIZACIÓN PARA LAS PRUEBAS DEL SOFTWARE
129
Toda prueba de software debe tener la coordinación de actividades:
• El responsable del desarrollo del software es el responsable de probar las unidades del
programa y a veces se encarga también de la prueba de integración.
• Cuando se tiene una arquitectura completa de software, los encargados de la prueba es
un Grupo Independiente de Prueba (GIP), permitiendo que se tenga independencia.
29.1.2. ESTRATEGIA DE PRUEBA DEL SOFTWARE
Los niveles de la estrategia para la prueba del software se pueden ver en el

siguiente gráfico:
130
La prueba se centra en cada módulo individualmente, asegurando que

funcionan adecuadamente como una unidad. La prueba de unidad hace uso de
las técnicas de prueba de caja blanca, ejercitando caminos específicos de la
estructura de control del módulo para asegurar un alcance completo y una
detección máxima de errores.
Se ensamblan o integran los módulos para formar el paquete de software

completo. La prueba de integración se dirige a todos los aspectos asociados con
el doble problema de verificación y de construcción del programa. Durante la
integración, las técnicas que más prevalecen son las de diseño de casos de
prueba de caja negra, aunque se pueden llevar a cabo algunas pruebas de caja
blanca con el fin de asegurar que se cubren los principales caminos de control.
131
Después de que el software se ha integrado (construido), se dirigen un conjunto

de pruebas de alto nivel. Se deben comprobar los criterios de validación. La
prueba de validación proporciona una seguridad final de que el software
satisface todos los requisitos funcionales, de comportamiento y de rendimiento.
Durante la validación se usan exclusivamente técnicas de prueba de caja negra.
La prueba del sistema verifica que cada elemento encaja de forma adecuada y
que se alcanza la funcionalidad y el rendimiento del sistema total.
Si se desea implementar una estrategia de prueba de software con éxito se

debe tener presente:
Especificar los requisitos del producto de manera cuantificable mucho antes de que
comiencen las pruebas
También se debe evaluar: portabilidad, facilidad de mantenimiento y facilidad de uso
Establecer los objetivos de la prueba de manera explícita
Se debe establecer:
• Objetivos específicos de la prueba

• Cobertura de la prueba
• Tiempo medio de fallo
• El coste para encontrar y arreglar errores
• Densidad de fallos remanente o frecuencia de ocurrencia
• Horas de trabajo por prueba
132
Comprender qué usuarios van a manejar el software y desarrollar un perfil para cada
categoría de usuario
Se debe:
• Describir el escenario de interacción para cada clase de usuario
Desarrollar un plan de prueba que haga hincapié en la “prueba de ciclo rápido”

El equipo de ingeniería de software, debe aprender a probar en ciclos rápidos y que se pueda
probar sobre el terreno.
Construir un software “robusto” diseñado para probarse a sí mismo.
El software debe ser capaz de diagnosticar ciertas clases de errores. Además, el diseño debe
incluir pruebas automatizadas y pruebas de regresión.
Usar revisiones técnicas formales efectivas como filtro antes de la prueba
Las revisiones técnicas formales ayudan a reducir el esfuerzo de prueba necesaria para la
producción del software.
Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los
propios casos de prueba.
Permiten descubrir inconsistencias, omisiones y errores claros en el enfoque de la prueba.
Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la
estrategia de prueba.
Permite usar un enfoque estadístico de control del proceso para la prueba del software.
LECCIÓN 30. MANEJO Y DISEÑO DETALLADO DE OBJETOS
133
30.1. DISEÑO DEL SISTEMA
Se define subdivisiones en aplicaciones del sistema y la forma de comunicación

con los sistemas ya existentes con los cuales debe interactuar.
Documentación
134
30.2. DISEÑO DETALLADO DE OBJETOS
Se adecua el análisis a las características específicas del ambiente de

implementación y se completan las distintas aplicaciones del sistema con los
modelos de control, interfaz o comunicaciones.
2 Desarrollar el modelo de interfaz
135
3 Desarrollar los modelos de control, persistencia y comunicaciones
Documentación
ACTIVIDADES COMPLEMENTARIAS
136
EJERCICIO
1. Del sistema de información seleccionado en el capitulo anterior. Continué

con la elaboración del documento identificando y relacionando:
Objetivos y características de la interfaz
Tipos de acciones que posee la interfaz
Características que tiene el diseño del diálogo
Estrategias del diálogo que se utilizan
Diálogos con entrada de datos
Sistemas de ayuda
2. Teniendo en cuenta el ejercicio planteado en el capitulo anterior de

Parqué’s Pizza:
a. Diseñe la interfaz y diseño de diálogo. Teniendo en cuenta:
Objetivos y características de la interfaz que utilizará el sistema
Tipos de acciones que tendrá la interfaz
Características que tendrá el diseño del diálogo
Estrategias del diálogo
Diálogos con entrada de datos

137
Sistemas de ayuda
EJERCICIO
Del sistema de información seleccionado en el capitulo anterior. Continué con

la elaboración del documento identificando y relacionando:
Objetivos y características del diseño base de datos
Modelos de datos
Estructuración de datos
3. Teniendo en cuenta el ejercicio planteado en el capitulo anterior de

Parqué’s Pizza:
Diseñe las características que tendrá los archivos. Teniendo en cuenta:
Objetivos y características del diseño base de datos a utilizar
Modelos de datos
Estructuración de datos
EJERCICIO
Del sistema de información seleccionado en el capitulo anterior. Continué con

la elaboración del documento identificando y relacionando:
138
Características que la empresa y/o el aplicativo tienen implementados para el

aseguramiento de la calidad.
Principios de diseño de software que tiene el sistema
Documentación que posee el sistema
Niveles de aseguramiento de la calidad que se utilizan
Estrategias de prueba que utiliza el sistema
Teniendo en cuenta el ejercicio planteado en el capitulo anterior de Parqué’s

Pizza:
Diseñe las características que tendrá para la comunicación de datos. Teniendo

en cuenta:
Características que la empresa y/o el aplicativo deben implementarse para el

aseguramiento de la calidad.
Principios de diseño de software que debe tener el sistema
Documentación que debe poseer el sistema
Niveles de aseguramiento de la calidad que debe utilizar
Estrategias de prueba que debe utilizar el sistema
Proyecto de Grupo
139
Teniendo en cuenta la misma descripción del ejercicio propuesto en el curso de

Análisis de Sistemas y de los capítulos anteriores:
Determine los requerimientos planteados en la documentación para:
Diseño del sistema
Diagramas de Procesadores
Ejecución, Procesos
versión inicial Mecanismos de
comunicación
Descripción detallada
Diseño detallado
Diagramas de clases y paquetes

Diagramas de interacción con el detalle de las
operaciones más importantes del sistema
Diagramas de estados y/o actividades para las
clases concurrentes o complejas
140
BIBLIOGRAFÍA
Burch-Grudfnitski. (2001). Diseño de sistemas de información. Teoría y

Práctica. México.
J., W. (1996). Análisis y diseño de sistemas de información. Madrid.
James, S. (1992). Análisis y diseño de sistemas de información. México.
K., L. (1992). Administración de los sistemas.
Kendall, K. &. (2005). Análisis y diseño de sistemas.
ELECTRÓNICA
http://www.cpis.es/cpiMenu1.htm
http://www.cpis.es/master.html?http://www.cpis.es/cpiMenu.htm
http://www.uag.mx/66/Pull.htm
http://www1.universia.net/CatalogaXXI/pub/ir.asp?IdURL=42071&IDC=10010&I
DP=ES&IDI=1
http://www.monografias.com/trabajos6/inus/inus.shtml
http://alarcos.inf-cr.uclm.es/doc/bda/doc/trab/T0001_MAMoraga.pdf
http://www.jegsworks.com/Lessons-sp/lesson7/lesson7-2.htm
http://es.geocities.com/yeiko_6/
141
http://ciberhabitat.gob.mx/museo/cerquita/redes/medios/intro.htm
http://ciberhabitat.gob.mx/museo/cerquita/redes/medios/alambre.htm
http://ciberhabitat.gob.mx/museo/cerquita/redes/medios/coaxial.htm
http://ciberhabitat.gob.mx/museo/cerquita/redes/medios/trenzado.htm
http://ciberhabitat.gob.mx/museo/cerquita/redes/medios/f_optica.htm
http://ciberhabitat.gob.mx/museo/cerquita/redes/medios/estructura.htm
http://ciberhabitat.gob.mx/museo/cerquita/redes/medios/aire.htm
http://tecnologias.gio.etsit.upm.es/domotica/medios-de-transmision--
componentes-55.asp
http://www.wilac.net/descargas/documentos/2ri.pdf
ANEXOS
Software Libre para Diseño
Acá un listado de muchos programas para edición, animación, 3D, CAD y más.
EDICIÓN DE IMÁGENES
GIMP - es un programa para manipular imágenes. Es de libre distribución.

Disponible para muchos sistemas operativos y en múltiples lenguajes.
142
Picasa - software libre para organización y edición de fotografías provisto por

Google.
Paint.NET - este programa corre sobre Windows. Podemos agregar efectos y

cuenta con muchas herramientas para la edición de imágenes. Además cuenta
con una gran comunidad online que provee ayuda, tutoriales y plugins.
Magnifier - permite acercase a los detalles de la imagen.
Easy Thumbnails - permite crear thumbnails (pequeñas vistas previa) y también

editar las imágenes.
ImageDiff - permite comparar dos imágenes lado a lado y ver las diferencias
entre éstas. Compara imágenes de diversos formatos: JPG, GIF, BMP y TIF,
PNG.
IrfanView - es un compacto y rápido visor y convertidor de imágenes. Soporta

diversos formatos de imagen.
FastStone Image Viewer - visor de imágenes rápido, estable y de entorno

amigable. Además cumple funciones de convertir y editor. Soporta muchos
formatos (BMP, JPEG, JPEG 2000, GIF, PNG, PCX, TIFF, WMF, ICO y TGA).
ILUSTRACIONES
Inkscape - editor de gráficos vectoriales, con capacidad similar a Illustrator,

Freehand, CorelDraw o Xara X.
143
SmoothDraw NX ofrece utilidades de trazado e impresión con un acabado de

una calidad apreciable. Además ofrece una buena gama de filtros para mejorar
la visualización y aplicarle efectos.
ParticleDraw proporciona a los usuarios un pincel para dibujar partículas en

cualquier lugar de la escena
InsightPoint es una herramienta de creación de gráficos vectoriales e imágenes

complejas que combina a la perfección todas las cualidades para ser tratado
como un potente competidor de los actuales editores de gráficos escalables
vectoriales (SVG).
144

MD 3013092013

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MD 3013092013

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD

ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS

301309 – DISEÑO DE SISTEMAS

MOISÉS DE JESÚS RODRÍGUEZ BOLAÑO

UNIDAD 1. INTRODUCCIÓN AL DISEÑO ................................................. 11

Capítulo 1. VISIóN GENERAL DEL DISEÑO DE SISTEMAS ........................... 13

Lección 1. CONCEPTO DEL DISEÑO ................................................ 14

Lección 2. OBJETIVOS DEL DISEÑO DE SISTEMAS ................................ 15

Lección 3. CARACTERÍSTICAS A DISEÑAR ......................................... 17

Lección 4. NIVELES DEL DISEÑO ................................................... 18

Lección 5. PROCESO DEL DISEÑO GENERAL DE SISTEMAS ...................... 20

Capítulo 2. MANEJO DEL PROCESO DE DISEÑO ..................................... 22

Lección 6. BOSQUEJOS Y PROTOTIPOS ........................................... 23

Lección 7. MESA DE TRABAJO DE LOS DISEÑADORES............................ 27

Lección 8. CARPETA DE DESCRIPCIÓN DEL DISEÑO DEL SISTEMA .............. 28

Lección 9. SEGUIMIENTO DEL PROCESO DE DISEÑO ............................. 29

Lección 10. SELECCIÓN DE HARDWARE Y SOFTWARE ........................... 32

10.1 Determinación de los requerimientos de tamaño y capacidad ....... 32

10.2 Factores financieros ........................................................ 33

10.3 Mantenimiento y soporte ................................................... 34

10.5 Selección de software ...................................................... 34

Capítulo 3. MANEJO DE SISTEMAS DESARROLLADO POR USUARIOS FINALES ... 36

Lección 11. PARTICIPACIÓN DE LOS USUARIOS .................................. 36

Lección 12. RESPONSABILIDAD DE LOS USUARIOS EN EL DISEÑO .............. 37

Lección 13. RESPONSABILIDAD DEL ANALISTA DE SISTEMAS ................... 37

Lección 14. RIESGOS ASOCIADOS CON EL DESARROLLO POR PARTE DE LOS

Lección 15. Recomendaciones prácticas para el inicio del diseño e

ACTIVIDADES COMPLEMENTARIAS .................................................... 41

Unidad 2. DISEÑO DE SISTEMAS ........................................................ 46

Capítulo 4. DISEÑO DE SALIDAS ...................................................... 48

Lección 16. OBJETIVOS, tipos de salida y objetivos del diseño de entrada . 50

16.1 TIPOS DE SALIDA ............................................................. 53

16.1.1. Tabular .................................................................. 54

16.1.2. Gráfica .................................................................. 54

16.2 OBJETIVOS DE DISEÑO DE ENTRADA ...................................... 55

Lección 17. DISEÑO DE SALIDA IMPRESA y DISEÑO DE SALIDA POR PANTALLA

17.1 Métodos para la salida impresa ........................................... 57

17.2 DISEÑO DE SALIDA POR PANTALLA ........................................ 57

17.3 Diseño de Ventanas ......................................................... 60

Lección 18. CAPTURA DE DATOS, DISEÑO DE DOCUMENTOS Y VALIDACIÓN DE

18.1. DISEÑO DE DOCUMENTOS .................................................. 62

18.1.1. Creación de formularios fáciles de contestar ..................... 62

18.1.2. Cumplir el propósito para el cual se diseñan ...................... 64

18.1.3. Garantizar que los formularios se contesten con precisión ..... 65

18.1.4. Hacer formularios atractivos ......................................... 65

18.2. VALIDACIÓN DE ENTRADAS ................................................ 65

18.2.1. Validación de las transacciones de entrada ....................... 66

18.2.2. Validación de datos de entrada ..................................... 67

18.3. Procesos de validación .................................................... 68

Lección 19. DEFINICIÓN DE INTERFACE, diseño de dialogo y estrategias de

19.1. Características de la interface ......................................... 70

19.2. Tipos de acciones en la interface ..................................... 70

19.3. DISEÑO DE DIALOGO ..................................................... 71

19.4. ESTRATEGIA DEL DIALOGO ................................................ 77

Lección 20. DIALOGO CON ENTRADA DE DATOS ................................. 80

20.1. Paginación y scrolling ...................................................... 81

20.2. Sistemas de Ayuda ......................................................... 85

Capítulo 5. DISEÑO DE ARCHIVOS .................................................... 87

Lección 21. DIAGRAMA DE ESTRUCTURAS DE DATOS ........................... 88

Lección 22. TIPOS Y MÉTODOS DE ORGANIZACIÓN DE ARCHIVOS ............. 90