Análisis y Diseño de Sistemas de Información (página 2)

En la figura se muestran la diversidad de sistemas de
información que pueden desarrollar los analistas.
Observe que la figura presenta estos sistemas de abajo
hacia arriba, indicando que el nivel operacional, o más
bajo, de la
organización está apoyado por el TPS, y el
más alto o estratégico, el de las decisiones
semiestructuradas o sin estructura,
está apoyado por el ESS en la parte más alta. Este
texto usa los
términos sistema de
información gerencias, sistema de
información, sistema de información
computarizada y sistema de información de negocios
computarizado en forma indistinta para referirse a sistemas de
información computarizada que dan soporte al rango
más amplio de actividades de negocios por medio de la
información que producen.

La necesidad del análisis y
diseño de sistemas.

El análisis y diseño de
sistemas, tal como es ejecutado por los analistas de
sistemas, busca analizar sistemáticamente la entrada de
datos o el
flujo de datos, el proceso o
transformación de los datos, el almacenamiento de
datos y la salida de información dentro del contexto de un
negocio particular. Además, el diseño
y análisis de sistemas es usado para analizar,
diseñar e implementar mejoras en el funcionamiento de los
negocios que pueden ser logradas por medio del uso de sistemas de
información computarizados. La instalación de un
sistema sin la planeación
adecuada lleva a grandes frustraciones, y frecuentemente causa
que el sistema deje de ser usado.

Usuarios finales.

Cualquiera que interactúe con un sistema de
información en el contexto de su trabajo en la
organización puede ser llamado un usuario
final. A lo largo de los años se han hecho borrosas las
distinciones entre usuarios. Además, cualquier
categoría de usuarios empleada no debe ser vista como
excluyente. Sin importar cómo se hayan clasificado los
usuarios finales, un hecho es pertinente al analista de sistemas:
el involucramiento del usuario a lo largo del proyecto, es
crítico para el desarrollo
exitoso de los sistemas de información computarizados. Los
analistas de sistemas, cuyos papeles dentro de la
organización se tratan a continuación, son el otro
componente esencial para el desarrollo de sistemas de
información.

c) EL PAPEL DE EL ANALISTA DE SISTEMAS

El analista de sistemas como
consultor.

El analista de sistemas frecuentemente actúa como
consultor y, por lo tanto, puede ser contratado
específicamente para que se encargue de los asuntos de los
sistemas de información dentro de un negocio. Esto puede
ser una ventaja, debido a que los consultores externos pueden
llevar con ellos una perspectiva fresca que no poseen otros
miembros de la organización. Pero también puede
decirse que los analistas externos están en desventaja,
debido a que la verdadera cultura
organizacional nunca puede ser conocida por un
extraño.

El analista de sistemas como experto de
soporte.

Otro papel que tal vez requiera desarrollar es el de
experto de soporte en un negocio donde se está empleado
regularmente en alguna actividad de sistemas. En este papel el
analista se apoya en su experiencia profesional relacionada con
el hardware y
software de
computadora y
su uso en el negocio. Este trabajo frecuentemente no es un
proyecto de sistema completo, sino solamente pequeñas
modificaciones o decisiones que afectan a un solo
departamento.

El analista de sistemas como agente de cambio.

El papel más comprensivo y responsable que toma
un analista de sistemas es el de agente de cambio, ya sea interno
o externo al negocio. Como analista se es un agente de cambio
cada vez que se ejecuta cualquiera de las actividades del
ciclo de vida
del desarrollo de sistemas (tratado en la siguiente
sección) y se está presente en el negocio por un
periodo extendido (desde dos semanas hasta más de un
año). Un agente de cambio puede ser definido como una
persona que
sirve de catalizador para el cambio, desarrolla un plan para el
cambio y trabaja junto con otros para facilitar ese
cambio.

d) EL CICLO DE VIDA DEL DESARROLLO DE
SISTEMAS.

Identificación de problemas,
oportunidades y objetivos.

En la primera fase del ciclo de vida del desarrollo de
sistemas el analista tiene que ver con la identificación
de problemas, oportunidades y objetivos. Esta etapa es crítica
para el éxito
del resto de proyecto, debido a que nadie quiere desperdiciar el
tiempo
subsecuente resolviendo el problema equivocado. La primera fase
requiere que el analista observe honestamente lo que está
sucediendo en un negocio. Luego, junto con los demás
miembros de la organización, el analista hace resaltar los
problemas. Frecuentemente estos ya han sido vistos por los
demás, y son la razón por la cual el analista fue
llamado inicialmente. Las personas involucradas en la primera
fase son los usuarios, analistas y administradores de sistemas
que coordinan el proyecto. Las actividades de esta fase consisten
en entrevistas a
los administradores de los usuarios, sumarización del
conocimiento
obtenido, estimación del alcance del proyecto y documentación de los resultados. La salida
de esta fase es un estudio de
factibilidad que contiene una definición del problema
y la sumarización de los objetivos. Luego los
administradores deben tomar una decisión para ver si
continúan con el proyecto propuesto.

