1

ANALISIS BBDD (TOMADO DE http://www.canalvisualbasic.net/db/tema1.asp)

CICLO DE VIDA

1. 1.- METODOLOGÍA DE DESARROLLO DE SISTEMAS DE INFORMACIÓN

Por metodología se entiende "un conjunto integrado de técnicas y método que permite abordar
de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de
desarrollo de un sistema de información"

• Sistema de Información: Es un conjunto de componentes (computadoras, periféricos,

software y usuarios) que trabajan juntos para conseguir un objetivo, transformando
elementos de entrada al sistema en otros elementos de salida (datos).

• Ciclo de Vida: Conjunto de fases implicadas en un proyecto de desarrollo de un sistema

de información, desde su concepción inicial, pasando por su desarrollo, implantación,
funcionamiento y mantenimiento, hasta que el sistema deja de utilizarse o se transforma
en otro.

• Método: Concreción en etapas o pasos precisos, tanto el proceso de desarrollo en

general (ciclo de vida) como cada una de las fases generales en las que se divide éste.

• Técnicas: Mecanismos, procedimientos y recursos de que se sirve la metodología.

La utilización de técnicas de diagramas favorece la comunicación entre el personal de

desarrollo y los usuarios para los que se realiza el sistema. La documentación esquemática
que se establece facilita el mantenimiento del sistema, lo que hace que se consiga mayor
calidad del mismo. Para que todas estas ventajas sean efectivas, es preciso introducir la
metodología gradualmente, diseñando previamente:

• Un plan de formación, que garantice el aprendizaje necesario;

• Un plan de normalización, fijando estándares relativos a nomenclatura, a las técnicas y

a la documentación;

• Un plan de adaptación, mediante la aplicación de la metodología a un proyecto piloto.

El que un sistema deba o no ser informatizado es algo que discutiremos a lo largo del curso.
Como analistas de sistemas supondremos que todo sistema con el que nos encontremos
deberá ser informatizado y, el usuario con quien actuaremos generalmente supondrá tal
predisposición. La labor primaria como analista, será analizar o estudiar el sistema para
determinar su esencia: su comportamiento requerido, independientemente de la tecnología
utilizada para implantar el sistema.

La incapacidad de estimar el tiempo, coste y esfuerzo necesario para el desarrollo de un

producto software y, la falta de calidad del software producido son la causa de la aparición de
la Ingeniería del software como una disciplina científica.
 2

• Década 50-60: Programación Artesanal. Existe una fuerte dependencia del software
sobre el hardware. Se caracteriza por el desarrollo artesanal de los productos software,
ausencia total de planificación y escasa documentación de los mismos.

• Década 60-70: Lenguajes de Alto Nivel. Se produce un aumento en la complejidad de

los sistemas, por lo que surge la necesidad de fiabilidad en los mismos, aunque hay una
carencia de metodología para el desarrollo de aplicaciones. Reducción en el coste de
procesamiento.

• Década 70-80: Ingeniería del software. Se intenta dar una solución a los problemas de
etapas anteriores. Aparece la programación estructurada.

• Década 80-90: Paradigmas. Se produce un volcado de los resultados del álgebra y la

lógica al campo práctico. Desarrollo de las herramientas CASE.

• Década 90: Inteligencia Artificial. Se caracteriza por la aparición de la Programación

Orientada a Objetos.

• Para clasificar el software se parte de la definición de Pressman: "El software se

compone de los siguientes elementos:

• Instrucciones o programas que cuando se ejecutan tienen el comportamiento esperado;

• Estructuras de datos;

• Documentación o parte que explica el uso y manipulación del programa."

La Calidad del software se mide en base a los conceptos de:

• Fiabilidad: Capaz de dar los mismos resultados bajo las mismas condiciones.

• Eficiencia: Utilización óptima de los recursos del sistema.

• Robustez o Tolerancia a Fallos: No poseer comportamiento catastrófico ante situaciones

excepcionales.

• Corrección: Debe ajustarse a las especificaciones dadas por el usuario y sin errores de
diseño y codificación.

• Adaptabilidad: Fácilmente modificables algunas de sus funciones sin afectar al resto.

• Portabilidad: Capacidad de poder integrarse en entornos distintos con un mínimo

esfuerzo.

• Inteligible: Que tenga un diseño claro y fácil, bien documentado y estructurado.

• No erróneo: No debe haber diferencia entre valores reales y calculados.

 3

1. 2.- CICLO DE VIDA

Es el conjunto de fases por las que debe pasar un proyecto desde su concepción inicial, hasta
que el sistema deja de utilizarse o se transforma en otro.

Existen diferentes modelos de ciclo de vida, que pueden aplicarse en función del tipo de
sistema a desarrollar.

CICLO DE VIDA CLÁSICO O EN CASCADA

Este ciclo establece una serie de fases, al finalizar las cuales se obtiene una serie de productos
(documentos, diagramas, programas) que permite evaluar lo realizado hasta ese momento y
continuar con la fase siguiente o modificar algunos aspectos de las fases anteriores.

• Planificación estratégica: Su existencia es opcional. Si existe, su objetivo es adecuar los

objetivos estratégicos de la organización (usuario) y la información necesaria para
soportar dichos objetivos. Se debe determinar si el sistema es factible de informatizar,
incluyendo algunas especificaciones básicas acerca de coste y tiempo necesarios para
construir el sistema, así como los beneficios que se obtengan del nuevo sistema.

• Fase de Análisis: el objetivo de esta fase es el estudio de las necesidades de información

que debe satisfacer el sistema a desarrollar, elaborando una serie de especificaciones
formales que describan la funcionalidad del mismo y que permitan abordar con
garantías la siguiente fase. Se puede estructurar en dos subfases:

• Análisis de Requerimientos del Sistema: se trata de establecer el alcance, los objetivos

y requisitos del sistema, examinando las posibles alternativas que podrían solucionar las
necesidades del usuario y recomendar una de ellas. Al final de esta subfase se obtiene
un documento llamado "Documento de Requisitos del Sistema"

• Especificación Funcional del Sistema: conocida como Análisis Funcional. Una vez
aceptado formalmente el documento anterior por ambas partes (equipo de desarrollo y
usuario), se elabora un conjunto de especificaciones formales que describan la
funcionalidad del sistema, estableciendo los subsistemas en que se descompondrá,
definiendo los datos que utilizará y las interfaces de usuario. También se planificarán
las pruebas que deberá superar el sistema, se estimará la relación coste/beneficio para
comprobar si interesa su construcción y se establecerán los plazos de entrega del
sistema. Todo ello se recoge en dos documentos, denominados "Documento de
Especificación Funcional del Sistema" y "Documento de Pruebas del Sistema"

• Fase de Diseño: conocida como Análisis Orgánico. El objetivo de esta fase es obtener
un conjunto de especificaciones que contemplarán los aspectos físicos del sistema,
considerando las características tecnológicas del entorno específico en el que se
implantará, que constituirá el punto de partida para la construcción del sistema.
Equivale a la creación de una jerarquía apropiada de módulos de programas y de
interfaces entre ellos para implantar la especificación creada en la fase anterior.
Además, se encarga de la transformación de modelos de datos de Entidad-Relación en
 4

un diseño de base de datos. Al final de esta fase se obtienen el "Documento de Diseño

Técnico" y el anterior "Documento de Pruebas del Sistema" con las ampliaciones
relativas a la definición del entorno de pruebas.

• Fase de Construcción: el propósito de esta fase es, a partir de las especificaciones de

diseño, la obtención del sistema completamente construido y probado, listo para ser
implantado en la organización del usuario. También durante esta fase se desarrollará el
conjunto de procedimientos y se llevará a cabo la formación necesaria que permitirá,
tanto al personal del área de usuario final, como al personal del área de explotación o
proceso de datos (si existe), la utilización óptima del sistema. Al final de esta fase se
obtiene el Software correspondiente y, los siguientes documentos: "Documentación
Técnica de Programación", "Manual de usuario", "Manual de Explotación",
"Documento de Pruebas del Sistema" ampliado con los informes de las pruebas
unitarias, de integración y globales.

• Generación de Pruebas Unitarias: Comprobar la validación de cada uno de los módulos.

• Generación de Pruebas de Integración: unión de todos los módulos y prueba de la

unión.

• Fase de Implantación: el objetivo de esta fase es la puesta en servicio del sistema

construido y conseguir su adaptación final por parte de los usuarios del mismo, para lo
cual tratará de hacerse ver a éstos, mediante demostraciones formales (pruebas de
aceptación) que el sistema cumple todos los objetivos y requisitos para los que fue
desarrollado. En esta fase se incluye la ejecución y el mantenimiento del sistema, con lo
que su duración se prolongará hasta que el sistema deje de utilizarse o sea sustituido por
otro.

• Generación de Pruebas de Aceptación: Detección de errores de que el programa no se

ajusta a las especificaciones.

INCONVENIENTES:

1. Desarrollo manual.

2. Las herramientas utilizadas no están integradas ni relacionadas entre sí.

3. Los errores de análisis y diseño son muy caros de eliminar, ya que se encuentran muy
tarde.

4. Se produce efecto bola de nieve: los errores se arrastran a las fases siguientes..

CICLO DE VIDA DE PROTOTIPOS

• Prototipo: primera versión de un producto, construido con poca funcionalidad y poca

fiabilidad. La diferencia entre prototipo y producto final es que el prototipo es
 5

eficiente y el producto final debe serlo y, que en el prototipo no están todos los
detalles y, el producto final debe contenerlos.

Clases de prototipos:

• Vertical: no recoge todas las funciones del sistema final.

• Horizontal: recoge todas las funciones, pero no las desarrolla por completo.

Este ciclo casi siempre supone que el modelo será operante, es decir, una colección de
programas que simularán alguna o todas las funciones que el usuario desea. Pero dado que se
pretende que dichos programas sean solo de modelo, también se supone que al concluirse el
modelado, los programas se descartarán y se reemplazarán con programas reales.
Normalmente se utilizan las siguientes herramientas:

• Un diccionario de datos integrado.

• Un generador de pantallas.

• Un generador de informes no guiado por procedimientos.

• Un lenguaje de programación de cuarta generación.

• Un lenguaje de consultas no guiado por procedimientos.

• Medios poderosos de administración de bases de datos.

VENTAJAS:

1. Se incrementa la productividad del equipo de desarrollo. Se incrementa la calidad del

producto final, ya que el prototipo permite trabajar, ensayar,...

2. disminuyen los costes de mantenimiento del producto final. Los tiempos de desarrollo
son inferiores.

3. El tamaño del sistema es menor.

4. La especificación actúa como interface entre cliente y equipo de desarrollo.

5. El propio prototipo sirve de contrato con el cliente y cualquier cambio en el prototipo

debe estar consolidado por ambas partes.

6. El prototipo es un documento vivo de buen funcionamiento del producto final.

7. Ayuda para determinar requerimientos expresados en el prototipo. Experimenta sobre

los aspectos del sistema que representan mayor complejidad. Demuestran la viabilidad
del sistema.
 6

8. El cliente reacciona mucho mejor ante el prototipo, sobre el que puede experimentar,
que no sobre una especificación escrita.

INCONVENIENTES:

1. Fuerte inversión en un producto que se desechable: Los prototipos se descartan.

2. Tendencia a tratar de convertir el prototipo mismo en el sistema de producción.

3. Aumento del coste.

4. Se arrastran decisiones del diseño de prototipos al producto final.

CICLO DE VIDA DE PROGRAMACIÓN AUTOMÁTICA

El punto de partida es la utilización de un lenguaje formal de especificación, en el que las

especificaciones son directamente ejecutables, o lo que es lo mismo, la especificación es el
prototipo. El programa se obtiene de forma automática a partir de la especificación.

INCONVENIENTES:

1. No se dispone de la tecnología necesaria para aplicarla en su totalidad.

HERRAMIENTAS Y MODELOS

2. 1.- HERRAMIENTAS

Podemos definir las herramientas como el útil que se utiliza para desarrollar un análisis. Se
usan para:

- Concentrarse en las propiedades importantes del sistema,

- Discutir cambios y correcciones de los requerimientos del usuario, a bajo coste y con el
riesgo mínimo.

- Verificar que el analista comprende correctamente el entorno del usuario.

Dan soporte automático o semiautomático a los métodos. Ejemplos de herramientas de

modelado de sistemas importantes son:

- Diagramas Flujo de Datos. Ilustra las funciones que el sistema debe realizar.

- Diagrama Entidad-Relación. Hacen énfasis en las relaciones entre los datos.

- Diagrama de Transición de Estados. Se enfoca al comportamiento dependiente del tiempo

del sistema.
 7

2.2.- MÉTODOS

Indican los pasos a seguir para desarrollar una aplicación (cómo desarrollar todas las tareas
del desarrollo del software). Hay dos tendencias:

Americana (Yourdon, Martin, Gane & Sarson)

Europea: Inglesa - SSADM

Francesa - Merise

Las fases comunes a todas las metodologías son:

- Estudio de viabilidad. Implica hacer estimaciones aproximadas del costo y tiempo

necesarios para construir un sistema nuevo y los beneficios que se derivarán de ello.

- Análisis funcional. Se debe conseguir productos altamente mantenibles, siempre que sea
posible se utilizarán gráficos, se deben tratar los problemas de gran tamaño mediante métodos
de partición,...

- Diseño físico. Asignación de porciones de la especificación a procesadores adecuados, y a

tareas apropiadas dentro de cada procesador. Creación de una jerarquía de módulos de
programas e interfaces entre ellos.

- Puesta en marcha o implantación. Incluyendo la codificación y la integración de los

módulos.

- Explotación y mantenimiento.

2.3.- ANÁLISIS DE SISTEMAS

Se realiza teniendo en cuenta los siguientes objetivos:

1. Identificar las necesidades del cliente.

2. Evaluar la viabilidad del sistema.

3. Realizar un análisis técnico y económico.

4. Asignar funciones al software, al hardware, a la gente, a la base de datos y a otros

elementos del sistema.

5. Establecer restricciones de costo y tiempo.

 8

6. Crear una definición del sistema que sea la base para todo el trabajo posterior de
ingeniería.

Gran parte de la labor que desempeñará el analista involucra el modelado del sistema que
desea el usuario. un Modelo es una representación de una parte de la realidad, como p.e. un
mapa, un globo terráqueo, un diagrama de flujo, etc. Se construyen los modelos para enfatizar
ciertas propiedades críticas del sistema, mientras que simultáneamente se desacentúan otros
aspectos. Esto permite comunicarnos con el usuario de una manera enfocada, sin distraernos
en asuntos y características ajenas al sistema.. se pueden hacer cambios en el modelo o
desecharlo y hacer uno nuevo en caso de ser necesario. Por esta razón, se hace uso de
herramientas de modelado para:

• Concentrarse en las propiedades importantes del sistema y al mismo tiempo restar

importancia a otras menores.

• Discutir cambios y correcciones de los requerimientos de usuario, a bajo coste y riesgo

mínimo.

• Verificar que el analista comprende correctamente el ambiente del usuario y que lo haya
respaldado con información documental para que los diseñadores de sistemas y los
programadores puedan construir el sistema.

ANÁLISIS ESTRUCTURADO

Es una actividad de construcción de modelos. A medida que fluye la información por un

sistema basado en computadora, se transforma. El sistema acepta entradas en una gran
variedad de formas, aplica los elementos de hardware, software y humanos para transformar
la entrada en salida y produce salidas en una gran variedad de formas. El análisis estructurado
es una técnica de modelización del flujo y del contenido de la información. Las herramientas
en las que se apoya el análisis estructurado son:

HERRAMIENTAS DEL ANÁLISIS ESTRUCTURADO

El Diagrama de Flujo de Datos (DFD) es una técnica gráfica que representa el flujo de la
información y las transformaciones que se aplican a los datos al moverse desde la entrada
hasta la salida.

Se puede usar el DFD para representar un sistema o un software a cualquier nivel de

abstracción. Un DFD de nivel 0 o modelo fundamental del sistema o modelo del contexto,
representa al elemento de software completo como una sóla burbuja con datos de entrada y
salida. Al partir el DFD/0 para mostrar más detalles, aparecen representados procesos
(burbujas) y caminos de flujo de información adicionales.

Una entidad externa, es decir, un elemento del sistema u otro sistema, es quien produce la
información a ser transformada por el sistema o recibe información del sistema y que reside
fuera de los límites del sistema a ser modelado. Un círculo representa un proceso o
transformación que se aplica a los datos y los cambia de alguna forma y que reside dentro de
los límites del sistema a modelar. Todas las flechas en un DFD deben estar debidamente
 9

etiquetadas y representan un elemento de datos o una colección de elementos de datos,

indicando la dirección de los datos. Una línea doble representa un almacén de información
que es almacenada y manejada por el sistema, por uno o más procesos.

El diagrama no representa secuencia de procesamiento. Se puede refinar cada una de las

burbujas en distintos niveles para mostrar un mayor detalle, aunque se debe mantener la
continuidad del flujo de información o equilibrio, es decir, que la entrada y salida de cada
refinamiento debe ser la misma.

Un DFD representa el flujo de la información sin representación explícita de la lógica de

procesamiento. La notación básica que se utiliza para desarrollar un DFD no es suficiente en
sí misma para describir los requerimientos del sistema, ya que no se dice nada acerca del
contenido de los datos implicados en las flechas o en los almacenes de datos. Para ello, es
necesario otro componente del análisis estructurado: el Diccionario de Datos, que representa
qué información se transforma. Se necesita, además, una narrativa para describir cada proceso
o burbuja del DFD. Esta Especificación de Proceso describe la entrada del proceso, el
algoritmo que se aplica a la entrada y, la salida que produce, además de indicar las
restricciones y limitaciones impuestas al proceso, etc. Y describe cómo se transforma las
información.

Muchas aplicaciones de software son dependientes del tiempo y procesan más información
orientada al control que a datos. Un sistema en tiempo real debe interactuar con el mundo real
en marcos temporales que vienen dados por el mundo real. Como el DFD no es capaz de
representar estos sistemas, se necesita una ampliación del análisis estructurado para adaptarse
a las necesidades de estos sistemas:

• Flujo de información que es recogido o producido de forma continua en el tiempo,

representado por una flecha con doble punta.

• Información de control que pasa por el sistema y el procesamiento de control asociado,

representados por una flecha discontinua y una burbuja de trazo discontinuo.

• Instancias múltiples de la misma transformación que se encuentran a menudo en

situaciones de multitarea, representados por una burbuja sombreada.

• Estados del sistema y mecanismos que producen cambios de estado en el sistema.

• Almacenes de información de control representados por una doble línea discontinua.

La modelización del comportamiento es uno de los principios fundamentales de todos los

métodos de análisis de requisitos. El Diagrama de Transición de Estados (DTE) representa el
comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema
cambie de estado. Además, el DTE indica qué acciones se llevan a cabo como consecuencia
de un determinado cambio de estado.

La notación básica para el análisis estructurado va bien cuando la información que fluye a
través de una serie de procesos es relativamente sencilla. Sin embargo, para representar una
 10

serie de relaciones complejas entre colecciones de datos, es necesario incluir un componente

de modelización de datos.

La modelización de datos responde a una serie de preguntas específicas para cualquier

aplicación de procesamiento de datos. ¿Cuáles son los objetos de datos principales que ha de
procesar el sistema? ¿Cuál es la composición de cada objeto de dato y qué atributos describen
ese objeto? ¿Dónde se encuentran en ese momento los objetos? ¿Cuáles son las relaciones
entre los objetos y los procesos que los transforman?

Para responder a estas preguntas se hace uso del Modelo de Entidad - Relación (E-R), que
permite identificar objetos de datos y sus relaciones, usando una notación gráfica. En el
contexto del análisis estructurado, el DER proporciona un entendimiento adicional sobre los
detalles de los almacenes de datos y complementa la información del DD.

Con la utilización de estas herramientas de modelado, el analista es capaz de crear una

jerarquía de módulos (subrutinas o procedimientos) para realizar los requerimientos del
sistema. Una herramienta gráfica para representar esta jerarquía es el Diagrama de
Estructuras, en el que cada rectángulo representa un módulo. Las flechas que conectan los
módulos representan las invocaciones de los módulos. El diagrama representa los parámetros
de entrada que se le dan a cada módulo invocado y, los parámetros de salida devueltos por
cada módulo cuando termina su labor y devuelve el control al que lo llama. No se debe
enseñar al usuario ya que modela un aspecto de la implementación del sistema, no de sus
requerimientos.

Cada modelo gráfico describe un aspecto distinto del sistema: el DFD resalta las funciones del
sistema; el DER resalta las relaciones entre datos; el DTE resalta el comportamiento
dependiente del tiempo del sistema. Estos tres aspectos deben ser consistentes y compatibles
entre sí.

RESUMEN

Las especificaciones funcionales deben ser:

• Gráficas: compuestas por una gran variedad de diagramas, apoyadas con material
textual detallado.

• Particionadas: de tal manera que puedan leerse independientemente porciones

individuales de la especificación.

• Mínimamente redundante: de tal manera que los cambios en los requerimientos del
usuario puedan incorporarse normalmente en sólo una parte de la especificación.

2.4.- HERRAMIENTAS CASE

Debido a las características específicas del ciclo de vida y, sobre todo, debido a la gran
cantidad de información que se debe generar en cada etapa, comienzan a introducirse
herramientas y entornos automatizados de producción, organización, edición y gestión de
 11

dicha información, que facilitan, o en muchos casos posibilitan el uso de metodologías

formales de forma cómoda y eficiente. Por tanto, la tecnología CASE sustituye el papel y el
lápiz por el ordenador para hacer del desarrollo del software un proceso más productivo. El
objetivo fundamental del CASE es proporcionar un conjunto de herramientas que automaticen
los trabajos de desarrollo y mantenimiento del software. Algunas de las facilidades ofrecidas
por este tipo de herramientas son:

• Soporte a la gestión para aumentar el control y la coordinación por parte de la

dirección.

• Diseño de diagramas estructurados y creación de especificaciones gráficas.

• Prototipado de las pantallas de usuario.

• Centralización de la información del sistema en un diccionario en el que se pueden

almacenar, obtener informes y consultar.

• Verificación de la consistencia y la corrección de las especificaciones del sistema.

• Mantenimiento: re-documentación, reestructuración y análisis del sistema diseñado.

• Eliminar errores fácilmente.

Dado que la modelización es una actividad gráfica, se pueden conseguir DFD, DFC, DER y
DTE más eficientemente y conseguir resultados más estéticos con herramientas CASE. A
medida que se refina cada nivel del modelo de flujo, la herramienta CASE construye una
jerarquía interna, de forma que cada burbuja "padre" está asociada con sus burbujas "hijas" y,
éstas con él.

Aunque la gestión del DD está presente en todas las herramientas CASE, la mayoría también
ofrecen otra serie de utilidades como son la normalización de las estructuras de datos, la
generación de las bases de datos a partir de las especificaciones de diseño, la generación de
código fuente a partir de las especificaciones funcionales, la elaboración de prototipos que
permitirán al usuario observar cómo funcionará el sistema una vez implantado, etc. Según la
capacidad de la herramienta CASE, podemos hacer la siguiente clasificación:

• CASE Superior: denominada también Planificación Asistida por Ordenador, se basa en

la utilización de software que permita automatizar las tareas de planificación
empresarial, por ejemplo, lo que concierne a la gestión de proyectos de desarrollo de
Sistemas de Información.

• CASE Intermedia: se refiere a la automatización del análisis y diseño de Sistemas de

Información.

• CASE Inferior: pretende la asistencia del computador en la construcción (programación

o generación de código) de los Sistemas de Información.
 12

LISTA DE EVENTOS

3.1.- FASE DE ANÁLISIS EN EL CICLO DE VIDA

Gran parte de la labor que se desempeña como analista, involucra el modelado del sistema
que desea el usuario. Los modelos que se realizarán en la fase de análisis, son
representaciones abstractas de lo que al final será una combinación de hardware y software de
computadora. Se construyen modelos porque se pueden enfatizar ciertas propiedades críticas
del sistema, mientras que simultáneamente, desacentuamos otros de sus aspectos. Esto nos
permite comunicarnos con el usuario sin distraernos con asuntos y características ajenas al
sistema.

El propósito general de la fase de análisis es descubrir cuáles son las situaciones posibles en
las que se puede encontrar el sistema y, no dar solución a los problemas, es decir, transformar
los requerimientos del sistema en una especificación estructurada. Por tanto, durante esta fase,
seremos capaces de:

• Modelar el mundo real.

• Usar un método riguroso y disciplinado.

• Gestionar lo complejo dividiéndolo en partes menos complejas.

• Dejar el detalle para fases posteriores.

Por tanto, durante la fase de análisis se debe:

• Recoger información del sistema actual. Dicha información puede ser de tipo:
Organizacional en cuento a estructura jerárquica, objetivos etc.; Informacional, que
permitirán detectar la información que se maneja en el sistema y se obtienen
preguntando a los usuarios del sistema; Operacional, respecto a fiabilidad, prestaciones,
etc.

• Desarrollar los modelos lógicos de datos y de procesos.

• Se refinarán ambos modelos con el usuario para llegar al modelo lógico final.

• Se volverá a validar con el usuario.

El primer lugar debe realizarse un estudio de las necesidades de información que debe
satisfacer el nuevo sistema y, a continuación, elaborar un conjunto de especificaciones
 13

formales que describan la funcionalidad del sistema para su aprobación por parte del usuario y
que permitan abordar con garantías la siguiente fase de diseño.

Cuando en cualquier organización se plantea un problema y se pretende resolver mediante un

Sistema Informático, (ya sea nuevo o modificación de uno existente), es imprescindible
establecer previamente el esfuerzo que será necesario para que el desarrollo del nuevo sistema
llegue a su término. Se debe estudiar el nuevo sistema de forma que se llegue a obtener:

• El ámbito y alcance del proyecto.

• Definición de objetivos y requisitos.

• Diseño del modelo lógico actual.

• Estudio de alternativas de construcción.

Es preciso identificar las áreas a las que afectará el proyecto. Se comenzará por elaborar una
planificación inicial del proyecto, elaborar una composición del equipo de trabajo necesario y,
se obtendrá como resultado un único documento final denominado Documento de requisitos
del sistema.

Para la obtención de información se utilizarán las entrevistas y reuniones con los usuarios, así
como cuestionarios. Para la planificación inicial se utilizarán técnicas habituales de desarrollo
de sistemas, como PERT y CPM.

Las entrevistas permiten obtener datos cuantitativos y cualitativos de una organización a

través del personal de la misma. El objetivo de una entrevista es conseguir respuestas francas
y competas del entrevistado. Para ello, el entrevistador (analista) se enfrenta a un individuo
que reaccionará con recelo, tanto a la personalidad del entrevistador como al asunto del que se
discuta. El tipo de preguntas con el que nos podemos encontrar en una entrevista son:
abiertas, que permiten al entrevistado explayarse en sus opiniones; cerradas, que limitan la
respuesta del entrevistado.

Los cuestionarios son útiles cuando el número de personas a entrevistar es grande, si está
ubicados es áreas geográficas dispersas o para verificar los datos obtenidos por otros métodos
o de otras personas. No son efectivos para búsquedas detalladas ni para identificar problemas
o soluciones a problemas.

3.2.- LISTA DE EVENTOS / ACONTECIMIENTOS

La información sobre el funcionamiento del sistema actual se obtendrá de los responsables de

las áreas de usuario afectadas que aporten una visión global de la misma y de los propios
usuarios para obtener una visión detallada. Para facilitar esta función, se utilizará la Lista de
Eventos, que es una lista narrativa de los estímulos que ocurren en el mundo exterior a lo
cuales el sistema debe responder. Hay 3 tipos de acontecimientos o de eventos:
 14

• Acontecimientos Orientados a Flujos: se asocia a un flujo de datos. Son aquellos en los

que el sistema se da cuenta de que ha ocurrido algo y contesta a ese evento.

• Acontecimientos Temporales: estos eventos arrancan con la llegada de un momento

dado en el tiempo. No se inician con flujos de datos de entrada; se puede imaginar que
el sistema tiene un reloj interno con el cual puede determinar el paso del tiempo.

• Acontecimientos Orientados a Flujos de Control: deben considerarse como un caso

especial de los acontecimientos temporales. A diferencia del un acontecimiento
temporal normal, no se asocia con el paso regular del tiempo, por lo que el sistema no
puede anticiparlo utilizando un reloj interno. Y, a diferencia de un acontecimiento de
flujo normal, el de control no indica su presencia con la llegada de datos. Se asocia con
un flujo de control (o flujo binario). Son bastantes comunes en sistemas de tiempo real.

Al final de este estudio y, para la posterior obtención del modelo de funciones, se debe tener
una idea clara de:

• Las principales entradas y salidas de información y su procedencia, eliminando toda

referencia al entorno físico.

• Identificación de las principales funciones ejecutadas por el sistema.

• Realizar el modelo de funciones para cada subsistema, identificando las subfunciones

que realizan.

El modelo obtenido es una descripción lógica o conceptual del sistema, sin distinguir entre
funciones que se realizarán de forma manual o automatizada.

3.3.- CONSTRUCCIÓN DE LA LISTA DE EVENTOS

La lista de eventos es un listado textual sencillo de los acontecimientos del ambiente a los
cuales debe responder el sistema. Al crear la lista de acontecimientos, se debe asegurar de
distinguir entre un acontecimiento y de describirlos desde el punto de vista de fuera del
sistema, es decir, de fuera hacia adentro.

En la mayor parte de los casos, la mejor manera de identificar los acontecimientos para un
sistema es visualizarlo en acción: examinar cada agente externo y preguntar qué efecto
pueden tener sus acciones sobre el sistema.

MODELO DE PROCESOS

4.1.- DIAGRAMA DE CONTEXTO

 15

Un Diagrama de Contexto (DC) es un caso especial de DFD, en donde un proceso único

representa el sistema externo. Define la frontera o marco del análisis o lo que es lo mismo, las
interfaces del sistema y el resto del universo. Destaca varias características importantes del
sistema:

• Aquellos agentes externos que se comunican con el sistema, que a veces se conocen
como terminadores.

• Los datos que el sistema recibe del exterior y que se deben procesar de alguna forma.

• Los datos producidos por el sistema y que se mandan al mundo exterior.

• La frontera entre el sistema y el resto del mundo.

• Los almacenes de datos que el sistema comparte con los agentes externos. Estos
almacenes se crean fuera del sistema para su uso, o bien son creados en él y usados
fuera.

ELEMENTOS DE UN DIAGRAMA DE CONTEXTO

Los elementos de un DC son los mismos que los de un DFD. Por tanto:

Sistema:

Representado por una burbuja.

Indica una parte del sistema que transforma entradas en salidas. En este caso, representa el
sistema entero. Trabaja sobre los datos. Debe tener un nombre claro, compuesto por un verbo
de acción más un sustantivo, p.e. emitir factura.

Entidad / Agente Externo

Define la frontera del sistema. Son los emisores y/o receptores de los flujos de información.
Deben tener un nombre claro. Aparecen exclusivamente en el nivel 0 o DC. No se puede
cambiar el contenido de una entidad externa. Cualquier relación entre entidades externas no
debe aparecer en el diagrama. Son el interface con el mundo exterior.

Flujo de Datos
 16

Representa los datos del sistema. Es una flecha que indica el movimiento de los datos. Define
origen, dirección y destino de los datos. Une al emisor y al receptor de los datos. Conecta al
resto de los componentes del DFD. Se puede bifurcar o converger. Deben ser claros, concisos
y fácil de definir. Se debe evitar flujos diferentes con el mismo nombre.

4.2.- CONSTRUCCIÓN DEL DIAGRAMA DE CONTEXTO

El DC consiste en agentes externos, flujos de datos, almacenes de datos y un solo proceso que
representa a todo el sistema. Estudiemos cada uno de ellos por separado:

Proceso: es la parte más fácil del DC. El nombre dentro del proceso suele ser el nombre del
sistema completo.

Agentes Externos: se comunican directamente con el sistema a través de flujos de datos o de

control (o a través de almacenes externos). No se comunican entre sí. Se deben seguir unas
pautas:

1. Algunos agentes externos tienen un buen número de entradas y salidas, por lo que
conviene dibujarlos más de una vez.

2. Cuando el agente externo es una persona individual, es preferible indicar el rol que
desempeña más que su identidad.

3. Mostrar la verdadera fuente de datos en lugar del manejador como agente externo. Un
manejador es un mecanismo, dispositivo o medio físico utilizado para transportar datos
hacia dentro o fuera del sistema.

Flujos de datos: los que aparecen en el DC modelan datos de entrada y salida al sistema,
además de las señales de control que recibe o genera. Se incluyen en el DC si sirven para
detectar un acontecimiento externo al que debe responder el sistema, o si sirven para
representar una respuesta. También se muestran si el sistema produce datos para responder a
un acontecimiento.

El DC debe dibujarse bajo el concepto de que las entradas son causadas e iniciadas por los
agentes externos y, que las salidas son causadas e iniciadas por el sistema. Por tanto, se
modela sólo el flujo neto de los datos.

Una vez se ha obtenido la lista de eventos y el DC, deben revisarse para comprobar que son
consistentes, es decir, se debe confirmar:

• El sistema necesita cada flujo de entrada del DC para reconocer que ha ocurrido un
acontecimiento; debe necesitarlo para producir una respuesta a un acontecimiento, o
ambas cosas.
 17

• Cada flujo de salida debe ser respuesta a un acontecimiento.

• Cada acontecimiento no temporal de la lista de acontecimientos debe tener entradas a

partir de las cuales el sistema pueda detectarlo.

• Cada acontecimiento debe producir salidas inmediatas como respuesta o bien almacenar
los datos que luego serán salidas, o debiera ocasionar un cambio en el estado del
sistema (DTE)

RESUMEN

Con la lista de eventos y el DC se obtiene el modelo ambiental, que es lo primero y más

importante en la construcción de un modelo completo de los requerimientos de usuario para
un nuevo sistema. Una vez obtenido el modelo ambiental, debe ser revisado cuidadosamente
para comenzar a construir el modelo del comportamiento, es decir, el modelo del interior del
sistema. Esto incluye el desarrollo de un DFD y un DER preliminares, además de las entradas
iniciales al DD. Básicamente este enfoque implica dibujar un borrador de DFD, con un
proceso o burbuja para la respuesta del sistema ante cada uno de los acontecimientos que se
identificó en la lista de eventos, dibujar almacenes de datos que deben recordarse entre
acontecimientos no sincronizados y, la conexión entre los elementos del borrador. Finalmente,
se compara el DFD con el DC para asegurar la consistencia.

TRANSACION DE ESTADOS

5.1.- DIAGRAMA DE FLUJO DE DATOS

Un Diagrama Flujo de Datos es una representación estructurada y gráfica que describe cómo
circula la información a través de un sistema y los diferentes procesos de transformación a los
que se ve sometida. Permite visualizar un sistema como una red de procesos funcionales,
conectados entre mediante flujos de datos. Es una de las herramientas más usadas en sistemas
computacionales en los que las funciones del sistema son de gran importancia y son más
complejas que los datos que éste maneja.

Es un modelo lógico (no físico) que representa qué hace el sistema y no cómo. Es
comprensible por el usuario. Muestra cualquier nivel de detalle y, el flujo de la información
asociada. Sirve para identificar y dar nombre a las fuentes de datos, destinos de los datos,
flujos de datos, almacenes de datos y, procesos.

El DFD se desarrolla con un enfoque descendente y está sujeto a una notación y a unas reglas
predefinidas que buscan producir un documento conciso y autoorganizado. El DFD se
compone de Entidades Externas, flujos de datos, funciones o procesos y almacenes de datos.

5.2.- ELEMENTOS DE UN DIAGRAMA DE FLUJO DE DATOS

 18

En un DFD se utilizan símbolos gráficos para representar procesos, entidades externas, flujos
de datos y almacenes de datos. Veamos cada uno de estos componentes:

PROCESO

Muestra una parte del sistema que transforma entradas en salidas, es decir, muestra cómo es
que una o más entradas se transforman en salidas. Actividad definida y predecible que
transforma flujos de datos con el fin de conseguir un cierto objetivo. Se representa
gráficamente por un círculo. El proceso se nombre o describe con una sola palabra, frase u
oración sencilla, que describirá lo que hace el proceso.

FLUJO

Información que circula de un objeto del diagrama a otro. Puede representar un dato
elemental o una estructura de datos. Se representa gráficamente por una flecha que entra o
sale de un proceso. Se usa para describir el movimiento de bloques de información de una
parte a otra del sistema, por lo que representan datos en movimiento. El nombre del flujo de
datos describe el tipo de información que se transporta.

ALMACÉN DE DATOS

Conjunto de datos siempre disponible donde los datos quedan retenidos. Se utiliza para
modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas. El
nombre que se utiliza para denotar al almacén es el plural del que se utiliza para los datos que
almacena. La información almacenada está en reposo. Es independiente de la implementación
física.

Los flujos que van hacia el almacén se interpretan como una escritura, una actualización o una
eliminación de información del almacén. Los flujos que salen del almacén se interpretan
como una lectura o un acceso a la información del almacén.

AGENTE EXTERNO

Se representa gráficamente por un rectángulo y representa las entidades externas con las que
el sistema se comunica. Existen tres cosas importantes acerca de los agentes externos:

• Son externos al sistema que se está modelando; los flujos que los conectan a los
distintos procesos representan la interfaz entre él y el mundo exterior.

• No es posible cambiar el contenido del agente externo, ya que está fuera del dominio
del cambio.

• Las relaciones existentes entre los agentes externos, no se muestran en el DFD.

• No es relevante ni como obtiene la información ni qué hace con ella.

 19

5.3.- EXPLOSIONES DE UN DIAGRAMA DE FLUJO DE DATOS

La técnica del DFD se basa en el principio de descomposición de la funcionalidad de un

sistema en sucesivos niveles de refinamiento (enfoque top-down) cuyo objetivo es permitir
una lectura de la especificación del sistema desde lo abstracto al detalle, permitiendo ver el
sistema de forma global (niveles superiores), o de forma detallada (niveles inferiores). Se
organiza así el DFD global en una serie de niveles de modo que cada uno proporcione
sucesivamente más detalles sobre una porción del nivel anterior. Así se parte de un diagrama
general o Diagrama de Contexto en el que se representa una sola función con el nombre del
sistema, las entidades externas que se relacionan con el sistema y, los flujos de entrada y
salida al sistema. El siguiente nivel conocido como DFD/0 representa la vista de más alto
nivel de las principales funciones del sistema, al igual que sus principales interfaces. Y así
sucesivamente. La descomposición de cada subsistema no se detiene en un nivel determinado,
sino que dependen del grado de complejidad del sistema. Normalmente se suele recomendar
no utilizar más de 4 niveles y que en cada nivel no aparezcan más de 9 funciones.

Veamos algunos aspectos de cada nivel:

• Diagrama de Contexto (Nivel inicial). El objetivo de este diagrama es la delimitación

del dominio del sistema que se está estudiando. Formado por una única función, que
representa al sistema completo y, el contexto del mismo.

• Diagrama nivel 0 (DFD/0). En este diagrama se especifican las funciones más

importantes del sistema, cada una de las cuales será llevada por una parte del sistema.
Podemos encontrarnos dos posibilidades: que sea igual al DC o, que esté formado por
las funciones o áreas más importantes del sistema.

• Diagrama nivel 1 (DFD/1). Es un modelo de trabajo con toda la funcionalidad del

sistema. No muestra errores ni excepciones. Está formado por tantos procesos como
eventos o acontecimientos se hallan detectado en la lista de eventos.

• Diagramas de niveles intermedios. Corresponden a los DFD en los que se explotan o

descomponen cada uno de los subsistemas.

• Diagramas de último nivel. Son aquellos en los que las funciones que aparecen no se
van a descomponer en subfunciones. Tales funciones no se pueden descomponer en otro
DFD pero si en un documento denominado "Especificación de Función Elemental" en
el que se describe textualmente lo que debe hacer la función, pero no cómo debe
hacerlo (que corresponde a la fase de diseño).

Debemos saber algunos cosas sobre la descomposición en niveles:

1. ¿Cómo saber cuántos niveles debe haber en un DFD? Cada DFD no debería tener más
de 6 burbujas y almacenes relacionados. Si no es posible escribir una especificación de
una función en una página, entonces es probable que sea demasiado complejo y debe
descomponerse en un DFD de nivel inferior.
 20

2. ¿Existen reglas acerca del número de niveles que debe obtenerse? No, dependerá de la
complejidad del sistema.

3. ¿Deben partirse todas las partes del sistema con el mismo nivel de detalle? No, algunas
partes del sistema pueden ser más complejas que otras y pueden requerir uno o más
niveles de descomposición.

4. ¿Cómo asegurar que los niveles del DFD son consistentes entre sí? Para asegurarse que
un DFD es consistente con su DFD de nivel superior, los flujos de datos que entran y
salen de una burbuja en un nivel dado, deben corresponder con los que entran y salen
del nivel inmediato inferior que lo describe.

5. ¿Cómo se muestran los almacenes en los distintos niveles? Se debe mostrar un almacén
en el nivel más alto donde primeramente sirva de interfaz entre dos o más procesos;
luego, mostrarlo de nuevo en cada diagrama de nivel inferior que describa más a fondo
dichos procesos.

5.4.- GUÍA PARA CONSTRUIR UN DIAGRAMA DE FLUJO DE DATOS

Veamos algunas recomendaciones para la construcción de un DFD:

1. Identificar las entidades externas al sistema y, sus flujos de entrada y salida. Es decir,
establecer el contexto del sistema.

2. Elegir nombres adecuados para todos los objetos del diagrama, evitando términos
demasiado generales o ambiguos.

3. Ignorar la inicialización y terminación del sistema. Un DFD no representa el flujo de

ejecución de un sistema, sino los datos que maneja, por lo que se puede suponer que el
sistema ya está en funcionamiento y que nunca termina.

4. Ignorar el flujo de control. Los flujos de datos válidos son aquellos que son recibidos
por una función que los modifica y los vuelve a generar como flujo de salida o como
parte de un flujo de salida.

5. Evitar los DFD demasiado complejos, con demasiados flujos, procesos, almacenes y
agentes externos.

6. Omitir tratamiento de errores.

7. Refinar los DFD constantemente. El diseño de un DFD es un proceso iterativo, por lo

que habrá que hacer revisiones y modificaciones periódicas hasta obtener la versión
definitiva. Es importante dedicar tiempo a esta labor ya que los posibles errores
introducidos en un DFD será errores de análisis que se arrastrarán a lo largo de las
siguientes fases del ciclo de vida del sistema.

8. Asegurase de que el DFD sea lógicamente consistente, evitando sumideros infinitos

(procesos que solo tienen entradas pero no salidas), burbujas de generación espontánea
 21

(tienen salida sin tener entradas), flujos no etiquetados, almacenes de solo lectura o solo
escritura.

5.5.- EL DICCIONARIO DE DATOS

El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema, con
definiciones precisas y rigurosas para que tanto el analista como el usuario tengan un
entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos
intermedios. Sirve como descripción lógica del sistema y documenta: todos los flujos
incluidos en el DFD, todos los almacenes de datos, la actividad de los procesos, las entidades
externas. El diccionario de datos define los datos haciendo:

• Describe un significado de los flujos y almacenes que se muestran en los DFD.

• Describe la composición de agregados de paquetes de datos que se mueven a lo largo de

los flujos.

• Describen la composición de los paquetes de datos en los almacenes.

• Especifica los valores y unidades relevantes de piezas elementales de información en

los flujos de datos y en los almacenes de datos.

• Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama
de entidad-relación.

Para comprobar que un DD es correcto se deberá comprobar si todos los flujos del DFD se
han definido en el diccionario, si se han definido todos los componentes de los datos, si se ha
definido un dato más de una vez y, si se ha utilizado la notación correcta.

NOTACIÓN DEL DICCIONARIO DE DATOS

SÍMBOLO DESCRIPCIÓN
= está compuesto por
+ y
() optativo (puede estar presente o ausente)
{} iteración
[] seleccionar una de varias alternativas
** comentario
@ identificador (campo clave) para un almacén
| separa opciones alternativas en la construcción

DEFINICIONES

La definición de un dato se introduce con el símbolo "=", que se lee: "se define como", "se
compone de", "significa". Para definir por completo un dato, nuestra definición debe incluir:
 22

la composición del dato, si se compone de partes elementales con significado; los valores que
puede tomar el dato, si es un dato elemental que no puede descomponerse más.

ELEMENTOS DE DATOS BÁSICOS

Las partes elementales de los datos son aquellas para las cuales ya no existe una
descomposición con significado dentro del contexto del ambiente de usuario. Cuando se han
identificado todos los datos elementales, deben introducirse en el DD con una breve narrativa
describiendo su significado en el contexto del usuario.

DATOS OPCIONALES

Un dato opcional es que puede estar o no presente en un dato compuesto. Van encerrados
entre paréntesis y deben verificarse con el usuario.

ITERACIÓN

La notación de iteración se utiliza para indicar la ocurrencia repetida de un componente de un

dato. Se lee como "cero o más ocurrencias de".

SELECCIÓN

La notación de selección indica que un dato consiste en exactamente un elemento de entre un

conjunto de opciones alternativas. Las opciones se encierran entre corchetes y, se separan con
una barra vertical. Es importante revisar las opciones de selección con el usuario para cubrir
todas las posibilidades.

ALIAS

Un alias es una alternativa de nombre para un dato. Se incluye en el DD y se relaciona con el

nombre primario u oficial del dato. Por ejemplo:

comprador = *alias de cliente*

Comprador no muestra su composición ya que estos detalles aparecen en el nombre primario

y así se evita la redundancia en el modelo. Debe evitarse el uso de alias en la medida de lo
posible.

5.6.- LA ESPECIFICACIÓN DE PROCESOS

Cuando un proceso puede describirse en un espacio razonable, ya no es necesario

descomponerlo en otros subprocesos. Se dice entonces que se trata de un proceso primitivo o
elemental, al que se debe asociar una especificación de proceso. La Especificación del
Proceso es la descripción de qué es lo que sucede en cada burbuja primitiva de nivel más bajo
en un DFD. Debe expresarse de una manera que pueda verificar tanto el usuario como el
analista y de forma que pueda ser comunicada efectivamente al público amplio que esté
 23

involucrado. Una buena herramienta de especificación de proceso no debe imponer o aplicar

decisiones de diseño e implementación arbitrarias.

Existen varias formas de describir la lógica de un proceso:

• Mediante un Texto Narrativo. Se debe evitar esta opción porque puede producir frases
oscuras(no obstante, sin embargo, etc.), rangos indefinidos ("hasta un 20 con descuento,
más de 20 al 50%" ¿y con 20?), frases con y/o ("los clientes que nos compran más de 1
millón al año y tienen una buena historia de pagos o que han tenido tratos con nosotros
por más de 20 años..."), adjetivos indefinidos ("buena historia de pagos").

• Mediante Lenguaje Natural Estructurado. Se trata de limitar el lenguaje natural

obligando a la utilización de un vocabulario limitado: verbos infinitivos precisos
(sumar, calcular,...), términos definidos en el DD, palabras reservadas para la
formulación lógica (Repetir, Si...) y una sintaxis limitada a base de constructores
predefinidos (Hacer Mientras, Repetir Hasta,...). esta técnica también se conoce como
seudocódigo.

• Mediante Árboles de Decisión. Pueden resultar no válidos en situaciones complejas con

gran número de condiciones e implicaciones, ya que no aseguran que se hayan
considerado todas las opciones.

• Mediante Tablas de Decisión. Son más precisas dado que permiten reflejar todas las
situaciones posibles, pero son más difíciles de entender por el usuario. Se crea listando
todas las variables (lógicas) relevantes y todas las acciones relevantes a su lado
izquierdo. A continuación, se lista en columnas separadas cada combinación posible de
valores de las variables; cada columna se conoce como regla y describe una acción que
debe llevarse a cabo para una combinación específica de valores de las variables.

1 2 3 4 5 6 7 8
Edad>21 S S S S N N N N
Sexo M M V V M M V V
Peso>100 S N S N S N S N
Medicamento 1 X X X
Medicamento 2 X X
Medicamento 3 X X X
Ningún medicamento X X

Si existen N variables con valores binarios entonces existirán 2N reglas distintas.

• Mediante Diagramas de Flujo. Muestra una lógica secuencial y de tipo

procedimiento. Muy pocos analistas utilizan este método.

5.8.- VALIDACIONES A REALIZAR EN UN DIAGRAMA DE FLUJO DE DATOS

 24

Los DFD se pueden verificar utilizando tres tipos de pruebas: de exactitud, de comprensión y
de cohesión.

PRUEBAS DE EXACTITUD

Se trata de comprobar que el DFD refleja lo que realmente hace o debe hacer el sistema
modelado. Este tipo de pruebas implica varios aspectos:

• Mantenimiento: se trata de comprobar que no haya flujos de datos sin nombre o con
nombre ambiguo, que cada flujo está definido en el DD, de detectar y eliminar todos
los flujos falsos y, por último, de comprobar que los nombres de las funciones son
correctos.

• Errores de consistencia: se trata de comprobar que el DFD no sea autocontradictorio

ni tenga funciones redundantes.

• Conservación de datos: hay que comprobar que todas las funciones cumplen la regla
de conservación de datos: "una función debe ser capaz de construir sus salidas
usando solamente la información suministrada por los flujos de entrada más los datos
constantes (internos en la función)".

• Problemas de almacenes: comprobación de que no existan almacenes de datos de

solo lectura o solo escritura.

• Errores conceptuales: conviene revisar el DFD con el usuario para comprobar si se

ha entendido correctamente sus especificaciones.

PRUEBAS DE COMPRENSIÓN

Puede que un DFD sea muy difícil de leer y comprender. Para obtener un DFD legible se
recomienda someterlo a varias pruebas:

* Complejidad de la interfaz: comprobar que no es excesivo el número de flujos que

entran y salen de un proceso y que se entienden sus nombres.

* Nombres de los procesos: hay que evitar nombres ambiguos. Se deben usar nombres
con verbos de acción fuerte y acoplarlo con un objeto explícito simple.

* Descomposición desigual: se trata de descomponer los procesos de la forma más

igualada posible. Será desigual si en un mismo nivel existen procesos primitivos junto a
otros que necesitan ser descompuestos en varios niveles más.

PRUEBAS DE COHESIÓN

Se trata de obtener una versión mejorada del DFD. Comprobar que no existen redundancias,
que no falten procesos y que sean totalmente coherentes.
 25

BALANCEO DE MODELOS

6.1.- INTRODUCCIÓN AL MODELO DE DATOS

El modelado de datos es el proceso de ordenar los datos y sus relaciones con el fin de
desarrollar el modelo lógico de la base de datos. Los objetivos que se pretenden so: conseguir
estructuras de datos flexibles, estables y normalizadas y, separar procesos de los datos.

La modelización de los datos procesados por un Sistema de información se realiza en

diferentes niveles consecutivos de abstracción:

• Nivel Conceptual: a este nivel se realiza una formalización de los datos almacenados en
el sistema (los de los almacenes del DFD) mediante una descripción de las entidades
(objetos materiales o inmateriales del sistema), los atributos (propiedades) de estas
entidades y las posibles relaciones entre ellas. Este modelo se realiza durante la fase de
análisis del sistema.

• Nivel Lógico: mientras que el modelo conceptual es independiente del tipo de software
de gestión de información, en el nivel lógico se realiza la adaptación de aquel modelo
(ya validado) al tipo de Sistema de Gestión de Base de Datos (relacional, jerárquico o
en red) que se vaya a utilizar. Al final se obtiene un modelo lógico de registros que
representa la estructura de los datos (a nivel de registros lógicos) en dicho sistema. Este
modelo se realiza durante la fase de diseño del sistema, se suele completar con
información adicional sobre el volumen de los datos y la forma de acceso a los mismos.

• Nivel Físico: a este nivel se debe determinar cómo se organiza físicamente el

almacenamiento de los datos en ficheros. Todos estos detalles se pueden ignorar, ya que
son competencia del Sistema de Gestión de Base de Datos que se utilice.

Con la modelización de los datos, además de especificar las características de la información,

se pretende conseguir la simplificación de las estructuras definidas en el DD del proyecto,
buscando y eliminando los elementos de datos (campos de registro) redundantes, para lo cual
se produce una reorganización de estas estructuras para eliminar repeticiones, proceso que se
conoce con el nombre de normalización.

6.2.- MODELO CONCEPTUAL DE DATOS

Es una representación abstracta de los datos utilizados por un sistema. Este modelo tiene un
alto nivel de independencia, ya que:

• no presupone ninguna hipótesis sobre la utilización que se hace de ellos;

• no tiene en cuenta la localización de los datos en los distintos soportes;

 26

• traduce las elecciones u opciones de gestión fundamentales, en términos de objetos y

relaciones;

• no hay razón para que se modifique su diseño, a menos que se produzca un cambio
radical de los requisitos del sistema.

Se representa mediante el Diagrama de Entidad-Relación (DER)

DEFINICIONES PREVIAS

Entidad o Individuo: es un objeto abstracto o concreto del sistema, con existencia propia y
fácilmente identificable. Es una clase de objetos sobre los que se quiere guardar información.
Puede ser de tres tipos:

Fundamental: Cuando es de interés por sí misma, independiente de cualquier relación.

Atributiva: Cuando sirve para completar la descripción de otro tipo de entidad.

Asociativa: Su razón de existir es relacionar otras entidades.

Cada miembro de la entidad puede identificarse de manera única por algún medio. El sistema
no puede operar sin tener acceso a estos miembros. Cada uno de los miembros puede
describirse con uno o más datos.

Atributo o Propiedad: es el mínimo elemento lógico de información que se puede encontrar

en una entidad o asociación de entidades. El Atributo Clave de una entidad es aquel que puede
ser utilizado para identificar cada ocurrencia de la entidad.

Relación: es una asociación entre entidades, cuya existencia está condicionada por las
entidades que relaciona. Tiene asociada una dimensión o número de entidades que relaciona,
pudiendo ser 1, 2, .... Para una relación binaria entre A y B, pueden darse de tres casos:

• uno a uno (1-1): en la cual una ocurrencia de A no está en relación más que con una
ocurrencia de B y, cada ocurrencia de B no está en relación más que con una ocurrencia
de A.

• uno a muchos (1-n): en la cual una ocurrencia de A está en relación con una o muchas
ocurrencias de B y, cada ocurrencia de B no está en relación más que con una
ocurrencia de A.

• muchos a muchos (n-n): en la cual una ocurrencia de A está en relación con una o
muchas ocurrencias de B y, cada ocurrencia de B está en relación con una o muchas
ocurrencia de A.

La relación representa la memoria del sistema, ya que representa algo que debe ser recordado
por el sistema. No se muestran las relaciones que se pueden calcular o derivar.
 27

La cardinalidad es el número de objetos que participan en la relación. Es el número de

ocurrencias de cada tipo de entidad que intervienen o pueden intervenir en una relación.

La cardinalidad mínima es el número mínimo de veces que una ocurrencia de una entidad está
implicada en una ocurrencia de la relación. El valor 0 indica que no participa en la relación o
lo que es lo mismo, que una ocurrencia de una entidad puede existir sin estar implicada en
ninguna ocurrencia de la relación. El valor 1 que participa una sola ocurrencia o lo que es lo
mismo, que no puede existir sin estar implicada en una o más ocurrencia de la relación.

La cardinalidad máxima es el número máximo de veces que una ocurrencia de una entidad
está implicada en una ocurrencia de la relación. El valor 1 indica que participa en la relación
con una sola ocurrencia, o lo que es lo mismo, que no puede estar implicada más que en un
máximo de una ocurrencia de la relación. El valor n que participa con muchas ocurrencias o
lo que es lo mismo, que puede estar implicada en n ocurrencias de la relación.

6.3.- DIAGRAMA ENTIDAD-RELACIÓN

El modelo conceptual de datos se representa gráficamente mediante el Diagrama Entidad-

Relación, en el que aparecen los elementos descritos en el apartado anterior. Los símbolos
utilizados por este diagrama son:

• Un rectángulo para representar una entidad, en cuyo interior se especifica un nombre.

• Un rombo para una relación, en cuyo interior se especifica el nombre de la relación.

• Círculos para los atributos identificadores y los atributos normales de las entidades y
relaciones.

ENTIDADES ASOCIATIVAS

Una Entidad Asociativa es algo que funciona como objeto y como relación. Una manera de
ver esto es considerar que el tipo asociativo representa una relación acerca de la cual se desea
mantener alguna información.

CLIENTE ARTICULO

Compras

Supongamos que existen datos que se quieren conservar acerca de cada instancia de una
compra, p.e. a qué hora se hizo. ¿Dónde se puede almacenar dicha información? "Hora del
día" no es un atributo de Cliente, ni de Artículo. Más bien se asocia con la compra misma.

CLIENTE ARTICULO
 28

COMPRA

Compra se describe ahora dentro de un círculo conectada, por medio de líneas dirigidas a un
rombo de relación sin nombre, lo que indica que Compra funciona ahora como un tipo de
objeto acerca del cual se desea almacenar información y una relación que conecta dos
entidades Cliente y Artículo.

Podemos pensar que una entidad asociativa es que la relación que tiene atributos.

SUBTIPO Y SUPERTIPO

Las entidades Subtipo y Supertipo consisten en tipos de objeto de una o más categorías,
conectados por una relación. El Supertipo se describe por datos que se aplican a todos los
subtipos. Sin embargo, cada subtipo se describe por medio de datos diferentes.

Por ejemplo, Empleado y las subcategorías Empleado Asalariado y Empleado Por Horas
relacionadas a través del atributo Tipo. Este atributo es denominado Atributo Común
Particionante y es el que permite fraccionar el conjunto de Empleados en los dos tipos. Las
entidades subtipo son mutuamente excluyentes, o lo que es lo mismo, denotan conjuntos
disjuntos.

RESTRICCIÓN DE EXISTENCIA Y DE IDENTIFICACIÓN

Se dice que una entidad E1, tiene una Restricción de Existencia respecto de la relación R,
cuando toda ocurrencia de E1 debe estar asociada a una ocurrencia de R.

Se dice que una entidad E1, tiene una Restricción de Identificación respecto de la relación R,
cuando las ocurrencias de E1 no pueden ser identificadas por sus propios atributos, siendo
identificadas a través de su pertenencia a la relación R.

CLASES DERIVADAS Y AGREGACIÓN

Una entidad E1, tiene una Clase Derivada de entidades E si cada ocurrencia de E1 lo es
también de E. En este caso, las clases derivadas forman un conjunto no disjunto.

En la Agregación se forman objetos compuestos partiendo de otros objetos simples y,

estableciendo relaciones con estos objetos compuestos.

6.4.- PASOS PARA LA CONSTRUCCIÓN DEL DIAGRAMA ENTIDAD-RELACIÓN

 29

Veamos los pasos necesarios para la elaboración del modelo conceptual de datos o DER.

IDENTIFICAR LA LISTA DE DATOS

Se enumeran todos los datos del campo de estudio que afectan al sistema. A continuación se
debe depurar la lista de datos, eliminando los sinónimos o datos que, con diferente semántica
expresan el mismo concepto. De esta lista de datos se deben detectar las entidades y las
relaciones entre ellas.

CLASIFICAR LOS ATRIBUTOS

La forma de desarrollar esta clasificación es la siguiente:

• Se buscan los atributos de la lista que puedan ser identificadores (claves) de una
entidad.

• Se describen las entidades, asignando atributos a cada una de ellas, además del
identificador clave previamente asignado.

• El resto de los atributos que quede en la lista y que no se han asignado a ninguna
entidad, pertenecerán a las relaciones.

Si durante esta fase se descubre que algunos datos no pueden aplicarse a todas las instancias
de algún tipo de objeto dado (entidad), se necesitará crear una entidad Subtipo/Supertipo.

Si se tiene un tipo de objeto que solo tiene un atributo asignado, existe la oportunidad de
eliminar el tipo de objeto y asociar el identificador como dato a una entidad relacionada. Esto
solo tiene sentida si la relación que las conecta es de tipo 1:1.

CONTROLAR LA COHERENCIA Y ELIMINAR REDUNDANCIAS

Una vez realizado el primer modelo de datos, se comprueba que cada entidad es determinada
sin ambigüedad por su clave y que todas las entidades asociadas a cada relación son
necesarias para definir cada atributo de la relación. También se procede a eliminar
redundancias mediante la normalización.

6.5.- EXTENSIONES AL DICCIONARIO DE DATOS

En general, las entidades del DER corresponden con almacenes del DFD, por lo que la
definición en el DD servirá tanto para el almacén como para la entidad. En el DD se tendrá
que incluir una definición de cada relación que aparezca en el DER, indicando su significado
en el contexto de la aplicación.

6.6.- MODELO LÓGICO DE DATOS

 30

El Modelo Conceptual de Datos es independiente del software de gestión de bases de datos

utilizado. Para proceder al diseño de los ficheros y de las bases de datos del sistema, se debe
convertir previamente el modelo conceptual que incluía tipos de entidades y relaciones con
atributos asociados, en un modelo lógico que únicamente considere tipos de registros
compuestos por campos de datos. Al Modelo Lógico de Datos normalmente se le suele llamar
Diagrama de Estructura de Datos (DED) o Diagrama de Bachman.

Existen tres tipos de SGBD. Basados en una base de datos relacional, en el que se almacenan
los datos como un conjunto de tablas o relaciones. Basados en una base de datos en red, en el
que la estructura de los registros establece una relación subordinada "padre-hijo" entre ellos.
(P.e. un registro Departamento puede poseer registros Proyectos que, a su vez, poseen
registros Empleados). Basados en una base de datos jerárquica, similar a la anterior, con la
diferencia que cada registro sólo puede tener un padre. Nos limitaremos a las basadas en bases
de datos relacionales, ya que son las más utilizadas y poseen la ventaja de que la conversión
del modelo conceptual es directa, sin más que considerar las entidades como registros y los
atributos como campos de éstos.

ESTRUCTURA DE UN MODELO RELACIONAL

La estructura es la tabla. Veamos algunos conceptos importantes:

Clave Primaria: es el atributo o grupo de atributos que identifica a la tabla. No pueden haber
dos o más registros en una tabla con el mismo valor en el campo clave.

Clave Candidata o Alternativa: una posible clave principal.

Clave Ajena: atributo o conjunto de atributos cuyo valor debe coincidir con el valor de la
clave primaria de alguna tupla de la relación R a la cual referencia.

Restricción de clave: los valores de las claves candidatas deben ser únicos para cada tupla en
cualquier caso de la tabla.

Restricción de integridad de entidades: ningún valor de la clave primaria puede ser nulo.

Restricción de integridad referencial: se especifica entre dos tablas o relaciones y se usa para
mantener la consistencia entre las tablas relacionadas. Establece que una tupla de una tabla
que haga referencia a otra tabla, debe referirse a una tupla existente en esa tabla.

El esquema lógico es un conjunto de tablas en el cual, cada tabla tiene un identificador. Se

trata de pasar del DER al esquema lógico correspondiente, para lo que se tendrá que realizar
una transformación para las entidades y otra para las relaciones del DER. Para cada entidad
del DER se obtendrá una tabla con tantos campos como atributos tenga. Esta transformación
es directa. Para las relaciones N:N es necesario crear una nueva tabla, mientras que el resto de
relaciones puede ser modelada añadiendo atributos a las tablas existentes.

TRANSFORMACIÓN DE RELACIONES 1:1

 31

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:1. En principio,
tanto E1 como E2 producen tablas individuales. En cuanto a la relación, se tiene que estudiar
el comportamiento de las entidades E1 y E2 .

Si las dos entidades participan de forma total y tienen las mismas claves primarias, se
fusionan en una única tabla formada por los campos de ambas e incluyendo la clave primaria
una sola vez.

Si las dos entidades tienen claves primarias diferentes, se fusionan en una única tabla formada
por los campos de ambas. Una de las dos claves primarias es la clave primaria de la tabla
resultante.

Cuando una de las entidades participa de forma parcial en la relación, se obtiene una nueva
tabla para la relación, en la que aparecerán las claves principales de las entidades
participantes.

TRANSFORMACIÓN DE RELACIONES 1:N

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:N.

Si la entidad del lado de "muchos" participa de forma obligatoria, la clave primaria de la

entidad del lado de "uno" se debe incluir en la tabla del lado de "muchos".

Si la entidad del lado de "muchos" tiene una participación parcial, se establece una nueva
tabla formada por las claves primarias de las entidades y, como clave primaria, la clave de la
tabla del lado obligatorio.

TRANSFORMACIÓN DE RELACIONES N:N

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:N. En este
caso, se crea una nueva tabla que tiene como clave primaria la combinación de atributos que
constituyen las claves primarias tanto de E1 como E2 y que incluye los atributos de R.

6.7.- MODELO FÍSICO DE DATOS

El último paso en la relación con los datos que utilizará un sistema de información, consiste
en la elección de la organización física que soporte los métodos de acceso a los datos
establecidos anteriormente. Durante el diseño físico también se seleccionan las claves de
acceso a los ficheros de datos (tablas), y se eligen las claves alternativas. Se crean, por tanto,
los ficheros índices para posibilitar accesos alternativos.

6.8.- NORMALIZACIÓN DE DATOS

Con la modelización de los datos, además de especificar las características de la información,

se pretende conseguir la simplificación de las estructuras de datos definidas, localizando los
elementos de datos (atributos o campos de registros) redundantes, para lo cual se procede a
una reorganización de estas estructuras para eliminar las repeticiones, proceso que se conoce
 32

como normalización. La normalización es un proceso progresivo, en el que se pasa por la

Primera Forma Normal (1FN) en el que las entidades no contienen atributos repetidos,
Segunda Forma Normal (2FN) en el que las entidades tienen claves simples o si es
compuesta, los atributos clave no dependen de la totalidad de la clave, Tercera Forma Normal
(3FN) en el que las entidades no contienen dependencias funcionales entre sus atributos no
clave, Forma Normal de Boyce-Codd (FNBC) también conocida cono Forma Normal Óptima,
en el que para toda dependencia funcional entre cualquier atributo de la entidad, los atributos
que originan la dependencia son una clave de la relación, Cuarta Forma Normal (4FN) en el
que la entidad no debe contener más de una dependencia multievaluada independiente o una
dependencia multievaluada independiente junto con una dependencia funcional, y Quinta
Forma Normal (5FN) que es una extensión de la 4FN en el que las dependencias
multievaluadas no son independientes.

Una vez obtenido el modelo de datos normalizado, se procede a su optimización, ya que la

normalización también supone un aumento del tiempo de acceso a la información, al implicar
un aumento del número de entidades y, por tanto de accesos.

DEFINICIONES PREVIAS

Dependencia Funcional: Un atributo X (campo o atributo) depende funcionalmente de otro

atributo (o grupo de atributos) Y de la misma entidad si a cada valor de Y le corresponde sólo
un valor de X. Se representa como: Y ---> X

Por ejemplo, en una entidad EMPLEADO cuyos atributos son COD_EMPLEADO,

NOMBRE, DIRECCIÓN, los atributos NOMBRE y DIRECCIÓN dependen funcionalmente
de COD_EMPLEADO. Simbólicamente:

COD_EMPLEADO ---> NOMBRE

COD_EMPLEADO ---> DIRECCIÓN

Dependencia Funcional Completa: Un atributo X tiene dependencia funcional completa de

un grupo de atributos Y de la misma entidad, si X depende funcionalmente de Y pero no de
ningún subconjunto obtenido de los posibles atributos que forman Y.

Por ejemplo, la entidad asociativa PERSONAL cuyos atributos son COD_PROYECTO,

COD_EMPLEADO, FECHA_INCORPORACIÓN, HORAS_DEDICADAS, los atributos
FECHA_INCORPORACIÓN y HORAS_DEDICADAS tienen una dependencia funcional
completa respecto de COD_PROYECTO y COD_EMPLEADO. Simbólicamente:

COD_PROYECTO, COD_EMPLEADO ---> FECHA_INCORPORACIÓN

COD_PROYECTO, COD_EMPLEADO ---> HORAS_DEDICADAS

Dependencia Funcional Transitiva: Sean X, Y, Z tres atributos (o grupos de atributos) de la

misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende
funcionalmente de Y, se dice que Z depende transitivamente de X. Simbólicamente sería:

X ---> Y ---> Z entonces X ---> Z

 33

Por ejemplo, la entidad PROYECTO cuyos atributos son COD_PROYECTO,

COD_DIRECTOR, FECHA_COMIENZO, PRESUPUESTO, si un proyecto puede tener un
director, los atributos FECHA_COMIENZO y PRESUPUESTO tienen una dependencia
transitiva de COD_DIRECTOR. Simbólicamente:

COD_DIRECTOR ---> COD_PROYECTO ---> FECHA_COMIENZO

COD_DIRECTOR ---> COD_PROYECTO ---> PRESUPUESTO

Clave: es el atributo o grupo de atributos que identifica a la tabla y cuyo valor no puede ser
nunca nulo (para garantizar la integridad de clave) tal que todos los demás atributos tienen
una dependencia funcional completa de él.

Por ejemplo, la entidad EMPLEADO cuyos atributos son COD_EMPLEADO, NOMBRE,

DIRECCIÓN, la combinación de atributos COD_EMPLEADO y NOMBRE no es una clave a
pesar de que se cumple:

COD_EMPLEADO + NOMBRE ---> DIRECCIÓN

pero no se cumple NOMBRE ---> DIRECCIÓN, al poder haber empleados con el mismo
nombre. En cambio COD_EMPLEADO si es clave, pues se cumple: COD_EMPLEADO --->
NOMBRE y COD_EMPLEADO ---> DIRECCIÓN

Clave Ajena: En algunas entidades, pueden existir atributos que sean claves de otras
entidades. En este caso, tal atributo recibe el nombre de clave ajena y su valor ha de coincidir
con alguna de las ocurrencias de la entidad de la que es clave. De esta forma se garantiza la
integridad referencial. Cuando se elimine del sistema alguna ocurrencia de la entidad de la
que es clave principal, se deben borrar también todas las ocurrencias de otras entidades en las
que aparece como clave ajena, o bien darle un valor nulo a ese atributo.

Por ejemplo, la entidad PROYECTO tiene como clava COD_PROYECTO, pero existe el
atributo COD_DIRECTOR que es clave de otra entidad denominada DIRECTOR. En este
caso, COD_DIRECTOR en la entidad PROYECTO deberá tener el valor correspondiente a
alguno de los directores que existan en la entidad DIRECTOR.

COD_DIRECTOR ---> COD_PROYECTO ---> FECHA_COMIENZO

COD_DIRECTOR ---> COD_PROYECTO ---> PRESUPUESTO

Determinante: Atributo o grupo de atributos del que depende funcionalmente de forma

completa otro atributo.

REGLAS DE NORMALIZACIÓN

PRIMERA FORMA NORMAL (1FN) Una entidad está en 1FN si todos sus atributos son
simples, es decir, no contiene grupos repetidos. En este caso se cumple que todos los atributos
dependen funcionalmente de la clave.
 34

Ejemplo:

Una entidad que aparece en el DD con la siguiente descripción: PEDIDO =

@COD_PEDIDO + FECHA_PEDIDO + COD_PROVEEDOR +
NOMBRE_PROVEEDOR + DIRECCIÓN_PROVEEDOR + {COD_PRODUCTO +
NOMBRE_PRODUCTO + CANTIDAD_PEDIDA_PRODUCTO +
PRECIO_UNITARIO_PRODUCTO}

No está en 1FN por contener un grupo repetido.

Para conseguir obtener entidades en 1FN, se debe eliminar el grupo repetido, o lo que es lo
mismo, los atributos que no dependen funcionalmente de la clave, formando con ellos una
nueva entidad, cuya clave principal estará formada por la concatencación del atributo (o grupo
de atributos) que la identifica y la clave principal de la entidad original.

Ejemplo:

Por tanto, del ejemplo anterior se obtiene:

PEDIDO LÍNEA_PEDIDO

@COD_PEDIDO @COD_PEDIDO

FECHA_PEDIDO @COD_PRODUCTO

COD_PROVEEDOR NOMBRE_PRODUCTO

NOMBRE_PROVEEDOR CANTIDAD_PEDIDO_PRODUCTO

DIRECCIÓN_PROVEEDOR PRECIO_UNITARIO_PRODUCTO

SEGUNDA FORMA NORMAL (2FN) Una entidad está en 2FN si está en 1FN y cada
atributo que no pertenezca a la clave tiene una dependencia funcional completa de la
clave, es decir, si cada uno de los atributos de la entidad depende de toda la clave.

Ejemplo:

En el ejemplo anterior la entidad LÍNEA_PEDIDO no está en 2FN, ya que los

atributos NOMBRE_PRODUCTO y PRECIO_UNITARIO_PRODUCTO no tienen
una dependencia funcional completa de la clave, sino sólo de la parte
COD_PRODUCTO, al ser atributos propios de un producto, independientemente del
pedido en el que esté implicado.

Para conseguir obtener entidades en 2FN, se debe eliminar de la entidad original los
atributos que no dependen funcionalmente de toda la clave, sino solo de una parte de
la misma y, forman con ellos una nueva entidad, cuya clave principal estará formada
por la parte de la original de la que dependen funcionalmente.

Ejemplo:
 35

Por tanto, del ejemplo anterior se obtiene:

LÍNEA_PEDIDO PRODUCTO

@COD_PEDIDO @COD_PRODUCTO

@COD_PRODUCTO NOMBRE_PRODUCTO

CANTIDAD_PEDIDO_PRODUCTO PRECIO_UNITARIO_PRODUCTO

Una entidad que esté en 1FN pero no en 2FN ha de tener una clave primaria compuesta. Una
entidad que está en 1FN pero no en 2FN siempre se podrá reducir a un conjunto de entidades
en 2FN.

TERCERA FORMA NORMAL (3FN) Una entidad está en 3FN si está en 2FN y cada
atributo que no pertenezca a la clave no dependen transitivamente de la clave, es decir, si cada
uno de los atributos de la entidad dependen solo de la clave.

Ejemplo:

En el ejemplo anterior la entidad PEDIDO no está en 3FN, ya que los atributos

NOMBRE_PROVEEDOR y DIRECCIÓN_PROVEEDOR dependen transitivamente
de la clave COD_PEDIDO, es decir, no dependen sólo de la clave COD_PEDIDO,
sino que además dependen del atributo COD_PROVEEDOR.

Para conseguir obtener entidades en 3FN, se debe eliminar de la entidad original los atributos
que dependen de otro atributo distinto de la clave (dependencia transitiva) y, se forma con
ellos una nueva entidad, cuya clave principal será el atributo del cual dependen.

Ejemplo:

Por tanto, del ejemplo anterior se obtiene:

PEDIDO PROVEEDOR

@COD_PEDIDO @COD_PROVEEDOR

FECHA_PEDIDO NOMBRE_PROVEEDOR

COD_PROVEEDOR DIRECCIÓN_PROVEEDOR

ANALISIS FUNCIONAL

7.1.- INTRODUCCIÓN

El tercer tipo de herramienta de modelado que vamos a estudiar (el diagrama de transición de
estados), enfatiza el comportamiento del sistema dependiente del tiempo. Se utiliza
 36

fundamentalmente para sistemas de tiempo real, en los que se manejan fuentes externas de
datos de alta velocidad y a los que se debe proporcionar alguna respuesta lo suficientemente
rápida para manejar el ambiento externo. En este tipo de modelado es importante qué sucede
cuando ocurre tal evento.

7.2.- NOTACIÓN DE LOS DIAGRAMAS DE TRANSICIÓN DE ESTADOS

Los principales componentes de este tipo de diagrama son los estados y, las flechas o cambios
de estado.

Los estados se representan con un rectángulo al que se le ha añadido el nombre del estado que
simbolizan. Se define como un conjunto de circunstancias o atributos que caracterizan a un
objeto en un tiempo dado: forma de ser, condición,... representa algún comportamiento del
sistema que es observable y que perdura durante algún tiempo finito.

El DTE se utiliza para desarrollar un modelo de cómo se comportaría el sistema si hubiera

tecnología perfecta. Un aspecto de esta tecnología perfecta sería que el sistema trabajara de
manera infinitamente rápida. Así cualquier estado observable en el que el sistema se puede
encontrar corresponde a periodos en los que el sistema está esperando que algo ocurra en el
ambiente exterior o está esperando a que alguna actividad que se está desarrollando en ese
momento en el ambiente cambie a otra.

CAMBIOS DE ESTADO

Un sistema que solo existe en un estado es estático. Pero si un sistema puede tener varios
estados, ¿cómo se cambia de un estado a otro? Si se tienen reglas ordenadas que gobiernan el
comportamiento del sistema, entonces suelen existir algunos cambios de estado significativos
y válidos.

ESTADO 1

ESTADO 2

ESTADO 3

Los cambios de estado se representan conectando los estados con flechas. Cualquier estado
puede tener varios estados sucesores.

En este ejemplo no se dice nada acerca de cuáles son los estados inicial y final del sistema.
Este ejemplo representa un sistema estable, que siempre ha estado activo y que siempre lo
estará. La mayoría de los sistemas tienen un estado inicial y final reconocible.
 37

Lo habitual es representar el estado inicial en la cima del diagrama, aunque lo que realmente
identifica al estado inicial es la flecha que llega a él de ningún estado, es decir, la ausencia de
predecesores.

Lo habitual es representar el estado final en la base del diagrama, aunque lo que realmente
identifica al estado final es la ausencia de flechas que salen de él, es decir, la ausencia de
sucesores.

Un sistema tiene un estado inicial y puede tener varios estado finales. Cada estado final es
mutuamente excluyente: solo uno de ellos puede ocurrir durante alguna ejecución del sistema.

Se puede suponer que los cambios de estado ocurren instantáneamente, o lo que es lo mismo,
no se requiere tiempo observable para que el sistema cambie de un estado a otro.

CONDICIONES Y ACCIONES

Las condiciones causan un cambio de estado y las acciones que toma el sistema cuando
cambia de estado deben reflejarse en el DTE, junto a las flechas que conectas los estados
relacionados.

Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de

detectar y que hace que el sistema cambie de estado. Como consecuencia del cambio de
estado, el sistema hará una o más acciones. Las acciones son respuestas devueltas al ambiente
externo, o bien cálculos cuyos resultados se deben recordar.

7.3.- CONSTRUCCIÓN DEL DIAGRAMA DE TRANSICIÓN DE ESTADOS

Tenemos dos enfoque para realizar un DTE:

• Identificar todos los posibles estados del sistema y representarlos como cajas
separadas. Luego explorar las conexiones con significado (los cambios de estado).

• Empezar por el estado inicial e ir siguiendo un camino hasta el estado final.

Una vez construido el DTE se deberá contestar a las preguntas: ¿se han definido todos los
estados? ¿Se pueden alcanzar todos los estados? En cada estado, ¿el sistema responde a todas
las condiciones posibles?

7.4.- LA RELACIÓN DEL DTE CON OTROS MODELOS.

En la mayoría de los casos, el DTE representa una especificación de proceso para una burbuja
de control en un DFD. Los flujos de entrada al DFD se transforman en condiciones del DTE
y, los flujos de salida del DFD se transforman en las acciones del DTE.

DISEÑO DE INTERFACES
 38

8.1.- INTRODUCCIÓN AL MODELO DE DATOS

El balanceo de modelos se utiliza para evitar inconsistencias entre modelos. Esto quiere decir
que, si en un análisis estructurado se utilizan las siguientes herramientas:

• Diagrama de flujo de datos.

• Diccionario de datos.
• Especificación de proceso.
• Diagrama Entidad-Relación.

Se deben comprobar entre sí para asegurar su consistencia y obtener modelos balanceados. El

error más común de balanceo involucra una definición faltante: algo que se define (o
describe) en un modelo y no se define apropiadamente en otro. El segundo tipo de error es el
de inconsistencia: la misma "realidad" se describe de dos maneras diferentes y contradictorias
en dos modelos diferentes.

8.2.- BALANCEO DEL DFD Y EL DD

Cada flujo de datos y cada almacén de datos deben estar definidos en el diccionario de datos.
Si falta la definición en el diccionario, el flujo o almacén se considera "indefinido".

Cada dato y cada almacén definido en el diccionario de datos, deben aparecer en alguna parte
del DFD. Si no aparece dicho dato o almacén, es algo definido pero que no se utiliza en el
sistema.

8.3.- BALANCEO DEL DFD, EL DD Y LA ESPECIFICACIÓN DE PROCESO

Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con una especificación
de proceso, pero no ambos.

Cada especificación de proceso debe tener una burbuja de nivel inferior asociada en el DFD.

Las entradas y salidas deben coincidir en la burbuja del DFD del nivel inferior y, su
correspondiente especificación de proceso.

Cada término que aparece en la especificación de proceso debe existir en el diccionario de

datos.

Cada entrada del diccionario de datos debe tener referencia en una especificación de proceso,
un DFD u otro diccionario de datos.

Estas reglas sólo se aplican a las burbujas de procesos. Para las burbujas de control en un
DFD existe correspondencia entre las burbujas y los diagramas de transición de estados
asociados.
 39

8.4.- BALANCEO DEL DER CON EL DFD Y LA ESPECIFICACIÓN DE PROCESO

Cada almacén del DFD debe corresponder con una entidad del DER. No pueden existir
almacenes que no estén definidos en el DER como entidades y viceversa.

Los nombres de entidades en el DER y los nombres de almacenes en el DFD deben coincidir,
teniendo en cuenta la convención de nomenclatura de usar el plural en el DFD y el singular en
el DER.

Las entradas del diccionario de datos deben aplicarse tanto al modelo de DFD como al
modelo de DER.

Se deben de crear y mantener las instancias de los almacenes por parte de algún proceso del
DFD, por lo que al suceder dentro de la burbuja, se debe documentar en la especificación de
proceso correspondiente.

8.5.- BALANCEO DEL DFD Y EL DIAGRAMA DE TRANSICIÓN DE ESTADOS

Cada burbuja de control del DFD se asocia con un diagrama de transición de estados como su
especificación de proceso. De manera similar, cada diagrama de transición de estados en el
modelo global del sistema debe asociarse con una burbuja de control en el DFD.

Cada condición del diagrama de transición de estados debe corresponder con un flujo de datos
de entrada al proceso de control asociado con el diagrama de transición de estados. De manera
similar, cada flujo de control que entra en la burbuja de control debe asociarse con una
condición apropiada en el diagrama de transición de estados correspondiente.

Cada acción en el diagrama de transición de estados debe corresponder con un flujo de

control de salida del proceso de control asociado con dicho diagrama. De manera similar, cada
flujo de control de salida de la burbuja de control debe asociarse con una acción apropiada en
el diagrama de transición de estados correspondiente.

COSTOS Y TIEMPOS

9.1.- INTRODUCCIÓN

Hemos estado estudiando las distintas herramientas de modelado existentes en el análisis

estructurado, pero no hemos definido el concepto de Análisis Funcional. El término análisis
funcional indica el modelado de actividades dentro de una empresa; una función es una
porción de una empresa. El análisis funcional se centra en el entendimiento de cómo cada
función usa la información y cómo es intercambiada ésta entre las funciones. Es el primer
paso hacia la especificación y diseño de programas de aplicación que operan sobre la base de
datos. El análisis funcional se basa en las siguientes actividades a realizar:

• Realización del Modelo de Funciones del sistema (DFD)

• Realización del Modelo de Datos del sistema (DER)
 40

• Diseño de interfaces de usuario y prototipos.

• Establecimiento de Especificaciones no Funcionales.
• Establecimiento de Especificaciones de Entrega.
• Estimación Costo / Beneficio.

9.2.- CUALIDADES DE UN ESQUEMA FUNCIONAL

Independencia funcional: esta propiedad se alcanza cuando cada proceso es lo bastante

autónomo, es decir, que puede realizar una parte sustancial de sus funciones de manera
independiente.

Compleción: un modelo es completo cuando representa todos los rasgos del dominio de
aplicación en un nivel de detalle apropiado (es decir, cuando se especifican suficientes
detalles sobre el mismo pero no se describen rasgos procedimentales)

Corrección: un modelo es correcto cuando usa de manera apropiada los conceptos del modelo
para representar los requerimientos.

Legibilidad: un modelo es legible cuando representa los requisitos de manera natural y puede
ser entendido fácilmente sin necesidad de otras explicaciones.

Minimalidad: un modelo es mínimo cuando cada aspecto de los requerimientos aparece sólo
una vez en el esquema.

9.3.- RECONSTRUCCIÓN DE LOS MODELOS INICIALES

Hasta ahora, lo que se ha obtenido ha sido una versión inicial del modelo del comportamiento
del sistema. Sin embargo, este modelo no puede ser presentado al usuario para su verificación,
porque es demasiado complejo. El DFD preliminar tendrá una burbuja para cada
acontecimiento identificado en la lista da eventos. Del mismo modo, el DER inicial puede
tener muchas entidades como para ser revisado con el usuario. Por tanto, se necesita un
refinamiento de los mismos para eliminar los objetos innecesarios y/o añadir nuevos.

TERMINADO DEL MODELO DE PROCESO (DFD)

Lo primero es reorganizar el DFD/1. Se necesita una nivelación ascendente del DFD

preliminar, es decir, se deben agrupar procesos relacionados en agregados con significado,
cada uno de los cuales representa una burbuja de nivel superior. Existen tres reglas que
permiten hacer esto:

Cada agrupación de procesos debe involucrar respuestas relacionadas cercanamente, es decir,

se deben agrupar procesos que manejan datos relacionados cercanamente.

Se debe intentar esconder datos almacenados que aparecen en el nivel inferior. Si hay
procesos que se refieren a un almacén común y no hay otros procesos en el DFD preliminar
que se refieran a este almacén, entonces se puede crear una burbuja de nivel superior para
esconderlo.
 41

Se deben crear agregados de procesos que consistan en aproximadamente 7 más menos 2

bloques de información, donde un proceso y sus flujos relacionados, se considera como un
bloque.

TERMINADO DEL DICCIONARIO DE DATOS (DD) Y LAS ESPECIFICACIONES

DE PROCESO

Es necesario comprobar que se ha dado el significado de cada dato, se han dividido los datos
complejos del sistema en elementos menores, que sea consistente, que esté balanceado con el
DFD por niveles, el DER y las especificaciones de proceso.

Cuando el DFD preliminar empieza a estabilizarse y, cuando ha pasado la prueba de

nivelación ascendente, entonces se puede empezar a escribir las especificaciones de proceso,
que deberán ir balanceándose y comparándose con el DD y el DER.

TERMINADO DEL MODELO DE DATOS (DER)

Si el DFD y el DER se van realizando al mismo tiempo, se deben ir revisando al mismo

tiempo para asegurar la existencia de almacenes comunes, flujos de datos, etc.

TERMINADO DEL MODELO DE COMPORTAMIENTO (DTE)

Si el sistema tiene características de tiempo real, se estará definiendo un DTE y un DER. Se

deben encontrar los siguientes tipos de errores:

• ¿ Se han definido todos los estados ?

• ¿ Se puede llegar a todos los estados ?
• ¿ Se puede salir de todos los estados ?
• En cada estado, ¿responde el sistema adecuadamente a todas las condiciones posibles?

CONTROL DE PROYECTOS

10.1.- INTRODUCCIÓN

La interfaz de usuario es el mecanismo a través del cual se establece un diálogo entre el

programa y el usuario. Define cómo interactúa el ordenador y el usuario. Si se tienen en
cuenta los factores humanos, el diálogo será fluido y se establecerá un ritmo entre el usuario y
el programa. Si estos factores se han ignorado, el sistema será casi siempre visto como "poco
amigable" o lo que es lo mismo, una interfaz buena y de fácil uso hará más fácil y agradable
el trabajo al usuario, por lo que el usuario realizará el trabajo de manera más efectiva.

Las entradas y salidas pueden ser interactivas o por lotes. En una interfaz interactiva, el
usuario se comunica directamente con el ordenador. La salida interactiva debe ser rápida y
mínima para un propósito particular. Si la información es insuficiente, el usuario puede pedir
más información, por tanto, el ordenador puede ser selectivo en la información a mostrar.
 42

El sistema de entradas o salidas del sistema o Interfaz Humana, tiene gran importancia para el
usuario. Daremos importancia a cuatro aspectos fundamentales:

1. Distribución del modelo esencial entre personas y máquinas. Es decir, asignación de

partes que deben funcionar bajo el control del usuario y, bajo la máquina.

2. Factores humanos que influyen en la decisión de la interfaz humana.

3. Detalles de interacción hombre-máquina, o formatos de entrada/salida del sistema.

Actividades manuales que se puedan necesitar: ingreso de datos al sistema, almacenamiento
de datos, etc.

4. Restricciones operativas que el usuario desea imponer al sistema: volumen de datos,

tiempo de respuesta, restricciones de seguridad, etc.

10.2.- DETERMINACIÓN DE LA FRONTERA DE AUTOMATIZACIÓN

En este momento del análisis, se está trabajando con todas las actividades (funciones y
procesos) del sistema y, con los datos esenciales. Tendremos que plantearnos qué funciones y
qué datos deben ser manejados manualmente y cuáles deben ser automatizados. Podemos
encontrarnos tres casos:

1. Al usuario no le importa la frontera de automatización, cuáles son los límites entre parte
manual y parte automática. Esta situación es poco probable.

2. El usuario podría escoger un sistema totalmente automatizado. Esta situación suele ser
habitual si el sistema está siendo reemplazado por uno más moderno y no se cambia la
frontera de automatización, por lo que las actividades manuales ya se representan en el
Diagrama de contexto como agentes externos al sistema.

3. El usuario se decide por un sistema completamente manual, opción muy anormal. Se

puede dar en situaciones en las que se pretenda reorganizar la forma en la que se desempeñan
as actividades en una organización.

Lo habitual es que se automatizará parte de las actividades del sistema y, se dejarán como
manuales otras. De la misma forma, se dejarán unos datos como computerizados y otros
quedarán bajo el control del usuario. Suele ser aconsejable que el usuario, analista y el
programador, exploren varias soluciones. Cada solución posible tendrá un coste que habrá que
determinar y, diferentes ramificaciones organizacionales.

Es labor del usuario el escoger la frontera de automatización que más le interese. Una vez
asignada la frontera, no se deben eliminar los procesos del DFD que no sean automatizadas.
Es más, es posible que sea necesario incluir procesos de apagado/encendido del sistema, ya
que en el modelo esencia se supone que el sistema ha estado trabajando siempre y que
continuará trabajando para siempre.
 43

10.3.- FACTORES HUMANOS

PERCEPCIÓN HUMANA

La interfaz suele llevarse a cabo a través de un medio visual. El ojo y el cerebro trabajan
conjuntamente para recibir e interpretar la información visual. La especificación apropiada de
la comunicación visual es el elemento clave de una interfaz amigable. El tamaño del texto,
tipo de letra, longitud de línea, uso de mayúsculas, posición, color, etc., influyen en la
facilidad de extracción de información por parte del usuario. La información según se extrae,
debe ser almacenada para ser utilizada posteriormente.

NIVEL DE HABILIDAD HUMANA Y COMPORTAMIENTO

Una interfaz usada por dos personas de la misma educación y preparación, pero con
personalidades completamente diferentes, puede ser vista como "amistosa" por uno y como
"poco amigable" por la otra. Por tanto, el nivel de habilidad tendrá un impacto significativo
sobre la habilidad para extraer la información significativa. La interfaz hombre-máquina debe
diseñarse para las diferentes personalidades de los usuarios finales.

TAREAS Y FACTORES HUMANOS

Un sistema basado en computadoras, raramente permite al usuario hacer algo nuevo. En la

mayoría de los casos, el sistema se construye para automatizar ciertas tareas que se realizaban
antes a mano, por lo que la interfaz hombre-máquina debe dotar al usuario final de un entorno
fácil y natural para realizarse. Casi siempre se realizan las siguientes tareas genéricas:

• Tareas de comunicación: actividades que permiten que la información sea transferida

desde el productor al consumidor.

• Tareas de diálogo y control: actividades que permiten al usuario dirigir y controlar la

interacción con el sistema o permiten al usuario controlar la información y el
conocimiento y, ordenar el proceso a través del cual se desarrolla el resto de tareas.

• Tareas cognitivas: actividades que se realizan una vez que se ha obtenido la

información. Actividades asociadas con el funcionamiento del sistema.

10.4.- DETERMINACIÓN DE LA INTERFAZ HUMANA

Suele ser la tarea que consume más tiempo y que más interesa al usuario. 4 aspectos a tener
en cuenta:

• Elección de los dispositivos de Entrada/Salida.

• Formato de las entradas que van desde los agentes externos al sistema.

• Formato de salidas hacia el agente externo.

 44

• Secuencia y tiempos de E/S en un sistema en línea.

10.4.1.- ELECCIÓN DE LOS DISPOSITIVOS DE ENTRADA/SALIDA.

La elección de estos dispositivos puede estar determinada por los agentes externos. Las
entradas al sistema proporcionadas por el usuario pueden facilitarse utilizando los siguientes
dispositivos:

• Tarjetas perforadas: Tenían la ventaja de ser utilizadas como documento fuente por el
usuario externo. Las desventajas que ofrece son su tamaño engorroso, limitada
capacidad de almacenamiento, sólo utilizables una vez, susceptibles a errores.

• Cinta magnética: su ventaja es un mayor volumen de datos que en la tarjeta. Como

desventaja, los datos no pueden ser manipulados fácilmente.

• Discos flexibles.

• Terminales y ordenadores personales: como tipos de terminales podemos encontrarnos

simples: ordenador y teclado; e inteligentes, con posibilidad de edición y
almacenamiento local. Los ordenadores personales tienen una capacidad mayor de
almacenamiento y, todas las capacidades computacionales del PC. Los ordenadores
personales y las terminales inteligentes hacen que el usuario haga cambios y corrija
errores de manera instantánea.

• Lectores ópticos y de código de barras: leen información impresa o codificada en varios

tipos de documento. Se elimina la introducción manual de datos. Una de sus
desventajas es su coste y posibilidad de errores.

• Teléfono: a través del módem y la RTC.

• Voz: desventajas que ofrece, coste del dispositivo, vocabulario limitado, tiempo de
respuesta lento, no siempre reconocen la voz.

• Los distintos dispositivos de salida que se pueden emplear en un sistema son:

• Salidas impresas: es la forma más común. Como ventaja constituye un documento

permanente y puede usarse en una variedad de aplicaciones fuera del sistema. Su
desventaja es el gran tamaño, velocidad baja, etc.

• Tarjetas perforadas.

• Cinta magnética.

• Discos flexibles.
 45

• Terminales y ordenadores personales: los sistemas en línea utilizan la terminal como

medio de salida. Como ventaja puede mostrar gran volumen de información a gran
velocidad y, como desventaja no representa una salida material.

• Teléfono: a través del módem y la RTC.

• Voz: a través del teléfono y la RTC. Es bueno para mensajes cortos.

10.4.2 y 10.4.3.- FORMATOS DE ENTRADA/SALIDA.

Para diseñar la interfaz hombre-máquina, se debe tener en cuenta la percepción del sistema o
imagen mental del sistema que se forma el usuario final. Encontramos situaciones en las que
las E/S del sistema deben tener un formato fijo. En otras, al usuario no le preocupa el tamaño
o la presentación de los datos de E/S pero sí puede interesar la secuencia con la que se
presentan las pantallas de comunicación con el usuario. Para ello, debe utilizarse un DTE.

10.5.- ESTILOS DE INTERACCIÓN HOMBRE-MÁQUINA

En los primeros tiempos, la única interfaz humana existente era la Interfaz de Preguntas y
Órdenes también llamada de comandos. El ordenador pide al usuario entradas específicas. Al
obtener la información, el ordenador puede responder con alguna información o interrogar de
nuevo al usuario. Este proceso continua hasta que se han introducido o recuperado todos los
datos. La comunicación era únicamente textual y conducida mediante órdenes y respuestas a
preguntas generadas por el sistema. Estas órdenes eran concisas, propensas a errores, muy
estrictas y bastantes difíciles de aprender.

Una variante de esta interfaz es la Interfaz de Menú Simple, que es menos dada a errores ya
que las opciones se introducen con un número o letra, pero su uso puede llegar a ser tedioso.
Se le presenta al usuario una serie de acciones y requiere la elección de una de ellas. Una vez
seleccionada la acción, se presenta otro menú. Este menú depende de la acción seleccionada

La Interfaz Orientada a Ventanas, tiene la posibilidad de señalar y de elegir. Son los

equivalentes a los formularios del ordenador. Ofrece al usuario un gran número de ventajas: a)
se pueden visualizar diferentes tipos de información simultáneamente, permitiendo al usuario
cambiar de contexto; b) el esquema de menús desplegables permite realizar muchas tareas
interactivas diferentes; c) la utilización de iconos gráficos, menús desplegables, botones y
técnicas de presentación continua reducen el número de pulsaciones de teclado.

