Especificaciones de los procesos y decisiones estructuradas · PDF fileLas especificaciones de...

259

C A P Í T U L O 9

Especificaciones de los procesos y decisiones estructuradas

OBJETIVOS DE APRENDIZAJE Al completar este capítulo usted podrá:

1. Comprender el propósito de las especificaciones de los procesos.

2. Reconocer la diferencia entre las decisiones estructuradas y las semiestructuradas.

3. Usar español estructurado, tablas y árboles de decisión para analizar, describir y documentar las decisiones estructuradas.

4. Elegir un método apropiado para analizar las decisiones estructuradas y crear especificaciones de los procesos.

El analista de sistemas que se enfoca en las especificaciones de los procesos y las decisiones estructuradas tiene muchas opciones para documentarlas y analizarlas. En los capítulos 7 y 8 vimos procesos como VERIFICAR Y CALCU-LAR CUOTAS, pero no explicamos la lógica necesaria para ejecutar estas tareas. Los métodos disponibles para documentar y analizar la lógica de las decisiones incluyen español estructurado, tablas y árboles de decisión. Es

importante ser capaces de reconocer las decisiones lógicas y estructuradas que ocurren en una empresa y cómo podemos diferenciarlas de las decisiones semiestructuradas que tienden a involucrar el juicio humano. Así, es imprescindible reconocer que las decisiones estructuradas se prestan particularmente bien al análisis con métodos sistemáticos que promueven la integridad, precisión y comunicación.

GENERALIDADES DE LAS ESPECIFICACIONES DE LOS PROCESOSPara determinar los requerimientos humanos de información de una estrategia de análisis de

decisiones, el analista de sistemas debe primero determinar los objetivos de los usuarios junto

con los objetivos de la organización, ya sea mediante el uso de una metodología arriba-abajo

o una metodología orientada a objetos. El analista de sistemas debe comprender los principios

de las organizaciones, además de contar con un conocimiento práctico sobre las técnicas de

recopilación de datos. La metodología arriba-abajo es imprescindible, ya que todas las decisio-

nes humanas en la organización deben estar relacionadas, al menos en forma indirecta, con los

objetivos generales de toda la organización.

Las especificaciones de los procesos (a las que algunas veces se les denomina mini-especifi-caciones, debido a que son una pequeña 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 ni-

vel más alto que se expanden en un diagrama hijo. También se pueden crear para los métodos de

clases en el diseño orientado a objetos y, en un sentido más general, para los pasos en un caso de uso

(como se ve en los capítulos 2 y 10). Estas especificaciones explican la lógica de la toma de decisio-

nes y las fórmulas que transformarán la entrada del proceso en su salida. Cada elemento derivado

debe tener lógica de proceso para mostrar cómo se produce desde los elementos base u otros ele-

mentos derivados creados con anterioridad que actúen como entrada para el proceso primitivo.

260 PARTE III • EL PROCESO DE ANÁLISIS

Los tres objetivos al producir especificaciones de procesos son:

1. Reducir la ambigüedad 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 descripción 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 diseño. Este objetivo incluye asegurar que un proceso tenga todo el flujo de datos de

entrada necesario para producir la salida. Además, todas las entradas y salidas se deben representar en el

diagrama de flujo de datos.

Usted se encontrará con muchas situaciones en las que no se hayan creado las especificaciones de los proce-

sos. Algunas veces el proceso es muy simple o ya existe el código de computadora. Hay que tomar nota de esta

eventualidad en la descripción del proceso y no se requiere ningún diseño adicional. Las categorías o procesos

que por lo general no requieren especificaciones son:

1. Procesos que representan entrada o salida física, como lectura y escritura. Por lo general estos procesos

requieren sólo una lógica simple.

2. Procesos que representan una validación de datos simple, lo cual por lo general es bastante fácil de lograr.

Los criterios de edición se incluyen en el diccionario de datos y se incorporan en el código fuente de

computadora. Se pueden producir especificaciones de procesos para una edición compleja.

3. Procesos que utilizan código escrito con anterioridad. Comúnmente estos procesos se incluyen en un sistema

como procedimientos, métodos y funciones, o en bibliotecas de clases (que se pueden comprar o están

disponibles en forma gratuita a través de Web).

Estos bloques son código de programa de computadora que se almacena en el sistema computarizado. Por

lo general realizan una función general del sistema, como validar una fecha o un dígito de verificación. Estos

subprogramas de propósito general se escriben y documentan sólo una vez, pero forman una serie de bloques

de construcción que se pueden usar en muchos sistemas en toda la organización. Por ende, estos subprogramas

aparecen como procesos en muchos diagramas de flujo de datos (o como métodos de clases, lo cual veremos en

el capítulo 10).

Formato de especificación de procesoLas especificaciones de procesos vinculan a un proceso con el diagrama de flujo de datos y también con el

diccionario de datos, como se muestra en la figura 9.1. Cada especificación 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 capítulo. Debe introducir la siguiente información:

1. El número del proceso, que debe coincidir con el ID del proceso del diagrama de flujo de datos. Esta

especificación permite a un analista trabajar en cualquier proceso o revisarlo, además de que puede localizar

con facilidad el diagrama de flujo de datos que contiene el proceso.

2. El nombre del proceso, que además debe ser el mismo que el nombre mostrado en el símbolo del proceso en

el diagrama de flujo de datos.

3. Una descripción 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 fórmula o lógica deben coincidir con los del diccionario de

datos para asegurar la consistencia y la buena comunicación.

5. Los flujos de datos de salida, que también utilicen los nombres del diagrama de flujo de datos y del

diccionario de datos.

6. Una indicación del tipo de proceso: por lotes, en línea o manual. Todos los procesos en línea requieren

diseños 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 código escrito con anterioridad, incluya el nombre del subprograma o función que

contiene ese código.

8. Una descripción de la lógica del proceso que establece la política y las reglas de negocios en lenguaje

cotidiano, no en lenguaje de seudocódigo de computadora. Las reglas de negocios son los procedimientos, o

tal vez un conjunto de condiciones o fórmulas, que permiten a una empresa operar su negocio. La definición

anticipada del problema (como vimos en el capítulo 3) que usted completó en un principio puede proveer un

punto de inicio para esta descripción. Los formatos de las reglas de negocios comunes son:

• Definiciones de los términos de negocios.

• Condiciones y acciones de negocios.

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 261

• Restricciones de integridad de los datos.

• Derivaciones matemáticas y funcionales.

• Inferencias lógicas.

• Secuencias de procesamiento.

• Relaciones entre los hechos acerca de la empresa.

9. Si no hay suficiente espacio en el formulario para una descripción completa en español estructurado, o si

hay una tabla o árbol de decisión que describa la lógica, incluya el nombre de la tabla o árbol

correspondiente.

10. Haga una lista de todos los problemas sin resolver, las porciones incompletas de lógica o cualquier otra

cuestión 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.

Hay que introducir estos elementos para completar un formulario de especificación de proceso, el cual incluye

el número del proceso, su nombre o ambos elementos del diagrama de flujo de datos, así como los otros ocho

elementos que se muestran en el ejemplo de World’s Trend (figura 9.2). Cabe mencionar que si completamos este

formulario con el mayor detalle posible, será más fácil vincular el proceso con el diagrama de flujo de datos y el


ESPAÑOL ESTRUCTURADOCuando la lógica del proceso involucra fórmulas o iteraciones, o cuando las decisiones estructuradas no son

complejas, una técnica apropiada para analizar el proceso de decisión es el uso del español estructurado. Como

su nombre indica, el español estructurado se basa en 1) la lógica estructurada, o las instrucciones organizadas en

