Sistemas II

Área Informática
INSTITUCIÓN CERVANTES Sistemas II
Fundamentos
La asignatura Sistemas II forma parte de la carrera Analista de Sistemas de Computa-
ción.
En la estructura de estudios corresponde al 2do. Cuatrimestre.
En esta asignatura los alumnos desarrollarán actividades que le permitan experimentar

en organizaciones del medio efectuando estudios de casos reales.
El perfil del alumno deberá potenciar fortalezas que lo preparen para el trabajo de rele-
vamiento de sistemas de información, en el contexto de una Organización, y deberá ad-
quirir habilidades para analizar e identificar los requerimientos y problemas, que le per-
mitan proponer un proyecto capaz de optimizar la situación identificada.
Objetivos Generales
Comprender las características de los sistemas de información.
Conocer el ciclo de vida de un proyecto de desarrollo de sistemas de información.
Comprender el rol del Analista en el proyecto de sistemas y la relación con los usua-
rios.
Aprender a efectuar el relevamiento de información conociendo la situación existen-
te en la organización objeto del estudio.
Identificar los requerimientos del usuario y los problemas y oportunidades existen-
tes en la organización objeto de estudio.
Comprender la importancia de la planificación del Proyecto.
Proponer el Plan del Proyecto capaz de optimizar la situación observada.
INSTITUCIÓN CERVANTES 1
INSTITUCIÓN CERVANTES
Contenidos
Unidad I: Sistemas de Información
Conceptos y diferencias de datos e información.
Función de la información.
Características de la información
Clasificación de la información.
Operaciones con los datos.
Métodos de Procesamiento de datos existentes.
La elección del método de procesamiento.
Sistemas de Información: Conceptos y características. Sistema Objeto, Sistema de
Datos, Teoría de los sistemas de Información.
Problemas de diseño de sistemas: infológico y datológico.
Funciones de los Sistemas de Información.
Necesidades de los Sistemas de Información.
Información para la toma de decisiones.
La toma de decisiones
Elementos para la toma de decisiones
Clases de decisiones. Decisiones Programadas y No Programadas
El proceso de toma de decisiones.
Niveles de toma de decisión.
Necesidades de información para los diferentes niveles de decisión.
La Información como un recurso de las organizaciones.
Unidad II: El ciclo de vida de desarrollo de los sistemas de información

¿Qué es el análisis y diseño de sistemas?
Responsabilidades del Analista de Sistemas
Responsabilidad de la programación de computadoras.
Papeles del Analista de Sistemas: Como consultor, como especialista de apoyo, co-
mo agente de cambio.
Lo que No es el Analista de Sistemas.
¿Cómo han cambiado las responsabilidades del Analista de Sistemas?
¿Quiénes son los usuarios de los sistemas de información?
¿Quiénes participan de los proyectos de sistemas?
Cómo comienzan los proyectos de sistemas. Razones para los proyectos.
Origen de las solicitudes de un proyecto
Administración de la previsión y selección de proyectos.
Tipos de Sistemas de Información.
El ciclo de desarrollo de los Sistemas.
Diferentes tipos de ciclo de vida de proyectos.
2 INSTITUCIÓN CERVANTES
Área Informática
Unidad III: El relevamiento de datos e información

Técnicas para hallar datos.
Entrevistas. Concepto, características, ventajas, desventajas, situaciones de aplica-
ción práctica.
Determinación del tipo de entrevista.
Etapas de la entrevista. Antes, durante y después de la entrevista.
¿A quiénes entrevistar?
Cuestionarios. Concepto, características, ventajas, desventajas, situaciones de
aplicación práctica
Revisión de registros, documentación y antecedentes. Concepto, características,
ventajas, desventajas, situaciones de aplicación práctica
Observación Personal. Concepto, características, ventajas, desventajas, situaciones
de aplicación práctica
Cuándo observar.
Relevamiento del hardware y software existente.
Unidad IV: Inicio del ciclo de vida de un proyecto - El estudio de la situación actual.
Estudio de la situación actual del negocio.
Determinación de los requerimientos de información para el futuro sistema. Ver-
daderos y falsos requerimientos.
Cómo se determinan los requerimientos básicos.
Identificación de los datos utilizados e información producida.
Determinación del tiempo de proceso y cantidad.
Identificación de controles.
Cómo se determinan los requerimientos de transacciones de los usuarios.
Cómo se determinan los requerimientos de decisión de los usuarios.
Identificación de problemas y oportunidades.
Unidad V: Anteproyecto.
El Anteproyecto.
Propósito.
¿Quién hace el anteproyecto?
Características.
Detalle.
La declaración de la meta.
La lista de objetivos.
El estudio de factibilidad de un proyecto.
Factibilidad Técnica.
Factibilidad Económica. El valor y costo de la información.
Factibilidad operativa.
Criterios de evaluación de los objetivos. Criterios de evaluación de costos, tiem-
pos y riesgos. Criterios de “idad”.
Opciones de solución.
El Anteproyecto escrito como un contrato.
Evaluación de diagnóstico
Esta asignatura requiere que el alumno tenga sólidos los conceptos recibidos en la
asignatura Técnicas de Programación I del 3er. Cuatrimestre de estudios.
A continuación se presentan una serie de preguntas que deberá responder con sus pro-
pias palabras.
1. Conceptualice: ¿Qué es un sistema?
2. Dé algunas clasificaciones de sistemas por Ud. Conocida.
3. Qué aspectos caracterizan a las organizaciones como sistemas.
Área Informática
4. De acuerdo al siguiente enunciado identifique:

Objetivos
Políticas.
Estrategias
Recursos
Procesos
Y defina brevemente cada uno de esos puntos.
“La institución INFORMÁTICA PARA EL NUEVO SIGLO dicta cursos de computa-

ción en un edificio situado en Av. Alem 1200. El mismo consta de una sala de recepción
para atención al público y actividades administrativas, y 10 aulas prácticas con 10 P.C.
cada una para el dictado de las clases.
Las reservas de lugar se realizan a través de la inscripción del alumno conjuntamente

con el pago de la matrícula.
Una vez que el alumno se matricula se lo anota en una ficha donde consta el curso, el
profesor y los alumnos anotados.
Esa ficha sirve para evitar que se pase del tope de alumnos anotados (12), aunque a ve-
ces se matricula un alumno sin que se controle el total inscripto hasta el momento.
No se efectúan reservas de lugar sin el pago de la matrícula correspondiente, aunque

en algunas oportunidades se anota con lápiz una especie de reserva previa para aquellos
que llaman telefónicamente, hasta que paguen la matrícula.
Normalmente ocurre que no se sabe quién tomó la reserva y cuando el alumno viene a
inscribirse los lugares están todos ocupados.
Para comenzar el curso se deben tener por lo menos 6 alumnos anotados, si eso no ocu-
rre el día anterior se le debe avisar a cada aluno la postergación de la fecha de inicio, lo
mismo al docente del mismo.
Tarea complicada es la de controlar todos los días la carpeta de fichas de cursos y anali-
zar si los cursos del día siguiente pueden comenzar o no, pues son demasiados los cursos
que comienzan cada mes.
Otro aspecto a tener en cuenta es que los alumnos pagan el curso el día del inicio, pu-
diendo hacerlo de contado o en dos cuotas en efectivo únicamente. Los pagos se llevan en
un Sistema de Administración computarizado.
A veces se pierde el control de las cuotas pagadas, pues no se sabe si el alumno sigue
viniendo al curso o lo abandonó.
Esto se sabe controlando la planilla de asistencia de cada curso. Estas planillas se emi-
ten a través del sistema el día de inicio y se entregan al profesor para el control diario de
inasistencias.
En cada curso el profesor toma un examen final y el alumno recibe el certificado sólo si
aprobó el mismo y está regular con las asistencias (80% obligatoria).
El control de inasistencias y calificaciones se lleva manualmente, lo que origina que al

final del curso cada docente deba preparar una lista con los alumnos aprobados.
Dicha planilla se encarpeta y en función de la misma se preparan los diplomas en ad-

ministración para ser entregados a cada alumno.
En algunas ocasiones los alumnos piden el diploma después de mucho tiempo y es len-
to el proceso de buscar la planilla del curso que hizo para poder preparar el certificado.
Las autoridades de la institución desean contar con un sistema que integre todas las ac-
tividades tanto en lo académico como en lo administrativo. Analice la situación existente
y conteste los puntos solicitados inicialmente.
Área Informática
5. Describa brevemente las características de los subsistemas de la organización.
6. Dé la definición de las actividades esenciales de la administración:

Planificar
Organizar
Dirigir
Coordinar
Controlar
Área Informática
7. ¿Qué información incluye un plan?
8. Compare y diferencie la organización formal y la informal.
9. ¿Para qué sirve un organigrama?
10. ¿Qué tipos de organigrama conoce?
11. ¿Qué es un puesto de trabajo?
12. ¿Qué elementos incluye un sistema de control?
13. ¿Qué tipos de control existen?
14. Enumere y describa brevemente los métodos de control conocidos.
Área Informática
Unidad I
Sistemas de Información
Objetivos Específicos
Diferenciar los conceptos de datos e información.
Comprender los diferentes métodos de procesamiento de datos y las operaciones que
se puedan realizar con los mismos para generar la información requerida.
Identificar las características, funciones y problemas de los sistemas de información.
Conocer el proceso de toma de decisiones.
Relacionar los diferentes niveles de decisión con características de la información re-
querida.
Mapa Conceptual de la Unidad
Área Informática
Introducción
La tecnología sobre computación abunda en la actualidad en todos los órdenes de la
vida cotidiana. Los negocios no son la excepción, las computadoras y los sistemas de
información ocupan un lugar especial ya que hacen posible la funcionalidad de las ofici-
nas de reservas aéreas, departamentos de registros hospitalarios, contabilidad, liquidacio-
nes de sueldos y operaciones bancarias, entre otras aplicaciones, tanto en empresas gran-
des como pequeñas.
Como se puede observar existen diferentes tipos de sistemas de información con objeti-
vos muy dispares, pero en todos los casos persiguen la meta de brindar la información a
los usuarios del negocio a fin de servir de apoyo a las acciones llevadas a cabo y a las de-
cisiones adoptadas.
La información será entonces, un recurso sumamente valioso para la organización; y,

como tal tendrá una utilidad para quien la recibe.
Ello implica que al momento de preparar un informe sus características podrán variar
de acuerdo al destinatario del mismo.
El desafío para los profesionales de sistemas consistirá en desarrollar sistemas de infor-

mación que sean capaces de brindar la información necesaria para que la organización
pueda alcanzar sus metas en forma efectiva y eficiente.
En esta unidad abordaremos las cualidades que debe tener la información, el proceso
de datos para generar la información con los métodos aplicados y las características y
funciones que tiene el sistema de información sobretodo en el apoyo a los procesos de
toma de decisiones.
Datos e Información
Los términos “Datos” e “Información”, son dos conceptos diferentes, pero íntimamente
relacionados.
8 Los DATOS son hechos aislados y en bruto, los cuales situados en un con-
texto significativo y mediante una o varias operaciones de procesamiento,
permiten obtener resultados que son objeto del procesamiento.
La finalidad de recopilar y procesar datos es la de producir INFORMACIÓN.
8 Por ello podemos definir a la información como el resultado del procesa-

miento de datos.
El procesamiento estará constituido por una serie de operaciones que se pueden aplicar
a los datos, como ser cálculos, clasificaciones, ordenamientos, etc.; sin importar los me-
dios que se utilicen para realizar dichas operaciones.
Aún cuando en la organización existan enormes volúmenes de datos, no todos tienen

importancia para los usuarios, por ende deben ser filtrados solo los importantes mediante
un adecuado sistema de información.
No debemos confundir cantidad con calidad informativa.
La información resultante del procesamiento debe satisfacer las necesidades del des-
tinatario, es decir, debe tener significado informativo.
8 En definitiva, podemos determinar que dato es una representación de he-

chos, conceptos o instrucciones, en forma convencional, que resulta
apropiada para la comunicación, la representación o el procesamiento
por medios humanos o automáticos.
La INFORMACIÓN significa un aumento de conocimientos, obtenidos por el recep-

tor, mediante la coordinación apropiada de los elementos de los datos con las variables de
un problema.
Información es cualquier clase de conocimiento o mensaje, para posibilitar, modificar o

corregir una decisión o una acción.
La información es el conocimiento derivado del análisis de los datos.
La información es el principal componente de las decisiones de las personas, aunque

por si sola no garantiza que la decisión adoptada sea la correcta.
8 Para concluir la información es un acontecimiento, o una serie de acon-

tecimientos, que lleven un mensaje y que, al ser percibida por el recep-
tor mediante alguno de sus sentidos, amplía sus conocimientos. Sólo el
destinatario puede evaluar la significación y la utilidad de la información recibi-
da.
Para citar un ejemplo, si un disertante quisiera preparar una charla en función del
promedio de edades de los asistentes, no le serviría contar con la edad de cada individuo o
de algunos de ellos, sino que necesitaría obtener un promedio de edades del auditorio.
Cada edad, es un dato, y el promedio resultante de una serie de operaciones de cálculo,

es la información.
De todos modos, siempre dependerá de la necesidad informativa del destinatario, pues

puede ser que el disertante requiriera la edad de un solo asistente, en ese caso la respuesta
obtenida (edad) será la información.
Función de la Información
La función primordial de la información, y, por lo tanto de un sistema de información,
consiste en aumentar el conocimiento del usuario, o en reducir su incertidumbre. La
Área Informática
información comunicada al usuario puede ser el resultado del aporte de datos a un mo-
delo de decisión, o de su procesamiento.
La información, tratándose de decisiones complejas, aumenta la certidumbre o reduce

el número de posibilidades.
Las funciones de la información pueden ser resumidas de la siguiente manera:
Proporcionar a quién toma las decisiones una base de probabilidades para su elec-
ción, reduciendo la gama de decisiones y la incertidumbre para una decisión inteli-
gente.
Proporcionar una serie de estándares de reglas de evaluación y de reglas de decisión
para la determinación y la comunicación de advertencias y retroalimentación para
fines de control.
La información puede provenir de diferentes fuentes, a saber, conversaciones con otras
personas, entes externos o del mismo sistema de información.
Características de la Información
La información puede ser:
Adecuada
Oportuna
Ilustrativa
Adecuada: La información debe ser adecuada en cuanto a su estructuración y selecti-

vidad. No debe ser abundante en demasía ni tampoco escasa. Debe ser suficiente y no
solo en cantidad, sino también en la forma de poner en evidencia los puntos críticos.
Es importante tener en cuenta algunos conceptos, por demás importantes:

Los niveles inferiores de una organización, generan mayor cantidad de información
que los superiores.
La información para los niveles superiores debe ser sintética, resúmenes o resulta-
dos. A medida que bajamos de niveles, aumenta el nivel de detalle.
Los niveles superiores, por la importancia de sus decisiones, tienen una mayor nece-
sidad de información que los inferiores.
Las decisiones que se toman en los niveles superiores tienen mayor importancia y
afectan a toda la organización (personas y demás recursos). A medida que bajamos
de nivel la importancia decrece.
Cada nivel requiere información adecuada al mismo.
Oportuna: La información debe ser oportuna en el tiempo. Debido al carácter diná-

mico de las decisiones, la información sólo tiene valor si se la posee en el instante mismo
que se la necesita.
La información debe representar la realidad y no estar atrasada.
Ilustrativa: Significa que debe ser comunicativa, inteligible y bien estructurada, es de-
cir, debe ser clara.
/ A continuación se analizan tres características relacionadas con la informa-

ción con respecto al nivel de jerarquía dentro de la organización.
Ellas son:
Cantidad de información generada

Nivel de detalle de información
Necesidades de información.
En primer lugar se presenta la cantidad de información generada, y tal cual se observa

en la figura siguiente, los niveles inferiores generan mayor cantidad de información que
los superiores.
Nivel de la Organización Cantidad de información generada
En segundo término se analiza el grado de detalle de la información. Los niveles supe-

riores requieren información de resultados o sintética, en cambio los inferiores necesitan
mayor cantidad de detalles para llevar a cabo sus operaciones.
Nivel de la Organización Nivel de detalle de la información
Por último observamos que los niveles superiores por la importancia de sus decisiones
tienen mayor necesidad informativa que los niveles inferiores.
Área Informática
Nivel de la Organización Necesidad de la información
8 Las características de la información dependerá de la necesidad del

destinatario y del nivel que ocupa en la Organización.
Clasificación de la Información
No existe una forma universal de clasificación de la información, sin embargo detalla-
remos a continuación algunas de las formas más frecuentes, a saber:
Información de acción o no acción: La información es de acción cuando el receptor

emprende una acción al recibirla, por ejemplo pedidos de clientes. Puede ser una
acción inmediata (recepción de un pedido), acción futura (factura con vencimiento
a 10 días), acción posible no definida (al recibir un informe de gastos generales pue-
de decidirse la acción inmediata o esperar un mes).
La información es de no acción cuando al recibirla no se hace nada, pues puede ser
que la acción ya se llevó a cabo (pago de sueldos) o simplemente pues cumple una
mera función comunicativa (información de un periódico).
Información recurrente y no recurrente: La recurrente se genera a intervalos regula-
res de tiempo (balance general), la no recurrente se obtiene cuando es necesaria (in-
forme de mercado, estudio de factibilidad de un proyecto).
Información documental y no documental: La primera es expresada por escrito o
que queda guardada en forma permanente (discos, disquetes), la segunda implica
transmisión por medio de la palabra.
Información interna e información externa: Depende de donde sea generada. La
primera es generada dentro de la organización (estados contables), la segunda es ge-
nerada en el ambiente (informe de la competencia).
Información de rendimiento presente, información histórica, información de pro-
yección futura, información simulada: De acuerdo al tiempo de ocurrencia de los
hechos o datos involucrados. La primera contiene datos de actualidad, la segunda
implica hechos ya ocurridos en base a los cuáles se puede plasmar una proyección
para el futuro. La información de proyección requiere confiabilidad y se prepara te-
niendo en cuenta a las dos primeras. Por ejemplo una proyección de gastos teniendo
en cuenta gastos de períodos anteriores, y los costos actuales para un lote de produc-
ción. La simulada plantea casos hipotéticos y resultados esperados para cada caso.
Por ejemplo qué cantidad de alumnos serían atendidos en la inscripción a exámenes

con dos, tres o cuatro bedeles con sus respectivas computadoras.
Información Constituyente de la organización, información para el Nivel Estratégi-
co, para el Táctico o para el Operativo o Técnico. Dependerá de la jerarquía del
usuario dentro de la organización.
Existen otras formas de clasificación, pero se han puesto las más importantes. Un as-
pecto importante es el hecho de que si un informa pertenece a una forma de clasificación,
no quita que pueda pertenecer a otra.
Operaciones con los Datos

Para que un sistema de información pueda producir información significativa, es nece-
sario aplicar a los datos a una serie de operaciones, que se detallan a continuación, a sa-
ber:
Captación: Registración de datos a partir de los eventos ocurridos.

Verificación: Comprobación o validación de los datos con motivos de seguridad.
Clasificación: Agrupamiento de los datos en categorías determinadas por el usua-
rio, por ejemplo los informes de ventas clasificados por clientes.
Ordenación: Implica colocar los datos en una secuencia específica determinada.
Un listado de alumnos ordenados por apellido.
Cálculo: Operaciones aritméticas y lógicas con los datos.
Almacenamiento: Guardado de los datos en algún dispositivo (papel, disco fijo),
para accederlos cuando se lo requiera.
Recuperación: Búsqueda y acceso a los datos necesitados.
Reproducción: Copia de datos de un dispositivo a otro.
DATOS PROCESAMIENTO INFORMACIÓN

METODOS DE
OPERACIONES
PROCESAMIENTO
/ Analice el siguiente texto y conteste las preguntas:

“Consideremos el caso de una Fábrica de Zapatos que vende a comercios
minoristas.
En base a las facturas realizadas durante el mes se debe preparar un infor-
me ordenado alfabéticamente con la razón social de cada cliente, el nombre
y apellido del titular de la firma, el domicilio, el T.E. y la dirección de correo
electrónico si es que tiene.”
Área Informática
a) ¿Cuáles son los datos y cuál la información?
b) ¿Qué operaciones con los datos identifica en el proceso de preparar el lista-

do?
c) ¿En qué rango de clasificaciones de la información recaería el listado de

clientes?
d) Si tuviera que preparar un informe con las ventas realizadas ordenadas por clientes
para ser entregada al Gerente General de la firma:
¿Detallaría todas las facturas realizadas? ¿Colocaría sólo el total facturado
para cada cliente? Justifique su respuesta.
Método de Procesamiento de Datos

Según sea el o los medios utilizados para efectuarla o las operaciones con los datos, será
el método de procesamiento.
Método manual: Todas las operaciones se realizan con la ayuda de dispositivos bási-
cos como lápiz, papel, reglas de cálculo, etc..
Método electromecánico: Participa el hombre secundado con máquinas (de escribir,
de calcular, registradoras, etc..)
Método de equipo de tarjetas perforadas, ya prácticamente en desuso, los datos están
dispuestos en tarjetas con columnas. El sistema trabaja con dispositivos como son
perforadoras, verificadora, reproductora, etc.. Al trabajar con dispositivos podríamos
incluirlo en la categoría anterior.
Métodos computarizados: Se utiliza únicamente la computadora como medio de
procesamiento destacándose su capacidad para trabajar con grandes volúmenes de
datos, capacidad de cálculo y de almacenamiento.
De todos modos a la hora de determinar el mejor método de procesamiento podemos

diferenciar directamente entre métodos computarizados o no.
Es más cuando se está realizando el diseño de un sistema de información se tendrá que
optar para cada proceso, si se le llevará a cabo con la computadora (implicando el desa-
rrollo del software específico por ejemplo para arrojar un listado de ventas) o se lo efec-
tuará manualmente (por ejemplo el control de un remito por un pedido recibido).
La elección del método de procesamiento

La elección del método de procesamiento requerirá por parte del analista de sistemas
un adecuado conocimiento de las necesidades de procesamiento. Las mismas están de-
terminadas por:
Volúmenes de datos involucrados.

Complejidad en las operaciones.
Las limitaciones de tiempo.
Demandas de cálculo.
Lógicamente, a medida que crece el volumen de datos, también aumentará la comple-

jidad de las operaciones o las demandas de cálculo, requiriendo mayor tiempo para las
tareas.
8 Conforme crezca el volumen de datos se aconsejará una mayor tecno-

logía para el procesamiento.
Área Informática
Demanda de
procesamiento
de datos
Nivel de automatización
De todos modos, al margen del asesoramiento profesional, es el usuario el que tendrá la

última palabra muchas veces basándose en cuestiones económicas.
Al margen de los factores enumerados anteriormente enumeraremos otros aspectos

igualmente importante a la hora de la elección y que son los siguientes:
Inversión inicial: Costo de máquinas e instalaciones.

Preparación: Gasto para la preparación de los datos.
Conversión: Gasto para la adecuación de los datos según el cambio de método de
procesamiento.
Personal especializado: La preparación exigida para el personal que trabajará con el
sistema.
Modularidad: Capacidad de aumentar o disminuir la capacidad de procesamiento.
Flexibilidad: Posibilidad de modificar el sistema de procesamiento en el futuro.
Velocidad de procesamiento.
Poder de cálculo frente a operaciones complejas.
Control de procesamiento de acuerdo a lo planeado inicialmente.
Detección de errores durante el procesamiento.
Poder de decisión ante diferentes alternativas.
Alteración del sistema: Grado de eficacia del sistema ante una eventual caída del
equipo.
Sistemas de Información
La denominación Sistemas de información (SI) tiene diversos significados. El más co-
mún “El sistema de información es un sistema de datos que recupera datos o contesta pregun-
tas”. De acuerdo a esto el SI provee información pero no procesa los datos...
Un uso más generalizado de la denominación sistemas de información se apoya en el