La Generación Actual de interfaz reúne todas las características de la interfaz anterior más el
hipertexto y la multitarea.

10.6.- REGLAS PARA EL DESARROLLO DE LA INTERFAZ DE USUARIO

1. El sistema debe pedir Entradas y producir Salidas consistentes sobre todo en sistemas en
línea.
 46

2. Pedir información con una secuencia lógica. Buscar la eficiencia en el diálogo.

3. Hacer entender al usuario dónde ha cometido el error y de qué tipo. Cada dato se
comprueba en el momento de ser introducid y los usuarios son informados si se ha cometido
un error.

4. Distinguir entre edición de campos y ediciones de pantalla: determinar si el campo

proporcionado por el usuario es correcto o no sin hacer referencia a otros campos. Preguntar
por la verificación de cualquier acción destructiva no trivial.

5. Hacer la edición y revisión de errores dependiente del usuario, protegiéndose de estos

errores.

6. Permitir al usuario cancelar toda la transacción o parte. Permitir una vuelta atrás.

7. Proporcionar un mecanismo de ayuda conveniente.

8. Hacer distinción entre sistemas guiados por menús o por órdenes, aunque se debe de
reducir la cantidad de información a memorizar por parte del usuario.

9. Si el sistema tiene que realizar un proceso largo, avisar al usuario con un reloj o algo
parecido para no dar sensación de error.