procedimientos anidados y agrupados, y 2) las instrucciones en español simple tales como sumar, multiplicar y

mover. Un problema escrito se puede transformar en español estructurado si ponemos las reglas de decisión en su

secuencia apropiada y usamos la convención de las instrucciones IF-THEN-ELSE a lo largo del proceso.

Cómo escribir español estructuradoPara escribir español estructurado es conveniente utilizar las siguientes convenciones:

1. Expresar toda la lógica en términos de uno de estos cuatro tipos: estructuras secuenciales, estructuras de

decisión, estructuras de casos o iteraciones (en la figura 9.3 podrá ver ejemplos).

Formulario deespecificación

de proceso

Árbol dedecisión

X

P

Q

T

20 40

5010

30

Proceso

Diagrama de flujo de datos Especificación y lógica de proceso

Españolestructurado

Tabla dedecisión

Reglas2' 3' 4'1'

YY Y YX

XX

N

N

I F c o n s t r u c c i ó nT H E N d e d u cE N D I F

I F r e e m p l a z oT H E N s u m a r 1E N D I F

I F p r o p i e t a r i o e l i g i óT H E N s u m a r 1E N D I F

FIGURA 9.1 Cómo se relacionan las

especificaciones de los procesos

con el diagrama de flujo de datos.


Formulario de especificación de proceso

NúmeroNombreDescripción

Flujo de datos de entrada

Flujo de datos de salida

Tipo de procesoEn línea Por lotes Manual

Nombre de subprograma/funciónLógica del proceso

Referir a: Nombre:Español estructurado Tabla de decisión Árbol de decisiónCuestiones sin resolver:

1.3Determinar cantidad disponibleDeterminar si un artículo está disponible para su venta. Si no está disponible,

crear un registro de artículo pendiente. Determinar la cantidad disponible.

Artículo válido del proceso 1.2Cantidad disponible del registro del artículo

Artículo disponible (Número de artículo + Cantidad vendida) para los procesos 1.4 y 1.5Artículo pendiente a control de inventario

IF la Cantidad artículo pedido es mayor que Cantidad disponible THEN Mover Cantidad artículo pedido a Cantidad disponible artículo Mover Número artículo pedido a Número artículo disponibleELSE Restar Cantidad disponible de Cantidad artículo pedido para producir Cantidad pendiente Mover Cantidad pendiente a Registro artículos pendientes Mover Número artículo a Registro artículos pendientes DO escribir Registro pendiente Mover Cantidad disponible a Cantidad disponible artículo Mover Número artículo pedido to Número artículo disponibleENDIF

¿Habrá que tomar en cuenta la cantidad que está en el pedido para este artículo? Si combinamos esto con la fecha esperada de la llegada de los artículos en el pedido,¿cambiaría la forma en que se calcula la cantidad?

FIGURA 9.2 Un ejemplo de formulario de especificación de proceso

completado para determinar si un artículo está disponible.

2. Usar y poner en mayúsculas las palabras clave aceptadas como IF, THEN, ELSE, DO, DO WHILE, DO

UNTIL y PERFORM.

3. Aplicar sangría a los bloques de instrucciones para mostrar su jerarquía (anidamiento) con claridad.

4. Cuando haya palabras o frases definidas en un diccionario de datos (como en el capítulo 8), subraye esas

palabras o frases para indicar que tienen un significado especializado y reservado.

5. Tenga cuidado al usar “y” y “o”, y evite la confusión 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 lógicas ahora, en vez de esperar hasta la etapa de codificación del

programa.


Tipo de español estructurado

Estructura secuencial Un bloque de instrucciones en las que no ocurre bifurcación

Acción #1Acción #2Acción #3

IF condición A es verdadera THEN implementar Acción AELSE implementar Acción BENDIF

IF Caso # 1 implementar Acción #1ELSE IF Caso #2 Implementar Acción #2ELSE IF Caso #3 Implementar Acción #3ELSE IF Caso #4 Implementar Acción #4ENDIF

Estructura de decisión Sólo SI (IF) una condición es verdadera, completar las siguientes instrucciones; en caso contrario, ir al ELSE

Estructura de caso Un tipo especial de estructura de decisión en la que los casos son mutuamente excluyentes (si ocurre uno, los otros no pueden ocurrir)

Iteración Bloques de instrucciones que se repiten hasta terminar

DO WHILE haya clientes.Acción #1ENDDO

Ejemplo FIGURA 9.3 Ejemplos de la lógica expresada

en una estructura secuencial, una

estructura de decisión, una

estructura de caso y una iteración.

