DESARROLLO DE

SISTEMAS DE
INFORMACIÓ N

UNIVERSIDAD NACIONAL DE
LUJAN

Departamento de Ciencias
Sociales

Introducción a los Sistemas de

Información

GUIA N°4
INTRODUCCIÓN

La obtención de una ventaja competitiva utilizando los sistemas de información dependerá en gran
medida del correcto desarrollo y puesta en funcionamiento del sistema de información.
El desarrollo de un sistema de información no resulta sencillo. Aquellas organizaciones que
simplemente adquieren tecnologías de información sin tener en cuenta las necesidades existentes
en la compañía fracasarán, poniendo en peligro la supervivencia de la empresa.
Por lo tanto, resulta conveniente describir este ciclo de vida, para considerar después las diversas
fuentes y modalidades de incorporación de sistemas de información.

ETAPAS DEL CICLO DE VIDA

El desarrollo completo de un sistema de información, desde el reconocimiento de la necesidad que
va a satisfacer hasta el funcionamiento óptimo del sistema, atraviesa distintas etapas que
conforman lo que se denomina el ciclo de vida de un sistema.
Aunque la enumeración y denominación de estas etapas varía de acuerdo con distintos enfoques
metodológicos y prácticos, las diferencias no son sustanciales. En definitiva, las tareas involucradas
en el desarrollo eficiente de un sistema de información son las mismas, cualquiera sea el criterio
con que se las clasifique, agrupe o denomine.
Desde este punto de vista, aquí se describirá las siete fases del ciclo de desarrollo de sistemas
(SDLC) propuestas por Kendall & Kendall y que se muestra en la siguiente figura
Identificación de los problemas, oportunidades y objetivos
En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se encarga de
identificar correctamente los problemas, las oportunidades y los objetivos. Esta etapa es
imprescindible para el éxito del resto del proyecto: ya que a nadie le gusta desperdiciar el tiempo
resolviendo un problema mal caracterizado.
En la primera fase el analista debe analizar con honestidad lo que está ocurriendo en la empresa.
Después, junto con otros miembros de la organización, debe comenzar a señalar los problemas. A
menudo, otras personas habrían planteado también estos problemas, razón por la cual se llamó en
un principio al analista. Las oportunidades residen en las situaciones que el analista cree poder
mejorar mediante el uso de sistemas de información computarizados. Al aprovechar estas
oportunidades, la empresa puede obtener una ventaja competitiva o establecer un estándar en la
industria.
La identificación de los objetivos también es un componente importante de la primera fase. El
analista debe descubrir primero qué trata de hacer la empresa; después debe ser capaz de
determinar si alguno de los aspectos de las aplicaciones de los sistemas de información puede
ayudar a que la empresa logre sus objetivos al enfrentar problemas u oportunidades específicos.
Las personas involucradas en la primera fase son los usuarios, los analistas y los administradores de
sistemas que coordinan el proyecto. En esta fase las actividades consisten en entrevistar a los
encargados de la administración de los usuarios, sintetizar el conocimiento obtenido, estimar el
alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de
viabilidad, el cual contiene la definición de un problema y sintetiza los objetivos. Después, la
administración de la empresa debe tomar una decisión en cuanto a proceder o no con el proyecto
propuesto. Si el grupo de usuarios no tiene suficientes fondos en su presupuesto o desea hacer
frente a problemas que no están relacionados, o si los problemas no requieren un sistema
computacional, tal vez se pueda recomendar una solución distinta y el proyecto de sistemas no
continúe.

Determinación de los requerimientos de información del factor humano