10. Proporcionar entradas o valores por omisión para las entradas estándar, así como agrupar
las actividades por función.

11. No abusar del sonido y del color.

ENTRADAS DE DATOS

• Minimizar el número de acciones que debe realizar el usuario.

• Mantener la consistencia entre la información visualizada y los datos de entrada.

• Permitir la personalización.

• Interacción flexible y ajustada al modelo de entrada preferido por el usuario.

• Desactivar órdenes inapropiadas.

• Permitir al usuario controlar el flujo interactivo.

• Proporcionar ayuda en todas las acciones.

• Eliminar entradas innecesarias.

 47

SALIDAS DE DATOS

• Mostrar sólo la información relevante en el contexto actual.

• No abrumar al usuario con datos. Utilizar un formato de presentación que permita una
asimilación rápida de la información.

• Utilizar etiquetas consistentes, abreviaciones estándar, colores predecibles.

• Permitir al usuario mantener el contexto visual.

• Producir mensaje de error significativos.

• Utilizar mayúsculas/minúsculas, tabulaciones, agrupaciones de texto, etc. para ayudar

a la comprensión.

• Utilizar representaciones analógicas para mostrar la información que es más fácil de

asimilar desde esta representación.

• Utilizar la pantalla eficientemente.

10.7.- ESPECIFICACIÓN DE LAS RESTRICCIONES OPERACIONALES

Para conseguir encontrar el hardware ideal, sistema operativo, equipo de telecomunicaciones,

lenguaje de programación y estrategia de diseño para el nuevo sistema, se deben tener en
cuenta las restricciones operativas que imponga el usuario, como puede ser el volumen de
datos, tiempo de respuesta a las diversas entradas, restricciones políticas sobre modalidades
de implantación, restricciones ambientales. Restricciones de seguridad y confiabilidad
respecto a errores, restricciones de seguridad para impedir usos indebidos o no autorizados del
sistema, etc.