ESPECIFICACIONES

DE
LOS
PROCESOS
Y
DECISIONES
ESTRUCTURADAS
GENERALIDADES DE LAS ESPECIFICACIONES DE LOS PROCESOS
Para determinar los requerimientos humanos de informacin de una
estrategia de anlisis de decisiones, el analista de sistemas debe
primero determinar los objetivos de los usuarios junto con los
objetivos de la organizacin, ya sea mediante el uso de una
metodologa arriba-abajo o una metodologa orientada a objetos. El
analista de sistemas debe comprender los principios de las
organizaciones, adems de contar con un conocimiento prctico sobre
las tcnicas de recopilacin de datos. La metodologa arriba-abajo es
imprescindible, ya que todas las decisiones humanas en la
organizacin deben estar relacionadas, al menos en forma indirecta,
con los objetivos generales de toda la organizacin. Las especificaciones
de los procesos (a las que algunas veces se les denomina
Mini- especificaciones
, debido a que son una pequea parte de las especificaciones totales del proyecto) se crean
para procesos primitivos en un flujo de diagrama de datos, as como para
algunos procesos de nivel ms alto que se expanden en un diagrama hijo.
Tambin se pueden crear para los mtodos de clases en el diseo orientado a
objetos y, en un sentido ms general, para los pasos en un caso de uso (como se ve en los
captulos 2 y 10). Estas especificaciones explican la lgica de la toma de decisiones y las
frmulas que transformarn la entrada del proceso en su salida. Cada elemento
derivado debe tener lgica de proceso para mostrar cmo se produce desde los
elementos base u otros elementos derivados creados con anterioridad que
acten como entrada para el proceso primitivo.
Los tres objetivos al producir especificaciones de procesos son:
1.
Reducir la ambigedad del proceso. Este objetivo obliga al analista a
aprender los detalles acerca de la forma en que trabaja el proceso.
Hay que detectar las reas imprecisas, anotarlas y consolidarlas para
todas las especificaciones de los procesos. Estas observaciones
forman una base y proveen las preguntas para las entrevistas de
seguimiento con la comunidad de usuarios.
2.
Obtener una descripcin precisa de lo que se va a lograr, que por lo
general se incluye en un paquete de especificaciones para el
programador.
3.
Validar el sistema de diseo. Este objetivo incluye asegurar que un
proceso tenga todo el flujo de datos de entrada necesario para
producir la salida. Adems, todas las entradas y salidas se deben
representar en el diagrama de flujo de datos.
Las categoras o procesos que por lo general
no
requieren especificaciones son:
1.
Procesos que representan entrada o salida fsica, como lectura y
escritura. Por lo general estos procesos requieren slo una lgica
simple.