UN EJEMPLO DE ESPAÑOL ESTRUCTURADO El siguiente ejemplo demuestra cómo se transforma un procedimiento

hablado para procesar reclamaciones médicas en español estructurado:

Procesamos todas nuestras reclamaciones de esta forma. Primero determinamos si el solicitante ha

presentado alguna reclamación antes; si no es así, establecemos un nuevo registro. Después se actualizan

O P O R T U N I D A D D E C O N S U L T O R Í A 9 . 1

Kit Chen Kaboodle, Inc.

“N o quiero que se agiten, pero creo que necesitamos dar un vis-

tazo a nuestras políticas de pedidos incompletos”, dice Kit Chen. “No

me gustaría presionar a nuestros clientes. Como saben de antemano,

Kit Chen Kaboodle es una empresa de venta de utensilios de cocina a

través de Web y por correo convencional, que se especializa en ‘kitsch

elegante para cocinas’ como dice nuestro catálogo más reciente. Es

decir, tenemos todo lo necesario para la cocina gourmet y entreteni-

miento: molinillos de nuez moscada, batidoras de papas, separadores

de huevos, jeringas para pavos, manteles individuales con gatos, bande-

jas para cubos de hielo en forma de tréboles y mucho más.

“He aquí la forma en que hemos estado manejando los pedidos

incompletos. Buscamos en nuestro archivo de pedidos incompletos

de Internet, así como las ventas de pedidos por correo, una vez por

semana. Si el pedido se completó esta semana, eliminamos el regis-

tro y el resto es pan comido. Si no hemos escrito al cliente en cuatro

semanas, les enviamos esta linda tarjeta con un chef asomándose al

horno, diciendo: ‘No está listo todavía’ (es una notificación de que

su artículo sigue pendiente)”.

“Si cambió la fecha del pedido pendiente a más de 45 días a

partir de hoy, enviamos un aviso. Pero si la mercancía es de tempo-

rada (como con las bolsas para dulces de Halloween, los cortadores

de galletas de Navidad o los moldes de pasteles del día de San Va-

lentín) y la fecha del pedido pendiente es de 30 días o más, envia-

mos un aviso con un chef mirando su temporizador”.

“Si la fecha del pedido pendiente cambió y no hemos enviado

una tarjeta en las últimas dos semanas, enviamos una tarjeta con un

chef revisando su receta. Si la mercancía ya no está disponible,

enviamos un aviso (con todo y el chef llorando en la esquina) y

eliminamos el registro. No hemos empezado a usar el correo elec-

trónico en vez de las tarjetas enviadas por correo, pero me gustaría

hacerlo”.

“Gracias por escuchar todo esto. Creo que tenemos los ingre-

dientes apropiados para una buena política; sólo necesitamos mez-

clarlos y cocinar algo especial”.

Como usted es el analista de sistemas que Kit contrató, repase

la narrativa de cómo Kit Chen Kaboodle, Inc. Maneja los pedidos

incompletos. Dibuje cuadros alrededor de cada acción que men-

ciona Kit y circule cada condición que vaya surgiendo. Haga una

lista de las ambigüedades que quiera aclarar en una entrevista pos-

terior y después escriba cinco preguntas a tratar en la entrevista.



Estructura para amasar

K it Chen se puso a la altura de las circunstancias y respondió a sus

preguntas relacionadas con el manejo de los pedidos incompletos en

Kit Chen Kaboodle, Inc. Con base en esas respuestas y las suposicio-

nes que tenga que hacer, vacíe la narrativa de Kit (de la Oportunidad

de consultoría 9.1) en un nuevo molde; vuelva a escribir la receta para

manejar pedidos incompletos en español estructurado. Describa en

un párrafo cómo podría cambiar este proceso si para las notificacio-

nes utilizara correo electrónico en vez de correo convencional.

DO WHILE haya reclamaciones restantes IF solicitante no ha presentado una reclamación THEN establecer un nuevo registro de solicitante ELSE continuarAgregar reclamación a reclamación AAF IF solicitante tiene plan de póliza A THEN IF deducible de $100.00 no se ha cumplido THEN restar deducible no cumplido a reclamación Actualizar deducible

ELSE continuar ENDIF Restar copago de 40% de reclamación a reclamación ELSE IF solicitante tiene plan de póliza B THEN IF deducible de $50.00 no se ha cumplido THEN restar deducible no cumplido a reclamación Actualizar deducible

ELSE continuar ENDIF Restar copago de 60% de reclamación a reclamación ELSE continuar ELSE escribir mensaje de error en plan ENDIF IF reclamación es mayor que cero THEN imprimir cheque ENDIF Imprimir resumen para solicitante Actualizar cuentasENDDO

FIGURA 9.4 Español estructurado para el

sistema de procesamiento de

reclamaciones médicas. Los

elementos subrayados indican que

se definieron los términos en el


los totales de las reclamaciones para el año. Luego determinamos si un solicitante tiene la póliza A o B,

que difieren en los deducibles y los copagos (el porcentaje de la reclamación que tienen que pagar los

solicitantes). Para ambas pólizas revisamos si se cumple con el deducible ($100 para la póliza A y $50

para la póliza B). Si no se cumple con el deducible, aplicamos la reclamación al deducible. En otro paso

se ajusta el copago; restamos el porcentaje que paga el solicitante (40 por ciento para la póliza A y 60 por

ciento para la póliza B) de la reclamación. Después emitimos un cheque si el solicitante va a recibir

dinero, imprimimos un resumen de la transacción y actualizamos nuestras cuentas. Hacemos esto hasta

que se procesan todas las reclamaciones de ese día.

Al examinar las declaraciones anteriores podemos observar algunas estructuras de secuencia simples, en especial

al inicio y al final. Hay un par de estructuras de decisión y lo más apropiado es anidarlas, para lo cual primero


hay que determinar qué póliza (A o B) usar y después hay que restar los deducibles y copagos correctos. El

último enunciado apunta a una iteración: HACER HASTA (DO UNTIL) que todas las reclamaciones se hayan

procesado o HACER MIENTRAS (DO WHILE) haya reclamaciones pendientes.