La siguiente fase a la que entra el analista es determinar las necesidades de los usuarios
involucrados, mediante el uso de varias herramientas, para comprender la forma en que
interactúan en el contexto laboral con sus sistemas de información actuales. El analista utilizará
métodos interactivos como entrevistas, muestreos e investigación de datos duros, además de los
cuestionarios y los métodos discretos, como observar el comportamiento de los encargados al
tomar las decisiones y sus entornos de oficina, y los métodos integrales como la creación de
prototipos.
El analista utilizará estos métodos para plantear y responder muchas preguntas relacionadas con la
interacción humano-computadora (HCI), incluyendo preguntas tales como: “¿Cuáles son las
fortalezas y limitaciones físicas de los usuarios?”, o dicho en otras palabras, “¿qué hay que hacer
para que el sistema sea perceptible, legible y seguro?”, “¿cómo puede diseñarse el nuevo sistema
para que sea fácil de usar, aprender y recordar?”, “¿cómo puede el sistema ser agradable o incluso
divertido de usar?”, “¿cómo puede el sistema apoyar las tareas laborales individuales de un usuario
y buscar nuevas formas de hacerlas más productivas?”.
En la fase de requerimientos del SDLC, el analista se esfuerza por comprender qué información
requieren los usuarios para realizar sus trabajos. En este punto el analista examina cómo hacer que
el sistema sea útil para las personas involucradas. ¿Cómo puede el sistema ofrecer un mejor apoyo
para las tareas individuales que se deben llevar a cabo? ¿Qué nuevas tareas habilita el nuevo
sistema que los usuarios no podían realizar sin él?
¿Cómo se puede crear el sistema de manera que extienda las capacidades de un usuario más allá
de lo provisto por el sistema anterior? ¿Cómo puede el analista crear un sistema gratificante para
los trabajadores?
Las personas involucradas en esta fase son los analistas y los usuarios, por lo general los gerentes y
los trabajadores de operaciones. El analista de sistema debe conocer los detalles sobre las
funciones del sistema actual: el quién (las personas involucradas), el qué (la actividad de la
empresa), el dónde (el entorno en el que se lleva a cabo el trabajo), el cuándo (la coordinación) y
el cómo (de qué manera particular se realizan los procedimientos actuales) de la empresa a la que
está estudiando. Después, el analista debe preguntar por qué la empresa utiliza el sistema actual.
Puede haber buenas razones por las cuales la empresa trabaje con los métodos actuales, razón por
la que se deben tener en cuenta al diseñar un nuevo sistema.
No obstante, si la razón de seguir con las operaciones actuales es que “siempre se ha hecho de esa
forma”, el analista querrá mejorar los procedimientos. Al terminar esta fase, el analista deberá
comprender la forma en que los usuarios realizan su trabajo al interactuar con una computadora y
deberá empezar a comprender cómo mejorar la utilidad y capacidad de uso del nuevo sistema.
También deberá saber cómo funciona la empresa y tener información completa sobre personas,
objetivos, datos y procedimientos involucrados.

Análisis de las necesidades del sistema