2.
Procesos que representan una validacin de datos simple, lo cual por
lo general es bastante fcil de lograr. Los criterios de edicin se
incluyen en el diccionario de datos y se incorporan en el cdigo
fuente de computadora. Se pueden producir especificaciones de
procesos para una edicin compleja.
3.
Procesos que utilizan cdigo escrito con anterioridad. Comnmente
estos procesos se incluyen en un sistema como procedimientos,
mtodos y funciones, o en bibliotecas de clases (que se pueden
comprar o estn disponibles en forma gratuita a travs de Web).Estos
bloques son cdigo de programa de computadora que se almacena en
el sistema computarizado. Por lo general realizan una funcin general
del sistema, como validar una fecha o un dgito de verificacin.
Formato de especificacin de proceso
Las especificaciones de procesos vinculan a un proceso con el
diagrama de flujo de datos y tambin con el diccionario de datos,
como se muestra en la figura 9.1. Cada especificacin de proceso se
debe introducir en un formulario separado o en la pantalla de una
herramienta CASE, como la que se usa para Visible Analyst y se
muestra en el caso de la CPU al final de este captulo. Debe introducir
la siguiente informacin:
1. El nmero del proceso, que debe coincidir con el ID del proceso del
diagrama de flujo de datos. Esta especificacin permite a un analista
trabajar en cualquier proceso o revisarlo, adems de que puede
localizar con facilidad el diagrama de flujo de datos que contiene el
proceso.
2. El nombre del proceso, que adems debe ser el mismo que el
nombre mostrado en el smbolo del proceso en el diagrama de flujo
de datos.
3. Una descripcin breve de lo que logra el proceso.
4. Una lista de flujos de datos de entrada, que utilice los nombres
que se encuentran en el diagrama de flujo de datos. Los nombres de
los datos utilizados en la frmula o lgica deben coincidir con los del
diccionario de datos para asegurar la consistencia y la buena
comunicacin.
5. Los flujos de datos de salida, que tambin utilicen los nombres del
diagrama de flujo de datos y del diccionario de datos.
6. Una indicacin del tipo de proceso: por lotes, en lnea o manual.
Todos los procesos en lnea requieren diseos de pantallas y todos los
procesos manuales deben tener procedimientos bien definidos para
los empleados que realizan las tareas del proceso.
7. Si el proceso utiliza cdigo escrito con anterioridad, incluya el
nombre del subprograma o funcin que contiene ese cdigo.
8. Una descripcin de la lgica del proceso que establece la poltica y
las reglas de negocios en lenguaje cotidiano, no en lenguaje de
seudocdigo de computadora. Las reglas de negocios son los
procedimientos, o tal vez un conjunto de condiciones o frmulas, que
permiten a una empresa operar su negocio. La definicin anticipada
del problema (como vimos en el captulo 3) que usted complet en un

principio puede proveer un punto de inicio para esta descripcin. Los

formatos de las reglas de negocios comunes son:

Definiciones de los trminos de negocios.

Condiciones y acciones de negocios

Restricciones de integridad de los datos.

Derivaciones matemticas y funcionales.

Inferencias lgicas.

Secuencias de procesamiento.
Relaciones entre los hechos acerca de la empresa.
9. Si no hay suficiente espacio en el formulario para una descripcin
completa en espaol estructurado, o si hay una tabla o rbol de
decisin que describa la lgica, incluya el nombre de la tabla o
rbol correspondiente.

10.Haga una lista de todos los problemas sin resolver, las porciones
incompletas de lgica o cualquier otra cuestin relacionada. Estas
cuestiones forman la base de las preguntas utilizadas para las
entrevistas de seguimiento con los usuarios o expertos de
negocios que usted agreg a su equipo del proyecto
ESPAOL ESTRUCTURADO
Cuando la lgica del proceso involucra frmulas o iteraciones, o cuando las
decisiones estructuradas no son complejas, una tcnica apropiada para
analizar el proceso de decisin es el uso del espaol estructurado. Como su
nombre indica, el espaol estructurado se basa en 1) la lgica estructurada,
o las instrucciones organizadas en procedimientos anidados y agrupados, y
2) las instrucciones en espaol simple tales como sumar, multiplicar y
mover. Un problema escrito se puede transformar en espaol estructurado
si ponemos las reglas de decisin en su secuencia apropiada y usamos la
convencin de las instrucciones IF-THEN-ELSE a lo largo del proceso.

Cmo escribir espaol estructurado

Para escribir espaol estructurado es conveniente utilizar las siguientes
convenciones:
1. Expresar toda la lgica en trminos de uno de estos cuatro tipos:
estructuras secuenciales, estructuras de decisin, estructuras de
casos o iteraciones.
2. Usar y poner en maysculas las palabras clave aceptadas como IF,
THEN, ELSE, DO, DO WHILE, DO UNTIL y PERFORM.
3. 3.
4. Aplicar sangra a los bloques de instrucciones para mostrar su
jerarqua (anidamiento) con claridad.
5. 4.

6. Cuando haya palabras o frases definidas en un diccionario de datos