enfoque de que siempre que se usan o procesan datos, el propósito es proveer informa-
ción, ya sea para apoyar decisiones o emprender una acción o no. Es obvio que esta apre-
ciación comprende la primera.
8 Podemos definir un sistema de información como “cualquier sistema usado

para proveer información (incluyendo su procesamiento) para cual-
quier uso que pueda hacerse de ella”.
Interpretando la definición anterior consideraremos un sistema de información sin

importar si se utilizan computadoras o no.
El sistema de información deberá ser capaz de responder a las necesidades de informa-

ción de los usuarios, por lo tanto es importante analizar tales necesidades y sólo a partir
de ellas evaluar qué datos usar para su representación y procesamiento.
El sistema tendrá entonces que, recuperar los datos, procesarlos y generar la informa-
ción requerida.
8 El sistema de información se diseña para prestar servicio a otro:

su SISTEMA OBJETO.
Dicho sistema objeto es la organización misma para la que se diseña el sistema o para
un sector de ella.
Obviamente, cuando este sistema de información queda implementado, su parte ope-

rativa queda incluida en el sistema objeto. Este sistema objeto puede contener diferentes
componentes como hombres, máquinas, operaciones, datos o computadoras.
De acuerdo a esto podemos concluir que todo sistema de información incluye un SIS-
TEMA DE DATOS, que contiene los datos que hacen referencia a hechos ocurridos en
el sistema objeto.
De aquí se deduce que el problema básico de la TEORÍA DE LOS SISTEMAS DE

INFORMACIÓN debe ser como diseñar los datos en forma tal que realicen esas refe-
rencias.
La Teoría de los Sistemas de Información hace referencia a cómo definir la informa-

ción que requiere el sistema objeto y cómo proveerla usando datos y aprovechando las
tecnologías existentes.
Área Informática
Esto implica enumerar las “cuestiones teóricas” antes de trasladarlas al “mundo prácti-
co” analizando costos y beneficios involucrados.
Problemas del diseño de los sistemas de información

Un sistema de información es típicamente un sistema muy amplio y complejo que in-
volucra una extremada variedad de clases de problemas, las cuáles son tenidas en cuenta
en la Teoría de los Sistemas de Información de acuerdo a lo expresado anteriormente.
En un extremo encontramos el interrogante: Cómo podemos asegurarnos de que un sis-
tema responderá a las necesidades de información existentes o que se plantearán en el
futuro en el sistema objeto; en el otro extremo encontramos el problema de estructurar el
sistema de información en forma tal que se aproveche la tecnología de procesamiento de
datos existente.
Entonces tenemos dos categorías de “problemas” a tener en cuenta en el diseño de un

sistema de información, ellas son:
1. PROBLEMA INFOLÓGICO: ¿Qué información proveerá el sistema a fin de satisfa-

cer las necesidades de información de los usuarios? .
Este se descompone en dos subproblemas:

¿Qué sistema objeto existe o existirá?. Implica realizar un estudio que permita
tomar conocimiento del sistema objeto sobre el que se desarrollará el sistema de
información. Se deberán recabar datos de diferentes aspectos como son: Metas u
objetivos organizacionales, políticas, estrategias, métodos, perfil organizacional,
actividades llevadas a cabo, recursos, estructura existente (organigramas), planes,
problemas existentes, procedimientos llevados a cabo, documentación utilizada,
etc..
¿Cuáles son las necesidades o usos de información para cada función del sistema
objeto? Se deberá analizar detenidamente con la participación del usuario sus
verdaderas necesidades o requerimientos de información, par poder desarrollar el
sistema que pueda satisfacerlas.
2. PROBLEMA DATOLÓGICO: Cómo será estructurado y operado el sistema apro-

vechando eficientemente la tecnología de procesamiento de datos disponible.
Este se descompone a su vez en varios subproblemas:
Delinear la Arquitectura General del sistema de datos.
Construcción en detalle de los componentes de la estructura de datos.
Implementación y operación del Sistema de Datos.
Podemos sacar dos conclusiones importantes luego de haber tratado dos “problemas”
presentes en cualquier proyecto de desarrollo de sistemas de información.
Primero es importante tener en cuenta que:
/ “Un sistema de información estará bien diseñado sólo si provee la información

adecuada, en cuanto a su tipo, calidad y oportunidad, y lo hace en una forma
económica”.
Por otro lado debemos tener en cuenta que en todo proyecto...
/ Se realizará el diseño del sistema objeto, del sistema de información y del siste-
ma de datos. Por lo tanto se deberá diferenciar estas tres actividades.
Funciones de un sistema de información.

Enfocar el efecto completo de una decisión por anticipado, suministrando datos
completos, exactos y oportunos para los procesos de planeación.
Eliminar de los de los procesos de planeación y toma de decisiones los problemas
vinculados al empleo de datos incompletos o inconsistentes, mediante el aporte de
un medio para preparar y presentar información de manera uniforme.
Emplear datos y métodos ordinarios en la preparación de planes a largo plazo.
Identificar, organizar y medir relaciones pasadas significativas, para predecir rela-
ciones futuras a través del empleo de técnicas matemáticas especialistas en el análisis
de datos.
Fusionar datos económicos de producción y de mercado para producir mediciones
significativas de desempeño, a efecto de facilitar el control de los costos corrientes y
los planes de procesamiento de datos.
Satisfacer las necesidades de cada unidad de la organización, con un mínimo de du-
plicación, sirviendo al mismo tiempo a la organización como un todo.
Reducir el tiempo y el volumen de información requerida para la toma de decisio-
nes, mediante una información a cada nivel de dirección, con solo el grado de deta-
lle necesario.
Necesidad de un Sistema de Información

Un sistema de información se necesita con el propósito de usarlo como auxiliar de
otro sistema, el sistema de objetos o sistema administrador. El sistema de informa-
ción ha de suministrar la información necesaria en cualquier punto y en cualquier
momento, en un sistema de objetos. Este último será a menudo una organización,
es decir, una empresa o un cuerpo administrativo.
Es usual comprobar que cierto tipo de información es requerida con frecuencia, pe-
ro, en realidad, solo es una parte limitada del sistema de objetos; en cambio, otra in-
formación reclama datos originados en muchos puntos del sistema de objetos, pero
pueda realizar un muestreo en puntos mas distantes de tiempo.
En el diseño de un sistema de información es importante, por supuesto, ser capaz de
identificar situaciones de esta clase, porque al descuidar estas propiedades del sis-
tema uno puede realizar una labor excesiva de transporte y procesamiento de datos,
o tal vez menos de lo necesario. Ambos extremos originaran perdidas.
Área Informática
A fin de determinar la cantidad exacta de información que debemos suministrara

tenemos que ser capaces de descubrir por que se necesita la información en un sis-
tema. Comprobaremos que es conveniente invertir la pregunta e inquirir un cam-
bio: “¿Cómo podemos usar la información?”.
Precisamente cuando un sistema cambia su estado en el tiempo, necesitamos un sis-
tema de información que actué continuamente y que por lo tanto, afrontamos el
problema de diseñar el sistema de información que permita obtener eficientes flujos
de información y recolectarla.
Si el sistema de objetos servido o contratado por el sistema de información es estáti-
co, el sistema al sistema de información adquiere un carácter meramente computa-
cional, por ejemplo, en la de creación de un sistema de ecuaciones, el descubrimien-
to de su solución y su evaluación.
Una consecuencia de los dos puntos anteriores es que el diseño del sistema de in-
formación se refiera, muy a menudo a información vinculada con el control de un
sistema dinámico. En relación con el tiempo, las necesidades de información ten-
drán que determinar por el ritmo con que debe estar disponible y procesarse de mo-
do que permita la estabilidad del sistema controlado.
En los problemas del modo de control pertenecen a la teoría del control o toma de deci-
sión. La teoría de los sistemas de información tiene que estudiar las necesidades de in-
formación y las necesidades de procesamiento, según las determina la teoría del control y
hallar medios económicos de suministrara esta información y ese procesamiento.
Información para la toma de decisiones
La toma de decisiones
Una de las actividades básicas de la administración consiste en compenetrarse en las ca-
racterísticas del sistema hasta un grado que le permita juzgar el rendimiento con toda
propiedad, mejorándolo dentro de las restricciones establecidas.
La toma de decisiones, pues, es el proceso de elegir entre varias alternativas, que pue-
den ser cuantitativas o cualitativas, aquella que sea la mejor para resolver un problema o
arreglar un conflicto.
Elementos para la toma de decisiones

La causa por la que un administrador debe tomar una decisión es la confrontación de
un problema o la presencia de una situación conflictiva. El hecho de decidir resuelve el
problema o arregla el conflicto. Un proceso ordenado para llegar a una decisión contiene
cuatro elementos:
Un modelo. Un proceso es una descripción cuantitativa o cualitativa del problema.

Criterios. Los criterios establecidos representan las metas u objetivos del problema
de decisión (por ej. Mejorar el servicio a los cliente). Cuando varios criterios entran
en conflictos (por ej. Mejorar el servicio y reducir el inventario), quien toma la deci-
sión debe elegir un termino medio.
Restricciones. Son varios los factores que se deben considerarse cuando se trata de
resolver el problema de decisión. La falta de recursos es una restricción.
Optimización. Una vez planteado claramente el problema los objetivos y las restric-
ciones, se podrá elegir la mejor alternativa.
Clases de decisiones
Los problemas de decisión y los conflictos aparecen por todas partes. Algunos son sen-
cillos y deterministas, con pocas ramificaciones; pero otros son bastantes complejos y
probabilistas, y sus efectos pueden ser considerables. La toma de decisiones puede ser
rutinaria y bien estructurada, o compleja o mal estructurada. De manera que, en térmi-
nos generales, hay dos clases de decisiones: Programadas y no programadas.
Decisión Programada. Esta clase de decisión implica una respuesta automática de

acuerdo con las políticas previamente establecidas. Todos los problemas repetitivos y
rutinarios con parámetros bien definidos, se prestan a la decisión programada. La
identificación de esta clase de decisiones, la aportación de los posibles, son un reto
para el analista. Para tomar esta clase de decisiones es preciso haber establecido y de-
finido claramente una regla de decisión. Una vez establecida esta regla, todo se re-
duce a desarrollar un programa que permite llegar a la decisión de modo rutinario y
automático.
En muchas empresas se presenta la oportunidad de adoptar la decisión programada

porque gran parte de las decisiones se toman de acuerdo con procedimientos estándares
y rutinarios de operación. El beneficio de la decisión programada consiste en que los
administradores queden libres para enfocar su atención en otras tareas más importantes.
Un ejemplo de decisión programada sería el control de inventarios, cuando la deter-

minación del lote económico, el punto de reabastecimiento y la existencia de seguri-
dad son manejados por el sistema de computación conforme a las necesidades.
Cuando las existencias bajan hasta un nivel preestablecido, se indica automática-
mente la solicitud de un número de artículos para reabastecer los almacenes.
Decisión no programada. Esta clase de decisión representa el proceso de afrontar

problemas poco definidos. Generalmente dichos problemas son complejos y solo se
conoce una parte de sus parámetros, y ocurre que muchos de los parámetros conoci-
dos presentan un alto grado de probabilidad. La toma correcta de decisiones no pro-
gramadas requiere de todo el talento del administrador experimentado, más el auxi-
lio del sistema de información. La ampliación de la planta, el desarrollo de un nuevo
producto, las políticas de procesamiento y publicidad, el manejo de personal, la ad-
quisición contra el arrendamiento, las funciones, etc., son problemas que exigen la
decisión no programada. La sección siguiente analiza a quienes toman decisiones y
la función que desempeñan en esta clase de decisión.
Área Informática
El proceso de la toma de decisiones.

Las personas que toman decisiones poseen en diversos grados la facultad de asimilar la
información, lo cual determina la eficiencia de su procesamiento. Los conocimientos de
una persona, unidas a su eficiencia para procesar la información, determinan su capaci-
dad de decisión. Frente a varias alternativas, elige un objetivo y trata de alcanzarlo esco-
giendo, con base en lo que sabe, la mejor alternativa. Si reconoce que sus conocimientos
no le permiten comprender el significado de cada alternativa, busque información adi-
cional. Si trata de actuar sin tener información suficiente surgirán nuevos problemas y
tendrá que redoblar sus esfuerzos. La falta de información proviene de la incapacidad de
las fuentes para proporcionar toda la que hace falta, o de la incapacidad de quien toma
las decisiones para determinar exactamente sus necesidades.
Los directores de empresas, funcionarios del gobierno, administradores de colegios y

muchos otros invierten mucho tiempo en la solución de problemas y en el arreglo de con-
flictos. Se comprende que en buena medida su éxito en estas actividades estará relaciona-
da directamente con la calidad de la información que utilizan.
8 La toma de decisiones es un proceso de utilización de informes, no de

un proceso emocional.
Por lo tanto, en este contexto, las dificultades que se encuentran al tomar decisiones pue-
den imputarse a cualquiera de los factores siguientes:
Información inadecuada. Es decir información incorrecta o incompleta con respecto

a las diferentes alternativas de curso de acción o con respecto a sus implicaciones en
cuanto a los resultados.
Objetivos incorrectamente especificados. O sea que no se ha indicado claramente
cuales resultados son los más deseables.
Niveles de toma de decisión

Las decisiones pueden ser desde muy superficiales y rutinarias (programadas) hasta
muy complejas, o sea, aquellas que producen un efecto significativo en el sistema (no
programadas). Para su clasificación, situaremos la toma de decisiones en tres niveles:
estratégico, táctico y operativo o técnico.
A continuación se presenta un cuadro comparativo con las características de las deci-

siones de los tres niveles de la pirámide de administración.
TÉCNICO TÁCTICO ESTRATÉGICO

Referentes a realizar acciones A cerca de como utilizar los re- A cerca de qué hará la empresa,
inmediatas, por ejemplo, realizar cursos y su control, por ejemplo determinación de políticas, aprove-
un arqueo de caja. fijar fechas de compras. chamiento de oportunidades, etc..
Por ejemplo cambio de tecnolo-
gías a utilizar.
El horizonte en cuanto al tiempo, La persona que toma las decisio- Decisiones a largo plazo, a veces
es corto generalmente barca nes visualiza un período de tiem- pueden llegar a meses o años.
horas o minutos. po de días o semanas.
TÉCNICO TÁCTICO ESTRATÉGICO

Quien toma las decisiones esté en Los datos se originan dentro de la Los datos se originan en el exte-
contacto con los recursos, obte- organización, a veces a través de rior.
niendo los datos en forma dire- un sistema de datos.
cta.
Las incertidumbres si las hubiera Pueden estar involucrados ciertos Nivel de incertidumbre de impor-
son escasas. eventos futuros inciertos. tancia.
La escala de recursos que se La escala de recursos que se Se arriesgan recursos en gran
arriesgan es escasa. arriesgan es menor que en el nivel escala. De toda la empresa.
estratégico. Solo los de un área.
El proceso de decisiones es direc- Las decisiones requieren actividad En esencia es un proceso creati-
to. Se puede programar la deci- mental humana que sirve para vo, imaginativo y humano.
sión. reconocer las necesidades e iden-
tificar las alternativas.
La decisión por sí sola no requie- Se requiere meditar un poco más Tardan mucho más en adoptarse,
re demasiado tiempo. la decisión en contraste con las respecto a las dos anteriores.
operativas.
Tienden a ser altamente repetiti- Las decisiones administrativas tien- Las decisiones estratégicas son
vas. Se las puede programar y den a repetirse ocasionalmente, generalmente únicas, requiriendo
automatizar. permitiendo que los sistemas de datos externos.
control administrativo participen
activamente en el proceso.
Necesidades de Información
para los diferentes niveles de decisión
Los diferentes niveles de decisión tienen diferentes necesidades de información para
poder tomar decisiones.
Los analistas deben estar al tanto de estas clases de decisiones y conocer la forma de di-
señar el sistema de información con el fin de satisfacer las diversas necesidades, puesto
que la información generada por el sistema dependerá de esas necesidades.
Las características de la información requerida se indica a continuación:
Nivel estratégico: Información externa (acciones de la competencia, de los clientes,

estudios de mercado, etc.). Información predictiva o de proyecciones a largo plazo.
Información simulada. (qué pasaría si...).
Nivel Táctico: Información descriptiva histórica. Información sobre rendimiento
presente. Información predictiva futuro al corto plazo. Información simulada.
Nivel Operativo: Información descriptiva histórica. Información de rendimiento pre-
sente.
Todas las organizaciones cuentan con una u otra clase de sistema de información que,
según se supone, satisface las necesidades informales y disminuye la probabilidad de que
lleguen a adoptarse decisiones incorrectas. Sin embargo, muchos sistemas no pueden
proporcionar información adecuada para tomar decisiones estratégicas, y, hasta cierto
punto tácticas. Para la toma de decisiones estratégicas es imperativo diseñar sistemas de
información que puedan captar las realidades exteriores.
Área Informática
3 Actividad:
Se anima a contestar las siguientes preguntas de acuerdo a lo expresado ante-
riormente.
¿Qué relación existe entre un sistema de información implementado en una
empresa cualquiera y los procesos de decisiones establecidos en el Nivel Táctico
y Operativo?
Cite ejemplos de decisiones de Nivel Estratégico, Táctico y Operativo en una Insti-

tución Educativa de tipo Terciaria.
La Información como un recurso

de las Organizaciones
De tiempo atrás, las organizaciones han reconocido la importancia de una administra-
ción adecuada de los recursos básicos, tales como la mano de obra y materias primas.
Hasta ahora es cuando la información tiene una connotación de recurso primordial. Los
responsables de la toma de decisiones empiezan a considerar que la información no es
un producto colateral de la operación de la empresa, sino que en sí, es uno de los promo-
tores de la misma. La información puede ser un elemento decisivo que determine el éxito
o fracaso del negocio.
Como es un recurso indispensable para las acciones o decisiones empresariales, debe

ser administrado en forma correcta, pues existen costos asociados a la información en lo
que se refiere a su producción, distribución, seguridad, almacenamiento y recuperación.
Material Soporte de Información

KENDALL y KENDALL – Análisis y Diseño de sistemas Cap. 1
STONER-FREEMAN-GILBER Jr. – Administración
YOURDON, Eduard – Análisis Estructurado Moderno Cap. 2
F. ALVAREZ, Héctor – Principios de Administración
BAU GASCONS, Joaquín – El ejecutivo moderno
Área Informática
Unidad II
El ciclo de vida de desarrollo
de los Sistemas de Información
Diferenciar los conceptos de Análisis y Diseño.
Conocer los participantes de los proyectos de sistemas diferenciando las responsabi-
lidades que le competen a cada uno.
Conocer el ciclo de vida de un proyecto de sistemas.
Área Informática
Introducción
En la primera unidad se abordaron las funciones y características que tienen los siste-
mas de información.
Su desarrollo e implementación será la tarea de los analistas de sistemas.
Para que sea de utilidad para la organización donde se lo implementa, un sistema de

información basado en la computadora, debe funcionar adecuadamente, ser fácil de ma-
nejar y adecuarse a la empresa para la cual se lo diseñó.
Los proyectos de sistemas nacen a partir de la solicitud de los responsables de un nego-

cio por diferentes motivos.
Hasta que el sistema se implementa el proyecto pasará por diferentes fases o actividades
en las cuáles participarán analistas responsables del mismo y el personal del negocio.
Para comprender las diferentes etapas del ciclo de vida del proyecto de sistemas se de-
berá comprender qué es el análisis y diseño de sistemas, qué principios guían el esfuerzo
que implica desarrollar un sistema de información computarizado.
El ciclo de vida de desarrollo de sistemas de información transcurren por diversas eta-

pas, en esta unidad se describirán las mismas, se analizarán cómo comienzan los proyec-
tos de sistemas, quiénes participan, y qué responsabilidades le competen a los analistas de
sistemas.
¿Qué es el Análisis y Diseño de Sistemas?

En términos generales, en las empresas el análisis y diseño de sistemas se refiere al pro-
ceso de examinar una situación de la empresa con la intención de mejorarla mediante
nuevos procedimientos y métodos.
El desarrollo de sistemas puede estructurarse en forma general mediante dos compo-

nentes principales: análisis de sistema y diseño de sistema. El diseño de sistemas es el
proceso de plantación de un nuevo sistema dentro de la empresa para reemplazar o com-
plementar al existente; pero antes de que esto pueda llevarse a cabo primero se debe en-
tender por completo el sistema anterior y determinar cómo se puede utilizar la computa-
dora en forma óptima (si es posible) para hacer esta operación en forma más efectiva; por
lo tanto, el análisis de sistemas es el proceso que sirve para recopilar e interpretar los he-
chos, diagnosticar problemas y utilizar estos hechos a fin de mejorar el sistema. Es el tra-
bajo del analista de sistemas.
Considérese, por ejemplo, el almacén de una fábrica de ropa: con objeto de controlar
mejor sus inventarios y tener información más actualizada sobre los niveles de inventario
y punto de reorden, la empresa necesita "computarizar" la operación del almacén. Antes
de diseñar un sistema para la captación de datos, actualización de archivos y producción
de informes, se debe conocer más acerca de cómo maneja la tienda sus operaciones; por
ejemplo, saber qué formas se utilizan para almacenar la información en forma manual,
corno requisiciones, órdenes de compra y facturas, además saber qué informes se produ-
cen ahora y para qué se utilizan; por lo tanto, se debe buscar la información acerca de
dichos informes, listas de avisos de pedidos, órdenes de compra, inventarlo de existencias,
etc. También se necesita encontrar en dónde se origina esta información, por ejemplo, el
departamento de compras, el almacén o los departamentos contables. En otras palabras,
se debe comprender la forma en que trabaja el sistema actual, y más específicamente,
cuál es el flujo de información por el que atraviesa el sistema. También es importante
aprender por qué la tienda desea cambiar sus operaciones actuales: ¿tiene problemas al
dar seguimiento a los pedidos, a la mercancía o al dinero? ¿Ha caído en mucho "papeleo"
en el manejo de su inventarlo? ¿Necesita un sistema más eficiente antes de que amplíe
sus operaciones?
Sólo después de recabar todos estos datos se puede comenzar a definir cómo y dónde se
puede beneficiar un sistema de información basado en la computadora y que sirva a to-
dos los usuarios del sistema. Esta acumulación de información se llama estudio del
sistema y debe preceder a todas las demás actividades de análisis. Los analistas de siste-
mas no sólo resuelven problemas actuales. Frecuentemente se les llama para ayudar a
manejar la expansión planeada de una empresa. En este caso, el estudio del sistema se
orienta hacia el futuro, dado que no existe ningún sistema actual. El análisis, la conside-
ra, tan cuidadosamente como sea posible, cuáles serán las necesidades de la empresa y en
que área deberá considerar los cambios para que coincida con estas necesidades. En este
caso, Y en la gran mayoría de las circunstancias, los analistas pueden recomendar formas
alternativas para mejorar la situación. Normalmente es posible aplicar más de una estra-
tegia. Al trabajar con los gerentes y empleados de la empresa, el analista de sistemas re-
comienda qué opción debe adaptarse para una solución. La selección debe basarse en
aspectos como la adaptabilidad de la solución a la estructura de la empresa, así como el
apoyo que deberá tener por parte de los empleados. Si los usuarios que emplearán el sis-
tema no se sienten a gusto con éste, fallará en su propósito por mejorar la compañía. Al-
gunas veces el tiempo que lleva desarrollar una opción, comparada con otras, será el as-
pecto más difícil.
Los costos y beneficios financieros también son importantes de determinar. La gerencia

