República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Superior

Colegio Universitario “Francisco de Miranda”
Cátedra: Análisis y Diseño de Sistemas I

UNIDAD II y III
Especificaciones de Procesos
Diseño de Sistema
Diseño Modular
Casos Prácticos

Fonten, Soveida Carnet: 3700920

Morales, Yetza Carnet:
Almaro Salas, Luis Alberto Carnet: 6300028
Pacheco, Daniel Carnet: 6400478
Menoscal, Carlos Carnet: 6400408

Junio 2009
Índice
Introducción....................................................................................................................... 4
Desarrollo .......................................................................................................................... 4
Situación Actual............................................................................................................. 5
Bases Teóricas ............................................................................................................... 5
Parte I ............................................................................................................................ 5
Especificaciones De Procesos......................................................................................... 5
Formato De La Especificación De Proceso ................................................................. 6
Lenguaje (Español) Estructurado............................................................................ 7
Cómo Escribir Español Estructurado ...................................................................... 8
Tablas De Decisión ................................................................................................ 8
Desarrollo De Tablas De Decisión.......................................................................... 9
Verificación De La Completitud Y La Exactitud .................................................. 10
Tablas De Decisión Más Avanzadas ..................................................................... 10
Árboles De Decisión............................................................................................. 11
Construcción De Árboles De Decisión.................................................................. 12
Selección de una Técnica de Análisis de Decisiones Estructuradas ....................... 12
Parte II ......................................................................................................................... 13
Diseño del Sistema....................................................................................................... 13
Definición ................................................................................................................ 13
Objetivo ................................................................................................................... 13
Características .......................................................................................................... 13
Diseño de Datos ................................................................................................... 13
Diseño Arquitectónico .......................................................................................... 14
Diseño de la Interfaz............................................................................................. 14
Diseño Procedimental........................................................................................... 14
Método del Prototipo de Sistemas......................................................................... 14
Las Técnicas Estructuradas................................................................................... 15
Prototipos................................................................................................................. 15
Interfaz con el Usuario ............................................................................................. 18
Interfaz ................................................................................................................. 18
Tipos De Interfaz.................................................................................................. 18
Lineamientos para el Diseño de Diálogos ............................................................. 18
Diseño Modular ........................................................................................................... 21
Diagrama Warnierr – Orr ......................................................................................... 21
Elementos Básicos................................................................................................ 21
Uso De Diagramas De Warnier/Orr ...................................................................... 21
Diagrama HIPO........................................................................................................ 23
Definición ............................................................................................................ 23
El VTOC ( Visual Table of contents).................................................................... 23
Diagrama General IPO ......................................................................................... 24
Diagrama detallado IPO ....................................................................................... 25
Casos Prácticos ................................................................................................................ 27
Lenguaje (Español) Estructurado.................................................................................. 27
Tablas de Decisión ....................................................................................................... 27
 Árboles de Decisión ..................................................................................................... 28
Diseño de Sistema ........................................................................................................ 29
Diseño de Datos ....................................................................................................... 29
Diseño de Arquitectónico ......................................................................................... 32
Diseño de Interfaz .................................................................................................... 32
Conclusión....................................................................................................................... 34
Introducción
En la fase de diseño del ciclo de vida del desarrollo de sistemas, el analista utiliza
la información recopilada en las primeras fases para realizar el diseño lógico del
sistema de información.

El analista diseña procedimientos precisos para la captura de datos que aseguran

que los datos que ingresen al sistema de información sean correctos. Además, el
analista facilita la entrada eficiente de datos al sistema de información mediante
técnicas adecuadas de diseño de formularios y pantallas.

La concepción de la interfaz de usuario forma parte del diseño lógico del sistema
de información. La interfaz conecta al usuario con el sistema y por tanto es
sumamente importante. Entre los ejemplos de interfaces de usuario se encuentran
el teclado (para teclear preguntas y respuestas), los menús en pantalla (para
obtener los comandos de usuario) y diversas interfaces gráficas de usuario que se
manejan a través de un ratón.

En el presente trabajo se expondrá la continuación del anterior y proseguiremos a

la fase de diseño de sistemas, se mostrarán las distintas etapas o fases a seguir
en la realización de un diseño eficaz, eficiente además de funcional.
Desarrollo

Situación Actual

Bases Teóricas

Parte I

Especificaciones De Procesos

Para determinar los requerimientos de información de una estrategia de análisis

de decisión, el analista de sistemas primero debe determinar los objetivos
organizacionales mediante un enfoque de jerarquización de arriba hacia abajo. El
analista de sistemas debe entender los principios organizacionales y debe contar
con experiencia en las técnicas de recopilación de datos. El enfoque de
jerarquización de arriba hacia abajo es muy importante porque todas las
decisiones de la organización se deben relacionar, por lo menos indirectamente,
con los objetivos generales de la misma.

Las especificaciones de procesos, a veces llamadas miniespecificaciones, debido

a que representan una parte pequeña de las especificaciones del proyecto total,
se crean para los procesos primitivos en un diagrama de flujo de datos así como
también para algunos procesos de nivel superior que se amplían a un diagrama
hijo. Estas especificaciones explican la lógica de la toma de decisiones y las
fórmulas que transformarán los datos de entrada de un proceso en salidas. Cada
elemento derivado debe tener lógica del proceso para mostrar cómo se origina de
los elementos base u otros elementos derivados previamente creados que se
alimentan del proceso primitivo.

Las tres metas para producir especificaciones de procesos son las siguientes:
1. Reducir la ambigüedad del proceso. Esta meta obliga al analista a aprender
los detalles acerca del funcionamiento de un proceso. Es necesario
detectar, anotar e integrar la s áreas indefinidas de todas as l
especificaciones de procesos. Estas observaciones constituyen una base y
proporcionan las preguntas para las entrevistas de seguimiento con la
comunidad de usuarios.
 2. Obtener una descripción precisa de lo que se está realizando, lo cual