(como en el captulo 8), subraye esas palabras o frases para indicar
que tienen un significado especializado y reservado.
7. 5.
8. Tenga cuidado al usar y y o, y evite la confusin al diferenciar
entre mayor que y menor o igual que y con las relaciones de
igualdad. A y B significa tanto A como B; A o B significa que
puede ser A o B, pero no ambas. Aclare las instrucciones lgicas
ahora, en vez de esperar hasta la etapa de codificacin del programa.
Diccionario de datos y especificaciones de procesos
Todos los programas de computadora se pueden codificar mediante el uso
de tres construcciones bsicas: secuen-cia, seleccin (IFTHENELSE y la
estructura de caso), e iteracin o ciclo. El diccionario de datos indica cules
de estas construcciones se deben incluir en las especificaciones de los
procesos.Si el diccionario de datos para el flujo de datos de entrada y salida
contiene una serie de campos sin ninguna iteracin { } o seleccin [ ]
, la especificacin de proceso contendr una secuencia simple de instrucciones, como MOVER, SUMAR y RESTAR. Consulte el ejemplo de un
diccionario de datos para el ESTADO DE CUENTA DE ENVO
Cabe mencionar que el diccionario de datos para el ESTADO DE CUENTA DE
ENVO tiene los elementos NMERO DE PEDIDO, FECHA DEL PEDIDO y numero de
cliente como simples campos secuenciales

Desarrollar tablas de decisin

Para construir tablas de decisin, el analista necesita determinar el tamao
mximo de la tabla; eliminar cual-quier situacin imposible, inconsistencia o
redundancia, y simplificar la tabla lo ms que pueda. Los siguientes pasos
proveen al analista un mtodo esquemtico para desarrollar tablas de
decisin:
1.
Determinar el nmero de condiciones que pueden afectar la decisin.
Combinar filas que se traslapan, como las condiciones mutuamente
excluyentes. El nmero de condiciones se convierte en el nmero de filas en
la mitad superior de la tabla de decisin.
Determinar el nmero de acciones posibles que se pueden realizar. Ese
nmero se convierte en el nmero de filas en la mitad inferior de la tabla de
decisin.
3. Determinar el nmero de alternativas de condiciones para cada
condicin. En la forma ms simple de la tabla de decisin, habra dos
alternativas (Y o N) para cada condicin. En una tabla con entradas
extendidas, podra haber muchas alternativas para cada condicin.
Asegrese de incluir todos los valores posibles para la condicin. Por
ejemplo, si el enunciado de un problema que calcule el descuento de un

cliente menciona un rango de valores para un total del pedido de $100 a

$1,000 y otro rango de ms de $1,000, el analista debe tener en cuenta que
tambin debe agregar el rango de 0 a $100 como una condicin. Esto es
cierto sobre todo cuando hay otras condiciones que se pueden aplicar al
total de pedido de 0 a $100.
4. Calcular el nmero mximo de columnas en la tabla de decisin, para lo
cual hay que multiplicar el nmero de alternativas para cada condicin. Si hubiera
cuatro condiciones y dos alternativas (Y o N) para cada una de las condiciones,
habra 16 posibilidades, como se muestra a continuacin: Condicin 1:
x
2 alternativas Condicin 2:
x
2 alternativas Condicin 3:
x
2 alternativas Condicin 4:
x
2 alternativas
16 posibilidades
Llenar las alternativas de condiciones. Empezar con la primera condicin y
dividir el nmero de columnas entre el nmero de alternativas para esa
condicin.
Para completar la tabla, inserte una X donde las reglas sugieran ciertas
acciones.

