Unidad 4

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

Dentro de las organizaciones, el análisis y diseño de sistemas se refiere al proceso de examinar

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

¿QUE HACE UN ANALISTA DE SISTEMAS?

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

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

Por otra parte, el analista necesita saber los motivos que tiene la tienda para cambiar su modo
de operación. ¿Tiene la empresa problemas con el surtido de pedidos, con la mercancía o con el

1
dinero? ¿Se rezaga el registro del inventario? ¿Se necesita un sistema más eficiente como requisito
previo para poder aumentar el número de operaciones?.

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

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

Al trabajar con los gerentes y empleados de la organización los analistas de sistemas

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

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

Los diseños para el almacén proporcionan las diferentes maneras para capturar datos
relacionados con pedidos y ventas, además de especificar la forma en que estos datos serán
almacenados, ya sea en documentos diseñados para tal fin o en algún medio donde una computadora
los pueda leer, como cintas y discos magnéticos. Los diseños también indican qué trabajos serán

2
efectuados por las personas y cuáles por la computadora. Los diseños cambian en este aspecto de la
división del trabajo; depende si éste es hecho por las personas o por las computadoras.

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

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

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

EL TRABAJO DEL ANALISTA DE SISTEMAS

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

1. Análisis de sistemas. En este caso la única responsabilidad del analista es conducir estudios de
sistemas para detectar hechos relevantes relacionados con la actividad de la empresa. La función
más importante en este caso es reunir información y determinar los requerimientos. Los analistas
no son responsables del diseño de sistemas. (Analista de información).
2. Análisis y diseño de sistemas. Además de llevar a cabo el estudio completo de los sistemas, el
analista tiene la responsabilidad adicional de diseñar el nuevo sistema. Los que se responsabilizan
tanto del análisis como del diseño trabajan en menos proyectos que los analistas de información
pero invierten más tiempo en ellos. (diseñadores de sistemas, diseñadores de aplicaciones).

3
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

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

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

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

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

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

2. Un método para medir el desempeño actual.
3. Un medio para comparar el desempeño actual contra el estándar.
4. Un método de retroalimentación.

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

5
6
 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.

7
Estrategia de desarrollo Descripción Características de aplicación.
Método del ciclo de vida de desarrollo de Incluye las actividades de investigación preliminar, • Requerimientos del sistema de información
sistemas. determinación de requerimientos, diseño del sistema, predecibles.
desarrollo de software, prueba de sistemas e implantación. • 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
Método del prototipo de sistemas
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.
Desarrollo iterativo o en continua evolución donde el •
usuario participa directamente en el proceso.
• Asimismo, útil para probar la factibilidad del sistema,
Adecuado para todo tipo de aplicaciones.
Mayor utilidad como complemento de otros métodos
de desarrollo.
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.
identificar los requerimientos del usuario, evaluar el
diseño de un sistema o examinar el uso de una
aplicación.

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

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

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

8
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:

9
1. Factibilidad técnica. El trabajo para el proyecto, ¿puede realizarse con el equipo actual, la tecnología
existente de software y el personal dispone? Si se necesita nueva tecnología, ¿Cual es la posibilidad
de desarrollarla?.
2. Factibilidad económica.- Al crear el sistema, ¿los beneficios que se obtienen serán suficientes para
aceptar los costos?, ¿los costos asociados con la decisión de no crear el sistema son tan grandes
que se debe aceptar el proyecto?.
3. Factibilidad operacional. Si se desarrolla e implanta. ¿será utilizado el sistema?, ¿existirá cierta
resistencia al cambio por parte de los usuarios que dé como resultado una disminución de los
posibles beneficios de la aplicación?.

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

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

Determinación de los requerimientos del sistema

El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de
la parte de la empresa que se encuentra bajo estudio. (Es por esta razón que el proceso de adquirir
información se denomina, con frecuencia, investigación detallada.) Los analistas, al trabajar con los

10
empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las
siguientes preguntas clave:

1. ¿Qué es lo que se hace?

2. ¿Cómo se hace?.
3. ¿Con que frecuencia se presenta?
4. ¿Qué tan grande es el volumen de transacciones o de decisiones?
5. ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
6. ¿Existe algún problema?.
7. Si existe un problema, ¿Qué tan serio es?.
8. Si existe un problema, ¿Cuál es la causa que lo origina?

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

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

Diseño del sistema

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

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

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

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

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

Desarrollo de software

Los encargados de desarrollar software pueden instalar (o modificar y después instalar)

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

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

Prueba de sistemas

Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para

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

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

Implantación y evaluación

La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios,

instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla.

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

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

La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La

evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

• Evaluación operacional.- Valoración de la forma en que funciona el sistema, incluyendo su

facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, contabilidad
global y nivel de utilización.
• Impacto organizacional.- Identificación y medición de los beneficios para la organización en áreas
tales como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo.
También se incluye el impacto sobre el flujo de información interno y externo.
• Opinión de los administradores.- Evaluación de las actitudes de directivos y administradores dentro
de la organización así como de los usuarios finales.
• Desempeño del desarrollo.- La evaluación del proceso de desarrollo de acuerdo con criterios tales
como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios
de administración de proyectos. También se incluye la valoración de los métodos y herramientas
utilizados en el desarrollo.

Método de desarrollo por análisis estructurado.

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de

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

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

Elementos del análisis estructurado

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

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

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

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

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

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

¿Qué es el diseño estructurado?

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

El diseño estructurado es una técnica específica para el diseño de programas y no a un método

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

La herramienta fundamental del diseño estructurado es el diagrama de flujo estructurado. Al

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

Empleo del análisis estructurado con otros métodos de desarrollo.- El análisis estructurado se
combina con bastante frecuencia, con el método ya presentado de ciclo de vida clásico de desarrollo
de sistemas. Por ejemplo, los analistas pueden optar por desarrollar diagramas de flujo de datos como
una forma para documentar las relaciones entre componentes durante la investigación detallada de

16
algún sistema existente. Asimismo, se puede definir los archivos y datos en un diccionario
centralizado de datos de acuerdo con las reglas del análisis estructurado.

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

Método del prototipo de sistemas

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

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

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

Razones para desarrollar prototipos de sistemas

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

17
muy amplio de requerimientos de sistemas, pero construir un sistema que satisfaga a todos ellos quizá
necesite del desarrollo de nueva tecnología.

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

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

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

En general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad bajo
las siguientes condiciones:
• Los encargados de diseñar e implantar sistemas nunca han desarrollado uno con las características
del sistema propuesto.
• Se conoce sólo una parte de las características esenciales del sistema; las demás no son identificables
a pesar de un cuidadoso análisis de requerimientos.
• La experiencia con el uso del sistema añadirá una lista significativa de requerimientos que el sistema
debe satisfacer (más que la que puede obtenerse con cualquier otro método de desarrollo).
• Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo
adicional y el refinamiento de sus características.

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

El principio fundamental del desarrollo de prototipos es el siguiente:

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

El desarrollo de prototipos de sistemas es un proceso interactivo. Comienza con unas cuantas

funciones y crece al incluir otras que son identificadas con posterioridad. También puede comenzar
con un conjunto de funciones que tanto el analista como los usuarios consideraran completo y que
puede aumentar o disminuir con el uso y la experiencia.
En general, los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes:
1. Identificar los requerimientos de información que el usuario conoce junto con las características
necesarias del sistema.
2. Desarrollar un prototipo que funcione.
3. Utilizar el prototipo anotando las necesidades de cambios y mejoras . Esto expande la lista de los
requerimientos de sistemas conocidos.
4. Revisar el prototipo con base en la información obtenida a través de la experiencia del usuario.
5. Repetir los pasos anteriores las veces que sea necesario, hasta obtener un sistema satisfactorio.

Tal como lo sugieren los pasos anteriores, la construcción de prototipos no es un proceso de

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

El desarrollo de un prototipo que funcione es responsabilidad del analista de sistemas. El

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

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

1. Volver a desarrollar el prototipo. Esta alternativa quizá signifique volver a programar por completo,
empezando desde el principio .
2. Implantar el prototipo como sistema terminado. La eficiencia en el funcionamiento junto con los
métodos para interactuar con el usuario son suficientes; esto permite utilizar el sistema tal como
está.
3. Abandonar el proyecto.- En este caso el prototipo ha proporcionado información suficiente para
demostrar que no es posible desarrollar el sistema para satisfacer los objetivos deseados dentro del
marco de la tecnología existente o de lineamientos económicos u operacionales.
4. Iniciar otra serie de construcción de prototipos. La información ganada con la experiencia sugiere
ya sea un enfoque totalmente distinto o características contrastantes.

Métodos para el desarrollo de prototipos

Con los prototipos la velocidad de desarrollo es más importante que la eficiencia en el

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

Los sistemas prototipo pueden desarrollarse con métodos y lenguajes de programación

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

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

La industria de computadoras busca continuamente generadores de aplicaciones, programas

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

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

21
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

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

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

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

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

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

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

Enfoque del análisis de sistemas

Una de las tentaciones más dañinas presentes en el análisis de sistemas es pensar en términos de
computadoras y hacer énfasis primeramente en el componente estructural de la tecnología. El enfoque
primario durante el análisis de sistemas debe estar en las operaciones de la empresa, los requerimientos
de los usuarios y los componentes estructurales de la entrada, la salida, la base de datos y los controles
y no en las computadoras, ni en cintas magnéticas o discos, ni en las telecomunicaciones, ni en el
software. Uno de los mayores errores que se repiten una y otra vez en el “trabajo en sistemas” se