normalmente se incluye en un paquete de especificaciones para el
programador.
3. Validar el diseño del sistema. Esta meta incluye garantizar que un proceso
tenga todo el flujo de datos de entrada necesario para producir la salida.
Además, todas las entradas y salidas deben representarse en el diagrama
de flujo de datos.

Se encontrará muchas situaciones en las que no se crean especificaciones de

procesos. A veces el proceso es muy simple o el código de la computadora ya
existe. Esta eventualidad se debería asentar en la descripción del proceso, y no se
requeriría ningún diseño adicional. A continuación se mencionan las categorías de
procesos que generalmente no requieren especificaciones:

1. Procesos que representan entrada o salida física, tal como leer y escribir.
Por lo general estos procesos sólo requieren lógica simple.
2. Procesos que representan una validación de datos simple, la cual
normalmente es bastante fácil de realizar. Los criterios de edición se
incluyen en el diccionario de datos y se integran en el código fuente de la
computadora. Las especificaciones de procesos se podrían crear para la
edición compleja.
3. Procesos que usen código preescrito. Estos procesos generalmente se
incluyen en un sistema como subprogramas y funciones.

Formato De La Especificación De Proceso

Las especificaciones de procesos vinculan el proceso al diagrama de flujo de

datos y, por consiguiente, al diccionario de datos. La especificación de cada
proceso se debe registrar en un formulario especial Ingrese la siguiente
información:
1. El número del proceso, el cual debe coincidir con el ID del proceso del
diagrama de flujo de datos. Esta especificación permite a un analista
trabajar con cualquier proceso o modificarlo y localizar fácilmente el
diagrama de flujo de datos donde se encuentra el proceso.
2. El nombre del proceso, el cual nuevamente debe ser el mismo que el
asentado en el símbolo del proceso en el diagrama de flujo de datos.
3. Una descripción breve de lo que realiza el proceso.
4. Una lista de flujos de datos de entrada, usando los nombres que están en el
diagrama de flujo de datos. Los nombres de datos que se usan en la
fórmula o lógica deben coincidir con los del diccionario de datos para
garantizar la consistencia y una buena comunicación.
5. Los flujos de datos de salida, utilizando también los nombres del diagrama
de flujo de datos y del diccionario de datos.
 6. Una indicación del tipo de proceso: por lote, en línea o manual. Todos los
procesos en línea requieren diseños de pantalla, y todos los procesos
manuales deben tener procedimientos bien definidos para que los
empleados realicen las tareas del proceso.
7. Si el proceso usa código preescrito, incluya el nombre del subprograma o
función que contenga al código.
8. Una descripción de la lógica del proceso que indique las políticas y reglas
del negocio en lenguaje cotidiano, no en pseudocódigo de lenguaje de
computadora. Las reglas del negocio son los procedimientos, o quizás un
conjunto de condiciones o fórmulas, que permiten a una corporación dirigir
su negocio. Los formatos comunes de las reglas del negocio incluyen lo
siguiente:
a. Definiciones de los términos del negocio.
b. Condiciones y acciones del negocio.
c. Restricciones de la integridad de los datos.
d. Derivaciones matemáticas y funcionales.
e. Inferencias lógicas.
f. Secuencias de procesamiento.
g. Relaciones entre las circunstancias del negocio.
9. Si no hay suficiente espacio en el formulario para una descripción completa
del Español estructurado o si hay una tabla o árbol de decisión que
describa la lógica, incluir el nombre de la tabla o árbol correspondiente.
10. Mencione cualquier problema sin resolver, partes incompletas de la lógica u
otras consideraciones. Estos problemas constituyen la base de las
preguntas usadas para las entrevistas de seguimiento.

Los elementos anteriores se deben introducir para completar un formulario de

especificación del proceso, el cual contiene un número de proceso, nombre del
proceso, o ambos, del diagrama de flujo de datos, así como también otros
elementos. Observe que completar este ormulario f facilita ampliamente la
vinculación del proceso con el diagrama de flujo de datos y el diccionario de datos.

Lenguaje (Español) Estructurado

Cuando la lógica del proceso involucra fórmulas o iteración, o cuando las
decisiones estructuradas no son complejas, el uso del Español estructurado es
una técnica apropiada para analizar el proceso de decisión. Como su nombre
implica, el Español estructurado se basa en (1) lógica estructurada o instrucciones
organizadas en procedimientos anidados y agrupados, y (2) enunciados simples
del Español tales como sumar, multiplicar y mover.

Un problema de expresión se puede transformar en Español estructurado,

poniendo las reglas de decisión en su secuencia adecuada y usando en todo
momento la convención de instrucciones IF-THEN-ELSE. El Español estructurado
puede ser más complejo si se anidan bloques de instrucciones dentro de otros
bloques de instrucciones.
Cómo Escribir Español Estructurado
Para escribir Español estructurado, podría seguir las convenciones siguientes:
1. Exprese toda la lógica en uno de estos cuatro tipos: estructuras
secuenciales, estructuras de decisión, estructuras de caso o iteraciones.
2. Use en mayúsculas las palabras clave aceptadas como IF, THEN, ELSE,
DO, DO WHILE, DO UNTIL y PERFORM.
3. Ponga sangría en los bloques de enunciados para mostrar claramente su
jerarquía (anidamiento).
4. Cuando las palabras o frases se han definido en un diccionario de datos,
subráyelas para denotar que tienen un sig nificado especializado o
reservado.
5. Tenga cuidado al usar "y" y "o", y evite la confusión al distinguir entre
"mayor que" y "mayor que o igual a" y otras relaciones similares. "A y B"
quiere decir tanto A como B; "A o B" quiere decir cualquiera de A o B, pero
no ambos. Aclare ahora los enunciados lógicos en lugar de esperar hasta la
etapa de codificación del programa.