Combine las reglas en las que sea aparente que una alternativa no
marca una diferencia en el resultado.
Revise cualquier situacin imposible, contradiccin o redundancia en
la tabla. Abundaremos sobre esto posteriormente.
Vuelva a ordenar las condiciones y acciones (o incluso las reglas) si
esto le ayuda a comprender mejor la tabla de decisin
Verificar la integridad y precisin
Es esencial que verifique la integridad y precisin de sus tablas de
decisin. Pueden ocurrir cuatro problemas principales al desarrollar
tablas de decisin: que estn incompletas, que existan situaciones
imposibles, contra-dicciones y redundancia. Es de suma importancia
poder asegurar que todas las condiciones, alternativas de condiciones,
acciones y re-glas de accin estn completas. Suponga que omitimos una
condicin importante
Al construir tablas de decisin segn lo indicado en los pasos
anteriores, algunas veces podemos llegar a es.
Las tablas de decisin son una importante herramienta en el anlisis
de las decisiones estructuradas. Una ventaja importante de usar
tablas de decisin en comparacin con otros
mtodos es que las tablas ayudan al ana-lista a asegurar la
integridad.tablecer situaciones imposibles. Al usar tablas de decisin
tambin se facilita la accin de verificar posibles errores, como las
situaciones imposibles, contradicciones y redundancia. Tambin

existen los procesadores de tablas de decisin, que reciben la tabla

como entrada y proveen cdigo de programa de computadora como
salida.
RBOLES DE DECISIN
Los rboles de decisin se utilizan cuando ocurren
ramifi caciones complejas en un proceso de decisin estructurado.
Los
rboles
tambin
son
tiles
cuando
es
imprescindible mantener una cadena de decisiones en una
secuencia especfi ca. Aunque el nombre rbol de decisin se
deriva de los rboles naturales, por lo general los rboles de
decisin se dibujan de lado, con la raz en el lado izquierdo del
papel; a partir de ah el rbol se ramifi ca hacia la derecha.
Esta orientacin permite al analista escribir en las ramas para
describir las con-diciones y acciones. A diferencia del rbol de
decisin que se utiliza en la ciencia de la administracin, el rbol del
analista no contiene probabilidades y resultados. En el anlisis de
sistemas, los rboles se utilizan principalmente para iden-tificar y
organizar las condiciones y acciones en un proceso de decisin
completamente estructuradoibujar rboles de decisin
Es conveniente poder diferenciar entre las condiciones y las acciones
al momento de dibujar rboles de decisin. Esta distincin es en
especial relevante cuando las condiciones y acciones se llevan a cabo
durante un periodo de tiempo y su secuencia es importante.
Al dibujar el rbol hay que:
1.
Identificar todas las condiciones y acciones, junto con su orden y
sincronizacin (si son crticas).
2.
Empezar a construir el rbol de izquierda a derecha; hay que
asegurarnos de enlistar todas las alternativas posibles antes de
avanzar a la derecha.El rbol simple es simtrico y las cuatro
acciones al final son nicas, aunque un rbol no tiene que ser
simtrico. La mayora de los rboles de decisin tienen condiciones
con un nmero distinto de ramificaciones. Adems pueden aparecer
acciones idnticas ms de una vez
El rbol de decisin tiene tres principales ventajas sobre una tabla de
decisin. En primer lugar saca prove-cho de la estructura secuencial
de sus ramas, por lo que se puede observar de inmediato el orden de
verificacin de las condiciones y ejecucin de las acciones. En
segundo lugar, podemos encontrar condiciones y acciones de los
rboles de decisin en algunas ramas pero no en otras, lo cual
contrasta con las tablas de decisin, donde to-das forman parte de la
misma tabla.

CMO ELEGIR UNA TCNICA DE ANLISIS DE DECISIONES