Determinación de los requerimientos de
información.

Entre las herramientas
utilizadas para definir los requerimientos de información
en el negocio se encuentran: muestreo e
investigación de los datos relevantes,
entrevistas, cuestionarios, el comportamiento
de los tomadores de decisiones y su ambiente de
oficina y
hasta la elaboración de prototipos. En esta fase el
analista está esforzándose por comprender
qué información necesitan los usuarios para
realizar su trabajo. Las personas involucradas en esta fase son
los analistas y los usuarios, típicamente los
administradores de las operaciones y los
trabajadores de las operaciones.

Análisis de las necesidades del
sistema.

La siguiente fase que realiza el analista de sistemas
involucro el análisis de las necesidades del sistema.
Nuevamente, herramientas y técnicas
especiales ayudan para que el analista haga las determinaciones
de los requerimientos. Una herramienta de éstas es el uso
de diagramas de
flujo de datos para diagramar la entrada, proceso y salida de las
funciones del
negocio en forma gráfica estructurado. A partir de los
diagramas de flujo de datos se desarrolla un diccionario de
datos, que lista todos los conceptos de datos usados en el
sistema, así como sus especificaciones, si son
alfanuméricos y qué tanto espacio ocupan cuando se
imprimen. Durante esta fase el analista de sistemas
también analiza las decisiones estructuradas que se hacen.
Las decisiones estructuradas son aquellas para las que pueden ser
determinadas las condiciones como alternativas de
condición, acciones y
reglas de acción.
Hay tres métodos
principales para el análisis de decisiones estructurales:
lenguaje
estructurado, tablas de decisión y árboles
de decisión.

Diseño del sistema
recomendado.

En esta fase del ciclo de vida del desarrollo de
sistemas, el analista usa la información recolectada
anteriormente para realizar el diseño lógico del
sistema de información. El analista diseña procedimientos
precisos para la captura de datos, a fin de que los datos que van
a entrar al sistema de información sean correctos.
Además, el analista también proporciona entrada
efectiva para el sistema de información mediante el uso de
técnicas para el buen diseño de formas y
pantallas.

Desarrollo y documentación del
software.

En la quinta fase del ciclo de vida del desarrollo de
sistemas el analista trabaja con los programadores para
desarrollar cualquier software original que se necesite. Durante
esta fase, el analista también trabaja con los usuarios
para desarrollar documentación efectiva para el software,
incluyendo manuales de
procedimientos. La documentación le dice al usuario la
manera de usar el software y también qué hacer si
se suceden problemas con el software.

Pruebas y mantenimiento
del sistema.

Antes de que pueda ser usado, el sistema de
información debe ser probado. Es mucho menos costoso
encontrar problemas antes de que el sistema sea entregado a los
usuarios. Algunas de las pruebas son
realizadas por los programadores solos, y otras por los analistas
de sistemas junto con los programadores. Primero se ejecuta una
serie de pruebas para que destaquen los problemas con datos de
ejemplo y eventualmente con datos reales del sistema actual. El
mantenimiento del sistema y de su documentación comienza
en esta fase y es efectuado rutinariamente a lo largo de la vida
del sistema de información.

Implementación y evaluación
del sistema.

En esta fase del desarrollo del sistema el analista
ayuda a implementar el sistema de información. Esto
incluye el entrenamiento de
los usuarios para que manejen el sistema. Algún
entrenamiento es hecho por los proveedores,
pero la supervisión del entrenamiento es responsabilidad del analista de sistemas.
Adicionalmente, el analista necesita un plan para una
conversión suave del sistema antiguo al nuevo. La
evaluación se muestra como
parte de esta fase final de ciclo de vida del desarrollo del
sistema, principalmente para efectos de discusión. De
hecho, la evaluación se realiza durante cada fase. Un
criterio principal que debe ser satisfecho es si los usuarios
pretendidos ya están usando el sistema.

La importancia del mantenimiento.

Después de que el sistema está instalado
se le debe dar mantenimiento, esto significa que los programas de
computadora deben ser modificados y mantenidos actualizados. La
figura muestra la cantidad promedio de tiempo empleada en
mantenimiento en una instalación MIS
típica.