es la que al final seleccionará cuál opción va a aceptar. Los analistas de sistemas pueden
recomendar, pero la gerencia que va a pagar y utilizar los resultados es la que realmente
decide.
Una vez que se toma la decisión se desarrolla un plan para poner en marcha la reco-
mendación. El plan incluye todas las características de diseño de sistemas, como son ne-
cesidades nuevas de captación de datos, especificaciones de archivos, procedimientos de
operación, las necesidades de equipo y personal. El diseño de sistema, es como un plano
para una construcción; especifica todas las características que se considerarán en el pro-
ducto terminado. Los diseños para el almacén proporcionarán diferentes maneras para
captar los datos en relación con los pedidos para los clientes. También especificarán la
forma en que los datos se almacenarán, ya sea en formas de papel con medios legibles
para la computadora como discos magnéticos. De hecho, los diseños establecerán el tra-
bajo que desempeñará el personal y el que realizarán las computadoras. Por lo tanto, los
diseños variarán en la división de las tareas del personal y de la computadora. El personal
del almacén también necesitará información acerca del negocio. Cada diseño describe
informes, documentos y salidas que producirá el sistema. Las salidas probables incluyen
informes de inventario, análisis de ventas y resúmenes de compra y facturas; sin embargo,
Área Informática
el analista de sistemas será quien decida cómo se van a producir. El análisis específica
qué es la que el sistema debe hacer y cómo alcanzar el objetivo.
Cada uno de los procesos anteriores involucró al personal. Los gerentes y empleados
saben lo que funciona y lo que no es útil para la empresa; asimismo conocen qué ocasio-
na problemas, los lugares donde se necesita o no el cambio y, específicamente, dónde
afectará la innovación v dónde no. Aun cuando la tecnología abunda en muchas empre-
sas de negocios, el personal es todavía el que logra que esa compañía funcione; por lo
tanto, la comunicación y el trato con los empleados son parte muy importante del trabajo
del analista de sistemas.
Responsabilidades del Analista se Sistemas

A continuación se presenta una lista de los conjuntos más comunes de responsabilida-
des que se asignan a los analistas de sistemas (también se anotan entre paréntesis otros
nombres que se dan a los analistas).
Solamente el análisis de sistemas. Esta responsabilidad que es totalmente del analis-

ta radica en conducir el estudio del sistema para conocer los hechos importantes en
relación con la actividad del negocio. Se determinan los requerimientos de informa-
ción y del proceso. Sus responsabilidades no incluyen el diseño de sistemas. (Analis-
tas de información.)
Análisis y diseño de sistemas. Esta persona lleva a cabo el estudio completo del sis-
tema, pero también tiene la responsabilidad de diseñar el nuevo sistema. La gente
que es responsable tanto del análisis como del diseño de sistema trabajará en menos
proyectos, pero empleará más tiempo en cada uno. (Diseñadores de sistemas, des-
arrolladores de aplicaciones.)
Análisis, diseño y programación de sistemas. Esta gente dirige la investigación de
sistemas, las especificaciones del diseño del desarrollo y programa el software para
poner en marcha el diseño. (Analistas-programadores.)
No se debe deducir que un tipo de analista es mejor que otro, dado que a menudo el
tamaño de la empresa impone la naturaleza del trabajo del analista. En las compañías
pequeñas, los analistas llevan a cabo más actividades que en las compañías grandes, las
cuales contratan gente que se especializa por ejemplo en diseños de sistemas y no traba-
jan en otra cosa. En muchas empresas la programación real se desarrolla por personal
que se especializa en esta parte del desarrollo de sistemas. Con más frecuencia se les lla-
ma programadores de aplicaciones.
Otro aspecto a tener en cuenta es el tamaño del proyecto. En proyectos pequeños puede
participar un solo analista que cubre las diferentes responsabilidades, en otros, tal vez
más grandes trabajan un equipo de sistemas que se dividen las tareas según la especiali-
zación que tenga cada profesional.
Responsabilidad de la programación
de computadoras
¿Los analistas de sistemas escriben programas para computadora? ¿Realiza programas
para computadoras la mayoría de los analistas en la actualidad? Esto varía de una com-
pañía a otra; sin embargo, una cosa es muy clara, los mejores y más valiosos analistas de
sistemas saben programar. Los analistas de sistemas que tienen este tipo de conocimien-
tos normalmente son más valiosos para las compañías, ya que su experiencia adicional les
permite formular mejores y más completas especificaciones para una nueva aplicación.
No solamente conocen lo que puede o no hacerse dentro de un programa, sino también
saben qué es lo que se debe comunicar al programador. El resultado es casi siempre un
software de mayor calidad y menos tiempo de desarrollo. Esto es muy útil para cualquier
empresa.
Papeles del Analista de Sistemas

El analista de sistemas audita, de forma sistemática, el funcionamiento de la empresa al
examinar las funciones de captura y procesamiento de datos, así como la función de emi-
sión de resultados, lo cual le permitirá mejorar los procesos a la organización. Al mejorar
el soporte que proporcionan los sistemas de información computarizados, se obtienen
importantes avances en las funciones empresariales. Estas definiciones recalcan el uso de
enfoques sistemáticos y metódicos para analizar y lograr mejorar las operaciones que
ocurren en el contexto particular de la empresa.
8 El analista requiere tener la habilidad de trato para con cualquier tipo de, per-
sona, así, como también, tener la debida experiencia en el manejo de computa-
doras. El analista protagoniza numerosos papeles, y en ocasiones, se ve obligado
a mantener un equilibrio al asumir simultáneamente más de uno. Los tres pape-
les principales que el analista de sistemas debe cubrir son el del consultor, el
del especialista de apoyo o soporte y el del agente de cambio.
El analista de sistemas como consultor: Por lo regular, el analista de sistemas

participa como un consultor para la empresa. Esto implica que un analista pueda
contratarse sólo para canalizar a la empresa ciertos tópicos de la informática. Esto
ofrece una ventaja, en el sentido de que el consultor externo trae consigo perspecti-
vas frescas, que no poseen otros miembros de la organización. Por otra parte, para el
analista externo implica una desventaja, pues apenas tiene pleno acceso a la cultura
organizacional auténtica, que no se ofrece de forma abierta a un externo. Como
consultor externo, deberá conocer e implantar las metodologías, que le serán útiles
para analizar y diseñar sistemas de información adecuados para cualquier empresa
en particular. Más aún, contará con la ayuda de los usuarios de los sistemas de in-
formación, para entender la cultura de la organización desde sus propios puntos de
vista.
El analista de sistemas como especialista de apoyo: El otro papel que podrá
protagonizar es el de especialista de apoyo o staff dentro de una empresa, donde de
manera regular, trabaje dentro del departamento de sistemas. En esta posición, el
analista dispone de una experiencia profesional respecto al hardware y al software y
a sus aplicaciones en la empresa. Con frecuencia estas tareas no se asocian a un pro-
Área Informática
yecto ambicioso de sistemas, sino más bien implican decisiones o modificaciones

menores que se dan en un departamento individual. Como especialista de apoyo, no
dirigirá un proyecto, sólo será un recurso humano de apoyo para quienes lo dirigen.
Si es un analista de sistemas contratado por una organización de servicios o de ma-
nufactura, muchas de sus actividades diarias se ajustarán a este papel.
El analista de sistemas como agente de cambio: El papel que mejor se entien-
de y que le confiere una alta responsabilidad al analista de sistemas, es el de agente
de cambio; sin importar si es o no externo a la organización. Como analista, será un
agente de cambio cada vez que realice alguna de las actividades del ciclo de desarro-
llo del sistema, las cuales se mantienen presentes en la empresa por un largo periodo
(desde dos semanas hasta quizá más de un año). Un agente de cambio puede defi-
nirse como aquella persona que sirve como catalizador para el cambio, que desarro-
lla un plan para el mismo y que colabora con otros para agilizarlo. Su presencia de-
ntro de la empresa la modifica. Como analista de sistemas debe aceptar lo anterior y
utilizarlo como el punto de inicio de su análisis. Esto es por lo que tendrá que rela-
cionarse con los usuarios y con la dirección (si ellos no fueran la misma y única per-
sona), desde el principio del proyecto. Sin su colaboración, será incapaz de entender
lo que pasa en la organización y el cambio real no se llevará a cabo. Si el cambio
(esto es, los beneficios que la empresa obtiene mediante los sistemas de informa-
ción) parece quedar garantizado después del análisis, el siguiente paso será desarro-
llar un plan para tal cambio, en colaboración con las personas que se involucrarán
en tales cambios. Una vez que se alcance un consenso para el cambio a realizar, se
encontrará en constante relación con aquellos que estén participando del cambio.
Facilita el cambio al usar su experiencia en el trato humano y en la computación,
para llegar a una integración hombre-máquina en el sistema de información.
Lo que NO es el Analista de Sistemas

Se sabe que un analista de sistemas es quien estudia los sistemas de la empresa para
conocer los métodos actuales y buscar la efectividad; pero también es útil conocer lo que
NO es un analista de sistemas:
No es:
Quien estudia un negocio a fin de ver cuáles procesos debe manejar una computa-
dora y cuáles deben hacerse por métodos no computarizados.
Quien determina qué cambios deben realizarse. El objetivo de la investigación de
sistemas radica en estudiar el proceso de la empresa v evaluarlo. En ocasiones el
cambio no es necesario ni posible; éste puede ser un resultado, no una intención.
Quien determina cómo resolver mejor un problema de sistemas. Sin importar el tipo
de empresa, el analista trabaja en problemas comerciales. Sería un error distinguir
entre problemas del negocio en sí y de sistemas. Para estudiar cualquier sugerencia
debe considerarse primero si beneficiará o no a la empresa. Las ideas técnicamente
atractivas no deben considerarse a menos que mejoren el sistema del negocio.
¿Cómo han cambiado las responsabilidades

del analista de sistemas?
En alguna época todos los analistas de sistemas eran especialistas en computación, no
en negocios; por lo tanto, tenían que entrenarse en las funciones de un negocio antes de
poder desarrollar sistemas para un departamento de la empresa.
La situación cambia conforme el personal de las compañías aprende computación. En

la actualidad, los usuarios (gerentes v empleados dentro de una empresa) se adentran
cada vez más en el desarrollo de sistemas. Esto ocurre por varias razones:
Los usuarios han acumulado experiencia al trabajar con aplicaciones anteriores que
se desarrollaron para ellos. Tienen un mejor concepto de lo que significa el empleo
de sistemas de información.
Hoy en día, los usuarios que entran a las compañías de negocios con frecuencia han
recibido entrenamiento en el colegio o en la universidad sobre los diferentes aspectos
de los sistemas de información.
Las aplicaciones que se desarrollan en las empresas que tienen experiencia en sis-
temas de información se están volviendo complejas debido a que los analistas de sis-
temas necesitan de la participación continua de los usuarios con objeto de entender
las funciones del negocio en estudio. Continuamente surgen mejores herramientas
de desarrollo de sistemas.
¿Quiénes son los usuarios

de los sistemas de información?
Se mencionó a los usuarios en el tema anterior: gerentes y empleados dentro de una
empresa que interactúan con los sistemas de información.
Los usuarios directos son quienes realmente interactúan con el sistema. Ellos ali-
mentan (ingresan) datos o reciben salidas, quizás por medio de una terminal.
Los usuarios indirectos se benefician de los resultados o informes producidos por el
sistema, pero no interactúan directamente con el hardware o el software. Estos usua-
rios pueden ser gerentes de algún área de los negocios que utilicen el sistema (como
gerentes de mercadotecnia responsables de la aplicación del análisis de venta que da
como resultado informes mensuales).
Los usuarios administrativos, quienes tienen responsabilidades en la administración
de los sistemas de aplicación. Estos usuarios pueden ser gerentes de altos niveles con
diferentes funciones en los negocios, que emplean mucho los sistemas de informa-
ción. Mientras el personal puede no utilizar el sistema directa o indirectamente,
ellos tienen la autoridad para aprobar o desaprobar la inversión en el desarrollo de
aplicación; también tienen la responsabilidad de organización para la efectividad de
los sistemas.
Área Informática
¿Quiénes participan
de los proyectos de sistemas?
En un proyecto característico de sistemas participan las siguientes personas:
Usuarios: Aquel para quién se construye el sistema, que puede participar de diferen-
tes maneras según sea su categoría (usuarios directos, indirectos o administradores),
de acuerdo a lo visto anteriormente.
Administración: El término “administración” es bastante amplio y puede que los
analistas de sistemas estén en contacto con diversos tipos de administradores:
Administradores usuarios: Son administradores que están a cargo de varias perso-
nas donde se va a implantar el nuevo sistema. Son administradores que desean
que el sistema produzca informes internos y controles a corto plazo.
Administradores de informática: Encargadas del proyecto de sistemas.
Administración general: Administradores del Nivel Superior que no están direc-
tamente involucrados con la organización de informática ni son de la organiza-
ción usuaria. Pueden ser el Gerente General o el Jefe del área Financiera. Les in-
teresa los sistemas de apoyo a las decisiones o de planeamiento estratégico, y, por
lo general requieren informes externos.
Analistas de Sistemas: Son los responsables del proyecto de sistemas en sus diferen-
tes fases desde que el proyecto nace hasta que se implementa. Dependiendo de las ca-
racterísticas de la organización o de la envergadura del proyecto las responsabilidades
recaerán en una o varias personas. De todos modos según sean las responsabilidades
asumidas por el analista encontraremos las siguientes categorías de acuerdo a lo
enunciado anteriormente:
Analistas de Sistemas: Detectan requerimientos y problemas. Analizan el sistema
actual.
Analistas Desarrolladores o Diseñadores: Responsables del diseño del nuevo sis-
tema, de acuerdo a los requerimientos del usuario.
Analistas Programadores: Se encargan de la tarea de codificación. La preparación
del software de aplicación. Pueden también analizar o diseñar.
Auditores, control de calidad y departamento de normas o estándares: Par-

ticipan dependiendo del tamaño del proyecto, y su objetivo es controlar los sistemas
desarrollados de acuerdo a normas o directivas recibidas.
Programadores de Aplicación: Únicamente programan, pero no diseñan. Se en-
cargan de la tarea de codificación en base a la documentación recibida sobre el diseño
del sistema.
Personal de operaciones: Responsables del centro de cómputos, seguridad del
software y hardware, carga de datos, etc..
Cómo comienzan
los proyectos de sistemas
Las aplicaciones de sistemas de información se originan virtualmente en todas las áreas
de las compañías y se refieren a una gran cantidad de diferentes problemas de negocios. A
continuación se analizarán las razones por las que se hacen las solicitudes para ayuda de
sistemas y el origen de las propuestas de aplicación.
Los usuarios solicitan proyectos de sistemas de información por diferentes razones. A

veces es para solucionar un problema, como la reducción de costos, realizar ciertas tareas
o mejorar el control del trabajo que se lleva a cabo. Otras veces es para mejorar la eficien-
cia del trabajo realizado en los departamentos. En la mayoría de los casos, los usuarios
tienen varias razones para requerir ayuda de sistemas de información. Estas son algunas
de éstas:
1. MAYOR VELOCIDAD EN EL PROCESO:

Dado que las computadoras procesan los datos muy rápidamente, su velocidad es
una razón por la que la gente busca el desarrollo de proyectos de sistemas. Los sis-
temas basados en computadoras pueden ayudar a liberar al personal de varios cál-
culos tediosos o comparar diferentes artículos con otros. Por ejemplo, cuando al-
guien va a la tienda selecciona los artículos que desea comprar y los lleva a las cajas
registradoras. La cajera registra el precio de cada artículo en la caja registradora o
terminar instalada en el mostrador. Imagine el lector qué tedioso sería el trabajo si
el registro faltara, o cuánto tiempo tendría que esperar en la fila para pagar su com-
pra. Ni el cliente ni el empleado de la tienda estarían a gusto con ello.
Hoy en día, las tiendas ayudan a los cajeros a mejorar la velocidad instalando
nuevas terminales, conocidas como sistemas de punto de venta, que realmente son
pequeñas computadoras que calculan y almacenan información de compras con
una velocidad sorprendente. También consultan en la memoria información de
precios de productos que se venden a precios especiales. Estos sistemas consultan
los datos sobre precios mucho más rápido que el empleado, por lo tanto, cada em-
pleado está contento de dejarle esta tarea a la terminal ayudada por la computadora.
Un sistema automatizado puede ser de mucha utilidad; sin embargo, debe dise-
ñarse apropiadamente y utilizarse en forma efectiva; estos son dos aspectos que los
analistas deben tener en cuenta al examinar las requisiciones de provechos hechas
por los usuarios.
2. MAYOR EXACTITUD Y MEJOR CONSISTENCIA

En ocasiones se solicitan los proyectos de sistemas de información para mejorar la
exactitud de los datos procesados o para asegurar que siempre se siga un procesa-
miento que prescribe cómo realizar una tarea específica.
Tomamos como ejemplo un negocio de facturación y ventas de productos alimen-

ticios. La práctica común del proceso de facturas por pagar a los proveedores de-
mostrará esta razón para los requerimientos de proyectos. Los procedimientos es-
tándar mencionan que deben acumularse las facturas en grupos de 50. Antes de in-
troducirlas al proceso, los que toman el pedido calculan el total de todas las facturas
Área Informática
en cada lote y envían esta información con este lote. El contador verifica cada factu-
ra del grupo en cuanto a su exactitud aritmética, obtiene nuevamente el total de
costos y le añade los costos de embarque e impuestos de ventas. El total de todas las
facturas se acumula para obtener un total general del lote; a su vez es comparado
con el total manual del lote y preparado en forma anticipada por el que toma los
pedidos. Cualquier diferencia entre el total manual del lote y el nuevo total son se-
ñales de que hay un error (como un error aritmético, una factura sin procesar o una
factura perdida).
Este ejemplo describe un caso común del proceso de transacciones. El procedi-

miento presentado anteriormente no es difícil; sin embargo, si el procedimiento de
volver a calcular cada factura y acumular el total del lote se introduce en un pro-
grama de computadora, el contador puede guiarse a través de cada etapa de manera
que no se omita nada. Las etapas se completarán en forma consistente y exacta. Más
aún, todas las etapas se llevarán a cabo para cada lote de transacciones. A diferencia
del ser humano, el sistema no se distraerá con interrupciones telefónicas, no perderá
su lugar en el lote ni tenderá a saltearse las facturas más difíciles. La gerencia se be-
neficiará con la eficacia del sistema. (La persona responsable de procesar las factu-
ras estará muy contenta de tener esta ayuda.)
3. CONSULTA MÁS RÁPIDA DE LA INFORMACIÓN

Las empresas almacenan grandes cantidades de datos sobre sus operaciones, em-
pleados, clientes, proveedores y finanzas. Dos aspectos son constantes: dónde alma-
cenar los datos y cómo consultarlos cuando se necesitan. El almacenamiento de da-
tos se vuelve más complejo si los usuarios desean recuperar los datos en varias for-
mas en diferentes circunstancias.
Por ejemplo, La información sobre el suministro y uso de la materia prima es de

vital importancia para las compañías manufactureras. Cada parte utilizada en la
manufactura de una máquina de escribir, por ejemplo, tiene un número de parte
que la identifica y es único, y una descripción de ese artículo; además, cada artículo
lo suministran fabricantes específicos y se utiliza en uno o más productos diferentes.
Hay muchos usuarios de los datos, corno el supervisor de producción que maneja la
manufactura, el comprador que adquiere la materia prima o el ingeniero, quien de-
termina el conjunto de piezas necesarias para fabricar cada producto. Los usuarios
necesitan tener la posibilidad de recuperar la información para responder a las si-
guientes preguntas representativas:
¿Qué materiales suministra la empresa XX?

¿Quién es el proveedor del motor de bajo ruido de un caballo de fuerza?
¿En qué modelos de máquinas de escribir se utiliza un tabulador automático?
La respuesta a cualquiera de estas preguntas puede encontrarse en una empresa

que no utiliza computadoras, ya sea solicitando al administrador del registro que
busque en cada registro del archivo cada pregunta, o en el archivo más importante,
si se tienen varios; cada uno está organizado para contestar una pregunta diferente.
Por ejemplo, si el archivo se almacena por número de identificación de cada parte,
para contestar la primera pregunta citada, el empleado del registro de pedidos debe
buscar en cada registro para ver si el proveedor es XX.
Los costos de cada opción en tiempo y espacio de almacenamiento pueden ser tan
altos que la gerencia se conformaría con menor información que la que se necesita-
ría para operar en forma efectiva. Sin embargo, al desarrollar en forma apropiada
un sistema basado en computadoras, la gerencia puede asegurar que está en posibi-
lidad de obtener las respuestas para cualquiera de las preguntas anteriores rápida-
mente.
4. INTEGRACION DE LAS ÁREAS DEL NEGOCIO

Los sistemas de información se utilizan para integrar las actividades que se ex-
panden alrededor de diversas áreas de la empresa. En muchos negocios, el trabajo
hecho en determinada área es coordinado con el que se lleva a cabo en otra. La ma-
nufactura, por ejemplo, depende de los materiales ordenados por compras. Para co-
ordinar mejor las áreas, la gerencia a menudo distribuye informes tanto de compras
como de producción a ambos departamentos. Para mencionar otro ejemplo, consi-
dérese el trabajo de coordinar el diseño y manufactura de un gran avión de pasaje-
ros, un grupo de diseñadores trabaja en las alas, otro en la cabina, otro en la sección
de la cola y así sucesivamente; incluso otros equipos de trabajo, como los que dise-
ñan los sistemas eléctricos, de comunicación y suministro de aire, deben conocer su
relación con otros diseños antes de que puedan completar sus tareas. Para cada ta-
rea se utilizan diferentes materiales con costos variables. Se necesita una gran coor-
dinación para asegurar que los componentes ensamblen entre sí, que el proyecto se
termine conforme al calendario establecido y que los costos estén de acuerdo con lo
esperado. La coordinación se lleva a cabo en forma más compleja por el número de
días y meses que lleva terminar el avión. El tiempo en este ejemplo es un problema,
porque puede haber intervalos de meses entre algunas tareas, aunque dependan
una de otra para que el avión pueda volar finalmente. También el personal se in-
corpora o se retira del proyecto. Considérese la información que se necesita para di-
rigir y coordinar este trabajo.
En este caso, los sistemas de información son útiles para comunicar los detalles de
diseño entre los diferentes grupos, para mantener las especificaciones esenciales en
una situación accesible y para calcular factores tan necesarios como son la tensión y
los niveles de costo a partir de datos que proporcionan otros grupos.
5. REDUCCIÓN DE COSTOS
Algunos diseños de sistemas permitirán que se realice la misma cantidad de traba-
jo a menor costo; es decir, si se acepta la ventaja del cálculo automatizado y de las
capacidades de recuperación que se pueden incluir en procedimientos de flujo con-
tinuo de programas de computadoras. Algunas de las tareas las lleva a cabo un pro-
grama de computadora y menos quedan por hacerse en forma manual.
Ahorrar dinero es atractivo para los gerentes. En el pasado, mucha gente pensaba
que al desarrollar aplicaciones de sistemas de información, especialmente las alta-
mente automatizados, se necesitaría menos personal. En realidad, los procedimien-
tos automatizados del negocio pueden cambiar la naturaleza del trabajo (es decir,
menos cantidad de trabajo atractivo puede turnarse a los sistemas basados en com-
putadoras) pero la necesidad de personal normalmente no decrece. Los usuarios
deben mantenerse escépticos respecto a que las nuevas aplicaciones reduzcan los
requerimientos de personal, lo que frecuentemente no sucede. Por otro lado, el per-
Área Informática
sonal que experimente ansiedad respecto a su trabajo cuando se desarrollan aplica-

