Componentes Estructurales

COMPONENTES ESTRUCTURALES DE LOS SISTEMAS DE INFORMACIÓN

Sin importar las organizaciones a las que sirven o la forma en que se desarrollan y diseñan, todos los sistemas de información están compuestos de los siguientes seis componentes estructurales: entrada, modelos, salida, tecnología, base de datos y controles. Como se ilustra en la figura 1, estos componentes estructurales pueden tomar diferentes formas, valores y contenido; pueden parecer diferentes y trabajar en forma diferente; algunos pueden soportar sistemas bien diseñados; otros pueden soportar sistemas diseñados con deficiencia; algunos pueden ser imperfectos ; algunos pueden ser altamente sofisticados, todo ello es irrelevante. Estos son los seis componentes estructurales básicos de todos los sistemas de información. El qué tan bien se combinen y el tipo de sistema de información que resulte depende del diseñador, que es el arquitecto de los sistemas. Así como un estuche para construcción de juguetes conteniendo unos cuantos componentes básicos que, con adecuada dosis de imaginación, puede transformarse en camiones, aviones, molinos de viento, ruedas de la fortuna puentes, e incluso robots y dinosaurios, los componentes estructurales de sistemas de información pueden conjugarse para obtener sistemas de información funcionales que satisfagan las necesidades de las organizaciones y de sus usuarios . La comprensión de estos componentes estructurales, sus relaciones y acoplamientos y su contenido lógico y físico. proporciona los conocimientos básicos para describir, desarrollar y diseñar sistemas de información. En este momento, y simplemente con fines de definición, se estudiarán brevemente los componentes estructurales.

Bloque de entrada

La entrada representa a todos los datos , texto, voz e imágenes que entran al sistema de información y los métodos y los medios por los cuales se capturan e introducen. La entrada está compuesta de transacciones, solicitudes, consultas, instrucciones y mensajes. Por lo general, la entrada sigue un protocolo y un formato para que el contenido, la identificación, la autorización , el arreglo y el procesamiento sean adecuados. La introducción puede hacerse mediante escritura manual, formas en papel, reconocimiento de características físicas como geometría manual y huellas digitales, teclados, bastones de mando, gatos, ratones, voz, sensores táctiles, y caracteres y códigos ópticos y magnéticos.

Bloque de modelos

Este componente consta de modelos lógico-matemáticos que manipulan de diversas formas la entrada y los datos almacenados, para producir los resultados deseados o salida. Un modelo lógico matemático puede combinar ciertos elementos de datos para proporcionar una respuesta adecuada a una consulta, o puede reducir o agregar volúmenes de datos para obtener un reporte conciso. Puede ser tan simple como : Ganancias=Ingresos-gastos

El componente de modelos también contiene una descripción de algunas de la técnicas de modelado más populares empleadas por los analistas de sistemas para diseñar y documentar las especificaciones de los sistemas. Estas técnicas incluyen tablas para diseñar y documentar las especificaciones de los sistemas. Estas técnicas incluyen tablas y árboles de decisión, diagramas de flujo tradicionales, diagramas de estructura, etc.

Bloque de salida

El producto del sistema de información es la salida información de calidad y documentos para todos los niveles de la gerencia y para todos los usuarios dentro y fuera de la organización. La salida es, en gran medida, el componente que guía e influye en los otros componentes. Si el diseño de este componente no satisface las necesidades del usuario, entonces los otros componentes tienen poca importancia. La salida representa el otro extremo de la entrada y obviamente no puede ser mejor que la entrada y los modelos empleados para producirla. Con frecuencia, la entrada y la salida son interactivas. La entrada se convierte en salida; la salida se convierte en entrada. La bocina de un teléfono es un dispositivo de entrada; el auricular es un dispositivo de salida. El teclado de una máquina de escribir introduce datos; los tipos de impresión producen salida en papel.

De manera lógica, la salida está compuesta de elementos tales como estados financieros, facturas, órdenes de compra, cheques de pago, reportes de presupuestos, respuestas a consultas, mensajes, órdenes, resultados de una toma de decisiones programada, escenarios y simulaciones, y reglas de decisión. La calidad de esta salida se basa en su exactitud, oportunidad y relevancia. Además, esta salida debe tratarse en función de su destino, uso, frecuencia de uso y seguridad.

Bloque de tecnología

La tecnología es la caja de herramientas del trabajo en sistemas de información. Captura la entrada, activa los modelos, almacena y accesa datos produce y transmite salida, y ayuda a controlar todo el sistema. Hace todo el trabajo pesado y une a todos los componentes estructurales. La tecnología consta de tres componentes principales: la computadora y el almacenamiento auxiliar, las telecomunicaciones y el software. Las telecomunicaciones comprende el empleo de medios electrónicos y de transmisión de luz para la comunicación entre nodos a lo largo de una distancia. El software corresponde a los programas que hacen que funcione el hardware de la computadora y le dan instrucciones sobre la forma de procesar los modelos. El hardware está compuesto de una variedad de dispositivos que proporcionan el soporte físico para los componentes estructurales. Por ejemplo, una terminal sirve como dispositivo de entrada para las transacciones contables; una unidad central de procesamiento (CPU) acciona a los modelos contables con datos apropiados; las impresoras localizadas en varias divisiones a lo largo de todo el país y conectadas a la CPU mediante satélites y estaciones terrestres producen como una salida estados contables; un disco magnético en la base de datos almacena los archivos maestros de contabilidad, los diarios y los libros; y un dispositivo codificador y cifrador ayuda a controlar la confidencilidad de la contabilidad y demás información sensible a medida que se transmite y también mientras se almacena en la base de datos. En esencia misma, la tecnología es un sustituto del esfuerzo humano . De los seis componentes estructurales, la tecnología es el más evidente. La mayoría de los sistemas de información actuales y del futuro estarán basados en la tecnología.

Bloque de base de datos

La base de datos es el lugar en donde se almacenan todos los datos necesarios para atender a las necesidades de todos los usuarios. Nuevamente, los datos pueden ser una combinación de voz, imágenes, texto y números. La base de datos se considera desde dos puntos de vista, el físico y el lógico. La base de datos física está compuesta de los medios de almacenamiento, como las cintas, discos, disquetes, casetes, tarjetas magnéticas, pastillas y microfilms. Esta es la forma en que los datos se almacenan realmente. Sin embargo, otro problema probablemente más importante es cómo buscar, asociar y recuperar los datos almacenados para satisfacer necesidades específicas de información. Esto, por supuesto, es el lado lógico de la base de datos y, si está estructurada correctamente, asegura la recuperación oportuna, relevante y exacta de la información. También tiene que ver con el componente de software del sistema e incluye técnicas lógicas y asociativas de datos como índices, directorios, listas, llaves, apuntadores, redes, árboles y relaciones.

Bloque de controles

Todos los sistemas de información están sujetos a una diversidad de peligros y amenazas, como desastres naturales, incendios, fraude, fallas de los sistemas, errores y omisiones, intercepción secreta, deficiencias, sabotajes y mutilaciones maliciosas. En muchos casos, sin embargo, los peores abusos del sistema provienen de procedimientos operacionales inadecuados, empleados incompetentes y una pobre administración. Algunos de los controles que necesitan diseñarse en el sistema para asegurar su protección, integridad y operación uniforme son la instalación de un sistema de administración de registros, la aplicación de controles contables tradicionales, el desarrollo de un plan maestro de sistemas de información, la creación de un plan de contingencias, la aplicación de procedimientos para el personal, como verificación de antecedentes, capacitación, rotación de tareas, vacaciones obligatorias, etc., la preparación de una documentación completa y actualizada, la aplicación de monitores de hardware y software, el establecimiento de sistemas de respaldo y almacenamiento fuera de las instalaciones, la instalación de sistemas ininterrumpidos de energía y sistemas contra incendio, el empleo de adecuados procedimientos de programación y controles, y la aplicación de una diversidad de procedimientos de seguridad, dispositivos y controles de acceso.

¿QUE ES EL ANÁLISIS Y DISEÑO DE SISTEMAS?

Dentro de las organizaciones, el análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de mejorarla con métodos y procedimientos más adecuados. El desarrollo de sistemas puede considerarse, en general, formado por dos grandes componentes: el análisis y el diseño de sistemas. El diseño de sistemas es el proceso de planificar, reemplazar o complementar un sistema organizacional existente. Pero antes de llevar a cabo esta planeación es necesario comprender, en su totalidad, el viejo sistema y determinar la mejor forma en que se pueden , si es posible utilizar las computadoras para hacer la operación más eficiente. El análisis de sistemas, por consiguiente, es el proceso de clasificación e interpretación para recomendar mejoras al sistema. Este es el trabajo del analista de sistemas.

¿QUE HACE UN ANALISTA DE SISTEMAS?

Considere, por ejemplo, las operaciones del almacén de una tienda de ropa. Para tener mejor control del inventario y acceso a información más actualizada con respecto a los niveles de inventario y abastecimiento, la empresa solicita a un analista de sistemas “computarizar” todas las operaciones del almacén. Antes que el analista pueda diseñar un sistema para capturar datos, actualizar archivos y emitir reportes, primero necesita averiguar más acerca de cómo opera el almacén, con que documentación cuanta (requisiciones, pedidos, facturas) para guardar la información manualmente y, qué informes, si es que los hay, se producen y cómo se emplean.

Para seguir adelante, el analista busca información relacionada con las listas de reabastecimiento, pedidos pendientes, registros manuales del almacén y otros reportes. También necesita determinar dónde se origina esta información, ya sea en el departamento de compras, en el propio almacén o en el departamento de contabilidad. En otras palabras el analista debe comprender cómo trabaja el sistema actual y, de manera más específica, cual es el flujo de información en todo el sistema.

Por otra parte, el analista necesita saber los motivos que tiene la tienda para cambiar su modo de operación. ¿Tiene la empresa problemas con el surtido de pedidos, con la mercancía o con el dinero? ¿Se rezaga el registro del inventario? ¿Se necesita un sistema más eficiente como requisito previo para poder aumentar el número de operaciones?.

Sólo después de haber reunido todos los hechos, el analista se encuentra en la posición de determinar cómo y dónde un sistema de información basado en computadora será beneficio para todos los usuarios del sistema. Esta acumulación de información, denominada estudio del sistema, es la que precede a todas las demás actividades del análisis.

Los analistas hacen mucho más que resolver problemas. Con frecuencia se solicita su ayuda para planificar la expansión de la organización. En el caso de la tienda de ropa el estudio de sistemas está orientado hacia el futuro, ya que todavía no existe ningún sistema como tal. El analista valora, de manera cuidadosa, las necesidades futuras de la empresa y los cambios que deben considerarse para satisfacer esas necesidades. En caso, como en muchos otros, los analistas recomiendan opciones para mejorar la situación, siendo lo usual tener varias estrategias posibles.

Al trabajar con los gerentes y empleados de la organización los analistas de sistemas recomiendan qué opciones adoptar de acuerdo con la forma en que adecua la solución a la empresa y su ambiente en particular así como al soporte que, por parte de los empleados, tenga la solución propuesta. Algunas veces el tiempo necesario para desarrollar una opción, comparado con el de otras, es el aspecto más críticos. Los costos y beneficios también son factores determinantes. Al final, la administración, que es la que paga y hace uso de los resultados , es la que decide qué opción aceptar.

Una vez tomada la decisión, se diseña un plan para implantar la recomendación. El plan incluye todas las características de diseño del sistema, tales como las necesidades de captura de nuevos datos, especificaciones de archivo, procedimientos de operaciones y necesidades de equipo y personal. El diseño de sistemas es como los planos de un edificio: especifica todas las características del producto terminado.

Los diseños para el almacén proporcionan las diferentes maneras para capturar datos relacionados con pedidos y ventas, además de especificar la forma en que estos datos serán almacenados, ya sea en documentos diseñados para tal fin o en algún medio donde una computadora los pueda leer, como cintas y discos magnéticos. Los diseños también indican qué trabajos serán efectuados por las personas y cuáles por la computadora. Los diseños cambian en este aspecto de la división del trabajo; depende si éste es hecho por las personas o por las computadoras.

El personal del almacén también necesitará información relacionada con la empresa. Cada diseño describe las diferentes salidas generadas por el sistema, tales como reportes de inventario, análisis de ventas, listas de compradores y facturación. Los analistas de sistemas deciden qué salidas utilizar y cómo generarlas.

El análisis especifica qué es lo que el sistema debe hacer. El diseño establece cómo alcanzar el objetivo.

Nótese que en cada uno de los procesos mencionados participan personas. Los gerentes y empleados tienen buenas ideas con respecto a qué es lo que sí trabaja y qué es lo que no, qué causa problemas y qué no, dónde son necesarios los cambios y dónde no y, especialmente, en que partes el cambio será aceptado y en cuales no. Aún con toda la tecnología, son las personas las piezas más importantes para que una organización trabaje. De esta manera, comunicarse y tratar con las personas es uno de los aspectos muy importantes del trabajo del analista de sistemas.

EL TRABAJO DEL ANALISTA DE SISTEMAS

La descripción dada hasta este momento del análisis de sistemas brinda un panorama de lo que hace el analista. Las responsabilidades de los analistas, sin embargo, así como su denominación dentro de un empresa, cambian de una organización a otra. A continuación se encuentra una lista de las funciones más comunes asignadas a los analistas de sistemas.