El mantenimiento se realiza por dos razones. La primera
de estas es para corregir errores de software. Sin importar que
tan completamente se pruebe el sistema, se deslizan errores en
los programas de computadora. Los errores del software comercial
para microcomputadoras son a veces documentados como
"anomalías conocidas", y son corregidos cuando son
lanzadas nuevas versiones del software o versiones intermedias.
En el software personalizado los errores deben ser corregidos
conforme son detectados. La otra razón para realizar el
mantenimiento del sistema es para mejorar las capacidades del
software en respuesta a las necesidades organizacionales
cambiantes y, por lo general, involucran algunas de las
siguientes tres situaciones:

1. Los usuarios frecuentemente solicitan
características adicionales después de que se
familiarizan con el sistema de cómputo y sus capacidades.
Estas características solicitadas pueden ser tan simples
como el desplegado de totales adicionales en un reporte o tan
complicadas como el desarrollo de nuevo software.

2. El negocio cambia a través del tiempo. Se debe
modificar el software para abarcar cambios tales como nuevos
requerimientos de reportes gubernamentales o corporativos, la
necesidad de producir nueva información para clientes,
etcétera.

3. El hardware y software están cambiando a un
ritmo acelerado. Un sistema que usa tecnología antigua
puede ser modificado para usar las capacidades de una
tecnología más nueva. Un ejemplo de tal cambio es
el reemplazo de una Terminal de macrocomputadora con una
estación de trabajo de microcomputadora, o una
microcomputadora con una computadora de escritorio.

La figura ilustra la cantidad de recursos, por lo
general tiempo y dinero,
gastados en el desarrollo y mantenimiento del sistema. El
área bajo la curva representa la cantidad total de
dólares gastada. Se puede ver que a lo largo del tiempo es
probable que el costo de
mantenimiento exceda al del desarrollo del sistema. En cierto
punto es más conveniente realizar un nuevo estudio del
sistema, debido a que el costo de mantenimiento continuado es
claramente mayor que la creación de un sistema de
información completamente nuevo. Resumiendo, el
mantenimiento es un proceso continuo a lo largo del ciclo de vida
de un sistema de información. Después de que es
instalado el sistema de información, el mantenimiento por
lo general toma la forma de corrección de errores de
programa no
detectados previamente. Una vez que son corregidos, el sistema
alcanza un estado estable
proporcionando servicios
contables a sus usuarios. El mantenimiento durante este periodo
puede consistir en la eliminación de unos cuantos errores
no detectados anteriormente y la actualización del sistema
con una cuantas mejoras menores. Sin embargo, conforme pasa el
tiempo y cambia el negocio y la tecnología, los esfuerzos
de mantenimiento se incrementan dramáticamente.

e) USO DE LAS HERRAMIENTAS
CASE.

A lo largo de este libro
enfatizamos la necesidad de un enfoque sistemático y
profundo al análisis, diseño e
implementación de los sistemas de información.
Reconocemos que para ser productivos los analistas de sistemas
debe ser organizado, preciso y completo en lo que se proponen
hacer. En los últimos años los analistas han
comenzado a beneficiarse de nuevas herramientas de productividad que
han sido creadas implícitamente para mejorar su trabajo
rutinario mediante un apoyo automatizado. A estas se les llama
herramientas CASE, que significa herramientas para ingeniería de software asistido por
computadora. Los analistas se apoyan en las herramientas CASE
para aumentar la productividad, comunicarse más
efectivamente con los usuarios e integrar el trabajo que
realizan en el sistema, desde el principio hasta el fin del ciclo
de vida.

Aumento de la productividad del
analista.

Estas herramientas permiten que sus usuarios tracen y
modifiquen diagramas fácilmente. Por nuestra
definición, el analista puede entonces llegar a ser
más productivo simplemente por la reducción del
tiempo considerable que es gastado típicamente en el trazo
manual de
diagramas de
flujo de datos hasta que son aceptados.

Mejora de la
comunicación del analista-usuario.

Para que el sistema propuesto se convierta en realidad y
sea usado de hecho, es esencial una comunicación excelente entre los analistas
y usuarios a lo largo del ciclo de vida del desarrollo del
sistema. El éxito de una eventual implementación
del sistema depende de la capacidad de los analistas y usuarios
para comunicarse en una forma significativa. Hasta ahora los
analistas que actualmente usan las nuevas herramientas CASE han
experimentado que su uso promueve una comunicación mayor y
más significativa entre usuario y analistas.

Integración de las actividades del ciclo de
vida

La tercera razón para el uso de herramientas CASE
es para integrar las actividades y proporcionar continuidad de
una fase a la siguiente a lo largo del ciclo de vida del
desarrollo de sistemas. Las herramientas CASE son especialmente
útiles cuando una fase particular del ciclo de vida
requiere varias interacciones o retroalimentación y
modificación.

