Rfdsfsfsfsde

OBJETIVOS DE APRENDIZAJE

Una vez que haya dominado el material de este capítulo, podrá:
1. Entender el propósito de las especificaciones de procesos.
2. Reconocer la diferencia entre decisiones estructuradas y semi estructuradas.
3. Usar Español estructurado, tablas de decisión y árboles de decisión para analizar, describir
y documentar decisiones estructuradas.
4. Elegir un método deanálisis de decisiones apropiado para analizar decisiones estructuradas
y crear especificaciones de procesos.

PANORAMA GENERAL DE LAS ESPECIFICACIONES DE PROCESOS
Para determinar los requerimientos de información de una estrategia de análisis di- decis-ión,
el analista de sistemas primero debe determinar los objetivos organizacionales medianil1 un
enfoque de jerarquización de arriba haciaabajo. El analista de sistemas dene entender los
principios organizacionales y debe contar con experiencia en las técnicas de recopilación de
datos. EJ enfoque de jerarquización de arriba hacia abajo es muy importante poi"i|iie 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 —aveces llamadas miniesperíficacUmes, 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 procosos
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 deentrada 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 detallesacerca del funcionamiento de un proceso. Es necesario detectar, anotar e integrar las
áreas indefinidas de todas las 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 deespecificaciones 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.
Usted encontrará muchas situaciones en las que no se crean especificaciones de procesos.
A veces el proceso esmuy 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 requierenló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 enun
sistema como subprogramas y funciones.
Los subprogramas son programas de computadora que se escriben, prueban y almacenan
en el sistema de cómputo. Éstos normalmente realizan una función general en el sistema,
tal como validar una fecha o un dígito de verificación. Estos subprogramas de propósito
general se escriben y documentan una sola vez pero constituyen una serie de elementos...