Tablas De Decisión
Una tabla de decisión es una a t bla de filas y columnas separadas en cuatro
cuadrantes. El cuadrante superior izquierdo contiene la(s) condición(es); el
cuadrante superior derecho contiene las alternativas de condición. En la parte
inferior izquierda de la tabla se encuentran las acciones que se deben realizar y en
la parte inferior derecha las reglas para llevar a cabo las acciones. Cuando se usa
una tabla de decisión para determinar qué acción se debe realizar, la lógica se
mueve en el sentido de las manecillas del reloj empezando en la parte superior
izquierda.

Suponga que una tienda desea ilustrar su política sobre las compras que los
clientes no pagan en efectivo. La compañía podría hacer esto mediante una
sencilla tabla de decisión. Cada una de las tres condiciones (venta menor de $50,
paga con cheque y usa tarjeta de crédito) tiene tan sólo dos alternativas. Las dos
alternativas son S (sí, es verdad) o N (no, no es verdad). Pueden ocurrir cuatro
acciones:

1. Registrar la venta.
2. Buscar el número de la tarjeta de crédito en el libro antes de registrar la
venta.
3. Pedir la aprobación al supervisor.
4. Pedir la autorización de la tarjeta de crédito al banco.

El último ingrediente que hace que la tabla de decisión valga la pena es el grupo
de reglas para cada una de las acciones. Las reglas son las combinaciones de las
alternativas de condición que provocan una acción.
Desarrollo De Tablas De Decisión
Para construir tablas de decisión, el analista necesita determinar el tamaño
máximo de la tabla; eliminar ituacioness imposibles, inconsistencias o
redundancias, y simplificar la tabla tanto como sea posible. Los pasos siguientes
proporcionan al analista un método sistemático para desarrollar tablas de decisión:

1. Determine el número de condiciones que podrían afectar la decisión.

Combine filas que se traslapen, como en el caso de condiciones que se
excluyen mutuamente. El número de condiciones se vuelve el número de
filas en la mitad superior de la tabla de decisión.
2. Determine el número de posibles acciones que se pueden realizar. Dicho
número se vuelve el número de filas en la mitad inferior de la tabla de
decisión.
3. Determine el número de alternativas de condición para cada condición. En
la forma más simple de tabla de decisión, habría dos alternativas (S o N)
para cada condición. En una tabla de entradas extendidas podría haber
muchas alternativas para cada condición.
4. Calcule el número máximo de co lumnas en la tabla de decisión
multiplicando el número de alternativas para cada condición. Si hubiera
cuatro condiciones y dos alternativas (S o N) para cada una de las
condiciones, habría 16 posibilidades como sigue:
Condición 1: x 2 alternativas
Condición 2: x 2 alternativas
Condición 3: x 2 alternativas
Condición 4: x 2 alternativas
16 posibilidades
5. Complete las alternativas de condición. Empiece con la primera condición y
divida el número de columnas entre el número de alternativas para esa
condición. En el ejemplo anterior hay 16 columnas y dos alternativas (S o
N), de modo que 16 dividido entre 2 es 8. Después seleccione una de las
alternativas, supongamos S, y escríbala en las primeras ocho columnas.
Termine escribiendo N en las ocho columnas restantes como sigue:
Condición 1 : SSSSSSSSNNNNNNN N
Repita este paso para cada con dición mediante un
subconjunto de la tabla, Condi
ción 1 :
SSSSSSSSNNNNNNN N
Condición 2 : SSSSNNN N
Condición 3: S S N N
Condición 4: S N
y siga el patrón para cada condición:
Condición 1 : SSSSSSSSNNNNNNN N
 Condición 2 : SSSSNNNNSSSSNNN N
Condición 3 : SSNN S SNN S SNN S SN N
Condición 4 : SNSNSNSNSNSNSNS N

6. Complete la tabla insertando una X en donde las reglas indiquen ciertas

acciones.
7. Combine las reglas en donde sea evidente que una alternativa no
representa una diferencia en el resultado. Por ejemplo,
Condición 1: S S
Condición 2: S N
Acción 1: XX
se puede expresar como:
Condición 1: S
Condición 2: —
Acción 1: X
La raya (—) significa que la condición 2 puede ser S o N, y
que aún así se realizará la acción
8. Verifique si la tabla contiene situaciones imposibles, contradicciones y
redundancias.
9. Reorganice las condiciones y acciones (o incluso las reglas) si esto hace
más comprensible la tabla de decisión.

Verificación De La Completitud Y La Exactitud

Es esencial verificar que sus tablas de decisión estén completas y sean exactas.
En el desarrollo de las tablas de decisión pueden ocurrir cuatro problemas
principales: incompletitud, situaciones imposibles, contradicciones y redundancia.
Es de suma importancia asegurarse de que todas las condiciones, alternativas de
condición, acciones y reglas de acción estén completas. Suponga que una
condición importante se ha omitido en un problema. La tabla de decisión entera
cambiaría porque se tendría que agregar una nueva condición, un nuevo grupo de
alternativas, una nueva acción y una o más reglas de acción.

Tablas De Decisión Más Avanzadas

Las tablas de decisión pueden ser muy difíciles de manejar porque crecen
rápidamente conforme se incrementa el número de condiciones y alternativas. Una
tabla con tan sólo siete condiciones y con alternativas sí o no tendría 128
columnas. Para reducir la complejidad de las tablas de decisión difíciles de
manejar, use entradas extendidas o la regla ELSE, o bien, construya varias tablas.
Observe que en la siguiente tabla de S o N las condiciones son mutuamente
excluyentes.

Cl : No pidió S N N N
C2: Pidió una vez N S N N
C3: Pidió dos veces N N S N
C4: Pidió más de dos veces N N N N

Por lo tanto, las condiciones se pueden escribir en forma de entradas extendidas

como sigue:
Cl : Número de veces que el cliente pidió 0 1 2 >2

El número de columnas y filas requeridas disminuye y la comprensibilidad

aumenta. En lugar de usar cuatro filas para el número de veces que pide un
cliente, tan sólo se necesita una.

Al usar tablas de entradas extendidas, disminuye la probabilidad de redundancia y

contradicción.