Evaluación precisa de los cambios del
mantenimiento

La cuarta razón, y posiblemente una de las
más importantes para el uso de herramientas CASE, es que
permite que los usuarios analicen y valoren el impacto de los
cambios de mantenimiento. Por ejemplo, puede ser que el
tamaño de un elemento, tal como un número de
cliente, necesite
ser agrandado.

2. COMPRENSIÓN DE LOS ESTILOS ORGANIZACIONALES
Y SU IMPACTO SOBRE LOS SISTEMAS DE
INFORMACIÓN

a) FUNDAMENTOS ORGANIZACIONALES

Para analizar y diseñar adecuadamente los
sistemas de información, el analista de sistemas necesita
comprender las organizaciones en
que trabaja como sistemas conformados por la interacción de tres fuerzas principales:
los niveles de administración, el diseño de la
organización y la cultura
organizacional. Las organizaciones son sistemas grandes
compuestos de subsistemas interrelacionados. Los subsistemas son
relacionados por tres amplios niveles de administradores que
toman decisiones (operación, administración media y administración estratégica) y que
cortan horizontalmente a través del sistema
organizacional. Las culturas y subculturas organizacionales
influencian la manera en que se interrelaciona la gente en los
subsistemas.

b) LAS ORGANIZACIONES COMO SISTEMAS

Las organizaciones son conceptualizadas en forma
útil como sistemas diseñados para lograr metas y
objetivos predeterminados por medio de la gente y otros recursos
que emplean. Las organizaciones están compuestas de
sistemas más pequeños interrelacionados
(departamentos, unidades, divisiones, etc.) que sirven a
funciones especializadas.

La interrelación e interdependencia de los
sistemas

Todos los sistemas y subsistemas están
relacionados y son interdependientes. Este hecho tiene
implicaciones importantes para las organizaciones y para los
analistas de sistemas que buscan ayudarlos a lograr mejor sus
objetivos. Cuando cualquier elemento de un sistema es cambiado o
eliminado, también son impactados el resto de los
elementos y subsistemas del sistema.

Retroalimentación del sistema para
planeación y control

La retroalimentación es una forma de control del
sistema. Como sistemas, todas las organizaciones usan
planeación y control para administrar sus recursos en
forma efectiva.

Ambientes para sistemas
organizacionales

La retroalimentación es recibida desde el
interior de la organización y del ambiente exterior que la
rodea. Cualquier cosa que esté fuera de las fronteras de
una organización es considerada como un ambiente. Varios
ambientes, con diversos grados de estabilidad, constituyen el
medio ambiente
en donde existe la organización. Aunque se pueden planear
cambios en el estado del
ambiente, frecuentemente no pueden ser controlados directamente
por la organización.

Apertura y restrictividad en las
organizaciones

La apertura y restrictividad existen en forma continua,
ya que no hay una cosa tal como una organización
absolutamente abierta o totalmente cerrada. La apertura se
refiere al libre flujo de información dentro de una
organización. Los subsistemas tales como los departamentos
creativos o artísticos frecuentemente son caracterizados
como abiertos, con un flujo libre de ideas entre sus
participantes y muy pocas restricciones sobre quién
obtiene tal información y en qué momento un
proyecto creativo está en su infancia. Al
extremo opuesto de este continuo puede estar una unidad del
departamento de defensa asignada para trabajar sobre la
planeación muy confidencial que afecta la seguridad
nacional. Cada persona necesita recibir acreditación, la
información en su momento es una necesidad y el acceso a
la información se da con base en la que "es necesario
saber". Este tipo de unidad está limitada por muchas
reglas.

Cómo tomar una perspectiva de
sistemas

La toma de una perspectiva de sistemas permite a los
analistas de sistemas iniciar la clarificación y
comprensión de los diversos negocios con los que
entrarán en contacto. Es importante que los miembros de
subsistemas se den cuenta que su trabajo está
interrelacionado.

REPRESENTACIÓN GRÁFICA DE
SISTEMAS

Un sistema o subsistema, tal como existe dentro de la
organización corporativa, puede ser representado
gráficamente en varias formas. Los diversos modelos
gráficos muestran las fronteras del sistema
y la información usada dentro del sistema.

Los sistemas y el diagrama de flujo
de datos a nivel contexto