25
resume de la siguiente manera: “vamos a conseguir la computadora; luego vamos a ver si existe algún
software que pueda correr en ella; y después de eso, vamos a ver como lo vamos a usar” . Es como
poner los calcetines sobre los zapatos y, aunque parece ridículo, hay algunas organizaciones que lo
hacen todo el tiempo. Una gran instalación gubernamental, por ejemplo, compra nuevo equipo cada
tres años. No obstante , su existencia parece cada vez menos productivo y tiene un atraso en nuevos
desarrollos medido en años. El tiempo, medido en intervalos de tres años, se convierte en el factor
controlador.

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

Conclusión del análisis preliminar de sistemas

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

El reporte deberá facilitar una comprensión inicial profunda, así como proporcionar puntos de
referencia a los que puedan tener acceso para reportar periódicamente el desempeño real del análisis.
Deberá incluir lo siguiente:
1. Una definición clara y concisa de las razones para realizar el análisis.
2. Un planteamiento específico referente a los requerimientos del desempeño del sistema propuesto.
3. Una definición del alcance del análisis.
4. Una identificación de los hechos que probablemente necesiten recopilarse durante el análisis.
5. Una identificación de las fuentes potenciales donde pueden obtenerse los hechos.
6. Un programa que indique los eventos principales del análisis.

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

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

Estudio del sistema actual

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

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

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

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

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

27
2. Ideas de diseño. El análisis del sistema anterior puede proporcionar al analista una fuente inmediata
de ideas para el diseño. Estas ideas incluyen lo que se está haciendo actualmente y en qué forma,
así como las necesidades o capacidades adicionales que han sido solicitadas con el paso de los años.
El analista puede obtener una mayor comprensión de la forma en que el sistema de información
actual sirve a la función de toma de decisión, así como para determinar relaciones clave.
3. Reconocimiento de recursos. El examen del sistema actual le permite al analista identificar los
recursos disponibles para el nuevo sistema o subsistema. Estos recursos podrían incluir el talento
gerencia, el talento del personal de oficinas y el equipo que se posee actualmente y está en operación.
4. Conocimiento de conversión. Cuando se implemente el nuevo sistema, el analista de sistemas tiene
la responsabilidad de haber determinado previamente las tareas y actividades que serán necesarias
para ir abandonando gradualmente el sistema anterior y empezara a operar el nuevo sistema. Para
identificar estos requerimientos de conversión, el analista debe conocer no solamente qué
actividades se realizarán, sino también qué actividades se realizaban. El estudio del sistema actual
le da al analista la respuesta al “qué había”.
5. Punto de partida común. Cuando se comunica con la gerencia, el analista de sistema es un agente
de cambio. Como tal, el analista con frecuencia se enfrentarán a la resistencia a las nuevas técnicas,
ideas y métodos, a la falta de comprensión de los nuevos conceptos, retrasos en la obtención de las
decisiones, falta de compromiso para hacer que funcione el nuevo sistema y otras manifestaciones
similares de las personas a las que se les solicita que cambien las actividades con las que están
familiarizados. Para minimizar estas reacciones, el analista puede comparar y contrastar el nuevo
sistema con el sistema anterior y demostrar que éste no es totalmente nuevo.

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

1. Gastos. El estudio del sistema anterior requiere tiempo, y en todas las organizaciones el tiempo
puede convertirse en dinero. Como preguntó un ejecutivo: “¿Por qué nos pasamos meses analizando
y modelando el sistema que se va a tirar?”.
2. Barreras innecesarias. Un análisis extenso de un sistema existente puede dar por resultado que se
incluyan barreras innecesarias o restricciones artificiales en el diseño del nuevo sistema. Por
ejemplo, en el sistema existente en un departamento dado, podría haber un flujo de documentos y
una serie de acciones que se realizan con dicho documento. El analista puede involucrarse tanto en
la mejora de dichas acciones que la participación del departamento en primer lugar se deja sin
cuestionar. Entre más se familiarice un analista con un sistema dado, es más probable que se pierda
cierta perspectiva u objetividad con relación a él. Uno podría argumentar lógicamente que un

28
 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á Documentos que describen lo que Documentos que describen lo que hace