ciones automáticas seguro debe sentirse. Rara vez son desplazados y, de hecho, su
trabajo puede convertirse en algo más interesante si las tareas tediosas se automati-
zan.
6. MAYOR SEGURIDAD
A veces, el hecho de que los datos puedan almacenarse en forma legible para la
máquina, provee una seguridad que sería difícil de alcanzar en un ambiente no
computarizado. Por ejemplo, una compañía fabricante que produce jabones y lim-
piadores automatizó por completa sus fórmulas de producción.
Para proporcionar mayor seguridad, la gerencia desarrolló un sistema de informa-

ción automatizado de fórmulas. Todas las fórmulas de los productos y costos se al-
macenaron dentro del sistema. El acceso a esta información tan confidencial se con-
trolaba a través de un intrincado sistema de palabras clave; se necesitaba la palabra
clave para utilizar cualquier información.
Concluyendo, las solicitudes de proyectos a menudo se incluyen por más de una

razón. Las que se han listado aquí señalan las áreas en donde las propuestas son
más justificables. Desear desarrollar un proyecto que parezca como más avanzado o
productivo al tener un sistema automatizado, no es justificación adecuada para in-
vertir en sistemas basados en computadoras. El mejoramiento en las operaciones,
como las que se han presentado anteriormente, deberá formar la base para cual-
quier solicitud de proyecto.
Origen de las solicitudes de un proyecto

Existen cuatro orígenes principales de solicitudes de proyecto. Los solicitantes de la
empresa son gerentes de departamentos, altos ejecutivos y analistas de sistemas. También
las agencias gubernamentales, fuera de la empresa, pueden solicitar proyectos de sistemas
de información. Los solicitantes pueden buscar aplicaciones totalmente nuevas o cambios
en las ya existentes dependiendo del origen y de la razón de la solicitud.
Gerentes de departamento
Frecuentemente, las personas que trabajan diariamente en las actividades del negocio,
va sean empleados o gerentes, buscan ayuda dentro de su departamento. Por ejemplo, en
una gran clínica médica un gerente de negocio supervisa la preparación de las formas de
reclamación para los pacientes que se registran en las compañías aseguradoras, las cuales
reembolsan a la clínica el dinero del cuidado médico. El administrador observa la gran
cantidad de tiempo invertido por los contadores que mecanografían formas idénticas de
seguros para solicitar información que ya está almacenada en los registros médicos de
cada paciente.
Después de comentar el problema del seguro con los administradores de otras clínicas,
el gerente solicitó al comité administrativo deja clínica, que se aprobara el desarrollo de
un sistema basado en la computadora para preparar las formas de los seguros y mantener
los registros de los pacientes en relación con los pagos de las aseguradoras.
El ejemplo de la clínica es común en casos donde los gerentes solicitan proyectos de sis-
temas.
Ejecutivos de alto nivel

Los ejecutivos de alto nivel, como los presidentes, presidentes de consejos y vicepresi-
dentes normalmente tienen información sobre la empresa que no está disponible para los
gerentes de departamento. Esta información, junto con las amplias responsabilidades que
ellos asumen administran las compañías en su totalidad en lugar de departamentos indi-
viduales), influyen los requerimientos de proyectos de sistemas que ellos solicitan. Por
ejemplo, el vicepresidente de producción que sabe que una sucursal adicional de produc-
ción se construirá dentro de dos años en otra ciudad, puede querer implantar un proyecto
de sistemas para desarrollar un sistema de planeación centralizado de la producción que
permita a la gerencia planear la producción en ambas plantas al mismo tiempo. Este pro-
yecto incluye varios departamentos (producción, control de inventarios y compras) en dos
localidades, e incluye muchas otras gerencias.
Los requerimientos de proyectos solicitamos por los ejecutivos de alto nivel son más
amplios en sus objetivos que aquellos que preparan los gerentes de departamento.
Analistas de sistemas
En ocasiones, los analistas de sistemas detectan áreas donde los proyectos se deben des-
arrollar, ya sea que escriban una propuesta de sistemas o motiven a un gerente a realizar
una propuesta. Por ejemplo, un analista que ve que un procedimiento de registro de cur-
sos universitarios es lento, con tendencias a provocar errores e ineficiente en forma gene-
ral, puede elaborar una propuesta de proyecto para un nuevo sistema de registro.
Grupos externos
Los diferentes acontecimientos fuera de la compañía también originan solicitudes de
proyectos. Por ejemplo, a quienes llevan contratos con el gobierno se les solicita el uso de
sistemas especiales de contabilidad de costos, con características estipuladas por el mismo
gobierno. (De otra forma, pueden no estar en condición de recibir contratos por parte del
gobierno.)
Administración de la previsión y
Selección de proyectos
Se generan muchas más solicitudes de desarrollo de sistemas, de las que las compañías
quieren o son capaces de llevar a cabo. Algunas solicitudes valen la pena, otras no. Antes
de que cualquier trabajo se lleve a cabo en relación con estas solicitudes, alguien debe
decidir cuáles se van a realizar y cuáles se van a rechazar (quizá para canalizarlas por
otros medios). La decisión de aceptar o rechazar una petición puede hacerse en muchas
formas diferentes y por diversos miembros de la empresa. Los analistas de sistemas no
son los que toman la decisión final.
Área Informática
Uno de los métodos más comunes para revisar y seleccionar los proyectos de desarrollo
es mediante un comité. Existen varios tipos de comité que seleccionan los proyectos; tres
de ellos son: comité directivo, comité de sistemas de información y comité del grupo de
usuarios.
Tipos de Sistemas de Información

Los sistemas de información se desarrollan con diferentes propósitos, los cuales depen-
den de las necesidades de la empresa. Los sistemas de procesamiento de datos, los siste-
mas de información para la administración (MIS, Management Information Systems), y
los sistemas de apoyo para la torna de decisiones (DSS, Decision Support Systerms), son
diferentes tipos de sistemas de información computarizados que se analizan y diseñan
mediante la aplicación de los conceptos y las técnicas del diseño y del análisis de sistemas.
3 Actividad:
Complete el siguiente cuadro resumen con la enumeración de los partici-
pantes en los proyectos de sistemas y una breve explicación de las respon-
sabilidades que le competen a cada uno:
PARTICIPANTE RESPONSABILIDADES
El ciclo de desarrollo de los sistemas

En las organizaciones pequeñas los proyectos de desarrollo de sistemas nacen de con-
versaciones entre el usuario y el administrador del proyecto (analistas de sistemas), y el
proyecto procede desde el análisis hasta el diseño e implantación del sistema.
En las organizaciones más grandes, la cosa es más formal. La comunicación entre los
usuarios, la administración y el equipo de sistemas suele ser por escrito, y todo el mundo
entiende que el proyecto pasará por diversas fases antes de completarse.
Puede variar la forma en que dos analistas afronten sus proyectos, y por lo general son
estos los que determinan las fases o actividades que se llevarán a cabo.
El tener un ciclo de desarrollo unificado apunta a 3 (tres) objetivos principales:
1. Definir las actividades a llevarse a cabo en el proyecto.

2. Lograr congruencia entre los diferentes proyectos de la misma organización.
3. Proporcionar puntos de control y revisión administrativos de las decisiones sobre
continuar o no con el proyecto.
El ciclo de vida del proyecto organizará las actividades del administrador del mismo,
aumentando la probabilidad de que se aborden los problemas pertinentes en el momento
adecuado.
No siempre los analistas están de acuerdo respecto al número exacto de etapas o activi-
dades que conforman el ciclo de desarrollo de los sistemas; sin embargo, por lo general se
reconoce la importancia de su enfoque sistemático y ordenado.
Dependiendo el autor o de la metodología seguida para el desarrollo del proyecto existi-

rán diferentes números de etapas.
A continuación daremos un ciclo de vida general para los proyectos de desarrollo de sis-
temas. Identificaremos los siguientes puntos a cubrir:
1. Estudio de la situación existente.

2. Análisis del Nuevo Sistema.
3. Diseño del Sistema.
4. Construcción.
5. Pruebas del Sistema.
6. Implementación.
A continuación se da una explicación de cada uno.
Estudio de la situación existente: A través de las diferentes técnicas de relevamiento de

información, se deberá realizar un exhaustivo estudio del comportamiento del sistema
actual, detectando fortalezas y debilidades. Lo que se realiza no es ni más ni menos que
un análisis del sistema actual.
Esto implica recopilar datos sobre las características del negocio (metas, actividades,
contexto, recursos, estructura y demás puntos que se necesiten para el proyecto en curso).
Se deberán detectar requerimientos de información del usuario a cubrir en el nuevo sis-

tema, dificultades existentes y oportunidades a tener en cuenta. Estos, constituyen el dia-
gnóstico del comportamiento del sistema actual con las diferencias entre lo qué se está
dando y lo qué se debería dar de acuerdo a lo que pretende el usuario.
Análisis del Nuevo Sistema: A partir del diagnóstico obtenido, se planteará el modelo
del nuevo sistema. El modelo será una representación abstracta del sistema real, y, por lo
Área Informática
general serán esquemas gráficos del comportamiento interno que tendrá el sistema, re-
presentando los procesos intervinientes para poder cubrir requerimientos y solucionar los
problemas encontrados, y el ambiente en el que actuará el sistema.
Diseño del Sistema: Los modelos planteados en el punto anterior comienzan a acer-
carse al sistema real. Se determinan qué procesos se automatizarán y cuáles no, se especi-
fica la interfaz hombre-máquina (diseño de pantallas y diálogos entre el usuario y la
computadora), se diseñan las estructuras de datos, se definen las lógicas de los procesos.
Se plantea la base para la futura programación.
Construcción: Se refiere al desarrollo del software conocido como la codificación o

programación. Se define la estructura de módulos del sistema con el esquema de menú
de opciones previstos.
Pruebas del Sistema: A partir de casos de pruebas definidos entre el analista y los usua-
rios se realizan pruebas de comportamiento al nuevo sistema hasta que el usuario de
garantías de la calidad del mismo, es decir apruebe su implementación.
Implementación del sistema: Una vez aprobado el software se procederá a la instala-

ción del mismo. La forma en que se lo haga (gradualmente en diversas etapas, en forma
completa, etc.) dependerá de cada proyecto.
Sin embargo para poder instalar el sistema, los analistas deberán preparar los manuales
de usuario con las explicaciones de la operatividad del sistema, los manuales de procedi-
mientos, con los detalles de cada proceso (automatizados o no), capacitar a los usuarios
sobre el nuevo sistema y preparar las bases de datos para poder comenzar a trabajar (car-
gas iniciales, conversiones de datos del formato manual al informatizado, adaptación de
archivos de datos de viejos sistemas al nuevo).
Diferentes tipos de ciclo de vida de proyectos

Existen diferentes metodologías para el análisis y diseño de sistemas, y, obviamente de-
pendiendo de estas variarán el nombre y la cantidad de las actividades o fases el ciclo de
vida del proyecto; sin embargo sea cual fuere la metodología adoptada en todo proyecto
existirá una forma de estudio inicial, un análisis, un diseño y la programación e imple-
mentación final.
Varía la forma de encararlo, el número de actividades según como se las agrupe o divi-
da, el nombre de las mismas, pero siempre el proyecto nacerá con el planteo inicial del
usuario y terminará una vez implementado.
En el ciclo de vida del proyecto clásico se trabaja con la idea de un modelo en

cascada en donde para avanzar a la etapa siguiente tengo que finalizar la anterior.
El sistema se implanta en forma ascendente pues se efectúan pruebas individuales de

los programas, luego se prueban los subsistemas y por último se prueba todo el sistema.
Las etapas son las siguientes: Encuesta, diseño preliminar, estudio del hardware, análi-
sis, diseño detallado, codificación, prueba de programa, prueba de subsistema, prueba del
sistema.
En ciclo de vida del proyecto semiestructurado se aplica un modelo donde ya

no hablamos de fases o etapas sino de actividades. Si en un punto del ciclo noto una de-
bilidad de alguna actividad anterior puedo retornar a la misma y efectuarle los cambios
necesarios. Se puede trabajar con actividades en forma paralela.
La implantación es de arriba hacia abajo, que es un enfoque en el cual los módulos de

alto nivel se codifican y prueban primero, seguidos por los de bajo nivel, más detallados.
Se programa en forma estructurada, siguiendo estructuras de programa y procedimientos.
El diseño clásico es reemplazado por el diseño formal tratado por autores como Yourdon
y Constantine y Page-Jones.
Las actividades del ciclo semiestructurado son: Encuesta, estudio del hardware, análi-
sis, diseño estructurado, implantación descendente; que no se realizarán siguiendo un
orden rígido como ocurría en el enfoque clásico.
En ciclo de vida estructurado se complementa lo planteado en la metodología se-

miestructurada. También aquí la implantación es de arriba hacia abajo y se pude reto-
mar actividades anteriores para efectuar correcciones.
Las actividades son: Encuesta, análisis, diseño, implantación, generación de pruebas de
aceptación, control de calidad, descripción de procedimientos, conversión de bases de
datos y por último la instalación del sistema.
En el ciclo de vida de prototipos se realiza una variación del enfoque descendente

antes discutido. Se lo conoce como enfoque de prototipos y lo popularizaron Bernard
Boar, James Martin y otros. Como lo describe Boar:
“Una alternativa de enfoque para la definición de los requerimientos consiste en

8 capturar un conjunto inicial de necesidades e implantarlas rápidamente con la in-
tención declarada de expandirlas y refinarlas iterativamente al ir aumentando la
comprensión que del sistema tienen el usuario y quien lo desarrolla. La definición
del sistema se realiza mediante el descubrimiento evolutivo y gradual y no a través
de la previsión omnisciente... Este enfoque se denomina de prototipos o modelado
de sistemas o desarrollo heurístico.”
En la metodología de diseño orientada a objetos el software se organiza como

una colección de objetos discretos que contienen tanto estructuras de datos como un
comportamiento. Se tienen en cuenta cuatro aspectos: identidad, clasificación, polimor-
fismo y herencia.
La metodología consiste en construir un modelo de un dominio de aplicación añadién-

dose detalles de la implementación durante el diseño del sistema. Esta aproximación se
denomina Técnica de Modelado Orientada a Objetos (OMT), y consta de las siguientes
fases: análisis, diseño del sistema, diseño de objetos e implementación.
Para ampliar las características de las fases o actividades de cada metodología podrán
remitirse a los libros de Análisis Estructurado Moderno de E. Yourdon, Análisis y Dise-
Área Informática
ño Práctico de sistemas Cliente-Servidor con GUI de David A. Rubble, Análisis y diseño

Semiestructurado de Sarson-Gene, Modelado y Diseño orientado a Objetos de Rum-
baugh-Blaha-Premerlani-Eddy-Lorensen.
3 Actividad:
Accediendo a la bibliografía anteriormente mencionada Ud. deberá:
1. Investigar las diferencias entre las metodologías en cascada y en espiral.
2. Completar las características y actividades o fases de cada metodología ante-

riormente mencionada.

SENN – Análisis y diseño de Sistemas de información Cap. 1 y 2
RUBLE, David – Análisis y Diseño Práctico de Sistemas Cliente-Servidor con GUI
Cap. 1
KENDALL y KENDALL – Análisis y Diseño de sistemas Cap. 1
YOURDON, Eduard – Análisis Estructurado Moderno Cap. 3 y 5
RUMBAUGH-BLAHA-PREMERLANI-EDDY-LORENSEN - Modelado y Dise-
ño Orientado a Objetos Cap. 1
PRESSMAN, R. – Ingeniería del Software Cap. 1
Área Informática
Unidad III
El Relevamiento de Datos e Información
Aprender a realizar el relevamiento de información.
Comprender las técnicas para recopilar datos conociendo las características de cada
una, sus ventajas y desventajas, y las situaciones en que conviene aplicarlas.
Área Informática
Introducción
Como se vio anteriormente el punto clave del análisis de sistemas se consigue adquirir
un conocimiento detallado de todas las características del área de negocio que se investi-
ga.
Los analistas deben estudiar el proceso que actualmente se lleva a cabo para contestar
preguntas clave como son:
¿Qué se está haciendo?

¿Cómo se está haciendo?
¿Qué tan frecuentemente ocurre?
¿Quién lo realiza?
¿Existen problemas?
Para contestar estas preguntas los analistas deberán recabar datos dentro de la organi-
zación, hablando con las diferentes personas, preparando cuestionarios escritos, o asis-
tiendo al lugar de los hechos a fin de observar la forma en que se desarrollan las activida-
des.
En esta unidad se analizarán las diferentes técnicas para recabar información a fin de
poder obtener un cabal conocimiento de la situación existente en el negocio.
Técnicas para hallar datos

Para poder llegar a conocer a fondo el sistema objeto, con sus características, problemas,
y necesidades de información, el analista deberá realizar un relevamiento de información
detallado.
El relevamiento es una de las actividades esenciales dentro del ciclo de vida del proyec-
to y es fundamental prestarle la debida atención.
A través del mismo podremos conocer a fondo la situación del negocio bajo estudio pa-
ra poder desarrollar un sistema acorde sus necesidades.
8 Ese relevamiento consistirá en recopilar datos sobre la situación existente a

través de técnicas como son entrevistas, cuestionarios, observación personal y la
inspección de documentación y antecedentes.
Cada una de ellas tiene características diferentes y por lo general se

combinan varias de ellas durante la investigación efectuada.
A continuación se darán las características de cada una de las técni-
cas, con sus ventajas y desventajas.
Entrevista
8 Las entrevistas se utilizan para recabar información en forma verbal, a través de
preguntas que propone el analista. Quienes responden pueden ser gerentes o
empleados, los cuales son usuarios del sistema existente, usuarios potenciales
del sistema propuesto o aquellos que proporcionarán datos o serán afectados
por la aplicación propuesta.
En las investigaciones de sistemas. las formas cualitativas y cuantitativas de la informa-

ción, son importantes. La información cualitativa, está relacionada, con opiniones, polí-
ticas y descripciones narrativas de actividades o problemas, mientras que 1as descripcio-
nes cuantitativas tratan con números, frecuencias, cantidades. A menudo las entrevistas
son la mejor fuente de información cualitativa; los otros métodos tienden a ser útiles en la
recabación de datos cuantitativos.
Resulta esencial la inclusión de datos sobre nuevos productos, cambios en las políticas
en relación con clientes y proyectos de construcción o crecimientos planeados en ventas:
las entrevistas pueden ser la mejor forma para recopilar esa información. Son valiosas las
opiniones, comentarios, ideas o sugerencias en relación a cómo se podría hacer el trabajo.
La entrevista a veces es la mejor forma para conocer las actividades de la empresa.
Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal.
Como resultado de esto, las entrevistas pueden descubrir rápidamente malos entendidos,
falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; más
aún, a menudo es más fácil calendarizar una entrevista con los gerentes de alto nivel, que
pedirles que llenen cuestionarios.
Las entrevistas implican un trato directo entre el analista y el entrevistado y ello implica
una serie de ventajas:
Permite el conocimiento mutuo entre ambos de manera de que exista confianza en
el trato.
El analista puede explicar detenidamente las características del proyecto y la impor-
tancia de las preguntas que hará.
El analista puede aclarar dudas sobre la pregunta formulada cuando lo manifieste el
entrevistado.
El analista podrá observar reacciones, temores o actitudes del entrevistado.
El analista podrá cambiar el orden de las preguntas si hiciera falta, es decir que po-
drá guiar en todo momento la conversación.
Determinación del tipo de entrevista

La estructura de las entrevistas varía. Si el objetivo de la entrevista radica en adquirir
información general, es conveniente elaborar una serie de preguntas sin estructura, con
una sesión de preguntas v respuestas libres. La atmósfera abierta v de fácil flujo de esta
modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas v creen-
cias de quien responde. Sin embargo, cuando los analistas necesitan adquirir datos más
específicos sobre la aplicación o desean asegurar una alta confiabilidad en las respuestas a
Área Informática
las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son
mejores.
Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respues-

tas para las preguntas puede ser abierto o cerrado; las preguntas para respuestas abiertas
permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Pueden
contestar por completo con sus propias palabras. Con las preguntas para respuestas cerra-
das se proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Todas
las personas que responden se basan en un mismo conjunto de posibles respuestas. En
las preguntas abiertas el usuario se puede explayar en cambio en las cerradas la respuesta
esperada es concreta.
Una pregunta de tipo abierta sería: ¿Cómo ha sido la evolución de la empresa en los últi-
mos años?
Una pregunta de tipo cerrada sería: ¿Cuántos empleados tiene el departamento marke-
ting?
Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no se

necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, anali-
zar las respuestas después de las entrevistas lleva más tiempo que con las entrevistas es-
tructuradas. De cualquier manera, el mayor costo radica en la preparación administra-
ción y análisis de las entrevistas estructuradas para preguntas cerradas.
Etapas de la entrevista
Existen 3 momentos principales en las entrevistas:
1. Antes de la entrevista
2. Durante la entrevista
3. Después de la entrevista
1. Antes de la entrevista: Se debe determinar la finalidad de la misma, planteando

objetivos finales y parciales y estableciendo la relación con las entrevistas anteriores.
Se debe trazar un plan para la entrevista, y, si fuera necesario tener una guía con las
preguntas a realizar.
La entrevista debe ser solicitada por anticipado, poniéndonos de acuerdo con los fu-
turos entrevistados a cerca del lugar, día, hora y duración de la entrevista.
2. Durante la entrevista: La entrevista se debe iniciar con una explicación de los

motivos de la misma y la importancia que tiene para el proyecto de sistema.
El analista debe:
Cerciorarse que el entrevistado sea la fuente de los hechos que narra y que no
hable de temas que corresponden a otras personas.
Debe llevar un orden en sus anotaciones, de manera que sea lo suficientemen-
te claro, dejando de lado las ambigüedades.
Debe tener en cuenta en las excepciones, sobretodo en aquellos hechos que el
entrevistado no le da importancia.
Debe separar los hechos de las opiniones.
Debe solicitar copia de los documentos que se mencionen en la conversación.

Ganar la confianza del entrevistado, venciendo las resistencias.
El analista no debe:
Interrumpir la exposición del entrevistado.
Ofrecer soluciones durante la entrevista a los problemas planteados.
Formular una pregunta que sugieran de una respuesta
Dejar que la entrevista se desvíe del tema.
Perder la conducción de la entrevista.
Analizar los hechos durante la entrevista.
Utilizar vocabulario muy técnico.
Plantear más de una pregunta en una sola.
Forzar las respuestas.
3. Después de la entrevista: Se debe analizar la información recabada efectuando

una confrontación de hechos horizontal y vertical.
La confrontación vertical se refiere a comparar datos recibidos de personas que se
ubican en cargos contiguos en la cadena de mandos, teniendo en cuenta las entradas
y salidas de información a que hacen referencia.
En la horizontal se comparan datos de personas que se encuentran en jerarquías si-
milares.
Si existieran puntos no claros o en los que no existieran coincidencias se deberán
efectuar las aclaraciones pertinentes utilizando nuevas entrevistas o algunas de las
otras técnicas como son observaciones o cuestionarios.
¿A quiénes entrevistar?
Se deben entrevistar a todos los niveles de jerarquía del negocio u organización, sobre-
todo a aquellos que guardan directa relación con el proyecto.
Es necesario pedir el organigrama de la organización, que puede no coincidir con la es-