1. Análisis de sistemas. En este caso la única responsabilidad del analista es conducir estudios de sistemas para detectar hechos relevantes relacionados con la actividad de la empresa. La función más importante en este caso es reunir información y determinar los requerimientos. Los analistas no son responsables del diseño de sistemas. (Analista de información).

2. Análisis y diseño de sistemas. Además de llevar a cabo el estudio completo de los sistemas, el analista tiene la responsabilidad adicional de diseñar el nuevo sistema. Los que se responsabilizan tanto del análisis como del diseño trabajan en menos proyectos que los analistas de información pero invierten más tiempo en ellos. (diseñadores de sistemas, diseñadores de aplicaciones).

3. Análisis, diseño y programación de sistemas. El analista conduce la investigación de sistemas, desarrolla las especificaciones de diseño y escribe el software necesario para implantar el diseño. (Analista programador).

De lo anterior no se debe concluir que el papel de algunos analistas es superior o inferior al de otros ya que es el tamaño de la organización el que, con bastante frecuencia, dicta la naturaleza del trabajo del analista. En empresas pequeñas, los analistas tienen más funciones que los que trabajan en grandes organizaciones; estos últimos son personas que se especializan en un solo campo, por ejemplo diseño de sistemas. En muchas otras organizaciones la programación la llevan a cabo los programadores de aplicaciones, quienes se especializan en esta parte del proceso de desarrollo de sistemas. Muchos analistas comienzan como programadores y después, una vez que han ganado suficiente experiencia, se convierten en analistas de sistemas.

¿QUE ES UN SISTEMA?

En el sentido más amplio, un sistema es un conjunto de componentes que interaccionan entre sí para lograr un objetivo común. Nuestra sociedad está rodeada de sistemas. Por ejemplo, cualquier persona experimenta sensaciones físicas gracias a un complejo sistema nervioso formado por el cerebro, la médula espinal, los nervios y las células sensoriales especializadas que se encuentran debajo de la piel; estos elementos funcionan en conjunto para hacer que el sujeto experimente sensaciones de frío calor, comezón, etc.Las personas se comunican con el lenguaje, que es un sistema muy desarrollado formado por palabras y símbolos que tienen significado para el que habla y para quienes lo escuchan. Asimismo, las personas viven en un sistema económico en el que se intercambian bienes y servicios por otros de valor comparable y en el que , al menos en teoría, los participantes obtienen un beneficio en el intercambio.

CARACTERÍSTICAS IMPORTANTES DE LOS SISTEMAS

La finalidad de un sistema es la razón de su existencia. Para alcanzar sus objetivos, los sistemas interaccionan con su medio ambiente, el cual está formado por todos los objetos que se encuentran fuera de las fronteras de los sistemas. Los sistemas que interactúan con su medio ambiente (reciben entradas y producen salidas) se denominan sistemas abiertos. En contraste, aquellos que no interactúan con su medio ambiente se conocen como sistemas cerrados . Todos los sistemas actuales son abiertos. Es así como los sistemas cerrados existen sólo como un concepto.

El elemento de control está relacionado con la naturaleza de los sistemas, sean cerrados o abiertos. Los sistema trabajan mejor - “si se encuentran bajo control”- cuando operan dentro de niveles de desempeño tolerables . Por ejemplo, las personas trabajan mejor cuando su temperatura es de 37 grados centígrados. Quizá una desviación de 37 a 37.5 grados no afecte en mucho su desempeño aunque, en algunos casos, la diferencia puede ser notable. Una mayor desviación , sin embargo, tal como una fiebre de 39.5 grados, desencadena un cambio drástico en las funciones corporales. El sistema deja de funcionar y permanece inactivo hasta que se corrija su condición. Si esta condición se prolonga demasiado, los resultados pueden ser fatales para el sistema.

Este ejemplo muestra además la importancia del control en los sistemas de todo tipo. Todos los sistemas tienen niveles aceptables de desempeño, denominados estándares y contra los que se comparan los niveles de desempeño actuales. Siempre deben anotarse las actividades que se encuentran muy por encima o por debajo de los entándares para poder efectuar los ajustes necesarios. La información proporcionada al comparar los resultados con los estándares junto con el proceso de reportar las diferencias a los elementos de control recibe el nombre de retroalimentación.

Para resumir, los sistemas emplean un modelo de control básico consistente en:

1. Un estándar para lograr un desempeño aceptable.

2. Un método para medir el desempeño actual.

3. Un medio para comparar el desempeño actual contra el estándar.

4. Un método de retroalimentación.

Los sistemas que pueden ajustar sus actividades para mantener niveles aceptables continúan funcionando. Aquellos que no lo hacen , tarde o temprano dejan de trabajar.

ESTRATEGIAS PARA EL DESARROLLO DE SISTEMAS

Los sistemas de información basados en computadora sirven para diversas finalidades que van desde el procesamiento de las transacciones de una empresa (la sangre de muchas organizaciones), hasta proveer de la información necesaria para decidir sobre asuntos que se presentan con frecuencia, asistencia a los altos funcionarios con la formulación de estrategias difíciles y la vinculación entre la información de las oficinas y los datos de toda la corporación. En algunos casos los factores que deben considerarse en un proyecto de sistemas de información, tales como el aspecto más apropiado de la computadora o la tecnología de comunicaciones que se van a utilizar, el impacto del nuevo sistema sobre los empleados de la empresa y las características específicas que el sistema debe tener, se pueden determinar de una manera secuencial. En otros casos, debe ganarse experiencia por medio de la experimentación conforme el sistema evoluciona por etapas.

A medida que las computadoras son empleadas cada vez más por personas que no son especialistas en computación, el rostro del desarrollo de sistemas de información adquiere una nueva magnitud. Los propios usuarios emprenden ya el desarrollo de algunos de los sistemas que ellos emplean.

Todas estas situaciones están representadas por tres distintos enfoques al desarrollo de sistemas de información basados en computadora:

1. Método del ciclo de vida para el desarrollo de sistemas.

2. Método del desarrollo del análisis estructurado.

3. Método del prototipo de sistemas.

Esta sección tiene como finalidad explorar cada enfoque, abordando las características del método y las condiciones bajo las que probable que se obtenga el mayor beneficio para la organización. La tabla 1 presenta un resumen de las condiciones para las que cada estrategia tiene la mayor utilidad.

Estrategia de desarrollo Descripción Características de aplicación.

Método del ciclo de vida de desarrollo de sistemas. Incluye las actividades de investigación preliminar, determinación de requerimientos, diseño del sistema, desarrollo de software, prueba de sistemas e implantación. • Requerimientos del sistema de información predecibles.

• Manejable como proyecto.

• Requiere que los datos se encuentren en archivos y bases de datos.

• Gran volumen de transacciones y procesamiento.

• Requiere de la validación de los datos de entrada.

• Abarca varios departamentos

• Tiempo de desarrollo largo

• Desarrollo por equipos de proyecto.

Método del análisis estructurado Se enfoca en lo que el sistema o aplicación realizan sin importar la forma en que llevan a cabo su función (se abordan los aspectos lógicos y no los físicos). Emplean símbolos gráficos para describir el movimiento y procesamiento de datos. Los componentes importantes incluyen los diagramas de flujo de datos y el diccionario de datos. • Adecuado para todo tipo de aplicaciones.

• Mayor utilidad como complemento de otros métodos de desarrollo.

Método del prototipo de sistemas Desarrollo iterativo o en continua evolución donde el usuario participa directamente en el proceso. • Condiciones únicas de la aplicación donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de cometer un error pueden ser altos.

• Asimismo, útil para probar la factibilidad del sistema, identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

El desarrollo de sistemas, un proceso formado por las etapas de análisis y diseño, comienza cuando la administración o algunos miembros del personal encargado de desarrollar sistemas, detectan un sistema de la empresa que necesita mejoras.

El método del ciclo de vida para desarrollo de sistemas (SDLC) es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. Esta sección examina cada una de las seis actividades que constituyen el ciclo de vida de desarrollo de sistemas. En la mayor parte de las situaciones dentro de una empresa todas las actividades están muy relacionadas, en general son inseparables, y quizá sea difícil determinar el orden de los pasos que siguen para efectuarlas. Las diversas partes del proyecto pueden encontrarse al mismo tiempo en distintas fases de desarrollo; algunos componentes en la fase de análisis mientras que otros en etapas avanzadas de diseño.

El método de ciclo de vida para desarrollo de sistemas consta de las siguientes actividades:

1. Investigación preliminar.

2. Determinación de los requerimientos del sistema.

3. Diseño del sistema.

4. Desarrollo de software.

5. Prueba de los sistemas

6. Implantación y evaluación.

Investigación preliminar.

La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones; sin importar cuáles sean éstas, el proceso se inicia siempre con la petición de una persona , administrador, empleado o especialista en sistemas.

Cuando se formula la solicitud comienza la primera actividad de sistemas: la investigación preliminar. Esta actividad tiene tres partes: aclaración de la solicitud, estudio de factibilidad y aprobación de la solicitud.

Aclaración de la solicitud.- Muchas solicitudes que provienen de empleados y usuarios no están formuladas de manera clara. Por consiguiente, antes de considerar cualquier investigación de sistemas, la solicitud de proyecto debe examinarse para determinar con precisión lo que el solicitante desea. Si éste tiene una buena idea de lo que necesita pero no está seguro cómo expresarlo, entonces bastará con hacer una llamada telefónica. Por otro lado, si el solicitante pide ayuda sin saber qué es lo que está mal o dónde se encuentra el problema, la aclaración del mismo se vuelve más difícil. En cualquier caso, antes de seguir adelante, la solicitud de proyecto debe estar claramente planteada.

Estudio de factibilidad.- Un resultado importante de la investigación preliminar es la determinación de que el sistema solicitado sea factible. En la investigación preliminar existen tres aspectos relacionados con el estudio de factibilidad:

1. Factibilidad técnica. El trabajo para el proyecto, ¿puede realizarse con el equipo actual, la tecnología existente de software y el personal dispone? Si se necesita nueva tecnología, ¿Cual es la posibilidad de desarrollarla?.

2. Factibilidad económica.- Al crear el sistema, ¿los beneficios que se obtienen serán suficientes para aceptar los costos?, ¿los costos asociados con la decisión de no crear el sistema son tan grandes que se debe aceptar el proyecto?.

3. Factibilidad operacional. Si se desarrolla e implanta. ¿será utilizado el sistema?, ¿existirá cierta resistencia al cambio por parte de los usuarios que dé como resultado una disminución de los posibles beneficios de la aplicación?.

El estudio de factibilidad lo lleva a cabo un pequeño equipo de personas (en ocasiones una o dos) que está familiarizado con técnicas de sistemas de información; dicho equipo comprende la parte de la empresa u organización que participará o se verá afectada por el proyecto, y es gente experta en los procesos de análisis y diseño de sistemas. En general, las personas que son responsables de evaluar la factibilidad son analistas capacitados o directivos.

Aprobación de la solicitud.- No todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que sólo es posible atender una cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo común es que los miembros del equipo de sistemas se encuentren ocupados con otros proyectos. Cuando este ocurre, la administración decide qué proyectos son los más importantes y decide el orden en que se llevarán a cabo. Muchas organizaciones desarrollan sus panes para sistemas de información con el mismo cuidado con el planifican nuevos productos y programas de fabricación o la expansión de sus instalaciones. Después de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal; con esta información se determina dónde ubicarlo dentro de la lista existente de proyectos.

Determinación de los requerimientos del sistema

El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. (Es por esta razón que el proceso de adquirir información se denomina, con frecuencia, investigación detallada.) Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

1. ¿Qué es lo que se hace?

2. ¿Cómo se hace?.

3. ¿Con que frecuencia se presenta?

4. ¿Qué tan grande es el volumen de transacciones o de decisiones?

5. ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?

6. ¿Existe algún problema?.

7. Si existe un problema, ¿Qué tan serio es?.

8. Si existe un problema, ¿Cuál es la causa que lo origina?

Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa, sus opiniones sobre por qué ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso. Se emplean cuestionarios para obtener esta información cuando no es posible entrevistar, en forma personal, a los miembros de grupos grandes dentro de la organización. Asimismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observación en condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestran de formas y documentos con el fin de comprender el proceso en su totalidad.

Conforme se reúnen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las características que debe tener el nuevo sistema, incluyendo la información que debe producir los sistemas junto con características operacionales tales como controles de procesamiento, tiempos de respuesta y métodos de entrada y salida.

Diseño del sistema

El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la de desarrollo del software, a la que denominan diseño físico.

Los analistas de sistemas comienzan el proceso de diseño identificando los reportes y demás salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisión los datos específicos para cada reporte y salida. Es común que los diseñadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema esté terminado. Lo anterior se efectúa en papel o en la pantalla de una terminal utilizando para ello algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas.

El diseño de un sistema también indica los datos de entrada, aquellos que serán calculados y los que deben ser almacenados. Así mismo, se escriben con todo detalle los procedimientos de cálculo y los datos individuales. Los diseñadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento, tales como discos y cintas magnéticos o incluso archivos en papel. Los procedimientos que se escriben indican cómo procesar los datos y producir las salidas.

Los documentos que contienen las especificaciones de diseño representan a éste de muchas maneras (diagramas, tablas y símbolos especiales). La información detallada del diseño se proporciona al equipo de programación para comenzar la fase de desarrollo de software.