Si consideramos que es posible anidar las estructuras de decisión de acuerdo con los planes de las pólizas,

podemos escribir el español estructurado para el ejemplo anterior (vea la figura 9.4). A medida que empiece

a trabajar en el español estructurado descubrirá que una parte de la lógica y las relaciones que parecían claras

una vez son en realidad ambiguas. Por ejemplo, ¿debemos agregar la reclamación a la reclamación del año a la fecha

(AAF) antes o después de actualizar el deducible? ¿Es posible que ocurra un error si se almacena algo que no

sea la póliza A o B en el registro del solicitante? ¿A qué restamos el 40 por ciento de la reclamación? Hay que

aclarar estas ambigüedades en este punto.

Además de la obvia ventaja de aclarar la lógica y las relaciones que se encuentran en los lenguajes humanos,

el español estructurado tiene otra ventaja importante: es una herramienta de comunicación. Podemos enseñar a

los usuarios en la organización el español estructurado para que lo comprendan, por lo que si es importante la

comunicación, el español estructurado es una alternativa viable para el análisis de decisiones.

Diccionario de datos y especificaciones de procesosTodos los programas de computadora se pueden codificar mediante el uso de tres construcciones básicas: secuen-

cia, selección (IF…THEN…ELSE y la estructura de caso), e iteración o ciclo. El diccionario de datos indica

cuáles 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

iteración —{ }— o selección —[ ]—, la especificación de proceso contendrá una secuencia simple de instruc-

ciones, como MOVER, SUMAR y RESTAR. Consulte el ejemplo de un diccionario de datos para el ESTADO

DE CUENTA DE ENVÍO que se muestra en la figura 9.5. Cabe mencionar que el diccionario de datos para el

ESTADO DE CUENTA DE ENVÍO tiene los elementos NÚMERO DE PEDIDO, FECHA DEL PEDIDO y

Estado de cuenta de envío = Número de pedido +Fecha del pedido +Número de cliente +Nombre del cliente +Dirección del cliente +5{Líneas de artículos del pedido} +Número de artículos +

Total de mercancía +(Impuestos) +Envío y manejo +Total del pedido

Primer nombre +(Inicial segundo nombre) +Apellido paterno

Calle +(Departamento) +Ciudad +Estado +CP +(Expansión CP) +(País)

Número de artículo +Cantidad ordenada +Cantidad pendiente +Descripción del artículo +Descripción del tamaño +Descripción del color +Precio unitario +Monto extendido +

Nombre del cliente =

Dirección =

Líneas de artículos del pedido =

1

FIGURA 9.5 Estructura de datos para un estado

de cuenta de envío de World’s

Trend.


NÚMERO DE CLIENTE como simples campos secuenciales. La lógica correspondiente, que se muestra en las

líneas 3 a la 5 en el correspondiente español estructurado en la figura 9.6, consiste de instrucciones MOVER

simples.

Una estructura de datos con elementos opcionales contenidos entre paréntesis o elementos ya sea/o conteni-

dos entre corchetes, tendrán su correspondiente instrucción IF…THEN…ELSE en la especificación del proceso.

Además, si un monto tal como CANTIDAD PENDIENTE es mayor que cero, la lógica subyacente será IF…

THEN…ELSE. La iteración, que se indica mediante llaves en una estructura de datos, debe tener una instrucción

correspondiente DO WHILE, DO UNTIL o PERFORM UNTIL para controlar los ciclos en la especificación del

proceso. La estructura de datos para LÍNEAS DE ARTÍCULOS DEL PEDIDO permite hasta cinco artículos en

el ciclo. Las líneas 8 a la 17 muestran las instrucciones contenidas en el DO WHILE hasta el END DO necesa-

rias para producir las diversas LÍNEAS DE ARTÍCULOS DEL PEDIDO.

TABLAS DE DECISIÓNUna tabla de decisión es una tabla de filas y columnas, separada en cuatro cuadrantes, como se muestra en la figura

9.7. El cuadrante superior izquierdo contiene la(s) condición(es); el cuadrante superior derecho contiene las alter-

nativas de condiciones. La mitad inferior de la tabla contiene las acciones a realizar a la izquierda y las reglas para

ejecutar las acciones a la derecha. Cuando se utiliza una tabla de decisión para determinar la acción a realizar, la

lógica se mueve en sentido de las manecillas del reloj, partiendo desde el cuadrante superior izquierdo.

Español estructurado

GET Registro de pedidoGET Registro de clienteMover Número de pedido a estado de cuenta de envíoMover Fecha del pedido a Estado de cuenta de envíoMover Número de cliente a Estado de cuenta de envíoDO aplicar formato a Nombre del cliente (dejar sólo un espacio entre Primer/Segundo/Apellido)

DO aplicar formato a las líneas de Dirección del clienteDO WHILE haya artículos para el pedido GET Registro de artículo DO Aplicar formato a Línea de artículo Multiplicar Precio unitario por Cantidad ordenada para obtener Monto extendido Mover Monto extendido a Líneas de artículos del pedido Sumar Monto extendido a Total de mercancía IF Cantidad pendiente es mayor que cero Mover Cantidad pendiente a Líneas de artículos del pedido ENDIF

ENDDOMover Total de mercancía a Estado de cuenta de envíoMover 0 a ImpuestosIF Estado es igual a CT Multiplicar Total de mercancía por Tasa de impuestos para obtener ImpuestoENDIFMover Impuesto a Estado de cuenta de envíoDO calcular Envío y manejoMover Envío y manejo a Estado de cuenta de envíoSumar Total de mercancía, Impuestos y Envío y manejo para obtener Total del pedidoMover Total del pedido a Estado de cuenta de envío

GET Registro de pedidoGET Registro de clienteMover Número de pedido a estado de cuenta de envíoMover Fecha del pedido a Estado de cuenta de envíoMover Número de cliente a Estado de cuenta de envíoDO aplicar formato a Nombre del cliente (dejar sólo un espacio entre Primer/Segundo/Apellido)