El uso de la columna ELSE es otra técnica útil para construir tablas de decisión.
Esta técnica es útil para eliminar muchas reglas repetitivas que requieren
exactamente la misma acción. También es útil para evitar omisiones.

Las tablas de decisión son una herramienta importante en el análisis de decisiones

estructuradas. Una ventaja importante de usar tablas de decisión en lugar de otros
métodos es que éstas ayudan al analista a asegurar la completitud. Al usar tablas
de decisión, también es fácil verificar posibles errores, tal como situaciones
imposibles, contradicciones y redundancia. También existen procesadores de
tablas de decisión que toman la tabla como entrada y proporcionan código de
programa de computadora como salida.

Árboles De Decisión
Los árboles de decisión se usan cuando ocurre una bifurcación compleja en un
proceso de decisión estructurada. Los árboles también son útiles cuando es
necesario mantener una cadena de decisiones en una secuencia particular.
Aunque el nombre del árbol de decisión se deriva de los árboles naturales, en la
mayoría de los casos los árboles de decisión se construyen de manera lateral, con
la raíz del árbol del lado izquierdo del papel; a partir de allí, el árbol extiende sus
ramas hacia el lado derecho. Esta orientación permite al analista escribir en las
ramas para describir condiciones y acciones.

A diferencia del árbol de decisión que se utiliza en las ciencias administrativas, el

árbol del analista no contiene probabilidades y resultados, debido a que en el
análisis de sistemas los árboles se usan principalmente para identificar y organizar
condiciones y acciones en un proceso de decisión completamente estructurado.
Construcción De Árboles De Decisión
Es muy útil distinguir entre condiciones y acciones al dibujar árboles de decisión.
Esta distinción es especialmente significativa cuando las condiciones y acciones
ocurren durante un periodo y su secuencia es importante. Para este propósito, use
un nodo cuadrado para indicar una acción y un círculo para representar una
condición. El uso de notación hace al árbol de decisión más legible, como numerar
los círculos y los cuadrados secuenciales. Considere que un círculo indica IF,
mientras que un cuadrado representa THEN.

Para dibujar el árbol:

1. Identifique todas las condiciones y acciones, así como su orden y duración

(si son críticas).
2. Empiece a construir el árbol de izquierda a derecha, asegurándose de
mencionar todas las alternativas posibles antes de pasar al lado derecho.

Un árbol no tiene que ser simétrico. La mayoría de los árboles de decisión tienen
condiciones con un número diferente de ramas. También, podrían aparecer
acciones idénticas más de una vez. El árbol de decisión tiene tres ventajas
principales en comparación con una tabla de decisión:

Primero, se beneficia de la estructura secuencial de las ramas del árbol de

decisión de manera que el orden de verificación de las condiciones y de ejecución
de las acciones se aprecia de inmediato.

Segundo, las condiciones y acciones de los árboles de decisión se encuentran en

ciertas ramas pero no en otras, lo cual contrasta con las tablas de decisión, en
donde todas son parte de la misma tabla. Aquellas condiciones y acciones que
son críticas se conectan directamente a otras condiciones y acciones, mientras
que las condiciones que no son importantes están ausentes. En otras palabras, el
árbol no tiene que ser simétrico.

Tercero, en comparación con las tablas de decisión, los árboles de decisión son
entendidos con más rapidez por los miembr os de la organización. En
consecuencia, son más apropiados como herramienta de comunicación.

Selección de una Técnica de Análisis de Decisiones Estructuradas

Se han examinado las tres técnicas para el análisis de decisiones estructuradas:
Español estructurado, tablas de decisión y árboles de decisión. Aunque su uso no
debe ser exclusivo, por lo general se elige una técnica de análisis para una
decisión en lugar de usar las tres. Los siguientes lineamientos le proporcionan un
método para escoger una de las tres técnicas para un caso particular:

1. Use el Español estructurado cuando:

a. Haya muchas acciones repetitivas, O
 b. La comunicación con los usuarios finales sea importante
2. Use tablas de decisión cuando
a. Se encuentren combinaciones complejas de condiciones, acciones y
reglas, O
b. Requiera un método que evite eficazmente situaciones imposibles,
redundancias y contradicciones.
3. Use árboles de decisión cuando
a. La secuencia de condiciones y acciones sea crítica, O
b. Cuando no todas las condiciones sean relevantes para cada acción
(las ramas son diferentes).

Parte II

Diseño del Sistema

Definición
El diseño de sistemas es la evaluación de las distintas soluciones alternativas y la
especificación de una solución detallada de tipo informático. Mientras que el
análisis concentra su interés en los aspectos lógicos, el diseño trata los aspectos
físicos. Una vez obtenida las necesidades de una empresa con respecto a la
elaboración de un sistema de información mejorado, se puede planear el modo en
que funcionará dicho sistema.

El diseño podría definirse como “el proceso de aplicar distintas técnicas y

principios con el propósito de definir un dispositivo, un proceso o un sistema con
suficiente detalle como para permitir su realización física”.

Objetivo
El objetivo del diseño es producir un modelo o representación de una entidad que
se va a construir posteriormente.

El diseño es un proceso multifase en el que se sintetizan representaciones de la

estructura de datos, estructura del programa, características de la interfaz y
detalles procedimentales desde los requisitos de la información.

Características

Diseño de Datos
Es la primera de las cuatro actividades que se llevan a cabo durante la ingeniería
del software. La actividad principal del diseño de datos es seleccionar
representaciones lógicas de objetos de datos identificadas durante la fase de
definición y especificación de requisitos.

Diseño Arquitectónico
El objetivo de este, es desarrollar una estructura de programa modular y
representar las relaciones de control entre los módulos.

Diseño de la Interfaz
Se concentra en tres áreas importantes: el diseño de interfaces entre los módulos
del software, el diseño de interfaces entre el software y otros productores y
consumidores no humanos de información, y el diseño de la interfaz entre el
hombre y la computadora.

