Determinación de la
frontera de automatización
¿Qué funciones y qué datos se manejarán manualmente, y cuales se
automatizarán?
La frontera de automatización es casi irrelevante en el modelo
esencial pues, aunque el usuario obviamente quiere que se desarrolle un sistema
automatizado, también necesita una declaración bien hecha de los requerimientos
de las funciones y datos que queden justo fuera de la frontera de
automatización.
Hay tres casos extremos que mencionaremos:
- Al usuario pudiera no
importar dónde esté la frontera de automatización.
- El usuario podría escoger un
sistema totalmente automatizado.
- El usuario podría optar por
un sistema completamente manual.
Normalmente estas opciones extremas no ocurren; debido a que se puede
llegar a algún compromiso entre el usuario, analista y el equipo de
implantación. Escogiendo que partes de las actividades del modelo esencial se
automatizarán y cuales funcionarán manualmente. Como ilustran las figuras
8.2.1, pudiera haber diversas alternativas razonables para dibujar la frontera
de automatización. Cada una tendrá diferente costo (que el equipo de
implantación debe estimar, puesto que tiene conocimiento sobre las
posibilidades de la tecnología de implantación) y diferentes ramificaciones
organizacionales en el área del usuario.
No es labor ni del analista ni del equipo de implantación escoger la
frontera de automatización, sino responsabilidad del usuario. Una vez elegida
la frontera de automatización, el analista pudiera darse el lujo de pensar en
eliminar procesos y datos manuales (es decir, aquellas burbujas y almacenes que
no se automatizarán). Pero generalmente esto no es verdad. En el caso más
sencillo, se puede requerir regresar las actividades y los datos manuales a los
terminadores que rodean al sistema.
Finalmente, una vez que se ha escogido la frontera de automatización,
podría ser necesario aumentar el modelo esencial para mostrar cómo se enciende
y apaga el sistema.
Determinación de la interfaz-humana.
Esto involucra cuatro asuntos relacionados:
- La elección de los
dispositivos de entrada y salida.
- El formato de todas las
entradas que fluyen desde los terminadores hasta el sistema.
- El formato de todas las
salidas que fluyen desde el sistema hacia los terminadores.
- La secuencia y los tiempos
de entradas y salidas en un sistema en línea.
Dispositivos de entrada y salida.
La elección de los dispositivos de entrada y salida puede estar
determinada por los terminadores fuera del sistema. Los dispositivos que se
usan típicamente para proporcionar entradas al sistema incluyen los siguientes:
- Tarjetas perforadas.
- Cintas magnéticas.
- Discos flexibles
- Terminales y computadoras
personales.
- Lectores ópticos y lectores
de código de barras.
- Teléfono.
- Voz.
Los dispositivos de salida más usados son los siguientes:
- Salidas impresas.
- Tarjetas perforadas.
- Terminal
- Salida de voz.
- Graficador.
- Cinta magnéticas o disco.
- COM (Microforma para Salidas
de Computadoras).
Formatos de entrada y salida.
Para elaborar los formatos los usuarios informan al analista de "la
manera en la que las cosas tienen que ser". Es así sobre todo si el nuevo
sistema debe comunicarse con otros sistemas o personas externas a la
organización que construye el nuevo sistema. Por ejemplo, las organizaciones
externas o los otros sistemas de cómputo externo pueden proporcionar datos al
sistema nuevo en un formato físico prescrito que no se puede cambiar.
En la 8.3.1 se muestra un ejemplo típico de diagrama que se usa para
modelar la secuencia en pantalla que el usuario final utiliza para comunicarse
con el sistema. ¿Esto es útil sobre todo manejar preguntas como "Puedo
regresar al menú principal desde la imagen de pantalla 12?". Otras
cuestiones de entrada/salida importantes son el acomodo físico de los datos en
la pantalla de vídeo, la naturaleza de los mensajes si se comete un error de
entrada; y el acomodo físico de los datos de salida en la pantalla y los
reportes.
En el caso de sistemas de información computarizados, las siguientes
reglas ayudarán a desarrollar una interfaz amable con el usuario en la mayor
parte de los casos.
- El sistema debe pedir
entradas y producir salidas en forma consistente.
- Pida información con una
secuencia lógica.
- Haga obvio al usuario el
tipo de error que ha cometido, y dónde.
- Distinga entre edición de
campos y ediciones de pantalla.
- Haga la edición y revisión
de errores dependientes del usuario.
- Permita que el usuario pueda
(a) cancelar parte de la transacción y (b) cancelarla toda.
- Proporcione un mecanismo de
"ayuda" conveniente.
- Distinga entre sistemas
guiados por menús y sistemas dirigidos por ordenes; si es apropiado, déle
a escoger al usuario.
- Si el sistema está
realizando un proceso largo, despliegue un mensaje al usuario para que no
crea que se detuvo.
- Proporcione alternativas por
omisión para las entradas estándar.
- Aproveche el color y el
sonido, pero no abuse.
Diseño de formas.
El diseño de los formatos de entrada y salida de un sistema
tradicionalmente se conoce como diseño de formas. Aunque hay muchos estilos
diferentes para las formas, todas deben contener la siguiente información
básica:
- Título, para distinguirla de
cualquier otra.
- Instrucciones, para decir al usuario
cómo poner la información necesaria en la forma.
- Cuerpo, es decir, la parte
principal de la forma, donde se ingresan los datos.
Dependiendo de la aplicación, el analista puede
diseñar formas individuales o de especialidad. Las primeras suelen imprimirse
en hojas sencillas y son adecuadas para la gran mayoría de las situaciones; con
la disponibilidad de los sistemas de edición de escritorio y los programas de
diseño de formas, el usuario y el analista puede diseñar fácilmente sus propias
formas.
Las formas de especialidad son más complejas y se crean con la ayuda de
un diseñador de formas con experiencia. Los tipos de formas de especialidad
son:
- Formas empastadas en libros
(por ejemplo, libros de pedidos de ventas).
- Formas múltiples
desprendibles, con un original y varias copias que se pueden separar (por
ejemplo, formas de cobro de tarjeta de crédito).
- Formas contínuas, que se
llenan manualmente o por computadora.
- Para correo: formas
preimpresas insertas en un sobre, unidas como en forma contínua.
Códigos de entrada y salida.
Como parte de especificar formatos de entrada y salida, el analista
muchas veces debe especificar códigos, es decir, abreviaciones de la
información que sería difícil y tardado describir con detalle. Ejemplos de
éstos son los números del Seguro Social, códigos postales, números de ISBN para
libros publicados y números de identificación de empleados que se asignan a las
compañías en sus declaraciones de impuestos.
Algunos puntos que se deben tomar en cuenta para la codificación de los
datos en un sistema nuevo son:
- Expandible. Debe proporcionar espacio
para entradas adicionales que pudieran requerirse.
- Preciso. Debe identificar al
artículo específico.
- Conciso. Debe ser breve pero
describir adecuadamente al artículo.
- Conveniente. Debe ser fácil de
codificar y decodificar.
- Con significado. Debe ser útil para quienes
lo manejan. De ser posible debe indicar algunas características del
artículo.
- Operable. Debe ser compatible
con los métodos presentes y anticipados de proceso de datos, manual o a
máquina.
Identificación de las
actividades de apoyo manual adicional.
El usuario podría decidir que ciertas porciones del sistema automatizado
estén bajo su propio control operacional (por ejemplo, una PC para su área de
trabajo) y preocuparse por posible errores operacionales que su propio personal
pudiera cometer. Estas actividades de apoyo adicional se representarán por
medio de nuevos procesos en elDFD de comportamiento. En la figura 8.3 se
muestra un ejemplo.
En general, tenemos que preocuparnos por la posibilidad de la
tecnología defectuosa en cuatro áreas principales:
- Ingreso de datos al sistema. Si los datos de entrada se
proporcionan por medio de terminales de vídeo conectados con las
computadoras principales usando líneas de telecomunicaciones, entonces es
posible que algunas o todas las transacciones se pierdan o revuelvan.
- Realización de cálculos. Una vez ingresados los
datos al sistema, existe la remota posibilidad de que la computadora misma
pudiera funcionar mal, y la posibilidad mayor de que un error en los
programas pudiera producir un resultado incorrecto.
- Almacenamiento a largo plazo
de los datos. La
mayor parte de los sistemas guardan información durante largos periodos en
disco magnéticos, cintas magnéticas, discos flexibles, etc. Es posible que
algunos (o todos) estos datos se pierdan o destruyan debido a errores de
hardware y/o software.
- Salida de datos del sistema. Los problemas potenciales
que se pueden dar aquí son análogos a los que se tienen con las entradas
al sistema.
Para resolver este problema pudiera añadir cualquiera de lo siguiente al
modelo esencial:
- Entrada o salida redundante. Esto es la duplicación de
las entradas desde dos fuentes distintas (por ejemplo, de dos usuarios
distintos ante dos terminales distintas).
- Tecnología de procesador
redundante.
Los datos que el sistema mantiene pueden almacenarse, por duplicado, en
dos discos o cintas diferentes. Los cálculos que se realizan podrían
hacerse, por duplicado, en dos procesadores distintos.
- Redundancia interna. Un ejemplo de esto podría
ser: en un sistema bancario en línea el empleado bancario debe pedir tanto
el número de cuenta como el nombre de quien deposita.
- Controles por lote (batch). Para este se requiere
que el usuario mantenga cuenta de las transacciones que ingresa al
sistema, además del total acumulativo de los datos importante en dichas
transacciones.
- Verificaciones secuenciales. El usuario asigna un
número de secuencia o de transacción a casa entrada, y el sistema
verifica, al procesarlas, que estén en secuencia y que no se pierda
ninguna transacción. De manera similar, el sistema puede añadir un número
de secuencia a cada salida que produce, y el usuario verifica manualmente
que no se hayan perdido
Especificación de
restricciones operacionales.
Finalmente, el equipo de implantación tendrá que decidir la combinación
de hardware, sistema operativo, equipo de telecomunicaciones, lenguajes de
programación y estratégia de diseño para implantar mejor los requerimientos.
Pero esto será difícil de lograr sin alguna declaración de restricciones
operativas. Las cuestiones típicas son:
- Volúmen de los datos. El usuario necesita
especificar los volúmenes de transacciones de entrada y el tamaño
requerido de los almacenes de datos.
- Tiempo de respuesta a las
diversas entradas. Esto se puede plantear en términos absolutos, pero es más
realista hacerlo en términos de probabilidades: "el 90% de todas las
transacciones debe tener un tiempo de respuesta menor de 2 segundos".
- Restricciones políticas
sobre modalidades de implantación. El usuario pudiera, por racionales o
irracionales, especificar la marca de hardware que se usará (o que se
evitará), el lenguaje de programación, los proveedores de
telecomunicaciones que se usarán, etc.
- Restricciones ambientales. El usuario que trabaja en
el equipo de implantación pudiera imponer restricciones de temperatura,
humedad, interferencia eléctrica, consumo de energía, limitaciones de
tamaño, etc.
- Restricciones de seguridad y
confiabilidad. El
usuario pudiera especificar un tiempo promedio entre fallas y tiempo
promedio para la reparación para el sistema.
- Restricciones de seguridad. El usuario puede
especificar una variedad de restricciones enfocadas a minimizar el uso no
autorizado del sistema. Esto puede incluir la consideración de números de
cuenta y claves de acceso.
No hay comentarios:
Publicar un comentario