DO aplicar formato a las líneas de Dirección del clienteDO WHILE haya artículos para el pedido GET Registro de artículo DO Aplicar formato a Línea de artículo Multiplicar Precio unitario por Cantidad ordenada para obtener Monto extendido Mover Monto extendido a Líneas de artículos del pedido Sumar Monto extendido a Total de mercancía IF Cantidad pendiente es mayor que cero Mover Cantidad pendiente a Líneas de artículos del pedido ENDIF

ENDDOMover Total de mercancía a Estado de cuenta de envíoMover 0 a ImpuestosIF Estado es igual a CT Multiplicar Total de mercancía por Tasa de impuestos para obtener ImpuestoENDIFMover Impuesto a Estado de cuenta de envíoDO calcular Envío y manejoMover Envío y manejo a Estado de cuenta de envíoSumar Total de mercancía, Impuestos y Envío y manejo para obtener Total del pedidoMover Total del pedido a Estado de cuenta de envío

Aplique formato al Estado de cuenta de envío. Una vez que haya aplicado formato a cadalínea del estado de cuenta, escriba la línea de envío.1.2.3.4.5.6.7.8.9.

10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.

FIGURA 9.6 Español estructurado para crear el

estado de cuenta de envío para

World’s Trend.


Condiciones y acciones

Condiciones

Acciones

Reglas

Alternativas de condiciones

Entradas de acciones

FIGURA 9.7 El formato estándar utilizado para

presentar una tabla de decisión.

Suponga que una tienda desea ilustrar su política sobre compras que no son en efectivo. La empresa podría

hacerlo mediante el uso de una tabla de decisión simple, como se muestra en la figura 9.8. Cada una de las tres

condiciones (venta menor de $50, paga con cheque y usa tarjetas de crédito) sólo tiene dos alternativas. Las dos

alternativas son Y (sí, es verdadero) o N (no, no es verdadero). Es posible realizar cuatro acciones:

1. Completar la venta después de verificar la firma.

2. Completar la venta. No se necesita firma.

3. Llamar al supervisor para la aprobación.

4. Comunicarse vía electrónica con el banco para la autorización de la tarjeta de crédito.

El ingrediente final que hace que valga la pena usar la tabla de decisión es el conjunto de reglas para cada

una de las acciones. Las reglas son las combinaciones de las alternativas de condiciones que precipitan una ac-

ción. Por ejemplo, la regla 3 dice:

El ejemplo anterior presenta un problema con cuatro conjuntos de reglas y cuatro posibles acciones, pero


Menor de $50Paga con cheque con dos formas de IDUsa tarjeta de crédito

Completar la venta después de verificar la firma.Completar la venta. No se necesita firma.Llamar al supervisor para la aprobación.Comunicarse vía electrónica con el banco para la autorización de la tarjeta de crédito.

Reglas1

Y Y N NY N Y NN

X

Y

X

N

X

Y

X

2 3 4

FIGURA 9.8 Uso de una tabla de decisión para

ilustrar la política de una tienda en

cuanto al pago de los clientes con

cuatro conjuntos de reglas y cuatro

posibles acciones.

eso es sólo una coincidencia. El siguiente ejemplo demuestra que con frecuencia las tablas de decisión se hacen

extensas y complicadas.

Desarrollar tablas de decisiónPara construir tablas de decisión, el analista necesita determinar el tamaño máximo de la tabla; eliminar cual-

quier situación imposible, inconsistencia o redundancia, y simplificar la tabla lo más que pueda. Los siguientes

pasos proveen al analista un método esquemático para desarrollar tablas de decisión:

1. Determinar el número de condiciones que pueden afectar la decisión. Combinar filas que se traslapan, como

las condiciones mutuamente excluyentes. El número de condiciones se convierte en el número de filas en la

mitad superior de la tabla de decisión.

IF N (la venta total NO es menor de $50.00)

AND

IF Y (el cliente pagó con cheque y tuvo dos formas de ID)

AND

IF N (el cliente no usó una tarjeta de crédito)

THEN

DO X (llamar al supervisor para la aprobación).


2. Determinar el número de acciones posibles que se pueden realizar. Ese número se convierte en el número de

filas en la mitad inferior de la tabla de decisión.

3. Determinar el número de alternativas de condiciones para cada condición. En la forma más simple de la

tabla de decisión, habría dos alternativas (Y o N) para cada condición. En una tabla con entradas extendidas,

podría haber muchas alternativas para cada condición. Asegúrese de incluir todos los valores posibles para la

condición. 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 más de $1,000, el analista debe

tener en cuenta que también debe agregar el rango de 0 a $100 como una condición. Esto es cierto sobre

todo cuando hay otras condiciones que se pueden aplicar al total de pedido de 0 a $100.

4. Calcular el número máximo de columnas en la tabla de decisión, para lo cual hay que multiplicar el número

de alternativas para cada condición. Si hubiera cuatro condiciones y dos alternativas (Y o N) para cada una de

las condiciones, habría 16 posibilidades, como se muestra a continuación:

Condición 1: � 2 alternativas




16 posibilidades

5. Llenar las alternativas de condiciones. Empezar con la primera condición y dividir 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 (Y o N), por lo que 16 dividido entre 2 es 8. Después hay que elegir una de las alternativas, por

ejemplo Y, y escribirla en las primeras ocho columnas; para terminar hay que escribir N en las ocho

columnas restantes, como se muestra a continuación:

Condición 1: Y Y Y Y Y Y Y Y N N N N N N N N

Condición 1: Y Y Y Y Y Y Y Y N N N N N N N N

Condición 2: Y Y Y Y N N N N

Condición 3: Y Y N N

Condición 4: Y N

Condición 1: Y Y

Condición 2: Y N

Acción 1: X X

6. Para completar la tabla, inserte una X donde las reglas sugieran ciertas acciones.

7. Combine las reglas en las que sea aparente que una alternativa no marca una diferencia en el resultado. Por

ejemplo,

Repita este paso para cada condición; utilice un subconjunto de la tabla,

y continúe el patrón para cada condición:

Condición 1 Y Y Y Y Y Y Y Y N N N N N N N N

Condición 2: Y Y Y Y N N N N Y Y Y Y N N N N

Condición 3: Y Y N N Y Y N N Y Y N N Y Y N N