Los diseñadores son los responsables de dar a los programadores las especificaciones de software completa y claramente delineadas. Una vez comenzada la fase de programación, los diseñadores contestan preguntas, aclaran dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseño.

Desarrollo de software

Los encargados de desarrollar software pueden instalar (o modificar y después instalar) software comprado a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Por regla general, los programadores (o analistas programadores) que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. En empresas pequeñas, donde no hay programadores, se pueden contratar servicios externos de programación.

Los programadores también son responsables de la documentación de los programas y de proporcionar una explicación de cómo y por qué ciertos procedimientos se codifican en determinada forma. La documentación es esencial para probar el programa y llevar a cabo el mantenimiento una vez que la aplicación se encuentra instalada.

Prueba de sistemas

Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y después se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema para que los analistas observen si tratan de emplearlo en formas no previstas. Es preferible descubrir cualquier sorpresa antes de que la organización implante el sistema y dependa de él.

En muchas organizaciones, las personas son conducidas por personas ajenas al grupo que escribió los programas originales; con esto se persigue asegurar, por un aparte, que las pruebas sean completas e imparciales y, por otra, que el software sea más confiable.

Implantación y evaluación

La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla.

Dependiendo del tamaño de la organización que empleará la aplicación y el riesgo asociado con su uso, puede elegirse comenzar la operación del sistema sólo en un área de la empresa (prueba piloto), por ejemplo en un departamento o con una o dos personas. Algunas veces se deja que los dos sistemas, el viejo y el nuevo, trabajen en forma paralela con la finalidad de comparar los resultados. En otras circunstancias, el viejo sistema deja de utilizarse determinado día para comenzar a emplear el nuevo al día siguiente. Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas.

Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses. Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones; realizar cambios y modificaciones en el software, archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios. Dado que los sistemas de las organizaciones junto con el ambiente de las empresas experimentan cambios de manera continua, los sistemas de información deben mantenerse siempre al día. En este sentido, la implantación es un proceso en constante evolución.

La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

• Evaluación operacional.- Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, contabilidad global y nivel de utilización.

• Impacto organizacional.- Identificación y medición de los beneficios para la organización en áreas tales como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información interno y externo.

• Opinión de los administradores.- Evaluación de las actitudes de directivos y administradores dentro de la organización así como de los usuarios finales.

• Desempeño del desarrollo.- La evaluación del proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.

Método de desarrollo por análisis estructurado.

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de 1) la división del sistema en componentes y 2) la construcción de un modelo del sistema. El método incorpora elementos tanto de análisis como de diseño.

¿Qué es el análisis estructurado?

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. No se establece cómo se cumplirán los requerimientos o la forma en que implantará la aplicación. Más bien permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadoras, terminales, sistemas de almacenamiento, etc.) Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

Elementos del análisis estructurado

Los elementos esenciales del análisis estructurado son símbolos gráficos, diagramas de datos y el diccionario centralizado de datos.

Descripción gráfica.- Una de las formas de describir un sistema es preparar un bosquejo que señale sus características, identifique la función para la que sirve e indique cómo éste interactúa con otros elementos , entre otras cosas. Sin embargo, describir de esta manera un sistema grande es un proceso tedioso y propenso a errores ya que es fácil omitir algún detalle o dar una explicación que quizá los demás entiendan.

En lugar de las palabras el análisis estructurado utiliza símbolos, o iconos, para crear un modelo gráfico del sistema. Los modelos de éste tipo muestran los detalles del sistema pero sin introducir procesos manuales o computarizados, archivos en cinta o disco magnético, o procedimientos operativos y de programas. Si se seleccionan los símbolos y notación correctos entonces casi cualquier persona puede seguir la forma en que los componentes se acomodarán entre sí para formar el sistema.

Diagramas de flujo de datos.- El modelo del sistema recibe el nombre de diagrama de datos (DFD). La descripción completa de un sistema está formada por un conjunto de diagramas de flujo de datos.

Para desarrollar una descripción del sistema por el método de análisis estructurado se sigue un proceso descendente (top-down). El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujo de datos cada vez más detallados. Esta secuencia se repite hasta que se obtienen suficientes detalles que permiten al analista comprender en su totalidad la parte del sistema que se encuentra bajo investigación.

Diccionario de datos.- Todas las definiciones de los elementos en el sistema , flujo de datos, procesos y almacenes de datos, están descritos en forma detallada en el diccionario de datos. Si algún miembro del equipo encargado del proyecto desea saber alguna definición del nombre de un dato o el contenido particular de un flujo de datos, esta información debe encontrarse disponible en el diccionario de datos.

¿Qué es el diseño estructurado?

El diseño estructurado, otro elemento del análisis estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. La meta del diseño estructurado es crear programas formados por módulos independientes unos de otros desde el punto de vista funcional. Este enfoque no sólo conduce hacia mejores programas sino que facilita el mantenimiento de los mismos cuando surja la necesidad de hacerlo.

El diseño estructurado es una técnica específica para el diseño de programas y no a un método de diseño de comprensión. Es decir, no indica nada relacionado con el diseño de archivos o bases de datos, la presentación de entradas o salidas, la secuencia de procesamiento o el hardware que dará soporte a la aplicación. Esta técnica conduce a la especificación de módulos de programas que son funcionalmente independientes.

La herramienta fundamental del diseño estructurado es el diagrama de flujo estructurado. Al igual que los diagramas de flujo de datos, los diagramas estructurados son de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los diagramas estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interaccionan con él. Estas especificaciones funcionales para los módulos se proporcionan a los programadores antes que dé comienzo la fase de escritura de código.

Empleo del análisis estructurado con otros métodos de desarrollo.- El análisis estructurado se combina con bastante frecuencia, con el método ya presentado de ciclo de vida clásico de desarrollo de sistemas. Por ejemplo, los analistas pueden optar por desarrollar diagramas de flujo de datos como una forma para documentar las relaciones entre componentes durante la investigación detallada de algún sistema existente. Asimismo, se puede definir los archivos y datos en un diccionario centralizado de datos de acuerdo con las reglas del análisis estructurado.

Sin embargo muchas organizaciones optan por no utilizar este método de desarrollo. Por ejemplo, los analistas deciden con frecuencia que el desarrollo de diagramas y esquemas es una tarea que consume mucho tiempo, sobre todo si el sistema es grande y complejo.

Método del prototipo de sistemas

Este método hace que el usuario participe de manera más directa en la experiencia de análisis y diseño que cualquiera de los ya presentados. Tal como ya se indicó, la construcción de prototipos es muy eficaz bajo las circunstancias correctas. Sin embargo, al igual que los otros métodos, el método es útil sólo si se emplea en el momento adecuado y en la forma apropiada.

¿Qué es un prototipo?

El prototipo es un sistema que funciona, no solo una idea en el papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, está constituido por software que acepta entradas, realiza cálculos, produce información ya sea impresa o presentada en una pantalla, o que lleva a cabo otras actividades significativas. Es la primera versión, o iteración, de un sistema de información; es el modelo original.

Los usuarios evalúan el diseño y la información generada por el sistema. Lo anterior sólo puede hacerse con efectividad si los datos utilizados, al igual que las situaciones, son reales. Por otra parte, deben esperarse cambios a medida que el sistema es utilizado.

Razones para desarrollar prototipos de sistemas

Los requerimientos de información no siempre están bien definidos. Es probable que los usuarios conozcan sólo ciertas áreas de la empresa donde se necesiten mejoras o cambios en los procedimientos actuales. También es posible que reconozcan la necesidad de tener mejor información para administrar ciertas actividades pero que no estén seguros cuál de esta información será la adecuada. Los requerimientos del usuario pueden ser demasiado vagos aun al formular el diseño. En otros casos, es probable que una investigación de sistemas bien llevada dé como resultado un conjunto muy amplio de requerimientos de sistemas, pero construir un sistema que satisfaga a todos ellos quizá necesite del desarrollo de nueva tecnología.

Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de diseñar e implantar sistemas no tienen información ni experiencia, o también donde existen situaciones de riesgo y costo elevados, y aquellos donde el diseño propuesto es novedoso y aún no ha sido probado. Por ejemplo, en muchas empresas algo que aún no se demuestra es la factibilidad de que los vendedores envíen órdenes de pedido al sistema de cómputo de la compañía desde el sitio donde efectúan la operación por medio de terminales portátiles enlazadas a teléfonos públicos. Para probar el concepto los administradores y encargados de sistemas pueden optar por construir una versión en pequeña escala del software, adquirir unas cuantas terminales y seleccionar un grupo de vendedores. El prototipo proporcionará información preliminar sobra la funcionalidad del concepto.

El prototipo es, en realidad, un modelo piloto o de prueba; el diseño evoluciona con el uso. Si el empleo del prototipo de ventas revela que se comenten muchos errores, entonces los diseñadores del sistema pueden modificarlo para que sólo sea necesario escribir los nombres de los clientes ya que sus direcciones se pueden obtener en forma automática de los archivos almacenados en el sistema.

Aunque el prototipo es un sistema que funciona, está diseñado para ser modificado con facilidad. La información obtenida con su uso se aplica en un nuevo diseño que se emplea, otra vez, como prototipo y que revela más información valiosa sobre el diseño. El proceso se repite las veces que sea necesario para revelar los requerimientos esenciales del diseño.

En general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad bajo las siguientes condiciones:

• Los encargados de diseñar e implantar sistemas nunca han desarrollado uno con las características del sistema propuesto.

• Se conoce sólo una parte de las características esenciales del sistema; las demás no son identificables a pesar de un cuidadoso análisis de requerimientos.

• La experiencia con el uso del sistema añadirá una lista significativa de requerimientos que el sistema debe satisfacer (más que la que puede obtenerse con cualquier otro método de desarrollo).

• Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo adicional y el refinamiento de sus características.

• Los usuarios del sistema participan en el proceso de desarrollo.

El principio fundamental del desarrollo de prototipos es el siguiente:

Los usuarios pueden señalar las características que les agradaría o no tener, junto con los problemas que presenta un sistema que existe y funciona, con mayor facilidad que si se les pidiese que las describieran en forma teórica o por escrito. El uso y la experiencia producen comentarios más significativos que el análisis de diagramas y las propuestas por escrito.

El desarrollo de prototipos de sistemas es un proceso interactivo. Comienza con unas cuantas funciones y crece al incluir otras que son identificadas con posterioridad. También puede comenzar con un conjunto de funciones que tanto el analista como los usuarios consideraran completo y que puede aumentar o disminuir con el uso y la experiencia.

En general, los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes:

1. Identificar los requerimientos de información que el usuario conoce junto con las características necesarias del sistema.

2. Desarrollar un prototipo que funcione.

3. Utilizar el prototipo anotando las necesidades de cambios y mejoras . Esto expande la lista de los requerimientos de sistemas conocidos.

4. Revisar el prototipo con base en la información obtenida a través de la experiencia del usuario.

5. Repetir los pasos anteriores las veces que sea necesario, hasta obtener un sistema satisfactorio.

Tal como lo sugieren los pasos anteriores, la construcción de prototipos no es un proceso de desarrollo por prueba y error. Antes que dé inicio cualquier actividad de diseño o programación, el analista se reúne con los usuarios una o dos veces con la finalidad de identificar los requerimientos. El resultado de estas reuniones forma la base para la construcción del prototipo.

El desarrollo de un prototipo que funcione es responsabilidad del analista de sistemas. El diálogo de interface permite a los usuarios actuar recíprocamente con el sistema, las rutinas de procesamiento y las salidas deben ser adecuadas (aunque no necesariamente completas) para que las personas puedan comprender cómo utilizar el sistema para realizar estas funciones. Los mensajes y pantallas no incluidos en el prototipo se añaden más tarde, cuando se conoce un conjunto más completo de requerimientos.

Cuando el analista y el usuario deciden que cuentan ya con la suficiente información proveniente del proceso de construcción del prototipo, determinan cómo satisfacer los requerimientos ya identificados. En general, se opta por una de las siguientes cuatro opciones:

1. Volver a desarrollar el prototipo. Esta alternativa quizá signifique volver a programar por completo, empezando desde el principio .

2. Implantar el prototipo como sistema terminado. La eficiencia en el funcionamiento junto con los métodos para interactuar con el usuario son suficientes; esto permite utilizar el sistema tal como está.

3. Abandonar el proyecto.- En este caso el prototipo ha proporcionado información suficiente para demostrar que no es posible desarrollar el sistema para satisfacer los objetivos deseados dentro del marco de la tecnología existente o de lineamientos económicos u operacionales.

4. Iniciar otra serie de construcción de prototipos. La información ganada con la experiencia sugiere ya sea un enfoque totalmente distinto o características contrastantes.

Métodos para el desarrollo de prototipos

Con los prototipos la velocidad de desarrollo es más importante que la eficiencia en el procesamiento. Un sistema prototipo se construye con rapidez, frecuentemente en días o semanas. Por otro lado, el costo asociado con esta tarea es mucho menor comparado con el de un sistema convencional, aun a pesar de no ser tan eficiente como los sistemas desarrollados sobre periodos de meses.

