- Características de un
buen diseño de sistemas - Características
del diseño conceptual - Proyección del
análisis a las salidas - Proyección del
análisis a las entradas y controles - Proyección del
análisis a la base de datos - Proyección del
análisis a los procesos (programas) - Proyección del
análisis a los procedimientos - Propuesta del
sistema - Preparación del
reporte - Alternativas de
solución - Documentación del
análisis preliminar
CARACTERÍSTICAS DE UN BUEN DISEÑO DE
SISTEMAS
Los componentes de un sistema de
información descritos durante el análisis de
requerimientos son el punto focal del diseño de
sistemas.
- Flujos de datos. Movimientos de datos hacia,
alrededor y desde el sistema. - Almacenes de datos. Conjunto
temporales o permanentes de datos. - Procesos. Actividades para aceptar,
manejar y suministrar datos e información. - Procedimientos. Métodos y rutinas para utilizar el
sistema de información y lograr con ello los
resultados esperados. - Controles. Estándares y
lineamientos para determinar si las actividades que
están ocurriendo en la forma anticipada o
aceptada. - Funciones del personal. Las responsabilidades de
todas las personas que tiene que ver con el nuevo sistema,
incluyendo los usuarios, operadores d computadora y personal de apoyo.
CARACTERÍSTICAS DEL DISEÑO
CONCEPTUAL
El manejo del proceso de
diseño
significa tomar los pasos necesarios para que el esfuerza de
desarrollo
avance en forma apropiada y produzca los resultados
esperados.
Carpeta de descripción del diseño de
sistema
Los analistas de sistema denominan a esta s
especificaciones información liberada o carpeta de
diseño.
La información liberada incluye los siguientes
aspectos:
- Cuadro de despliegue. Descripciones
de las entradas y salidas donde se muestra la
ubicación de todos los detalles que aparecerán
en los reportes, documentos y
pantallas de terminal. - Estructuras de registros. Descripciones de todos los
datos contenidos en los archivos
maestros y de transacciones así como los diagramas
relacionados con la base de
datos. - Sistemas de codificación. Descripciones de
los códigos que explican o identifican tipos de
transacciones, clasificaciones y categorías de
eventos o
entidades. - Especificaciones de los programas. Cuadros, tablas y
descripciones gráfica de los módulos y
componentes del software de
computadora junto con la interacción entre cada una de
ellos. - Especificaciones de procedimientos. Procedimientos
planificados para instalar y operar el sistema cuando este
terminado. - Plan de desarrollo. Cronogramas que
indican los tiempos necesarios para el desarrollo de las
actividades. - Costo del paquete. Gastos
anticipados para el desarrollo, implantación y
operación de nuevos sistemas,
clasificados por categorías tales como personal,
equipo, comunicaciones, facilidades y
suministros.
PROYECCIÓN DEL ANÁLISIS A LAS
SALIDAS
Para muchos usuarios finales, la salida es la
única razón para el desarrollo del sistema y la
base sobre la que ellos evaluarán la utilidad de la
aplicación.
Cuado diseñan la salida, los analistas deben
realizar lo siguiente:
- Determinar que información
presentar. - Decidir si la información será
presentada en forma visual, verbal o impresa y seleccionar el
medio de salida. - Disponer la presentación en un formato
aceptable. - Decidir como distribuir la salida entre los
posibles destinatarios.
PROYECCIÓN DEL ANÁLISIS A LAS
ENTRADAS Y CONTROLES
Los analistas de sistemas deciden los siguientes
detalles del diseño de entradas:
- Que datos ingresan los sistemas.
- Que medios
utilizar. - La forma en que se debe disponer o codificar los
datos. - El diálogo que servirá de
guía a los usuarios para dar entrada a los
datos. - Validación necesaria de datos y
transacciones para detectar errores. - Métodos para llevar a cabo la
validación de las entradas y los pasos a seguir cuando
se presentan errores.
Las decisiones de diseño para el manejo de
entradas especifican la forma en que serán aceptados los
datos para su procesamiento por computadora.
El diseño de la entrada también incluye la
especificación de los medios por los que tanto los
usuarios finales como los operadores dan instrucciones al sistema
sobre las acciones que
deben emprender.
Controles de entrada.-
El analista de sistemas debe especificar los controles
para evitar la entrada errónea al sistema de
información. Para los campos críticos el control de la
entrada implica verificar o volver a teclear. Si un campo es
crítico para la verificación de una entrada y
está sujeto a errores de transcripción o
transposición, como un número de cuenta o el
número de identificación de un empleado, en
analista también podría elegir anexarle un
dígito de verificación.
En consecuencia, se debe decidir acerca de un algoritmo en
particular de dígitos de verificación y
documentarlo.
Dependiendo del tipo de método
empleado para la captura de datos, puede ser necesario realizar
sobre la entrada varias pruebas de
racionalidad. Estos controles de entrada se aplican en cuatro
niveles: (1) Campos, (2) registros, (3) lotes y (4)
archivos.
Controles de procesamiento.-
Aún cuando el analista de sistemas pudiera
proponer un extenso conjunto de controles de entrada para el
sistema que se está desarrollando, siempre habrá
algunos errores de entrada que no puedan detectarse, creando
errores adicionales durante el procesamiento.
Operando bajo la suposición de que ningún
sistema de información está completamente libre de
errores, el analista de sistemas inserta en los programas de
procesamiento ciertos controles del tipo de los de la
entrada.
Verificación de racionalidad. En la
codificación de los programas se especifican pruebas de
racionalidad como parte de las rutinas básicas para la
validación de las entradas.
Bitácora de transacciones. Se utilizan para
respaldo, recuperación y pruebas de auditoría contable. Este deberá
incluir información acerca del lugar, el momento y la
terminal de donde se originaron las transacciones, además
del número de usuario.
Controles de acceso a las bases de
datos.-
Los controles de acceso a la base de datos incluyen un
gran número de dispositivos y procedimientos desde puertas
con cerradura y procedimientos de firma de entrada/ firma de
salida hasta dispositivos biométricos.
Los usuarios autorizados se identifican con base en un
dispositivo de control de acceso mediante geometría manual. Unos
apuntadores conectan a los usuarios autorizados a la tabla de
autorizaciones, la cual especifica lo que puede hacer un usuario
una vez que se le ha dado acceso a ciertas relaciones o conjuntos de
datos de la base de datos.
Controles de salida.-
Una vez que se produce la salida, deberán existir
ciertos controles para asegurar que esta salida no se pierda,
corrompa o sea robada. Por lo general, los controles más
extensos se aplican a la salida en lotes debido a que en la
producción y distribución de las copias en papel
está involucrado un mayor número de
personas.
La salida en línea por pantalla, normalmente
requiere menores controles debido a la interfaz directa usuario/
sistema y a controles de acceso más estrechos.
PROYECCIÓN DEL ANÁLISIS A LA BASE
DE DATOS
En estos casos, el analista de sistemas no afecta el
diseño de l base de datos sino que consulta al administrador.
A su vez el papel del administrador de base de datos
incluye las siguientes responsabilidades:
- Evaluar la conveniencia de la solicitud del
analista. - Describir los métodos para interactuar con
la base de datos. - Asegurar que la aplicación no pueda
dañar la base de datos o que la afecte de manera
adversa a las necesidades de otros sistemas de
información.
PROYECCIÓN DEL ANÁLISIS A LOS
PROCESOS
(PROGRAMAS)
Hasta el momento, en la fase del diseño
detallado, el analista de sistemas ha especificado las entradas,
las salidas, la base de datos, los controles y los procedimientos
para el nuevo sistemas de información. Si el nuevo sistema
de información requiere hardware o software de
sistemas adicionales, el analista de sistemas ya se habrá
ocupado de que el proceso de abastecimiento de dichos recursos
está en camino.
El diseño detallado de los programas requiere
concentrar los esfuerzos del analista de sistemas en definir los
programas que formaron el sistema de información, los
módulos detallados de cada programa y las
relaciones entre los módulos y los programas.
Definición de programas.-
El objetivo de la
definición de programas es la preparación de una
descripción de cada programa del sistemas de
información. El analista de sistemas podría empezar
agrupando las salidas que serán producidas por el sistema
de información.
Luego se podría diseñar un programa para
generar cada grupo de
salida. Para las entradas podría seguirse un proceso
similar de agrupamiento y designación, comparando tareas
tales como validación y edición
de la entrada. Si los datos necesitan ordenarse, entonces
podría definirse otros programas de
utilería.
Este proceso de agrupar las entradas y las salidas y
luego pensar en las transformaciones necesarias para pasar de la
entrada a la salida, produce una lista de programas.
Esta lista contendrá el nombre, número en
clave, y una definición breve de cada programa del sistema
de información.
PROYECCIÓN DEL ANÁLISIS A LOS
PROCEDIMIENTOS
Uno de lo principales beneficios del diseño de
los sistemas es la generación automática de
documentación y procedimientos como un
subproducto del desarrollo de trabajo en
sistemas. Para cuando uno ha concluido la fase del diseño
detallado de sistemas, se han completado entre muchas otras
cosas, los procedimientos tanto para los programas de
aplicaciones como para el personal.
El inglés
estructurado, los diagramas de
flujo de datos y el diseño detallado de la salida, la
entrada, la base de datos, los controles y los procedimientos,
proporcionan especificaciones suficientes para permitir a los
programadores escribir el código.
Cuando el programador de aplicaciones termina un
programa, entonces se agregan detalles adicionales como el
número de identificación del programa, el lenguaje de
control de trabajos (JCL), los procedimientos de prueba y el
listado fuente para formar un paquete completo de la
documentación del programa de aplicaciones.
Los analistas de sistemas también identifican las
actividades realizadas por el personal. Se escriben
procedimientos para guiar al personal en sus tareas, de manera
similar a los procedimientos escritos para los programas de
aplicaciones.
Se presenta un ejemplo de captura de pedidos para
ilustrar los procedimientos escritos para los programadores de
aplicaciones, seguido de los procedimientos de descuento por pago
en efectivo para el personal de ventas y de
captura de pedidos.
CONCLUSIÓN DEL ANÁLISIS DE
SISTEMAS
A lo largo de toda la fase del análisis de
sistemas, el analista deberá mantener una extensa
comunicación con el solicitante, y
demás personal de proyectos. Esta
comunicación comienza con el reporte de la propuesta para
realizar el análisis de sistemas que se describió
anteriormente.
En forma continua este esfuerzo de comunicación
incluye una retroalimentación a las personas
entrevistadas, u observadas, con relación a lo que el
analista atiende; la verificación con el personal usuario
con respecto a los hallazgos en otras funciones o
actividades relacionadas que el analista identifique y reuniones
periódicas para informar a la gerencia y
demás personal del proyecto acerca
del progreso, situación y apego al calendario.
PREPARACIÓN DEL REPORTE
ESCRITO
Reporte de terminación del análisis de
sistemas
Quizás es la
comunicación mas importante de todas, que describe los
hallazgos del análisis de sistemas. El formato y contenido
de este reporte incluye lo siguiente:
- Una nueva exposición de la razón y alcance
del análisis. - Una lista de los principales problemas
identificados. - Una presentación de todos los requerimientos
de los usuarios. - Un planteamiento de todas la suposiciones
críticas hechas por el analista durante el
análisis. - Una proyección de los recursos requeridos y
los costos
esperados que estarán involucrados en el diseño
de cualquier nuevo sistema o en la modificación del
sistema actual. - Cualquier recomendación referente al sistema
propuesto o a sus requerimientos.
PREPARACIÓN ORAL DEL REPORTE
La simple entrega de los reportes de sistemas no es
suficiente. Es necesaria una presentación oral para una
comunicación clara del trabajo realizado. Cuatro
métodos para la presentación oral de los reportes
de sistemas son la memorización, la presentación
improvisada, la lectura, y
el método extemporáneo.
MEMORIZADA
Una presentación memorizada es eficaz en cierta
forma y le proporciona a uno un sentimiento de seguridad, pero a
costa de una libertad y
frescura, incluso en la presentación memorizada, se
necesita tener un bosquejo para el caso en que uno se
pierde.
IMPROVISADA
El método improvisado es una presentación
sin ensayo y no se
recomienda en absoluto para la presentación de los
reportes del sistema. Debido a que uno es el autor de estos
reportes, se podría considerar que no es necesario
revisarlos; sin embargo, sino se hace, se olvidarán los
puntos principales y se tenderá a divagar.
LECTURA
La lectura de los
reportes puede describirse en una palabra arrullo; es una
pastilla para dormir la lectura de los reportes, además de
la incapacidad para mantener un contacto visual.
EXTEMPORÁNEA
El método extemporáneo es la mejor forma
de presentar los reportes. Si uno ha hecho su tarea y conoce sus
reportes de pies a cabeza, entonces éste es el
método de entrega más versátil y expresivo.
Se es espontáneo y enérgico. Uno se puede adaptar
fácilmente a tópicos y situaciones que no estaban
planeadas.
- Parar el trabajo.-
Este resultado significa que ya no se va a realizar más
trabajo y que el trabajo en sistemas y los recursos
deberán dirigirse hacia otros trabajos. Este resultado
podría presentarse debido a que una propuesta no cumple
las consideraciones de factibilidad,
debido a un cambio en
las decisiones de la gerencia o del solicitante, o debido a un
reordenamiento de las prioridades de los sistemas. - Estado de espera.- Este resultado es bastante
común y generalmente se da por una falta de fondos o una
actitud
conservadora de la gerencia. - Modificar.- Este resultado significa que la gerencia
decide que algunos aspectos de la propuesta se deben cambiar o
combinar con otros subsistemas. - Proceder bajo condición.- Este resultado
significa que el trabajo en sistemas proseguirá
según se propuso, pero que la propuesta del
diseño final antes de la implementación
tendrá que justificarse en base a la
factibilidad. - Proceder sin condiciones.- Muchas propuestas de
sistemas o subsistemas son autorizadas por la gerencia con un
conocimiento
total de que los costos superaron los beneficios
medibles.
DOCUMENTACIÓN
DEL ANÁLISIS PRELIMINAR
El reporte está dirigido a dos receptores
diferentes. Primeramente, el gerente para
determinar si el analista ha realizado un trabajo
competente.
El segundo lugar a la gerencia general y a la gerencia
de los usuarios para determinar si el analista ha considerado o
no todos los requerimientos de la
organización.
Para proporcionar un reporte significativo a estas dos
partes interesadas, el analista deberá esforzarse por ser
conciso pero completo al preparar el reporte. Los requerimientos
deberán cuantificarse y explicarse de manera
específica.
El analista deberá evitar en el reporte el
lenguaje
técnico y los acrónimos. Deberán anexarse
exposiciones y los documentos de trabajo que se utilizaron en el
análisis de sistemas.
Rocío García