La siguiente fase que debe llevar a cabo el analista de sistemas involucra el análisis de las
necesidades del sistema. Aquí también hay herramientas y técnicas especiales que ayudan al
analista a realizar las determinaciones de los requerimientos. Las herramientas como los diagramas
de flujo de datos (DFD) para graficar la entrada, los procesos y la salida de las funciones de la
empresa, o los diagramas de actividad o cursogramas para mostrar la secuencia de los eventos,
sirven para ilustrar a los sistemas de una manera estructurada y gráfica. A partir de los diagramas
de flujo de datos, de secuencia u otros tipos de diagramas se debe desarrollar un diccionario de
datos para enlistar todos los elementos de datos utilizados en el sistema, así como sus
especificaciones.
Durante esta fase, el analista de sistemas también analiza las decisiones estructuradas llevadas a
cabo. Las decisiones estructuradas son aquellas para las que se pueden determinar condiciones,
alternativas de condición, acciones y reglas de acción. Hay tres métodos principales para el análisis
de las decisiones estructuradas: inglés/español estructurado, tablas de decisión y árboles de
decisión.
En este punto del SDLC, el analista de sistemas prepara una propuesta de sistemas en la que
sintetiza todo lo que ha averiguado sobre los usuarios, la capacidad de uso y la utilidad de los
sistemas actuales; incluye un análisis de costo-beneficio de las alternativas y, si se requiere, hace
recomendaciones. Si la administración acepta una de las recomendaciones, el análisis continúa por
esa vía. Cada problema de sistemas es único, por lo que nunca hay sólo una solución correcta. La
manera en que se formule una recomendación o solución depende de las cualidades individuales y
la capacitación profesional de cada analista, y de su interacción con los usuarios en el contexto de
su entorno laboral.
Diseño del sistema recomendado
En la fase de diseño del SDLC, el analista de sistemas utiliza la información recolectada antes para
realizar el diseño lógico del sistema de información. El analista diseña los procedimientos para
ayudar a que los usuarios introduzcan los datos con precisión, de manera que los datos que entren
al sistema de información sean los correctos. Además, el analista debe ayudar a que los usuarios
completen la entrada de datos efectiva al sistema de información mediante el uso de las técnicas
del buen diseño de formularios y páginas Web o pantallas.
Parte del diseño lógico del sistema de información es idear la interacción humano-computadora. La
interfaz conecta al usuario con el sistema, por lo que es extremadamente importante. La interfaz
del usuario se diseña con ayuda de los usuarios para asegurar que el sistema sea perceptible,
legible y seguro, así como atractivo y divertido de usar. Ejemplos de interfaces de usuario físicas
son el teclado (para escribir las preguntas y respuestas), los menús en pantalla (para obtener los
comandos de los usuarios) y varios tipos de interfaces gráficas de usuario (GUI) basadas en un
ratón o una pantalla táctil.
La fase de diseño también incluye el diseño de bases de datos que almacenarán gran parte de los
datos necesarios para los encargados de tomar las decisiones en la organización. Los usuarios se
benefician de una base de datos bien organizada que sea lógica para ellos y se corresponda con la
forma en que ven su trabajo. En esta fase, el analista también trabaja con los usuarios para diseñar
una salida (ya sea en pantalla o impresa) que cumpla con sus necesidades de información.
Por último, el analista debe diseñar controles y procedimientos de respaldo para proteger el sistema
y los datos, y para producir paquetes de especificación de programas para los programadores. Cada
paquete debe contener los diseños de las entradas y las salidas, las especificaciones de los archivos
y los detalles sobre el procesamiento; también puede incluir árboles o tablas de decisión, UML o
diagramas de flujo de datos, junto con los nombres y las funciones de cualquier código previamente
escrito dentro de la empresa o que utilice código u otras bibliotecas de clases.

Desarrollo y documentación del software

En la quinta fase del SDLC, el analista trabaja con los programadores para desarrollar el software
original requerido. Durante ella, el analista desarrolla junto con los usuarios una documentación
efectiva para el software, incluyendo manuales de procedimientos, ayuda en línea, sitios Web con
preguntas frecuentes (FAQ) y archivos Léame (Read Me) para incluir con el nuevo software. Como
los usuarios están involucrados desde el principio, la fase de documentación debe lidiar con las
preguntas que hicieron y resolvieron junto con el analista. La documentación indica a los usuarios
cómo deben usar el software y qué deben hacer en caso de que ocurran problemas.
Los programadores desempeñan un rol clave en esta fase, ya que diseñan, codifican y eliminan los
errores sintácticos de los programas de computadora. Para asegurar la calidad, un programador
puede llevar a cabo un recorrido por el diseño o por el código para explicar las porciones complejas
del programa a un equipo formado por otros programadores.

Prueba y mantenimiento del sistema

Antes de utilizar el sistema de información, se debe probar. Es mucho menos costoso detectar los
problemas antes de entregar el sistema a los usuarios. Una parte del procedimiento de prueba es
llevado a cabo por los programadores solos; la otra la realizan junto con los analistas de sistemas.
Primero se completa una serie de pruebas para señalar los problemas con datos de muestra y
después se utilizan datos reales del sistema actual. A menudo, los planes de prueba se crean en las
primeras etapas del SDLC y se refinan a medida que el proyecto progresa.
A la hora de establecer las pruebas, las empresas pueden realizarlas de tres tipos:
pruebas de programas: los diversos programas elaborados se probaran o separado, con el fin de
garantizar que cada uno de ellos está libre de errores
Pruebas al sistema: se probará el sistema de información como un todo. La
finalidad será el correcto funcionamiento del sistema en conjunto, puesto que en ocasiones puede
que los programas función correctamente de forma individual, pero a la hora de funcionar en
conjunto el sistema de información no ofrezca los resultados esperados por la empresa
pruebas de aceptación: pruebas realizadas por los usuarios finales del sistema de información.
Cuando estos dan el visto bueno se proporciona la certificación final del correcto funcionamiento del
sistema de información