Los sistemas prototipo pueden desarrollarse con métodos y lenguajes de programación convencionales, aunque no contengan todas las características y toques finales que normalmente se incluyen en un sistema terminado. Por ejemplo, en los reportes pueden faltar los encabezados, títulos y números de página. La organización de los archivos puede ser temporal y las estructuras de registro pueden dejarse incompletas. Quizá falten los controles de entrada y procesamiento y , en general, la documentación del sistema es un punto que suele evitarse. Lo importante es ensayar ideas y generar hipótesis relacionadas con los requerimientos y no la eficiencia y perfección alcanzadas.

En algunos casos se toman segmentos de programas que forman parte de otros sistemas o se utilizan librerías de código reutilizable. Por ejemplo, todos los sistemas en línea tienen rutinas de entrada de edición que son muy similares en su estructura de procesamiento, aunque los detalles de las aplicaciones sean diferentes. Durante la construcción de prototipos los analistas enlazan partes de código reutilizable con código que ellos mismos escriben con la finalidad de tener listo el sistema para su operación y evaluación.

La industria de computadoras busca continuamente generadores de aplicaciones, programas que sirven para generar otros programas, para apoyar los esfuerzos de la construcción de prototipos. Estas herramientas automatizan la construcción de sistemas de información, lo que permite a los analistas definir la estructura visual de las pantallas, los registros de entrada y el formato de los reportes; estas especificaciones son procesadas por los generadores de aplicaciones para producir con rapidez, usualmente en cuestión de horas, programas que trabajan.

En algunos casos, aquellos donde el sistema será utilizado con poca frecuencia, el prototipo puede, de hecho, convertirse en el sistema terminado. Una vez que existe acuerdo en los requerimientos o diseños formulados, el sistema puede ser reprogramado para alcanzar mayor rapidez en ejecución o para obtener todas las características deseadas que fueron ignoradas al inicio del proyecto.

ANÁLISIS DE SISTEMAS

El análisis de sistemas llega a la raíz del problema o a la necesidad y define los requerimientos de los usuarios. Con frecuencia, lo que los usuarios creen que necesitan o lo que parece ser el problema al principio, resulta ser algo totalmente diferente después de realizar un análisis profundo. Cuando el analista de sistemas se reúne con los usuarios y ambos empiezan a escarbar, surgen nuevos y en ocasiones diferentes requerimientos que al principio no eran evidentes necesariamente. Y, con mucha frecuencia, aparecen oportunidades de sistemas adicionales.

¿Cuánto tiempo debe dedicarse al análisis de sistemas? Algunos dicen que tan sólo un 10 por ciento del tiempo total de la metodología de desarrollo de sistemas. Otros opinan que hasta un 40 por ciento o más. Otros más piensan que dedicar “demasiado tiempo” al análisis de sistemas da por resultado una “parálisis del análisis”, en donde la víctima no se puede mover de la fase del análisis de sistemas para pasar a otras fases de la SDM debido a la incertidumbre. Pero la certeza es un lujo que los analistas de sistemas raras veces se pueden permitir. En cualquier paso de una fase a otra, siempre existirá algún grado de incertidumbre.

Todos los profesionales de sistemas concuerdan en que las otras fases descansan en lo que se establece en la fase del análisis de sistemas. Esta fase ayuda a asegurar que el sistema de información que se construya será el sistema correcto. En consecuencia, se podría decir que el análisis de sistemas es la fase más importante. En cualquier caso, la base de un sistema de información con el que los usuarios estarán contentos es un buen y completo análisis de sistemas.

ANÁLISIS PRELIMINAR DE SISTEMAS

Después de iniciar un proyecto de sistemas, el analista de sistemas trata de definir su alcance y desarrollar un enfoque profundo en los requerimientos de los usuarios. El documento que resulta de este análisis preliminar es el reporte de la propuesta para realizar el análisis de sistemas. Este documento demuestra que se ha llegado a un acuerdo entre las ideas del analista de sistemas y las de los usuarios.

Razones para iniciar el análisis de sistemas

Los analistas de sistemas deben entender en primer lugar porque se va a realizar un trabajo en sistemas. Las razones básicas para iniciar un análisis de sistemas de sistemas son las siguientes:

1. Mejora de los sistemas de información estratégica. Idealmente, un nuevo trabajo en sistemas se inicia para desarrollar un sistema de información estratégica que no sólo realice el procesamiento de transacciones y otras operaciones, sino que también se ajuste a la estrategia de la organización y da apoyo a las metas de la misma. La mejora de sistemas de información estratégica trae consigo una mayor productividad, una mejor diferenciación de productos y servicios, una mejora en el desempeño gerencial, reducción de costos y reportes más rápidos y más completos. El iniciador de la mejora de sistemas de información estratégica es el plan de sistemas. El principal componente del plan de sistemas es una cartera de proyectos de sistemas prioritarios que hay que desarrollar sobre el horizonte de planeación.

2. Nuevo requerimiento. Un nuevo requerimiento o un nuevo reglamento significa que debe hacerse un trabajo en sistemas para satisfacer dichos requerimientos. Entre los ejemplos se pueden incluir nuevas leyes de impuestos, nuevos procedimientos contables y nuevas cláusulas en la nómina.

3. Aplicación de una nueva idea o tecnología. El analista de sistemas puede realizar un trabajo en sistemas para determinar si una nueva forma de hacer las cosas o un nuevo componente tecnológico pueden mejorar el rendimiento o reducir los costos. Por ejemplo, el analista de sistemas podría investigar el empleo de códigos de barras para el control de inventarios.

4. Solución y mantenimiento de problemas no planeados. En las compañías que no hacen uso de la SISP, el trabajo en sistemas comienza con una necesidad por cubrir, una falla que requiere corrección o un problema que necesita solución. Por lo general, con estas tareas está relacionado un alto grado de urgencia debido a que no se desarrollan planes de sistemas de información que pudieran ayudar a anticipar y coordinar los proyectos de sistemas. En dichos ambientes, el mantenimiento consume una gran parte del presupuesto de sistemas a medida que se retrasan más y más los nuevos proyectos.

Solicitud de un análisis de sistemas

El plan de sistemas contiene una cartera de solicitudes de proyectos de sistemas. Estas solicitudes son muy generales y se emplean principalmente para establecer las prioridades de los proyectos de sistemas y dar una guía general para los esfuerzos en sistemas de información sobre un horizonte de planeación de tres a cinco años.

Sin embargo lo que el analista de sistemas necesita al inicio del análisis de sistemas es algo un poco más específico. En consecuencia, independientemente de la razón para iniciar un análisis de sistemas, todos los proyectos de sistemas deberán empezar con una forma de solicitud de servicios de sistemas de información.

Esta forma para la solicitud no sólo proporciona información acerca del proyecto de sistemas y sus objetivos, sino también de los beneficios anticipados. También sirve como una especie de contrato o acuerdo entre el usuario potencial y el analista de sistemas. Establece también una base para la participación del usuario durante todo el ciclo de la SDM.

En muchos casos, los usuarios y los analistas de sistemas trabajan conjuntamente para completar la forma de solicitud de servicios de sistemas de información. Típicamente, el usuario tiene ideas bastante definidas acerca de la salida requerida, las entradas necesarias, y posiblemente, una noción general de los controles necesarios. El analista de sistemas puede interactuar con el usuario para refinar , agregar y sintetizar estas ideas. Sin embargo, no se espera que todos los detalles del proyecto de sistemas se respondan en este punto. Obviamente, se cubren huecos, y algunos cambios ocurren durante el análisis de sistemas. De hecho, en algunos casos, algunos cambios llegan a ocurrir incluso en la fase del diseño general de sistemas o aun posteriormente. Además, los beneficios anticipados quizás nunca lleguen a materializarse, o bien los beneficios pueden resultar ser mayores que los que se anticiparon inicialmente, No obstante, la forma de solicitud de servicios de sistemas de información proporciona un punto claro de inicio, eliminando de esta forma varias salidas en falso, que es el aspecto principal que se debe evitar en esta etapa.

Incidentalmente, el proyecto de sistemas deberá recibir un nombre o acrónimo corto y llamativo. Un nombre personaliza el proyecto y facilita su referencia. Además, se ha determinado que si los usuarios potenciales asignan el nombre al proyecto de sistemas, entonces éste se convierte en su sistema. Por ejemplo, un nuevo sistema de costos estándar podría denominarse STCCE (Sistema de transacciones de contabilidad de costos estándar). OPPC podría significar organizador y programador de producción computarizado.

Definición del alcance del análisis de sistemas.

¿Cuál debe ser exactamente el alcance de un nuevo proyecto en sistemas? Un analista de sistemas, quien aparentemente tiene mucha experiencia en tratar de responder a esta pregunta, hizo la siguiente observación.

La construcción de un sistema se parece mucho a esculpir la estatua de un elefante. Se consigue un gran bloque de mármol y se empieza a cortar todo aquello que no se parezca a un elefante.

Las actividades y eventos que comprenden el análisis de sistemas se dirigen en su mayor parte a responder la pregunta ¿Qué va a incluir el nuevo sistema?. En muchos casos, esta pregunta se puede plantear con mayor precisión como ¿qué más va a incluir el sistema existente?. Al responder a estas preguntas generales, el analista de sistemas debe plantear muchas preguntas específicas ¿Qué información se necesita?. ¿Quién la necesita?, ¿Cuando?, ¿Dónde?, ¿en qué forma?, ¿en dónde se origina?, ¿cuándo? y ¿cómo puede obtenerse?.

Además , el alcance del análisis de sistemas puede variar ampliamente en términos de duración, complejidad y gastos. En consecuencia, en ocasiones el alcance se debe definir en forma un poco arbitraria para satisfacer restricciones como tiempo y costo. El principal problema tanto para el analista novato compara el profesional experimentado es convertir inconscientemente una instrucción como “deseo saber hoy a las 8:00 AM , cuáles fueron las ventas de ayer “, en “desarrollar un nuevo sistema de reportes de ventas”.

En la práctica, con frecuencia un analista que no logra definir correctamente el alcance del análisis de sistemas fracasa en el logro de los objetivos o los alcanza con una gran pérdida de tiempo y dinero. Sin embargo, se debe entender que la presencia de objetivos limitantes (o restricciones) sobre el alcance del análisis, limita las soluciones o recomendaciones potenciales que resultan del análisis. Como regla, la definición inicial del propósito y el alcance, así como cualquier objetivo y restricción, están sujetos a una redefinición en una fecha posterior, basados en los hallazgos del análisis.

Enfoque del análisis de sistemas

Una de las tentaciones más dañinas presentes en el análisis de sistemas es pensar en términos de computadoras y hacer énfasis primeramente en el componente estructural de la tecnología. El enfoque primario durante el análisis de sistemas debe estar en las operaciones de la empresa, los requerimientos de los usuarios y los componentes estructurales de la entrada, la salida, la base de datos y los controles y no en las computadoras, ni en cintas magnéticas o discos, ni en las telecomunicaciones, ni en el software. Uno de los mayores errores que se repiten una y otra vez en el “trabajo en sistemas” se resume de la siguiente manera: “vamos a conseguir la computadora; luego vamos a ver si existe algún software que pueda correr en ella; y después de eso, vamos a ver como lo vamos a usar” . Es como poner los calcetines sobre los zapatos y, aunque parece ridículo, hay algunas organizaciones que lo hacen todo el tiempo. Una gran instalación gubernamental, por ejemplo, compra nuevo equipo cada tres años. No obstante , su existencia parece cada vez menos productivo y tiene un atraso en nuevos desarrollos medido en años. El tiempo, medido en intervalos de tres años, se convierte en el factor controlador.

El objetivo tanto de los usuarios como de los analistas de sistemas durante el análisis de sistemas es llegar a un acuerdo de ideas para establecer lo que realmente se necesita para realizar el trabajo y lo que el sistema les puede proporcionar. Obviamente , un arquitecto no diseñará un puente o un edificio antes de entender completamente los requerimientos de quienes lo utilizaron y de realizar un estudio completo del ambiente en el que operaron y las leyes y reglamentos que deben observar.

Conclusión del análisis preliminar de sistemas

Una vez que el analista de sistemas completa las entrevistas iniciales y determina que deberá realizarse el análisis de sistemas, se deben comunicar formalmente al solicitante y a la propia gerencia del analista de sistemas el entendimiento de lo que debe realizarse y el enfoque general hacia esta meta. Esta comunicación se denomina reporte de la propuesta para realizar el análisis de sistemas. Proporciona un punto de verificación en el que el solicitante puede evaluar si el analista entiende o no claramente lo que se desea, y le da a la gerencia del analista la oportunidad de evaluar el enfoque y la cantidad de recursos que se van a emplear durante el análisis.

El reporte deberá facilitar una comprensión inicial profunda, así como proporcionar puntos de referencia a los que puedan tener acceso para reportar periódicamente el desempeño real del análisis. Deberá incluir lo siguiente:

1. Una definición clara y concisa de las razones para realizar el análisis.

2. Un planteamiento específico referente a los requerimientos del desempeño del sistema propuesto.

3. Una definición del alcance del análisis.

4. Una identificación de los hechos que probablemente necesiten recopilarse durante el análisis.

5. Una identificación de las fuentes potenciales donde pueden obtenerse los hechos.

6. Un programa que indique los eventos principales del análisis.

FUENTES DE LOS HECHOS DE ESTUDIO PARA EL ANÁLISIS DE SISTEMAS

Tres categorías de hechos de estudio son: (1) el sistema actual, (2) otras fuentes internas y (3) fuentes externas.

Estudio del sistema actual