organizada la empresa planea hacer la empresa la empresa
Declaraciones de políticas Declaraciones de metas y objetivos Estados financieros
Manuales de métodos y procedimientos Presupuestos Reportes de desempeño
Organigramas Programas Reportes históricos
Descripción de puestos Pronósticos Archivos de transacciones
Delegación de desempeño Minutas corporativas (incluyendo ordenes de compra, pedidos
Catálogo de cuentas de los clientes, facturas, hojas de
(Todas las demás referencias en clave de la tiempo,registros de gastos,
estructura) 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

29
de lo que la gerencia consideraba que era su estructura y dirección en un momento dado. No es raro
que las organizaciones y los planes cambien, en tanto que su documentación permanece sin
modificación.

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

Fuentes externas

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

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

Si los analistas de sistemas no tienen un conocimiento profundo de las operaciones de la

compañía y el “folklore” de los usuarios, entonces el analista de sistemas probablemente pueda
relacionar lo que ellos entienden acerca del proyecto de sistemas actual con otra aplicación familiar.
En realidad, la gama de aplicaciones de sistemas no es tan amplia como algunas personas podrían
pensar. La elaboración de un sistema de reservaciones para un hotel tiene similitudes con un sistema
de reservaciones para una línea aérea o un sistema contable para los pacientes de un hospital. El

30
manejo de apuestas en un hipódromo no es totalmente diferente al empleo de cajeros automáticos. El
control de inventarios funciona de una manera muy similar ya sea que se hable de artículos en estantes,
casas en calles, o habitaciones en un edificio. Para los corredores de bienes raíces, su inventario son
las casas y las propiedades que ellos tienen a la venta. Para los hoteleros, las habitaciones de los hoteles
son su inventario. Si los analistas relacionan las diferencias y similitudes de un sistema que conocen
con uno que no conocen muy bien, aumentará significativamente su habilidad para imaginarse lo que
requiere realmente.

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

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

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

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

La entrevista

En muchos casos , la mejor forma de obtener hechos de estudio críticos consiste en realizar
una serie de entrevistas. En general, preguntas tales como: “¿Este reporte le proporciona lo que

31
necesita?” y “¿como podría hacerse esto mejor?” permiten a quienes responden contribuir al análisis.
Otras preguntas que generan la base para un trabajo adicional en sistemas son: “¿cuál es el objetivo de
su trabajo?” o “¿qué información está obteniendo ahora para ayudarle a cumplir estos objetivos?” o
“¿qué información adicional necesita?”.

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

Dentro de una organización, la entrevista es la técnica más significativa y productiva de que

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

La entrevista se realizan a todos los niveles de la organización, desde el presidente o el jefe

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

Preparación para la entrevista

Antes de iniciar la entrevista, el analista de sistemas deberá consultar y obtener la cooperación

de todos los gerentes de los departamentos que estarán incluidos en el proyecto de sistemas. El analista

32
deberá explicar completamente a los gerentes de departamento el alcance y la naturaleza del análisis
y recalcar que este alcance puede estar sujeto a cambios después de una investigación posterior.

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

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

2. Identificar la posición del entrevistado dentro de la organización y las responsabilidades y
actividades de su trabajo. Fijar la entrevista a una hora que sea conveniente para el entrevistado y
en un momento en que no vaya a ser distraído por interrupciones.
3. El objetivo principal de la entrevista es recopilar hechos de estudio. Por lo tanto, se debe preparar
un bosquejo de la entrevista, junto con las preguntas pertinentes. Si es conveniente, envíe al
entrevistado una copia de las preguntas. No se presente a una entrevista y trate de “tocar de oído”.

Realización de la entrevista

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

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

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

33
2. Asegúrese de conocer correctamente las responsabilidades y deberes del trabajo del entrevistado.
Una pregunta es: “Entiendo que su trabajo consiste en ... (una breve descripción del puesto). ¿Es
correcto?.
3. Es importante tratar de determinar el modelo de toma de decisiones del entrevistado (es decir, qué
decisiones toma el entrevistado y cómo lo hace). Entre las preguntas típicas están: “Entiendo que,
como contador de costos, para preparar un resumen de análisis de costos mensual usted necesita
determinar en qué forma se asignaron los gastos telefónicos entre los departamentos. ¿Puede
decidir cómo hacer esto con la información que está recibiendo actualmente? Si no es así, ¿Cuál es
precisamente la información que necesita y cuántos días antes del cierre?
4. Hasta donde sea posible, trate de hacer preguntas específicas que permitan respuestas cuantitativas.
Una pregunta típica es: “¿Cuántos teléfonos tiene actualmente este departamento?”.
5. Evite palabras impresionantes, jerga sin sentido y generalizaciones amplias. Algunas expresiones
típicas que deben evitarse son: “Probablemente tengamos que establecer una interfaz entre CRT y
un delantero (front-end) XYZ, multiplicado en un modo conversacional en línea con un DASD
empleando canales síncronos de banda ancha conectados a nuestra computadora Mod 369 Número
1000, que tiene 100 megabytes de almacenamiento virtual”.
6. Comprenda los sentimientos de la persona que está siendo entrevistada. Aprenda a escuchar bien.
Cuídese de no anticipar respuestas antes de que el entrevistado haya tenido tiempo suficiente para
responder.
7. Mantenga el control de la entrevista utilizando tacto y discriminación para acabar con vaguedades
y comentarios ajenos. Una respuesta típica a lo anterior es: “Regresemos ahora al problema de
asignación de costos del que estábamos hablando antes; ¿Propone usted que se utilicen las llamadas
de larga distancia como base de la asignación?.”
8. Deben tratarse de aclarar completamente las respuestas vagas a las preguntas. Una declaración típica
es: “Por favor, discúlpeme, pero no entiendo muy bien como se propone manejar esto”.
9. Determine si el entrevistado tiene algunas ideas o sugerencias adicionales que posiblemente se
hayan omitido. Una pregunta típica es: “¿Tiene algunas sugerencias o recomendaciones adicionales
con relación al método empleado para calcular las variaciones presupuestarias?”. Asimismo,
determine si el entrevistado desea que se le dé el crédito por sus sugerencias o recomendaciones. Es
muy importante que el analista de sistemas dé el crédito correspondiente cuando sea el caso. Una
pregunta típica es : “¿Desea que su supervisor o alguien más conozca su sugerencia?”.
10.Al final de la entrevista haga un resumen de los principales puntos de la sesión, dé las gracias al
entrevistado e indique que regresará en caso de tener más preguntas. Un método tradicional a

34
 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
Trata de decirle al analista lo que éste supuestamente desea escuchar, en vez de corregir
los hechos
Le da al analista mucha información irrelevante o le cuenta cuentos
Deja de hablar si ve al analista tomando notas
Trata de acelerar la entrevista
Expresa su satisfacción con la forma en que ahora se hacen las cosas y no desea cambios
Muestra un resentimiento obvio hacia el analista, responde a las preguntas en forma
cautelosa, o parece retener datos.
Sabotea la entrevista con una falta de cooperación. De hecho, rehusa dar información.
Se queja de su trabajo, sus socios, sus supervisores y de su trato injusto.
Muestra una iniciativa y un entusiasmo exagerados acerca de nuevas idea, artefactos y
técnicas.
Después de la entrevista, valide las respuestas dudosas
Evite plantear preguntas en forma tal que impliquen la repuesta. Valide
las respuestas dudosas.
En forma amable, pero persistente, haga que la discusión regrese a los
puntos deseados.
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.
Sugiera regresar más tarde.
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.
Trate de que el entrevistado hable sobre su propio interés, o sobre su
experiencia previa con analistas.
Pregunte al entrevistado. “Si obtengo esta información de alguien más,
¿podría verificarla para mí? Luego continúe con dicho plan.
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.
Escuche en busca de los hechos deseados y pistas valiosas. No se
involucre emocionalmente ni anticipe en la campaña del entrevistado.

El cuestionario

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

Uso del cuestionario

Para descubrir hechos, el cuestionario es un canal un tanto restringido de comunicación y deberá

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

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

Limitaciones del cuestionario

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

Guías para elaborar un cuestionario.

36
 Cuando el analista decide emplear un cuestionario, deberán seguirse unas cuantas, pero importantes
guías:
1. Explicar el propósito, el uso, la seguridad y el destino de las respuestas.
2. Proporcionar instrucciones detalladas sobre la forma en que se desea que se contesten las preguntas.
3. Indicar una fecha límite o un plazo para la devolución del cuestionario.
4. Hacer preguntas concisas y concretas.
5. Dar forma a las preguntas de manera que las respuestas pueden tabularse mecánica o manualmente.
6. Proporcionar un espacio suficiente para una respuesta completa.
7. Expresar las preguntas claramente. Por ejemplo, la pregunta: ¿Ha dejado de funcionar
incorrectamente su procesador?, puede ser frustante para la persona cuyo procesador nunca ha
funcionado mal.
8. Si una pregunta no puede contestarse en forma objetivo, deberá proporcionarse a quien responde la
oportunidad de agregar comentarios aclaratorios.
9. Identifique cada cuestionario por nombre de la persona que lo contesta, título del puesto,
departamento, etc.
10.Incluya una sección en donde las personas que contestan puedan presentarse sus opiniones y críticas.

Observación

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

El analista de sistemas puede hacer su observaciones de la siguiente manera. Primeramente, el

analista puede hacer un recorrido y tomar notas al azar de personas, cosas y actividades. En segundo
lugar, el analista puede observar a una persona o a una actividad sin que se percate de su presencia y

37
sin que haya interacción con el analista. Una observación discreta probablemente tiene poca
importancia en el análisis de sistemas ya que es casi imposible que se den las condiciones necesarias.
En tercer lugar, el analista puede observar una operación sin que haya interacción, pero en donde la
persona que está siendo observada está plenamente consciente de este hecho. Finalmente, el analista
puede observar e interactuar con las personas que están siendo observadas. Esta interacción puede
consistir simplemente en cuestionar una tarea específica, pedir una explicación, etc.

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

Preparación para las observaciones

Antes de iniciar la observación, el analista deberá (1) identificar y definir lo que se va a

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

Realización de las observaciones

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

38
CONCLUSIÓN DEL ANÁLISIS DE SISTEMAS
A lo largo de toda la fase del análisis de sistemas, el analista deberá mantener una extensa
comunicación con el solicitante, y además personal de proyectos. Esta comunicación comienza con el
reporte de la propuesta para realizar el análisis de sistemas que se describió anteriormente. En forma
continua este esfuerzo de comunicación incluye una retroalimentación a las personas entrevistadas, u
observando, con relación a lo que el analista entiende; la verificación con el personal usuario con
respecto a los hallazgos en otras funciones o actividades relacionadas que el analista identifique; y
reuniones periódicas para informar a la gerencia y demás personal del proyecto acerca del progreso,
situación y apego al calendario.

Preparación del reporte de terminación del análisis de sistemas.

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

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

2. Una lista de los principales problemas identificados.
3. Una presentación de todos los requerimientos de los usuarios.
4. Un planteamiento de todas las suposiciones críticas hechas por el analista durante el análisis.
5. Una proyección de los recursos requeridos y los costos esperados que estarán involucrándose en el
diseño de cualquier nuevo sistema o en la modificación del sistema actual. Esta proyección incluye
la factibilidad de continuar con el trabajo en sistemas.
6. Cualquier recomendación referente al sistema propuesto o a sus requerimientos.

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

39
 Para proporcionar un reporte significativo a estas dos partes interesadas, el analista deberá
esforzarse por ser conocido pero completo al preparar el reporte. Los requerimientos deberán
cuantificarse y explicarse de manera específica. El analista deberá evitar en el reporte el lenguaje
técnico y los acrónimos. Deberán anexarse exposiciones y los documentos de trabajo que se utilizaron
en el análisis de sistemas.

Métodos de presentación oral

La simple entrega de los reportes de sistemas no es suficiente. Es necesaria una presentación

oral para una comunicación clara del trabajo realizado. Cuatro métodos para la presentación oral de los
reportes de sistemas son la memorización, la presentación improvisada, la lectura y el método
extemporáneo. Cada uno tiene su lugar, pero generalmente el método extemporáneo es el más eficaz.

Una presentación memorizada es eficaz en cierta forma y le proporciona a uno un sentimiento

de seguridad, pero a costa de una libertad y frescura. Incluso en la presentación memorizada, se necesita
tener un bosquejo para el caso en que uno se pierda.

El método improvisado es una presentación sin ensayo y no se recomienda en absoluto para la

presentación de los reportes de sistemas. Debido a que uno es el autor de estos reportes, se podría
considerar que no es necesario revisarlos; sin embargo, si no se hace, se olvidarán los puntos
principales y se tenderá a divagar.

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

El método extemporáneo es la mejor forma de presentar los reportes. Si uno ha hecho su tarea
y conoce sus reportes de pies a cabeza, entonces éste es el método de entrega más versátil y expresivo.
Se es espontáneo y enérgico. Uno se puede adaptar fácilmente a tópicos y situaciones que no estaban
planeados. Este método ofrece la mejor oportunidad de mantener un contacto visual y establecer

40
relaciones armónicas. Domine completamente su material, desarrolle un bosquejo y parta desde ahí.
Con este método, se tiene una fuerte organización por una parte, y flexibilidad y energía por la otra.

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

Resultados finales del análisis de sistemas

Los siguientes son cinco resultados alternativos de cualquier análisis de sistemas particular:
1. - Para el trabajo. Este resultado significa que ya no se va a realizar más trabajo y que el trabajo en
sistemas y los recursos deberán dirigirse hacia otros trabajos. Este resultado podría presentarse
debido a que una(s) propuesta(s) no cumple(n) las consideraciones de factibilidad TELOS, debido
a un cambio en las decisiones de la gerencia o del solicitante, o debido a un reordenamiento de las
prioridades de los sistemas, que dan como resultado que se abandone el proyecto actual.
2. Estado de espera. Este resultado es bastante común y generalmente se da por una falta de fondos
o una actitud conservadora de la gerencia.
3. Modificar.- Este resultado significa que la gerencia decide que algunos aspectos de la propuesta se
deben cambiar o combinar con otro subsistema.
4. Proceder bajo condición. Este resultado significa que el trabajo en sistemas proseguirá según se
propuso, pero que la propuesta del diseño final antes de la implementación tendrá que justificarse
en base a la factibilidad TELOS.
5. Proceder sin condiciones.- Muchas propuestas de sistemas o subsistemas son autorizadas por la
gerencia con un conocimiento total de que los costos superaron los beneficios medibles. Por
ejemplo, las restricciones severas impuestas sobre la organización por una acción legislativa y
judicial podrían requerir el desarrollo de un sistema independientemente de su costo. O bien, podría
ser que algunos objetivos organizacionales más amplios dicten el desarrollo de un sistema que nos
ea costo eficaz. Por ejemplo, la gerencia podría estar planeando extenderse en un área que no será

41
lucrativa durante varios años. Un subsistema para el apoyo de esta aventura no será costo-eficaz
durante cierto tiempo.

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

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

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

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

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

Elementos del diseño

Los componentes de un sistema de información descritos durante el análisis de requerimientos, son

el punto focal del diseño de sistemas. Los analistas deben diseñar los siguientes elementos:
• Flujo de datos.
Movimientos de datos hacia, alrededor y desde el sistema.
• Almacenes de datos
Conjuntos temporales o permanentes de datos
• Procesos
Actividades para aceptar, manejar y suministrar datos e información. Pueden ser manuales o basadas
en computadoras.
• Procedimientos
Métodos y rutinas para utilizar el sistema de información y lograr con ello los resultados esperados.
• Controles

44
 Estándares y lineamientos para determinar si las actividades están ocurriendo en la forma anticipada
o aceptada, es decir si se encuentran “bajo control”. Asimismo, debe especificar las acciones que
tienen que emprenderse cuando ocurren problemas o se presentan circunstancias inesperadas. Puede
incluirse un reporte sobre las excepciones o procedimientos para la corrección de los problemas.
• Funciones del personal
Las responsabilidades de todas las personas que tienen que ver con el nuevo sistema, incluyendo los
usuarios, operadores de computadora y personal de apoyo. Abarca todo el espectro de componentes
del sistema, incluso desde la entrada de datos hasta la distribución de salidas o resultados. A
menudo, las funciones del personal se establecen en forma de procedimientos.

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

Diseño de la salida

El término salida, como es probable que el lector lo conozca, se refiere a los resultados e
información generados por el sistema. Para muchos usuarios finales, la salida es la única razón para el
desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación. En realidad,
muchos usuarios no operan el sistema de información y tampoco ingresan datos en él, pero utilizan la
salida generada por el sistema.

Cuando diseñan la salida, los analistas deben realizar lo siguiente:

• Determinar que información presentar.
• Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el medio
de salida.
• Disponer la presentación de la información en un formato aceptable.
• Decidir cómo distribuir la salida entre los posibles destinatarios.

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

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

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

Diseño de archivos

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

• Los datos que deben incluirse en el formato de los registros contenidos en el archivo.
• La longitud de cada registro, con base en las características de los datos que contiene.
• La secuencia a disposición de los registros dentro del archivo (la estructura de almacenamiento que
puede ser secuencial, indexada o relativa).

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

Diseño de interacciones con la base de datos

Muchos sistemas de información, ya sea implantados en sistemas de cómputo grandes o

pequeños, interactúan con las bases de datos que abarcan varias aplicaciones. Dada la importancia que
tienen las bases de datos en muchos sistemas, su diseño es establecido y vigilado por un administrador
de base de datos, que es una persona ( o grupo de personas) que tiene la responsabilidad de desarrollar

46
y mantener la base de datos. En estos casos, el analista de sistemas no efectúan el diseño de la base de
datos sino que consulta al administrador de la base para determinar las interacciones más apropiadas
con la base de datos. El analista proporciona al administrador la descripción de 1) los datos que son
necesarios de la base de datos, y 2) las acciones que tendrán efecto sobre la propia base ( por ejemplo,
la recuperación de datos, cambios en los valores de los datos o el ingreso de nuevos datos en la base).