Condición 4: Y N Y N Y N Y N Y N Y N Y N Y N

se puede expresar como:

Condición 1: Y

Condición 2: —

Acción 1: X

El guión [—] significa que la Condición 2 puede ser Y o N, y la acción se realizará de cualquier manera.

8. Revise cualquier situación imposible, contradicción o redundancia en la tabla. Abundaremos sobre esto

posteriormente.

9. Vuelva a ordenar las condiciones y acciones (o incluso las reglas) si esto le ayuda a comprender mejor la

tabla de decisión.



Ahorrar un centavo en Citron Car Rental

“N os sentimos afortunados de ser tan populares. Creo que los

clientes sienten que tenemos tantas opciones que ofrecerles que

deberían de rentar un automóvil de nosotros”, dice Ricardo Limon,

quien dirige varios puntos de venta para Citron Car Rental. “Nues-

tro eslogan es, ‘Nunca se sentirá exprimido en Citron’. Tenemos

cinco tamaños de automóviles que listamos de la A a la E.”

si su empresa tiene una cuenta con nosotros. También hay un des-

cuento por membresía en cualquiera de los clubes de viajero fre-

cuente operados por las aerolíneas corporativas. Cuando los clientes

se acercan al mostrador, nos dicen el tamaño de automóvil que re-

servaron y verificamos que lo tengamos disponible, listo para irse.

Por lo general preguntan por los descuentos, y nosotros les pregun-

tamos si desean un seguro y cuánto tiempo usarán el automóvil.

Después calculamos su tarifa y les damos un recibo para que lo

firmen ahí mismo”.

Ricardo le ha pedido a usted que computarice el proceso de

facturación para Citron, de manera que los clientes puedan recibir sus

automóviles con rapidez sin errores de facturación. Dibuje una tabla

de decisión que represente las condiciones, alternativas de condicio-

nes, acciones y reglas de acciones que usted deduzca de la narrativa

de Ricardo para guiar un proceso de facturación automatizado.

Ricardo desea expandir la porción de comercio electrónico de

su empresa al hacer que sea posible reservar un automóvil a través

del sitio Web. Dibuje una tabla de decisión actualizada que muestre

un 10 por ciento de descuento por reservar un auto a través del sitio

Web.

A Subcompacto

B Compacto

C Mediano

D Grande

E De lujo

“La transmisión estándar sólo está disponible para A, B y C. La

transmisión automática está disponible para todos los automóviles”.

Si un cliente reserva un subcompacto (A) y al llegar descubre

que no tenemos uno, recibe una actualización gratuita al siguiente

tamaño, en este caso un compacto (B). Los clientes también reciben

una actualización del tamaño de automóviles que tengan reservado

UN EJEMPLO DE TABLA DE DECISIÓN La figura 9.9 es una ilustración de una tabla de decisión desarrollada

mediante el uso de los pasos antes descritos. En este ejemplo, una empresa trata de mantener una lista de clientes

de correo representativa. El objetivo es enviar sólo los catálogos para que los clientes compren la mercancía

anunciada en ellos.

Los gerentes saben que ciertos clientes leales hacen pedidos de todos los catálogos y que algunas personas de

la lista nunca hacen pedidos. Estos patrones de pedidos son fáciles de observar, pero es más difícil decidir cuáles

catálogos enviar a los clientes que ordenan sólo de ciertos catálogos seleccionados. Una vez tomadas estas deci-

siones, se construye una tabla de decisión para tres condiciones (C1: el cliente hizo un pedido del catálogo de

otoño; C2: el cliente hizo un pedido del catálogo de Navidad y C3: el cliente hizo un pedido de un catálogo es-

pecializado), cada una de las cuales tiene dos alternativas (Y o N). Se pueden tomar tres acciones (A1: enviar el

catálogo de Navidad de este año; A2: enviar el nuevo catálogo especializado y A3: enviar ambos catálogos).

La tabla de decisión resultante tiene seis filas (tres condiciones y tres acciones) y ocho columnas (dos alternati-

vas � dos alternativas � dos alternativas).

Ahora hay que examinar la tabla de decisión para ver si se puede reducir. No hay condiciones mutuamente

excluyentes, por lo que no es posible usar menos de tres filas de condiciones. No hay reglas que permitan la


El cliente hizo un pedido del catálogo de otoño.El cliente hizo un pedido del catálogo de Navidad.El cliente hizo un pedido del catálogo especializado.

Enviar el catálogo de Navidad de este año.Enviar el catálogo especializado.Enviar ambos catálogos.

Reglas1 2 3 4 5 6 7 8

Y Y Y Y N N N NY Y N N Y Y N NY N

XX

X XX

X X X

Y N Y N Y N

FIGURA 9.9 Construcción de una tabla de

decisión para decidir qué catálogo

enviar a los clientes que piden sólo

de catálogos seleccionados.


combinación de acciones. Sin embargo, es posible combinar algunas de las reglas como se muestra en la figura

9.10. Por ejemplo, las reglas 2, 4, 6 y 8 se pueden combinar debido a que todas tienen dos cosas en común:

1. Nos sugieren enviar el catálogo de Navidad de este año.

2. La alternativa para la Condición 3 siempre es N.

No importa cuáles sean las alternativas para las primeras dos condiciones, por lo que es posible insertar guiones

[—] en vez de Y o N.

Las reglas restantes (1, 3, 5 y 7) no se pueden reducir a una sola regla debido a que restan dos acciones. En

vez de ello podemos combinar las reglas 1 y 5; de igual forma podemos combinar las reglas 3 y 7.

Verificar la integridad y precisiónEs esencial que verifique la integridad y precisión de sus tablas de decisión. Pueden ocurrir cuatro problemas

principales al desarrollar tablas de decisión: que estén 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 acción estén completas. Suponga que omitimos una condición importante (si un cliente hizo un pedido me-

nor de $50) del problema de la tienda de catálogos que vimos antes. Esto provocaría que cambiara toda la tabla de

decisión, ya que habría que agregar una nueva condición, un nuevo conjunto de alternativas, una nueva acción y una