El mantenimiento del sistema y la documentación de este mantenimiento empieza en esta fase y se

lleva a cabo de manera rutinaria durante toda la vida del sistema de información. Gran parte del
trabajo rutinario del programador consiste en el mantenimiento, por lo cual las empresas invierten
una gran cantidad de dinero en este proceso.
Ciertos procedimientos de mantenimiento, como las actualizaciones de los programas, se pueden
llevar a cabo a través del sitio Web del distribuidor. Muchos de los procedimientos sistemáticos que
emplea el analista durante el SDLC pueden ayudar a asegurar que el mantenimiento siempre se
mantenga en el nivel mínimo necesario.

Implementación y evaluación del sistema

En esta última fase del desarrollo de sistemas, el analista ayuda a implementar el sistema de
información. En esta fase hay que capacitar a los usuarios para operar el sistema. Los distribuidores
se encargan de una parte de la capacitación, pero la supervisión de la capacitación es
responsabilidad del analista de sistemas. Además, el analista necesita planear una conversión sin
problemas del sistema antiguo al nuevo. Este proceso incluye convertir los archivos de los formatos
anteriores a los nuevos, o crear una base de datos, instalar equipo y llevar el nuevo sistema a
producción.
La evaluación se incluye como parte de esta fase final del SDLC principalmente por cuestiones
informativas. En realidad, la evaluación se realiza durante cada fase. El criterio clave que debemos
satisfacer es si los usuarios previstos están utilizando el sistema.
Hay que tener en cuenta que a menudo el trabajo relacionado con los sistemas es cíclico. Cuando
un analista termina una fase del desarrollo de sistemas y continúa con la siguiente, al descubrir un
problema tal vez se vea obligado a regresar a la fase anterior y modificar el trabajo que realizó ahí.

El impacto del mantenimiento

Una vez instalado el sistema hay que darle mantenimiento, lo cual implica que tal vez haya que
realizar modificaciones en los programas y mantenerlos actualizados.
el mantenimiento es un proceso continuo que se realiza a lo largo del ciclo de vida de un sistema
de información. Una vez que se instala el sistema de información, por lo general el mantenimiento
implica corregir los errores del programa que no se habían detectado antes. Una vez corregidos, el
sistema se acerca a un estado estable para proveer un servicio confiable a sus usuarios. Durante
este periodo, el mantenimiento puede consistir en eliminar unos cuantos errores o ‘bugs’ que no se
detectaron antes y actualizar el sistema con mejoras menores.
Sin embargo, a medida que pasa el tiempo y evolucionan tanto la empresa como la tecnología, el
esfuerzo de mantenimiento aumenta en forma considerable.

Herramientas para la Recopilación de Información

Existen diversas herramientas que el analista puede usar para obtener los requerimientos de
información de los miembros de la organización y algunos de ellos son