tructura que se da en la realidad. Es por eso que a medida que se avance en el releva-
miento el analista podrá ir confeccionando el organigrama real.
El nivel estratégico de la organización podrá plantearle al analista puntos de vista refe-

ridos al proyecto pues son los que toman decisiones de importancia para el mismo. A su
vez podrán proporcionar información referida a la organización en general (fines, planes,
objetivos, políticas empresariales, estrategias de negocio, problemas existentes, estructu-
ras, niveles subordinados, recursos de la empresa, ambiente en el que se desenvuelve,
etc.).
A su vez podrá proporcionarle al analista la autorización a entrevistar a los niveles infe-
riores e informarles a estos de la necesidad de prestar apoyo al proyecto.
El nivel táctico (gerentes de área, jefes, subjefes, directores, etc..) que tienen a su cargo
un grupo de personas y conducen los procesos de un sector de la organización, propor-
cionarán información respecto al funcionamiento del área a su cargo (recursos humanos
Área Informática
y tecnológicos, procesos que se llevan a cabo, planes, políticas sectoriales, problemas exis-
tentes).
El nivel operativo o técnico efectúan operaciones y brindarán información respecto a

sus tareas (órdenes recibidas, datos ingresados, información entregada, descripción de los
procesos, recursos técnicos utilizados, problemas existentes en su tarea diaria).
Cada nivel brindará información de los hechos de que es partícipe directo.
Cuestionarios
Los cuestionarios proporcionan, una alternativa muy útil para las entrevistas; sin em-
bargo, existen características que pueden ser apropiadas en unas situaciones y en otras
no.
8 Los cuestionarios son grupos de preguntas planteadas en un papel preimpreso y

que los usuarios deberán llenar.
No existe trato personal entre el analista y el que responde.
Para los analistas, los cuestionarios pueden ser la única forma posible de relacionarse
con un gran número de personas para conocer varios aspectos del sistema.
Cuando se hacen los estudios en varios departamentos, se pueden distribuir los cues-
tionarios a todas 1as personas apropiadas para recabar hechos en relación al sistema.
También es posible utilizarlos para recabar datos con personas que están en otros sitios
geográficos que no nos es posible entrevistarlas. Se los puede utilizar para recabar datos
sobre hechos concretos y que no requerirían una entrevista o para aclara dudas que hu-
bieran quedado de las mismas.
Por supuesto, no es posible observar las expresiones o reacciones de quienes responden

a los cuestionarios. (Si esto es importante, las entrevistas pueden ser necesarias.) En la
mayor parte de los casos, el analista no verá a los que responderán y esto implica que no
se podrá observar reacciones, temores, lugar de trabajo entre otras cosas.
Puede que contesten las preguntas sin darle importancia o que las interpreten erró-
neamente dando lugar a respuestas equivocadas. Esto obligaría a realizar cuestionarios
aclaratorios.
Sin embargo el cuestionario tiene la ventaja del ahorro de tiempo por parte del analista.
Existen dos tipos de cuestionarios, abiertos y cerrados.
El cuestionario abierto sirve para recabar sentimientos, opiniones y experiencias, utili-

zando preguntas abiertas como es: ¿Podría mejorarse el proceso de control de mercaderías
ingresantes?
El cuestionario cerrado limita las respuestas del interrogado: Sí/No, De acuerdo/en de-
sacuerdo, selección de opciones, etc..
En todos los casos la preparación del cuestionario lleva tiempo y trabajo, en lo que se
refiere a desarrollar preguntas bien elaboradas y se deben probarse y modificarse cuantas
veces sea necesario antes de imprimirlo definitivamente.
Revisión de registros, documentación y antecedentes

Se trata de un método netamente complementario y consiste en el relevamiento de in-
formación contenida en archivos, registros, balances, manuales, etc..
Esta técnica apunta a obtener “copias” de la documentación existente en la organiza-

ción y que puede ser de vital importancia para el análisis y diseño del nuevo sistema de
información.
Muchos tipos de registros e informes son accesibles si el analista sabe dónde buscar. En
la revisión de registros, los analistas examinan datos y descripciones que ya están escritos
o registrados en relación con el sistema y los departamentos de usuarios. Esta forma de
encontrar datos puede servir como presentación del analista, si se realiza al iniciar el es-
tudio, o como un término de comparación de lo que sucede en el departamento con lo
que los registros presentan como lo que debería suceder.
El término “registros” se refiere a los manuales escritos sobre políticas, regulaciones,

procedimientos de operaciones estándar que la mayoría de las empresas mantienen co-
mo guía para sus empleados. Los manuales que documentan o describen las operaciones
para los procesos de datos existentes, o sistemas de información que entran dentro de1
área de investigación también proporcionan elementos de gran importancia Normal-
mente muestran los requerimientos y restricciones del sistema (como cantidad de tran-
sacciones o capacidad de almacenamiento requerida de datos) y características de diseño
(controles y verificaciones del procesamiento).
También es necesario requerir los documentos y formas que se utilizan a través de los
diferentes procedimientos solicitando formas en blanco y llenadas para poder analizar
los datos que tienen en cuenta y cuáles según la opinión del analista, necesitarían para el
futuro sistema.
Si existe un sistema computarizado funcionando se requerirán los informes o listados

impresos que arroje el mismo, siendo una manera muy útil para obtener requerimientos
de información para el futuro sistema.
A veces existen anotaciones que no constituyen documentos formales y pueden resultar
de suma utilidad, se debe prestar especial atención en los datos escritos en esos papeles
“informales”.
Es tan importante esta parte del relevamiento pues los documentos y registros pueden
tener una gran incidencia en el diagnóstico de la situación actual, el análisis del nuevo
sistema y el diseño, sobretodo en la planificación de la nueva estructura de datos.
Área Informática
Observación Personal
Observar las operaciones le proporciona al analista hechos que no podría obtener de
otra forma.
Leer en relación con una actividad del negocio le proporciona al analista una dimen-
sión de las actividades del sistema. Entrevistar personas, ya sea directamente a través de
cuestionarios, también le ayuda v le dice algo más. Ninguno cae los dos métodos da una
información completa.
La observación proporciona información en relación con la forma en que se llevan a

cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se
realizan las tareas y si ocurren los pasos específicos como se preestablecieron, pueden,
contestarse rápidamente si se observan las operaciones.
Cuándo observar:
La observación es muy útil cuando el analista necesita ver de primera mano cómo se
manejan los documentos, cómo se llevan a cabo los procesos y si ocurren los pasos espe-
cificados. La observación es un arte en sí misma. Saber qué buscar también requiere de
experiencia. Los observadores con experiencia determinan quién utiliza los documentos
y si encuentran dificultades; también están alertas para detectar documentos o registros
que no se utilizan; por ejemplo, si un vendedor no utiliza un libro de precios para com-
pletar un pedido grande, ¿eso significa que está seguro del precio correcto del artículo,
aun cuando existan más de 10 mil artículos diferentes en el libro? Como se sabe, mu-
chas veces la memoria puede fallar.
Los analistas también deben observar otras etapas poco usuales. ¿Se realiza una llama-
da telefónica para cada pedido de ventas que se procesa? ¿Por qué se requiere a veces
información financiera en la oficina?
Siempre se deben identificar las tareas problemáticas, que llevan a los empleados a
cometer errores con frecuencia al completarlas, así como aquellas que retardan el proce-
dimiento.
Se podrán tomar tiempos de los procesos y detectar los cuellos de botella. Los cuellos
de botella son lugares en un sistema de proceso en donde las cargas de trabajo se incre-
mentan debido a que no pueden realizarse tan rápido cuando llegan. No sólo son un
problema de operación, los cuellos de botella también se presentan en Niveles de Alta
Gerencia por ejemplo en donde se requieren firmas para aprobaciones formales. La ob-
servación puede ayudar a detectara causa v revelar si el cuello de botella se rompe de vez
en cuando (¿y, cómo?) o si continua repitiéndose.
La observación es una técnica muy útil a la hora de analizar los recursos utilizados en
los procesos, el ambiente de trabajo, el espacio ambiental, las instalaciones eléctricas, el
mobiliario y cuanto elemento creamos que sea útil para el estudio realizado.
También se puede aplicar está técnica mientras se realizan las entrevistas estudiando
reacciones del entrevistado, actitudes personales o resistencias que pueden afectar el futu-
ro del proyecto.
En todos los casos cualquiera sea el elemento observado requerirá una gran habilidad
por parte del analista para pasar inadvertido en su tarea de observación para no consti-
tuirse en un elemento de presión para los usuarios del negocio. Por ejemplo si el analista
necesita estudiar un proceso determinado mientras se lleva a cabo deberá tratar de hacer-
lo sin interferir en el normal desarrollo de las tareas.
Relevamiento del hardware y software existente

Tanto el hardware como el software constituyen recursos como tantos otros para el ne-
gocio bajo estudio, sin embargo merecen especial atención en su análisis.
Para ambos se aplicará la observación pormenorizada de cada detalle y la solicitud de la

documentación que exista sobre cada uno.
En cuanto al hardware se debe revisar la configuración del equipamiento existente

(discos, memoria, motherboard, microprocesador, velocidad de reloj).
Se tendrá que solicitar la documentación existente de cada equipo (manuales, remitos

de entrega) que faciliten su estudio.
A partir de allí se sacarán las conclusiones respecto al grado de actualización de la tec-

nología existente y si es posible la actualización del equipamiento.
También es importante el observar los periféricos con que cuenta el negocio (impreso-
ras, lectoras de CD, lectoras de códigos, por citar algunos), y las instalaciones de cablea-
dos, tanto de datos como eléctricas.
El relevamiento de hardware es fundamental para determinar una vez que el analista

tenga idea de las características del proyecto de sistemas que se llevará a cabo, si el equi-
pamiento servirá para implementar el nuevo sistema o se requerirá actualizarlo o se de-
berán adquirir equipos nuevos.
En cuanto al relevamiento de software, se analizarán dos aspectos:

Los sistemas operativos y software utilitarios que existan en el negocio: Se deberán
solicitar la documentación pertinente respecto a licencias, números de copias, y re-
querimientos tecnológicos.
Los sistemas de aplicación existentes: Se deberá solicitar información de los sistemas
de información computarizados ya implementados en el negocio, obteniendo la do-
cumentación de dichos sistemas (manuales de operación, de usuarios, estructuras de
datos y demás elementos que existieran). Pero, por sobre todas las cosas se deberá
prestar atención en aquel sistema que será reemplazado por el que el analista des-
arrollará en el actual proyecto. Si en una organización existe un sistema y se solicita
al analista encarar un nuevo proyecto es porque el viejo sistema ya no satisface al
usuario por diferentes causas. Allí hay que detenerse y recabar la mayor cantidad de
datos.
Será necesario observar como el usuario directo opera el sistema obteniendo informa-
ción a cerca de los problemas que tiene o de las necesidades de información no satisfe-
chas por el sistema (debilidades del viejo sistema) y de los puntos que deben ser resca-
Área Informática
tados como positivos o a ser tenidos en cuenta en el proyecto como son interfaces, facili-
dad de operación, etc.. (fortalezas del viejo sistema).
También se deberán estudiar los archivos de datos en cuanto a su estructura y el soft-

ware que se utilizó para el desarrollo del sistema.
3 Actividad:
1. Defina con sus palabras cada una de las técnicas de relevamiento:

Entrevista:
Cuestionarios:
Observación:
Documentación:
2. Prepare un cuadro comparativo con las características sobresalientes de las

distintas clases de técnicas para hallar datos.
DOCUMENTACIÓN Y
Técnica ENTREVISTA CUESTIONARIOS OBSERVACIÓN
ANTECEDENTES
Caracterís-
ticas

YOURDON Eduard, Análisis Estructurado Moderno, Apéndice “E”
SENN, James A., Análisis y diseño de sistemas de Información, Cap. 3
Área Informática
Unidad IV
Inicio del ciclo de vida de un proyecto
El estudio de la situación actual
Conocer la situación actual de la organización objeto del estudio.
Aprender a determinar los requerimientos de información.
Aprender a descubrir los problemas existentes en la organización.
Identificar las oportunidades no aprovechadas.
Relacionar requerimientos, problemas y oportunidades con el Plan General del pro-
yecto.
Área Informática
Introducción
Anteriormente describimos la distintas técnicas para hallar datos a fin de conocer la si-
tuación existente en la empresa bajo estudio.
Conforme se recopilan los elementos, los analistas estudian los requerimientos de datos
para identificar las características que tendrá el nuevo sistema, incluyendo la información
que el sistema debe producir y las características operativas, como son controles de proce-
samiento, tiempos de respuestas y métodos de entrada y salida.
No se puede comprender lo que el usuario pretende del nuevo sistema, sin entender
qué comportamiento tiene el sistema actual.
La planificación del nuevo sistema se efectúa a partir de las necesidades de información

que tiene el usuario y los problemas existentes en el negocio.
A continuación diferenciaremos y relacionaremos estos conceptos.
Estudio de la situación actual del negocio

Una vez que se inicia el proyecto el analista deberá conocer cuáles son las necesidades y
problemas de los usuarios. Pero, lógicamente que para comprender los planteos recibi-
dos, deberá conocer a fondo el negocio en el cuál se implementará el sistema (conoci-
miento del sistema objeto – problema infológico).
Para ello efectuará el relevamiento de información para recabar datos referidos al siste-
ma actual. Se necesitará conocer:
Historia y evolución de la organización.

Actividad desarrollada.
Objetivos planteados.
Políticas organizacionales.
Estrategias organizacionales.
Planes.
Ambiente o contexto donde se desenvuelve (mercado, competidores, etc.)
Recursos tecnológicos, humanos y financieros de la organización.
Restricciones existentes políticas, económicas o tecnológicas.
Estructura organizacional:
Organigrama Formal.
Organigrama Real.
Departamentalización existente.
De cada departamento: Objetivos, políticas, recursos sectoriales, procesos que se
llevan a cabo, información de entrada, información saliente, problemas existen-
tes.
Una vez obtenida la información de las características del negocio, se podrá conocer y
comprender el comportamiento actual del sistema, a través de la identificación de necesi-
dades, problemas y oportunidades.
Determinación de los requerimientos

de información para el futuro sistema
El análisis de sistemas es el conocimiento de situaciones y no la solución de los proble-
mas. Los buenos analistas, por lo tanto, hacen hincapié en la investigación y las pregun-
tas para aprender cómo opera un sistema actualmente y para identificar los requerimien-
tos que los usuarios tienen para uno nuevo o modificado. Sólo después de que los analis-
tas han entendido por completo el sistema, son capaces de analizarlo y preparar las bases
para el diseño de sistemas.
La determinación de los requerimientos es el estudio del sistema actual del negocio a fin
de encontrar cómo trabaja y dónde debe mejorarse. Los estudios de sistemas son el re-
sultado de una evaluación para conocer cómo funcionan los métodos actuales si son ne-
cesarios o posibles algunos ajustes; elaboran preguntas en relación con sus procesos ma-
nuales y computarizados, y como se verá más adelante: así pues, no sólo son estudios de
computadora.
Un requerimiento es una característica que debe incluirse en un nuevo sistema v puede

consistir en una forma de captar o procesar datos, producir información, controlar una
actividad de negocio o de apoyo a la gerencia, por lo tanto la determinación de los reque-
rimientos, significa estudiar el sistema existente, recopilar los datos en relación con éste
para encontrar cuáles son estos requerimientos.
Dado que los analistas de sistemas no trabajan como gerentes o empleados en los depar-
tamentos para usuarios, no tienen los mismos conocimientos sobre hechos y datos que los
Área Informática
gerentes y usuarios de esas áreas; por lo tanto, un paso inicial en la investigación es enten-
der la situación. Existen ciertos tipos de requerimientos tan fundamentales que son comu-
nes a todas las situaciones. También existen clases especiales de requerimientos depen-
diendo de si el sistema está orientado hacia transacciones, toma de decisiones o si el sistema
afecta en forma directa a varios departamentos.
Es importante tener en cuenta que durante esta fase de investigación los requerimientos
para el futuro sistema pueden surgir de diferentes maneras:
Algunos requerimientos serán enumerados por los usuarios, verdaderos conoce-

dores de sus necesidades.
Otros requerimientos serán identificados por los analistas de sistemas a través del
conocimiento de los procesos del negocio.
Y, otros surgen a partir de problemas identificados.
Y, lógicamente estos tres puntos se conocerán a través del relevamiento de información

que realizan los analistas por medio de las diferentes técnicas de recopilación de datos.
Los requerimientos de información a tener en cuenta en el futuro sistema son llamados

VERDADEROS REQUERIMIENTOS para diferenciarlos de los requerimientos tecnológicos o
requerimientos determinados por el analista en forma arbitraria y que no hacen a la
esencia del proyecto a los que llamaremos FALSOS REQUERIMIENTOS.
Cómo se determinan los requerimientos básicos

Los analistas estructuran su investigación buscando respuestas a las siguientes pre-
guntas:
¿Cuál es el proceso básico?

¿Qué datos se utilizan o se producen durante este proceso?
¿Cuáles son los límites impuestos por tiempo y cantidad de trabajo?
¿Qué controles de rendimiento se utilizan?
Entender el proceso
Se empezará con lo básico. Se harán aquellas preguntas que proporcionarán, cuando
se contesten, un antecedente de los datos fundamentales y de las descripciones del siste-
ma. Las siguientes preguntas ayudarán a adquirir él conocimiento necesario:
¿Cuál es el propósito de esta actividad? ¿Cuáles son los pasos que se realizan? ¿Dónde se
realizan?
¿Quién los ejecuta? ¿Cuánto tiempo consumen? ¿Con qué frecuencia se realizan? ¿Quién
utiliza la información resultante? ¿Qué tan grande es la cantidad de transacciones o decisio-
nes? ¿Existe algún problema?
Supóngase que se investiga un sistema de control de inventarios.

A continuación se listan respuestas breves a las preguntas básicas del sistema de control
de inventarios. Éstos son los tipos de respuestas que se deberían buscar para cualquier
sistema que se estudie.
¿Cuál es el objetivo del control de inventario?

¿Cuáles son los pasos que se realizan?
¿Quién desempeña estas tareas'
¿Cuánto tiempo consumen?
Identificación de los datos utilizados y la información producida

A continuación el analista necesita encontrar qué datos se deben utilizar para realizar
cada actividad, por ejemplo, para reordenar un inventario, el comprador puede requerir
de ciertos datos que describan la cantidad del artículo en existencia, demanda esperada
para éste, costo nombre del proveedor.
La mayor parte de las transacciones de negocios producen también información que

sirve a los gerentes cuando evalúan a los empleados, al negocio el rendimiento de los
sistemas puede ser útil en otro contexto para el gerente y analista. Un analista inquisitivo
encontrará, por ejemplo, que los datos en cuanto al control de inventarios también pro-
porcionan información en relación con las demandas del almacén, prácticas de compras,
ventas flujo de efectivo.
Determinación del tiempo de proceso y cantidad

La frecuencia de las actividades del negocio varía enormemente; por ejemplo, algunas
actividades, como el pago de impuestos, se presentan unas cuantas veces al año, mientras
que pagar a los empleados es una actividad quincenal; por lo tanto el analista debe cono-
cer con qué frecuencia se repite la actividad y cuál es la razón que la ocasiona.
Identificación de controles
El analista necesitará comprender durante el análisis los métodos de control aplicados
en el negocio a través de preguntas como las siguientes:
¿Existen normas de rendimiento? ¿Quién compara el rendimiento con esas normas? ¿Cómo
se descubren los errores? ¿A quién se los informa?.
Lo fundamental es descubrir los controles débiles o faltantes.
Cómo se determinan los requerimientos

de transacciones de los usuarios
Las transacciones siguen un procedimiento específico, las rutinas están bien definidas y
son recurrentes.
Una transacción capta, procesa y almacena datos. Por ejemplo en un sistema de entra-
das de pedidos el analista deberá conocer a cerca de la transacción:
¿Quién inicia el pedido? ¿Para qué propósito? ¿Qué información genera? ¿Qué datos se ne-
cesitan? ¿Con qué frecuencia se generan los pedidos?.
Área Informática
Cómo se determinan los requerimientos

de decisión de los usuarios
Las decisiones, a diferencia de las transacciones, son estructuradas por el individuo, ca-
recen de rutinas, son impredecibles y cambian continuamente. Ante esto el analista debe-
rá conocer:
¿Qué información se utiliza para tomar la decisión? Qué datos de las transacciones se necesi-
tan? ¿Cómo debe presentarse la decisión?.
De acuerdo a esto existe una relación directa entre las transacciones y las decisiones de
los usuarios.
Identificación de problemas
y oportunidades
Además de identificar los requerimientos del usuario, será necesario identificar qué hay
de malo en el sistema actual, llegando a obtener una lista de problemas.
Un problema es una situación conflictiva que debe ser resuelta. Para diseñar la solución
adecuada se debe comprender el problema que se está tratando de resolver. Los proble-
mas pueden ir desde la variedad de obstáculos importantes (como “el sistema antiguo
produce resultados falsos que no pueden tomar como datos precisos”), hasta los comunes
(como, “los reportes de impresora son difíciles de leer”).
Existe un problema en cualquier momento en que alguien no esté satisfecho con el

comportamiento o capacidades de un sistema existente y puede expresar lo que piensa
que debiera ser el comportamiento adecuado.
Un problema existe si hay una diferencia entre lo que está sucediendo actualmente y lo
que se desea que suceda.
Los problemas podrán presentarse con los sistemas, organización o procedimientos actuales.
Por otra parte además de los problemas puede haber oportunidades no explotadas dis-
ponibles para el negocio que no han sido utilizadas. Los problemas no son iguales a las
oportunidades.
La oportunidad se presenta cuando se puede aprovechar una nueva tecnología, produc-

tos o servicios que no existían antes o que no habían sido considerados.
También pueden existir oportunidades no tecnológicas.
Conclusión final
Los sistemas de información se desarrollan en función a los requerimientos de informa-
ción y los problemas y oportunidades identificados.
Luego de tener el detalle de requerimientos de información, problemas identificados y

oportunidades a aprovechar, se podrá preparar el plan general del proyecto.

SENN, James A., Análisis y Diseño de sistemas de información, Cap. 2 y 3
KENDALL y KENDALL, Análisis y Diseño de sistemas, Cap. 3.
RUBLE, David, Análisis y diseño Práctico de Sistemas, Cap. 2.
Área Informática
Unidad V
Anteproyecto
Determinar la factibilidad del proyecto de Sistemas en sus aspectos técnico, econó-
mico y operativo.
Definir el anteproyecto de Sistemas, con todos los aspectos involucrados.
Realizar la documentación del proyecto propuesto.
Área Informática
Introducción
Diversas son las metodologías que se pueden aplicar para el análisis y diseño de siste-
mas.
Todas tienen sus pro y sus contras y eso hace que los profesionales de sistemas opten
por unas u otras de acuerdo a sus preferencias o bien trabajen combinando criterios de
diferentes metodologías.
Desde las metodologías clásicas, pasando por las semiestructuradas de Sarson-Gene o

en las actuales metodologías estructuradas o en las orientadas a objetos; lo que se ha
tratado es brindar técnicas adecuadas para la construcción o adquisición de sistemas de
información.
En esta unidad se definirán las características que incluirá el anteproyecto del sistema.
Se definirán objetivos del sistema, límites, alcances, factibilidad, propuestas de solución
para los problemas y requerimientos enumerados en el diagnóstico.
La importancia de esta unidad radica en el hecho de que, cualquiera sea la metodología