Diseño Procedimental
Se realiza después de los diseños de datos, arquitectónico y de interfaz. Los
fundamentos del diseño procedimental proponen el uso de un conjunto de
construcciones lógicas con las que se puede formar cualquier programa, estas son
la secuencia, la condición y al repetición. Estas tres construcciones son
fundamentales para la programación estructurada, una importante técnica de
diseño procedimental. El diagrama de flujo y las tablas de decisión son otras
técnicas utilizadas para el diseño procedimental.

Método del Prototipo de Sistemas

Un prototipo es un sistema que funciona, desarrollado con la finalidad de probar
ideas y suposiciones relacionadas con el nuevo sistema. Este método se
fundamenta en que los usuarios pueden señalar las características que e ls
agradaría o no tener, junto con los problemas que presenta un sistema que existe
y funciona, con mayor facilidad que si se les pidiese que las describieran en forma
teórica o por escrito.

Jeffrey L. Whitten, propone que el ciclo de vida del desarrollo de sistemas, es un

proceso por el cual los analistas de sistemas, los ingenieros de software, los
programadores y los usuarios inalesf elaboran sistemas de información y
aplicaciones informáticas. Según Whitten: “Las técnicas y metodologías del
desarrollo de sistemas pretenden servir de complemento al ciclo de vida y no
reemplazarlo”. Señala que entre las técnicas y metodologías que complementan al
ciclo de vida se encuentran:
Las Técnicas Estructuradas
Son métodos formales de división de un problema de empresa en fragmentos y
relaciones manejables, la ulterior reunión de estos fragmentos y relaciones útil
para resolver el problema. Entre estas técnicas se encuentran:
 La programación estructurada: técnica orientada a procesos para el
diseño y la escritura de programas con mayor claridad y consistencia.
 El diseño estructurado: técnica orientada a procesos utilizada para
fragmentar un programa grande en un conjunto jerarquizado de módulos y
obtener un programa más fácil de implantar y mantener.
 El análisis estructurado: técnica centrada en los procesos que se utilizan
para realizar modelos de las necesidades de usuario en un sistema.
La Modelización de Datos: técnica orientada por lo datos que representa un
sistema en función de sus datos. Independientemente de que como se procesen
dichos datos para producir información.

Técnica del Desarrollo Conjunto de Aplicaciones (DCA)

El desarrollo conjunto de aplicaciones (DCA) es una forma de trabajo altamente
estructurada que lleva a los usuarios, los directivos y los especialistas en sistemas
de información a definir y especificar conjuntamente las necesidades de los
usuarios, las opciones técnicas y los diseños externos.

Técnicas de Prototipos y Desarrollo Rápido (DRA)

El diseño de prototipos es una popular técnica de ingeniería utilizada para
desarrollar modelos a escala de un producto o de sus componentes. Implica la
creación de modelos interactivos de trabajo de un sistema o subsistema. El
desarrollo rápido de aplicaciones (DRA) es una combinación de diversas técnicas
estructuradas con técnicas de prototipos y de desarrollo conjunto de aplicaciones
cuyo fin es acelerar el desarrollo de sistemas.

Prototipos

El termino prototipo se refiere a un modelo que funciona para una aplicación de

sistemas de información. El prototipo no contiene todas las características o lleva
a cabo la totalidad de las funciones necesarias del sistema final. Más bien incluye
elementos suficientes para permitir a las personas utilizar el sistema propuesto
para determinar que les gusta, que no les gusta e identifica r aquellas
características que deben cambiarse o añadirse. El proceso de desarrollo y
empleo de un prototipo tiene cinco características:

1. El prototipo es una aplicación que funciona

2. La finalidad del prototipo es probar varias suposiciones formuladas por
analistas y usuarios con respecto a las características requeridas del
sistema
3. Los prototipos se crean con rapidez
4. Los prototipos evolucionan a través de un proceso iterativo
 5. Los prototipos tiene un costo bajo de desarrollo

El Uso de los Prototipos de Aplicaciones

El uso de prototipos de aplicaciones tiene dos usos principales. Por un lado es un

medio eficaz para aclarar los requerimientos de los usuarios. Las especificaciones
por escrito se crean, por lo egneral, como vehículos para describir las
características y requerimientos que debe satisfacer la aplicación.

El segundo uso del prototipo de aplicación es verificar la factibilidad del diseño de

un sistema. Los analistas pueden experimentar con diferentes características de la
aplicación y evaluar la reacción y respuesta por parte del usuario.
Razones Para el Empleo de Prototipos

Las razones para el uso de prototipos son resultado directo de la necesidad de

diseñar y desarrollar sistemas de información con rapidez, eficiencia y eficacia.
Existen tres elementos principales a considerar para el empleo de los prototipos:

1. Aumento de la Productividad
2. Desarrollo Planificado
3. Entusiasmo de los Usuarios con respecto a los prototipos

Aplicaciones para Candidatos

Los prototipos son más eficaces en el desarrollo de sistemas de información

cuando se cumplen ciertas condiciones. Cualquiera de las siguientes cinco
condiciones sugieren la necesidad de utilizar un prototipo:

1. No se conocen los requerimientos

2. Los requerimientos necesitan evaluarse
3. Costos altos
4. Alto riesgo
5. Nueva tecnología

Etapas del Método de Prototipos

El desarrollo de un prototipo para una aplicación se lleva a cabo en una forma

ordenada, sin importar las herramientas utilizadas, estas etapas son:

1. Identificación de requerimientos conocidos: la determinación de los

requerimientos de una aplicación es tan importante para el método de
desarrollo de prototipos como lo es para los métodos del ciclo clásico de
desarrollo de sistemas o análisis estructurado (aunque las tácticas son
diferentes). Por consiguiente, antes de crear el prototipo, los analistas y
usuarios deben trabajar juntos para identificar los requerimientos conocidos
 que tiene que satisfacerse. Para hacerlo determinan los fines para lo que