Es verdaderamente raro que un analista tenga la oportunidad de desarrollar un sistema de información en donde anteriormente no haya existido ninguno. En la mayoría de los casos existe un sistema o un subsistema que da a la organización. Como resultado, el analista se enfrenta con decisión del tipo ¿qué papel desempeña el sistema anterior con respecto al nuevo sistema?, ¿debo analizar el sistema anterior?, si es así ¿qué subsistemas del sistema anterior debo analizar?.

Con gran frecuencia se dedica una gran cantidad de tiempo y dinero investigando, analizando y documentando el sistema anterior, con resultados que parecen aportar muy poco beneficio al diseño del nuevo sistema. No es raro oír el siguiente comentario de gerentes experimentados: “Gastamos $20,000 estudiando el sistema anterior solo para lograr que nos dijera que teníamos razón en solicitar un nuevo sistema “. En otro extremo del espectro, algunos afirman enfáticamente que el primer paso en todos los estudios de sistema consiste en analizar el sistema anterior. Nuevamente , muchos gerentes que han experimentado la conversión a nuevos sistemas comentan: “Nunca consentiré en implementar otro sistema antes de haber analizado completamente mi sistema actual.”.

Aunque puede ser imposible reconciliar completamente estas dos posiciones extremas, un examen de las ventajas puede ayudar a determinar cuándo y qué tan extensamente deberá estudiarse el sistema anterior.

Las principales ventajas de analizar el sistema anterior son las siguientes:

1. Eficacia del sistema actual. El estudio del sistema anterior proporciona una oportunidad para determinar si dicho sistema es satisfactorio, requiere alguna reparación menor, requiere un mantenimiento considerable o debe ser reemplazado. Diseñar un nuevo sistema sin esta consideración podría compararse a comprar un nuevo automóvil sin saber que al auto actual sólo le puede faltar gasolina.

2. Ideas de diseño. El análisis del sistema anterior puede proporcionar al analista una fuente inmediata de ideas para el diseño. Estas ideas incluyen lo que se está haciendo actualmente y en qué forma, así como las necesidades o capacidades adicionales que han sido solicitadas con el paso de los años. El analista puede obtener una mayor comprensión de la forma en que el sistema de información actual sirve a la función de toma de decisión, así como para determinar relaciones clave.

3. Reconocimiento de recursos. El examen del sistema actual le permite al analista identificar los recursos disponibles para el nuevo sistema o subsistema. Estos recursos podrían incluir el talento gerencia, el talento del personal de oficinas y el equipo que se posee actualmente y está en operación.

4. Conocimiento de conversión. Cuando se implemente el nuevo sistema, el analista de sistemas tiene la responsabilidad de haber determinado previamente las tareas y actividades que serán necesarias para ir abandonando gradualmente el sistema anterior y empezara a operar el nuevo sistema. Para identificar estos requerimientos de conversión, el analista debe conocer no solamente qué actividades se realizarán, sino también qué actividades se realizaban. El estudio del sistema actual le da al analista la respuesta al “qué había”.

5. Punto de partida común. Cuando se comunica con la gerencia, el analista de sistema es un agente de cambio. Como tal, el analista con frecuencia se enfrentarán a la resistencia a las nuevas técnicas, ideas y métodos, a la falta de comprensión de los nuevos conceptos, retrasos en la obtención de las decisiones, falta de compromiso para hacer que funcione el nuevo sistema y otras manifestaciones similares de las personas a las que se les solicita que cambien las actividades con las que están familiarizados. Para minimizar estas reacciones, el analista puede comparar y contrastar el nuevo sistema con el sistema anterior y demostrar que éste no es totalmente nuevo.

Las principales desventajas de analizar el sistema anterior son las siguientes:

1. Gastos. El estudio del sistema anterior requiere tiempo, y en todas las organizaciones el tiempo puede convertirse en dinero. Como preguntó un ejecutivo: “¿Por qué nos pasamos meses analizando y modelando el sistema que se va a tirar?”.

2. Barreras innecesarias. Un análisis extenso de un sistema existente puede dar por resultado que se incluyan barreras innecesarias o restricciones artificiales en el diseño del nuevo sistema. Por ejemplo, en el sistema existente en un departamento dado, podría haber un flujo de documentos y una serie de acciones que se realizan con dicho documento. El analista puede involucrarse tanto en la mejora de dichas acciones que la participación del departamento en primer lugar se deja sin cuestionar. Entre más se familiarice un analista con un sistema dado, es más probable que se pierda cierta perspectiva u objetividad con relación a él. Uno podría argumentar lógicamente que un concepto ideal de sistemas deberá emplearse en del trabajo en sistemas. Es decir, el analista formula un sistema ideal y luego procede con su trabajo en sistemas empleando este marco ideal de sistemas.

Fuentes internas

La fuente más importante de hechos de estudio a disposición del analista es la gente. Esto incluye no sólo a la gerencia formal, sino también a los trabajadores de oficinas y de producción. Los requerimientos de información pueden se planteados mejor por los usuarios de la información. Sin embargo, el analista puede ayudar a los usuarios a definir sus requerimientos explicándoles lo que puede proporcionarse. Es importante observar que la mayoría de los individuos se guían en la formulación de sus necesidades por nociones arbitrarias y, con frecuencia, anticuadas de lo que ellos “piensan” que se puede proporcionar. La función del analista, así pues, es la de eliminar o extender estas actitudes a fin de que se puedan obtener los verdaderos requerimientos de información.

Una fuente secundaria de hechos de estudio para el analista proviene del papeleo existente dentro de la organización. El papeleo en la mayoría de las organizaciones puede clasificarse como aquél que describe la forma en que la organización está estructurada, el que describe lo que la organización esta haciendo o ha estado haciendo, y el que describe lo que la organización planea hacer.

Documentos que describen cómo está organizada la empresa Documentos que describen lo que planea hacer la empresa Documentos que describen lo que hace la empresa

Declaraciones de políticas Declaraciones de metas y objetivos Estados financieros

Manuales de métodos y procedimientos Presupuestos Reportes de desempeño

Organigramas Programas Reportes históricos

Descripción de puestos Pronósticos Archivos de transacciones

Delegación de desempeño

Catálogo de cuentas

(Todas las demás referencias en clave de la estructura) Minutas corporativas

(incluyendo ordenes de compra, pedidos de los clientes, facturas, hojas de tiempo,registros de gastos, correspondencia con los clientes)

Conviene mencionar unas palabras de precaución cuando los documentos organizacionales se emplean como hechos de estudio en el análisis de sistemas. Los documentos identificados que describen la forma en que está estructurada una organización y lo que planea hacer, no necesariamente reflejan la realidad. A lo sumo, estos documentos sirven para proporcionar al analista una comprensión de lo que la gerencia consideraba que era su estructura y dirección en un momento dado. No es raro que las organizaciones y los planes cambien, en tanto que su documentación permanece sin modificación.

Una tercera fuente de hechos de estudio importante para el analista puede denominarse relaciones. La definición de las relaciones entre las personas, los departamentos o las funciones, puede proporcionar al analista información e ideas profundas que no se conocían anteriormente o que no se encuentran documentadas en ninguna parte dentro de la organización.

Fuentes externas

El trabajo del analista de sistemas lo puede llevar fuera de los límites del segmento de la organización para el cual se está realizando el análisis. La exploración de otros subsistemas de información dentro de la organización puede ser una fuente útil de recopilación de datos, procesamiento de datos o de ideas y técnicas para el reporte de información. Además, la revisión de otros sistemas proporciona una oportunidad para identificar puntos de interfaz potenciales cuando el analista está involucrado en un análisis limitado o de un subsistema.

Igualmente significativa, aunque con frecuencia se pasa por alto, es una revisión de los sistemas de información similares en otras organizaciones. Esto no solamente puede ser una fuente de nuevas ideas, sino que también puede proporcionar al analista una oportunidad de ver realmente sistemas, subsistemas, conceptos, técnicas y mecanismos en operación. Muchas organizaciones guarden celosamente las técnicas de manufactura y comercialización, pero los intercambios del procesamiento de información son comunes. De hecho, existen muchas sociedades y organizaciones cuyo único propósito es el intercambio de información y experiencias en procesamiento de datos, tanto las buenas como las malas.

Si los analistas de sistemas no tienen un conocimiento profundo de las operaciones de la compañía y el “folklore” de los usuarios, entonces el analista de sistemas probablemente pueda relacionar lo que ellos entienden acerca del proyecto de sistemas actual con otra aplicación familiar. En realidad, la gama de aplicaciones de sistemas no es tan amplia como algunas personas podrían pensar. La elaboración de un sistema de reservaciones para un hotel tiene similitudes con un sistema de reservaciones para una línea aérea o un sistema contable para los pacientes de un hospital. El manejo de apuestas en un hipódromo no es totalmente diferente al empleo de cajeros automáticos. El control de inventarios funciona de una manera muy similar ya sea que se hable de artículos en estantes, casas en calles, o habitaciones en un edificio. Para los corredores de bienes raíces, su inventario son las casas y las propiedades que ellos tienen a la venta. Para los hoteleros, las habitaciones de los hoteles son su inventario. Si los analistas relacionan las diferencias y similitudes de un sistema que conocen con uno que no conocen muy bien, aumentará significativamente su habilidad para imaginarse lo que requiere realmente.

Los libros de texto y las revistas profesionales proporcionan al analista otra fuente más de hechos de estudio. El estudio de este material puede traer consigo la revisión de la teoría conocida y de la práctica o de la investigación sobre nuevas ideas, teorías y propuestas. De manera similar, el analista puede beneficiarse al asistir a seminarios profesionales, talleres y conferencias que se presentan en todo el país.

Los folletos de ventas de los proveedores de equipo y de software de computadoras son una fuente excelente de conceptos e ideas. Cuando se considera que los productos y los servicios se desarrollan y comercializan para satisfacer necesidades, se deduce que los folletos y las propuestas de los proveedores que ofrecen los productos definen las necesidades que pretenden satisfacer.

Las fuentes de hechos de estudio disponibles para un analista durante el análisis de sistemas son variadas y abundantes. La cantidad de fuentes que se exploten diferirá de análisis al considerar las restricciones de tiempo y costo. El tamaño y la complejidad del sistema bajo estudio también ayudará a determinar qué fuentes se van a utilizar. El sentido común es con frecuencia el factor más apremiante al determinar las fuentes de hechos de estudio que el analista seleccione efectivamente. No obstante, es importante reconocer cuál puede ser la elección general de las fuentes.

TÉCNICAS PARA LA RECOPILACIÓN DE HECHOS DE ESTUDIO

La entrevista

En muchos casos , la mejor forma de obtener hechos de estudio críticos consiste en realizar una serie de entrevistas. En general, preguntas tales como: “¿Este reporte le proporciona lo que necesita?” y “¿como podría hacerse esto mejor?” permiten a quienes responden contribuir al análisis. Otras preguntas que generan la base para un trabajo adicional en sistemas son: “¿cuál es el objetivo de su trabajo?” o “¿qué información está obteniendo ahora para ayudarle a cumplir estos objetivos?” o “¿qué información adicional necesita?”.

Es importante que el analista de sistemas se asegure de que cada persona que responde entienda que el objetivo final del trabajo en sistemas es hacer que el nuevo sistema sea más útil. La obtención de hechos significativos y útiles por parte de las personas que responden está en función de una actitud positiva de parte de todos los participantes. Es importante que los analistas de sistemas escuchen activamente a quienes responden . Los tonos y matices sutiles de parte de quienes responden pueden ser tan significativos como su respuesta directa a las preguntas. Finalmente, debido a que el sistema final desarrollado descansará, en gran medida, en los hechos proporcionados por las personas, el sistema no será mejor que los hechos sobre los cuales se basa.

Dentro de una organización, la entrevista es la técnica más significativa y productiva de que dispone el analista para indagación de hechos. En términos sencillos, una entrevista es un intercambio cara-cara de información. Es un canal de comunicación entre el analista y la organización. La entrevista se emplea para obtener información con relación a lo que se requiere y la forma en que estos requerimientos pueden cubrirse. La entrevista puede emplearse para obtener apoyo o comprensión de parte del usuario acerca de una nueva idea o método. Adicionalmente, la entrevista proporciona una oportunidad excelente para que el analista establezca relaciones de armonía con el personal usuario.

La entrevista se realizan a todos los niveles de la organización, desde el presidente o el jefe principal de operaciones hasta el empleado de correspondencia o el ingeniero de mantenimiento. En consecuencia, los procedimientos para las entrevistas pueden ir desde aquellos altamente formales hasta los casuales. Incluso el lugar en donde se realiza la entrevista está sujeto a gran variación. El éxito de la entrevista depende de lo bien que el analista se adapte a estas variables ambientales.

Preparación para la entrevista

Antes de iniciar la entrevista, el analista de sistemas deberá consultar y obtener la cooperación de todos los gerentes de los departamentos que estarán incluidos en el proyecto de sistemas. El analista deberá explicar completamente a los gerentes de departamento el alcance y la naturaleza del análisis y recalcar que este alcance puede estar sujeto a cambios después de una investigación posterior.

Consideramos que varios de los puntos siguientes son útiles en la preparación de una entrevista y en obtener la cooperación y el apoyo necesarios:

1. Convenir una cita por adelantado. No se deberá “caer de sorpresa” simplemente.