Diseño de la entrada

Los analistas de sistemas deciden los siguientes detalles del diseño de entradas:
1. Que datos ingresan al sistema
2. Qué medios utilizar.
3. La forma en que se deben disponer o codificar los datos.
4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos.
5. Validación necesitaría de datos y transacciones para detectar errores.
6. Métodos para llevar a acabo la validación de las entradas y los pasos a seguir cuando se presentan
errores.

Las decisiones de diseño para el manejo de entradas, especifican la forma en que serán
aceptados los datos para su procesamiento por computadora. Los analistas deciden si los datos serán
proporcionados directamente, quizá a través de una estación de trabajo, o por el uso de documentos,
como talones de ventas, cheques bancarios o facturas, donde los datos a su vez son transferidos hacia
la computadora para su procesamiento.

El diseño de la entrada también incluye la especificación de los medios por los que tanto los
usuarios finales como los operadores darán instrucciones al sistema sobre las acciones que debe
emprender. Por ejemplo, un usuario que interactúa con el sistema por medio de una estación de trabajo,
tiene que ser capaz de indicarle al sistema ya sea que acepte una entrada, genere un reporte o termine
el procesamiento.

Los sistemas en línea incluyen un diálogo o conversación entre el usuario y el sistema. Por
medio del diálogo, el usuario solicita servicios al sistema y le indica cuándo realizar cierta función. A
menudo la naturaleza de la conversación en línea hace la diferencia entre un diseño exitoso y otro