El primer modelo es el
diagrama de
flujo de datos a nivel contexto (también llamado modelo
ambiental). Los diagramas de flujos de datos se enfocan en los
datos fluyendo hacia adentro y fuera del sistema y el
procesamiento de los datos. Estos componentes básicos de
todo programa de computadora pueden ser descritos a detalle y
usados para analizar el problema con respecto a su
precisión y totalidad. El diagrama a nivel de contexto
emplea solamente tres símbolos: (1) un rectángulo con
esquinas redondeadas, (2) un cuadrado con dos orillas sombreadas
y (3) una flecha, tal como se muestra en la figura.

Los procesos
transforman los datos de entrada en información de salida,
y el nivel de contenido tiene solamente un proceso que representa
al sistema completo. La entidad externa representa cualquier
entidad que proporciona o recibe información de sistema
pero que no es parte del sistema. Esta entidad puede ser una
persona, un grupo de
personas, una posición corporativa o departamento u otros
sistemas. Las líneas que conectan las entidades externas
con el proceso son llamados flujos de datos y representan
datos.

Un ejemplo de un diagrama de flujo de datos a nivel
contexto se encuentra en la siguiente figura. En este ejemplo se
representan los elementos básicos de un sistema
de

Reservaciones de una línea
aérea.

El pasajero (una entidad) inicia una petición de
viaje (flujo de datos). El diagrama a nivel contexto no muestra
suficientes detalles para indicar exactamente lo que sucede (y
tampoco se pretende que se muestre), pero podemos ver que se
envían las preferencias del pasajero y los vuelos
disponibles al agente de viajes, que
envía de regreso al proceso información sobre los
boletos. También podemos ver que la reservación del
pasajero es enviada a la línea aérea.

Los sistemas y el modelo
entidad-relación

Una manera en que un analista de sistemas puede definir
las fronteras adecuadas del sistema es usar un modelo
entidad-relación. Los elementos que conforman un sistema
organizacional pueden ser llamados entidades. Una entidad puede
ser una persona, un lugar o una cosa, tal como un pasajero en una
línea aérea, un destino o un avión. En forma
alterna, una entidad puede ser un evento, tal como el fin de mes,
un periodo de ventas o la
falla de una máquina. Una relación es la
asociación que describe la interacción entre las
entidades. El formato estándar para trazar un diagrama
entidad-relación (o E-R),

Mostrado en la figura, usa solamente dos
símbolos: un rectángulo y un rombo. El
rectángulo es usado para mostrar una entidad, y el rombo
representa la relación entre esa entidad y otra entidad.
El diagrama siempre es trazado poniendo en la parte superior a la
entidad primaria.

La figura muestra los cuatro tipos diferentes de
diagramas E-R. El primero es una relación uno a uno (1:1).
Aquí a cada EMPLEADO le es asignada solamente una
EXTENSIÓN TELEFÓNICA, y cada EXTENSIÓN
TELEFÓNICA es única para cada EMPLEADO. El segundo
diagrama muestra una relación muchos a uno (M:1). Un
DEPARTAMENTO puede tener muchos EMPLEADOS, pero el EMPLEADO puede
pertenecer a solamente un DEPARTAMENTO.

El tercer tipo de diagrama (E-R) muestra una
relación uno a muchos (1:M). Por último, el cuarto
diagrama muestra una relación muchos a muchos (M:N). Un
VUELO puede llevar muchos PASAJEROS y un PASAJERO puede tener
muchos VUELOS en su itinerario. Los diagramas
entidad-relación son usados frecuentemente por los
diseñadores de sistemas para ayudar a modelar el archivo o
base de datos.
Sin embargo, es todavía más importante que el
analista de sistemas comprenda desde las primeras etapas las
entidades y relaciones en el sistema organizacional. Para trazar
algunos diagramas E-R básicos el analista
necesita:

1. Listar las entidades de la organización para
obtener una mejor comprensión de la
organización.

2. Escoger entidades clave para estrechar el alcance del
problema a dimensiones manejables y significativas.

3. Identificar cuál debe ser la entidad
primaria.

4. Confirmar los resultados de los pasos 1 a 3 por medio
de otros métodos de recolección
de datos (investigación, entrevistas,
administración de cuestionarios, observación y elaboración de
prototipos).

NIVELES DE ADMINISTRACIÓN

La
administración existe en las organizaciones en tres
amplios niveles horizontales: control operacional,
planeación y control
administrativo y administración estratégica,
tal como se muestra en la siguiente figura. Cada nivel tiene sus
propias responsabilidades y todos trabajan para el logro de metas
y objetivos organizacionales en su manera propia.

Administración de
operaciones

El control operacional forma el nivel inferior de la
administración a tres niveles. Los administradores de
operaciones toman decisiones usando reglas predeterminadas que
tienen resultados predecibles cuando son implementadas
correctamente. Los administradores de operaciones son los
tomadores de decisiones cuyo trabajo es el más claro,
debido al alto nivel de certeza en su ambiente de toma de
decisiones.