ENTREVISTAS
Una entrevista para recopilar información es una conversación dirigida con un propósito específico,
en la cual se usa un formato de preguntas y respuestas. En la entrevista hay que obtener las
opiniones del entrevistado y lo que siente sobre el estado actual del sistema, los objetivos de la
organización y los personales, y los procedimientos informales para interactuar con las tecnologías
de la información.
Piense en el proceso completo de la entrevista antes de llevarla a cabo. Visualice por qué la hará,
las preguntas que formulará y qué la convertirá en una entrevista exitosa de acuerdo con su
criterio. Además debe planear cómo hacer de la entrevista un suceso satisfactorio para el
entrevistado
Sobre todo busque las opiniones del entrevistado. Al buscar opiniones en vez de hechos, descubira
problemas claves que se desean solucionar.
Para que las entrevistas resulten un medio eficiente de colectar información se requiere que se
cumplan una serie de premisas:
ENTÉRESE DE LOS ANTECEDENTES Lea y comprenda todo lo que pueda sobre los antecedentes
de los entrevistados y la organización
ESTABLEZCA LOS OBJETIVOS DE LA ENTREVISTA Defina los objetivos de la entrevista a partir
de los antecedentes investigados y de su propia experiencia.
DECIDA A QUIÉN ENTREVISTAR Incluya personas clave de todos los niveles que se vean
afectados por el sistema en cierta forma. Trate de que la muestra sea representativa para indagar
sobre la mayor cantidad posible de necesidades de usuario. Su contacto de la organización también
le puede dar ideas sobre las personas que debe entrevistar
PREPARE AL ENTREVISTADO Para preparar a la persona que va a entrevistar, llame por
teléfono o envíe un mensaje de correo electrónico con anticipación, de manera que el entrevistado
esté preparado; si la entrevista es muy detallada, envíe previamente el cuestionario por correo
electrónico para que el entrevistado pueda pensar en sus respuestas.
DECIDA SOBRE LOS TIPOS DE PREGUNTAS Y SU ESTRUCTURA Redacte preguntas para
cubrir las áreas clave de la HCI y el proceso de toma de decisiones que haya descubierto al
momento de determinar los objetivos de la entrevista. Las técnicas de interrogación apropiadas son
la base de la entrevista

Tipos de preguntas
PREGUNTAS ABIERTAS Las preguntas abiertas son del tipo: “¿Qué piensa en cuanto a poner a
todos los gerentes en una intranet?”, “Por favor explique cómo toma una decisión sobre la
programación de tiempos y fechas.”, “¿En qué formas extiende el sistema su capacidad de realizar
tareas que no sería posible realizar mediante algún otro medio?” o sea, son aquellas que dejan
abiertas al encuestado todas las posibles opciones de respuesta.
Los beneficios de utilizar preguntas abiertas son muchos, entre los cuales tenemos:
1. El entrevistado baja la guardia.
2. El entrevistador puede percibir el vocabulario del entrevistado, lo cual refleja su educación,
valores, posturas y creencias.
3. Se proveen muchos detalles.
4. Se descubren vías de cuestionamiento adicionales que de otra manera no se hubieran explotado.
5. El entrevistado encuentra el proceso más interesante.
6. Se permite una mayor espontaneidad.
7. El entrevistador puede expresar mejor las preguntas.
8. El entrevistador puede recurrir a ellas en caso de que tenga que improvisar.
Como puede ver, hay varias ventajas en cuanto al uso de preguntas abiertas. Sin embargo, también
hay muchas desventajas:
1. Las preguntas pueden generar muchos detalles irrelevantes.
2. Se puede llegar a perder el control de la entrevista.
3. Se permiten respuestas que pueden requerir demasiado tiempo debido a la cantidad obtenida de
información útil.
4. Podría parecer que el entrevistador no está preparado.
5. Puede darse la impresión de que el entrevistador “anda de pesca”, sin objetivos bien definidos.
Debe considerar con cuidado las implicaciones de usar preguntas abiertas en las entrevistas
PREGUNTAS CERRADAS La otra alternativa la constituyen las preguntas cerradas; asumen las
formas básicas “¿Es fácil usar el sistema actual?” y “¿Cuántos subordinados tiene a su cargo?”. Las
posibles respuestas son cerradas para el entrevistado, debido a que sólo puede responder con un
número finito tal como “Ninguna”, “Una” o “Quince”. Una pregunta cerrada limita el entrevistado la
respuesta disponible
Los beneficios de usar preguntas cerradas de cualquier tipo incluyen:
1. Ahorro de tiempo.
2. Se pueden comparar las entrevistas con facilidad.
3. Van directo al grano.
4. Se mantiene el control sobre la entrevista.
5. Se cubre mucho terreno con rapidez.
6. Se obtienen datos relevantes.
Sin embargo, las desventajas de usar preguntas cerradas son substanciales. Entre las más comunes
tenemos:
1. Son aburridas para el entrevistado.
2. No proporcionan detalles adicionales (debido a que el entrevistador provee el marco de
referencia para el entrevistado).
3. Se pierden las ideas principales por la razón anterior.
4. No se puede generar una buena comunicación entre el entrevistador y el entrevistado.