2. Identificar la posición del entrevistado dentro de la organización y las responsabilidades y actividades de su trabajo. Fijar la entrevista a una hora que sea conveniente para el entrevistado y en un momento en que no vaya a ser distraído por interrupciones.

3. El objetivo principal de la entrevista es recopilar hechos de estudio. Por lo tanto, se debe preparar un bosquejo de la entrevista, junto con las preguntas pertinentes. Si es conveniente, envíe al entrevistado una copia de las preguntas. No se presente a una entrevista y trate de “tocar de oído”.

Realización de la entrevista

Al realizar la entrevista, el analista deberá comportarse y hacer las preguntas de tal manera que obtenga los hechos de estudio requeridos en el menor tiempo posible. El analista no deberá asumir la posición de “sábelo todo” o aparecer como un interrogador. Antes de proceder a la entrevista, el analista deberá tener un conocimiento suficiente de los deberes y responsabilidades del entrevistado, junto con las relaciones personales y de trabajo del individuo con las demás personas en la organización. Adicionalmente, el analista deberá tener conocimiento de las clases de respuestas que busca y que probablemente reciba. Mucha de esta información proviene de otras entrevistas con la alta gerencia, lo cual supone un enfoque descendente.

Algunos puntos útiles al realizar una entrevista son los siguientes:

1. Explique quién es usted, cuál es el propósito de la entrevista, de qué se trata el proyecto de sistemas, y de qué manera el entrevistado contribuirá al desarrollo de un nuevo sistema. Una pregunta típica para esclarecimiento y subsecuente a esta introducción es : “En este momento, ¿le gustaría saber algo más acerca del proyecto de sistemas?”.

2. Asegúrese de conocer correctamente las responsabilidades y deberes del trabajo del entrevistado. Una pregunta es: “Entiendo que su trabajo consiste en ... (una breve descripción del puesto). ¿Es correcto?.

3. Es importante tratar de determinar el modelo de toma de decisiones del entrevistado (es decir, qué decisiones toma el entrevistado y cómo lo hace). Entre las preguntas típicas están: “Entiendo que, como contador de costos, para preparar un resumen de análisis de costos mensual usted necesita determinar en qué forma se asignaron los gastos telefónicos entre los departamentos. ¿Puede decidir cómo hacer esto con la información que está recibiendo actualmente? Si no es así, ¿Cuál es precisamente la información que necesita y cuántos días antes del cierre?

4. Hasta donde sea posible, trate de hacer preguntas específicas que permitan respuestas cuantitativas. Una pregunta típica es: “¿Cuántos teléfonos tiene actualmente este departamento?”.

5. Evite palabras impresionantes, jerga sin sentido y generalizaciones amplias. Algunas expresiones típicas que deben evitarse son: “Probablemente tengamos que establecer una interfaz entre CRT y un delantero (front-end) XYZ, multiplicado en un modo conversacional en línea con un DASD empleando canales síncronos de banda ancha conectados a nuestra computadora Mod 369 Número 1000, que tiene 100 megabytes de almacenamiento virtual”.

6. Comprenda los sentimientos de la persona que está siendo entrevistada. Aprenda a escuchar bien. Cuídese de no anticipar respuestas antes de que el entrevistado haya tenido tiempo suficiente para responder.

7. Mantenga el control de la entrevista utilizando tacto y discriminación para acabar con vaguedades y comentarios ajenos. Una respuesta típica a lo anterior es: “Regresemos ahora al problema de asignación de costos del que estábamos hablando antes; ¿Propone usted que se utilicen las llamadas de larga distancia como base de la asignación?.”

8. Deben tratarse de aclarar completamente las respuestas vagas a las preguntas. Una declaración típica es: “Por favor, discúlpeme, pero no entiendo muy bien como se propone manejar esto”.

9. Determine si el entrevistado tiene algunas ideas o sugerencias adicionales que posiblemente se hayan omitido. Una pregunta típica es: “¿Tiene algunas sugerencias o recomendaciones adicionales con relación al método empleado para calcular las variaciones presupuestarias?”. Asimismo, determine si el entrevistado desea que se le dé el crédito por sus sugerencias o recomendaciones. Es muy importante que el analista de sistemas dé el crédito correspondiente cuando sea el caso. Una pregunta típica es : “¿Desea que su supervisor o alguien más conozca su sugerencia?”.

10. Al final de la entrevista haga un resumen de los principales puntos de la sesión, dé las gracias al entrevistado e indique que regresará en caso de tener más preguntas. Un método tradicional a disposición del analista , y en ocasiones aceptado, consiste en tomar notas durante la entrevista para registrar diversos puntos, observaciones y respuestas a las preguntas. Así como cuando se toman notas durante una conferencia en la escuela, el analista debe cuidarse de no tomar notas en exceso, ya que se perderían algunas ideas y respuestas que se están presentando. El empleo de grabadora en lugar de las notas por escrito se está volviendo una práctica común. Aunque esto elimina el problema asociado con la toma de notas, la presencia de una grabadora puede poner nervioso al entrevistado y hacer que se cuide mucho al contestar las preguntas. El sentido común es generalmente la mejor guía con que cuenta el analista de sistemas al elegir las técnicas para recopilación de hechos.

Comportamiento del entrevistado Actividad para superarlo

Parece adivinar al responder, en vez de admitir su ignorancia Después de la entrevista, valide las respuestas dudosas

Trata de decirle al analista lo que éste supuestamente desea escuchar, en vez de corregir los hechos Evite plantear preguntas en forma tal que impliquen la repuesta. Valide las respuestas dudosas.

Le da al analista mucha información irrelevante o le cuenta cuentos En forma amable, pero persistente, haga que la discusión regrese a los puntos deseados.

Deja de hablar si ve al analista tomando notas Deje a un lado el cuaderno de notas y limite sus preguntas a las más importantes. En caso necesario, regrese después para obtener más detalles.

Trata de acelerar la entrevista Sugiera regresar más tarde.

Expresa su satisfacción con la forma en que ahora se hacen las cosas y no desea cambios Motive al entrevistado para que se explaye sobre la situación actual y sus virtudes. Tome notas cuidadosamente y haga preguntas acerca de los detalles.

Muestra un resentimiento obvio hacia el analista, responde a las preguntas en forma cautelosa, o parece retener datos. Trate de que el entrevistado hable sobre su propio interés, o sobre su experiencia previa con analistas.

Sabotea la entrevista con una falta de cooperación. De hecho, rehusa dar información. Pregunte al entrevistado. “Si obtengo esta información de alguien más, ¿podría verificarla para mí? Luego continúe con dicho plan.

Se queja de su trabajo, sus socios, sus supervisores y de su trato injusto. Escuche con complacencia y anote aquello que pudiera ser una pista verdadera. No interrumpa hasta que se haya terminado con la lista de quejas. Luego, exprésese en forma amable, pero sin compromisos, como: “En verdad usted tiene muchos problemas. Quizás el estudio pueda ayudar a resolver algunos de ellos”. Este enfoque puede ayudar cubrir el hueco para poder pasar a las preguntas de los hechos deseados. Posteriormente, trata de verificar las quejas para determinar si existen o no bases para las mismas. De esta forma no pasará por alto una buena pista ni se quedará con la impresión de sentirse influenciado indebidamente por pláticas sin fundamento o prejuicios personales.

Muestra una iniciativa y un entusiasmo exagerados acerca de nuevas idea, artefactos y técnicas. Escuche en busca de los hechos deseados y pistas valiosas. No se involucre emocionalmente ni anticipe en la campaña del entrevistado.

El cuestionario

El analista de sistemas puede utilizar un cuestionario en varios momentos durante el proceso de desarrollo de sistemas. Puede ser utilizado en el trabajo de sistemas para obtener un consenso para identificar una dirección o un área para un estudio más profundo para realizar una auditoría posterior a la implementación y para identificar requerimientos específicos pero variables.

Uso del cuestionario

Para descubrir hechos, el cuestionario es un canal un tanto restringido de comunicación y deberá emplearse con gran cuidado. Los analistas deben identificar lo que desean saber, estructurar las preguntas que den por resultado las respuestas a estas necesidades, y preparar y entregar el cuestionario a la persona que lo va a contestar. A diferencia de la entrevista, en un cuestionario el analista no tiene una oportunidad inmediata para volver a considerar comentarios poco claros. Además, el analista no puede dar un seguimiento a comentarios incidentales que podrían muy bien conducir a hechos o ideas adicionales.

El cuestionario puede utilizarse mejor como una herramienta para descubrir hechos cuando el receptor está alejado físicamente del analista y un viaje es prohibitivo para cualquiera de los dos, en los casos en donde hay muchos receptores potenciales y cuando la información pretende verificar información similar recopilada de otras fuentes.

Limitaciones del cuestionario

Las razones de recomendar un uso limitado de los cuestionarios en el análisis de sistemas son numerosos. En primer lugar, es extremadamente difícil estructurar preguntas significativas sin anticipar una cierta respuesta. En segundo lugar, la incapacidad de un seguimiento inmediato tiende a limitar el valor real de este tipo de comunicación. Finalmente, parece que los documentos de estilo general, especialmente los cuestionarios, reciben una prioridad e importancia inferiores por parte de la mayoría de las personas.

Guías para elaborar un cuestionario.

Cuando el analista decide emplear un cuestionario, deberán seguirse unas cuantas, pero importantes guías:

1. Explicar el propósito, el uso, la seguridad y el destino de las respuestas.

2. Proporcionar instrucciones detalladas sobre la forma en que se desea que se contesten las preguntas.

3. Indicar una fecha límite o un plazo para la devolución del cuestionario.

4. Hacer preguntas concisas y concretas.

5. Dar forma a las preguntas de manera que las respuestas pueden tabularse mecánica o manualmente.

6. Proporcionar un espacio suficiente para una respuesta completa.

7. Expresar las preguntas claramente. Por ejemplo, la pregunta: ¿Ha dejado de funcionar incorrectamente su procesador?, puede ser frustante para la persona cuyo procesador nunca ha funcionado mal.

8. Si una pregunta no puede contestarse en forma objetivo, deberá proporcionarse a quien responde la oportunidad de agregar comentarios aclaratorios.

9. Identifique cada cuestionario por nombre de la persona que lo contesta, título del puesto, departamento, etc.

10. Incluya una sección en donde las personas que contestan puedan presentarse sus opiniones y críticas.

Observación

Otra técnica con que cuenta el analista durante la indagación de hechos consiste en observar a las personas en el momento de ejecutar su trabajo. La observación es una técnica para descubrir hechos que tiene una amplia aceptación por parte de los científicos. Los sociólogos, los psicólogos y los ingenieros industriales emplean extensamente esta técnica para estudiar a las personas en actividades en grupos y actividades organizacionales. Los auditores observan diversas cosas como los inventarios. Los artículos que están cubiertos de polvo o están oxidados o que tienen rótulos de un inventario del ano anterior pueden indicar que corresponden a un inventario en exceso, de movimiento lento o que no se puede vender. El propósito de la observación es múltiple. Le permite al analista determinar lo que se está haciendo, la forma en que se hace, quién lo realiza, cuándo, cuánto tiempo requiere, dónde se hace y por qué.

El analista de sistemas puede hacer su observaciones de la siguiente manera. Primeramente, el analista puede hacer un recorrido y tomar notas al azar de personas, cosas y actividades. En segundo lugar, el analista puede observar a una persona o a una actividad sin que se percate de su presencia y sin que haya interacción con el analista. Una observación discreta probablemente tiene poca importancia en el análisis de sistemas ya que es casi imposible que se den las condiciones necesarias. En tercer lugar, el analista puede observar una operación sin que haya interacción, pero en donde la persona que está siendo observada está plenamente consciente de este hecho. Finalmente, el analista puede observar e interactuar con las personas que están siendo observadas. Esta interacción puede consistir simplemente en cuestionar una tarea específica, pedir una explicación, etc.

La observación puede emplearse para verificar lo que se reveló en una entrevista o como paso preliminar para esta última. La observación también es una técnica valiosa para recopilar hechos que representan relaciones. La observación tiende a ser más significativa a nivel del procesamiento de datos en donde las tareas se pueden cuantificar más fácilmente. Las actividades técnicas incluyen tareas relacionadas con la recopilación de datos, su acumulación y transformación. Las actividades de toma de decisiones se pueden entender mejor a través del proceso de la entrevista y el uso del análisis a nivel de decisiones.

Preparación para las observaciones

Antes de iniciar la observación, el analista deberá (1) identificar y definir lo que se va a observar, (2) estimar la cantidad de tiempo que requerirá esta observación, (3)obtener la aprobación apropiada de la gerencia para realizar las observaciones y (4) explicar a las personas que están siendo observadas lo que se va a hacer y el porqué.

Realización de las observaciones

El analista puede realizar las observaciones más eficazmente siguiendo unas cuantas reglas sencillas. Primeramente, el analista deberá familiarizarse con el ambiente físico y los componentes en el área inmediata de observación. En segundo lugar, al hacer las observaciones, el analista deberá anotar periódicamente la hora. En tercer lugar, el analista deberá anotar lo que observa de la manera más específica. Deberá evitarse las generalidades y las descripciones vagas. En cuarto lugar, si el analista está interactuando con las personas que están siendo observadas, entonces deberá abstenerse de hacer comentarios de juicios cualitativos o de valor. Una regla final que deberá seguirse al hacer las observaciones consiste en mostrar una cortesía correcta y hacer caso a las reglas de seguridad.

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 ademá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 observando, con relación a lo que el analista entiende; 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 de terminación del análisis de sistemas.

