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

1

SalidaModelosEntrada

ControlesTecnologíaB de datos

Usuario Usuario

Usuario

UsuarioUsuario

Usuario

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

2

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

3

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?

4

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

5

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.

6

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

7

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

8

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.

9

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.

10

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.

11

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

12

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:

13

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

14

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

15

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

16

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.

17

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

18

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

19

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.

20

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

21

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.

22

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.

23

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

24

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

25

rapidez en ejecución o para obtener todas las características deseadas que fueron ignoradas al inicio

del proyecto.

26

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

27

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.

28

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.

29

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

30

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.

31

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

32

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?”.

33

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

34

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

35

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

36

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.

37

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

38

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

39

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.

40

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

41

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.

42

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

43

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:

44

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.

45

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

46

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.

47

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.

48

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.

49

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.

50

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

51

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.

52

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

53

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

54

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

55

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.

56

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á

57

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

58

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.

59

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.

60

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.

61

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

-John G. Burch, Gary y Grudnitsky

-Diseño de sistemas de información teoría y práctica

-México /Limusa

62