Administración media

La administración media forma el nivel segundo, o
intermedio, del sistema de administración de tres niveles.
La administración media realiza decisiones de
planeación y control a corto plazo sobre la manera en que
son mejor asignados los recursos para satisfacer los objetivos
organizacionales. La administración media experimenta muy
poca certeza en su ambiente de toma de
decisiones.

Administración
estratégica

La administración estratégica comprende el
tercer nivel del control administrativo de tres niveles. Los
administradores estratégicos ven fuera de la
organización hacia el futuro, tomando decisiones que
guiarán a los administradores medios o de
operación en los meses y años por venir. Los
administradores estratégicos trabajan en un ambiente de
toma de decisiones altamente incierto.

Implicaciones para el desarrollo de sistemas de
información

Cada uno de los tres niveles de administración
tiene diferentes implicaciones para el desarrollo de sistemas de
información para la administración. Algunos de los
requerimientos de información para los administradores
están bien definidos y, en cambio, otros son difusos y se
traslapan. Los administradores de operaciones necesitan
información interna que es, por naturaleza, de
bajo nivel y repetitiva. Tienen gran dependencia sobre la
información que captura el desempeño actual y son grandes usuarios de
recursos de información en línea de tiempo real. La
necesidad de los administradores de operaciones de
información sobre el desempeño pasado y la
información periódica es solamente moderada. Ellos
tienen poco uso para información externa que les permita
proyecciones futuras o creación de escenarios "qué
pasa si".

En el siguiente nivel de administración, la
administración media, que tanto planea como controla, se
necesita información de corto y largo plazo. Debido a la
naturaleza de su trabajo de resolver problemas, los
administradores medios experimentan necesidades extremadamente
altas de información en tiempo real. Para poder
controlar adecuadamente también necesitan
información actual del desempeño medido en
comparación a juegos de
estándares. Los administradores estratégicos
(difieren, en buena medida, de los administradores medios y de
operaciones en sus requerimientos de información. Son
altamente dependientes de información de fuentes
externas que les proporciona noticias sobre
las tendencias del mercado y las
estrategias de
corporaciones con las que compiten.

Debido a que la tarea de la administración
estratégica demanda
proyecciones hacia un futuro incierto, los administradores
estratégicos tienen una gran necesidad de
información de naturaleza predictiva e información
que les permita la creación de muchos escenarios
"qué pasa si". Los administradores estratégicos
también muestran grandes necesidades de información
reportada periódicamente cuando buscan adaptarse a cambios
rápidos.

Los planeadores estratégicos necesitan
información general resumida, en vez de los datos burdos
altamente detallados requeridos por los administradores de bajo
nivel. La información para los planeadores
estratégicos puede ser más antigua y estimada y, en
cambio, los administradores operacionales necesitan
información precisa y actual.

Por último, el planeador estratégico
necesita información cualitativa, principalmente de
fuentes externas, en vez de la información cuantitativa de
fuentes internas requerida por la administración de
operaciones.

3. DETERMINACIÓN DE LA FACTIBILIDAD Y EL
MANEJO DE LAS ACTIVIDADES DE ANÁLISIS Y
DISEÑO

Los cuatro puntos principales que el analista de
sistemas debe manejar son:

a) Iniciación del proyecto,

b) Determinación de la factibilidad del
proyecto,

c) Calendarización del proyecto, y,

d) Administración de los miembros del equipo del
análisis del sistema.

El revisar la salida, la observación del
comportamiento de los empleados y el escuchar la
retroalimentación, son maneras que ayudarán al
analista a resaltar los problemas y oportunidades de los
problemas.

Los proyectos pueden
ser solicitados por muchas personas diferentes dentro del negocio
o por los mismos analistas de sistema. La selección
de un proyecto es una decisión difícil, debido a
que serán solicitados más proyectos de los que
pueden ser hechos. Cinco criterios importantes para la
selección de proyectos son:

a) Que el proyecto solicitado esté respaldado por
la administración,

b) Que tenga el tiempo adecuado para la
asignación de recursos,

c) Que mueva al negocio hacia la obtención de sus
objetivos,

d) Que sea practicable, y,

e) Que sea lo suficientemente importante para ser
considerado en vez de otros proyectos posibles.

Si un proyecto solicitado satisface estos criterios,
entonces puede ser elaborado un estudio de factibilidad de sus
méritos operacionales, técnicos y
económicos. Por medio de este estudio los analistas de
sistemas recopilan datos que permiten a la administración
decidir si continúan con un estudio de sistema
completo.