utilizada para el análisis y diseño, deberá previamene documentarse el proyecto de siste-
ma.
El proyecto de sistema será analizado y diseñado en las asignaturas posteriores.
Definición del Anteproyecto
Introducción
Un proyecto exitoso comienza con un buen plan. A continuación se analizará cómo es-
tablecer el plan general del proyecto y se presentará una técnica útil llamada el marco de
trabajo para la toma de decisiones del proyecto. Esta técnica dirige a los miembros de la
organización a través de las etapas necesarias para comprender sus necesidades y proble-
mas actuales y reconocer nuevas oportunidades y que permitirán articular los objetivos
del proyecto en términos claros y mensurables.
Propósito del Anteproyecto

El anteproyecto establece las objetivos generales y particulares del proyecto y propor-
ciona un conjunto de medidas que permiten saber cuándo se han logrado los mismos.
¿Quién hace el Anteproyecto?

El proceso de establecer el plan del proyecto es un esfuerzo cooperativo entre el perso-
nal de sistemas y la organización o negocio.
Es responsabilidad del personal de sistemas proporcionar asistencia técnica, analítica y

procedural, y dirigir al negocio a través del proceso de la producción de un plan general.
Es responsabilidad del negocio dedicar personas y tiempo para articular los objetivos y
alcances como así también los criterios de evaluación del negocio, participando mate-
rialmente de las decisiones.
Características del Anteproyecto

El anteproyecto es un plan general del sistema a desarrollar. Es el plan estratégico y ór-
denes de avance del proyecto. El proceso de establecer el plan general determina que tan
factible es continuar con un proyecto y en qué dirección y a qué ritmo se debe realizar el
esfuerzo. Además de indicar los objetivos del proyecto, el plan general detalla el tiempo y
el costo estimado de lograr esos objetivos.
La calidad del plan general es crucial para el éxito del proyecto que le sigue, por lo tan-
to el esfuerzo que se ponga en las estimaciones de tiempo y recursos será muy importan-
te.
También hay que aclarar que las estimaciones que aquí se efectúan son aproximadas,
pues en el futuro los usuarios pueden realizar nuevos planteos de requerimientos que
obliguen a modificar las estimaciones iniciales.
Área Informática
Esto significa que, conforme el proyecto avanza se vuelve a revisar periódicamente las
estimaciones.
Una estimación sólo es precisa al cien por ciento el último día del proyecto.
En estas estimaciones es importante la participación de los miembros de la organiza-

ción pues aumenta su sentido de propiedad del proyecto y su valoración, como así tam-
bién comprender como impactan los cambios de los requerimientos a mitad del proyecto.
Otro aspecto a tener en cuenta es que el plan es una especie de contrato de partes,
porque queda definido que es lo que será responsabilidad del o los analistas de sistemas
como así también se puede definir en qué intervendrán los responsables del negocio.
Detalle del Anteproyecto
La definición del objetivo

Parte de la indagación de la factibilidad global de un proyecto solicitado consiste en
descubrir cuáles son los objetivos de la organización, y luego determinar si tal proyecto es
útil para llevar de alguna manera el negocio hacia tales objetivos.
Todo proyecto de sistema de información tiene un objetivo central o una serie de obje-
tivos a lograr. No es ni más ni menos que la declaración de una meta. La misma necesita
ser clara, no ambigua, concisa y mensurable.
Todos necesitan estar de acuerdo sobre lo que es y saber cuando se ha logrado.
El objetivo general del sistema se determina descubriendo todos los requerimientos y

problemas de la organización, y proporcionando ideas sobre oportunidades no aprove-
chadas, por lo que es indudable que existe una relación directa entre los puntos definidos
en el diagnóstico y el anteproyecto propuesto.
El objetivo es una meta resumida que representa y abarca el conjunto de actividades o

procesos que involucrará el futuro sistema.
8 Los requerimientos, problemas y las oportunidades son la base para los ob-
jetivos
El objetivo debe ser expresado en pocas palabras, debe ser claro y conciso. Es la esencia
del sistema a desarrollar por lo que resume las características del mismo.
Brindar información de algo, mejorar controles, optimizar las funciones del sistema
administrativo, mejorar las comunicaciones del personal, entre otros, pueden ser ejem-
plos válidos de objetivos del sistema a desarrollar.
Existe una serie de objetivos razonables que deben contemplar los proyectos de siste-
mas. Estos son, sin ser limitativos:
La reducción de errores con una mayor precisión en la captura de datos.

La reducción del costo en las salidas del sistema, mediante la simplificación o elimi-
nación de informes duplicados o innecesarios.
La integración de los subsistemas del negocio.
La actualización de los servicios para lograr mayor competitividad.
Aceleración de la captura de datos.
Reducción del tiempo de procesamiento.
Automatización de procedimientos o mejoras en los mismos.
Reducción de cargas de trabajos del personal.
Disminución de tiempos en tareas.
Etc..
También existen objetivos de los proyectos de sistemas que se consideran poco probables,
como el emprender un proyecto sólo para demostrar la proeza del equipo de análisis de
sistemas o para demostrar eficiencia de un departamento. Resulta poco aceptable auto-
matizar procedimientos manuales por el simple hecho de la automatización o invertir
por el deslumbramiento de la nueva tecnología, que parece ser superior a la actual.
Los objetivos del proyecto deben definirse formalmente, por escrito, así como también
de una manera informal, mediante pláticas con el personal de la empresa, averiguando
qué problemas consideran que el proyecto de sistemas llegará a solucionar y qué aspec-
to será mejorado, como así también sus espectativas sobre el sistema propuesto.
El ejemplo siguiente relaciona problema y objetivos:
/ Problema
El personal de ventas proporciona información incompleta al grupo de desarrollo de
productos de los nuevos clientes y los requerimientos de los nuevos productos, y esto
obliga a llamar constantemente a los clientes a fin de pedirles datos aclaratorios.
Objetivo
Evitar el costo de llamar a los clientes para pedir aclaraciones, haciendo que el personal
de ventas proporcione información completa sobre los nuevos productos. Esto a su vez
mejorará el servicio a los clientes
Ahora bien, este objetivo es conciso y claro, pero no es mensurable.
Para poder medir el objetivo se debe incluir en su expresión un factor de medición, es

decir expresamos el objetivo en términos cuantitativos, aunque esto a veces resulta difi-
cultoso.
En el ejemplo incluiríamos en pesos ($) cuánto pretendemos que se reduzca el costo de

las llamadas.
Un ejemplo del objetivo de acuerdo al problema, puede ser:
“La meta del proyecto es proporcionar al departamento de mercadotecnia un sistema

/ de información para la recolección y diseminación de información sobre nuevos produc-
tos.”
Área Informática
Sin embargo si mejoramos la expresión podemos lograr que sea conciso y mensura-
ble...
La meta es reducir de cinco a dos días, el tiempo que lleva al departamento mercado-
/ tecnia validar y completar las especificaciones para un nuevo producto, desde el mo-
mento que se recibe la información completa de la oficina de ventas hasta la entrega
de especificaciones a la planta de producción.
La declaración de los límites del sistema

Los límites de un sistema se encuentran íntimamente vinculados con la cuestión del
ambiente. Podemos definir los límites de un sistema como: “la línea que forma un circu-
lo alrededor de variables seleccionadas, tal que existe un menor intercambio de energía (o
comunicación, y lo que corresponde) a través de esa línea con el interior del círculo que
delimita”. Se puede advertir con facilidad que el límite demarca el sistema respecto de su
ambiente.
Los límites se expresan con dos palabras: “desde...hasta....” . Son cotas iniciales y finales
del sistema, determinan donde comienza y donde termina.
Esas cotas no son puntos físicos sino que constituyen fronteras lógicas. Se relaciona-
rán directamente con los alcances del sistema que formularemos posteriormente.
A menudo se traza él limite de forma arbitraria; se puede ajustar el límite para deter-
minar si ciertas variables son importantes o no si se encuentran en el interior del ambien-
te o fuera de éste. Un sistema encarado desde dos niveles diferentes puede tener límites
distintos. Es decir que diferenes personas pueden tener distintas apreciaciones del siste-
ma y determinar límites diferentes.
Diferentes niveles de resolución para los problemas planteados, requieren diferentes

definiciones del sistema, diferentes objetivos de la investigación, diferentes límites para
separar el sistema de su ambiente. Lo importante en el análisis de sistemas es que distin-
gamos con claridad entre lo que se encuentra en el sistema y lo que se encuentra en el
ambiente.
En este caso el problema práctico consiste en cómo determinar los límites de un sistema
o, como determinar lo que constituye el sistema en estudio. Lamentablemente, no existen
normas con respecto a la mayor o menor inspección, que se debe realizar, ni acerca de los
sistemas que deben constituir el objeto a enfocar. La única conclusión que se extrae es
que no se puede formular ninguna conclusión hasta emprender otras investigaciones
con respecto al problema.
Resultan pertinentes varias observaciones. En primer lugar, al emplear el enfoque de

los sistemas se identifican otros subsistemas que pueden tener metas conflictivas. En se-
gundo término, la propia disciplina del enfoque de los sistemas nos obliga a determinar
identificar sus componentes. En tercer término, a menudo la identificación de un pro-
blema dicta los límites que el investigador acepta de una manera implícita. En cuarto
lugar, las metas de los sistemas se pueden modificar que alternemos sus límites. En últi-
mo término, el contexto actual de los límites de los sistemas pueden estar igualmente
relacionados con quien determina las metas de los sistemas.
Como conclusiones importantes podemos citar las siguientes:
1. Los sistemas tienen objetivos o metas a alcanzar.
2. Disponen de elementos componentes que llevan a cabo actividades para alcanzar

esos objetivos.
3. Los Límites son las fronteras que separan al sistema del ambiente, por lo tanto en-
cierran los componentes o variables del sistema.
4. El sistema puede actuar sobre las variables del mismo pues están dentro de sus lí-
mites. Cuando el sistema no puede hacer nada respecto al comportamiento de un
elemento, significa que está más allá de sus límites y pertenece al ambiente.
5. Los límites están relacionados con los objetivos del sistema y con sus alcances.
Como ejemplo de límites citaremos en el que el sistema bajo estudio es una institución
educativa de nivel medio y se tendrán en cuenta las actividades administrativas y acadé-
micas de sus alumnos como variables de análisis.
El objetivo del proyecto será por ejemplo “Brindar información académica y adminis-
trativa del alumnado de la Institución xx”
La variable a tener en cuenta es indudablemente el alumno, pues todo el sistema se de-

sarrollará en función de la información del mismo.
Una persona cualquiera para ser considerada alumna de la institución se debe matricu-
lar como tal. Y, seguirá siendo alumna hasta que termine sus estudios o bien abandone o
pida un pase a otra institución.
Como tal consideraremos como límites del proyecto:
Desde la matriculación de un nuevo alumno, hasta la entrega del analítico por finali-
zación de estudios o hasta la baja del alumno por abandono o pase a otra institución”.
La definición de los alcances del sistema
Es necesario comprender las funciones de un sistema, conocer sus finalidades y poder

definir sus objetivos, con lo que determinamos el alcance del sistema. En términos gene-
rales esto se podrá considerar como un cambio que el sistema genera entre los insumos
de sistema y los resultados obtenidos del mismo.
Insumos Resultados
Sistema
Área Informática
En los sistemas complejos, por ejemplo en un negocio, el definir el alcance de los obje-
tivos tiende a ser una tarea difícil y continua. Sin embargo, si no se conocen estos, será
complicado apreciar si el sistema está complicado apreciar si el sistema está cumpliendo o
no con su finalidad y por lo tanto será difícil de controlar.
Al tratar de entender los sistemas es importante darse cuenta que estos es invento del
hombre, creados por él, para permitir una mejor percepción de la realidad. Por lo tanto
los límites, las funciones y los niveles son determinados por las necesidades.
Los alcances constituyen las funciones o actividades que involucrará el proyecto y, lógi-
camente estarán relacionados con los requerimientos y problemas obtenidos en el rele-
vamiento.
Cada requerimiento, problema u oportunidad se convertirá en alcances para el nuevo

sistema, y, estos podrán asumir diversas formas, a saber: mejorar un servicio, reducir cos-
tos, incremento en las ganancias, mejorar la seguridad o los controles, etc .
Los alcances del sistema estarán determinados por el o los objetivos del proyecto, por lo
que, indudablemente si el sistema cumple eficientemente con sus funciones estará lo-
grando el obtetivo propuesto.
Los alcances deberán estar incluídos dentro de los límites del sistema, y, es posible que
al estar definiendo los alcances, el equipo de sistemas pueda observar la necesidad de
modificar los límites, ya sea agrandándolos, si es que hay procesos que quedan fuera de
los límites o acotándolos, si es que el proyecto es más pequeño que lo que fue definido.
Siguiendo con el ejemplo anterior de la institución educativa de nivel medio, podremos

citar como ejemplos de alcances: matriculaciones de nuevos alumnos, controles de asis-
tencia, registro de pago de cuotas, control de calificaciones del alumnado, etc.. Sin em-
bargo no constituyen alcances lo referido a liquidaciones de sueldos y jornales de los do-
centes, pues no fue contemplado ni en los objetivos ni en los límites del proyecto.
El estudio de Factibilidad de un proyecto

El estudio o prueba de factibilidad de un proyecto de sistemas se efectúa para determi-
nar si es un proyecto es...
Viable técnicamente.
Económicamente provechoso.
Exitoso en su operatividad.
El estudio de factibilidad es de vital importancia y sus resultados no son definitivos

pues el estudio que se realiza inicialmente y que algunos llaman estudio de prefactibili-
dad, puede repetirse las veces que sea necesario.
Inicialmente, cuando el proyecto está recién planteado, el margen de errores es de un

50%, pues se tienen sólo aproximaciones de los que será el proyecto final a implementar.
Sin embargo, conforme van surgiendo nuevos planteos de requerimientos o problemas

por parte de los usuarios o descubiertas por el analista, se podrá realizar un nuevo estudio
que variará del efectuado anteriormente.
Sólo podremos decir que el estudio ya es definitivo cuando estemos a punto de imple-
mentar el proyecto y estamos seguros que no sufrirá modificaciones.
El estudio de factibilidad se realiza en tres aspectos:
1. Factibilidad Técnica.
2. Factibilidad Económica.
3. Factibilidad Operativa.
Factibilidad Técnica
Implica analizar si el proyecto planteado será viable desde el punto de vista de los re-
cursos técnicos.
Lo primero que se deberá hacer es un estudio de los recursos tecnológicos existentes,

determinando la configuración del equipamiento y las instalaciones de cableados exis-
tentes.
A partir de allí, una vez que se tiene la idea del proyecto se analizarán los recursos tec-
nológicos exigidos por el mismo, para ello se deberá evaluar:
Volumen de datos previsto (inicial y perspectivas de crecimiento futuro)

Tiempos de respuesta exigidos para los procesamientos.
Tipos de operaciones.
Demandas de equipos para programación.
Perspectivas de crecimiento del sistema
Con estos y otros factores a tener en cuenta se determinará la configuración de equipos

necesaria para implementar el nuevo sistema.
Hay factores complementarios pero igualmente importantes como son analizar si los
equipos se utilizarán para la programación del sistema o la incidencia que pueden tener
las eventuales fallas de equipos. Estos aspectos pueden influir a la hora de analizar la
configuración requerida.
Posteriormente se analizará el equipamiento existente efectuándose los siguientes plan-

teos sobre:
El equipamiento existente será capaz de soportar el nuevo sistema?
Si el equipamiento no podrá soportar el sistema, se deberá descartar.
Si la respuesta es negativa se continuará con el análisis posterior realizando los siguien-

tes planteos:
Área Informática
Se deberá actualizar el equipamiento? Si la respuesta es positiva se detallarán que ele-

mentos deben ser actualizados y hasta qué punto. Por ejemplo cambiar un disco o in-
crementar memoria. Lógicamente estará relacionado con el análisis de la conveniencia
económica de efectuar tales actualizaciones.
Si el equipamiento no se debe actualizar significa que podrá ser utilizado tal cual está
para el nuevo sistema.
Para terminar, en la factibilidad técnica no sólo se analiza lo referido al hardware sino

también a los demás recursos tecnológicos necesarios: instalaciones, dispositivos periféri-
cos, etc..
Factibilidad Económica
Los proyectos viables técnicamente deberán ser convenientes desde el punto de vista
económicos.
Los beneficios deberán justificar la inversión. Para ello se deberá comparar los costos
de la información con los beneficios obtenidos.
Y, para que la inversión se justifique, los beneficios financieros deberán igualar o exce-
der a los costos financieros.
Para realizar el análisis se deberán efectuar estimaciones de costo y valor de la información.
El costo involucra la inversión que deberá hacer el negocio para contar con el sistema de
información. Diversos factores pueden estar involucrados en dicha inversión, ellos son:
Costos de equipamiento (adquisición de equipos o actualizaciones).

Costo de desarrollo del sistema (análisis, diseño e implementación del mismo).
Costo de espacio ambiental (instalaciones eléctricas, cableados de redes, sistemas de
seguridad, etc.)
Costo de conversión (preparación de bases de datos, cargas iniciales)
Costos operativos (insumos, sueldos, mantenimientos de hardware y software).
Para el análisis de los costos se trabajan con diversas técnicas como son Puntos de
Equilibrio, análisis comparativo de costos de las diferentes alternativas, matrices de ho-
mogeneización, etc.., que serán estudiadas en cursos posteriores.
El valor de la inversión está relacionado con los beneficios que le reportarán al usuario
el contar con la información. Esos beneficios necesitan expresarse en términos financie-
ros, pero esto resulta muchas veces dificultoso.
El valor de la información estará expresado a través de una serie de características que

directa o indirectamente pueden ser trasladadas a valores monetarios. Esas son las si-
guientes: accesibilidad, comprensibilidad, precisión, claridad, confiabilidad, oportunidad,
flexibilidad, confiabilidad, imparcialidad. Lógicamente son propiedades de la informa-
ción, y, la estimación del valor monetario que tiene para el usuario depende del destina-
tario de la misma.
Para determinar el valor financiero de la información, el usuario le asigna un valor

monetario a la información recibida. Es la estimación aproximada del beneficio econó-
mico. Pero, como esto es difícil de calcular, los beneficios se estiman en función de la
reducción de costos lograda con el nuevo sistema o la reducción de errores costosos. Y, a
estos, sí se les puede estimar su valor financiero.
Por citar un ejemplo, supongamos que una empresa tiene un depósito con mercaderías,
y cada finalización de mes las autoridades se encuentran con que faltan mercaderías por
un valor de “xx” pesos por falta de control de las mercaderías entrantes y salientes. Con la
incorporación de un sistema de información de control de depósito se logrará reducir casi
en su totalidad el faltante de mercaderías por ese valor.
Esa es la reducción de costos lograda con el sistema.
Para cerrar, el sistema será factible económicamente si la inversión en el sistema se jus-

tifica de acuerdo a los beneficios obtenidos.
Factibilidad Operativa
Los proyectos propuestos son benéficos sólo si pueden convertirse en sistemas de in-
formación que cumplan los requerimientos operativos del negocio. Dicho sencillamente,
esta prueba de factibilidad cuestiona si el sistema trabajará cuando se instale y desarrolle.
¿Existen grandes obstáculos para ponerlo en marcha? A continuación se presentan al-
gunas preguntas que ayudarán a probar la factibilidad operativa de un proyecto:
¿Existe suficiente apoyo para el proyecto por parte de la gerencia? ¿También de los
usuarios? Si el sistema actual gusta y se usa, al grado de que las personas no ven ningu-
na razón para cambiarlo, ¿puede haber resistencia? ¿Son aceptables los métodos actuales
del negocio para los usuarios? Si no lo son, los usuarios pueden aceptar un cambio que
traiga un sistema más operativo y útil.
¿Se han involucrado los usuarios en la planeación y desarrollo del proyecto? Una par-
ticipación al iniciar el proyecto reduce las posibilidades de resistencia al sistema y al cam-
bio e incremento la probabilidad de proyectos exitosos. ¿Causará daño el sistema pro-
puesto?
¿Producirá resultados más pobres en algún aspecto o área? ¿Dará como resultado una
pérdida de control en alguna área? ¿Se perderá el acceso a la información? ¿Será más
pobre que antes el desempeño individual después de la puesta en marcha?
¿Se afectará a los clientes en forma indeseable? ¿Disminuirá la rapidez del trabajo en
algunas áreas?
Los aspectos que son relativamente pequeños y parecen cuestiones de menor importan-
cia al principio, encuentran siempre maneras de crecer y convertirse en problemas mayo-
res después de la puesta en marcha; por lo tanto, todos los aspectos operativos deben con-
siderarse con cuidado.
Área Informática
Un segundo aspecto a tener en cuenta es el referido a la elección del momento adecua-

do para la implementación del sistema. Un sistema muy bien desarrollado puede fallar
en su operatividad por elegir un momento inoportuno para su implementación.
Imaginemos la situación en la que se desea instalar un sistema de gestión académica en

un colegio secundario y se elige como momento de implementación el mes de diciembre
cuando el personal de Secretaría o Celaduría está abocado a la toma de exámenes o pre-
inscripciones para el ciclo lectivo siguiente. Evidentemente no le prestarían la debida
atención a los responsables del proyecto y se cometerían errores al operar el sistema. O tal
vez que se eligiera como momento para la implementación el mes de enero cuando el
personal administrativo está vacacionando. Situaciones como estas deben ser previstas
por el analista antes de decidir cuál es el mejor momento para implementar el sistema.
Otro aspecto relevante es el referido a la capacitación de los usuarios del sistema. Cada
persona debe ser analizada individualmente en todos sus aspectos a fin de determinar sus
experiencias, preparación, aptitudes, capacidad y demás cualidades, a fin de determinar si
puede cubrir o no un puesto de trabajo relacionado con el nuevo sistema.
Se deberá analizar cuándo realizar la capacitación y sobre qué temas concretamente, si

no son referidos al propio sistema.
Cada usuario directo deberá comprender cómo operar el sistema accediendo a los ma-
nuales de operación y de procedimientos.
Y, por último se deberán prever situaciones que pueden obstaculizar la utilización del
sistema en el futuro, como por ejemplo analizar los proveedores de determinados insu-
mos que pueden ser difíciles de adquirir en plaza.
Muchas veces se ha dado que sistemas factibles técnica y económicamente, tengan proble-
mas una vez implementados por cuestiones operativas que no se analizaron oportunamente.
Opciones de solución
Si bien, con el planteo de los objetivos, los límites y los alcances, se está indicando los
aspectos sobresalientes del proyecto, es importante presentar las alternativas de solución
que prevee el equipo de analistas de sistemas.
Las opciones de solución consisten en presentar una descripción general del funciona-
miento del sistema y que permitirá cubrir los requerimientos y solucionar los problemas.
Es posible que se puedan presentar más de una alternativa de solución, y en cada una
de ellas el analista deberá evaluar ventajas y desventajas, acompañándolas de una estima-
ción de costos y de los respectivos análisis de factibilidad técnica y operativa.
La adecuada explicación de las opciones de solución le permitirán al analista de sistemas

presentar las bondades del proyecto para que sea aceptado por los responsables del negocio.
La Planificación y control de actividades

El analista de sistemas debe administrar con cuidado el proyecto si desea que éste sea
de gran éxito.
La planeación incluye a todas las actividades que se requieren para la selección del
equipo de análisis de sistemas, la asignación de tareas a los miembros del equipo, la esti-
mación de tiempos que cada tarea requiere, la determinación de recursos y la programa-
ción del proyecto.
El control denota el uso de la retroalimentación para darle seguimiento al proyecto. Es-