Sin embargo, quizás la comunicación más importante de todas es el reporte de terminación del análisis de sistemas, que describe los hallazgos del análisis de sistemas. El formato y contenido de este reporte incluye lo siguiente:

1. Una nueva exposición de la razón y el alcance del análisis.

2. Una lista de los principales problemas identificados.

3. Una presentación de todos los requerimientos de los usuarios.

4. Un planteamiento de todas las suposiciones críticas hechas por el analista durante el análisis.

5. Una proyección de los recursos requeridos y los costos esperados que estarán involucrándose en el diseño de cualquier nuevo sistema o en la modificación del sistema actual. Esta proyección incluye la factibilidad de continuar con el trabajo en sistemas.

6. Cualquier recomendación referente al sistema propuesto o a sus requerimientos.

En general, el reporte de terminación del análisis de sistemas está dirigido a dos receptores diferentes. Primeramente, el gerente del analista utiliza el reporte para determinar si el analista ha realizado un trabajo competente en la identificación de los requerimientos de los usuarios y en evaluar la forma en que estos requerimientos entraron en cualquier plan maestro o general para el desarrollo de sistemas en la organización. En segundo lugar, el reporte proporciona a la gerencia general y a la gerencia de los usuarios una oportunidad de 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 conocido 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.

Métodos de presentación oral

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. Cada uno tiene su lugar, pero generalmente el método extemporáneo es el más eficaz.

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 pierda.

El método improvisado es una presentación sin ensayo y no se recomienda en absoluto para la presentación de los reportes de sistemas. Debido a que uno es el autor de estos reportes, se podría considerar que no es necesario revisarlos; sin embargo, si no se hace, se olvidarán los puntos principales y se tenderá a divagar.

La lectura de los reportes puede describirse en una palabra: arrullo; es una pastilla para dormir. Tiene todos los inconvenientes de la memorización, además de la incapacidad para mantener un contacto visual.

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 planeados. Este método ofrece la mejor oportunidad de mantener un contacto visual y establecer relaciones armónicas. Domine completamente su material, desarrolle un bosquejo y parta desde ahí. Con este método, se tiene una fuerte organización por una parte, y flexibilidad y energía por la otra.

El empleo de gráficas, diagramas de flujo, matrices y tablas de decisiones deberá ser una parte integral de la presentación y ayudar a apoyarla. Si se preparan bien, aumentan el entendimiento del auditorio y lo hacen a uno más creíble. Otros auxiliares visuales que pueden ser eficaces son las fotografías, pizarrones y rotafolios, películas, grabaciones, videotapes, prototipos, modelos a escala natural y muestras. Asimismo, las personas pueden ser utilizadas como el auxiliar visual más eficaz de todos, especialmente para demostrar un procedimiento o la forma en que se realiza una tarea. A decir verdad, los auxiliares visuales en ocasiones pueden lograr lo que las palabras no pueden por sí solas.

Resultados finales del análisis de sistemas

Los siguientes son cinco resultados alternativos de cualquier análisis de sistemas particular:

1. - Para 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(s) propuesta(s) no cumple(n) las consideraciones de factibilidad TELOS, debido a un cambio en las decisiones de la gerencia o del solicitante, o debido a un reordenamiento de las prioridades de los sistemas, que dan como resultado que se abandone el proyecto actual.

2. 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.

3. Modificar.- Este resultado significa que la gerencia decide que algunos aspectos de la propuesta se deben cambiar o combinar con otro subsistema.

4. 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 TELOS.

5. 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. Por ejemplo, las restricciones severas impuestas sobre la organización por una acción legislativa y judicial podrían requerir el desarrollo de un sistema independientemente de su costo. O bien, podría ser que algunos objetivos organizacionales más amplios dicten el desarrollo de un sistema que nos ea costo eficaz. Por ejemplo, la gerencia podría estar planeando extenderse en un área que no será lucrativa durante varios años. Un subsistema para el apoyo de esta aventura no será costo-eficaz durante cierto tiempo.

DISEÑO DE SISTEMAS

Especificaciones de los elementos lógicos del diseño

El diseño de sistemas tiene dos etapas: el diseño lógico y la construcción física del sistema. Cuando el analista formula el diseño lógico, escribe las especificaciones detalladas del nuevo sistema, es decir aquellas que describen sus características: salidas, entradas, archivos y bases de datos y los procedimientos, todo en una forma que satisfaga los requerimientos del proyecto. El conjunto formado por todas estas características recibe el nombre de especificaciones de diseño del sistema.

El diseño lógico de un sistema de información es similar al proyecto de ingeniería de un automóvil: muestra las características más sobresalientes ( como el motor, la transmisión y el espacio para los pasajeros) y la relación que guardan entre sí (dónde se conectan los componentes unos a otros o cuál es la separación que existe entre las puertas). Los reportes y salidas generadas por el analista son similares a los componentes de diseño del ingeniero. Los procedimientos y datos se enlazan entre sí para producir un sistema que trabaja.

Al diseñar un sistema de inventarios, por ejemplo, las especificaciones del mismo incluyen definiciones de reportes y pantallas de presentación que describen las existencias disponibles, el abastecimiento y retiro de artículos, y el resumen de transacciones realizadas durante, por ejemplo un mes de operación. El diseño lógico también especifica los formatos de entrada y la distribución de la salida en pantalla para todas las transacciones y archivos que son necesarios para dar mantenimiento a los datos del inventario, a los detalles de las transacciones y a los datos de los proveedores. Las especificaciones de procedimientos describen los métodos utilizados para ingresar datos en el sistema, copiar archivos y detectar problemas, si estos se presentaran .

La construcción física, que es la siguiente actividad después del diseño lógico, produce el software, los archivos y un sistema que funciona. Las especificaciones de diseño indican a los programadores lo que el sistema debe hacer. A su vez, los programadores escriben programas que aceptan la entrada proporcionada por los usuarios, procesan los datos, producen los reportes y guardan los datos en los archivos.

El diseño físico para el sistema de inventarios ya mencionado, está formado por instrucciones de programa, escritas en un lenguaje de programación. Estos pasos revisan los registros de mercancía en existencia utilizando para ello los datos asentados en la transacción, imprimen los reportes y guardan los datos. El analista especifica los algoritmos necesarios para cambiar las cantidades de mercancía en existencia. Durante la construcción física, los programadores escriben las instrucciones necesarias del programa para calcular los cambios y producir los resultados.

QUE CARACTERÍSTICAS SON LAS QUE SE DEBEN DISEÑAR

Las especificaciones de diseño describen las características del sistema, los componentes o elementos del sistema y la forma en que éstos aparecerán ante los usuarios. Para muchos usuarios, el éxito de un sistema está relacionado con la creencia que tengan sobre sí el sistema tiene las características adecuadas.

Esta sección describe las características que debe diseñar el analista de sistemas. Pero antes de considerarlas, es conveniente primero aclarar qué elementos tienen que tomarse en cuenta en las especificaciones formales de diseño.

Elementos del diseño

Los componentes de un sistema de información descritos durante el análisis de requerimientos, son el punto focal del diseño de sistemas. Los analistas deben diseñar los siguientes elementos:

• Flujo de datos.

Movimientos de datos hacia, alrededor y desde el sistema.

• Almacenes de datos

Conjuntos temporales o permanentes de datos

• Procesos

Actividades para aceptar, manejar y suministrar datos e información. Pueden ser manuales o basadas en computadoras.

• 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 están ocurriendo en la forma anticipada o aceptada, es decir si se encuentran “bajo control”. Asimismo, debe especificar las acciones que tienen que emprenderse cuando ocurren problemas o se presentan circunstancias inesperadas. Puede incluirse un reporte sobre las excepciones o procedimientos para la corrección de los problemas.

• Funciones del personal

Las responsabilidades de todas las personas que tienen que ver con el nuevo sistema, incluyendo los usuarios, operadores de computadora y personal de apoyo. Abarca todo el espectro de componentes del sistema, incluso desde la entrada de datos hasta la distribución de salidas o resultados. A menudo, las funciones del personal se establecen en forma de procedimientos.

Como se verá más adelante, estos elementos aparecen una y otra vez en muchas de las características de los sistemas de información. Por consiguiente, todos estos elementos tienen la misma importancia al estructurar el diseño.

Diseño de la salida

El término salida, como es probable que el lector lo conozca, se refiere a los resultados e información generados por el sistema. 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. En realidad, muchos usuarios no operan el sistema de información y tampoco ingresan datos en él, pero utilizan la salida generada por el sistema.

Cuando 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 de la información en un formato aceptable.

• Decidir cómo distribuir la salida entre los posibles destinatarios.

La disposición de la información sobre una pantalla o documento impreso se denomina distribución.

Para llevar a cabo las actividades antes mencionada, se requieren decisiones específicas tales como el empleo de formatos ya impresos cuando se preparan reportes, cuántas líneas planear sobre una página impresa o si se deben emplear gráficas y colores.

El diseño de la salida está especificado en los formularios de distribución, que son hojas que describen la ubicación, características (como longitud y tipo) y formato de los encabezados de columnas y la paginación. Estos elementos son análogos al bosquejo donde el arquitecto indica la localización de cada componente.

Diseño de archivos

El diseño de archivos incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos de tipo histórico o información de referencia. Entre las decisiones que se toman durante el diseño de archivos se encuentran las siguientes:

• Los datos que deben incluirse en el formato de los registros contenidos en el archivo.

• La longitud de cada registro, con base en las características de los datos que contiene.

• La secuencia a disposición de los registros dentro del archivo (la estructura de almacenamiento que puede ser secuencial, indexada o relativa).

No todos los nuevos sistemas de información requieren del diseño de todos los archivos utilizados por la aplicación. Por ejemplo, es probable que ya existan archivos maestros porque éstos son utilizados por otras aplicaciones existentes. Tal vez la nueva aplicación necesite hacer referencia sólo al archivo maestro. En este caso, los detalles del archivo se incluyen en las especificaciones de diseño de la aplicación pero el archivo no vuelve a diseñarse.

Diseño de interacciones con la base de datos

Muchos sistemas de información, ya sea implantados en sistemas de cómputo grandes o pequeños, interactúan con las bases de datos que abarcan varias aplicaciones. Dada la importancia que tienen las bases de datos en muchos sistemas, su diseño es establecido y vigilado por un administrador de base de datos, que es una persona ( o grupo de personas) que tiene la responsabilidad de desarrollar y mantener la base de datos. En estos casos, el analista de sistemas no efectúan el diseño de la base de datos sino que consulta al administrador de la base para determinar las interacciones más apropiadas con la base de datos. El analista proporciona al administrador la descripción de 1) los datos que son necesarios de la base de datos, y 2) las acciones que tendrán efecto sobre la propia base ( por ejemplo, la recuperación de datos, cambios en los valores de los datos o el ingreso de nuevos datos en la base).

Diseño de la entrada

Los analistas de sistemas deciden los siguientes detalles del diseño de entradas:

1. Que datos ingresan al sistema

2. Qué medios utilizar.

3. La forma en que se deben disponer o codificar los datos.

4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos.

5. Validación necesitaría de datos y transacciones para detectar errores.

6. Métodos para llevar a acabo 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. Los analistas deciden si los datos serán proporcionados directamente, quizá a través de una estación de trabajo, o por el uso de documentos, como talones de ventas, cheques bancarios o facturas, donde los datos a su vez son transferidos hacia la computadora para su procesamiento.

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 darán instrucciones al sistema sobre las acciones que debe emprender. Por ejemplo, un usuario que interactúa con el sistema por medio de una estación de trabajo, tiene que ser capaz de indicarle al sistema ya sea que acepte una entrada, genere un reporte o termine el procesamiento.

Los sistemas en línea incluyen un diálogo o conversación entre el usuario y el sistema. Por medio del diálogo, el usuario solicita servicios al sistema y le indica cuándo realizar cierta función. A menudo la naturaleza de la conversación en línea hace la diferencia entre un diseño exitoso y otro inaceptable. Un diseño inapropiado, que deja la pantalla en blanco, confunde al usuario con respecto a qué acción debe emprender.

Diseño de controles

Los analistas de sistemas también deben anticipar los errores que se cometerán al ingresar los datos en el sistema o al solicitar la ejecución de ciertas funciones. Algunos errores no tienen importancia ni consecuencias, pero otros pueden ser tan serios que ocasionarían el borrado de datos o el uso inapropiado del sistema. Aunque exista sólo la más mínima probabilidad de cometer un error serio, un buen diseño de sistemas de información ofrecerá los medios para detectar y manejar el error.

Los controles de entrada proporcionan medios para 1) asegurar que sólo los usuarios autorizados tengan acceso al sistema, 2) garantizar que las transacciones sean aceptables, 3) validar los datos para comprobar su exactitud y 4) determinar si se han omitido datos que son necesarios.

Diseño de procedimientos

Los procedimientos especifican qué tareas deben efectuarse al utilizar el sistema y quienes son los responsables de llevarlas a cabo. Entre los procedimientos importantes se encuentran

• Procedimientos para entrada de datos

Métodos para la captura de datos de las transacciones y su ingreso en el sistema de información (ejem. secuencia para dar entrada a los datos registrados en los documentos fuente).

• Procedimientos durante la ejecución