47
inaceptable. Un diseño inapropiado, que deja la pantalla en blanco, confunde al usuario con respecto
a qué acción debe emprender.

Diseño de controles

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

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

Diseño de procedimientos

Los procedimientos especifican qué tareas deben efectuarse al utilizar el sistema y quienes son
los responsables de llevarlas a cabo. Entre los procedimientos importantes se encuentran
• Procedimientos para entrada de datos
Métodos para la captura de datos de las transacciones y su ingreso en el sistema de información
(ejem. secuencia para dar entrada a los datos registrados en los documentos fuente).
• Procedimientos durante la ejecución
Pasos y acciones emprendidos por los operadores del sistema y, en ciertos casos, por los usuarios
finales que interactúan con el sistema para alcanzar los resultados deseados (ejem. montar paquetes
de discos o colocar en las impresoras formas preimpresas).
• Procedimientos para el manejo de errores
Acciones a seguir cuando se presentan resultados inesperados (ejem. ocurre un error cuando el
sistema intenta leer datos de un archivo o la impresora se atasca durante la impresión de una gran
cantidad de hojas).
• Procedimientos de seguridad y respaldo.
Acciones para proteger al sistema y sus recursos contra posibles daños ( ejem: ¿cuándo y cómo
hacer copias de los archivos maestros o de partes de la base de datos?).

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