servirá el sistema y el alcance de sus capacidades.
2. Desarrollo de un modelo de trabajo: Es útil comenzar el proceso de
construcción del prototipo con el desarrollo de un plan general que permita
a las personas conocer lo que se espera de ellas y del proceso de
desarrollo. Es difícil, y en ocasiones imposibles, fijar una fecha tentativa de
terminación. La experiencia con el sistema es la que determi na
eventualmente cuando en sistema esta terminado. Para comenzar la
primera iteración, usuarios y analistas identifican de manera conjunta los
datos que son necesarios para el sistema y especifican la salida que debe
producir la aplicación. Las decisiones de diseño necesarias para desarrollar
la salida del sistema cambian muy poco en relación con las tomadas en
otros métodos de desarrollo. Sin embargo, con un prototipo, se espera que
las especificaciones iniciales estén incompletas. En el desarrollo de un
prototipo se preparan los siguientes componentes:
a. El lenguaje para el diálogo o conversación entre el usuario y el
sistema
b. Pantallas y formato para la entrada de datos
c. Módulos esenciales de procesamiento
d. Salida del sistema

Al construir el prototipo se deben seguir los estándares para datos que

emplea la organización.

En esta etapa es más importante la rapidez con que se construye el

prototipo que la eficiencia de operación. Es por esto que el analista no
intenta optimizar la velocidad de operación del sistema. Durante la
evaluación los analistas de sistemas desean capturar

3. El prototipo y el usuario: es responsabilidad del usuario trabajar con

prototipo y evaluar su característica y operación. La experiencia con el
sistema bajo condiciones permite obtener la familiaridad indispensable para
determinar los cambios o mejoras que sean necesarios así como la
eliminación de características inadecuadas o innecesarias.
4. Revisión del prototipo: información sobre los que les gusta y los que les
desagrada a los usuarios. La información obtenida tendrá influencia sobre
las características de la siguiente versión de la aplicación. Los cambios al
prototipo son planificados con los usuarios antes de llevarlos a cabo. El
analista es el responsable de realizar las modificaciones.
5. Repetición del proceso las veces que sea necesario: el proceso finaliza
cuando los usuarios y analistas están de acuerdo en que el sistema ha
evolucionado lo suficiente como para incluir todas las características
necesarias o cuando ya es evidente que no se obtendrá mayor beneficio.
6. El abandono o dejarlo como esta: cuando se verifica de que no es posible
desarrollar el sistema para satisfacer los objetivos deseados, ya sea por la
tecnología existente o por el factor económico.
Interfaz con el Usuario

Para la mayoría de las personas, la interfaz es el sistema ya sea que este bien o
poco diseñada. Esta es la representación del sistema y por consiguiente, muestra
la calidad del analista de sistemas.

Interfaz

Es la parte de una aplicación que el usuario ve y con la cual interactúa, la interfaz

incluye las pantallas, ventanas, controles, menús, la ayuda en línea, la
documentación y el entrenamiento.

Tipos De Interfaz

 Interfaces de lenguaje natural: Permiten a usuarios interactuar con la

computadora en su lenguaje cotidiano o natural.
 Interfaces de pregunta y respuesta: La computadora despliega en
pantalla una pregunta para el usuario. Para interactuar el usuario introduce
una respuesta mediante pulsaciones del teclado o un clic en el ratón.
 Interfaces de menús: Proporciona al usuario una lista en pantalla de las
selecciones disponibles, en respuesta al menú un usuario esta limitado a
las opciones desplegadas.
 Interfaces de formulario: Consiste de formulario en pantalla o formularios
que se basan en la Web, que despliegan campos que contienen datos o
parámetros que necesitan ser comunicados al usuario.
 Interfaces de lenguaje de comandos: Permite al usuario controlar la
aplicación con una serie de pulsaciones del teclado, comandos, frases, o
alguna secuencia de estos tres métodos.
 Interfaces graficas de usuarios: Permiten la manipulación directa de la
representación grafica en pantalla, la cual puede realizar con la entrada del
teclado, una palanca de juego o el ratón. La manipulación directa requiere
mayor sofisticación del sistema que las interfaces nombradas anteriormente.
 Otras interfaces de usuario: Estas interfaces incluyen dispositivos de
indicación tales como lápiz óptico, pantallas sensibles al acto, t y
reconocimiento de voz.

Lineamientos para el Diseño de Diálogos

El dialogo es la comunicación entre la computadora y una persona. Un dialogo

bien diseñado facilita a las personas usar una computadora y tener menos
frustración con el sistema de computo.
Comunicación significativa

El sistema debe presentar la información con claridad al usuario. Esto significa

tener titulo apropiado para cada pantalla, minimizar el uso de abreviaciones y
proporcionar retroalimentación útil.

Acción mínima de usuario:

 Codificar los códigos en lugar de las pantallas completas en la pantalla de

entrada.
 Introducir únicamente datos que aun no están almacenados en los archivos.
 Proporcionar caracteres de edición.
 Usar valores predeterminados para los campos en las pantallas de entrada.

Cualquier combinación de estas puede ayudar al analista a disminuir el numero de

pulsaciones requeridos por el usuario, por esa razón aumenta la entrada de datos
y minimiza los errores.

Funcionamiento normal y consistencia

El sistema debe ser consistente en su juego de pantallas en las diferentes

aplicaciones, la consistencia hace más fácil para los usuarios aprender a usar
nuevas partes del sistema una vez que están familiarizados con un componente.

Tipos De Retroalimentación

 Reconociendo la aceptación de la entrada.

 Reconocimiento de la entrada es correcta.
 Notificación que la entrada es incorrecta
 Explicando un retrazo en el procesamiento.
 Reconociendo que una petición este correcta.
 Notificación que una petición no fue completada.
 Ofreciendo a los usuarios retroalimentación más detallada.

Diseño De Comercio Electrónico

Hay dos formas estándar para diseñar lo que verán los usuarios cuando hagan clic
en el botón retroalimentación:

1. Iniciar el programa del correo electrónico del usuario con la dirección de

correo electrónico del contacto de la compañía introducido
automáticamente en el campo ENVIAR A: del mensaje.
 2. Llevar a los usuarios a una plantilla de mensaje en blanco cuando hacen