ESTRUCTURADAS
Ya examinamos las tres tcnicas de anlisis de decisiones
estructuradas: espaol estructurado, tablas de decisin y rboles de
decisin. Aunque no es necesario utilizarlas en forma exclusiva, es
costumbre elegir una tcnica de anlisis para una decisin en vez de
emplear las tres. Los siguientes lineamientos le proveern una manera de
elegir una de las tres tcnicas para un caso especfico:
1. Use espaol estructurado cuando a. Haya muchas acciones
repetitivas, O b. La comunicacin con los usuarios finales sea
importante.
2. Use tablas de decisin cuando a. Se encuentre con combinaciones
complejas de condiciones, acciones y reglas, O b. Requiera un mtodo
que evite de manera efectiva las situaciones imposibles,
redundancias y contradicciones.
3. Use los rboles de decisin cuando a. La secuencia de condiciones
y acciones sea crtica, O b. No todas las condiciones sean relevantes
para todas las acciones (que las ramificaciones sean distintas).
Resumen

Una vez que el analista trabaja con los usuarios para identificar los flujos de
datos y empieza a construir un diccionario de datos, es tiempo de pasar a la
especificacin de procesos y el anlisis de decisiones. Los tres mtodos para el
anlisis de decisiones y para describir la lgica de procesos que vimos en este
captulo son espaol estructurado, tablas de decisin y rboles de decisin.Las
especificaciones (o mini-especificaciones) de procesos se crean para
los procesos primitivos en un diagrama de flujo de datos, as como
para algunos procesos de nivel ms alto que se expanden en un
diagrama hijo. Estas especificaciones explican la lgica de toma de
decisiones y las frmulas que transformarn los datos de entrada de
un proceso en su salida. Los tres objetivos de la especificacin de
procesos son reducir la ambigedad del proceso, obtener una
descripcin precisa de lo que se logra y validar el diseo del
sistema.Una manera de describir las decisiones estructuradas es me-diante el
mtodo que se conoce como espaol estructurado, en el cual la lgica se
expresa en estructuras secuenciales, estruc-turas de decisin, estructuras de
casos o iteraciones. El espaol estructurado utiliza palabras clave aceptadas
tales como SI (IF), ENTONCES (THEN), SINO (ELSE), HACER (DO), HACER MIENTRAS (DO
WHILE) y HACER HASTA (DO UNTIL) para describir la lgica utilizada; adems hace uso de la
sangra para indicar la estructura jerrquica del proceso de decisin.Las tablas de
decisin son otra forma de examinar, describir y documentar las decisiones. Se
utilizan cuatro cuadrantes (que se ven en sentido de las manecillas del reloj, a
partir de la esquina superior izquierda) para: 1) describir las condiciones, 2) identificar las
posibles alternativas de decisin (como Y o N), 3) indicar qu acciones se deben

realizar y 4) describir las acciones. Las tablas de decisin son ventajosas ya que
las reglas para desarrollar la tabla en s, adems de las reglas para eliminar
redundancia, con-tradicciones y situaciones imposibles, son simples y
manejables. Al usar tablas de decisin se fomenta la integridad y precisin en el
anlisis de las decisiones estructuradas.El tercer mtodo para el anlisis
de decisiones es el rbol de decisin, que consiste en nodos (un
cuadrado para las accio-nes y un crculo para las condiciones) y
ramificaciones. Los r-boles de decisin son apropiados cuando las
acciones se deben llevar a cabo en cierta secuencia. No hay ningn
requerimiento de que el rbol sea simtrico, por lo que slo las
condiciones y acciones que sean crticas para las decisiones en
cuestin son las que se encuentran en una rama especfica.Cada uno
de los mtodos de anlisis de decisiones tiene sus propias ventajas y
se debe utilizar de manera acorde. El es-paol estructurado es muy
til cuando se repiten muchas accio-nes y cuando es importante
comunicarse con otros. Las tablas de decisin proveen un anlisis
completo de las situaciones complejas, al tiempo que limitan la
necesidad de cambio que se atribuye a las situaciones imposibles,
redundancias o contra-dicciones. Los rboles de decisin son
importantes cuando es imprescindible la secuencia apropiada de las
condiciones y ac-ciones, y cuando cada una de las condiciones no son
relevantes para cada una de las acciones