Diseño para especificaciones para programas

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

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

• Los programas producidos lleven a cabo todas las tareas y lo hagan en la forma establecida.
• La estructuración del software en módulos permita su prueba y validación para determinar si los
procedimientos son correctos.
• Las modificaciones futuras se puedan realizar en forma eficiente y con un mínimo de interrupción
en el diseño del sistema.

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

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

DISEÑO DE SALIDAS

Como identificar las necesidades de salida del sistema

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

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

• Identifican la salida específica que es necesaria para satisfacer los requerimientos de información.
• Seleccionan los métodos para presentar la información.
• Crean los documentos, reportes u otros formatos que contienen la información producida por el
sistema.

Objetivos de la salida

La salida de un sistema de información debe alcanzar uno o más de los siguientes objetivos:
1. Expresar información relacionada con actividades pasadas, estado actual o proyecciones para el
futuro.
2. Señalar eventos importantes, oportunidades, problemas o advertencias.
3. Iniciar una acción
4. Confirmar una acción.

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

Tipos de salidas

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

La salida del sistema puede ser:

1. Un reporte.
2. Un documento.

50
3. Un mensaje.

De acuerdo con las circunstancias y los contenidos, la salida puede ser impresa o presentada en
una pantalla.
El contenido de la salida tiene su origen en las siguientes fuentes:
1. Recuperación de un dispositivo de almacenamiento.
2. Transmisión desde un proceso o actividad del sistema.
3. Directamente desde una fuente de entrada.