to incluye comparar el plan del proyecto con lo realizado del mismo y poder efectuar las
correcciones que permitan acelerar o reprogramar actividades y, así poder culminarlo a
tiempo.
En cuanto a las estimaciones de tiempo del proyecto, los planeadores han intentado re-
ducir la incertidumbre asociada a la estimación de las duraciones, proyectando estima-
ciones pesimistas, optimistas y más probables, y, luego, mediante promedios calculan la
estimación aproximada de la duración del proyecto. Esto ofrece cierta seguridad, sin em-
bargo conviene también mantener un enfoque estructurado que permita identificar cada
una de las actividades limitando las sorpresas que puedan ocurrir en el futuro.
Tal cuál se ha visto en asignaturas anteriores, el uso del diagrama de GANTT es una
muy buena alternativa para la programación de proyectos, como así también la gráfica de
PERT o el método del camino crítico.
El Anteproyecto escrito
como un contrato
Uno de los errores que comúnmente se da, es el hecho de no dejar debidamente docu-
mentado lo acordado entre el analista de sistemas y los responsables del negocio. La re-
dacción del anteproyecto como un plan general es una muy buena oportunidad para lo-
grar un contrato de partes.
La idea es dejar por escrito las responsabilidades del analista y de los usuarios del nego-
cio. Si bien se plantea un formato determinado, el mismo podrá cambiárselo según las
necesidades que pudieran surgir en cada proyecto.
En el contrato se podrán incluir los siguientes temas:
Los objetivos y la denominación del sistema a desarrollar.

Los límites y alcances del proyecto.
El curso de acción recomendado con la debida justificación
La metodología a emplear, divisiones del trabajo, personal, tiempos de duración y
presupuestos. En este punto participará activamente el analista a fin de mostrarle al
usuario las tareas previstas en el proyecto, las personas responsables de las mismas,
los recursos necesarios, los tiempos de duración previstos para cada una y lógica-
mente el presupuesto del trabajo.
Área Informática
Factores críticos para el éxito, explicando que aspectos resultarán imprescindibles

para el proyecto encarado.
Firmas que comprometan a las partes.
Conclusión final
El plan General es el por qué, el análisis es el qué y el diseño es el cómo. El plan general
plantea la justificación y objetivos del proyecto, los participantes del mismo, con las res-
ponsabilidades que le caben a cada uno. El plan General del proyecto es el inicio del pro-
ceso analítico.

SENN, James A., Análisis y Diseño de sistemas de información, Cap. 2.
KENDALL y KENDALL, Análisis y Diseño de sistemas, Cap. 3.
RUBLE, David, Análisis y diseño Práctico de Sistemas, Cap. 1 y 2.
Trabajo Práctico Obligatorio

Tipo de Actividad: GRUPAL
Cantidad de integrantes del Grupo: No más de 4 personas.
Objetivos del trabajo:

Aplicar las diferentes técnicas de relevamiento de datos.
Experimentar sobre un trabajo de análisis de sistemas real.
Aprender a documentar una carpeta de Estudio Inicial y de Plan General del
Proyecto.
Tiempo de desarrollo: A partir del primer parcial se comenzará el trabajo paulatina-

mente realizando entregas parciales de la carpeta en cada encuentro para la revisión por
parte del docente. La fecha de entrega final será en el encuentro previo al segundo parcial
de la asignatura.
Características del trabajo: el grupo deberá elegir una organización real de cual-
quier tipo, preferiblemente de la ciudad de Córdoba o alrededores a fin de efectuar un
relevamiento de información que permita obtener un diagnóstico de la situación existen-
te y preparar el Plan General Del Proyecto del sistema a desarrollar.
Contenidos de la carpeta a presentar: La carpeta tendrá dos partes, una con el estudio
de la situación del negocio con toda la información necesaria para el proyecto (objetivos, acti-
vidades, antecedentes, recursos, ambiente, planes, estructura, problemas requerimientos,
oportunidades, etc..), y, otra con el enunciado del Plan General del proyecto.
Referencias útiles: Para ver facilitada la preparación de la carpeta a presentar se po-

drán observar trabajos de Tesis de analistas recibidos en Biblioteca de la Institución,
además será útil las actividades prácticas de las unidades 2, 3, 4 y 5 del presente módulo.

para la Asignatura
SENN, James A., Análisis y Diseño de sistemas de información
KENDALL y KENDALL, Análisis y Diseño de sistemas
RUBLE, David, Análisis y diseño Práctico de Sistemas
YOURDON, Eduard, Análisis Estructurado Moderno
RUMBAUGH-BLAHA-PREMERLANI-EDDY-LORENSEN, Modelado y Diseño
Orientado a Objetos
PRESSMAN, R., Ingeniería del Software
Área Informática
Modelo de evaluación para la asignatura
Parte teórica
1. ¿Qué tipos de requerimientos de información se pueden encontrar en una organiza-
ción?
2. ¿Qué se analiza en el estudio de factibilidad operativa?
3. ¿Qué relación existe entre la definición del Plan general del Proyecto y los requeri-
mientos o problemas planteados por el usuario?
4. Cite ejemplos de situaciones prácticas en las que Ud. como Analista de Sistemas,
aplicaría la observación personal durante un relevamiento.
5. Desarrolle las funciones del sistema de información.
Parte práctica
Lea detenidamente el siguiente caso práctico y desarrolle los puntos que se solicitan a
continuación del enunciado.
“La empresa Computer S.A. vende insumos de computación y presta servicios de man-
tenimiento técnico a los clientes que lo requieran.
Para ello dispone de un local de atención al público y un depósito con la mercadería lis-
ta para la venta.
La firma cuenta con un pequeño software para facturación de productos y arqueos de

caja. En el depósito no existe un responsable de los ingresos y salidas de productos.
Su Gerente de Ventas observa que en más de una oportunidad los vendedores creen
contar con un determinado producto y se dirigen a buscarlo al depósito y notan que no
hay existencias. Lógicamente esto origina una venta perdida y la consecuente mala aten-
ción al público.
El sistema carece de control de inventarios y para facturar sólo se registra el código del
producto para la búsqueda del precio de lista a los efectos de la cobranza.
A raíz de ello decide contratar un analista de sistemas para desarrollar un sistema de

acuerdo a las necesidades del negocio.”
1. Definir el Objetivo de la empresa.

2. Determinar los Problemas del Sistema actual y los requerimientos de información a
cubrir en el nuevo sistema.
3. Qué solución técnica plantearía para el problema de la falta de control en el depósi-
to?
Área Informática
Indice
Fundamentos ......................................................................... 1
Objetivos Generales ............................................................... 1
Contenidos ............................................................................ 2
Evaluación de diagnóstico ....................................................... 4
U NIDAD I
Sistemas de Información ...................................................... 11
Objetivos Específicos........................................................................................... 11
Mapa Conceptual de la Unidad ........................................................................... 12
Introducción ........................................................................................................ 13
Datos e Información ............................................................................................ 13
Función de la Información ...................................................................................................14
Características de la Información.........................................................................................15
Clasificación de la Información............................................................................................17
Operaciones con los Datos ................................................................................. 18
Método de Procesamiento de Datos .................................................................. 20
La elección del método de procesamiento...........................................................................20
Sistemas de Información...................................................................................... 22
Problemas del diseño de los sistemas de información ........................................................23
Funciones de un sistema de información............................................................................24
Necesidad de un Sistema de Información...........................................................................24
Información para la toma de decisiones .............................................................. 25
La toma de decisiones ...........................................................................................................25
Elementos para la toma de decisiones .................................................................................25
Clases de decisiones...............................................................................................................26
El proceso de la toma de decisiones. ....................................................................................27
Niveles de toma de decisión .................................................................................................27
Necesidades de Información para los diferentes niveles de decisión.................................28
La Información como un recurso de las Organizaciones .................................... 29
Material Soporte de Información ........................................................................ 30
Unidad II
El ciclo de vida de desarrollo de los Sistemas de Información 31
Mapa Conceptual de la Unidad ........................................................................... 32
Introducción ........................................................................................................ 33
¿Qué es el Análisis y Diseño de Sistemas? ........................................................... 33
Responsabilidades del Analista se Sistemas ......................................................... 35
Responsabilidad de la programación de computadoras ...................................... 36
Papeles del Analista de Sistemas.......................................................................... 36
Lo que NO es el Analista de Sistemas.................................................................................37
¿Cómo han cambiado las responsabilidades del analista de sistemas? ................ 38
¿Quiénes son los usuarios de los sistemas de información? ................................ 38
¿Quiénes participan de los proyectos de sistemas?............................................. 39
Cómo comienzan los proyectos de sistemas ...................................................... 40
Origen de las solicitudes de un proyecto ............................................................ 43

Gerentes de departamento ................................................................................................... 43
Ejecutivos de alto nivel ......................................................................................................... 44
Analistas de sistemas............................................................................................................. 44
Grupos externos .................................................................................................................... 44
Administración de la previsión y Selección de proyectos.................................... 44
Tipos de Sistemas de Información....................................................................... 45
El ciclo de desarrollo de los sistemas .................................................................. 45
Diferentes tipos de ciclo de vida de proyectos ................................................... 47
Material Soporte de Información......................................................................... 50
Unidad III
El Relevamiento de Datos e Información ............................... 51
Mapa Conceptual de la Unidad............................................................................ 52
Introducción......................................................................................................... 53
Técnicas para hallar datos.................................................................................... 53
Entrevista............................................................................................................................... 54
Cuestionarios......................................................................................................................... 57
Revisión de registros, documentación y antecedentes........................................................ 58
Observación Personal ........................................................................................................... 59
Relevamiento del hardware y software existente ................................................................ 60
Unidad IV
Inicio del ciclo de vida de un proyecto El estudio de la situación actual .. 63
Introducción......................................................................................................... 65
Estudio de la situación actual del negocio............................................................ 65
Determinación de los requerimientos de información para el futuro sistema.... 66
Cómo se determinan los requerimientos básicos ............................................................... 67
Cómo se determinan los requerimientos de transacciones de los usuarios...................... 68
Cómo se determinan los requerimientos de decisión de los usuarios............................... 69
Identificación de problemas y oportunidades...................................................... 69
Conclusión final.................................................................................................... 69
Unidad V
Anteproyecto ....................................................................... 71
Introducción......................................................................................................... 73
Definición del Anteproyecto ................................................. 74
Introducción......................................................................................................... 74
Propósito del Anteproyecto ................................................................................ 74
¿Quién hace el Anteproyecto? ............................................................................. 74
Características del Anteproyecto ........................................................................ 74
Detalle del Anteproyecto .................................................................................... 75
La definición del objetivo ..................................................................................................... 75
Área Informática
La declaración de los límites del sistema.............................................................................77

La definición de los alcances del sistema.............................................................................78
El estudio de Factibilidad de un proyecto ...........................................................................79
Opciones de solución ............................................................................................................83
La Planificación y control de actividades ............................................................................84
El Anteproyecto escrito como un contrato ........................................................ 84
Conclusión final ................................................................................................... 85
Material Soporte de Información ........................................................................ 85
Trabajo Práctico Obligatorio ................................................ 86
Material Soporte de Información para la Asignatura ............. 86
Modelo de evaluación para la asignatura ............................... 87
Parte teórica ........................................................................................................ 87
Parte práctica....................................................................................................... 87
Material elaborado por Ing. Fernando Loza

2000 – AML
18/07/2009 09:53:00
Área Informática
INSTITUCIÓN CERVANTES Sistemas II - Actividades
Actividad Práctica I
Analice el texto siguiente e complete el cuadro identificando cuáles son los procesos,
operaciones con los datos y métodos de procesamiento de datos aplicados: t53
“En la institución educativa Bandera Nacional, el proceso de control de inasistencias se

realiza de la siguiente manera: Un sistema de cómputos emite al comienzo de cada mes
una planilla de control de inasistencias, a partir de la matriculación realizada antes de
empezar el ciclo lectivo. El celador le entrega la planilla al docente antes de ingresar a dar
su clase para que realice el control al comienzo de cada hora de cátedra.
Si un alumno está presente se le coloca una «P» en el casillero, de lo contrario se coloca

un punto. La planilla es entregada al final de la clase al celador para que cargue las
inasistencias en el sistema computarizado. El sistema controla los alumnos que quedan
libres por inasistencias.
Nombre – Descripción del Operaciones involucradas Método de procesamiento

Proceso con los datos utilizado
Emisión de planillas de Recuperación, Computarizado
control de inasistencias Ordenamiento,
Reproducción.
Siguiendo el caso anterior, conteste las siguientes preguntas:
Si en el futuro las autoridades de la Institución quisieran incorporar terminales en cada

aula con lectoras magnéticas de tarjetas a fin de que cada alumno pase su tarjeta al
comienzo y al final de la clase para el control de inasistencia diaria…
1.1. ¿En qué cambiaría el cuadro anterior?
1.2. ¿Qué influencia tendrá el grado de flexibilidad del sistema original en el cambio
de método de procesamiento? Justifíquelo según el ejemplo.
Actividad Práctica II
Analice el siguiente enunciado y conteste las preguntas formuladas:
“La empresa Computer S.A. vende insumos de computación y presta servicios de

mantenimiento técnico a los clientes que lo requieran.
Para ello dispone de un local de atención al público y un depósito con la mercadería

lista para la venta.
La firma cuenta con un pequeño software para facturación de productos y arqueos de

caja. En el depósito no existe un responsable de los ingresos y salidas de productos.
Su Gerente de Ventas observa que en más de una oportunidad los vendedores creen
contar con un determinado producto y se dirigen a buscarlo al depósito y notan que no
hay existencias. Lógicamente esto origina una venta perdida y la consecuente mala
atención al público.
El sistema carece de control de inventarios y para facturar sólo se registra el código del
producto para la búsqueda del precio de lista a los efectos de la cobranza.
A raíz de ello decide contratar un analista de sistemas para desarrollar un sistema de

acuerdo a las necesidades del negocio."
2.1. ¿Quién es el solicitante del proyecto y qué razones originaron el mismo? t283
t293 t303
2.2. ¿Quiénes participarán del proyecto de sistemas? t273 t283
2.3. Si Ud. fuera el analista:

¿Decidiría unilateralmente la incorporación de un encargado de depósito,
imponiendo cambios a la estructura organizacional?
(Ver Teórico Unidad Nro. 2 Papeles, responsabilidades, etc. del Analista de Sistemas)
Área Informática
Actividad Práctica III

Lea atentamente el siguiente caso práctico:
“El Sr. Carlos Escobar, Administrador General de la Playa de Estacionamiento Centro,

situada en la ciudad de Córdoba, está molesto por el gran embotellamiento de vehículos
que se da en determinadas horas del día.
No sabe el motivo por el cual se juntan tantos vehículos en las horas de mayor carga de
trabajo, tanto en entrada como en salida, pues de acuerdo a sus averiguaciones, los
responsables administrativos le atribuyen responsabilidad a los operadores de las
computadoras, y los operadores, a la lentitud del sistema, a los problemas que tiene pues
la playa fue cambiando en diversos aspectos y el sistema no fue actualizado o a la forma
de carga de datos que tiene el mismo.
Todo esto origina una inadecuada atención del público, que en muchos casos se dirigen
a otras playas de estacionamiento.
El Administrador General de la Playa necesita determinar si se aconseja el cambio del

Sistema por una más acorde a sus realidades y decide contratar a la consultora de sistemas
Desarrollos Informáticos para que efectúe el estudio correspondiente y analizar los pasos
a seguir.
El Sr. Escobar se contacta en forma telefónica con uno de los responsables de la consultora,
el Ingeniero en Sistemas Hugo Figueroa, y le explica brevemente el problema comentado
anteriormente. Al finalizar deciden tener una primera conversación más a fondo.
El Sr. Figueroa lo llama a Ud. como Analista integrante de la firma para que comience el
estudio correspondiente de las características generales de la Playa, entrevistando al Sr. Escobar.
El Ing. Figueroa agrega que como Ud. es nuevo en la consultora y es su primera

experiencia en análisis de situaciones lo irá evaluando continuamente a través de
situaciones prácticas y cómo resolverlas.
Para empezar, Figueroa le pide que averigüe qué deberá hacer antes de ir a
entrevistarlo y le muestre el plan de la entrevista con las preguntas a formular al
Administrador General y el motivo de la misma que planteará inicialmente.” t353
t363 t373 t383
El Sr. Escobar le explica en la primera entrevista en forma muy breve las características
del sistema que tiene funcionando y la forma de trabajo de la playa...
“La playa dispone de un sistema de información automatizado que tiene cuatro

terminales, dos en la entrada (en una casilla de ingreso) y otras dos en la salida (en la
casilla de salida). Todas están en red con un Servidor que se encuentra en oficina de
Administración, junto a otra terminal para cobranzas de abonos. En total trabajan 5

(cinco) terminales conectadas al equipo servidor de red.
En la entrada, en una terminal se emite un ticket con la patente del vehículo y la fecha
y hora de ingreso. En la otra existe un software que controla el ingreso de abonados
mensuales y quincenales. Los abonados disponen de una tarjeta magnética que es
pasada en una lectora conectada a la computadora donde está el software de control.
Si el abonado está al día en los pagos el sistema abre la barrera, de lo contrario deberá
estacionar y dirigirse a la Administración.
El abonado podrá pagar hasta el día 10 de cada mes, a partir de allí su tarjeta queda
inactiva y al ingresar el vehículo se le entregará un ticket para dirigirse a Administración.
La barrera no podrá ser levantada por el operador manualmente, sólo se lo hace a través
del sistema cuando se emite el ticket o un abonado pasa su tarjeta y está al día.
En la salida, una terminal tiene un software para cobranza de los tickets por hora.
El operador recibe el ticket del automovilista y tipea el número de patente del vehículo
retirado, el sistema le calculará el tiempo de permanencia en playa y el monto a cobrar.
La tolerancia es de 10 minutos o fracción inferior, pero si un vehículo entra a la playa y

está menos de 10 minutos lo mismo se le cobra la hora.
En la otra está el sistema de control de salida para abonados. El abonado para retirar su
vehículo deberá pasar su tarjeta en la lectora correspondiente. También para retirarlo
deberá estar al día en los pagos. Si el vehículo de un abonado entró el día 8 y estuvo
estacionado hasta el día 11 y su titular no pagó, el sistema no levantará la barrera.”
El Sr. Escobar agrega: “Estaba olvidando algo, hace un tiempo se incorporó lectoras de
tarjetas en las puertas de acceso lateral, son dos en total y se conectó las mismas a la
terminal de entrada de abonados. El abonado pasará su tarjeta en la lectora y si está al día
en los pagos se le abrirá la puerta de acceso para evitarle tener que trasladarse a la entrada
principal. Esto se lo hizo por razones de seguridad, para evitar la presencia de intrusos a
la playa que implicaran riesgos de robo; y para darle un mejor servicio a los abonados
mensuales. Tratamos siempre de darle una buena imagen a los abonados para que nos
hagan buena propaganda y atraigan a nuevos clientes.”
La entrevista se ha extendido por más de uno hora y media y el responsable de la playa

está agotado y Ud. analiza qué es lo que más conviene para continuar con el estudio…
t353 t363 t373
Al llegar de regreso a la consultora, el Ing. Figueroa le solicita que presente la
documentación del estudio realizado hasta el momento. t373 t383
Al leer el informe el Sr. Figueroa le manifiesta: “Está faltando información de la

estructura de la playa formal o informal…”
Área Informática
Ud. le explica que volverá al día siguiente a continuar con la entrevista.
Al regresar a la mañana siguiente Ud. solicita al Sr. Escobar que le explique la

estructura funcional existente, y ante esta requisitoria el Administrador le plantea que la
empresa se maneja con un esquema de organización verticalista con un agrupamiento
del personal de operaciones en 3 (tres) turnos de trabajo. El personal suele rotarse en los
puestos de trabajo, algunas veces están en la terminal de cobranza para los usuarios por
hora y en otras están en ingreso.
A continuación el Sr. Escobar manifiesta que no cuenta en un organigrama documentado

pero que puede explicar las funciones de cada integrante:
“Como Administrador General concentro las decisiones de la organización: cambios de

precios, determinación políticas, incorporación o despidos de personal, convenios con
empresas que desean tomar un servicio de estacionamiento diferenciado.
De mi dependen las dos personas que están en Secretaría administrativa, el Encargado

de Personal y el encargado de mantenimiento.
La Secretaría administrativa la conforman dos personas, una está por la mañana hasta
las 15 horas y la otra a partir de las 15 hasta las 23 horas. Se encargan de la cobranza de
abonos y la atención a proveedores de servicios y los pagos a los mismos.
El encargado de personal sólo se limita a organizar las actividades diarias del personal de
operaciones determinando que puesto ocupará cada uno y cuándo le corresponden los francos.
El personal de operaciones se organiza con 2 (dos) personas por cada turno. Uno está
en la entrada y el otro en salida. En total hay 8 operadores que ser van rotando en las
tareas y francos según les corresponda.
El turno mañana comienza a las 7 horas y termina a las 15 horas, el de la tarde es de 15

a 23 horas y el de la noche de 23 a 7 horas del día siguiente.
El encargado de mantenimiento supervisa las tareas de un electricista que está de 8 a 18

horas y dos personas que se encargan de la limpieza de la playa."
Para terminar manifiesta “esto no es totalmente rígido y que algunas responsabilidades

pueden variar” .
Al terminar la el administrador da su visto bueno para avanzar con el estudio que se ha

comenzado y agrega finalmente: “Ya que estamos encarando estos cambios, podemos
incluir en el proyecto la posibilidad de automatizar las actividades de Secretaría
Administrativa en lo concerniente al control de ingresos y egresos de dinero; y las
actividades de planificación de tareas y francos de los operadores realizada por el
Encargado de Personal. Se lo dejo en sus manos y más adelante me da algunas ideas...”
Antes de concluir con la entrevista Ud. expresa una posible solución para agilizar la salida
de vehículos: “Se podría incorporar una segunda casilla con otra terminal para ser utilizada
en horas pico de salida de vehículos por hora y efectuar la cobranza en dos cajas...”
Al llegar a la consultora, Ud. cree oportuno explicarle al Ing. Figueroa la solución que
le propuso al Administrador General
Al escuchar su propuesta su jefe manifiesta: “No estoy de acuerdo con su accionar, tiene
que averiguar las estrategias a tener en cuenta para efectuar un relevamiento. De todos
modos no se lo explicaré yo, es Ud. el que tiene que determinar el por qué de mi
reacción…” t233 t343 t353 t363 t373
Al concluir la conversación el Ing. Figueroa, como el día anterior le pide que le
presente el informe completo con las características generales de la empresa. t373
t383
Al día siguiente Ud. se dirige a fin de entrevistarse con el Encargado de Personal Sr.
Alfredo Paredes.
Se presenta y le explica los motivos de su presencia.
EL Sr. Paredes al escucharlo le manifiesta:
“Hoy no tengo tiempo para recibirlo y por otra parte no estoy al tanto del posible
cambio de sistemas que Ud. manifiesta...”
Ud. regresa y explica lo sucedido al Ing. Figueroa, quien reacciona diciendo:
“Previo a presentarse a esa entrevista Ud. debió haber cumplimentado una serie de
tareas... Averigüe qué debe hacer para poder continuar con el estudio” t373 t383
Ud. le explica al Ing. Figueroa los pasos a seguir y éste le solicita que prepare un
informe donde se detalle el motivo de la segunda entrevista y las preguntas a formularle
al Sr. Paredes... t353 t363 t373 t383
Ud. se entrevista con el Sr. Paredes y luego de explicar los objetivos de la entrevista, le
solicita que explique las funciones que le competen a su cargo.
Paredes comienza su relato “Soy Encargado de Personal y dependo directamente del