La planeación del proyecto incluye la
estimación del tiempo requerido por cada una de las
actividades del analista, su calendarización y la
agilización de ellas, si es necesario, para asegurar que
un proyecto sea terminado a tiempo. Una técnica de que
dispone el analista de sistemas para la calendarización de
tareas es la gráfica de Gantt, la cual despliega
actividades en forma de barras en una gráfica. La
calendarización de proyectos basada en computadora, es
ahora una práctica común, debido principalmente al
uso de interfaces de usuario gráficas. Adicionalmente, se pueden usar
los administradores de información personales (PIM) por
los analistas para planear, crear depósitos de
números telefónicos y de fax y hasta
ejecutar otros programas.

Una segunda técnica, llamada PERT
(evaluación de programas y técnicas de
revisión), despliega las actividades como flechas en
una red. El PERT
ayuda a que el analista determine la ruta crítica y el
tiempo de holgura, que es la información requerida para el
control efectivo del proyecto. Cuando es necesario terminar un
proyecto en menor tiempo, el analista puede reducir la
duración total del proyecto identificando y agilizando las
actividades principales.

Una vez que ha sido juzgado factible, el analista de
sistemas debe administrar a los miembros del equipo, sus
actividades, tiempo y recursos. La mayor parte de esto se logra
mediante la comunicación con los miembros del equipo. Los
equipos están constantemente buscando un balance entre
trabajar sobre las tareas y mantener las relaciones con el
equipo. Deben ser solucionadas las tensiones que suceden al
intentar lograr este balance. Frecuentemente emergen dos
líderes en un equipo, un líder
de tarea y un líder socioemocional. Los miembros deben
valorar periódicamente las normas del equipo
para asegurarse de que sean funcionales en vez de disfuncionales
para el logro de los objetivos de equipo.

Es importante que el equipo de análisis ponga
objetivos de productividad razonables para las salidas tangibles
y las actividades del proceso. Las fallas del proyecto pueden ser
evitadas, por lo general, examinando las motivaciones de los
proyectos solicitados, así como los motivos del equipo
para recomendar o evitar un proyecto particular.

UNIDAD II

Análisis de los requerimientos de
información

4. MUESTREO E INVESTIGACIÓN DE DATOS
IMPRESOS.

El proceso de seleccionar sistemáticamente
elementos representativos de una población es llamado muestreo. El objeto
del muestreo es seleccionar y estudiar documentos, tales
como facturas, reportes de ventas y memorándums, o tal vez
seleccionar y entrevistar, dar cuestionarios u observar a
miembros de la organización. El muestreo puede reducir
costos, velocidad de
recolección de datos, hacer potencialmente que el estudio
sea más efectivo y posiblemente reducir la ascendencia en
el estudio. Cuatro tipos principales de muestras que tiene el
analista. Un analista de sistemas debe seguir cuatro pasos en el
diseño de una buena muestra. Primero, se tiene la
necesidad de determinar la población misma. Segundo, se
debe decidir el tipo de muestra. Tercero, se debe calcular el
tamaño de muestra. Por último, se deben planear los
datos que necesitan ser recolectados o descritos. Tipos de
información buscada en la investigación Los tipos
de muestras útiles para un analista de sistemas son: de
conveniencia, intencionada, aleatoria simple y aleatoria
compleja. El último tipo incluye las subcategorías
de muestreo sistemático y muestreo estratificado. Hay
varios lineamientos a seguir para la determinación del
tamaño de muestra. El analista de sistemas puede hacer una
decisión subjetiva en relación con el estimado de
intervalo aceptable. Luego se selecciona un nivel de confianza y
puede ser calculado el tamaño de muestra
necesario.

El analista de sistemas necesita investigar datos
relevantes, incluyendo reportes, documentos, estados
financieros, manuales de procedimientos y memorándums.
Los datos relevantes muestran dónde ha estado la
organización y hacia dónde creen sus miembros que
están yendo. Es necesario que sean analizados documentos
cuantitativos y cualitativos.

Debido a que los documentos son mensajes persuasivos,
debe ser reconocido que el cambiarlos también puede
cambiar a la organización. Las consignas que se colocan
revelan la cultura oficial de la organización Hay muchas
formas de analizar documentos cuantitativos y cualitativos. Sin
embargo, es importante recordar que la investigación de
los datos archivados tiene ventajas y desventajas. Debido a que
muchas de las desventajas pueden ser superadas, vale la pena la
investigación de archivos. Una de
las desventajas del uso de datos archivados es que los datos
pueden ser importantes solamente para aquel que originalmente los
guardó.