Aspectos importantes de la salida

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

1. ¿Quienes recibirán la salida?

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

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

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

3. ¿Cuántos detalles son necesarios?

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

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

5. ¿Qué método utilizar?

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

COMO PRESENTAR LA INFORMACIÓN

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

Formato tabular

En general , los usuarios finales están más acostumbrados a recibir información en forma de
tablas. Los contadores y todos aquellos que revisan datos financieros en forma periódica, dependen
casi exclusivamente de información tabular (en un formato que contiene renglones y columnas). La
sola mención de la palabra “reporte” sugiere, para muchas personas, un formato tabular. Ejemplos

52
comunes de este tipo de formato son los informes de control de inventarios, cuentas por pagar,
contabilidad general, el formato tabular debe utilizarse bajo las siguientes condiciones:
• Cuando los detalles dominan y son necesarios pocos comentarios o explicaciones.
• Cuando los detalles son presentados en categorías discretas.
• Cuando cada categoría debe tener una etiqueta.
• Cuando se deben obtener totales o realizar comparaciones entre diversos componentes.

En un formato tabular cierta información es más importante y, por consiguiente, debe resaltar
sobre la demás. Lo anterior cambia de acuerdo con la aplicación pero, en general, se debe estar seguro
de que los siguientes aspectos sean los que sobresalgan:
• Excepciones a las expectativas normales.
• Categorías más importantes de actividades o entidades.
• Resúmenes de las categorías o actividades mas importantes
• Identificación única de la información
• Entidades que dependen del tiempo.

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

Asimismo, se desea presentar la información en un formato que presente los detalles en un

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

Formato gráfico

En el mercado se encuentran disponibles sistemas gráficos para computadoras personales hasta

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

Cuando utilizar gráficas

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

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

Manejo del volumen de información. La compresión de grandes cantidades de datos en una

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

Satisfacción de preferencias personales. A menudo, a las personas les gusta ver la información
más en forma gráfica que en renglones y columnas. Con frecuencia, los inversionistas prefieren tener

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

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

56
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

APELLIDOS Y NOMBRES

REGISTRO

57