Si bien formalmente las entrevistas tienen por objetivo reunir información, todo buen analista sabe
que la transmisión de datos tiene una corriente dual. Es así como, en el desarrollo de las mismas, el
analista debe utilizar el medio para informar al entrevistado de temas tan disímiles como:
a) la función del asesor y su posible utilidad si se lo usa como tal;
b) las limitaciones que tiene un trabajo de análisis de sistemas si no es apoyado por los hombres de
línea;
c) eliminar incertidumbres respecto de los alcances de las tareas y, con ello, sumar adhesiones o
por lo menos neutralizar recelos;
d) trasmitir ideas o posibilidades y observar la respuesta que el entrevistado efectúa ante las
mismas.
Encuestas: Las encuestas se desarrollan mediante el diseño de cuestionarios específicos que se
dirigen a los componentes de la organización; usualmente se utilizan tres tipos de formularios: los
dirigidos a niveles gerenciales, a los supervisores y al personal de línea. Para que una encuesta
tenga efectividad debe ser concreta, no muy extensa, de fácil respuesta y deben acompañarse los
cuestionarios con instrucciones relativas a cómo completar cada punto de la misma.

Mediante las encuestas se pretende identificar:

a) Las tareas que cumple el encuestado.
b) La frecuencia de ejecución y la cantidad de unidades procesadas por unidad de frecuencia (día,
semana, etc.).
c) La documentación que genera.
d) Los registros que opera.
e) Los archivos que mantiene o a los que accede.
f) La posición jerárquica que ocupa en la pirámide organizacional, indicando de quién depende.
g) El detalle de los subordinados que tiene a cargo.
Los puntos señalados de a) a e) inclusive se dividen en operados directamente por el encuestado o
por personas que están bajo su supervisión directa.

En las encuestas dirigidas a supervisores y gerentes no se piden detalles sobre documentación,

archivos y registros. Asimismo en este tipo de encuestas se pide que se mencionen los problemas
concretos existentes, en opinión del encuestado, y la posibilidad de solucionarlos con el programa
emprendido, así como las sugerencias específicas que se puedan aportar para superar los
problemas mencionados.

Las encuestas tienen un valor relativo como elemento de recolección de datos. Diversas son las
razones que confluyen para restarle validez a las mismas:
a) Los encuestados son personas de diferente nivel de preparación y, por lo tanto, las respuestas
no tienen la uniformidad que permitiría tomarlas como base para armar un panorama coherente de
la realidad.
b) El grado de atención que ponen los encuestados es variable, en la medida que algunos tienden a
no considerar las mismas como algo que hace a sus obligaciones dentro de la organización.
e) La gente, en general, es sumamente reticente a proporcionar información por escrito a personas
que no conoce, al no estar segura del uso que se dará a lo expresado.
Por las razones aludidas, las encuestas son usualmente formularios que recogen fragmentos
escritos por diversos autores, sin que el analista pueda compatibilizarlos razonablemente. No son,
por lo tanto, un elemento definitivo, pero resultan útiles como antecedente para poder planificar la
utilización de los otros medios de relevamiento.

En efecto, a partir de las encuestas se puede:

a) Programar adecuadamente la cadena de entrevistas, teniendo en cuenta las personas que
forman parte de la organización, sus tareas y sus relaciones jerárquicas.
b) Preparar la guía de desarrollo de las entrevistas tomando como punto de partida las funciones,
tareas y personas que surgen de las encuestas.
c) Concurrir a las entrevistas con un conocimiento, que si bien es fragmentario y poco seguro, sirve
de base para formular las preguntas sin un desconocimiento total de las realidades sobre las que se
está trabajando.