o más nuevas reglas de acción. Suponga que la regla es: SI el cliente no ordenó más de $50, ENTONCES no enviar

catálogos. Se agregaría una nueva regla 4 a la tabla de decisión, como se muestra en la figura 9.11.



Reglas

Reglas





YYY

YY Y

Y

YYY

YY

YY Y

NN N

N

N N

N

NN

NNN

NN

X

XX

X

X

XX

X

XX

X

1 2 3 4 5 6 7 8

1' 2' 3'

FIGURA 9.10 Combinación de reglas para

simplificar la tabla de decisión

cliente-catálogo.

Condiciones y accionesReglas

El cliente hizo un pedido del catálogo de otoño.

El cliente hizo un pedido del catálogo de Navidad.

El cliente hizo un pedido del catálogo especializado.

El cliente hizo un pedido de $50 o más.

Enviar el catálogo de Navidad de este año.

Enviar el catálogo especializado.

Enviar ambos catálogos.

No enviar ningún catálogo.

Y

Y

Y Y

Y

Y

N

N

N

X

X

X

X

1' 2' 3' 4'

FIGURA 9.11 Al agregar una regla a la tabla de

decisión cliente-catálogo se

modifica toda la tabla.


Al construir tablas de decisión según lo indicado en los pasos anteriores, algunas veces podemos llegar a

establecer situaciones imposibles. En la figura 9.12 se muestra un ejemplo. La regla 1 no es factible, ya que una

persona no puede obtener más de $50,000 al año y menos de $2,000 mensuales por mes al mismo tiempo. Las

otras tres reglas son válidas. El problema pasó desapercibido debido a que la primera condición se midió en años

y la segunda en meses.

Cuando las reglas sugieren distintas acciones pero satisfacen las mismas condiciones, ocurren contradic-

ciones. La falla podría estar en la forma en que el analista construyó la tabla o en la información que recibió.

A menudo ocurren contradicciones si se insertan guiones [—] incorrectamente en la tabla. La redundancia ocu-

rre cuando conjuntos idénticos de alternativas requieren exactamente la misma acción. La figura 9.13 ilustra una

contradicción y una redundancia. El analista debe determinar qué es lo correcto y después resolver la contradic-

ción o redundancia.

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

ventaja importante de usar tablas de decisión en comparación con otros métodos es que las tablas ayudan al ana-

lista a asegurar la integridad. Al usar tablas de decisión también se facilita la acción de verificar posibles errores,

como las situaciones imposibles, contradicciones y redundancia. También existen los procesadores de tablas de

decisión, que reciben la tabla como entrada y proveen código de programa de computadora como salida.

ÁRBOLES DE DECISIÓNLos árboles de decisión se utilizan cuando ocurren ramificaciones complejas en un proceso de decisión estruc-

turado. Los árboles también son útiles cuando es imprescindible mantener una cadena de decisiones en una

secuencia específica. Aunque el nombre “árbol de decisión” se deriva de los árboles naturales, por lo general

los árboles de decisión se dibujan de lado, con la raíz en el lado izquierdo del papel; a partir de ahí el árbol

se ramifica hacia la derecha. Esta orientación permite al analista escribir en las ramas para describir las con-

diciones y acciones.

A diferencia del árbol de decisión que se utiliza en la ciencia de la administración, el árbol del analista no

contiene probabilidades y resultados. En el análisis de sistemas, los árboles se utilizan principalmente para iden-

tificar y organizar las condiciones y acciones en un proceso de decisión completamente estructurado.


Salario > $50,000/añoSalario < $2,000/mes

Acción 1Acción 2

Reglas1 2 3 4

Y Y N NY N Y N

Ésta es unasituaciónimposible.

FIGURA 9.12 Es importante verificar que la

tabla de decisión no tenga

situaciones imposibles.

Condiciones y accionesReglas

YY Y

Y YY

YY

YNN

N

N

NN

X

XX

X XX

X

1 2 3 4 5 6 7

YN

Condición 1Condición 2Condición 3

Acción 1Acción 2Acción 3

Contradicción Redundancia

FIGURA 9.13 Es importante verificar que la

tabla de decisión no tenga

contradicciones ni redundancia

inadvertidas.


Dibujar árboles de decisiónEs conveniente poder diferenciar entre las condiciones y las acciones al momento de dibujar árboles de decisión.

Esta distinción es en especial relevante cuando las condiciones y acciones se llevan a cabo durante un periodo de

tiempo y su secuencia es importante. Para este fin hay que utilizar un nodo cuadrado para indicar una acción y

un círculo para representar una condición. El uso de esta notación mejora la legibilidad del árbol, al igual que la

acción de enumerar los círculos y cuadrados en forma secuencial. Piense en un círculo como si fuera un SI (IF),

mientras que el cuadrado significa ENTONCES (THEN).

Cuando hablamos sobre las tablas de decisión en una sección anterior, utilizamos un ejemplo de punto de venta

para determinar las acciones para aprobar las compras en una tienda de departamentos. Las condiciones incluían el

monto de la venta (menor a $50) y si el cliente pagaba con cheque o tarjeta de crédito. Las cuatro acciones posibles

eran completar la venta después de verificar la firma; completar la venta sin necesidad de la firma; llamar al super-

visor para la aprobación, o comunicarse vía electrónica con el banco para la autorización de la tarjeta de crédito. La

figura 9.14 muestra cómo se puede dibujar este ejemplo como un árbol de decisión. Al dibujar el árbol hay que:

1. Identificar todas las condiciones y acciones, junto con su orden y sincronización (si son críticas).

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 simétrico y las cuatro acciones al final son únicas, aunque un árbol no tiene que ser simétrico.

La mayoría de los árboles de decisión tienen condiciones con un número distinto de ramificaciones. Además

pueden aparecer acciones idénticas más de una vez.


Un árbol gratis

“s é que debe abordar un avión, pero déjeme tratar de expli-

carle otra vez, señor”, suplica Glen Curtis, gerente de marketing

de Premium Airlines. Curtis ha estado tratando, sin éxito, de ex-

plicar la nueva política de la aerolínea para acumular millas y