Pasos y acciones emprendidos por los operadores del sistema y, en ciertos casos, por los usuarios finales que interactúan con el sistema para alcanzar los resultados deseados (ejem. montar paquetes de discos o colocar en las impresoras formas preimpresas).

• Procedimientos para el manejo de errores

Acciones a seguir cuando se presentan resultados inesperados (ejem. ocurre un error cuando el sistema intenta leer datos de un archivo o la impresora se atasca durante la impresión de una gran cantidad de hojas).

• Procedimientos de seguridad y respaldo.

Acciones para proteger al sistema y sus recursos contra posibles daños ( ejem: ¿cuándo y cómo hacer copias de los archivos maestros o de partes de la base de datos?).

Estos procedimientos deben formularse por escrito y formar parte de la documentación del sistema.

Diseño para especificaciones para programas

Las especificaciones para programas son por sí mismas un diseño. Ellas describen cómo transformar las especificaciones de diseño del sistema -salidas, entradas, archivos, procesamiento y otras -- en software de computadora.

El diseño del software de computadora es importante para asegurar que:

• Los programas producidos lleven a cabo todas las tareas y lo hagan en la forma establecida.

• La estructuración del software en módulos permita su prueba y validación para determinar si los procedimientos son correctos.

• Las modificaciones futuras se puedan realizar en forma eficiente y con un mínimo de interrupción en el diseño del sistema.

Un sistema de software en particular será diseñado sólo una vez, pero será usado repetidamente y es muy probable que evolucione en la medida que cambien las necesidades de los usuarios.

En algunas organizaciones, existe una separación entre las responsabilidades del programador y las que tiene el analista. En otras, tanto los programadores como analistas comparten las responsabilidades. Aunque la combinación de responsabilidades facilita la comunicación del diseño a ciertos programadores que trabajan en el proyecto, ésta no elimina los aspectos mencionados hasta este momento.

DISEÑO DE SALIDAS

Como identificar las necesidades de salida del sistema

El diseño de la salida de la computadora debe avanzar en una forma organizada y bien pensada: tiene que desarrollarse correctamente mientras que al mismo tiempo se garantice que cada elemento de la salida está diseñado para que las personas encuentren que el sistema es fácil de emplear.

El término salida se utiliza para denotar cualquier información por un sistema de información, ya sea impresa o en una pantalla. Cuando los analistas diseñan la salida, ellos

• Identifican la salida específica que es necesaria para satisfacer los requerimientos de información.

• Seleccionan los métodos para presentar la información.

• Crean los documentos, reportes u otros formatos que contienen la información producida por el sistema.

Objetivos de la salida

La salida de un sistema de información debe alcanzar uno o más de los siguientes objetivos:

1. Expresar información relacionada con actividades pasadas, estado actual o proyecciones para el futuro.

2. Señalar eventos importantes, oportunidades, problemas o advertencias.

3. Iniciar una acción

4. Confirmar una acción.

El buen diseño de la salida de los sistemas, no puede ser desarrollado en forma independiente del uso que se dará a la salida. En otras palabras, no se puede clasificar como “buena” una salida estéticamente atractiva o que haga uso de una nueva tecnología a menos que satisfaga las necesidades de la organización y de sus usuarios. El propio proceso de diseño comienza cuando el analista de sistema identifica la salida que debe producir el sistema (un proceso que se inicia durante la determinación de requerimientos).

Tipos de salidas

Sin importar si la salida es un reporte o un listado del contenido de un archivo, éste siempre es resultado de un proceso por computadora.

La salida del sistema puede ser:

1. Un reporte.

2. Un documento.

3. Un mensaje.

De acuerdo con las circunstancias y los contenidos, la salida puede ser impresa o presentada en una pantalla.

El contenido de la salida tiene su origen en las siguientes fuentes:

1. Recuperación de un dispositivo de almacenamiento.

2. Transmisión desde un proceso o actividad del sistema.

3. Directamente desde una fuente de entrada.

Aspectos importantes de la salida

Cinco preguntas, a las que debe darse respuesta en forma completa u apropiada, ayudan a los analistas de sistemas a comprender mejor lo que debe ser la salida de un nuevo sistema.

1. ¿Quienes recibirán la salida?

El usuario, ¿forma o no parte de la organización? Quizá los usuarios externos tengan requerimientos específicos que no se pueden cambiar y que dictan los requerimientos de contenido, formato y medio de presentación. Tal vez las organizaciones decidan presentar la misma información en forma diferente cuando está es enviada a los usuarios tanto externos como internos.

2. ¿Cuál es el uso que se le pretende dar?

La salida, ¿presenta información (por ejemplo, un reporte sobre el volumen de ventas), solicita una respuesta (notificación de la renovación de la licencia de manejo), o inicia una acción (notificación de adeudo vencido)? El uso determina el contenido, la forma y el medio a utilizarse para su generación.

3. ¿Cuántos detalles son necesarios?

Pocos detalles son necesarios para indicarle a alguien que renueve una licencia de manejo (nombre, dirección, fecha de renovación, cuota y una identificación de la salida como aviso de renovación). Sin embargo, un informe trimestral de ventas contiene muchos detalles con formatos diferentes que son de ayuda para transmitir un mensaje (qué sucedió, como ocurrió y cuál fue el resultado) a todos los usuarios. Asimismo, la cantidad de datos también sugiere si deben emplear métodos de impresión o de presentación en una pantalla.

4.- ¿Cuándo y con qué frecuencia es necesaria la salida?

El calendario junto con la oportunidad de la salida son guías específicas de diseño. Algunas salidas se producen con poca frecuencia y sólo cuando aparecen ciertas condiciones: la emisión del aviso de renovación de licencia puede ocurrir cada cuatro años, la emisión de una notificación de pago sucede cuando el saldo de la cuenta está vencido. Sin embargo, la organización puede requerir cada mes una salida que indique todas las licencias que deben renovarse el próximo mes, o una salida cada semana que señale todas aquellas cuentas cuyo saldo se venció durante la semana.

5. ¿Qué método utilizar?

La salida, ¿debe ser impresa o presentada en una pantalla? Los ejemplos anteriores muestran que la salida impresa se emplea con bastante frecuencia. Sin embargo, si un sistema da respuesta del tipo sí o no a las consultas (“¿Existe un lugar disponible hoy en el vuelo 130?”), entonces a menudo es apropiado presentar la respuesta en una pantalla. Los sistemas de conmutación electrónica utilizados por muchas compañías telefónicas de Estados Unidos, emplean una salida de audio para informarles sobre un nuevo número telefónico o el cambio de éste. Sin embargo, ¿quién desearía examinar una lista extensa sobre las cantidades de inventario utilizando una salida de audio?.

Para cualquier requerimiento de salida, los analistas de sistemas deben dar respuesta a estas preguntas.

COMO PRESENTAR LA INFORMACIÓN

¿Puede usted capturar la atención de los usuarios sobre las características de la información contenida en la salida de una computadora? La forma en que se presenta la información determinará si la salida es clara y comprensible, si los detalles son convincentes y si la forma de decisiones efectúa con mayor rapidez y exactitud.

Formato tabular

En general , los usuarios finales están más acostumbrados a recibir información en forma de tablas. Los contadores y todos aquellos que revisan datos financieros en forma periódica, dependen casi exclusivamente de información tabular (en un formato que contiene renglones y columnas). La sola mención de la palabra “reporte” sugiere, para muchas personas, un formato tabular. Ejemplos comunes de este tipo de formato son los informes de control de inventarios, cuentas por pagar, contabilidad general, el formato tabular debe utilizarse bajo las siguientes condiciones:

• Cuando los detalles dominan y son necesarios pocos comentarios o explicaciones.

• Cuando los detalles son presentados en categorías discretas.

• Cuando cada categoría debe tener una etiqueta.

• Cuando se deben obtener totales o realizar comparaciones entre diversos componentes.

En un formato tabular cierta información es más importante y, por consiguiente, debe resaltar sobre la demás. Lo anterior cambia de acuerdo con la aplicación pero, en general, se debe estar seguro de que los siguientes aspectos sean los que sobresalgan:

• Excepciones a las expectativas normales.

• Categorías más importantes de actividades o entidades.

• Resúmenes de las categorías o actividades mas importantes

• Identificación única de la información

• Entidades que dependen del tiempo.

Se pueden añadir muchos más aspectos a la lista anterior, lo que depende de la aplicación específica. En cualquier caso, lo importante es garantizar que dichos elementos resalten; el analista de sistemas debe diseñar la salida tabular con la finalidad de alcanzar este objetivo.

Asimismo, se desea presentar la información en un formato que presente los detalles en un orden significativo (quizá de mayor a menor valor, por código postal, u orden alfabético), aquél donde éstos sean más sencillos de localizar. Es fácil colocar muchos detalles sobre un reporte y causar con esto que éste se vea atestado. De hecho, una de la quejas más frecuentes de los usuarios es demasiados detalles y poca información. A menudo, los gerentes comentan que están ahogados en datos, pero muertos por hambre de información.

Formato gráfico

En el mercado se encuentran disponibles sistemas gráficos para computadoras personales hasta mainframes, con una amplia gama de precios y características. Las gráficas empresariales no son por sí mismas una nueva área. Las presentaciones a nivel gerencial han experimentado mejoras desde hace mucho tiempo gracias a las gráficas y medios audiovisuales. Sin embargo, dentro del campo de los sistemas de información basado en computadora, está es un área en continuo crecimiento gracias a la existencia de software muy poderoso y de bajo costo que produce diagramas y gráficas de alta calidad, y que además permite utilizar datos provenientes de las bases de datos. Por otra parte, las gráficas pueden mostrarse en pantallas de video, elaborarse con varios colores en impresoras de bajo costo, dibujar en graficadores o producirse en transparencias de color por medio de cámaras especiales que pueden conectarse a la computadora. Todas estas facilidades se encuentran a disponibilidad de las computadoras personales, con una pequeña inversión, así como para los sistemas de cómputo grandes para los que existe una amplia gama de opciones y costos.

Cuando utilizar gráficas

Las gráficas se emplean por varias razones: 1) para mejorar la efectividad de los reportes que como salida se envían a los usuarios que deben recibirlos . 2) para manejar el volumen de información y 3) para ajustarse a preferencias personales.

Facilidad para la presentación efectiva de datos. Las gráficas son más adecuadas para detectar tendencias en el desempeño de la empresa que los reportes escritos o tabulares. Por ejemplo, las gráficas deben utilizarse para indicar si existe en un gran volumen de clientes la tendencia a comprar más o menos durante un lapso de, por ejemplo, dos años o para evaluar las fluctuaciones en las compras. Las comparaciones también son más fáciles de hacer con gráficas que con datos en forma tabular. Las presentaciones gráficas también facilitan el recordar grandes cantidades de datos asentados en una serie de reportes. Por ejemplo, cuando se trabaja con una serie de reportes, uno al mes por cada vendedor, es mucho más fácil recordar gráficamente la proporción promedio de ventas, en relación con las realizadas a través de llamadas telefónicas.

Manejo del volumen de información. La compresión de grandes cantidades de datos en una gráfica, no disminuye la cantidad de información. El beneficio real de la compresión es que separa la información en grupos más pequeños, lo que permite recordarlos y comprenderlos con mayor facilidad. La información fragmentada aísla los elementos (por ejemplo, el número de saltos o caídas en las ventas) y facilita su comparación.

Satisfacción de preferencias personales. A menudo, a las personas les gusta ver la información más en forma gráfica que en renglones y columnas. Con frecuencia, los inversionistas prefieren tener los precios de las acciones en una gráfica de líneas que en forma tabular. Como analista, el lector debe poner atención en la forma en que, por lo general, se prepara la información en determinado campo o ambiente específico. El diseño de una pantalla que no se adecua a las espectativas, puede confundir a los usuarios de la información y tal vez afectar en forma adversa el desempeño.

Uso de iconos

Los iconos son la representación gráfica de las entidades descritas por los datos. Por ejemplo, se puede utilizar la imagen de un automóvil para notificar las ventas de nuevos modelos de automóviles durante un lapso de 5 años. Se puede representar el nivel de ventas en cada año por medio del tamó del automóvil. De esta forma, se puede mostrar un aumento del doble de ventas en dos años consecutivos por medio de un icono dos veces mayor que otro.

CONCLUSIÓN

En la actualidad, el hecho de conocer la manera de cómo analizar y diseñar sistemas de computación, puede ahorrar grandes cantidades de dinero y tiempo para los procesos de cualquier empresa. Entre más tiempo se dedique al análisis y diseño de sistemas también puede agilizar de una manera notable el desarrollo de sistemas y se tendrán menos contratiempos en las etapas siguientes del ciclo de vida para el desarrollo de sistemas.

Es importante que cualquier persona que tenga experiencia en el desarrollo de sistemas (programación) aprenda de una manera efectiva los procedimientos necesarios para analizar y diseñar sistemas de información. Ya que es una tarea no muy sencilla, se recomienda que a la vez que se encuentre en el desarrollo de sistemas, se valla involucrando cada vez más y más en el proceso de análisis y diseño y cuando se haya obtenido la suficiente experiencia, pueda dirigir el análisis de cualquier sistema.

BIBLIOGRAFIA

-Casillas Cantú Carlos

-Análisis estructurado

-México /itesm

-Senn James A.

-Análisis y diseño de sistemas de iinformación

-México McGraw-Hill

...