Observación Directa:
Observar a los encargados de tomar decisiones, su entorno físico y su interacción con el entorno
físico y ergonómico es un importante método discreto para el analista de sistemas. Mediante la
observación de las actividades de los encargados de tomar decisiones, el analista busca obtener
una comprensión de lo que se lleva a cabo en realidad, no sólo de lo que está documentado o
explicado. Por medio de esta observación, el analista trata de ver de primera mano las relaciones
que existen entre los encargados de tomar decisiones y los demás miembros de la organización
Como observación directa se incluyen una seria de actividades que desarrolla el analista, a través
de las cuales toma conocimiento, por simple visualización, de temas como:
a) La disposición física del personal y elementos de trabajo.
b) La circulación de personas e información.
c) Las características de interacción con el público.
d) El funcionamiento de equipos.
e) La estructura y ordenamiento de los archivos.
f) Los antecedentes que se disponen en la línea de trabajo respecto de su ordenamiento,
(Manuales, memos, órdenes escritas, etc.).
g) La documentación de base efectivamente completada, tanto en sus particularidades de llenado
de formularios, como en los volúmenes que alcanza esta documentación.
El analista no puede actuar con prescindencia del personal de la empresa, lo que ocurre es que la
observación directa se ejecuta de común acuerdo con gerentes y supervisores, pero sin que ellos
tengan una participación directa, tal como les corresponde en encuestas o entrevistas.

Este medio es un complemento de los anteriores, de por sí no está en condiciones de

proporcionarnos todos los datos que se necesitan para diseñar un sistema, pero resulta insustituible
en casos como:
a) Estudios de disposición física de equipos, muebles y personas dentro de una oficina o fábrica,
(Lay Out),
b) Procesos donde interviene la atención al público.
c) Estudios de carga de trabajo en determinados sectores.
d) Sistemas en donde deban identificarse todos los posibles casos que puedan presentarse a los
efectos de programar una solución racional para ellos. En tales casos las encuestas y entrevistas no
resultan seguras y sólo el análisis de tiempos y movimientos por un período amplio de tiempo es el
medio idóneo para proporcionar información confiable y segura.

El método de observación directa, cuando se basa en la visualización del lugar de trabajo, puede
adolecer de inexactitudes, en la medida que el personal modifique sus actitudes frente a la
observación a la que es sometido. Sin embargo la experiencia indica que aun alertado, los vicios
adquiridos sin difícilmente disimulables cuando el tiempo de observación se extiende observación se
extiende lo suficiente como para que el observador quede confundido con la rutina diaria.

INVESTIGACIÓN
Investigar es descubrir y analizar información. Al investigar la evidencia en una organización, el
analista actúa como Sherlock Holmes, el famoso detective.
A medida que el analista de sistemas trabaja para entender a los usuarios, su organización y sus
requerimientos de información, debe examinar los distintos tipos de datos “duros” que ofrecen
información no disponible por cualquier otro medio de recopilación. Estos datos revelan dónde ha
estado la organización y hacia dónde creen sus miembros que se dirige. Para formarse una imagen
precisa, el analista necesita examinar datos tanto cuantitativos como cualitativos.
Análisis de documentos cuantitativos
Hay muchos documentos cuantitativos disponibles para su interpretación en cualquier empresa:
informes empleados para la toma de decisiones, informes de rendimiento, registros y variados tipos
de formularios. Todos estos documentos tienen un propósito y una audiencia específicos.
Algunos ejemplos de este tipo de documentos son : informes de ventas, informes de producción,
balances, registros de clientes , de proveedores.
Análisis de los documentos cualitativos
Los documentos cualitativos incluyen mensajes de correo electrónico, memorandos, anuncios en
tableros y áreas de trabajo, páginas Web, manuales de procedimientos y de políticas. Muchos de
estos documentos contienen gran cantidad de detalles que revelan las expectativas de los autores
con respecto al comportamiento de los demás, junto con las formas en que los usuarios esperan
interactuar con las tecnologías de información.

ÉXITO Y FRACASO DE LOS SISTEMAS DE INFORMACIÓN

El desarrollo e implantación de los sistemas de información en muchas