obtener premios (como promociones a primera clase y vuelos

gratis) para los miembros del club “Volando por premios” de

Premium Airlines.

Glen hace otro intento por echar a volar la política, y dice:

“Mire, señor, el viajero (ése es usted, el Sr. Icarus) recibirá las mi-

llas que haya volado. Si la distancia recorrida de un tramo fue me-

nor a 500 millas, el viajero recibirá 500 millas de crédito. Si el viaje

se hizo en sábado, la distancia recorrida se multiplicará por dos. Si

el viaje se hizo en martes, el factor de multiplicación es de 1.5. Si éste

es el noveno tramo recorrido durante el mes calendario, las millas

se duplican sin importar cuál sea el día, y si es el 17° tramo reco-

rrido, se triplican las millas. Si el viajero reservó el vuelo a través

de Web o mediante un servicio de viajes como Orbiz o Travelocity,

se agregan 100 millas”.

“Espero que ahora le quede más claro, Sr. Icarus. Disfrute su

vuelo y gracias por volar en Premium”.

El Sr. Icarus, cuyo deseo de abordar el avión de Premium es-

tuvo a punto de desaparecer durante la extensa explicación de Glen,

se pierde en el mar de personas que caminan por las filas de seguri-

dad, sin emitir siquiera un sonido en respuesta.

Desarrolle un árbol de decisión para la nueva política de Pre-

mium Airlines sobre la forma de acumular millas, de manera que la

política sea más clara, más fácil de comprender en forma visual y,

por ende, más fácil de explicar.

Completar la venta después de verificar la firma.Cheque

Tarjeta de crédito

Cheque

Menos de $50

≥ $50

Tarjeta de crédito

Completar la venta. No se requiere firma.

Llamar al supervisor para la aprobación.

Comunicarse vía electrónica con el banco parala autorización de la tarjeta de crédito.

2

5

7

6

4

3

1

FIGURA 9.14 Cómo dibujar un árbol de decisión

para mostrar las acciones de

aprobación de compras que no son

en efectivo para una tienda

departamental.


El árbol de decisión tiene tres principales ventajas sobre una tabla de decisión. En primer lugar saca prove-

cho de la estructura secuencial de sus ramas, por lo que se puede observar de inmediato el orden de verificación

de las condiciones y ejecución de las acciones. En segundo lugar, podemos encontrar condiciones y acciones de

los árboles de decisión en algunas ramas pero no en otras, lo cual contrasta con las tablas de decisión, donde to-

das forman parte de la misma tabla. Esas condiciones y acciones que son críticas se conectan de manera directa

con otras condiciones y acciones, mientras que las condiciones que no importan están ausentes. En otras pala-

bras, el árbol no tiene que ser simétrico. En tercer lugar, en comparación con las tablas de decisión, otras perso-

nas en la organización pueden comprender con más facilidad los árboles de decisión. En consecuencia, son más

apropiados como herramienta de comunicación.

CÓMO ELEGIR UNA TÉCNICA DE ANÁLISIS DE DECISIONES ESTRUCTURADASYa examinamos las tres técnicas de análisis de decisiones estructuradas: español estructurado, tablas de decisión

y árboles de decisión. Aunque no es necesario utilizarlas en forma exclusiva, es costumbre elegir una técnica de

análisis para una decisión en vez de emplear las tres. Los siguientes lineamientos le proveerán una manera de elegir

una de las tres técnicas para un caso específico:

1. Use 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 encuentre con combinaciones complejas de condiciones, acciones y reglas,

O

b. Requiera un método que evite de manera efectiva las situaciones imposibles, redundancias y

contradicciones.

3. Use los árboles de decisión cuando

a. La secuencia de condiciones y acciones sea crítica,

O

b. No todas las condiciones sean relevantes para todas las acciones (que las ramificaciones sean distintas).

RESUMENUna 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 especificación de procesos y el análisis de

decisiones. Los tres métodos para el análisis de decisiones y para

describir la lógica de procesos que vimos en este capítulo son

español estructurado, tablas de decisión y árboles de decisión.

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 más alto

que se expanden en un diagrama hijo. Estas especificaciones

explican la lógica de toma de decisiones y las fórmulas que

transformarán los datos de entrada de un proceso en su salida.

Los tres objetivos de la especificación de procesos son reducir

la ambigüedad del proceso, obtener una descripción precisa de

lo que se logra y validar el diseño del sistema.

Una manera de describir las decisiones estructuradas es me-

diante el método que se conoce como español estructurado, en

el cual la lógica se expresa en estructuras secuenciales, estruc-

turas de decisión, estructuras de casos o iteraciones. El español

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 lógica utilizada; además hace uso de la sangría para

indicar la estructura jerárquica del proceso de decisión.

Las tablas de decisión 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 decisión (como Y o N), 3) indicar qué

acciones se deben realizar y 4) describir las acciones. Las tablas

de decisión son ventajosas ya que las reglas para desarrollar la

tabla en sí, además de las reglas para eliminar redundancia, con-

tradicciones y situaciones imposibles, son simples y manejables.

Al usar tablas de decisión se fomenta la integridad y precisión en

el análisis de las decisiones estructuradas.

El tercer método para el análisis de decisiones es el árbol

de decisión, que consiste en nodos (un cuadrado para las accio-

nes y un círculo para las condiciones) y ramificaciones. Los ár-

boles de decisión son apropiados cuando las acciones se deben

llevar a cabo en cierta secuencia. No hay ningún requerimiento

de que el árbol sea simétrico, por lo que sólo las condiciones y

acciones que sean críticas para las decisiones en cuestión son

las que se encuentran en una rama específica.

Cada uno de los métodos de análisis de decisiones tiene

sus propias ventajas y se debe utilizar de manera acorde. El es-

pañol estructurado es muy útil cuando se repiten muchas accio-

nes y cuando es importante comunicarse con otros. Las tablas

de decisión proveen un análisis 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 decisión 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.

Especificaciones de los procesos y decisiones estructuradas · PDF fileLas especificaciones de...

Documents

Transcript of Especificaciones de los procesos y decisiones estructuradas · PDF fileLas especificaciones de...