clic en retroalimentación.

Diseño De Consulta

Hay seis tipos de consulta más comunes:

1. Se dan la entidad y uno de los atributos de esta. El propósito de la consulta

es encontrar el valor.
2. El propósito de esta es encontrar una entidad o entidades cuando se dan
un atributo y un valor.
3. Esta determina que atributos satisfacen la descripción proporcionada
cuando se dan la entidad y el valor.
4. En esta los valores de todos los atributos son deseados
5. Esta es una consulta global
6. En esta se solicita una lista de los atributos para todas las entidades en
lugar de una entidad particular.

Los seis tipos de consulta son elementos esenciales para las consultas más
complejas.

Métodos De Consulta

Hay dos métodos de consulta populares:

Mediante ejemplo: Es un método simple pero poderoso para implementar las

consultas en los sistemas de bases de datos como Microsoft Access
Mediante lenguaje de consulta estructurado (SQL): Usa una serie de
palabras y comandos para seleccionar las filas y las columnas que se deben
desplegar en la tabla resultante.

Busqueda En La Web

Los motores de búsqueda son básicamente bases de datos accedidas por un

usuario para buscar información. Algunos motores de búsqueda se basan en la
intervención humana.

Lineamientos Para Buscar En La Web

 Decida si realmente quiere buscar o navegar en la Web.

 Piense en sus condiciones importantes antes de que se siente en la
computadora.
 Construya su pregunta de búsqueda lógicamente.
  Use un motor de búsqueda que guarde y recuerde sus búsquedas.
 Use un motor de búsqueda que le informe de cambios en los sitios Web.
 Recuerde que el motor de búsqueda es muy competitivo.

Diseño Modular

Diagrama Warnierr – Orr

Los diagramas de Warnier/Orr (también conocidos como construcción lógica de

programas/construcción lógica de sistemas) fueron desarrollados inicialmente en
Francia por Jean Dominique Warnier y en los Estados Unidos por Kenneth Orr.

Este método ayuda al diseño de estructuras de programas identificando la salida y

resultado del procedimiento, y entonces trabaja hacia atrás para determinar los
pasos y combinaciones de entrada necesarios para producirlos.

Los sencillos métodos gráficos usados en los diagramas de Warnier/Orr hacen

evidentes los niveles en un sistema y más claros los movimientos de los datos en
dichos niveles.

Elementos Básicos
Los diagramas de Warnier/Orr muestran los procesos y la secuencia en que se
realizan. Cada proceso se define de una manera jerárquica ; es decir, consta de
conjuntos de subprocesos que lo definen, en cada nivel, el proceso se muestra en
una llave que agrupa a sus componentes. Puesto que un proceso puede tener
muchos subprocesos distintos, un diagrama de Warnier/Orr usa un conjunto de
llaves para mostrar cada nivel del sistema.

Uso De Diagramas De Warnier/Orr

La capacidad de mostrar la relación entre procesos y pasos de un proceso no es
exclusiva de los diagramas de Warnier/Orr, así como tampoco lo es el uso de la
iteración, selección de alternativas o el tratamiento de casos individuales. Tanto
los diagramas de flujo estructurado y los métodos del español estructurado logran
eso también. Sin embargo, el enfoque que se usa para desarrollar las definiciones
de un sistema por medio de estos diagramas es distinto y se adapta y se adaptan
bien a los que se usan en el diseño de sistemas lógicos.

Para desarrollar un diagrama de Warnier/Orr , el analista trabaja hacia atrás,

empezando con la salida del sistema y usando un análisis orientado hacia la salida.
En el papel el desarrollo se mueve de izquierda a derecha. En primer lugar, se
definen la salida o resultados esperados del procedimiento. En el nivel siguiente,
mostrado mediante la inclusión por medio de una llave, se definen los pasos
necesarios para producir la salida. A su vez, cada paso se define un poco mas.
Las llaves adicionales agrupan los procesos requeridos para producir el resultado
en el siguiente nivel.

Los diagramas de Warnier/Orr ofrecen a los expertos en sistemas algunas

ventajas distintivas. Son simples en apariencia y fáciles de entender. Aun así, son
poderosas herramientas de diseño. Tienen la ventaja de mostrar agrupaciones de
procesos y los datos que deben transferirse de nivel a nivel. Además, la secuencia
del trabajo hacia atrás garantiza que el sistema estará orientado hacia el resultado.
Diagrama HIPO

Definición
HlPO es un acrónimo de Herarchy (más) Input / Process / output. El acrónimo nos
proporciona una descripción y una ayuda a la memoria de lo que refiere esta
técnica.
 Primero, es una técnica jerárquica por que el sistema completo de
programación se conforma con pequeños subsistemas, esto reduce la
complejidad, ya que cada uno de los subcomponentes puede consultarse
por separado.

 Segundo, el acrónimo nos recuerda las tres partes principales de cualquier

sistema:

Entrada, Proceso y Salida ( Input, Process y Output ).

HlPO es una técnica estructurada altamente visual para el diseño y la

documentación.

El principal beneficio de una técnica visual es la lectura e d símbolos

estandarizados, utilizados para ilustrar los diferentes tipos de entradas,
almacenamiento de datos y dispositivos de salida.

El HlPO requiere de una considerable cantidad de espacio gráfico, con el fin de

ver todo el programa completo, son necesarias varias páginas. Los diferentes
niveles de los diagramas también ocupan espacio; y en ocasiones es difícil seguir
el flujo del programa.

Existen tres tipos principales de diagramas en los sistemas HIPO:

1. VTOC o tabla visual de contenido (visual table of contents) por sus siglas en
inglés.
2. Diagramas generales IPO ( input / Process I output ).
3. Diagramas detallados IPO.

El VTOC ( Visual Table of contents)

El VTOC es el diagrama de jerarquías. Proporciona un mapa que permite localizar
un módulo del programa dentro del sistema principal.