5. ENTREVISTAS.

El proceso de las entrevistas es un método que
usa el analista de sistemas para la recolección de datos
sobre los requerimientos de información. El analista de
sistemas escucha buscando objetivos, sentimientos, opiniones y
procedimientos informales en entrevistas con los tomadores de
decisiones de la organización. También vende el
sistema durante las entrevistas. Las entrevistas son
diálogos de preguntas respuestas planeados por anticipado
entre dos personas.

Hay cinco pasos que deben tomarse para la
planeación previa de la
entrevista:

1. Lectura de
material de fondo

2. Establecimiento de objetivos de la
entrevista

3. Decisión de a quién
entrevistar

4. Preparación del entrevistado

5. Decisión sobre el tipo y estructura de las
preguntas

Las preguntas tienen dos tipos básicos: abiertas
y cerradas. Las preguntas abiertas dejan abiertas todas las
opciones de respuesta para el entrevistado, Las preguntas
cerradas limitan las opciones posibles de la respuesta. Las
averiguaciones pueden ser abiertas o cerradas, pero le solicitan
al interlocutor una respuesta más detallada. Las
entrevistas pueden estar estructuradas en tres formas
básicas, estructura de pirámide, de embudo o de
rombo. Las estructuras
piramidales comienzan con preguntas cerradas y detalladas y se
amplían a preguntas más generales. Las estructuras
de embudo comienzan con preguntas abiertas generales y luego se
estrechan a preguntas cerradas más específicas. Las
estructuras de rombo combinan las fuerzas de las otras dos
estructuras pero se llevan más tiempo para realizarse. Hay
compromisos involucrados sobre la decisión de cómo
estructurar para realizar las preguntas y secuencias de preguntas
de la entrevista.
Las entrevistas deben ser grabadas por medio de grabadoras de
cinta o la toma de notas. Después de la entrevista, el
entrevistador debe escribir un reporte que liste los puntos
principales que se proporcionaron, así como opiniones
acerca de lo que fue dicho. Es extremadamente importante
documentar la entrevista lo más pronto posible
después de que haya sido realizada. Para reducir tanto el
tiempo como el costo de las entrevistas personales, los analistas
pueden considerar el diseño conjunto de aplicaciones (JAD)
como una alternativa. Mediante el uso del JAD los analistas
logran tanto el análisis de requerimientos como el
diseño de la interfaz de usuario con los usuarios en un
lugar de reunión de grupo. La valoración cuidadosa
del lugar de reunión para la organización
ayudará a juzgar al analista si el JAD es una alternativa
adecuada.

6. USO DE CUESTIONARIOS.

Mediante el uso de cuestionarios los analistas de
sistemas pueden recolectar datos sobre actitudes,
creencias, comportamientos y características de gentes
importantes en la organización. Los cuestionarios son
útiles sí: las personas de la organización
están ampliamente dispersas, muchas gentes están
involucradas con el proyecto de sistema, se necesita un trabajo
exploratorio antes de recomendar alternativas o hay una necesidad
para la sensibilización del problema antes de que se
realicen entrevistas. Una vez que han sido articulados los
objetivos del cuestionario,
el analista puede comenzar a escribir preguntas abiertas o
cerradas. La selección de la redacción es extremadamente importante y
debe reflejar el lenguaje de
los miembros de la organización. Idealmente, las preguntas
deben ser simples, específicas, sin ascendencia, sin
menosprecio, técnicamente precisas y dirigidas a aquellos
que tienen el
conocimiento. La asignación de escalas es el proceso
de asignar números u otros símbolos a un atributo o
característica. Tal vez quiera el analista de sistemas
usar escalas para medir las actitudes o las
características de los interlocutores o para hacer que los
interlocutores actúen como jueces sobre el tema del
cuestionario.

Las cuatro formas de medición son escalas nominales, ordinales,
de intervalo y de relación. La forma de medición es
frecuentemente indicada por los datos, y el análisis de
los datos es a su vez indicado en alguna medida por la forma de
medición.

Los analistas de sistemas necesitan tomar en
consideración la validez y la confiabilidad. La validez
significa que el cuestionario mide lo que el analista de sistemas
pretendió medir. La confiabilidad significa que los
resultados son consistentes.

Los analistas deben ser cuidadosos para evitar problemas
como lenidad, tendencia central y el efecto de halo cuando
construyen escalas. El control consistente del formato y estilo
del cuestionario puede dar como resultado una mejor tasa de
respuesta. Adicionalmente, el ordenamiento y agrupamiento
significativo de las preguntas es importante para ayudar a que
los interlocutores comprendan el cuestionario.