Administrador General. Tengo a mi cargo la planificación y seguimiento de las tareas de los
operadores. Ellos son los empleados que trabajan en las casillas. En total son 6 (seis) operadores,
dos en cada turno en forma fija y cuando hay francos que no puedo recurrir utilizo a los
encargados de limpieza para ponerlos en casilla de entrada a entregar tickets de ingreso”
El Sr. Paredes continúa con su relato: “El día Viernes se confecciona una planilla con
cada empleado y el puesto a cubrir día por día.
Cada turno es cubierto por dos personas, en forma fija; es decir que los dos operadores
del turno mañana trabajan siempre en ese turno pero rotan entre la casilla de entrada y la
de la salida.
Área Informática
El que está en la salida se encarga de cobrar a los usuarios de estacionamiento por hora.
Al final del turno llena manualmente una planilla con el detalle de la recaudación y le
agrega un ticket resumen que emite la caja registradora fiscal.
Esa planilla con la rendición del turno se me entrega y personalmente efectúo el

control.
Una copia de la planilla la entrego a Secretaría Administrativa.
El que se encuentra en entrada emite el ticket para los usuarios por hora a través del
Sistema”
Ud. le pregunta al Sr. Paredes si existen problemas en el área, y este plantea: “Los
problemas principalmente son de controles en diversos aspectos.
En la terminal de cobranzas, como planteé anteriormente se emite por medio de la

impresora fiscal un ticket resumen de la recaudación y el operador llena manualmente
una planilla con el detalle de lo cobrado. Pero a su vez, yo puedo sacar una planilla de
recaudación de la caja a través del Sistema. El operador de salida, cada vez que tipea el
ticket el sistema calcula lo que tiene que cobrar y lo guarda, además de mostrar el monto
y el código que tiene que tipear en la registradora e imprimir el control de cobro para
entregárselo al automovilista. Es decir que puedo llevar un doble control, a través de la
registradora y del sistema. Muchas veces no coincide el total recaudado según muestra el
sistema o el resumen de la registradora. Es como que el sistema guarda el monto a cobrar
pero no se lo tipea en la registradora y no se le emite el ticket al automovilista."
Al consultársele sobre el sistema de cobranzas de usuarios por hora el Sr. Paredes contesta:
“El sistema en sí es óptimo, no sabría decirle en cuanto a su lentitud o rapidez. Yo no

estaba en la empresa cuando se lo implementó. Originalmente no se trabajaba con
registradora y los tickets se imprimían con una impresora común, luego con las
reglamentaciones impositivas del Gobierno Nacional se sacó la impresora y se agregó en
forma paralela la registradora. Sólo objeto que el sistema permite que el operador acceda
a los registros de cobro y pueda efectuar cambios por ejemplo a los montos. Creo que allí
puede estar el motivo de las diferencias en las planillas de control”
Como la entrevista se extiende más de la cuenta Ud. y Paredes quedan en continuar al

día siguiente y se dirige a la consultora.
Su jefe al recibirlo lo escucha atentamente y continúa con su evaluación...
“Al explicar el organigrama y las funciones de cada persona, el Administrador General

manifestó que existían 8 (operadores), sin embargo el responsable del personal manifiesta
que existen 6 (seis) y que a veces se recurre a los responsables de la limpieza para hacer
reemplazos ante los francos que se pudieran dar...
¿Qué haría ante esta situación?:
¿Entrevistaría a las dos personas de limpieza como si fueran operadores?

¿Le prepararía un cuestionario con preguntas puntuales sobre la tarea que se le
encomienda excepcionalmente?
¿De qué otra forma procedería?
t343 t353 t363 t373 t383 t393 t403 t413 t423 t433
Al mismo tiempo el Ing. Figueroa le solicita que confeccione un modelo de
cuestionario para presentarle a ambas personas... t393
El Sr. Figueroa lo indaga a cerca de qué otras técnicas se pueden aplicar para tener una
visión más amplia del proceso de cobranzas en caja de usuarios por hora... t343
t353 t363 t373 t383 t393 t403 t413 t423 t433
Antes de continuar con el estudio debe presentarle a Figueroa un informe donde se
detalle la documentación que solicitará sobre el proceso de cobranzas y qué aspectos se
deberían relevar del software... t403 t433
Al dirigirse al día siguiente Ud. le manifiesta a Paredes “Hasta ahora me explicó lo

referido a cobranzas en caja, pero ¿Qué me puede decir de las otras actividades?”
Y él le contesta: “Bueno el resto es muy simple, pues en la salida y en entradas de

abonados el sistema actúa sólo. El operador no interviene. Y, en ingreso de vehículos por
hora, el operador imprime el ticket para entregárselo al automovilista. Con ese ticket, al
salir lo muestra al cajero para que le cobren.”
Para cerrar la entrevista Ud. le solicita que cuente los problemas y necesidades del
Sector a lo que el Sr. Paredes responde:
“Fundamentalmente es necesario ver el tema del sistema para mejorar la seguridad en

los cambios de datos de las cobranzas.
Otro aspecto importante es que necesito mejorar el tema de la planificación de

actividades de los operadores, tenerlo automatizado para poder consular en cualquier
momento e incluso prever con tiempo los francos y los reemplazos. La planilla que
preparo manualmente me lleva mucho tiempo y más aún comunicársela a cada
empleado. El sistema tendría que imprimir copias con el programa para cada operador.
Y la otra cuestión que resta analizar es la referida a los embotellamientos de vehículos

en ingresos y salidas. No sé a ciencia cierta cuál es el problema, puede ser una cuestión de
lentitud de la gente al operar las computadoras.
El Sistema actual no controla la cantidad de vehículos estacionados en los dos pisos y a

veces se forma cola al ingreso y nos encontramos con que no hay lugar. Esto origina un
problema pues se tienen que retirar los vehículos uno por uno marcha atrás”
Al regresar a la consultora Ud. prepara a Figueroa un informe con las información

relevada y una explicación de cómo continuará con el relevamiento... t373 t383
Área Informática
Al leer el informe Figueroa manifiesta “Respecto al embotellamiento de vehículos en

entrada y salida, ¿Cómo haría Ud. para estudiarlo y poder diagnosticar las causas y
proponer alguna solución?...” t343 t353 t363 t373 t383 t393
t403 t413 t423 t433
En su informe Ud. manifestó que a continuación entrevistaría a los operadores y
Figueroa pregunta “Según su opinión, ¿Convendrá entrevistarlos en sus horarios de
trabajo? t353 t363 t373 t383
Al finalizar la conversación Figueroa le solicita que prepare un informe con las

preguntas a formularle a los operadores ... t353 t363 t373
Para comenzar, Ud. entrevista al Sr. J. Heredia operador del turno mañana y comienza
explicándole las características del proyecto.
A continuación le pregunta a cerca de las características de su trabajo, a lo que Heredia

responde.
“Soy operador, cubro el turno mañana y mi tarea varía según lo que me indique mi
jefe, el Sr. Paredes. A veces cubro la entrada operando y otras veces en salida.
Cada Viernes el Encargado de Personal me muestra la planilla con los puestos a cubrir
y los nombres de los operadores que me preceden y me suceden. Es difícil recordarlo, por
lo que lo anoto en un papel y lo dejo en el mostrador.
En entrada la tarea es bastante simple, pues cuando viene un usuario de

estacionamiento por hora, le tengo que entregar un ticket. Tipeo la patente del coche y el
programa imprime el ticket con la fecha y hora del ingreso.
El único problema que tengo es que a la mañana temprano a eso de las 7,30 hs. Llegan
muchos vehículos y es lento el hecho de tener que tipear los 6 (seis) dígitos de la patente.
Tendría que ser de otro modo... Esto origina largas colas y la gente protesta demasiado.
En cuanto a la entrada de abonados, se realiza por la misma vía, por lo tanto forman la
cola junto con los vehículos por hora. El abonado pasa la tarjeta en la lectora y si está al
día en los pagos se levanta la barrera. El problema se da cuando la barrera no se abre. En
ese caso yo le tengo que pedir que pase la tarjeta de nuevo y ver en pantalla el mensaje
que el programa nuestra. Si hay problemas con la tarjeta, tipeo una tecla de función F4 y
se imprime un ticket de control de ingreso gratuito para que se levante la barrera y el
abonado se dirija a la administración a solucionar el problema.
Estas detenciones, si se dan en horas tempranas, también originan colas de vehículos.
Cuando me toca cubrir la salida la tarea es similar en cuanto a la salida de abonados,

pues no hago nada, salvo ver el monitor cuando no se levanta la barrera. A veces no me
doy cuenta que hubo un problema cuando no se levanta la barrera del subsuelo. Mi
casilla está en el piso superior. En esos casos los abonados que no pueden retirar sus
vehículos tocan bocina y veo la pantalla para observar el mensaje. Como no puedo salir
llamo a otra persona para que baje y le informe al automovilista del problema.
En estos casos el usuario no puede retirar el vehículo de ninguna manera, tiene que
dirigirse a la Administración a solucionar la situación.
En cuanto a la salida de vehículos por hora mi tarea es similar a la de entrada. Cuando

el automovilista pasa por la casilla, me entrega el ticket, tipeo el número de patente y el
programa me calcula el monto a cobrar y me lo muestra en pantalla junto con el código
que tengo que tipear en la registradora. Es un poco lento el hecho de tener que tipear en
la computadora y en la registradora. A las 14 horas cuando sale la mayor parte de los
vehículos se origina una gran cola.
Al final del turno saco un resumen de la registradora y lleno una planilla de recaudación
para entregársela al Encargado.”
Ud. al escuchar al operador le solicita que le entregue copias de los registros escritos
que utiliza y el operador le pide que le de un detalle de la documentación que necesita.
t403
Al continuar con la conversación Ud. le manifiesta al operador que necesita estudiar
las situaciones excepcionales que se presentan cuando un abonado no está al día en las
t343 t363 t373
cuotas y no se le abre la barrera, explicando cómo lo hará...
t383 t393 t403 t413 t423 t433 t443 t453 t463 t473
t483 t493 t503 t513 t523
Del mismo modo Ud. le explica que necesitará estudiar el software en ingreso como en
t413 t423
salida detallándole de qué manera lo hará y qué aspectos analizará...
t433 t443 t453 t463 t473 t483 t493 t503 t513 t523
Luego de entrevistar al Sr. Heredia, el analista releva a un segundo operador, el Sr. H.
Juárez, el otro operador del turno mañana, quien manifiesta respuestas similares a las del Sr.
Heredia, ante esto el analista de sistemas decide no entrevistar a los dos operadores del turno
tarde y entregarles un cuestionario escrito con preguntas concretas referidas al sistema.
Al llegar a la consultora le explica a Figueroa su decisión de no entrevistar a los

operadores del turno tarde y su jefe plantea que no está de acuerdo...
“Averigüe por qué no será conveniente utilizar cuestionarios en este caso e infórmelo...”
t343 t353 t363 t373 t383 t393 t403 t413 t423 t433
t443
Figueroa continúa con su evaluación... “A mi modo de ver a los operadores nocturnos
es difícil entrevistarlos pues no asisten en otros horarios, ¿Qué haría Ud. para relevarlos?
Área Informática
¿No los relevaría? ¿De qué manera procedería?” t343 t353 t363 t373
t383 t393 t403 t413
Figueroa plantea ”Supongamos que optamos por elaborar cuestionarios... Prepare un
modelo de cuestionario a presentar a los operadores nocturnos t393
Por último Figueroa le plantea que le presente un informe de cómo haría para estudiar
los embotellamientos vehiculares en entrada y salida y si ve conveniente realizar el
t343 t353 t363 t373
estudio del hardware justificando su opinión...
t383 t393 t403 t413 t423 t433 t443 t453 t463 t473
t483 t493 t503 t513
Luego de finalizar el relevamiento de los servicios de estacionamiento, Ud. se apresta a
entrevistar a la Secretaria Administrativa, Srta. Inés Duarte.
Inés Duarte es una de las dos personas a cargo de la Secretaría Administrativa, que
comienza relatando sus funciones de la siguiente manera...
“En este sector nos encargamos del pago a proveedores, pago de gastos que puedan
surgir y cobranzas de abonos mensuales, fundamentalmente la función es de control de
flujo de dinero.
Mi horario es de 7 a 15 horas y a continuación entra otra persona, Analía Moyano que

cumple la misma función de 15 a 23 horas.
Lo único que hago diferente respecto a Analía es que también me encargo de liquidar
sueldos y jornales y de abonarles a todos los empleados.
Para la liquidación de sueldos cuento con un programa que se compró hace varios
años, pero que cumple perfectamente con lo que necesitamos.
El resto de las tareas las realizamos manualmente y resulta bastante complicado.
Para llevar el control de gastos, utilizamos unas planillas de Gastos Previstos en donde
se asientan las facturas pendientes de pago y a medida que van venciendo efectuamos el
pago y asentamos el pago en esa planilla de Pagos Realizados.
En cuanto a los cobros, a través del sistema de estacionamiento, contamos con una
terminal en donde está el sistema de abonados, por lo tanto la cobranza está
automatizada.
Con él, damos de alta nuevos abonados, sacamos su ficha, cobramos mensualmente el
abono, desactivamos las tarjetas los días 10 de cada mes a los que no abonaron en base a
un listado de moras, podemos controlar si un vehículo está estacionado o no en la playa.
Para rendir el dinero ingresado, el sistema nos arroja un listado con los abonos
cobrados.
Ese listado junto con la planilla que me entrega el Encargado de Personal con la
recaudación de la caja de usuarios por hora y el resumen que arroja la registradora,
permiten llevar el control de ingresos.
En fin el sistema es bastante completo. El único inconveniente es la lentitud para

controlar las moras y desactivar tarjetas una por una. Sería bueno que el sistema lo haga
automáticamente.
Otro aspecto que se presenta es que originalmente estaba pensado para dos usuarios
especiales que tiene la playa, una empresa que autoriza a sus empleados a estacionar y
una compañía de seguros que se hace cargo del estacionamiento de sus clientes.
El sistema de cobro en la casilla se adaptó a estos clientes, que no pagan al momento de

retirar el vehículo, sino que a fin de mes el sistema emite un resumen de cuenta para que
las autoridades abonen. El sistema no permite actualmente incorporar nuevos clientes
“especiales”. Sería bueno poder tener abierta la posibilidad de categorizar clientes y
servicios contratados para que el sistema sea flexible a estos casos que se presentan.”
Ud. le consulta al operador que otros requerimientos plantearía para el nuevo sistema y
la Secretaria contesta lo siguiente:
“Fundamentalmente el sistema de gastos tiene que estar conectado al sistema de

estacionamiento. Quiero tener un solo sistema y no trabajar manualmente.
Los sueldos se seguirán llevando como está y la idea es registrar el pago en el sistema de
gastos.
El sistema tiene que llevar lo que hacemos manualmente en cuanto a los controles de
gastos pendientes y cumplimentados.
Respecto a las cobranzas y el sistema de estacionamiento, necesitamos que el nuevo

sistema realice lo mismo, más lo que planteé anteriormente respecto a clientes especiales
y desactivación de tarjetas.”
Al llegar a la consultora Figueroa le solicita que presente un informe con la información

relevada a los operadores y a la Secretaría administrativa... t383
Al leer el informe Figueroa le pregunta ¿Según su opinión, será necesario relevar el

sistema de abonados? t413 t423 t433
Al terminar la conversación Figueroa le manifiesta que no ha solicitado documentación

alguna y que le detalle qué documentación deberá solicitar. t403
Finalmente tanto Ud. como Figueroa consideran terminado el relevamiento y Ud. debe
detallar los requerimientos y problemas a cubrir en el proyecto total, a fin de poder
Área Informática
preparar un presupuesto para el cliente. t443 t453 t463 t473 t483

t493 t503 t513
Figueroa le pide que elabore el Anteproyecto enumerando la meta, objetivos y
planteando las opciones de solución. t543 t553 t563 t573 t583 t593
t603 t663
Al mismo tiempo el Ing. Figueroa le indica: “Necesitamos informar al Administrador
de la Playa el costo de implementación del proyecto...” t613 t623 t633 t653
“... y elaborar un Diagrama de Gantt con los tiempos estimativos para las actividades a
realizar a lo largo del proyecto “t653
Guía de tutores 3
1. Conceptos y diferencias de datos e información.
2. Función de la información.
3. Características de la información
4. Clasificación de la información.
5. Operaciones con los datos.
6. Métodos de Procesamiento de datos existentes.
7. La elección del método de procesamiento.
8. Sistemas de Información: Conceptos y características. Sistema Objeto, Sistema de
Datos, Teoría de los sistemas de Información.
9. Problemas de diseño de sistemas: infológico y datológico.
10. Funciones de los Sistemas de Información.
11. Necesidades de los Sistemas de Información.
12. Información para la toma de decisiones.
13. La toma de decisiones
14. Elementos para la toma de decisiones
15. Clases de decisiones. Decisiones Programadas y No Programadas
16. El proceso de toma de decisiones.
17. Niveles de toma de decisión.
18. Necesidades de información para los diferentes niveles de decisión.
19. La Información como un recurso de las organizaciones.
20. ¿Qué es el análisis y diseño de sistemas?

21. Responsabilidades del Analista de Sistemas
22. Responsabilidad de la programación de computadoras.
23. Papeles del Analista de Sistemas: Como consultor, como especialista de apoyo,
como agente de cambio.
24. Lo que No es el Analista de Sistemas.
25. ¿Cómo han cambiado las responsabilidades del Analista de Sistemas?
26. ¿Quiénes son los usuarios de los sistemas de información?
27. ¿Quiénes participan de los proyectos de sistemas?
28. Cómo comienzan los proyectos de sistemas. Razones para los proyectos.
29. Origen de las solicitudes de un proyecto
30. Administración de la previsión y selección de proyectos.
31. Tipos de Sistemas de Información.
32. El ciclo de desarrollo de los Sistemas.
33. Diferentes tipos de ciclo de vida de proyectos.
34. Técnicas para hallar datos.
35. Entrevistas. Concepto, características, ventajas, desventajas, situaciones de
aplicación práctica.
36. Determinación del tipo de entrevista.
37. Etapas de la entrevista. Antes, durante y después de la entrevista.
38. ¿A quiénes entrevistar?
39. Cuestionarios. Concepto, características, ventajas, desventajas, situaciones de
aplicación práctica
40. Revisión de registros, documentación y antecedentes. Concepto, características,
ventajas, desventajas, situaciones de aplicación práctica
41. Observación Personal. Concepto, características, ventajas, desventajas, situaciones
de aplicación práctica
42. Cuándo observar.
43. Relevamiento del hardware y software existente.
44. Estudio de la situación actual del negocio.
45. Determinación de los requerimientos de información para el futuro sistema.
Verdaderos y falsos requerimientos.
46. Cómo se determinan los requerimientos básicos.
47. Identificación de los datos utilizados e información producida.
48. Determinación del tiempo de proceso y cantidad.
49. Identificación de controles.
Área Informática
50. Cómo se determinan los requerimientos de transacciones de los usuarios.

51. Cómo se determinan los requerimientos de decisión de los usuarios.
52. Identificación de problemas y oportunidades.
53. Metodología de análisis y diseño Cliente-Servidor con interfaz gráfica.
Características de la metodología y actividades involucradas.
54. El Anteproyecto.
55. Propósito del anteproyecto.
56. ¿Quién hace el anteproyecto?
57. Características del Anteproyecto.
58. Detalle del Anteproyecto.
59. La declaración de la meta.
60. La lista de objetivos.
61. El estudio de factibilidad de un proyecto.
62. Factibilidad Técnica.
63. Factibilidad Económica. El valor y costo de la información.
64. Factibilidad operativa.
65. Criterios de evaluación de los objetivos. Criterios de evaluación de costos, tiempos y
riesgos. Criterios de “idad”.
66. Opciones de solución.
67. El Anteproyecto escrito como un contrato.
Material elaborado por Ing. Fernando Loza

2002 – AML & JCN
18/07/2009 09:57:00

Sistemas II

Cargado por

Copyright:

Formatos disponibles

Sistemas II

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemas II

Cargado por

Copyright:

Formatos disponibles

Área Informática

INSTITUCIÓN CERVANTES Sistemas II

En la estructura de estudios corresponde al 2do. Cuatrimestre.

En esta asignatura los alumnos desarrollarán actividades que le permitan experimentar

Unidad II: El ciclo de vida de desarrollo de los sistemas de información

Unidad III: El relevamiento de datos e información

1. Conceptualice: ¿Qué es un sistema?

2. Dé algunas clasificaciones de sistemas por Ud. Conocida.

3. Qué aspectos caracterizan a las organizaciones como sistemas.

4. De acuerdo al siguiente enunciado identifique:

“La institución INFORMÁTICA PARA EL NUEVO SIGLO dicta cursos de computa-

Las reservas de lugar se realizan a través de la inscripción del alumno conjuntamente

No se efectúan reservas de lugar sin el pago de la matrícula correspondiente, aunque

El control de inasistencias y calificaciones se lleva manualmente, lo que origina que al

Dicha planilla se encarpeta y en función de la misma se preparan los diplomas en ad-

5. Describa brevemente las características de los subsistemas de la organización.

6. Dé la definición de las actividades esenciales de la administración:

7. ¿Qué información incluye un plan?

8. Compare y diferencie la organización formal y la informal.

9. ¿Para qué sirve un organigrama?

10. ¿Qué tipos de organigrama conoce?

11. ¿Qué es un puesto de trabajo?

12. ¿Qué elementos incluye un sistema de control?

13. ¿Qué tipos de control existen?

14. Enumere y describa brevemente los métodos de control conocidos.

Mapa Conceptual de la Unidad

La información será entonces, un recurso sumamente valioso para la organización; y,

El desafío para los profesionales de sistemas consistirá en desarrollar sistemas de infor-

La finalidad de recopilar y procesar datos es la de producir INFORMACIÓN.

8 Por ello podemos definir a la información como el resultado del procesa-

Aún cuando en la organización existan enormes volúmenes de datos, no todos tienen

No debemos confundir cantidad con calidad informativa.

8 En definitiva, podemos determinar que dato es una representación de he-

La INFORMACIÓN significa un aumento de conocimientos, obtenidos por el recep-

Información es cualquier clase de conocimiento o mensaje, para posibilitar, modificar o

La información es el conocimiento derivado del análisis de los datos.

La información es el principal componente de las decisiones de las personas, aunque

8 Para concluir la información es un acontecimiento, o una serie de acon-

Cada edad, es un dato, y el promedio resultante de una serie de operaciones de cálculo,

De todos modos, siempre dependerá de la necesidad informativa del destinatario, pues

La información, tratándose de decisiones complejas, aumenta la certidumbre o reduce

Las funciones de la información pueden ser resumidas de la siguiente manera:

Adecuada: La información debe ser adecuada en cuanto a su estructuración y selecti-

Es importante tener en cuenta algunos conceptos, por demás importantes:

Oportuna: La información debe ser oportuna en el tiempo. Debido al carácter diná-

La información debe representar la realidad y no estar atrasada.

/ A continuación se analizan tres características relacionadas con la informa-

Cantidad de información generada

En primer lugar se presenta la cantidad de información generada, y tal cual se observa

Nivel de la Organización Cantidad de información generada

En segundo término se analiza el grado de detalle de la información. Los niveles supe-

Nivel de la Organización Nivel de detalle de la información

Nivel de la Organización Necesidad de la información

8 Las características de la información dependerá de la necesidad del

Información de acción o no acción: La información es de acción cuando el receptor

Por ejemplo qué cantidad de alumnos serían atendidos en la inscripción a exámenes

Operaciones con los Datos

Captación: Registración de datos a partir de los eventos ocurridos.

DATOS PROCESAMIENTO INFORMACIÓN