Los números de cada uno de los cuadros siguen un patrón, de tal forma que es
fácil localizar las relaciones existentes entre dos módulos.

El diagrama jerárquico del VTOC parece ser similar a un típico diagrama de la

estructura de una organización.
Diagrama General IPO
Estos tipos de diagramas en el sistema HIPO permiten una visión global de la
entrada, el proceso y la salida. Es útil listar todas las entradas, los procesos y
salidas en las tres secciones de papel, a la izquierda la entrada, al centro el
proceso y a la derecha la salida.
Diagrama detallado IPO
Los diagramas generales deben descomponerse en cada uno de los módulos
autocontenidos en él, en este punto sí conviene utilizar símbolos para los
elementos de entrada y de salida.
Casos Prácticos

Lenguaje (Español) Estructurado

A continuación se muestra la utilización de la técnica del lenguaje estructurado,

español para la demostración, para simular el análisis del proceso de pedidos de
mercancía de un almacén. Utilizamos MAYÚSCULAS MÁS NEGRITAS para las
palabras reservadas, MAYÚSCULAS MÁS CURSIVA para los almacenes o
archivos y normal para las operaciones o cálculos. También se muestra la
utilización de la identación para mayor claridad del código.

Gran-total=0

HACER-MIENTRAS haya mas pedidos que procesar

Total_de_pedidos = 0

LEER el siguiente pedido de PEDIDOS

HACER-MIENTRAS haya mas artículos en el pedido

Total_de_pedidos = Total_de_pedidos + numero_de_articulos

FIN HACER

MOSTRAR numero_de_pedido, Total_de_pedidos

Gran_total = gran_total + total_de_pedidos

FIN HACER

MOSTRAR gran_total

Tablas de Decisión

Procederemos a realizar una tabla de decisión para determinar los posibles

valores en la administración de tres tipos de medicinas a un paciente teniendo en
cuenta la edad, el sexo y el peso y las restricciones que para su administración
hemos obtenido en el levantamiento de información. Existen 3 variables con
valores binarios (si/no, verdadero/falso, masculino/femenino), por lo tanto
n
aplicando la regla 2 , donde n es igual al numero de variables, obtenemos 23=8.
 1 2 3 4 5 6 7 8
Edad >21 Y Y Y Y N N N N
Sexo M M F F M M F F
Peso >100 Y N Y N Y N Y N
Medicamento X X X
1
Medicamento X X
2
Medicamento X X X
3
Ningún X X
Medicamento

Árboles de Decisión

Siguiendo con el ejemplo anterior, ahora debemos determinar si se le debe o no administrar

un medicamento a un paciente según las siguientes reglas:

Se le administrara un medicamento X al paciente si:

1. Tiene presión alta, su azúcar en la sangre es alto, es alérgico a antibióticos y NO
tiene otras alergias.
2. Tiene presión alta, su azúcar en la sangre es alto y NO es alérgico a los antibióticos.
3. Tiene presión arterial alta y su azúcar en la sangre es bajo.
4. Tiene presión arterial media y su índice de colesterol es bajo.
5. Tiene presión arterial baja

No se le administrara el medicamento X si:

1. Tiene presión arterial alta, su azúcar en la sangre es bajo, es alérgico a los
antibióticos y SI tiene otras alergias.
2. Tiene presión arterial media y su índice de colesterol es alto.

SI

SI
Bajo
Baja

¿Colesterol? NO
Media Alto

¿Presion SI
Bajo
Arterial?
SI
¿Azúcar en Sangre? No

Alto ¿Alergia Antibióticos?

No SI
Si
¿Otras Alergias?
Si
NO
Diseño de Sistema

Para el siguiente caso práctico daremos por sentado que ya xeiste un

levantamiento de información sobre los requerimientos del Departamento de
Adiestramiento de la Compañía Acme se y detectó la necesidad de hacer un
registro de los trabajadores y de los cursos realizados y para los cuales serán
postulados.

Diseño de Datos
Se definen las siguientes tablas de datos que conformarán la estructura de la base
de datos de Recursos Humanos - Adiestramiento:

Hemos definido un diagrama de Entidad –Relación en el cual se muestran las

distintas entidades y sus atributos, del mismo modo se aprecian las relaciones
indicando la cardinalidad correspondiente:

Partiendo de este E-R procedemos al diseño de las distinta tablas:

 Tabla de Empleados

Tabla de Área

Tabla Asistencia_Eventos

Tabla Cargo

Tabla Cursos
 Tabla Instituciones

Tabla Dirección

Tabla Eventos

Tabla Instrucción

Tabla Plan _ ejecutado

Tabla Plan _ propuesto

Tabla Profesión

Tabla Tipo _ empleado

Tabla Tipo _ trabajador

 Tabla Tracks

Diseño de Arquitectónico

A continuación se muestra la definición estructural del sistema propuesto:

Diseño de Interfaz
Una vez realizados los pasos anteriores procedemos a definir el diseño de las
entradas y salidas del sistema. Hemos propuesto el desarrollo de unas interfaces
graficas de usuario (GUI por sus siglas en ingles):
 Menu Principal

Registro de datos

Luego de establecer el diseño procedimental, validamos los modelos y

procedemos a realizar un prototipo.
Conclusión

Se han aplicado las técnicas de análisis estructurado de sistemas siguiendo la

metodología del uso de Lenguaje Estructurado (Español), Tablas de Decisión y
Arboles de Decisión, posteriormente pasamos a la fase de Diseño Estructurado de
Sistemas, comenzando con el Diseño de Datos demostrando su aplicabilidad con
la propuesta de estructuras de tablas y diagrama de Entidad-Relación. Se muestra
como el Diseño Estructural nos brinda una imagen de la funcionalidad del sistema
propuesto. El Diseño de Interfaz de Usuario permite refinar la imagen que tenemos
del sistema puesto que vamos a un detalle más profundo puesto que incluimos la
interacción con el usuario. Por último procedemos a realizar un prototipo que nos
permitirá evaluar la funcionalidad real del sistema y su aceptación por parte del
usuario.