ocasiones termina en fracaso, lo cual implica un alto coste para la empresa y la pérdida
de recursos que se podían haberse utilizado en usos alternativas. A continuación vamos
a realizar un análisis a modo de resumen de las principales causas que originan el
fracaso de los sistemas de información:

a) Falta de alineación entre los sistemas de información y la estrategia

empresarial: muchas organizaciones siguen considerando los sistemas de información como un
mero instrumento que simplifica la burocracia sin valorar las ventajas estratégicas que estos
presentan.

b) Escaso apoyo de la administración: la alta dirección de la compañía ha de

percibir realmente que los sistemas de información constituyen un arma estratégica. Además ha de
existir una predisposición a cambiar la organización empresarial si lo requieren los nuevos sistemas
de información.

c) Mala identificación de las necesidades de información: las empresas

implantan las tecnologías de información sin previamente haber realizado un proceso de
determinación de las necesidades de información y como estas pueden ser satisfecha utilizando
adecuadamente los sistemas de información.

d) Escasa involucración o influencia del usuario final: a la hora de diseñar

el sistema de información resulta fundamental contar con la opinión del usuario final, el cual va a
ser quien utilice el sistema de información. Por ello este usuario ha de estar motivado e incentivado
a colaborar en el diseño del sistema.

e) Nula formación del personal: se requiere siempre la realización de actividades formativas

para el aprendizaje de las nuevas herramientas informáticas a utilizar en la empresa.

A la hora de planificar, desarrollar e implantar los sistemas de información ha de

realizarse por parte de la empresa un alineamiento de la estrategia global de la compañía
y los sistemas de información, identificando las principales necesidades y evaluando los
distintos métodos de satisfacción, teniendo presente en todo momento cuáles son las
tecnologías de información disponibles en el mercado y como estas pueden
utilizarse. Además han de definirse claramente cuáles son los objetivos de los sistemas
de información.

El proceso de desarrollo de los sistemas de información afectará en gran

medida al éxito o fracaso de la organización; las organizaciones tendrán que
adecuar los sistemas de información a sus recursos de capital y las necesidades de la
organización. La posesión de la compañía los ordenadores más avanzados, los mejores
programas y la mejor red de telecomunicaciones no resulta indicativo de un mejor
sistema de información, pues en ocasiones puede que con tecnologías de
información más modestas se satisfagan de igual manera las necesidades de la
compañía. Por ello toda empresa ha de considerar los sistemas de información
como un todo, un elemento más de su política de negocio.
Bibliografía
FERNANDO MADGALENA, Sistemas Administrativos, Macchi, 1996
LAUDON & LAUDON, Sistemas de Información Gerencial. 12° Edición Pearson
Educación, México 2012
EFFY OZ, Administración de los Sistemas de Información, 5° Edición, Cengage Learing
Editores, México 2008
HENRY MINTZBERG, Diseño de organizaciones eficientes, El Ateneo, 1996
ALBERTO LARDENT, MANUEL GOMEZ ECHARREN, ALBERTO LORO, Técnicas de
organización sistemas y métodos, Macchi, 1993
JORGE ROBERTO VOLPENTESTA, Sistemas Administrativos y Sistemas de Información,
Ed.Osmar Buyatti 2004
LARDENT, ALBERTO R “Sistemas De Información Para La Gestión Empresaria
Procedimientos, Seguridad, Auditoría”.: Prentice Hall/ Pearson Educations Set/2001
Bs.As.
LARDENT,ALBERTO R "Metodología De Análisis Y Diseño De Sistemas De Información"..
Ed. El Coloquio, 2da. Edic.
ALBERTO LARDENT, “Sistemas de información para la gestión empresarial:
planeamiento, tecnología y calidad” Ed. Prentice Hall – 2001
KENNETH KENDALL Análisis y Diseño de Sistemas, 8°Edición, Pearson, México 2011
PUNGITORE JOSE LUIS Sistemas Administrativos y Control Interno, Osmar Buyatti,
Argentina 2007
JUAN JOSE GULLI, SCHULMA DIANA Y OTROS Diseño Organizativo, estructuras y
Procesos, 1° Edición Granica, Buenos Aires 2007