471-477

INTRODUCCION
A LA INVESTIGACION
DE SISTEMAS
CONCEPTO BASICO
Una plena comprensin de investigaciones de sistemas puede permitirle participar en
proyectos de sistemas en cuanto entre a una organizacin, donde su contribucin puede
atraer de inmediato Ia atencin de los administradores senior.

OBJETIVOS DEL CAPITULO

1.

Delinear el "ciclo de vida" de un sistema de informacin.

2.

Introducir a los personas incluidas y explicar las diversas formas en que los
"problemas personales" pueden influir en los investigaciones de sistemas.

3.

Presentar varios principios generales para guiar las investigaciones de sistemas.

4.

Explicar cmo lo administracin controla una investigacin de sistemas.

QU ES LA INVESTIGACIN DE SISTEMAS?
Los trminos "anlisis de sistemas" y "diseo de sistemas" se encuentran con frecuencia;
la "investigacin de sistemas" incluye a stas as como a otras actividades. Una
investigacin de sistemas es un proyecto realizado para mejorar un aspecto especifico del
sistema de informacin, su naturaleza es trabajar con gente para identificar los sistemas
que ayudan a la gente a trabajar mejor. Una investigacin de sistemas, algunas veces
llamada un "proyecto de desarrollo de sistemas" se apoya en un cuerpo extenso de una
metodologa y un conjunto bien definido de herramientas y tcnicas para poder analizar,
disear e implantar un sistema de informacin, o una porcin de un sistema de
informacin.
POR QU ESTUDIAR INVESTIGACIN DE SISTEMAS?
El estudiante que toma un puesto en una organizacin pequea o mediana puede ser el
administrador ms calificado de la compaa en el rea de sistemas de informacin y, por
esta razn, es probable que se le pida que participe a fondo en una investigacin de
sistemas. Aun en compaas grandes, la oportunidad de participar en una investigacin de
sistemas se presenta con frecuencia a los administradores jvenes, cuya educacin
formal acaba de terminar y que han estudiado desarrollo e implantacin de sistemas. El
nuevo administrador debera buscar tal oportunidad porque es probable que dicha
participacin traiga consigo una experiencia muy valiosa. Con su conocimiento de
sistemas de informacin adquirido en investigacin de sistemas, el estudiante est en
posicin de participar en las investigaciones de sistemas; el principal ingrediente que le
falta es el conocimiento del proceso, herramientas y tcnicas involucradas en
investigaciones de sistemas.
Cmo pueden los administradores jvenes comprometerse en investigaciones de
sistemas? Hay, por lo menos, cinco maneras, como se muestran en la figura 14.1 y que
se estudian a continuacin.
1.

2.

Como Usuario de un sistema. Todos los puestos dentro de una organizacin

utilizan informacin, de la cual la mayor parte la proporciona un sistema de
informacin formal. Los usuarios de sistemas de informacin pueden involucrarse
activamente en la especificacin de sus necesidades de informacin: no tienen
que esperar a ser invitados. Un usuario debera entender la naturaleza de los
sistemas de informacin a fin de poder reconocer sus posibles mejoras.

Como un representante de usuarios. Con frecuencia, un departamento de una

organizacin designa formalmente a uno de sus miembros Para servir de enlace
con el departamento de sistemas de informacin de la organizacin. La actividad
de enlace incluye reuniones de los representantes de usuarios de otros
departamentos, comunicar a los analistas de sistemas las necesidades de
informacin del departamento y explicar a los otros miembros del departamento los
cambios propuestos por los analistas. Servir como enlace proporciona a un
administrador joven una oportunidad de obtener conocimientos de los sistemas de
informacin de la organizacin y de la estructura de los proyectos de sistemas.

3.

Como un participante de una investigacin de sistemas. Un administrador nuevo

puede ser asignado temporalmente a un proyecto particular de investigacin de
sistemas, quiz en un grupo de trabajo que utiliza la experiencia del administrador
especializado. Este trabajo temporal puede ser una experiencia valiosa.

4.

En un puesto de supervisin o de asesora. Cuando un administrador adquiere

experiencia en una organizacin, tal vez sea asignado como supervisor de una
investigacin de sistemas. Por ejemplo, podra convertirse en miembro o miembro
alternativo de un comit de sistemas o en lder del grupo de una comisin de
trabajo de sistemas

5.

Como un analista entrenado en sistemas. Un administrador joven puede elegir

dedicar un tiempo al desarrollo de sistemas. Las raras oportunidades disponibles
en trabajos en sistemas se discutieron en un captulo anterior. Una carrera puede
incluir de 1 a 3 aos dedicados a ser analista de sistemas, quiz corno parte de un
programa de entrenamiento para los administradores. Los puestos de analistas de
sistemas u otra clase de especialistas en sistemas puede estar dentro del grupo
central de computacin o de una parte de un departamento de usuarios. Debido a
la proliferacin de centros de microcornputadoras dentro de los departamentos
operativos, ha aumentado el nmero de puestos disponibles en sistemas con
grupos de usuarios.

Aun si la participacin est restringida a la comunicacin con el analista de sistemas

de la organizacin, el Conocimiento por parte de un administrador joven de los
sistemas de informacin e investigacin de sistemas proporciona un entendimiento de
las actividades del analista. Este conocimiento tambin ayuda a entender todas las
actividades de la organizacin.

Debe mencionarse un punto: una investigacin de sistemas es una actividad compleja con
muchas variables, y hay un horizonte muy amplio que permite una gran cantidad de
errores muy senos. Slo algunos de stos pueden mencionarse en un texto elemental;
generalmente alguien con especializacin en sistemas de informacin estudia dos cursos
de especializacin en investigacin de sistemas. Sin embargo, si el estudiante aplica los
principios y sigue los este captulo y de los siguientes, puede evitarse muchos de los
errores graves ms comunes ; el texto tambin destaca varias reas de investigaciones
de sistemas en las que debe tenerse sumo cuidado.
CICLO DE VIDA DE UN SISTEMA DE INFORMACIN
CONCEPTO
El concepto del ciclo de vida de un sistema de informacin es medular en las
investigaciones de sistemas. Durante su desarrollo, cada sistema se mueve a travs de
varias fases de un ciclo de vida, despus del cual slo funciona por varios aos con un
mnimo mantenimiento. El sistema se deteriora gradualmente hasta el punto en que cesa
de funcionar por completo y se comienza un nuevo ciclo de vida con el desarrollo de un
nuevo sistema.

La figura 14.2 muestra el ciclo de vida de un sistema. La figura muestra 5 fases. (Otros
autores ilustran el ciclo de vida con diferentes nmeros de fases, stas son la fase de
estudio preliminar, la fase de anlisis de sistemas, la fase de diseo de sistemas, la fase
de implantacin, la cual incluye una actividad separada llamada "auditora posterior". Los
ciclos de vida de sistemas varan en gran manera en trminos de longitud, pero por lo
regular el ciclo de vida de un sistema de informacin est en el rango de 3 a 8 aos: las
primeras cuatro fases de este ciclo de vida llamarse las fases de investigacion de
sistema.

FIGURA 14.2

Ciclo de vida del sistema

Analisis

Madurez y
Fases de
Mantenimiento Inv. De sistema
Diseo
del sistema
El concepto de ciclo de vida est relacionado con otro concepto importante, el de
grupos profesionales de desarrollo de sistemas
de informacin. Las organizaciones
Implantacion
grandes y medianas por lo general tienen especialistas de investigacin de sistemas de
Auditorioincluyendo
posterior
tiempo completo,
programadores y analistas. Por lo regular, para todas,
excepto para las investigaciones de sistemas menores, se formar un equipo al
momento de iniciar la fase de estudio preliminar. Es probable que el equipo crezca al
entrar en la fase del anlisis y que su composicin se modifique de alguna forma para
entrar en la fase del diseo de sistemas. Despus el equipo, quiz modificado de nuevo
en su composicin, implanta el sistema diseado. En cuanto cada miembro del equipo
termina las responsabilidades que le fueron asignadas, se le asignan otras
responsabilidades del proyecto o se le signa a otra investigacin de sistemas. Por tanto,
los equipos de proyectos son dinmicos: se forman y reforman de continuo para
participar en diferentes aspectos de la investigacin de sistemas o en otras
investigaciones de sistemas. Existe un reciclamiento continuo del personal profesional
de sistemas a travs de una serie de investigaciones de sistemas,
Es til mencionar brevemente cada una de las fases de la investigacin de sistemas:
1. Fase de estudio preliminar. Durante esta fase, con un sistema de informacin
existente se descubre un problema o una oportunidad de desarrollar tilmente un
nuevo sistema, y se lleva a cabo una cantidad limitada de investigacin preliminar
para ver si un proyecto de sistemas est garantizado.
2. Fase de anlisis de sistemas. Durante la fase de anlisis, se identifica un
problema u oportunidad asociada con el sistema. se examinan los puntos dbiles y
fuertes, del Sistema Antiguo, y se determina para que servir un nuevo sistema.
3. Fase de diseo de sistemas. Durante esta fase se disea un nuevo sistema o una
aplicacin computarizada para satisfacer Ias necesidades que se han determinado

durante la fase de anlisis. Asimismo se completan, tanto los estudios de

hardware, como el diseo del software.
4. Fase de implantacin. Esta fase involucra la programacin, instalacin de equipo,
y otras actividades relacionadas con la implantacin de un sistema diseado.
S.

Fase de madurez y mantenimiento de sistemas. Esta fase incluye la operacin

continua del sistema despus de su instalacin. Por lo general, el sistema alcanza
su ms alto desempeo, y despus la efectividad de su costo declina
gradualmente al cambiar su ambiente, al cambiar sus costos de operacin, o al
gastarse o convertirse en obsoleto su equipo. Cerca del final de esta fase, se
reconoce que el sistema no est funcionando satisfactoriamente y se reemplaza.

Una breve auditoria posterior es parte de la fase de madurez y mantenimiento de

sistemas. Para determinar si la investigacin se realizo con eficiencia y para establecer
hasta qu punto la empresa ha recibido, los beneficios esperados, un equipo de
auditoria posterior revisa los procesos de investigacin de sistemas, as como el
funcionamiento del nuevo sistema.
Debido a que las actividades de varias fases se sobreponen, puede ser difcil
distinguirlas entre s durante una investigacin de sistemas.
Por ejemplo, el
adiestramiento de personal es una parte de la fase de Implantacin, pero el tiempo en el
que el personal acepta y una ciertos tipos de sistemas es muy largo; adems esta
actividad con frecuencia comienza mucho antes de terminar el diseo del sistema. A
pesar de esta sobreposicin de fases, es til distinguir entre ellas, ya que las
distinciones faciliten un mejor entendimiento de los procesos de investigacin de
sistemas. Adems, la mayora de las actividades de planeacin y control de proyectos
de sistemas est asociada formalmente con fases, y, por tanto, es necesario entenderlas
para poder participar de modo provechoso en la planeacin y control de Investigaciones
de sistemas.
Los principios generales de investigaciones de sistemas son semejantes pata todos
los tipos y tamaos de proyectos de sistemas, aunque su aplicacin puede requerir
diferentes procedimientos, anlisis y otros mtodos para proyectos diferentes: las
actividades de investigacin de sistemas disminuyen considerablemente para los cuales
el proceso puede ser bastante informal.
Para simplificar el estudio. se da el supuesto de que la investigacin de sistemas
incluye el desarrollo de un nuevo sistema y no la revisin de uno actual, aunque los
principios generales son aplicables por igual en ambas situaciones. Los captulos de
esta seccin se ocupan de investigaciones formales de sistemas en su trato con
sistemas de Investigacin computarizados. Sin embargo, el estudiante deber recordar
que los principios, lo mismo que muchas de las herramientas y tcnicas discutidas, son
igualmente relevantes para los sistemas de informacin no computarizados.
Economas del ciclo de vida
Los costos y beneficios asociados con un ciclo de vida de un sistema se muestran en
la figura 14.3. En trminos econmicos, si se espera que el sistema vaga la pena, los
costos totales de implantacin y operacin continua, descontados al valor presente,

deben ser menores al valor presente total de los beneficios del sistema para toda la vida
del mismo, y la diferencia entre estos costos y beneficios descontados como proporcin
del costo total, deben ser mayores de lo que seria para posibles alternativas de nuevos
sistemas en cualquier otro sitio de la organizacin.
En la figura, son iguales al rea total debajo de la lnea de costos de implantacin, y
los beneficios totales son iguales al rea total debajo de la lnea de beneficios. La curva
de costo Indica unos altos costos de inicio durante las primeras cuatro fases del cielo de
vida. Los costos operativos comienzan despus de la implantacin del sistema: es
caracteristico que los costos operativos disminuyan cuando
Costos de implatacion

Beneficios
terminacion

Costos operativos

Costos y
Fig 14.3
beneficios de un ciclo de vida
tpico de un sistema
Costos-beneficios

Tiempo
Comienza siguente ciclo

La organizacin aprende a operar el sistema en forma eficiente, y que a partir de

entonces los costos disminuyan gradualmente conforme pasa el tiempo. Aunque los
costos aumentan por varias razones, hay dos notables. Primera, cuando comienzan las
ineficiencias en el sistema se hacen necesarios pequeos cambios continuos. Segunda,
al usarse el equipo aumentan los costos de mantenimientos de equipo.
Los beneficios de un sistema nuevo pueden obtenerse antes de completarse todo el
sistema, como se indica en la figura. Esto ocurre porque ciertos mdulos del sistema se
terminan y ponen en operacin antes de terminar todo el sistema. Despus de que el
sistema esta en operacin, los beneficios continan aumentando por un tiempo hasta que
el sistema se estabiliza: durante este periodo la organizacin aprende a utilizar el sistema
a todo su potencial: en el pinto mas alto de la curva de beneficios, los cambios en la forma
en que la organizacin menaje sus negocios comienzan a disminuir la efectividad del
sistema. Este tpico que un periodo de declive gradual en el nivel de servicios
proporcionados por el sistema contine por varios aos.

Como indica en la figura 14.3, a menos que el sistema se reemplace o modifique, ya sea
para aumentar los beneficios o reducir los costos, las curvas de costos y beneficios se
cruzaran eventualmente y en ese momento los costos sern iguales a los beneficios. El
siguiente ciclo de la investigacin de sistema, deber comenzar mucho antes de el punto
de cruzamiento. como se muestra en el eje horizontal de la figura. El siguiente sistema
deber estar implantado antes de que los costos del sistema viejo igualen a los
beneficios.
Los usuarios, administradores y personal de sistemas deben anticipar aproximadamente
cundo sern iguales los costos a los beneficios. la investigacin de un nuevo sistema

debera comenzar meses, o quiz aos antes para asegurarse de que el nuevo sistema
estar listo a tiempo. Un problema comn en trabajos de sistemas es la falla de la
organizacin para anticipar la necesidad de reemplazar un sistema existente. Por
ejemplo, muchas compaas no se dan cuenta que su computadora actual llenar su
capacidad en un futuro cercano,

486-493
los proyectos de sistemas para poder distribuir los recursos, tomar decisiones acerca de
la direccin general de los sistemas de informacin, y motivar a sus subordinados para
desarrollar y utilizar nuevos sistemas. Los administradores de niveles inferiores estn en
buena posicin para hacer que sus subordinados cooperen en los proyectos de sistemas.
Cuando un proyecto de sistemas tiene el potencial de influir en muchas reas de la
organizacin, representantes de todas las reas deberan participar en l, an durante las
etapas de planeacin del proyecto.
Involucrar a los usuarios en el proyecto. Es evidente la necesidad de
involucrar a los usuarios en los proyectos de sistemas y an as, a veces los
especialistas tratan de desarrollar sistemas nuevos sin ninguna o casi ninguna
participacin por parte de aquellos. La perspectiva de los usuarios de sistemas
es absolutamente esencial para la decisin con respecto a mantener el sistema
en uso o disear uno nuevo. Los usuarios que proporcionan informacin, o
reciben informacin del sistema estn en la mejor disposicin de conocer la
disponibilidad de la informacin y de saber las capacidades que se requieren
de un nuevo sistema.
Un sistema diseado sin interaccin amplia con los usuarios se convierte en una
sorpresa desagradable para ellos y es probable que no se utilice. Por lo general los
usuarios reaccionan en forma negativa haca cualquier sistema que se ha diseado sin
su participacin. Adems, los sistemas desarrollados sin comunicacin con los usuarios,
por lo general no estn diseados adecuadamente.
Planear el proyecto dentro del contexto de planeacin a largo plazo. Sin
una adecuada planeacin a largo plazo para todo el sistema de informacin,
los proyectos individuales no sirven a todos los intereses de la organizacin
satisfactoriamente. Cada proyecto propuesto debe evaluarse en trminos de
las metas de toda organizacin.
Mantener una cartera balanceada de proyectos de sistema. Es comn que
en una compaa de tamao mediano un grupo de desarrollo de sistemas
tenga, simultneamente en proceso, varios proyectos de investigacin de
sistemas. Estos proyectos constituyen su cartera, que es semejante a una
cartera de inversiones. Una cartera de inversiones alcanza un balance ptimo
entre las inversiones de alto y bajo riesgo; en forma similar, una cartera de
proyectos de sistemas trata de balancear proyectos de alto y bajo riesgo. Este
balance se logra incluyendo proyectos de rutina como de obras de arte, as
como proyectos de larga y corta duracin. En un momento dado, slo un
nmero limitado de proyectos de alto riesgo debera incluirse en la cartera. Los
proyectos de alto riesgo son aquellos que tienen una baja probabilidad de
terminarse segn lo programado, dentro del presupuesto, y con los beneficios
esperados. Demasiados proyectos riesgosos en una cartera de sistemas
pueden resultar en un alto ndice de proyectos sin xito. La consecuencia es
una reduccin en la confianza depositada en el grupo de sistemas por parte de
los administradores y usuarios, baja moral en el grupo de sistemas, y, a
menudo, el fin de los analistas de sistemas, a quien se culpa de la cantidad de
fracasos de los proyectos.
Tomar en cuenta la evolucin de los sistemas. La escala y complejidad de
los proyectos debera ser apropiada al nivel de complejidad de la organizacin.
Durante las primeras etapas de la evolucin de los sistemas de informacin de
una organizacin, rara vez el personal de sistemas tiene la experiencia para
disear e implantar con xito sistemas complejos. Aunque pudieran disearse

e implantarse sistemas ultracomplejos, quiz la administracin y el personal de

oficina no podran aceptar los cambios radicales en las operaciones y obtener
todos los beneficios de los sistemas sofisticados. Por ejemplo, una
organizacin que no tiene la mayor parte de las principales aplicaciones del
procesamiento de datos computarizadas no debera tratar de incorporar todas
sus aplicaciones a una base de datos computarizada.
Establecer un sistema de administracin de proyectos. Se pueden adaptar,
a proyectos pequeos de sistemas, sistemas formales de administracin de
proyectos que proporcionen informes peridicos de progreso, ya que tales
sistemas permiten el manejo sistemtico y controlado de los proyectos. La
probabilidad de que sea exitosa la implantacin de un nuevo sistema, aumenta
de modo impresionante si se utiliza un sistema de administracin de proyectos.
Sin embargo, el grado de organizacin para la administracin de proyectos
debera seleccionarse de acuerdo con el costo y el valor del proyecto.
Demasiada organizacin en un proyecto pequeo no es efectiva en cuanto a
costos.
Establecer los objetivos y alcances de un sistema propuesto al inicio. Si
en el momento en que se inicia el proyecto los objetivos y el alcance de un
nuevo sistema se establecen formalmente, todos los esfuerzos se dirigen, de
modo expreso, a alcanzar los objetivos. El esfuerzo no dirigido se desvanece
en actividades tangenciales de poco valor para la organizacin. Por algunos
estimados se sabe que en muchas organizaciones el 40% de los esfuerzos en
desarrollo de sistemas se pierde en falsos inicios y tareas innecesarias; esto
puede reducirse por medio de una definicin correcta, y a tiempo, de los
objetivos y alcances de los proyectos de sistemas. Cuando se tiene un comit
de sistemas, ste debe jugar un papel decisivo al establecer los objetivos y
alcances de un sistema propuesto.
Identificar el verdadero problema. Uno de los errores ms comunes en
investigacin de sistemas no es identificar el problema ms importante. Con
frecuencia, por ejemplo, el problema no es un problema de sistemas sino un
problema de tipo personal. Quiz los usuarios no entienden cmo usar el
sistema existente y requieren ms entrenamiento, o quiz se resisten al
sistema por alguna razn. Es frecuente que las organizaciones pequeas
identifiquen el problema como una falta de computadora, cuando de hecho una
computadora no mejorara en nada las operaciones; a veces el problema real
es que los sistemas manuales existentes no estn diseados correctamente o
se han degenerado a travs del tiempo. Se comete otro error cuando se afirma
que la computadora existente no es capaz de completar las tareas de
procesamiento de datos; as, el problema se define como una falta de
capacidad adecuada de la computadora, cuando en realidad el problema es la
utilizacin ineficiente de la computadora.
A veces no se diagnostican correctamente otros tipos de problemas. Por ejemplo,
los problemas polticos pueden ser causados por bandos contrarios. Cada bando puede
tener diferentes ideas del sistema de informacin, o un grupo en la organizacin pude
rehusarse a poner su informacin a la disposicin de otro, con la consecuencia de que el
segundo pide que se desarrolle un sistema nuevo (y redundante) para que se le
proporcione informacin que ya existe. En estos casos la solucin preferible es la
negociacin y no un nuevo sistema.
Otro tipo de problema puede estar relacionado con los proveedores, ya que con
frecuencia puede encontrarse un mejor hardware o software o mejor atencin con otro

proveedor o por otras razones, la organizacin no busca otro vendedor aun si el actual no
proporciona productos o servicios completamente satisfactorios.
Particularmente en organizaciones pequeas, la cantidad del servicio de
procesamiento de datos puede deberse a los altos ndices de cambios o al ausentismo de
los empleados. Aunque la dificultad puede diagnosticarse como un problema de sistemas,
tal como una capacidad inadecuada de la computadora, en realidad es un problema de
tipo personal. Otro problema que con frecuencia no se diagnostica correctamente se
relaciona con la forma como estn organizados los sistemas de informacin. Los
frecuentes retrasos en la recepcin de informes, por ejemplo, pueden interpretarse como
la consecuencia de capacidad de sistemas inadecuados. De hecho, el problema podra
ser tan sencillo como una programacin inadecuada, la necesidad de un turno nocturno
en procesamiento de datos, o la necesidad de un sistema distribuido descentralizado para
reemplazar uno que tenga capacidad adecuada pero que est demasiado centralizado.
PROBLEMAS TIPICOS NO DIAGNOSTICADOS
1.
2.
3.
4.
5.
6.
7.
8.

ENTENDIMIENTO INADECUADO DEL SISTEMA ACTUAL.

RESISTENCIA AL SISTEMA EXISTENTE.
UTILIZACION INEFICIENTE DE LA COMPUTADORA.
PROBLEMAS POLITICOS INTERNOS.
PROBLEMAS CON EL PROVEEDOR.
ROTACION Y AUSENTISMO DE EMPLEADOS.
FALTA DE ORGANIZACIN DEL SISTEMA DE INFORMACION.
PROGRAMACION INADECUADA DE PROCESAMIENTO DE DATOS.

FIGURA 14.7
Establecer una programacin razonable de terminacin del proyecto. El
personal de sistemas se conoce por proponer programaciones sumamente
optimistas. Esto con frecuencia evidencia sus ganas de agradar, o bien puede
ser la simple subestimacin del esfuerzo involucrado. Tambin con frecuencia,
una programacin optimista resulta de las ganas de buscar la aprobacin de un
nuevo proyecto. El personal de desarrollo de sistemas debe conocer las
consecuencias para la organizacin y para ellos mismos de colocar
estimaciones no razonables de terminacin para los proyectos. Por otro lado,
deberan evitarse proyectos sin fecha lmite. Todos los proyectos deberan
tener una programacin en horas, das o semanas junto con su fecha de
terminacin. La programacin correcta coloca una cantidad especfica de
recursos de personal a cada proyecto. Sin un control cuidadoso, a veces los
proyectos continan indefinidamente y consumen cantidades exageradas de
recursos.
Uso de un sistema de evaluacin de desempeo. Antes de comenzar el
proyecto, el personal de sistemas y la gerencia deberan definir los criterios
que medirn el xito de un nuevo sistema despus de su implantacin, los
cuales, adems, debern estar comprendidos en un sistema de evaluacin de
desempeo. Tal evaluacin tambin debera comprender la evaluacin de la
eficiencia del proyecto de sistemas. Adems, tambin deberan establecerse
por adelantado los procedimientos de auditora posterior. Cuando el personal
del proyecto entiende que el xito del sistema se medir con criterios
preestablecidos, se dedicar a satisfacer dichos criterios.
Hacer compromisos que puedan modificarse. Mientras sea posible, todas
las decisiones tomadas durante la investigacin deberan permanecer como

tentativas para que puedan alterarse si es necesario. La organizacin debe

escurrirse hacia un compromiso casi al final del proyecto y dirigir cada
recurso hacia ella. Cuando se usa este enfoque, si se descubre nueva
informacin o si anlisis subsecuentes contradicen las decisiones previas,
como sucede a menudo, tales decisiones pueden revisarse y modificarse con
un gasto mnimo de recursos. Tambin existen consideraciones psicolgicas.
Primero, cuando las decisiones tomadas al principio como tentativas se alteran
despus, el personal no se siente derrotado o desmoralizado ni cree que la
organizacin no sabe lo que realmente quiere de un proyecto. Adems, si una
decisin parece determinante, puede causar que el personal no est pendiente
de las alternativas preferibles, con la consecuencia de que es menos probable
que la organizacin reciba finalmente el sistema que necesita.
Iniciar con una investigacin amplia y despus hacerla cada vez ms
detallada. La investigacin de sistemas debera iniciar con la idea general de
cmo se relaciona la actividad con toda la organizacin y considerando
alternativas amplias; a esto puede llamrsele anlisis y diseo macro y
algunas veces los expertos las llaman refinamiento sucesivo o refinamiento
iterativo. Los anlisis y diseos sucesivos se enfocan y detallan cada vez ms,
cada uno operando dentro del contexto establecido por las decisiones y
actividades precedentes; a esto se le llama anlisis y diseo micro. Sobre
todo, en la fase de diseo pueden requerirse varias iteraciones de diseo, cada
una ms detallada que la anterior, antes de establecerse el diseo final micro
ms detallado.
Asegurar la conformidad con los estndares. Cada investigacin de
sistemas que se inicie debera conformarse a los estndares de los sistemas
de informacin preestablecidos en la organizacin. Si no existe un programa de
estndares, deberan invertirse recursos iniciales para desarrollar una
programacin, definicin de datos, procedimientos de documentacin, y otros
estndares comunes de sistemas. El desarrollo de un diccionario de datos es,
en grado creciente, el enfoque adoptado para establecer muchos de los
estndares en sistemas de informacin; este enfoque puede adoptarse en
forma til aun si no se desea tener una base de datos. Si se requiere que todos
los nuevos sistemas o revisados se conformen a estos estndares se
obtendrn altos dividendos. La conformidad promueve eficiencia en
mantenimiento y desarrollo de sistemas y facilita la introduccin subsecuente
de sistemas distribuidos de procesamiento de datos, la integracin de
aplicaciones existentes (tal como una base de datos), y la implantacin de
modelos de cmputo y sistemas de apoyo de decisiones. El desarrollo de un
programa de estndares es un proyecto de sistemas importante en s mismo.
Usar un enfoque estructurado. La investigacin de sistemas debera usar
una metodologa estructurada que consista en una serie de pasos dentro de
cada fase, cada una realizada en una secuencia aproximada. Esto proporciona
una estructura comprensible del proyecto. Esta estructura tambin sirve para
aumentar la naturaleza sistemtica de la actividad y por lo tanto reduce el
grado de esfuerzo perdido. En general, mientras ms estructurada sea la
investigacin de sistemas, menor es la proporcin de esfuerzo perdido. Hay
una gran prdida de esfuerzo cuando se realizan tareas fuera de secuencia y
cuando la terminacin de la tarea precedente en secuencia hubiera
demostrado que la tarea realizada no es necesaria o se hubiera tenido que
realizar en forma distinta.

Establecer las prioridades de los proyectos. A menudo parece haber un

nmero infinito de proyectos de sistemas posibles. En la organizacin tpica
existe un retraso formal de cerca de 3 aos; esto es, hay una lista de proyectos
requeridos que an no se han iniciado y que, debido a la escasez de recursos,
no se espera iniciar en los siguientes 3 aos. Adems, muchos proyectos que
ahora se necesitan pero que otros quiz no se necesiten sino hasta dentro de 3
o 4 aos, cuando puedan completarse, no se tienen en mente. En este medio
debe usarse un sistema de prioridades para asegurar que los proyectos de
sistemas ms crticos se realicen primero. Por lo regular, se establecen
prioridades por medio de un comit directivo de sistemas; despus de que se
da una audiencia a cada proyecto, se define la vala de cada uno, y se le
asigna un nivel de prioridad.
Una ltima palabra sobre principios de investigacin de sistemas.
Del estudio previo de principios puede verse que la investigacin de sistemas es
compleja y que el trabajo en sistemas es tanto un arte como una ciencia. Tratar con la
gente es en buena medida un arte, y la ciencia est representada por un extenso cuerpo
de la teora de desarrollo de sistemas y una serie de principios para la aplicacin de dicha
teora. Para ser un analista profesional, se requiere tanto el estudio, como la experiencia
en la aplicacin de los aspectos del arte y la ciencia de investigacin de sistemas.
PAPELES DE LOS AUDITORES EN LA INVESTIGACION DE SISTEMAS
Durante la fase de anlisis de sistemas, los auditores internos pueden ayudar a
asegurar que se identifique el problema de sistemas ms importante, su ayuda puede ser
valiosa si el sistema existente se entiende como consecuencia de auditoras previas.
Adems, cerca del final de est fase, el auditor puede asegurarse de que cualquier sistema
nuevo proporcionar datos necesarios durante las auditoras subsiguientes del sistema.
Ms all de esta participacin algo limitada, el auditor interno no est involucrado a fondo
en la fase de anlisis de sistemas.
Los auditores deberan involucrarse profundamente durante la fase de diseo.
Primero deberan preocuparse de que los sistemas que se acaban de disear sean
auditables; esto es, deben existir auditoras de prueba. Las auditoras de prueba son una
forma de vigilar las transacciones a travs del sistema. Sin tales auditoras, el sistema no
podra auditarse despus de su implantacin; lo que es ms importante, sin ellas, los
gerentes que deben monitorear el procesamiento de datos o las transacciones no podran
saber cmo se proces una transaccin especfica, o ni siquiera si se proceso. En el
procesamiento es importante mantener una lista de todas las transacciones procesadas y
una lista separada de todos los errores como un ingrediente importante en el
mantenimiento de una auditora.
A los auditores les preocupan los controles en el sistema que se est diseando.
Los controles aseguran que se complete el procesamiento de datos y que sea exacto;
tambin protegen los recursos de la organizacin de errores en el procesamiento de datos
y protegen a los sistemas del abuso por parte de las personas. Con frecuencia, durante el
diseo del sistema, el personal de sistemas da mucha importancia a la eficiencia de la
operacin de la computadora y no a la proteccin contra perdidas de los recursos de la
organizacin. Por otro lado, los auditores se preocupan de los recursos de la organizacin
y del uso eficiente de dichos recursos. Debido a esta perspectiva, los auditores
contribuyen de modo sustancial al diseo de controles para nuevos sistemas.
A los auditores no slo les preocupan los controles especficos; tambin les
preocupa si existe un marco unido de controles internos y si los controles especficos
planeados para un nuevo sistema son adecuados en el esquema general de los controles

internos. Como parte de esta preocupacin, los auditores tratan de especificar la

naturaleza de los riesgos contra los cuales hay que protegerse en todos los sistemas;
entonces pueden evaluar los controles de un nuevo sistema en trminos de cmo ayudan
estos controles a proteger contra los riesgos percibidos.
Aunque el papel exacto de los auditores en el diseo de sistemas vara en
diferentes organizaciones, muchas de ellas prefieren que los auditores recomienden qu
riesgos deben controlarse y que los diseadores de sistemas recomienden los controles
apropiados. En tales organizaciones los auditores no recomiendan controles especficos
ni participan directamente en el diseo del nuevo sistema. Sin embargo, revisan el diseo
del sistema para asegurarse que, dados los riesgos, los controles especficos
seleccionados sean adecuados y que todo el sistema de controles sea satisfactorio. En tal
tarea, deben considerar los puntos a favor y en contra entre el costo y el valor de los
controles en vista de los riesgos que se presentan.
Durante la fase de implantacin, la responsabilidad principal de los auditores es
asegurarse que los controles diseados en el nuevo sistema se implanten realmente. Un
auditor interno tambin puede ser parte del grupo de auditora. Una ventaja principal de
que los auditores participen desde la investigacin, es que les da la oportunidad de
estudiar el nuevo sistema desde su desarrollo; este estudio les ayuda en auditoras
posteriores del sistema durante su operacin.
Los auditores juegan otro papel ms amplio en los proyectos de sistemas. Cuando
existen cambios en proceso, existen riesgos no usuales porque los controles actuales
pueden ignorarse por conveniencia, porque los procedimientos estn en transicin, y
porque es probable que se intenten caminos ms cortos. Puede ser que se desmantele
parcialmente el sistema antiguo, pero que el nuevo no est todava implantado. El cambio
subsecuente al nuevo sistema puede significar que nunca se detecten errores o faltas
realizadas durante la transicin. Mediante una investigacin de sistemas, los auditores
internos deben estar alertas de actividades incorrectas y de errores causados por el
proyecto de sistemas o que estn ocultos por el proyecto.
Muchos auditores internos, desafortunadamente, no poseen un entendimiento
tcnico de sistemas de cmputo y no pueden contribuir a las investigaciones de sistemas
en las formas descritas. An ms, los grupos de desarrollo de sistemas pueden no
aminorar la participacin de auditores. Sin embargo, con frecuencia su participacin es
crtica en el xito de un nuevo sistema y deberan adquirir la experiencia necesaria.
CONTROL DE LA INVESTIGACION DE SISTEMAS.
Existen dos tipos principales de control de la investigacin de sistemas. El primero
consiste en el control administrativo general sobre todos los procesos del desarrollo de
sistemas, y el segundo est relacionado con el control de una investigacin de sistemas
especfica por medio de un sistema de control de proyectos. El comit directivo de
sistemas, que se estudiar es una combinacin de estos dos tipos de control.
Control administrativo del proceso de desarrollo de sistemas.
Los administradores de la organizacin deben controlar las actividades de todo
tipo para asegurarse de que las actividades sirvan a las necesidades de la organizacin.
Este control se conoce como control administrativo.
El control administrativo continuo sobre los sistemas de informacin, as como
sobre el desarrollo de sistemas, lo ejerce el gerente de sistemas de informacin, que
puede ser el gerente, director o vicepresidente de los servicios de procesamiento de datos
o sistemas de informacin. En el pasado, los gerentes de sistemas de informacin han
sido versados en tecnologa computacional pero no en mtodos administrativos ni de

control. Sin embargo, ahora que los sistemas de informacin computarizados se han
hecho ms complejos y que todas las reas de las organizaciones estn afectadas por
ellos, es necesario un gerente con experiencia en administracin general y control
administrativo como gerente de sistemas de informacin. Por cierto, el gerente de
sistemas debera tener todos los atributos de un buen gerente general, y estos atributos
administrativos son ms importantes que la experiencia tcnica del gerente.
La planeacin de sistemas tambin proporciona controles importantes sobre los
sistemas de informacin. La planeacin a largo plazo controla la direccin del desarrollo
de sistemas mediante el establecimiento del marco dentro del cual se desarrollan los
sistemas de informacin. Los presupuestos proporcionan las metas peridicas de
desempeo y un mecanismo de evaluacin de desempeo, que sirven como formas de
control. Los presupuestos de capital, que son una parte integral del plan general de
computacin, as como de una investigacin de sistemas particular, sirve como un control
sobre los gastos de capital para equipo.
Otra dimensin importante del control administrativo es el sistema que proporciona
informacin acerca de la utilizacin de la computadora al gerente de la misma, al
supervisor de dicho gerente y quiz al comit directivo de sistemas. Por lo general, estos
informes incluyen el control usual y la informacin del desempeo proporcionada en los
informes de presupuesto, informes de gastos de personal, e informes de adiestramiento.
Adems, es probable que los informes especializados contengan estadsticas de
desempeo en relacin con el estado de los proyectos de sistemas en proceso, al
porcentaje de utilizacin de los diversos componentes del equipo de cmputo, y al
porcentaje de tiempo muerto (el porcentaje de tiempo en que la computadora no est
operando).
La asignacin de los costos del procesamiento de datos a los usuarios con base
en el grado en que se usan los sistemas de informacin tambin constituyen un control
administrativo importante. Estos sistemas de asignacin de costos se conocen como
sistemas de cargo de costos. Finalmente, las auditorias, tanto internas como externas,
proporcionan a los administradores un control general sobre los sistemas de informacin.
Ambos tipos de auditores examinan los sistemas de informacin, evalan sus controles
internos y realizan auditoras detalladas de aplicaciones especficas de sistemas de
informacin.

494-501
El comit directivo de sistema
Una de las formas ms importantes de control administrativo proporcionan el comit
directivo de sistemas. En algunas organizaciones se le llama comit de computacin o
comit de procesamiento de datos o comit de planeacin de computacin. A dicho
comit se le otorga autoridad para establecer la direccin general de los sistemas de
informacin o bien en forma alternativa, su autoridad puede estar limitada a un proyecto
especfico de sistema
La razn para tal comit es el hecho de que como los sistemas de informacin
.afectan a toda la organizacin , todos los usuarios principales y los usuarios potenciales
deberan ayudar a dirigir los sistemas de informacin y participar en la asignacin de
recursos requeridos para el desarrollo de sistema. Dicho comit se asegura que las
necesidades de los usuarios de los sistemas de informacin dicten la organizacin y uso
del sistema de cmputo ;el personal de cmputo no debera tomar estas decisiones l
solo.
Los comits directivos de sistemas pueden organizarse, al principio, para un
proyecto importante de sistema. Despus, al reconocerse su utilidad para ese proyecto,
se convierten en permanentes, y su jurisdiccin se extiende a todas las actividades de
procesamiento de datos y futuros proyectos de sistema.
En la industria se estila mucho formar un comit directivo de sistemas y la
experiencia sugiere que las organizaciones con xito son las que tienden a utilizarlo con
mayor frecuencia. El concepto es anlogo al de un comit de administracin de una
organizacin, que por lo general se compone de los ejecutivos ms antiguos, el cual
determina la poltica general de una corporacin, revisa planes alargo plazo y toma las
decisiones principales sobre inversiones; sin embargo, este comit se limita a asuntos de
sistemas de informacin.
Propsito del comit directivo del sistema
Los propsitos del comit son:
1. Ayudar al gerente de sistema de computo en el desarrollo del planes a largo
plazo para los sistemas de informacin computarizados.

2. Asegura que las metas y objetivos del departamento de cmputo Sean

compatibles con los de toda la organizacin.
3. Revisar las propuestas de proyectos de nuevos sistemas y las revisiones de
los sistemas existentes.
4. Tomar las principales decisiones con respecto a la asignacin de recursos al
desarrollo de sistemas de cmputo, incluyendo decisiones para terminar
proyectos en proceso
5. Establecer el desarrollo de prioridades de proyectos de sistemas
6. Monitorear y controlar el desarrollo de sistemas de informacin en general, as
los principales proyectos de sistemas y realizar revisiones evaluaciones
cuando sean necesarias..
Estructura del comit de sistemas.
La lnea de autoridad y responsabilidad dentro del departamento de cmputo y entre el
gerente del departamento de cmputo y los administradores de niveles superiores

permanecen sin ningn cambio para los propsitos administrativos y de control, el comit
directivo de sistemas no participa en operaciones de rutina o en su control . Sin embargo,
la direccin general y las polticas del departamento de cmputo las establece este
comit, el cual tambin ejerce control administrativo y evala el progreso del desarrollo de
sistemas.
Membresa
Por lo general el comit tiene entre 6 y 15 miembros. Cada subunidad organizacional
principal ser o es potencialmente, un usuario principal de computadora, el cual est
representado en el comit por un administrador. El administrador del departamento de
cmputo es un miembro del comit y por lo general el jefe de ste es un miembro que
dirige al comit. Por lo general departamento de cmputo tambin se encuentra
representado por una o dos personas ms, quiz un especialista en computacin y el
asistente del administrador del departamento. El gerente de auditora interna de la
organizacin tambin es, casi siempre un miembro del comit.
Cuando no existen proyectos importantes en proceso, es comn que se realicen
juntas breves del comit, mensual o bimestralmente. Cuando existen proyectos
importantes en proceso, las juntas se realizan tan seguido como sea necesario para
evaluar el progreso del proyecto y proporcionar direccin
.
Fuerza de trabajo de los proyectos
Cada investigacin importante de sistema la toma un grupo al cual se conoce como
fuerza de trabajo del proyecto; sus miembros tiene habilidades especializadas necesarias
para el desarrollo del nuevo sistema. Por lo general la fuerza de trabajo del proyecto est
compuesta de personal que dedica todo o gran parte de sus tiempo a ese proyecto de
sistema hasta la finalizacin del proyecto o hasta que sean reasignados .Una fuerza de
trabajo de proyecto con frecuencia incluye administradores de organizaciones de usuarios
prestados para el proyecto, pero es tpico que la mayora de los miembros sea personal
profecional de sistema. La fuerza de trabajo del proyectos estn bajo la direccin diaria
del administrador del departamento de cmputo, pero la mxima responsabilidad para sus
actividades la tiene el comit directivo de sistema.
Beneficios de un comit directivo de sistema
Un comit as aborda el marco de desarrollo de sistemas, mantiene informada la alta
administracin de los muchos requerimientos de los sistemas de informacin y los
capacita acerca de la complejidad e importancia de los sistemas de informacin. Adems
el panorama global que slo los administradores poseen, se incluye en un proyecto de
sistema .Estos ayudan a dar direcciones a los proyectos y monitorean su proceso. Un
comit de sistema compuesto por este tipo de administradores tambin tiene lo necesario
para proporcionar soporto al personal de sistema que trabaja en cada proyecto

PLANEACIN DE SISTEMAS DE INFORMACION

Quiz la dimensin administrativa que ms que cualquiera otra distingue organizaciones
con xito de las que no tienen, es la calidad de planeacin realizada por los
administradores de las organizaciones. Es una lstima que en los departamentos de
cmputo la planeacin sea una actividad que se ha descuidado. Una razn de ello es que
los administradores de centro de cmputo no ha sido entrenado en los procesos de
planeacin. Otra razn es que l rea de computacin ha sido una parte especialmente

dinmica en la mayora de las organizaciones que padecen crisis casi continuas y

proyectos nuevos importantes en intervalos frecuentes. La razn anterior lleva a menudo
a que los administradores de estros centros digan: No tenemos tiempo de planear o
Nuestro medio es demasiado complejo y dinmico para que los planes sean tiles;
estaran obsoletos en 6 semanas . De hecho, la frecuencia de las crisis de procesamiento
de datos, de cambios tecnolgicos y de la investigacin de sistemas importantes para
realizar planeacin de los sistemas de cmputo; la planeacin ayuda a los
administradores a anticipar los efectos de estos factores y permite asignar los recursos de
tal forma que se moderen sus efectos.
Tambin existen otras razones para la importancia de la planeacin realizada por
grupos de sistemas de informacin. Una es la que la organizacin debe ganar experiencia
y hacer otro trabajo de base durante varios meses o aos para poder entender las
implicaciones de su nueva tecnologa, y esto casi siempre significa una asignacin de
recursos de personal mucho ms anticipada que los resultados de la nueva tecnologa.
Otra razn es que algunos proyectos principales de sistemas son a largo plazo por
naturaleza y deben iniciarse de 2 a 5 aos antes de que se espere que estn
completamente terminados. Por ejemplo, del desarrollo de una base de datos de una
organizacin debera realizarse 5 aos antes de cuando se espera est terminada; un
aspecto crtico de este desarrollo es la planeacin inicial que establece qu rea de
aplicacin se encontrarn envueltas en cualquiera de las base de datos. Sin la planeacin
por adelantado, que puede realizarse 2 o ms aos antes de terminar la primera base de
datos es probable para la organizacin que todo el proyecto sea una aventura sin xito.
Se necesitan tres tipos de planeacin en sistemas: a largo plazo, a corto plazo, y
uno de proyectos para cada investigacin de sistemas que tenga consecuencias. El plan a
largo plazo debe estar basado en, y derivado de, las metas y estrategias a largo plazo de
la organizacin. Como un ejemplo sencillo, suponga que una compaa est tratando de
doblar su volumen de ventas dentro de los prximos 5 aos (una meta) y espera realizar
esto principalmente mediante el establecimiento de sus primeras tiendas de venta de sus
productos (una estrategia). El departamento de cmputo debera conocer esta meta y
estrategia para poder planear el aumento de sus capacidad de procesamiento y poder
desarrollar estrategia para reunir y procesar datos transacciones de la nueva actividad de
venta. Por supuesto, el conjunto de metas y estrategias de una organizacin es en
realidad ms compleja que este ejemplo, y las metas y estrategias del rea de
computacin que se derivan de las de la organizacin corresponden de modo ms
complejo. Los miembros del comit directivo de sistemas han participado a fondo en la
planeacin a largo plazo de organizacin y son capaces de interpretar estos planes
correctamente, a fin de guiar las actividades de planeacin a largo plazo del grupo de
computacin., a fin de guiar las actividades de planeacin a largo plazo del grupo de
computacin.
El propsito del plan a largo plazo de los sistemas de cmputo es establecer cmo
se debe manejar a s mismo el departamento de cmputo en una posicin a largo plazo
que permita a sus sistemas ayudar en la forma ms efectiva a que toda la organizacin
alcance sus metas a largo plazo. Es tpico que el plan de sistemas a largo plazo sea de 3
a 5 aos y que sea ms detallado en los primeros aos que en los ltimos. Por lo general
el plan se alarga para agregar 1 ao cada ao, pero el departamento de cmputo debe
revisar cada ao todo el plan, en lugar de simplemente desarrollar uno nuevo para el ao
agregada.
Aunque est incompleta la figura 14.8 incluye mucho de los asuntos que deben
tratarse en el plan a largo plazo del departamento de cmputo. El anlisis de tecnologa
debera explicar cmo pueden usarse las computadoras, las comunicaciones y otras

tecnologas actuales y las futuras, a fin de aumentar la eficiencia de los sistemas de

informacin computarizados.
El personal y el reclutamiento, su retencin, y desarrollo, son la clave para los
sistemas de informacin computarizados con xito, y debera ponerse especial atencin a
esta seccin del plan a largo plazo. Con respecto al servicio a usuarios, los sistemas de
cmputo sirven a l organizacin dando servicio a los usuarios; por lo tanto, los que hacen
la planeacin deben enfocarse en que tambin y en que forma los usuarios estn siendo
atendidos, as como de que manera puede mejorarse el servicio actual. Aunque la
atencin a los usuarios es la razn de la existencia de los sistemas de cmputo en
muchos de estos departamentos se pone muy poca atencin a cmo atender mejor a los
usuarios.
Contenidos parciales de un plan de sistemas a largo plazo

fig. 14.8

1. Anlisis de tecnologa.
2. Personal
Perfil actual
Niveles puestos futuros y necesidades de experiencia
Programas esperados de entrenamiento y desarrollo
3. Niveles de servicio a usuarios:
Tipos actuales y niveles de servicio
Tipos separados y niveles de servicio
4. Configuracin de sistemas:
Configuracin actual
Configuracin futura esperada
5. Anlisis de proyectos de sistemas en proceso y programadas

La planeacin de configuracin de sistema incluye un anlisis del equipo actual y

sus ventajas y limitaciones. Tambin incluye la consideracin de que se esperen cambios
en el equipo durante el periodo del plan, dadas la tecnologa esperada y las metas con
respecto al servicio a usuarios.
Tambin debera proporcionarse en el plan un anlisis del estado de los principales
proyectos. Con frecuencia los principales proyectos nuevos propuestos se presentan
formalmente al comit directivo del sistemas como parte del plan a largo plazo, donde
pueden verse en el contexto de todo el sistema de informacin, tanto presente como
futuro. Es el plan a largo plazo, se hace explcito la cartera de proyectos de sistemas en
trminos de una combinacin de proyectos que equilibra los proyectos de alto y bajo
riesgo y de larga y corta duracin. La aprobacin del plan a largo plazo representa
entonces la aprobacin en principio de los proyectos individuales propuestos y de toda la
cartera del plan. Por supuesto, las circunstancias cambian, y debe prepararse y aprobarse
una proposicin detallada para cada proyecto en el momento apropiado para que algunos
proyectos aprobados en principio como parte de todo el plan se hacen posteriores. Sin
embargo, se propone un nuevo proyecto completamente fuera del marco del plan a largo
plazo, la suposicin del comit directivo de sistemas debe ser que el plan era inadecuado
o que el proyecto no tiene gran mrito.

Los propsitos del plan a corto plazo al que puede llamarse un plan de
presupuesto o un plan de utilidades, son establecer las asignaciones de recursos que
sern necesarias durante el siguiente periodo (por lo general un ao) y servir como
medio de control administrativo sobre los gastos. Este presupuesto es casi siempre, una
versin muy detallada del plan a largo plazo del departamento. Sin embargo, las
circunstancias y las filosofas de planeacin difieren, y en algunos casos un plan a corto
plazo es ms o menos independiente del primer ao del plan a largo plazo, por lo tanto,
las estrategias y gastos mostrados en los dos pueden diferirse. Es comn que el plazo se
prepare con base en meses o trimestres y a menudo, al terminar un trimestre, se agregue
otro para que el presupuesto siempre est adelantado un ao.
El tercer tipo de plan necesario, el de proyectos, difiere de modo significativo de
los otros dos tipos. Primero, aunque existe un plan detallado separado para cada
proyecto y se conoce como el plan de proyectos, tanto el de largo plazo como el de corto
plazo , incluyen a cada proyecto en forma general. Un plan de proyectos tambin difiere
de los planes a largo y corto plazos en cuanto a que no es un periodo, como un mes,
trimestre o ao como lo son los otros planes, sino que es por el tiempo esperado
requerido para la terminacin del proyecto. El plan de proyectos permanece vigente si el
proyecto no se terminado cuando se esperaba, pero se termina al terminar el proyecto, ya
sea adelantado, a tiempo, o atrasado.
SISTEMAS DE ADMINISTRACIN DE PROYECTOS.
Los planes de proyectos se desarrollan generalmente alrededor de un sistema de
administracin de proyectos, que es una combinacin especializada de un sistema de
planeacin de proyectos, y de uno de informacin de proyectos. Existen varios sistemas
de administracin de proyectos. Todos pueden ser tiles, se use o no un comit directivo
de sistemas. Cuando se usa uno de estos comits en conjunto con un sistema de
administracin de proyectos, los informes proporcionados por el sistema
de
administracin de proyectos son usados por el comit para conocer el progreso de
proyectos. Dos tipos comunes de sistemas de administracin de proyectos son las
grficas de barras PERT (tcnica de revisin y evaluacin de programas).
Grfica de barras
La figura 14.9 muestra una grfica de barras, quiz la forma ms sencilla de
administracin formal de proyectos. La grfica de barras (tambin conocida como
grfica de Gantt) se usa casi exclusivamente para propsitos de programacin y por
tanto slo controla el tiempo de los proyectos. En la figura la tarea (una parte de un
proyecto de sistemas particular) se programa para iniciarse a mediados de enero y
continuar hasta fines de febrero. La tarea 2 inicia al final de enero, antes de terminar la
tarea 1 , y contina hasta mediados de marzo. Despus de terminar la tarea 2, inicia la
tarea 3 de principios de abril y contina hasta julio. Las tareas 4 y 5 se realizan
simultneamente, se espera que la tarea 4 se termine alrededor del 1 de diciembre, y la
tarea 5 alrededor del 15 de diciembre.
Cuando se usa una grfica de barras como mtodo de control de proyectos, se
colocan puntos de revisin al terminar cada tarea (tambin pueden colocarse en medio
de las tareas). Estos puntos indican la terminacin de una tarea particular y son la base
para determinar si la tarea y el proyecto estn a tiempo segn lo programado; cuando se
llega a un punto de revisin, se verifican y evalan las tares que se han terminado, y todo
el proyecto. Los revisores se preguntan silos recursos asignados fueron utilizados en

forma correcta y si la tarea se termin en forma satisfactoria. Sin embargo, debido a que
la grfica de barras incorpora la medida de programacin de un proyecto, indica muy
brevemente que tareas deben terminarse antes de iniciar otras, y los costos de los
proyectos deben acumularse y evaluarse usando otros mtodos.
Tcnica de revisin y evaluacin de proyectos (PERT)
PERT puede ser, de modo indistinto, un sistema de administracin de costos o de tiempo;
PERT est constituido de eventos y actividades o tareas. Tiene varias ventajas sobre las
grficas de barras y es probable que se use con proyectos ms complejos. Una de sus
ventajas es que es un mtodo de programacin que tambin muestra en forma grfica
cules tareas deben terminarse antes de iniciar otras.
Tambin, al demostrar los diversos caminos de las tares, PERT permite el clculo
de una ruta crtica. Cada ruta o comino cosiste en combinaciones de tares que deben
terminarse. El tiempo y costo asociados con cada tarea de la ruta se calculan, y la ruta
que requiere la mayor cantidad de tiempo transcurrido es la ruta crtica. El clculo de la
ruta crtica permite a los administradores de proyectos monitorear ms cerca estas series
de tareas ms de cerca que a otras y modificar sus recursos si hay retrasos.
PERT controla tiempo y costos durante el proyecto y tambin facilita la
localizacin del balance correcto entre terminar un proyecto a tiempo y terminarlo dentro
del presupuesto. PERT reconoce que los proyectos son complejos, que algunas tareas
deben terminarse antes de comenzar otras, y que la manera correcta de manejar un
proyecto es definir y controlar cada tarea. Debido a que los proyectos generalmente se
atrasan PERT est diseado para facilitar la recuperacin de tiempo atrasado, asimismo
est basado en parte en la premisa de que la estimaciones subjetivas del tiempo total de
terminacin de un proyecto por lo general son inferiores a la suma de estimaciones
subjetivas para cada tarea.
PERT es una metodologa altamente desarrollada que tiene disponibles sus
descripciones detalladas. Hay muchas variaciones de PERT, algunas de las cuales estn
incorporadas en programas de software disponibles como sistemas de administracin de
proyectos computarizados, PERT se explica como mayor detalle en el apndice de este
capitulo.
RESUMEN ---------------------------------------------------------------------------------------------------Este capitul estudi la teora de investigacin de sistemas y el concepto de ciclo de vida
y su relacin con la investigacin de sistemas. Todos los sistemas de informacin deben
reemplazarse eventualmente, y por lo tanto las actividades de desarrollo de sistemas son
ms o menos continuas en compaas medianas y grandes. Los estudiantes deben
esperar que se les involucre en investigacin de sistemas en varias formas.
El problema de obtener la cooperacin completa de la gente es la preocupacin
ms crtica en el trabajo de sistemas, los usuarios, administradores y analistas de
sistemas pueden mostrar un comportamiento que inhiba el proyecto de sistemas. Si se
siguen varios principios de desarrollo de sistemas, pueden aliviarse los problemas con
personas ,y proporcionar la estructura necesaria para una investigacin de sistema y
aumentar en otras formas la probabilidad de que el resultado de una investigacin de
sistemas con xito. Estos principios constituyen una parte de la teora de desarrollo de
sistemas.
Los auditores juegan un papel importante en la investigacin de sistemas y
tambin es importante el control administrativo de la investigacin de sistemas. Los
comits directivos de sistemas, las actividades de planeacin del departamento de
cmputo y los sistemas de administracin de proyectos proporcionan las tres formas ms

importares de control administrativo de proyectos de sistema. Las grficas de barras y

PERT son tipos de sistemas de administracin de proyectos.
TERMINOS
CLAVE------------------------------------------------------------------------------------------------- Ciclo
de vida de un sistema; periodo que inicia con el anlisis de sistemas para un nuevo
sistema y se extiende durante su diseo, implantacin , y uso hasta que el sistema ya no
sea adecuado y se comience un nuevo anlisis de sistemas para reemplazarlo, por lo
general tiene duracin de varios aos.
Investigacin de sistema; proyecto de sistema para analizar, disear e implantar un
nuevo sistema de informacin o para modificar uno ya existente.
Comit directivo de sistema; comit de ejecutivos que tiene la responsabilidad general
de monitorear y controlar los sistemas de informacin de la organizacin.

502-509
Preguntas de repaso
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

14.

15.

16.

Qu es una investigacin de sistemas? Proporciones varios ejemplos de

investigacin de sistemas.
Explique el concepto de ciclo de vida se un sistema y su significado para la
investigacin de sistemas. El ciclo de vida de un sistema o el mismo periodo
durante el cual se realiza la investigacin de sistemas?
Cunto dura la fase de madurez y mantenimiento de un sistema? Cmo puede
extenderse?
Mencione el propsito de cada fase de una investigacin de sistemas
Cul es la diferencia entre un analista de sistemas y un programador?
Cmo pueden participar de modo amplio los graduados de la escuela de
administracin en la investigacin de sistemas? Cules son los principales
problemas de estos recin graduados con respecto a esta participacin?
En que forma pueden participar los administradores con experiencia en
investigacin de sistemas?
Qu papel o papeles pueden desempear los consultores en una investigacin
de sistemas?
Cules son las semejanzas y diferencias entre la investigacin de sistemas
grandes y pequeos?
Redibuje la figura 14.4 y b e incluya el costo de mantener el sistema.
Describa cada uno de los participantes en una investigacin de sistemas
Cules son algunas de las razones de porque a veces los empleados no
cooperan completamente en una investigacin de sistemas?
Jimmy Jones, un analista de sistemas, entrevist a Robert Clark acerca del
sistema que usan varios empleados del Sr. Clark, quien diseo el sistema hace
varios aos. El Sr. Jones dijo durante el anlisis: Es evidente que el sistema ya
no es til y necesita reemplazarse; tambin tendr que hablar con las personas
que estn usando el sistema, para llevar un registro de los problemas del
mismo, antes de disear uno nuevo .Despus, al hablar con un empleado el Sr.
Jones dijo: El nuevo sistema que voy a disear ser ms eficiente: slo
necesitar la mitad de las personas que necesita el sistema actual. Qu
errores cometi probablemente el Sr. Jones?
Qu significa cada una de las siguientes frases?
a) Involucramiento de la administracin en un proyecto de sistemas
b) Una cartera balanceada de proyectos de sistemas
c) Identificacin del problema correcto de sistemas
d) Una promesa temporal
e) Diseo macro y micro de sistemas
Para cada uno de los principios generales de investigacin de sistemas analizados
es este captulo, diga lo siguiente:
a) Su propsito y porqu es til
b) Cmo, si es posible hacerlo de alguna manera, se aplicaran en una
organizacin pequea de modo diferente de cmo se aplicaran en una
organizacin grande?
Cules son los papeles de los auditores internos de una investigacin de
sistemas? En qu cree usted que difieren de los papeles de los auditores
externos?

17.
18.
19.
20.
21.

Qu es un control administrativo sobre un sistema de informacin y cmo se

ejerce dicho control?
Por qu es tan crtico el control del sistema de informacin antiguo durante el
periodo de una investigacin de sistemas?
Cules son las ventajas de un comit directivo de sistemas? Ve algunas
desventajas? Cmo realiza una organizacin pequea los propsitos de un
comit directivo de sistemas?
Disee un sistema de planeacin para un departamento de sistemas de
informacin
Compare y contraste las grficas de barras y el PERT

PROBLEMA
Suponga que usted y un amigo han acordado las actividades de un da. Cada uno de
ustedes asistir a las clases separadas en la maana comenzando a las 8:00 a.m. (Cada
clase tiene duracin de 1 hora. Usted tiene 2 clases, y su amigo tiene slo una.) Despus,
ustedes deben estudiar durante 2 horas, y tambin planea comenzar un discurso , que
usted debe dar a las 4:00 p.m. Despus de clases su amigo debe podar el pasto de su
jardn; l estima que esta actividad le tomar alrededor de 3 horas. Despus planean
comer juntos a las 12 durante 1 hora; si usted llega tarde a comer, no lo atendern.
Despus de la comida continuar trabajando en su discurso y su amigo ir a clases
durante 2 horas ms. A las 3:00 p.m. l lo encontrar en la reunin de estudiantes en el
campus y escuchar su discurso en la junta semanal del Club de Veleros; es discurso
debe comenzar a las 3 p.m. en punto. Usted calcula que necesita 2 horas y media para
preparar su discurso. (Nota: Puede ser que usted desee leer el apndice antes de
comenzar este problema.)
1. Prepare un sistema PERT de las actividades combinadas de usted y su amigo.
2. Cul es la ruta crtica?
3. Cul actividad en la tarea crtica es ms probable que se retrase ms de lo
planeado? Qu recursos se asignarn a ella?
APNDICE
La figura 14.10 muestra un PERT muy sencillo. En la figura los nmeros en los crculos
indican nodos, o eventos terminados, y las letras indican tareas o actividades. Lo que se
nuestra en parntesis junto a cada letra es el nmero de das requeridos para terminar
esa tarea particular. La estructura del diagrama indica que las tareas A, B y C deben
terminarse antes de que ocurra el evento 3.Pueden obtenerse tres rutas de esa red de
PERT. La ruta 1 incluye las tareas A y E, la ruta 2 incluye las tareas B y D, y la ruta 3
incluye las tareas B, C y E. Unos clculos muy sencillo indican que la ruta 3 es la ruta
crtica porque la terminacin de las tareas B, C y E requiere un total de 20 das, esto es, 2
das ms que la ruta 1 y 5 das ms que la ruta 2. Para asegurarse que todo el proyecto
se termine en los 20 das programados, los administradores deben poner ms atencin a
las tareas B, C y E que a las dems. La terminacin del proyecto se muestra como el
evento 4.

FIGURA 14.10 Red de PERT

3

A (10 das)

B (7 das)

E (8 das)

C (5 das)

D (de 8das)

Rutas
1. Tareas A y E = 18 das
2. Tareas B y D = 15 das
3. Tareas B, C y E = 20 das
La ruta crtica es la ruta 3 que consiste en las tareas B, C y E
Si los administradores del proyecto desean terminar todo el proyecto en menos de 20
das, deben asignar ms recursos, como ms personal o personal ms especializado, a
las tareas B,C y E , Por ejemplo, si la tarea B puede terminarse en 5 das con el
reemplazo del personal que ahora est asignado a ella por personal con mayor
experiencia en esta tarea, todo el proyecto se terminara en 18 das. Con sta
reasignacin, las rutas 1 y 3 se convierten en rutas crticas, y amas deben monitorearse
para asegurarse de terminar el proyecto en 18 das.
PERT permite a los administradores del proyecto establecer un programa, observar el
progreso, y reasignar los recursos como sea necesario para mantenerse a tiempo a para
apresurar la terminacin del proyecto. PERT tiene otra dimensin interesante; puede ser
usado para valorar el funcionamiento del proyecto una vez que ste ha sido terminado.
La red de PERT es equivalente a un presupuesto porque a cada tarea se asignan das y
costos. Despus de la terminacin del proyecto o an despus de terminar cada tarea,
los tiempos y costos reales pueden compararse con los tiempos y costos presupuestados
en el PERT para determinar las diferencias de costo y tiempo . Las diferencias pueden
usarse para analizar desempeo y asignar responsabilidades por este desempeo o
para detrminar las formas por medio de las cuales pude mejorarse el desempeo
subsecuente.
Pasos en el desarrollo de un sistema PERT
Un proyecto PERT puede desarrollarse para uin proyecto siguiendo los pasos descritos a
continuacin:
1. Separe el proyecto en tareas o actividades lgicas. Asigne personal a cada
tarea.
2. Identifique las interdependencias entre estas tareas; esto es, determine cuales
tareas deben terminarse antes de que otras pueden iniciarse.
3. Usando estimaciones de ingeniera, consensos de opiniones u otras tcnicas,
determine el tiempo esperado para la terminacin ms eficiente de cada tarea,
por ejemplo, un tiempo de 5 das si se asignan dos personas . La terminacin

4.

5.
6.
7.

8.

9.

de la tarea se llama un evento, que es un crculo en la figura. Esta asignacin

de tiempo y tiempo total del personal se convierte, en efecto, en dos
estndares . Las diferencias pueden calcularse si el tiempo transcurrido real o
tiempo total de terminacin difiere de estos estndares.
Comenzando de izquierda a derecha , contruya una red similar a la que se
muestra en la figura. Construiya la red de tal forma que los eventos que deban
realizarse primero se coloquen a la izquierda, y estn conectados con aquellos
que les siguen.
Designe con un nmero a cada uno de los nodos de terminacin y con una
letra a cada una de las lneas de actividades; junto a cada letra; coloque el
tiempo total esperado para esa actividad (horas, dias o semanas).
Calcule la ruta crtica (esto es , el tiempo de terminacin ms corto posible)
segn se hayan hecho las asignaciones de recursos. Esta informacin es
importante para propsitos de control del proyecto.
Determine si el tiempo de terminacin de la ruta crtica es una fecha posible de
terminacin. Si esta fecha no es aceptable, asigne ms personal, personal
mejor calificado, o mejor o ms equipo, o planee apresurar laterminacin de
las tareas de la ruta crtica en otras formas (como el uso de transporte
areo).Tome en cuenta los costos adicionales, si los hay, para terminar el
proyecto ms pronto y determine si el tiempo ahorrado vale el costo adicional.
Observe las actividades la progresar el trabajo realizando informes regulares
en los puntos clave, que por lo general coinciden con las terminaciones de los
eventos, o nodos. Cuando sea posible, determine antes del tiempo esperado
de terminacin de una actividad si sta terminar a tiempo.
Reasigne los recursos si las tareas de la ruta crtica se atrasan y es esencial
que todo el proyecto se termine a tiempo. Una vez ms, evale los costos de
mantener el proyecto en el tiempo programado.

CASO 1
La Compaa ABC
Como respuesta de las crticas de varias reas de la compaa ABC, su controlador (a
quien reporta el gerente de procesamiento de datos) ha nombrado un comit directivo de
sistemas para establecer prioridades para el desarrollo de sistemas de informacin en
toda la organizacin y comprobar este desarrollo. Este comit est compuesto de los
miembros que se muestran a continuacin y tiene la autoridad de asegurarse de que el
gerente de procesamiento de datos haga que su grupo de conforme a las prioridades y
directivas del comit. Los equipos de proyectos estn encabezados por un analista de
sistemas y stos se nombrarn segn se inicien los proyectos. El comit directivo de
sistemas se reunir cada dos meses en forma rutinaria, y con mayor frecuencia si es
necesario.
Preguntas sobre el caso
1. Comente el cambio dado el comit directivo de sistemas
2. Cules son los propsitos de un comit directivo de sistemas?
3. Qu cambios organizacionales sugerira usted?

Comit directivo de sistemas de procesamiento de datos de la compaa ABC

Presidente: Auditor interno principal
Miembros: Contador principal
Dos asistentes tcnicos al gerente de procesamiento de datos
Supervisor de operaciones de computadora
Gerente de desarrollo de sistemas
Gerente de servicios de entrada y salida de procesamiento de datos
Director de beneficios para empleados

Equipo de
trabajo del
proyecto

Equipo de
trabajo del
proyecto

Equipo de
trabajo del
proyecto

4. Qu cambios de personal sugerira usted?

5. Cmo debera articularse los componentes?
6. Comente acerca de la frecuencia de las juntas y cmo debera distribuirse el tiempo
de las mismas.
7. Debera estar a cargo de un equipo de un proyecto un representante de los
usuarios?
8. Existe algn conflicto de intereses evidente?
CASO 2
El comit de revisin de sistemas en la Inland Steel
Por John R. Lanahan
Un comit dirige la funcin de sistemas de inland del cual juega un papel importante en
nuestra actividad. A este comit se le llama comit de revisin de sistemas, Los...
miembros son:
V.P. de finanzas
V.P. manufacturacin de acero
Contralor
V.P. estrategia corporativa
V.P. senitor
Pres. de J.T. Ryerson (Una bodega subsidiaria)
V.P. Ventas
Creemos que el trabajo de este comit, representando las cabezas de todos nuestros
usuarios o clientes internos, ha sido la piedra angular del desarrollo e instalacin de
sistemas que sostienen con eficacia las operaciones principales del negocio. El comit se
rene 3 veces al ao como mnimo.
La primera junta tiene como propsito analizar los problemas reales que tienen lass
operaciones de sistemas y de procesamiento de datos. Las materias de estudio han sido
el conflicto entre terminales interactivas y seguridad, la necesidad de una funcin de
auditora de procesamiento de datos, y alternativas de expansin del CPU.

En el primer caso se explic al comit como la introduccin de terminales interacyivas

eran una amenaza potencial para la seguridad de los datos y la integridad de sistemas
fiduciarios al mismo tiempo que ofrecian ventajas de costos y aplicaciones de sistemas
ms efectivas. El punto fue tratado con el consejo de directivos, quienes concluyeron que
las ventajas de costos y plicaciones valan la pena de tomar el riesgo. En forma
subsecuente, se estableci una funcin de auditora de procesamiento de datos para
asegurarse que los sistemas fiduciarios tuvieran controles correctos dentro de ellos y que
estaban implantados correctamente.
La segunda junta permite una reiteracin anual del plan a 5 aos, cubriendo aplicaciones,
fuerza de trabajo, y harware. La tercera junta es para finalizar el plan anual y hacer el
presupuesto para el siguiente ao.
No debera suponerse que las funciones del comit son nominales, o estereotipadas. Tres
de los 7 miembros son ingenieros que tienen experiencia directa con computadoras, y los
7 han tenido entrenamiento local y externo en computadoras y sus aplicaciones. Toman
desiciones reales acerca de problemas y estudian vigorosamente los proyectos que van a
realizarse y los recursos que cada uno de ellos requiere. Como representan ala consorcio
de jefes de departamentos, su aprobacin en su etapa favorable para el desarrollo e
implantacin.
Preguntas sobre el caso
1. Evale el comit de revisin de sistemas de la inland steel
2. Qu cambios, si acaso, recomendara usted y por qu?

CASO 3
Fruehauf Corporation
La estructura estndar de los proyectos de Fruehauf se describe en su manual, que tiene
ms de 200 pginas. Un proyecto de sistemas esta dividido en las siguientes 12 fases, y a
su vez cada fase est dividida en un nmero definido de tareas...
Fase de desarrollo
A. Planeacin
1. Investigacin inicial (3 tareas; 2 a 6 horas hombre)
2. Estudio preliminar (10 tareas; mximo 3 semanas hombre)
3. Planeacin del sistema (15 tareas; 2 semanas hombre a 2 meses hombre)
B. Desarrollo
4. Requerimientos del sistema (28 tareas)
5. Diseo del sistema (11 tareas)
6. Especficaciones de los programas (12 tareas, 6 repetidas para cada
programa)
7. Planeacin de conversin (10 tareas)
8. Programacin (12 tareas, 5 repetidas para cada programa)
9. Entrenamiento a usuarios (11 tareas)
10. Prueba del sistema (11 tareas)
C. Implantacin
11. Conversin (13 tareas)

12. Post implantacin (10 taareas)

Deben notarse varios puntos. Cada proyecto de ataca con sumo cuidado a l. La
investigacin inicial (fase 1) simplemente revisa la propuesta con brevedad , determina si
requiere estudio posterior, y determina si est involucrado un nuevo sistema de aplicacin
o una modificacin al sistema existente. El director de administracin de sistemas de
informacin puede autorizar la realizacin del trabajo en la fase 1, y si la recomendacin
es seguir con la fase 2, puede autorizar el trabajo en la fase 2; que trata con la creacin
de una descripcin general del nuevo sistema propuesto, as como del plan y presupuesto
para la siguiente fase.
Al final de la fase 2 se enva la propuesta la comit directivo de sistemas para que la
revise y apruebe para continuar. En este punto se ha dedicado un mximo de 3 semanas
hombre, y elgasto no ser demasiado si el comit directivo de sistemas decide terminar el
proyecto o asignarle una prioridad inferior.
La fase 3 trata de una investigacin detallada del sistema existente, si se tiene, y una
definicin del sistemaen trminos de archivos, entradas, salidas y controles. El sistema
propuesto tambin se define lo ms posible, en los mismos trminos. Esta fase marca en
realidad el incio del proyecto, y el personal del departamento de usuarios esta muy
involucrado en ella . Por lo general se requieren entre 2 semanas y 2 meses hombre para
ello. Al final de la fase 3, el comit directivo de sistemas revisa el proyecto una vez ms y
debe dar su aprobacin para continuar con la fase 4. En este momento se presenta para
ser aprobado un plan y una programacin para el balance del proyecto.
Debe mencionarse que el manual de estndares de la Fruehauf define la ducumentacin
estndar que debe prepararse durante cada fase. Esta documentacin debe terminarse
antes de que el comit directivo revise el proyecto. Si la documentacin no esta completa,
la fase no se ha terminado.
La fase 4 trata la definicin detallada de los requrimientos de los sistemas, sobre todo
desde el punto de vista de los usuarios. El comit directivo de sistemas revisa el proyecto
una vez ms al final de esta fase. Si el comit aprueba la continuacin del proyecto, esta
aprobacin cubre las siguientes 3 fases, hasta la planeacin d ela conversin.
El siguiente punto de revisin del comit directivo de sistemas (despus de la fase 7) est
al final de la fase 10, cuando se ha terminado la prueba del sistema. El comit determina
si debe o no iniciarse la conversin del sistema. Finalmente, el comit realiza la revisin
despus de la implantacin para evaluar el xito del ptoyecto.
Por tanto el comit revisa cada proyecto despus de las fases 2, 3, 4, 7 y 10, y determina
si debe continuarse, terminarse, o modificarse. La gente de Touche Ross llama a este el
concepto de promesa temporal.
Adems de esta estructura estndar, Fruehauf usa un sistema de control de proyectos
que usa horas-hombre estimadas para cada tarea en cada fase, y registra las horas
hombre reales contra las estimadas. Suponen que no necesitan PERT ni CPM, ya que la
mayora de los proyectos de sistemas tienen un patrn de actividades estndar bastante
sencillo.
Cuando cambiaron primero a esta estructura de estndar de proyectos, Fruehauf no se
regres y cre la documentacin estndar para todas las fases de los proyectos que ya
tenan iniciadas. En cambio, hicieron que cada proyecto cambiara a la documentacin y
procedimientos de revisin estndar, comenzando cada uno se encontraba.
La alta administracin de Fruehauf est satisfecha con el control administrativo que ahora
tienen sobre sus proyectos de procesamiento de datos. No slo estn trabajando en
proyectos de mayor reto sino que tambin se sienten seguros de esta evitando problemas
y gastos en los que hubieran incurrido bajo sus antiguos mtodos. La nueva metodologa,

tan pronto fue instalada, comenz a destacar las cosas que necesitaban atencin, y por
tanto los problemas se corrigieron cuando aran an de pequea magnitud.
Preguntas
1. De que manera es similar la forma de Fruehauf, y diferente de la sugerida en este
captulo?
2. Qu beneficios se obtienen de la estructura de proyectos de Fruehauf?
3. Hubiera sido tan efectivo si se hubiera eliminado el comit directivo de sistemas?
Porqu?
Consejo de directores

Director general

Comunicacin
corporativa

Vicedirector
general

Presidente

Vicepresidente
senior

Vicepresidente
Administrativo
de grupo

Secretaria
del presidente

Ventas

Investigacin

Manufacturacin
de acero

Compras

Materias
primas

Estrategia
Corporativa

Finanzas

Secretario

Tesorero

Trfico

FIGURA 14.11 Comit de revisin de sistemas: puestos en la empresa de Inland Steel

Ayudante al
vecepresidente
de finanzas

Relaciones
industriales

Controlador

510-517
CAPITULO 15
LAS FASES DE ESTUDIO PRELIMINAR Y ANALISIS DE SISTEMAS.
CONCEPTO BASICO.
El primer error importante que puede ocurrir ( y con frecuencia ocurre) durante una
investigacin de sistemas es la determinacin incorrecta del problema que debe resolver
un nuevo sistema. Si no se pone mucho cuidado para definir el problema correctamente,
puede ser que toda la investigacin de sistemas est mal dirigida. Por tanto, debe
dedicarse todo el esfuerzo que sea necesario a esta tarea.
OBJETIVOS DEL CAPITULO.
1.- Proporcionar una perspectiva de la naturaleza de la investigacin de sistemas.
2.- Explicar la naturaleza de las fases de estudio preliminar y anlisis de sistemas y las
herramientas y tcnicas usadas durante estas fases.
INTRODUCCION
Este captulo comienza el estudio de las actividades que comprenden las distintas fases
de una investigacin de sistemas. Las fases de estudio preliminar y de anlisis de
sistemas son similares en objetivos y mtodos. Para los propsitos de este estudio, la
fase de estudio preliminar est separada de la investigacin de sistemas, aunque algunas
veces se le describe como una parte de la de anlisis de sistemas. Durante la fase de
estudio preliminar se determina si el problema de sistemas que se ha descubierto es tan
serio como para ameritar los gastos de una cantidad significativa de recursos para la
continuacin de la investigacin de sistemas. A su ves, el propsito del anlisis de
sistemas es establecer en detalle las especificaciones de un nuevo sistema de
informacin propuesto o la modificacin de uno ya existente. Estas especificaciones
deben dejar bien claro lo que tiene que realizar el nuevo sistema de informacin
propuesto o la modificacin de uno ya existente. Estas especificaciones deben dejar bien
claro lo que tiene que realizar el nuevo sistema, pero no cmo se realizar. Cmo el
nuevo sistema realizar el procesamiento, se determina durante la fase de diseo del
sistema.
Con frecuencia se describe a las actividades de investigacin de sistemas como anlisis
de diseo de sistemas. Sin embargo, la descripcin es demasiado limitada en cuanto a
que el anlisis de sistemas y el diseo de sistemas slo son dos fases de toda la
investigacin. El trmino proyecto de desarrollo de sistemas es equivalente al trmino
investigacin de sistemas, ya que desarrollo de sistemas describe una serie de
proyectos individuales de investigacin de sistemas que, conjuntamente, conforman el
desarrollo de un sistema de informacin durante un largo periodo.
Los procedimientos generales y la forma de abordar el problema, descritos en este
captulo y los captulos subsecuentes, son vlidos para todas las investigaciones de

sistemas. Sin embargo, los procesos formales detallados de la investigacin que se

describen aqu se utilizan con mayor frecuencia para investigaciones grandes de
sistemas. Los proyectos ms pequeos son menos formales y detallados aunque debera
aplicarse el mismo anlisis general, casi siempre se realizan con menor profundidad y
pueden ser mucho menos estructurados. La cantidad de recursos dedicacos a la
investigacin de sistemas debe adecuarse al tamao del proyecto para que las
investigaciones ms pequeas de sistemas puedan realizarse ms econmicamente.
En este captulo y en los de diseo e implantacin de sistemas, se presenta un ejemplo
sencillo de la compaa Abercrombie.
LA NATURALEZA DEL ANALISIS DE SISTEMAS.
Las actividades de anlisis de sistemas son muy diferentes de las actividades en el diseo
e implantacin de sistemas de informacin. De todas las actividades de investigacin de
sistemas, las actividades del anlisis son por mucho las ms orientadas a las personas y
las menos estructuradas. Las actividades de anlisis tienen varias caractersticas
distintivas:
1) Implican la determinacin de lo que un sistema debera hacer, lo cual se relaciona con
el futuro y es, en parte, una cuestin de opinin y no de hechos.
2) Implican negociaciones extensas, ya que cada miembro de una comunidad de
usuarios tiene una opinin, y aun durante la fase de anlisis debe llegarse a un
acuerdo acerca de la naturaleza del problema, as como de lo que debera realizar un
nuevo sistema. Un analista de sistemas debe ser demasiado sensitivo a las personas
y debe poseer una abundancia de habilidades diplomticas, as como tipos
especficos de experiencia tcnica. Las relaciones interpersonales en un anlisis de
sistemas son complejas, y con frecuencia se encuentra la hostilidad, a veces creada
por el mismo analista.
3) Compromiso es un hecho de la vida en un anlisis de sistemas, con frecuencia los
compromisos son tan amplios que aunque el analista haya realizado un trabajo
superior, nadie est contento con los resultados.
4) Las estimaciones en lugar de las medidas precisas son la orden del da en el trabajo
de anlisis. Se estiman los costos, los requerimientos de memoria de computadora,
las cargas futuras de procesamiento, las mezclas de tipos de transacciones, incluso
los requerimientos de trabajo diario para la terminacin del proyecto.
Desafortunadamente, no hay ningn curso en la vida del estudiante que le ayude a
obtener experiencia en las estimaciones.
5) Finalmente, gran cantidad de la actividad de anlisis est orientada hacia la
prevencin del fracaso, en lugar de enfocarla a lograr el xito. No es tan importante,
por ejemplo, encontrar el mejor conjunto de especificaciones de sistemas como lo es
definir el problema y desarrollar las especificaciones de los sistemas de tal forma que
aseguren que ni la investigacin ni el sistema resultante sean un fracaso. Es ms
importante evitar todos los errores crticos de la fase de anlisis que hacer todo lo
dems totalmente bien. Un error crtico, como no definir correctamente el problema, no
consultar al principal usuario del sistema, o subestimar la capacidad necesaria en el
sistema, puede causar que todo el proyecto sea un desastre, sin imputar qu tan bien
se realicen las otras actividades. La mayora de los fracasos de los proyectos de
sistemas estn causados por errores cometidos durante la fase de anlisis.

Puede verse que el entrenamiento tcnico en sistemas de informacin slo es una parte
de la experiencia requerida en los analistas. Son ms importantes la habilidad de tratar
con las personas (incluyendo saber cmo negociar), las ganas de aceptar un compromiso,
y un conocimiento de los errores crticos que deben evitarse. Tambin es importante un
entendimiento de la organizacin y de su industria, especialmente de las funciones que se
estn analizando. Aunque hasta cierto punto todo esto puede aprenderse en un curso, el
mejor entrenamiento consiste en experiencia de trabajo con otros analistas de sistemas.
ANALISIS ESTRUCTURADO.
Los conceptos interrelacionados de anlisis estructurado, diseo estructurado, y
programacin estructurada, se emplean ampliamente en la investigacin de sistemas.
Para los propsitos de este captulo, el anlisis estructurado es una forma de anlisis de
sistemas que se basa en la particin efectiva del producto final de la fase de anlisis de
sistemas: las especificaciones de los requerimientos de los sistemas. Las
especificaciones de los requerimientos de los sistemas se formulan con anlisis
estructurado como una serie de mdulos en lugar de un conjunto monoltico de
especificaciones.
Los propsitos de esta modularizacin son tres. Primero, cada analista de un equipo de
proyecto puede trabajar por separado y eficientemente en mdulos diferentes. Segundo,
todos los participantes pueden entender mejor los mdulos estructurados. Tercero, y ms
importante, es el hecho de que la modularizacin permite la revisin separada y rpida de
cada aspecto de las especificaciones del sistema. Por un lado, los sistemas se desarrollan
en un ambiente dinmico, y nuevos desarrollos en el medio, as como el descubrimiento
de nueva informacin durante una investigacin de sistemas, ambos durante y despus
de la fase de anlisis, sugieren con frecuencia que deberan cambiarse las
especificaciones de los sistemas. Por otro lado, los analistas siempre han credo que es
imperativo congelar (dejar de cambiar) las especificaciones de los sistemas (y
posteriormente el diseo) desde el principio ya que los cambios posteriores son difciles
de implantar, en un documento monoltico de especificaciones de sistemas, e introducir
mayor complejidad, incertidumbre, y retraso en la investigacin de sistemas. El anlisis
estructurado trata de acomodar estas dos necesidades conflictivas. Slo se tiene que
cambiar un mdulo cuando cambian las especificaciones, y esto puede hacerse ms
rpido debido a la modularizacin. Al mismo tiempo, la mayora de las especificaciones de
sistemas pueden permanecer congeladas, lo cual minimiza el caos que se crea cuando se
realiza un cambio.
CLASES DE INVESTIGACION DE SISTEMAS.
Existen tres tipos de Investigaciones de Sistemas.
1) Proyectos que implican la adquisicin de equipo hardware nuevo.
2) Proyectos que implican un software para sistemas de procesamiento
transacciones.

de

3) Proyectos que implican el desarrollo de sistemas de informacin para administradores,

tambin orientados hacia el software.
Adems, los proyectos que implican el software pueden tratar el desarrollo de nuevos
programas, modificacin de programas existentes, o compras de nuevos programas.
Muchas investigaciones de sistemas implican tanto el hardware como el software. Los
principios de investigaciones de sistemas son casi los mismos para cada uno de los tres
tipos de investigaciones de sistemas, pero la experiencia requerida por los analistas y
otros participantes en la investigacin de sistemas pueden ser uy diferentes para cada
tipo.
Proyectos de hardware
Este tipo de proyectos requiere la evaluacin de componentes, de alternativas de
hardware de computadoras y de los diferentes proveedores que lo proporcional. El
hardware de computadoras debe compararse en trminos de capacidad, de lo que es
capaz de realizar, su confiabilidad, costo, y compatibilidad. Lo que puede realizar tiene
que ver con s el hardware puede realizar las tareas que se desean. La capacidad del
hardware se mide en trminos del nmero de transacciones que pueden procesarse en un
periodo dado.
La confiabilidad es la frecuencia de fallas mecnicas o electrnicas, incluyendo daos por
calor, agua, fuego y abuso fsico. En trminos de costo, deben valorarse los costos
originales, de mantenimiento y operativos. Los costos operativos incluyen costos de mano
de obra y de utilidades, los componentes del hardware requieren energa elctrica, aire
acondicionado y algunas otras consideraciones especiales.
Cuando se evalan los componentes del hardware, deben considerarse su compatibilidad
con otros componentes y sistemas de software existentes. La compatibilidad con otros
componentes y sistemas de software existentes. La compatibilidad del hardware significa
que los componentes deben interconectarse, si despus de la interconexin continan
funcionando correctamente, son compatibles. En forma ideal, se busca el 100% de
compatibilidad de componentes existentes con componentes nuevos ( a los que se llama
compatibilidad de conexin) y de programas existentes con programas nuevos. En la
prctica, la compatibilidad del 100% puede no ser posible.
Tambin deben preocuparse por la obsolescencia de la tecnologa y la vida til. Con
frecuencia los analistas de sistemas consideran los cambios entre adquirir equipo que
rene la tecnologa ms avanzada, pero que puede no ser del todo compatible con el
sistema existente, y la adquisicin de equipo que use tecnologa compatible, pero que
ser obsoleto en un periodo ms corto. Aunque el hardware puede hacerse obsoleto
antes de terminar su vida til, la longitud de vida fsica es importante, en general, los
componentes enteramente electrnicos tienen una vida til indefinida, pero pueden
daarse o destruirse sin darse cuenta. Sin embargo, es comn que los componentes
mecnicos o electrnicos a los electromecnicos o mecnicos.

El hardware debe instalarse y con frecuencia el lugar debe modificarse para poder
acomodar el equipo nuevo. Los cambios necesarios pueden incluir la instalacin de un
piso nuevo, un sistema especial contra incendios y sistemas sofisticados de control de
humedad y temperatura. Pueden requerirse fuentes de poder auxiliares para garantizar
energa constante. Mientas que algunos componentes retienen datos en su memoria si la
fuente de poder se interrumpe temporalmente, otros no, por lo consiguiente, datos
valiosos pueden perderse si se interrumpe momentneamente la energa. Las
capacidades de respaldo e inicio son importantes, estas permiten al equipo respaldar y
reprocesar los datos que se estaban procesando cuando ocurri la falta de energa o
cuando otra causa interrumpi el procesamiento.
La seleccin del hardware requiere analistas y tcnicos de hardware capaces. A menudo,
los especialistas que realizan esta parte de la investigacin de sistemas son ingenieros
electrnicos o gente que han terminado programas de ciencias computacionales. Con
mucha frecuencia la seleccin del hardware no es una actividad continua de desarrollo de
sistemas, y la seleccin de componentes principales se realiza con poca frecuencia. Por
esta razn, una organizacin puede preferir confiar mejor en consultores externos en
lugar de incurrir en el gasto de emplear especialistas en evaluacin del hardware.
Proyectos de software.
En general las investigaciones de sistemas que involucran software se concentran en una
de tres actividades generales: 1) adquisicin de paquetes de software preescritos, 2)
desarrollo y programacin de nuevas aplicaciones o programas de sistemas, o 3)
mantenimiento (revisin) de programas de aplicaciones computarizadas ya existentes.
Es ms probable que las organizaciones pequeas compren sus programas listos para
usarse, y es ms probable que las organizaciones grandes desarrollen sus propios
programas, aunque por parte de compaas grandes existen una tendencia creciente
hacia la compra de programas.
Cualquiera de los tres tipos de investigaciones de software que se realice, es probable
que requiera un anlisis de sistemas para determinar la naturaleza de los programas
necesarios. Por lo general, un analista de sistemas rene la informacin necesaria para
que sirva como base para el esfuerzo de programacin o para determinar qu paquetes
de software deberan adquirirse.
El desarrollo de los programas nuevos y la revisin de los antiguos son actividades
continuas en la mayora de las instalaciones de procesamiento de datos de cierto tamao.
Por cierto, estas actividades representan uno de los costos principales de estos centros
de procesamiento de datos, ya que los costos de programacin pueden exceder hasta en
50% los costos totales de procesamiento de datos. Vale la pena que los administradores
pongan especial atencin a estas actividades, para asegurar que la programacin se
realice con eficacia y eficiencia y que los proyectos de programacin se controlen con
todo cuidado.
El desarrollo total de nuevos programas y la revisin de los antiguos son actividades
similares. En una organizacin grande y madura de procesamiento de datos cerca del
70% del esfuerzo total de programacin se dedica, en general al mantenimiento de

programas existentes. Para un programa nuevo se usan procedimientos elaborados para

asegurarse que el programa no tenga

Situaciones de procesamiento incorrecto que necesitan cambios en programas

(mantenimiento correctivo)
1) no se dejo al programa libre de errores por completo lo cual causa un proceso
incorrecto. (pueden pasar meses hasta descubrir todos los errores).
2) Un cambio anterior en el programa introdujo errores lgicos inesperados en el
programa.
3) Se descubren debilidades en el control en los programas que permiten acceso no
autorizado a los archivos de datos.
4) No puede establecerse una auditoria porque un programa no registra el
procesamiento que realiza
Errores y que se localicen todos los errores en el programa, que no se incorporen
instrucciones n autorizadas en l y que ste opere con eficiencia. Para un programa que
se est revisando, deben usarse los procedimientos igualmente elaborados para
asegurarse que los cambios realizados fueron autorizados y que el programa revisado se
ha probado y est libre de errores. Sin embargo, un sistema de administracin formal,
como PERT, es ms probable que se use para proyectos formados por revisiones de
antiguos, ya que tienden a ser ms grandes, ms complejos y menos rutinarios que los
otros.
El mantenimiento de programas se requiere por una de tres razones generales: los
programas actuales requieren correcciones porque no procesan correctamente
(mantenimiento correctivo), deben modificarse para conformarse a un medio modificado
(mantenimiento adaptativo), o pueden proporcionar mayores beneficios si se le realizan
mejoras (mantenimiento de perfeccin). En la figura 15.1 se listan situaciones tpicas que
necesitan mantenimiento correctivo y en la figura 15.2 se encuentran ejemplos de razones
para realizar mantenimiento adaptativo.
Los mantenimientos correctivo y adaptativo comparten, en general, la caracterstica de
que se requieren estos cambios en los programas y con frecuencia deben realizarse de
acuerdo con fechas lmites impuestas externamente. No

Cambios en el ambiente que necesitan cambios en programas (mantenimiento

adaptativo)
1)
2)
3)
4)

se emplean nuevas reglas de contabilidad, tales como cambiar de LIFO a FIFO

Cambia la legislacin de pago de impuestos.
Se requieren nuevos informes regulatorios.
Nuevos problemas operativos o cambios en el sistema de control administrativo
requieren nuevos tipos de informacin.

5) Se adquiere o vende una subsidiaria.

6) Cambios en contratos con los sindicatos alteran la contabilidad del fondo de
pensiones.
7) Una reorganizacin interna cambia la jerarqua de la organizacin, y deben
redisearse los informes.

Situaciones que involucran mayores beneficios y llevan a cambios en programas

(mantenimiento de perfeccin)
1) Una estructura de archivos actual se redisea para aumentar la eficiencia de
procesamiento.
2) Los archivos se mezclan para eliminar la necesidad de transferir archivos y
procesamiento intermedio.
3) Cambios en el programa permitirn al programa procesar en menor tiempo.
4) Un nuevo vicepresidente pide cambios en los informes peridicos.
5) Los gerentes captan las formas en que pueden usar informacin adicional que puede
incorporarse a los informes actuales.

Se realiza en forma ordinaria ningn anlisis de costo-beneficio para determinar si se

procede con el mantenimiento correctivo o adaptativo.
El tercer tipo de mantenimiento, el de perfeccin, trata de mejorar la eficiencia del sistema
o sus beneficios a los usuarios. En la figura 15.e se muestran ejemplos de situaciones que
llevan a la realizacin de mantenimiento de perfeccin, el cual no es requerido y puede
diferirse si no existen recursos disponibles para realizar estos cambios. Por lo general, los
costos y beneficios relativos de estos cambios propuestos se evalan. Sin embargo, si un
cambio propuesto no consume mucho tiempo, puede realizarse sin antes realizar anlisis
limitado. Sin embargo, aun en un caso as, debe usarse controles normales en cambios
de programas, incluyendo la aprobacin anterior, dejar al programa completamente sin
errores, y la aceptacin formal despus de su terminacin. Muchas actividades de
mantenimiento de programas tambin incluyen cambios en los archivos de datos.
Considere, por ejemplo, el efecto del articulo 2 de la figura 15.2 en una organizacin que
realiza operaciones en una docena de estados. Debido a que cada estado tiene diferentes
leyes impositivas para una nomina, los archivos de nominas para cada estado se
organizaran en forma diferente, y la organizacin tendr una docena de conjuntos de
programas de nomina con pequeas diferencias entre si. Es muy probable que las
regulaciones de impuestos en nominas de cada estado cambien varias veces en un ao y
por tanto, los archivos de nominas, y los programas de nominas para cada archivo, deben
alternarse, cada cambio en el archivo puede requerir la revisin de varios programas. Los
cambios requeridos en programas de nominas pueden ser mas de 100 por ao y podran
mantener ocupado a un especialista en programacin de nominas casi por tiempo
completo a perpetuidad.

Considere el caso 5 de la figura 15.3. si un administrador decide incluir en un informe

peridico informacin acerca del tiempo estimado de llegada de pedidos de compras que
no esta en los archivos, un analista tendr que consultar primero con el administrador
para establecer con precisin que informacin acerca de los tiempos de llegada de los
pedidos de compras debe repor-

518-525
tarse y en qu forma. Despus, un diseador de sistemas debe revisar el archivo de
pedidos de compras o disear un archivo separado de pedidos de compras y pedidos
atrasados. Finalmente deben cambiarse los programas que procesan el archivo de
pedidos de compras para obtener la informacin deseada del archivo existente o de un
nuevo archivo de pedidos atrasados, e incorporar esto en el reporte.
PROYECTOS DE SISTEMAS DE INFORMACION GERENCIAL
Mientras que los proyectos de sistemas de informacin gerencial en general conllevan
esfuerzo de programacin, los aspectos de no programacin se convierten relativamente
en problemas ms complejos y crticos, hasta el punto en que todo el carcter de estos
proyectos es diferente del de los proyectos de sistemas de procesamiento de
transacciones. El desarrollo de sistemas gerencial se enfoca mucho mas al anlisis de las
actividades administrativas que al diseo y desarrollo de programas de computo. En
forma comparativa, el anlisis de actividades de operaciones suele consistir en un estudio
directo de las operaciones y en una optimizacin del flujo de las transacciones a travs
del sistema. La mayora de los programadores y analistas de sistemas son capaces de
realizar anlisis de operaciones.
Por otro lado, los analistas que tratan con sistemas administrativos deben
entender, tanto las actividades administrativas, como los procesos de toma de decisiones.
Asimismo, su perspectiva de los sistemas de informacin debe ser bastante amplia como
para incluir mucho mas que la tecnologa computacional. La creacin de sistemas
administrativos puede requerir la mezcla cuidadosa de informacin proveniente de varias
fuentes, incluyendo tanto fuentes de computadora como de no computadora en un solo
sistema. La figura 15.4 demuestra que el entendimiento de los procesos administrativos
es el ingrediente critico para el desarrollo del SIG y que, adems de la experiencia
relacionada

Procesos
administrativos
Sistemas de
computo

Habilidades de
tipo personal
Herramientas
de anlisis

Habilidades de
tipo personal

a)Experiencia para sistemas

de informacin de
operaciones

FIGURA 15.4
Requerimientos de
conocimientos y habilidades
de un analista de sistemas

Sistemas de
computo

Sistemas de
informacin
Herramientas
para la
de anlisis
administracin

b)Experiencia para sistemas

de informacin para la
administracin

con las computadoras, se requiere un conocimiento ms general de sistemas de

informacin. En la figura 15.4b, los sectores de la grfica con lneas fuertes representan
las habilidades especialmente criticas para el anlisis de proyectos de sistemas

administrativos. Debido a que es muy importante un conocimiento de los procesos

administrativos y del sistema de informacin administrativo, los proyectos de SIG emplean
con frecuencia a los analistas entrenados como administradores en lugar de analistas
cuya educacin es de disciplinas tcnicas. Como se sugiere en ambas partes de la figura,
las habilidades personales, las herramientas de anlisis, y algn conocimiento sobre
computadoras son importantes para todos los analistas, sin importar que tipo de proyecto
se este realizando.
Aunque diferentes tipos de investigacin de sistemas requieren diferentes tipos de
experiencia, los principios son casi los mismos para cada uno. Los estudios subsiguientes
sobre los diferentes tipos de investigacin de sistemas no tomaran en cuenta los
diferentes tipos de experiencia requerida para diferentes tipos de investigacin.
UNA PERSEPECTIVA DEL DESARROLLO DE SISTEMAS DE INFORMACION
La figura 15.5 proporciona una perspectiva general del desarrollo de sistemas. Cada nivel
da forma, directa o indirectamente, a la naturaleza de una investigacin de sistemas
particular. Esta perspectiva es til por que establece un marco para todas las
investigaciones de sistemas, adems de mostrar el alcance de un proyecto particular de
sistemas con respecto a todo el SIG.
La parte superior de la figura esta relacionada con toda la organizacin en la cual
se realiza el proyecto. Los proyectos tienen forma segn la estructura de la organizacin
(su jerarqua especifica, as como su grado de centralizacin administrativa), debido a que
este sistema de informacin debe realizarse de acuerdo con esta estructura. El estilo
administrativo tambin influye en los proyectos (particularmente en los proyectos de
sistemas administrativos), ya que determina las necesidades de informacin. Ambos, junto
con los planes de la organizacin (en especial sus planes a largo plazo), establecen el
contexto en el cual se desarrollan los planes del SIG. A su vez, los planes del SIG
controlan la direccin del futuro desarrollo de todo el SIG, en tanto que los planes del
anterior han dado forma al SIG actual.
Como se indica en la parte inferior de la figura 15.5, primero se escriben o se
compran los programas individuales y se disean sus archivos relacionados. Uno o ms
programas se combinan con uno o ms archivos para formar una "aplicacin" que realiza
una tarea especifica, como agregar nuevos empleados a la nomina. Por lo general varias
aplicaciones constituyen un "sistema", como un sistema de nominas. Varios sistemas,
incluyendo nominas, presupuestos, cuentas por cobrar y muchos otros, junto con
informacin proporcio

Estructuras de
organizacin

Estado
administrativo

Planes de
organizacin

Planes del SIG

SIG

Sistema

Sistema

Sistema

Aplicacin

Programa

Programa

Programa

Aplicacin

Archivo

Aplicacin

Archivo

nada por fuentes no computarizadas y software y hardware de sistemas, forman el SIG

de una organizacin.
El alcance y contexto de una investigacin especifica de sistemas se determinan
principalmente por su nivel, que puede ser cualquiera de los siguientes:
1. SIG
2. Sistema

3. Aplicacin
4. Programa/archivo
En el nivel programa/archivo, la tarea es desarrollar, comprar o mantener un programa
particular o disear o modificar un archivo particular. El punto de referencia para estas
tareas es el siguiente nivel (el de aplicaciones) y el analista/programador no necesita
ningn otro conocimiento acerca de todo el sistema. Al disear o revisar una aplicacin,
es esencial un entendimiento de todo el sistema del cual forma parte la aplicacin. En
forma similar, al disear o revisar un SIG, es importante un amplio conocimiento sobre
todos sus sistemas. Con frecuencia la carrera de analista/programador comienza en el
nivel programa/archivo, despus avanza al nivel de aplicaciones, despus al nivel de
sistemas, y, finalmente, cuando se ha adquirido un amplio entendimiento tanto de los
sistemas de operaciones como administrativos, el analista/programador tiene la
experiencia necesaria para jugar un papel muy importante en los proyectos de desarrollo
SIG.
En una clase introductoria de programacin, los estudiantes obtienen
conocimientos del nivel programa/archivo del trabajo de sistemas porque comnmente
escriben unos cuantos programas sencillos pero nunca desarrollan una aplicacin
completa. Desde este punto, es natural que tiendan a igualar el trabajo en sistemas con la
programacin, cuando de hecho las actividades de niveles superiores son mucho ms
ricas en su variedad y ms amplias en su alcance. Sin embargo, los estudiantes que se
concentran en sistemas de informacin, quiz tengan trabajo en cursos a nivel desarrollo
de sistemas, y con frecuencia a nivel de SIG.
FOMAS GENERALES DE ABORDAR LA INVESTIGACION DE SISTEMAS
Existen cuatro formas generales de abordar el desarrollo del tema:
1. Conducir un anlisis de sistemas y despus buscar comprar programas o un
sistema con un vendedor externo.
2. Realizar un prototipo de los programas o sistemas nuevos.
3. Hacer que los grupos de usuarios desarrollen sus propios programas y
sistemas, ya sea con o sin la ayuda de analistas, diseadores, y
programadores profesionales.
4. Desarrollar programas y sistemas en forma tradicional, usando personal
profesional de sistemas.
Las primeras tres formas estn adquiriendo cada vez mayor importancia debido a los
grandes atrasos en sistemas no desarrollados y a la escasez de personal profesional de
sistemas. La segunda y tercera formas tienen aspectos poco usuales que se estudian en
forma separada a continuacin. Los subsiguientes tienen relevancia para las cuatro
formas.
Realizar un prototipo, en esencia, es tratar de ahorrarse esfuerzo de programacin
mediante la eliminacin de las faces de anlisis, diseo e implantacin extensas y
sistemticas. El proceso se inicia con una idea baga, y no profunda, de las necesidades
de informacin de los usuarios que tengan los que van a desarrollar el sistema, quienes
entonces desarrollan rpidamente un sistema que funciona ("prototipo"), a menudo en
solo unos cuantos das los programas implantados en esta forma, se desarrollan, en
general con un leguaje de productividad que dise a la computadora que informacin se
necesita en lugar de usar procedimientos de codificacin detallados en programa acerca
de cmo extraer la informacin que se necesita.

La primera versin del sistema de prototipo proporciona, aproximadamente, la

informacin que se busca, los usuarios experimentan usando el sistema. Cuando obtienen
experiencia en el sistema, aplican su experiencia en formular necesidades mas refinadas
de informacin adicional y del sistema, y los diseadores alteran el sistema de acuerdo
con esto. Despus de varios ensayos, se considera que el sistema esta totalmente
desarrollado. Este enfoque se usa a veces para el desarrollo de sistemas de informacin
administrativos mas o menos sencillos (incluyendo sistemas de apoyo de decisiones),
pero con menor frecuencia para sistema administrativos mas complejos, y rara vez se usa
para el desarrollo de sistemas de procesamiento de transacciones.
El enfoque del prototipo pueden emplearlo los usuarios o el personal profesional
de sistema. Cuando los usuarios desarrollan sistemas administrativos por medio de este
enfoque, la actividad comienza a ser similar al desarrollo de sistemas de apoyo de
decisiones.
El enfoque de prototipo es contrario al desarrollo de sistemas tradicional, cuyo
nfasis esta en la definicin precisa y por adelantado de las necesidades de los usuarios,
seguida de un desarrollo cuidadoso y sistemtico del sistema. En forma contrastaste, el
prototipo pone nfasis en la respuesta "rpida" a las necesidades definitivas vagamente,
con el refinamiento subsecuente y se preocupa poco acerca de la eficiencia operativa de
los sistemas terminados. Este enfoque aun se encuentra en una etapa experimental pero
ya ha sido usada en muchas compaas.
Los sistemas desarrollados por los usuarios (sistemas desarrollados por personas
no profesionales de sistemas) son la consecuencia de 1) la existencia de lenguajes de
productividad, 2) la escasez de personal profesional calificado de sistemas, 3) la
existencia de microcomputadoras baratas en grupos de usuarios, bastante poderosas
para sostener uno o ms sistemas completos de los usuarios. Sin embargo, los sistemas
desarrollados por los usuarios tambin se desarrollan usando computadoras grandes. El
atractivo de sistemas desarrollados por los usuarios es que pueden desarrollarse cuando
son necesarios en lugar de tener que esperar a que se alcance la posicin de prioridad en
la cola de atrasos del sistema. As mismo, debido a que los sistemas los desarrollan sus
usuarios, estn hechos para las necesidades de los mismos y se adaptan de manera fcil
a sus necesidades cambiantes.
Una preocupacin seria acerca de los sistemas desarrollados por los usuarios, sin
embargo, es que a menudo contienen errores de diseo, no siempre estn libres de
errores y completamente probados, y con frecuencia no cuentan con la proteccin
adecuada para los datos. En general los usuarios no tienen la experiencia y
conocimientos den el desarrollo de sistemas del personal profesional de sistemas.
Resumen de la fase de estudio preliminar
Identificacin de la oportunidad de problema: obsolescencia de un sistema, deterioro de un sistema, nuevas
necesidades de informacin, etctera.
Estudio preliminar: una breve investigacin realizada por un analista de sistemas de la necesidad de una
investigacin de sistemas.
Preparacin de un resumen de anlisis preliminar: estudio de posibles problemas de sistemas y la
recomendacin y razonamiento del analista.
Decisin: no hacer nada mas, diferir el proyecto o realizar una investigacin de sistemas

Como se hizo notar en un capitulo anterior, se espera que los sistemas diseados
por los usuarios predominen en el futuro cercano. Las preocupaciones acerca de estos
sistemas pueden aliviarse si los usuarios siguen el enfoque del desarrollo tradicional de
sistemas y usan herramientas y tcnicas tradicionales de anlisis y diseo hasta el punto
en que sean necesarias. En general mientras mayor sea el posible impacto de un error en
el diseo o en el control de los datos en toda organizacin, mas fuerte es el argumento a
favor de que los usuarios realicen sus propias investigaciones de sistemas y desarrollen
su propio sistema.
FASE DEL ESTUDIO PRELIMINAR
Las actividades de la fase de estudio preliminar de una investigacin de sistemas se
encuentran resumidas en la figura 15.6; estas son: identificacin del problema, el anlisis
preliminar y la preparacin de un resumen del estudio preliminar. En la figura 15.7 se
muestran las condiciones que comnmente originan la realizacin de una investigacin de
sistemas. Las actividades de la investigacin de sistemas pueden comenzar cuando
alguien percibe que existe un
Condiciones que llevan a una investigacin de sistemas
1. Se identifica un problema con el sistema actual.
2. Nueva tecnologa u otras oportunidades pueden proporcionar mayores beneficios o resultar de menores
costos.
3. Se piensa que es necesario un sistema formal donde ahora se tiene un sistema manual o informal.
4. Se necesitan nuevos tipos de informacin, por ejemplo, cuando una lnea de negocios se agrega o se
requiere un nuevo informe regulatorio.
5. Se ponen a la disposicin nuevos recursos para una investigacin que estaba "a punto de realizarse".

problema en un sistema existente, cuando nueva tecnologa u otras circunstancias

presentan oportunidades para mejorar la eficiencia, cuando un sistema de informacin
manual necesita computarizarse, o cuando se necesitan nuevos tipos de informacin. Los
problemas comunes con un sistema existente incluyen la presencia de un gran nmero de
errores, Informes atrasados, una capacidad inadecuada para el procesamiento, y costos
demasiado altos en el procesamiento de datos. Tambin surgen problemas ms
especficos como un control inadecuado de los costos dentro de la organizacin, que
necesitan la implantacin de un sistema estndar de costos.
A menudo, un usuario de un sistema descubre un problema con el sistema o una
oportunidad de mejorarlo y pide una investigacin. Algunas veces un analista de sistemas
percibe un problema o una oportunidad. Los programadores o el personal de
procesamiento de datos detectan primero muchos problemas en los programas existentes
y piden que se modifique el programa. Los operadores de la computadora o el personal
administrativo de procesamiento de datos pueden detectar una falta de capacidad para
periodos pico, o pueden tener conocimiento de un equipo ms avanzado con
caractersticas que seran tiles.
Sea quien sea el que descubra lo que parece ser un problema, y cualquiera que sea su

naturaleza, el problema se lleva ante el administrador, quien tiene la autoridad de

autorizar un estudio preliminar; ste puede ser el vicepresidente de sistemas de
informacin, el director de sistemas de informacin, el gerente de desarrollo de sistemas u
otro gerente. Este ltimo revisa los hechos y autoriza o niega un estudio preliminar. Es
probable que el analista asignado realice varias entrevistas generales que tratarn de
verificar la existencia de un problema, reunir informacin adicional acerca del mismo, y
permitir un juicio informado pero tentativo acerca del problema y de qu tan serio es. Un
estudio preliminar puede requerir una hora, un da o varios das, pero la cantidad de
tiempo dedicado, es por lo general, muy poco en relacin con la cantidad de tiempo total
requerido si existe una investigacin de sistemas subsiguiente.
Es comn que la fase de estudio preliminar sea una actividad de minianlisis en la cual
se realizan muchas de las tareas de anlisis de sistemas pero en una forma superficial y
rpida. En cierto sentido, esta fase es un "estudio de factibilidad" para determinar si es
factible un nuevo sistema; la fase de anlisis de sistemas realiza esto con todos los
detalles, y algunas veces el concepto de un "estudio de factibilidad" se asocia con esta
fase. Ambas faces estn orientadas a determinar (en forma amplia durante la primera y en
detalle durante la segunda) s cualquier sistema es factible durante la fase de diseo, y se
examinan y comparan las alternativas de varios sistemas nuevos especficos; en este
texto el trmino "estudio de factibilidad" se reserva para las actividades de la fase de
diseo.
Si despus de terminar la fase de estudio preliminar, el analista piensa que el problema
merece mayor consideracin, se prepara un resumen de tal estudio. El resumen confirma,
de modo tentativo, Ia existencia de un problema potencialmente Importante, estima un
rango de tiempo y cost de una posible investigacin detallada y especula acerca de los
costos y beneficios probables asociados con la revisin del sistema actual o la instalacin
de uno nuevo. Es probable que el resumen recomiende si la investigacin de sistemas
debera continuar, y hasta puede proponer que se considere una solucin sencilla antes
de continuar la investigacin, por ejemplo, se puede sugerir otro turno de trabajo si la
capacidad de la computadora es demasiado limitada. Todas las partes entienden que el
resumen del estudio preliminar es un documento muy tentativo; cuando mucho, slo
sugiere una investigacin adicional.
Compaa Aberecrombie
La compaa Aberecrombie es un fabricante mediano de una amplia lnea de productos
deportivos. El gerente de operaciones de procesamiento de datos ha estado estudiando
estadsticas del porcentaje de utilizacin del sistema de cmputo y ha notado que hace
poco sta ha aumentado en ms del 80%.
"Es tiempo de decidir qu computadora reemplazar a la actual", concluy. "Una nueva
podra estar instalada de aqu a un ao si comenzamos el anlisis ahora. Para entonces,
nuestra computadora actual estar siendo utilizada a su mxima capacidad." En la
siguiente junta del comit directivo de sistemas, se trat este tema.
Este resumen lo revisar un gerente del departamento de sistemas de computo, y quiz
tambin el comit directivo de sistemas. El problema se evaluar con respecto a otros
problemas conocidos en otros sistemas de informacin. Como consecuencia el problema
puede 1) hacerse a un lado porque no merezca atencin adicional, 2) asignrsela una
prioridad no crtica y hacerse a un lado para su futura atencin, o, 3), darse el visto bueno
para su iniciacin en la fase de anlisis de sistemas. La disposicin del problema debera
ser consistente con los planes a largo plazo del desarrollo de sistemas y con las
prioridades de otros proyectos; debe darse un gran peso a los argumentos de los grupos
de usuarios para determinar esta disposicin.

La decisin de continuar o no con la investigacin de sistemas constituye el primer punto

importante del proyecto (algunas veces se le llama "Punto de revisin", "punto de muerte
sbita" o "punto de decisin"). Una Investigacin de sistemas tiene varios puntos
importantes; en cada uno se "mata" al proyecto (cancela) o se contina. Las decisiones
de continuar o no para los proyectos Importantes, las toma el comit directivo de
sistemas, si es que existe uno. Este comit decide si los hallazgos del estudio hasta ese
punto amerizan la continuacin de la investigacin. Sin un comentario explcito de que el
proyecto debe continuar, el proyecto debera detenerse. Los puntos importantes tambin
son los puntos en los que el proyecto se replanea o en los que se realiza una planeacin
ms detallada de las partes que faltan, Un proyecto tpico puede contener entre 5 y 20
puntos importantes.
Los puntos importantes dan al personal de sistemas la Idea de un "com-

526-535
compromiso, como se describi en el captulo anterior. La organizacin se compromete al
proyecto slo en cada punto importante, y el compromiso slo existe hasta el siguiente
punto importante, en el cual se toma otra decisin de continuar o no. Sin un proceso de
este tipo, los proyectos suelen adquirir vida propia porque alguien, con frecuencia el
analista, tiene inters en verlos continuar aunque la proporcin costo/beneficio se
mantenga favorable o no. Gran parte de los proyectos de sistemas que se comienzan
deberan cancelarse en un punto al principio cuando se ve que sus costos o beneficios no
son como se esperaban originalmente.
Si se toma la decisin de continuar la investigacin de sistemas, se comunica por
medio de un comunicado formal de proyectos de sistemas, a lo que se llama resumen de
asignaciones. Este consiste en un conjunto de directivas que establecen los objetivos
generales y el alcance mximo permitido de la investigacin de sistemas, as como la
naturaleza y cantidades de los recursos asignados al proyecto. Los objetivos describen lo
que tratar de realizar la investigacin de sistemas. Tambin se menciona cualquier
restriccin especifica o limitaciones en el alcance del proyecto. Es caracterstico que el
resumen de signe algunos o todos los miembros de la fuerza de trabajo para el proyecto.
En este punto comienza la fase de anlisis de sistemas.
FASE DE ANLISIS DE SISTEMAS
Se tienen seis componentes principales de la fase de anlisis de sistemas:
1.
2.
3.
4.
5.
6.

La propuesta del estudio del sistema

La investigacin del sistema
La especificacin del sistema
La revisin de la propuesta del estudio del sistema
El anlisis del sistema
El informe de especificaciones de requerimientos del sistema.

En resumen, la propuesta del estudio del sistema es el documento inicial de planeacin

del proyecto, la investigacin del sistema es un anlisis del sistema actual, la
especificacin trata de llegar a un acuerdo acerca del problema actual en el sistema, la
revisin de la propuesta del estudio del sistema es la propuesta modificada como
consecuencia de los hallazgos en la investigacin y el anlisis del sistema determina lo
que lo que debe realizar el sistema nuevo, que se especifica en el informe de
especificaciones de requerimientos del sistema.
PROPUESTA DEL ESTUDIO DEL SISTEMA
Una vez recibido el resumen de asignaciones al final de la fase de estudio preliminar, el
equipo de proyecto planea en detalle las actividades de estudio del sistema, al tiempo que
delinea el resto de la fase de anlisis, as como partes posteriores de la investigacin de
sistemas en menor detalle. Una parte importante de esta planeacin inicial es el
refinamiento de los objetivos de la investigacin de sistemas en menor detalle. Una parte
importante de esta planeacin inicial es el refinamiento de los objetivos de la investigacin
del sistema si estos no se han proporcionado en forma adecuada. Al plan resultante se le
llama propuesta de estudios del sistema. Suponiendo que la propuesta inicial ha sido
aceptada, se comienza la investigacin. La planeacin del proyecto es un proceso vital
que contina a travs de la investigacin.

INVESTIGACIN DEL SISTEMA

El propsito de la investigacin es examinar el sistema de informacin actual. Este
examen incluye estudio y documentacin de por lo menos lo siguiente:
1. El nmero total de transacciones de cada tipo que se procesan con el sistema en la
actualidad y que se procesaran en el futuro prximo.
2. Usos y variaciones de los usos durante el periodo normal, periodo pico y
estacional.
3. El porcentaje de la utilizacin de la capacidad del sistema.
4. Tendencias en el porcentaje de la utilizacin de la capacidad del sistema.
5. Tipos de errores, tasas de errores y tendencias.
6. El tipo y formato de los documentos e informes proporcionados por el sistema,
segn lo determinen las muestras reunidas.
7. Qu tan a tiempo se tienen los documentos e informes.
8. La utilidad de los informes proporcionados.
9. La confiabilidad del sistema, por ejemplo, su frecuencia de fallas.
10. Como podra mejorarse el sistema antiguo.
11. La naturaleza y calidad del servicio proporcionado por el sistema.
12. Las responsabilidades de empleados especficos en el sistema.
13. La naturaleza de los clculos realizados por el sistema.
14. Polticas actuales de la organizacin que influyen en el sistema.
15. Nuevos tipos de procesamiento de datos o informes que probablemente se
necesitarn en el futuro.
16. Problemas de tipo personal que parezcan causados por el sistema, tales como baja
moral y ausentismo.
17. Problemas de personas que afecten la operacin del sistema.
La investigacin del sistema debe proporcionar un entendimiento del sistema antiguo y
un conocimiento til para un convenio subsiguiente acerca de la naturaleza y extensin
del problema del sistema. Durante la investigacin, el enfoque tiene tres consideraciones
generales: determinar los objetivos del sistema actual, esto es, las razones para su
existencia; establecer el flujo general de transacciones a travs del sistema y obtener
informacin de los problemas (incluyendo problemas de tipo personal) en la operacin del
sistema.
No puede dedicarse un esfuerzo mayor al necesario en la encuesta del sistema. En
particular, un estudio profundo de todo el sistema, junto con su documentacin completa,
no vale la pena si es probable que el sntoma antiguo sea reemplazado. De la misma
forma, el enfoque debe estar puesto en el anlisis y documentacin del sistema existente
de tal forma que esclarezcan sus problemas y requerimientos de informacin de un nuevo
sistema. El estudio es demasiado profundo si el sistema antiguo pudiera reconstruirse de
la documentacin desarrollada durante la investigacin.
La encuesta del sistema concluye con un informe que resume las acciones de
investigacin realizadas y sus hallazgos. Una vez ms, puede hacerse la recomendacin
de concluir el estudio, suspenderlo temporalmente, o continuar la investigacin. En este
momento importante el comit directivo de sistemas ejerce su juicio y toma una decisin.
ESPECIFICACIN DEL PROBLEMA

Mientras que el punto de vista de conservar los recursos y slo hacer lo que es
claramente necesario es apropiado para la encuesta, especificar que el problema
requiere dedicar recursos de personal en su definicin, examen y estudio del rea del
problema desde varias perspectivas. Esto se debe al hecho de que la parte ms crtica de
una investigacin de sistemas es la identificacin cuidadosa del problema. Aunque ste
haya sido analizado previamente, ahora se tiene informacin nueva importante acerca del
sistema antiguo como resultado de la etapa anterior de investigacin. En general en este
punto se necesitan recursos adicionales para definir y especificar el problema
correctamente. Un consultor puede ayudar con el problema de especificacin, como
observador externo sin influencias con conocimiento especializado.
El punto ms importante es ste: el problema que se percibe es el problema que
debera abordar la investigacin? A menudo el problema real no es un problema de
sistemas, o es un problema muy diferente que del que originalmente se pensaba.
El problema no slo debe identificarse en forma correcta, sino que su alcance o la
magnitud tambin deben especificare. Un error comn es definir el problema en forma
demasiado escueta: su anlisis debera considerar formas en las cuales el problema est
relacionado con otros problemas posibles en la organizacin.
Cuando el anlisis del sistema y los usuarios confan en que el problema est
correctamente especificado, la naturaleza del problema debera presentarse en completo
detalle al comit ejecutivo de sistemas. El consiguiente estudio debera, abocarse a lograr
un consenso general acerca de las especificaciones del problema y a un planteamiento
formal del mismo. El comit debe estar de acuerdo formalmente con el problema segn se
especifique al final. El consenso del comit, compuesto de directores generales con una
perspectiva general, disminuye la probabilidad de que el problema no est bien
especificado. (No es poco comn que el problema se reformule). Adems, el consejo
asegura que ningn individuo o grupo se convierta, a la postre, en el conejillo de indias si
el sistema se disea para resolver el problema equivocado.
REVISIN DE LA PROPUESTA DEL ESTUDIO DEL SISTEMA
Una vez que el problema se ha especificado completamente, los analistas revisan la
propuesta del estudio del sistema. Esta propuesta, cuando se aprueba, 1) especifica en
detalle las tareas que faltan en la fase de anlisis del sistema y 2) delinea las actividades
probables de las fases de diseo e implantacin del sistema. Aunque el estudio pueda
tomar varios meses o aos de trabajo para terminarse, el desarrollo de est propuesta
puede consumir slo unos cuantos das. Hasta que s e acepte la propuesta del estudio del
sistema y comience el trabajo posterior, la organizacin ha dedicado, en forma relativa,
pocos recursos a la investigacin de sistemas.
La propuesta del estudio se apoya fuertemente sobre la informacin reunida durante la
investigacin previa, pero tambin se requiere anlisis adicional y un programa de
planeacin de proyecto. En la figura 15.8 se tiene muestra de una propuesta de un
estudio de sistemas. La primera columna lista las actividades especificas necesarias para
completar las actividades faltantes de la fase de anlisis del sistema, y la segunda
columna lista las actividades que estarn incluidas en posibles nuevos sistemas.

Se incluye un informe de necesidades de personal y un presupuesto para el resto de la

fase de anlisis des sistema. stos deben prepararse en detalle. Sin embargo, la misma
informacin para la fase de diseo e implantacin del sistema slo puede estimarse, ya
que depende de los hallazgos reunidos durante el resto de la fase de anlisis del sistema.
Aunque pueda llegarse a una programacin razonablemente exacta para la conclusin de
la fase de anlisis, slo puede proporcionarse una programacin estimada para las fases
de diseo e implantacin del sistema.
Compaa Abercrombie
El Sr. Goldenrod, gerente de operaciones de procesamiento de datos de al compaa
Abercrombie, reuni estadsticas de la operacin y las present al comit directivo de
sistemas; en ellas demostraba que la computadora actual estaba llegando a su limite.
Hablaba del problema como la necesidad de reemplazar la computadora actual.
Despus de un largo anlisis el comit replanteaba el problema como: El problema no es
que se necesite reemplazar la computadora: eso slo es una posible solucin al
problema. El problema parece ser que nos estamos sin el exceso de capacidad de la
computadora. El comit tambin vio una relacin entre este problema y una posible
necesidad para los nuevos tipos de capacidades de procesamiento de datos.

La propuesta final del estudio de sistemas tambin incluye un breve anlisis de las
principales alternativas, como se muestra en la segunda columna de la figura 15.8. stas
Figura 15.8

pueden ser tan amplias como, por ejemplo, elegir un sistema cen
Puntos principales de una propuesta comn de estudio de
sistemas
Fases
de
diseo
e
Fases de anlisis del sistema
implantacin de sistemas
1. explicacin del sistema
1. diseos de sistemas
alternativos que deberan
considerarse
2. explicacin de los objetivos 2. presupuesto alternativo de
de la investigacin de sistemas la fase de diseo
3. explicacin del alcance de la 3. programacin tentativa de
investigacin de sistemas
la fase de diseo
4. resumen de los beneficios 4. presupuesto tentativo de la
esperados de un nuevo sistema fase de implantacin
5. resumen de los costos que 5. programacin tentativa de
quedan
esperados
de
la la fase de diseo
investigacin de sistemas
6.
explicacin
de
las
necesidades de personal para la
terminacin de la fase de
anlisis del sistema
7. presupuesto requerido para la
terminacin de la fase de
anlisis del sistema

8. programacin de la fase de
anlisis del sistema
9. formato esperado y los
puntos principales del informe
de
especificaciones
de
requerimientos del sistema
tralizado, un sistema distribuido, o un sistema descentralizado; una perspectiva as de
amplia es, en especial, probable que se tome en uno de los niveles superiores que se
muestran en la figura 15.5 donde debe darse atencin explcita a la organizacin general
de los sistemas de informacin. Si el enfoque de la investigacin de sistemas est en un
nivel inferior, las alternativas pueden ser ms limitadas, como si debiera usarse el
procesamiento por lotes o el procesamiento por transaccin, individual para una
aplicacin particular. La consideracin de la que se tienen en cuanto al equipo de
entretenimiento en el hogar, como una televisin a color, un sistema estreo, o una
alberca. Una vez que se ha decidido que se prefiere un sistema de estreo en lugar de
una televisin o de otra alternativa macro, por ejemplo, debe evaluarse un nmero de
alternativas dentro de la amplia categora de sistemas de estreo.
Una de estas alternativas macro es una parte importante de la propuesta, porque el
comit directivo de sistemas necesita informacin acerca de los costos y beneficios
posibles relacionados con la continuacin del proyecto. La especificacin de alternativas
permite una decisin con mejor informacin acerca de aceptar la propuesta para continuar
la investigacin. El comit no puede estar bien informado sin tener por lo menos un cierto
conocimiento de los costos y beneficios asociados con cada una de las principales
alternativas.
El estudio de las principales alternativas puede incluir un anlisis general de la
factibilidad econmica, tcnica y operacional, as como de los beneficios generales para la
institucin, de cada alternativa. Mientras que cada una de estas operaciones se considera
extensamente como parte de las actividades de la fase de diseo, necesitan atencin
preliminar durante la fase de anlisis. La factibilidad econmica pregunta: Podemos
costear el sistema, y cuales son sus beneficios probables? La factibilidad tcnica trata de:
Poseemos la experiencia tcnica para implantar y corre el sistema nuevo? La factibilidad
operacional se pregunta: Se terminara a tiempo el nuevo sistema, y sera aceptado y
usado en nuestra organizacin el deseo de la institucin dice: A pesar de los costos y
beneficios del nuevo sistema, es bueno el proyecto para balancear el riesgo en nuestra
cartera de proyectos de sistemas, ya se ha dado preferencia a la unidad organizacional
que recibir el nuevo sistema, y qu tan bien apoyara el nuevo sistema a las metas de
la organizacin? Las respuestas a estas preguntas no pueden ser definitivas en este
punto, pero deberan considerarse y puede influir en la decisin del comit directivo de
sistemas.
Todas las partes implicadas reconocen que las actividades continuas en la fase de
anlisis de sistemas pueden sugerir alternativas adicionales y que el anlisis subsecuente
puede eliminar una o ms alternativas. Despus de que el comit directivo de sistemas ha
realizado la posible revisin y aprobacin de la propuesta del estudio de sistemas, los
analistas inician el anlisis de sistemas.
ANLISIS DE SISTEMAS

La atencin de la investigacin de sistemas est en el sistema antiguo: su capacidad,

virtudes, y defectos. En contraste, el anlisis de sistemas se enfoca a los logros de un
nuevo sistema. Se da nfasis al tipo de informacin que debe proporcionar el nuevo
sistema, la frecuencia requerida y exactitud de sus informes, y otras consideraciones que
se muestran en la figura 15.9. El anlisis de sistemas concluye con un informe de
especificaciones de los requerimientos de los sistemas.
Para proyectos de sistemas de informacin administrativos, la teora de decisiones
(mostrada en la figura 15.10) es una forma til de reunir la informacin. La teora de
decisiones se enfoca directamente a las decisiones de cada administrador. stas
especifican la informacin que debe estar disponible para el uso del administrador
mediante el sistema. El primer paso en teora de decisiones es llegar a las definiciones de
las decisiones tomadas por los administradores involucrados. stos pueden requerir,
primero, un examen de la posicin formal de la organizacin para el gerente,
Informacin reunida durante el anlisis de sistemas
Figura 15.9
Documentos o informes que debe proporcionar el nuevo sistema
Detalles de la informacin necesaria para cada documento e
informe
Frecuencia y distribucin requerida para cada documento e informe
Fuentes probables de informacin para cada documento e informe
Tiempo de procesamiento mximo permitido para cada trabajo
Nmero de transacciones de cada tipo que se espera se procesen:
En el futuro inmediato
En un tiempo especifico en el futuro a largo plazo
Niveles de exactitud aceptables en el procesamiento de
transacciones e ndice de errores residuales
Requerimientos de confiabilidad del sistema
Requerimientos de expandibilidad del sistema
Circunstancias especificas para los cuales se necesitan controles
de procesamiento
la cual debe especificar estas decisiones

536-543
Tablas de organizacin.
Las tablas de organizacin generalmente muestran las relaciones entre los informes e
indican los flujos de informacin jerrquicos generales. Por estas razones, examinar las
tablas de organizacin con frecuencia es una excelente manera de comenzar a examinar
el sistema de informacin actual. Sin embargo, las tablas de organizacin pueden dar un
idea equivocada; se muestran muy pocos de los flujos reales de informacin
Manuales de operacin.
Los manuales que describen los procedimientos de operacin estndares para un sistema
existente pueden proporcionar informacin til al analista. Por lo general los manuales
describen cmo opera un sistema, conocimiento escencial para un analista. Asimismo, es
importante cmo los manuales de operacin describen con frecuencia los pasos de
control que deben tomarse o dan importancia a las acciones particulares sobre las cuales
debe tenerse control; esto ayuda al analista a establecer las fuerzas y debilidades del
control de un sistema actual, lo cual le ayuda a definir los controles necesarios en un
nuevo sistema o revisado.
Descripciones de puestos.
Estas descripciones detallan las actividades requeridas de los empleados y las decisiones
que deben tomar los empleados. Sin embargo, al igual que las tablas de organizacin, las
descripciones de puesto deben considerarse como indicacin en un lugar de definitivas.
Como se ha notado, una descripcin de posicin puede mencionar que un administrador
toma un conjunto de decisiones, pero el administrador describir un conjunto algo
diferente, y el superior del gerente proporcionar otro conjunto ms. Las entrevistas
proporcionan informacin adicional que sirve para aclarar esto.
Cuestionarios.
Los cuestionarios son de dos tipos generales. Uno se estructura con cuidado para obtener
detalles especficos acerca de un sistema de informacin o acerca de las necesidades de
informacin. Este tipo de cuestionario se usa con frecuencia cuando deben realizarse
preguntas exactamente iguales a muchos empleados o cuando la informacin recibida
debe proporcionarse en forma annima. En el lado negativo, este tipo de cuestionario es
impersonal, difcil de disear, y puede dar ideas equivocadas porque aun las preguntas
preparadas por un experto en diseo de cuestionarios pueden malinterpretarse o las
respuestas proporcionadas pueden ser insuficientes o inadecuadas en otras formas.
El otro tipo de cuestionario tiene preguntas abiertas y es general y el que a
menudo se usa junto con las entrevistas. Las preguntas pertenecen al rea de un tema
general y tienen como objetivo comenzar un anlisis; es el anlisis y no las respuestas a
las preguntas especficas en el cuestionario, lo que proporciona la mayor parte de la
informacin til. Con frecuencia este tipo de cuestionario se enva con anticipacin al
entrevistado para animarlo a desarrollar las ideas acerca de los temas que se discutirn
durante la entrevista.

Revisin de la documentacin y formas del sistema.

Una tcnica til del anlisis de sistemas es la de revisin de la documentacin del sistema
actual. Esta documentacin puede incluir diagramas de flujo del sistema y de los
programas, descripciones narradas de los informes proporcionados por el sistema, copias
de los informes y formas de entrada, adems de otros materiales que describan la
operacin del sistema existente. Un estudio cuidadoso de las formas de transacciones
proporciona con frecuencia una gran cantidad de informacin acerca de cmo se
procesan las transacciones. En forma similar, un estudio cuidadoso de los informes del
sistema mostrar la informacin que ste proporciona.
Revisin paso a paso de los documentos.
Esta tcnica consiste en seguir (o realizar) un documento de transaccin a travs del
sistema para observar su procesamiento en cada estacin de trabajo. Aunque un
seguimiento paso a paso proporciona una buena perspectiva de la operacin de un
sistema, la tcnica es menos til si una parte significativa del procesamiento de
transacciones es computarizado; sin embargo, como se not en un captulo anterior, aun
en sistemas computarizados los pasos manuales involucrados en la preparacin de datos
de procesamiento pueden ser numerosos. Las revisiones paso a paso de los documentos
pueden verificar informacin de las entrevistas y diagramas de flujo y son especialmente
tiles para aclarar las variaciones causadas por desviaciones de los procedimientos
estndar no aprobados o por tipos de transacciones poco usuales.
Observacin directa.
Al pasar por all, o al estar presente durante las actividades operativas, un analista con
experiencia puede obtener informacin por medio de la observacin de la operacin del
sistema. Puede realizarse mayor observacin formal por un perodo o bien realizarse con
base en varias muestras. Como las revisiones paso a paso de los documentos, la
observacin directa indica si en realidad el sistema funciona como se supone que debe de
hacerlo. Por ejemplo, a menudo, el tiempo requerido para realizar una actividad no se
representa correctamente al analista, pero esto puede descubrirse con la observacin.
Quiz el empleado toma un descanso durante el tiempo asignado a una tarea particular, o
quiz no slo procesa documentos sino tambin los transporta a otro departamento o se
asegura que la actividad realizada en una estacin de trabajo anterior se ha realizado
completamente y con exactitud; estas son las cosas que no se toman en cuenta cuando
se usan otros mtodos y no la observacin directa.
Medicin de trabajo.
Un anlisis del sistema actual a nivel de operaciones puede incluir medicin de trabajo. El
analista mide la cantidad de trabajo que se termina en una estacin de trabajo durante un
perodo dado o mide la eficiencia con la cual el empleado procesa las transacciones.
Usando sus conocimientos acerca de la medicin de trabajo, los analistas pueden realizar
juicios cuidadosos acerca de cunto procesamiento (u otro trabajo) debera realizar un

empleado dado. Por extrapolacin, el analista estima cuntas transacciones puede

procesar un nuevo sistema durante un perodo dado en cual participan varios empleados.
Examen de otros sistemas.
Con mucha frecuencia los analistas pueden visitar otras organizaciones para estudiar sus
sistemas, lo cual proporciona informacin importante acerca de los problemas del sistema
actual, as como ideas frescas sobre los diseos para nuevos sistemas efectivos.
RESUMEN.
Este captulo consider los conceptos de anlisis estructurado, explic los tres tipos de
investigaciones de sistemas (proyectos de hardware, proyectos de software, y proyectos
de SIG), present una perspectiva de varias dimensiones y contextos de actividades de
desarrollo de sistemas de informacin, exmino cuatro formas generales de realizar la
investigacin de sistemas, y analiz varias herramientas y tcnicas de investigacin de
sistemas. El personal relacionado en cada uno de los tres tipos de proyectos de
investigaciones de sistemas necesita de diferentes tipos de experiencia. De las varias
herramientas y tcnicas que usan los analistas de sistemas, la ms importante son las
entrevistas. Como se vio en el contexto, el desarrollo de un programa individual slo es
una pequea parte de todas las actividades de la investigacin de sistemas.
El propsito de la fase de estudio preliminar de un ciclo de vida de un sistema es
determinar, con un mnimo gasto de recursos, si se debe realizar una investigacin de
sistemas completa. Si se toma la decisin de realizar una investigacin de sistemas se
inicia la fase de anlisis de sistemas. Las tareas clave de esta fase son: 1) estudiar el
sistema actual, 2) llegar a un acuerdo acerca de la naturaleza del problema de sistemas,
3) preparar una propuesta para la continuacin de investigacin de sistemas, 4) analizar
la informacin que debe proporcionar un nuevo sistema, y 5) establecer formalmente las
especificaciones de un nuevo sistema como gua para el resto de la investigacin de
sistemas y hacer esto en forma modular y fcil de mantener. A travs de las fases de
estudio preliminar y de anlisis de sistemas, los puntos importantes representan
momentos en los cuales se evala el progreso y se toman decisiones sobre continuar o
no.

REFERENCIAS.
De Marco, Tom, Structured Analysis and System Specification, Englewood Cliffs, NJ:
Prentice Hall, 1979.
Gremillion, Lee L., y Phillip Pyburn, Breaking the Systems Development Bottleneck,
Harvard Bussines Review, marzo-abril 1983, p. 130.
TERMINOS CLAVE.

Anlisis estructurado: forma de abordar el anlisis de sistemas que involucre la

realizacin de anlisis como una serie de mdulos en lugar de una anlisis comprensivo.
Investigacin del sistema: examen y evaluacin de un sistema de informacin actual.
Propuesta de estudio del sistema: pedido escrito formal para iniciar un proyecto de
sistemas.
Especificaciones de requerimiento de sistemas: estudio completamente detallado de
lo que debe realizar un sistema de informacin nuevo.
PREGUNTAS DE REPASO.
1.- Cules son las similitudes y diferencias entre la fase de estudio preliminar y la fase
de anlisis de sistemas?
2.- Se dice que el anlisis de sistemas involucra mucha negociacin; por qu?
3.- Qu actividades en anlisis de sistemas requieren que un analista sea sensible a las
personas y capaz de trabajar bien con ellas?
4.- Explique cmo cada uno de los siguientes trminos se relaciona con actividades de
anlisis de sistemas:
a) Negociacin
b) Compromiso
c) Estimacin
d) Prevencin de fallas
5.- Qu habilidades de un analista no se aprenden en un saln de clases?
6.- Qu ventajas es ms probable que tengan los estudiantes de disciplinas menos
tcnicas sobre los estudiantes de ingeniera y ciencias computacionales en trminos de
ser analistas de sistemas?
7.- Qu es anlisis estructurado y cules sus caractersticas?
8.- Explique la naturaleza de los tres tipos principales de investigacin de sistemas.
9.- Qu conocimientos que no sean crticos para otros tipos de proyectos de sistemas es
probable que necesite un analista en un proyecto de sistemas de informacin para la
administracin?
10.- Cul es la naturaleza de cada una de las siguientes fases?
a) Mantenimiento correctivo
b) Mantenimiento adaptivo
c) Mantenimiento de perfeccin
11.- Suponga que su tarea es escribir un programa que obtenga y analice datos de un
archivo de datos que el instructor le proporcione. En dnde entra este tipo de proyecto
de sistemas dentro de todo el esquema de investigacin de sistemas?
12.- Explique por qu es til una perspectiva amplia en los sistemas de informacin de
una organizacin para un analista o diseador que est trabajando en el nivel de sistemas
en un nuevo sistema particular.
13.-Qu implica el uso de un prototipo? En qu situaciones es especialmente benfico
un prototipo?
14.- Cules son las ventajas y desventajas de que los usuarios desarrollen sus propios
sistemas?
15.- Qu pasos estn tomando los usuarios debido al gran atraso en los proyectos de
sistemas?
16.- Cul es el propsito de la fase de estudio preliminar?
17.- Qu es un resumen de anlisis preliminar, y cmo se usa?
18.- Cite varias situaciones descritas en el presente captulo que ilustren el uso de un
compromiso.

19.- Por qu es necesario realizar una investigacin sobre el sistema actual? Qu tan
amplia debera ser esta investigacin?
20.- Por qu es tan importante la especificacin correcta del problema en una
investigacin de sistemas? Cmo se logra? Por qu es til un concenso acerca del
problema de sistemas?
21.- Qu es una propuesta de estudio de sistemas?
22.- Cul es la naturaleza de las actividades que se realizan durante el anlisis de
sistemas?
23.- Explique la teora de decisiones.
24.- Cul es el propsito del informe de especificaciones de requerimentos de sistemas?
25.- Repase el presente captulo para determinar el papel que juega el comit directivo de
sistemas durante la fase de estudio preliminar y la de anlisis de sistemas; describa este
papel.
26.- Cul es la tcnica ms importante del anlisis de sistemas? Por qu es tan
importante?
27.- De qu utilidad son las tablas de organizacin para entender los flujos de datos de
una organizacin?
APNDICE: Tcnicas de entrevistas
Las entrevistas formales son difciles y complejas; no se trata de llegar a visitar a otro
empleado para una pltica casual. Hay cursos completos dedicados a ensear tcnicas
de entrevistas a los analistas de sistemas, cuyo estudio vale la pena. A continuacin se
presentan algunas reglas generales:
1.- Durante una investigacin de sistemas, es probable que los entrevistados les
preocupe su posicin en la organizacin alertas a crticas de ellos o de su trabajo y ms
ocupados que nunca porque la investigacin de sistemas quiz ya ha interrumpido sus
programas o ha causado la alteracin de sus actividades de trabajo. Por estas razones un
analista de sistemas debe tratar con los entrevistados en una forma profesional y con
tacto y cortesa de excepcionales.
2.- Antes de comenzar las entrevistas, debe solicitarse a los superiores inmediatos
de los entrevistados que les expliquen la importancia y necesidad de su cooperacin con
el analista. Si un entrevistado conoce el apoyo de niveles superiores al proyecto, es ms
probable que coopere.
3.- El analista debe hacer una cita por adelantado para la entrevista, segn
convenga al entrevistado y debe de llegar a tiempo para relizarla. A nadie le gustan las
sorpresas desagradables, y caer en una entrevista no programada, es definitivamente
de stas. En cambio, una cita asegura al analista que el entrevistado tomar el tiempo
necesario para la pltica. Al hacer una cita tambin se da importancia al proyecto y a la
entrevista.
4.- El analista, adems de prepararse para la entrevista con el estudio de la
documentacin del sistema, debe hacerlo en otras formas que determinen lo mejor
posible, qu informacin est recibiendo el entrevistado y la estructura del sistema que la
proporciona. Este anlisis, antes de la entrevista, debe identificar cualquier inters en el
sistema actual o cualquier otra clase de desviacin que pueda influir en las respuestas del
entrevistado.
5.- Cada entrevista debe tener un propsito especfico y no ser una expedicin de
pesca. Este propsito debe comunicrsele al entrevistado con anterioridad.

6.- Debe enviarse por adelantado una lista de las preguntas de la entrevista; esta
lista puede estar en forma de cuestionario con el final abierto. Este procedimiento ayuda a
relajar al entrevistado, permite, por adelantado, la preparacin de respuestas formuladas
con sumo cuidado, hace que la entrevista sea ms eficiente, y reduce la incidencia de
respuestas sacadas de la manga.
7.- Durante la entrevista el analista debe ser directo, honesto, al grano y no
misterioso; tambin debe aparecer como alguien que desea la cooperacin del
entrevistado, adems de ser entusiasta, pero profundamente profesional.
8.- El analista debe evitar hacer comentarios amenazadores que sugieren el
reemplazo del sistema actual a cambios significativos en el empleo del entrevistado. De la
misma forma, debe parecer comprensivo y de confianza. Para muchos empleados, un
gran cambio en los sistemas puede ser un trauma y puede ser que necesiten el apoyo
moral del analista.
9.- El analista debe evitar tomar una posicin especfica e inequvoca. Por ejemplo,
puede decir: Estamos examinando el sistema actual para ver si existen problemas y para
consultar con todos acerca de que accin, si la hay, debe tomarse. No debe mencionar
que el sistema tiene problemas particulares o que se va a cambiar; el proceso de anlisis
de sistemas puede revelar una necesidad de cambios, pero nadie debera hacer
conclusiones por adelantado.
10.- El analista no debe de pedir recomendaciones al inicio al entrevistado que se
comprometa, ya sea a favor o en contra, del sistema actual o de un posible sistema
nuevo. Los compromisos por adelantado hacen que despus sea ms difcil aceptar a
cualquier solucin diferente de la recomendada con anterioridad.
11.- El analista debe cumplir las promesas realizadas durante la entrevista. Por
ejemplo, puede aceptar hablar con otras personas que el entrevistado le sugiera o enviar
materiales al entrevistado. Debe ser amable si no se puede prometer algo que se le pida.
12.- El analista debe de ser breve durante una entrevista. Muchos entrevistadores
estn ocupados y no pueden dedicar mucho tiempo a una entrevista.
13.- El analista no debe hablar acerca de una entrevista con otros entrevistadores.
Cada persona entrevistada necesita estar seguro de que la entrevista es confidencial. Si
el analista parece violar la confidencialidad de otros, la credibilidad del analista y la
cooperacin del entrevistado se disuelven.
14.- Despus de la entrevista, el analista debe escribir la informacin de los
hechos proporcionada por el entrevistado en forma de un informe y enviar una copia al
entrevistado para que ste la evale; esto es, se el entrevistado est en desacuerdo con
cualquiera de los comentarios del informe, podra ser posible que pidiera su correccin.
Estos informes de entrevistas debe servir como registro de los hechos reunidos.
Entrevistar es ms un arte que una ciencia, y algunas veces debe caminarse sobre una
lnea muy estrecha. Por ejemplo, puede ser difcil obtener informacin de un entrevistado
al que, a la vez que se le entrevista, se le previene que evite comentarios demasiado
negativos acerca del sistema de informacin actual.
DISEO E IMPLANTACIN DE SISTEMAS DE INFORMACIN.
CONCEPTO BSICO.
El control y administracin cuidadosos de los proyectos son la clave para un desarrollo de
sistemas con xito, varias de las actividades de las fases de diseo y desarrollo pueden

realizarse simultneamente, lo cual acortar el tiempo total de la investigacin de

sistemas.
OBJETIVOS DEL CAPTULO.
1. Explicar las actividades y procesos de las fases de diseo e implantacin de sistemas.
2. Poner especial atencin en la seleccin y evaluacin de programas prescritos
disponibles para su adquisicin.
3. Estudiar el propsito y objetivos de la auditora posterior de sistemas.

??????
INTRODUCCION
Este captulo examina las dos fases finales de las actividades de una investigacin de
sistemas, as como la auditora posterior y la actividad continua de mantenimiento de
sistemas. As mismo se analiza una gran variedad de tareas, aunque no todas ocurren en
cada investigacin de sistemas. Con frecuencia el estudiante deber referirse a la figura
16.1 al leer este captulo es un esquema que muestra las tareas principales de la fase de
diseo de sistemas y como estn interrelacionadas.
DISEO DE SISTEMAS
El diseo de sistemas determina cmo un sistema lograr lo que tiene que lograr;
involucra la configuracin de los componentes de software y hardware de un sistema para
que despus de su instalacin, el sistema satisfaga completamente las especificaciones
de sistemas establecidas al final de la fase del anlisis de sistema. Un aspecto posterior
del diseo del sistemas el la configuracin para que sea aceptable tanto para los usuarios
como para los operadores de sistemas.

Inicio del diseo

detallado

Seleccin
de hardware

Alternativas
De macro diseos
Seleccin

Seleccin de

Preparar
pp

Preparar
especificaciones
de hardware
Preparar

Evaluar
alternativas

Fase de implantacin

Evaluar

Seleccionar
de un macro Sistemas completos
sistema
Especificaciones
del sistema

pp

respuestas

diseo
Usar como est
Software

archivos

Diseos de

Modificar
Tradicional
Compra
Los usuarios
Desarrollo
El personal
de sistemas

Si el sistema como esta diseado no puede lograr una forma simultnea, las
especificaciones establecidas y ser aceptable a los usuarios y operadores; como algunas
veces se descubre, las actividades de anlisis de sistemas debe renovarse y modificarse
las especificaciones de sistemas. Una ventaja del anlisis estructurado es que slo uno o
varios de los mdulos de diseo pueden necesitar ser revisados.

El proceso de diseo
Mientras que el anlisis de sistemas es una actividad no estructurada que involucra
estimaciones y negociacin, el diseo de sistemas es ms estructurado y tcnico
por naturaleza. Los diseadores de sistemas necesitan un alto nivel de habilidades
tcnicas, en tanto que los anlisis de sistemas tienen mayor necesidad de
capacidades interpersonales. Sin embargo, existe mucha interaccin entre ambos
equipos de diseo; por lo tanto, la capacidad de los diseadores de trabajar entre
s es tema de consideracin. Durante la fase de diseo se realiza un nmero de
actividades especializadas y un equipo de trabajo para un equipo grande de
diseo de sistemas podra consistir en programadores, diseadores de archivos,
especialistas de control de entradas, expertos en adquisicin de hardware,
especialistas en la adquisicin de software, en administracin de proyectos,
expertos en redes de telecomunicacin, diseadores de archivos y consultores
especializados, aunque por lo general no todos estaran involucrados al mismo
tiempo.

Los consultores de sistemas se emplean con mayor frecuencia durante las fases del
diseo e implantacin porque ambas fases involucran varias actividades
especializadas y demasiado tcnicas, y porque hay mucha posibilidad de que una
organizacin no emplee al personal que posea, en forma colectiva, toda la
experiencia necesaria. Entre el personal externo empleado con mayor frecuencia
se encuentran los consultores de seleccin de hardware, programadores por
contrato, consultores de seleccin de software y de administracin de proyectos.
Tambin puede pedirse a los organismos pblicos de contabilidad que se
aseguren de la implantacin de los controles de sistemas adecuados y que
puedan realizarse auditoras sobre el sistema final.

La figura 16.1 muestra las actividades que pueden ocurrir durante el diseo de sistemas.
Todas se examinarn en este captulo, y gradualmente se explicar la figura al
progresar el captulo. Adems, los siguientes dos captulos ampliarn el estudio de
este captulo con respecto a la seleccin de equipo.

En la citada figura las lneas representan las actividades o alternativas, y el crculo

representa sucesos o decisiones. Como se ve, el diseo de sistemas est basado
en las especificaciones de sistemas; una serie de alternativas de macro diseo se
desarrollan y analizan, y se elige una. Dependiendo de qu macro diseo se elija,
el resto del diseo de sistemas se enfocar a una de las siguientes: seleccin de
hardware, de un sistema compuesto (hardware y software) o diseo de software.
Con frecuencia un proyecto combina diseo de software y seleccin de hardware.
Un proyecto de seleccin de un sistema compuesto involucra la seleccin de un
sistema listo para operar, el cual cosiste en un sistema de cmputo y programas
de cmputo proporcionados por un proveedor; la seleccin de sistemas
compuestos se examina en el siguiente captulo.

Diseo estructurado
El diseo estructurado implica el inicio del diseo del sistema con el conjunto ms amplio
de diseos alternativos permitidos por el alcance establecido por el proyecto (al que se
refiere aqu como alternativas de macro diseo) y su continuacin a travs de una serie
de conjuntos de alternativas progresivamente menores hasta que el conjunto menor (las
alternativas de micro diseo) defina por completo al sistema de detalle. A este enfoque
por estratos de iniciar con un macro diseo y proseguir a travs de muchas etapas hasta
un micro diseo final se le llama refinamiento sucesivo o diseo de arriba a bajo. Con
referencia a la figura 16.1, despus de la actividad de seleccin de alternativas de macro
diseo, los conceptos de diseo estructurado son muy relevantes para las actividades de
desarrollo de software que se muestran en la parte inferior de la figura. Usando diseo
estructurado, se busca una estructura de sistemas clara y sencilla para el software que se
mantiene y se pueda modificar con facilidad. Esto se logra en parte con el diseo modular
ya que cada mdulo realiza una tarea lgica y tiene tan picas uniones con otros mdulos
de software como sea posible.
Actividades de diseo de macro sistemas
1. Desarrollar alternativas de nuevos diseos que satisfagan
potencialmente las especificaciones establecidas de sistemas.
2. Realizar estudios de factibilidad para macro diseo
a) Factibilidad econmica
Anlisis de costo de beneficio
Anlisis de factores intangibles
b) Factibilidad tcnica

Existe la tecnologa?
La organizacin tiene la tecnologa
c)

Factibilidad operativa

3. Evaluar las alternativas macro en base a los estudios de

factibilidad

3
4. Presentar alternativas con una fundamentacin de normas directivo
de sistemas y seleccionando un macro diseo
5

Macro diseo
El macro diseo inicial de sistemas debe ser tan amplio como lo permita el alcance de la
investigacin de sistemas. Refirindose a la figura 15.5 si el alcance fuera tan ampli
como el nivel SIG, por ejemplo, el primer macro diseo podra considerar alternativas
como 1) un sistema descentralizado, 2) un sistema centralizado o 3) un sistema
distribuido. O, si la investigacin de sistemas estuviere restringida al diseo de un
sistema, como se muestra en la figura 15.5, el macro diseo podra considerar
alternativas tales como si debieran usarse una base de datos o un sistema de archivos
tradicional.
El diseo de sistema puede asociarse a un rompecabezas chino en el cual hay cajas
contenidas dentro de otras cajas. Se analiza un nivel superior de macro diseos y se elige
una alternativa; despus se evala otro conjunto de alternativas de macro diseos que
existe dentro de dicha alternativa; dentro de esa alternativa elegida, se encuentra otro
conjunto ms detallado, se evala y despus se elige una alternativa y as sucesivamente.
La figura indica que los pasos 1 al 4 que llevan a la evaluacin de macro diseos, se
repite cuantas veces sea necesario. Por lo comn se evalan secuencialmente tres o ms
niveles de alternativas macro en una investigacin de sistemas que tiene un alcance
bastante amplio.
Para ilustrar este proceso, suponga que para el primer macro diseo se consideran tres
alternativas de macro diseos: 1) un sistema centralizado de cuentas por cobrar, 2) un
sistema descentralizado de cuentas por cobrar, y 3) un sistema distribuido de cuentas por
cobrar. Cada alternativa se evala de forma general de acuerdo con su facilidad
econmica, tcnica y prctica. Con frecuencia se puede tomar una decisin tentativa en
este nivel macro superior sin demasiado esfuerzo porque la poltica o filosofa corporativa
hace que una alternativa sea ms atractiva que las dems.
Si se elige un sistema descentralizado de cuentas por cobrar, el siguiente conjunto de
macro diseos alternativos pueden incluir las alternativas de 1) procesamiento en lotes,
2) entrada por transaccin individual, y 3) procesamiento procesado en lote e individual de
transacciones. Una vez ms, se realiza suficiente diseo para servir como una base
razonable para la evaluacin de costos y beneficios aproximados y para realizar una
eleccin tentativa de entre las alternativa. Sin embargo, es caracterstico que al
considerarse niveles sucesivos de alternativas, los anlisis de facilidad sean cada vez
ms detallados. Esto se muestra en la figura 16.3. En forma eventual se elige una
configuracin especfica que se disea en detalle.
Note que tambin podran presentarse otras alternativas de macro diseos en la figura
16.3. Por ejemplo, despus de la eleccin de un sistema descentralizado, los anlisis
podran considerar la factibilidad de estas alternativas de macro diseos: descentralizar
cada sucursal o descentralizar slo cada ciudad (de tal forma que una ciudad que
contenga varias ramas slo tendra un sistema de cuentas por cobrar). Tambin se
considerarn las alternativas macro relacionadas con el hardware.
Jerarqua de alternativas anidadas de macro diseos*
1. Alternativas de macro diseos, conjunto 1:
a) Realizar estudios de factibilidad para:
Un sistema centralizado de cuentas por cobrar.

2.

Un sistema descentralizado de cuentas por cobrar.

Un sistema distribuido de cuentas por cobrar.
b) Evaluar alternativas y tomar una decisin tentativa; un sistema
descentralizado.
Alternativas de macro diseos, conjunto 2:
a)Realizar estudios de factibilidad para:
Procesamiento por lote
Procesamiento por transaccin individual
Procesamiento combinado lote y transacciones individuales

3. Alternativas de macro diseos, conjunto 3:

a)Realizar estudios de factibilidad para:
Capacidad de informar slo peridicamente cuentas por cobrar
Informes peridicos y capacidad de consultar en lnea
Informes peridicos y bajo pedido y capacidad de consultar
b)Evaluar alternativas y tomar decisin tentativa: informes peridicos y
capacidad de consultar en lnea
4. Realizar el macro diseo de un sistema descentralizado, de
procesamiento por lote, con informes peridicos y preguntas en lnea
Compaas Abercrombie
El comit directivo de sistemas consider tres conjuntos de alternativas macro
1. No agregar capacidades al sistema
2. Agregar una capacidad de base de datos
3. Agregar una capacidad de telecomunicaciones
4. Desarrollar un sistema distribuido
Decisin : Agregar capacidades de base de datos y telecomunicaciones usando
terminales ahora y disear el sistema para acomodar mayor adicin de capacidad de
centro de cmputo para convertirlo a un sistema de procesamiento distribuido.
1. Agregar un tercer turno de operacin al centro de cmputo
2. Aumentar la capacidad del sistema reemplazado o ampliarlo el sistema de cmputo
3. Comprar tiempo de cmputo de un proveedor externo (una compaa de tiempo
compartido).
Decisin: aumentar la capacidad
1. Aumentar la capacidad al agregar la computadora y un dispositivo de
comunicaciones.
2. Aumentar la capacidad al agregar memoria y procesador (CPU)adicional a la
computadora actual.
3. Aumentar la capacidad al reemplazar la computadora mayor que ya posea una
capacidad de base de datos y un dispositivo de comunicaciones.
Decisin: reemplazar la computadora con una computadora mayor con las capacidades
necesarias.
Estudios de factibilidad
Como se mencion en el captulo anterior, debe ponerse atencin a varios puntos de la
investigacin de sistemas a la factibilidad de un nuevo sistema, incluyendo la fase de
anlisis de sistemas. Sin embargo, en general los anlisis de factibilidad ms profundos, o

los estudios de factibilidad, se completan durante la fase de diseo de sistemas, por lo

general durante la consideracin de los conjuntos sucesivos de alternativas macro y
micro. Los estudios de factibilidad consideran la factibilidad tcnica, econmica y
operacional de cada alternativa, as como si el proyecto es o no apropiados los factores
polticos y otros del contexto institucional como se considerarn todos menos los ltimos.
Factibilidad tcnica
El anlisis de factibilidad tcnica evala si el equipo y software estn disponibles (o, en el
caso del software, si puede desarrollarse) y si tienen las capacidades tcnicas y
requeridas por cada alternativa del diseo que se est considerando. Los estudios de
factibilidad tcnica tambin considern las interfases entre los sistemas actuales y el
nuevo. Por ejemplo, los componentes que tienen diferentes especificaciones de circuito
no pueden interconectarse, y los programas de software no pueden pasar datos a otros
programas si tienen diferentes formatos en los datos o sistemas de codificacin; tales
componentes y programas no son compatibles tcnicamente. Sin embargo, puede
hacerse una interfase entre los sistemas no compatibles mediante la emulacin, la cual
son circuitos diseados para hacer que los componentes sean compatibles, o por medio
de simulacin, que es un programa de comput que establece compatibilidad, pero con
frecuencia o son demasiado costosas.
Los estudios de factibiulidad tcnica tambin consideran si la organizacin tiene el
personal que posee la experiencia tcnica requerida para disear , implantar , operar y
mantener el sistema propuesto. Si el personal no tiene est experiencia, puede
entrenrsele o pueden emplearse nuevos o consultores que lo tengan. Sin embargo, una
falta de experiencia tcnica dentro de la organizacin puede llevar al rechazo de una
alternativa particular.
Factibilidad econmica
Los estudios de factibilidad econmica incluyendo anlisis de costos y beneficios
asociados con cada alternativa del proyecto. Con anlisis de costo/beneficio, todos los
costos y beneficios de adquirir y operar cada sistema alternativo se identifican y se hace
una comparacin de cada uno de ellos. Primero se comparan los costos esperados de
cada alternativa con los beneficios esperados para asegurarse que los beneficios excedan
a los costos. Despus la proporcin costo/beneficio de cada alternativa se compara con
las proporciones costo /beneficio de las otras alternativas para identificar la alternativa que
sea ms atractiva en su aspecto econmico. Una tercera comparacin, por lo general
implcita, se relaciona con las formas en que la organizacin podra gastar su dinero de
modo de que fuera en un proyecto de sistemas.
Los costos de implantacin incluyendo comnmente el, costo remanente de la
investigacin de sistemas (para este propsito, los costos en que ya sea incurrido no son
relevantes), los costos de hardware y software ,los costos de operacin del sistema para
su vida til esperada, y los costos de mano de obra, material, energa, reparaciones y
mantenimiento. A travs del anlisis de costo/beneficio, la organizacin debe apoyarse en
los conceptos tradicionales de anlisis financiero y herramientas como teora del valor
presente anlisis de costos diferenciales y anlisis de flujos de caja descontados.
Algunos costos y beneficios pueden cuantificarse fcilmente. Los beneficios que pueden
cuantificarse con facilidad son de dos tipos generales: ahorros en costos, tales como una

disminucin en costos de operacin y aumentos en las utilidades directas. Como por

ejemplo de lo ltimo, un cliente pudo contratar un suministracin de pedidos de una
cantidad conocida si la organizacin implanta un sistema de informacin que proporcione
al cliente informacin contina acerca del estado de la produccin en proceso de los
embarques planeados de mercanca , de tal forma que los clientes de dicho cliente pueda
drseles estimaciones exactas de cuanto estar disponible la mercanca.
Un problema importante con el anlisis de costo/beneficio es la atencin inadecuada de
costos y beneficios intangibles. Estos son aspectos de alternativas de los nuevos
sistemas que s afectan los costos y utilidades y deberan evaluarse pero que los afectan
en formas que no pueden cuantificarse fcilmente. Los factores intangibles con frecuencia
estn relacionados a la calidad de la informacin afecta a la empresa, tal como alternando
las actitudes para que la informacin sea vista como un recurso.
Con frecuencia los diseadores de sistemas no estn a gusto, basando sus
recomendaciones en intangibles vagos que deben estimarse en forma contraria a lo que
se llama hechos duros de costos y beneficios fcilmente cuantificables; prefieren
justificar sus recomendaciones con datos determinados objetivamente. Cuando se da
mayor importancia a los costos y beneficios cuantificables que a los costos y beneficios
intangibles, quiz haya una desviacin contra el nuevo sistema porque la mayora de los
costos pueden cuantificarse de modo fcil, mientras que muchos de los beneficios ms
importantes pueden ser intangibles y por lo tanto no se consideran correctamente.
Dos beneficios intangibles son el servicio a clientes y mejor informacin administrativa.
Por ejemplo, los clientes pueden recibir informacin puntual y exacta acerca de los
envos, estados y otros informes ms exactos, y nuevos servicios. Los cajeros
electrnicos en los bancos que permiten a los clientes realizar operaciones las 24 horas
del da y que pueden resultar en un mayor nmero de clientes y utilidades para el banco,
son ejemplo de un nuevo servicio a los clientes. A dems, un nuevo sistema puede
proporcionar una mejor imagen de la organizacin a sus clientes, vendedores, y
empleados, que ayuda atraer ms clientes o que ayuda a retener a los empleados.
Los beneficios intangibles importantes pueden ser adquiridos de un nuevo sistema de
informacin. Es cierto que el principal mpetu al desarrollar un nuevo sistema puede ser la
expectativa de la informacin ms exacta y a tiempo, un mejor formato en los informes,
informes que estn ms enfocados a reas particulares de problemas. Por ejemplo, los
informes pueden recibirse ms pronto despus del cierre de periodo, o el nuevo sistema
puede hacer que la informacin est disponible con base en preguntas durante todo el
tiempo. A dems, en muchos casos un nuevo sistema proporciona informacin que antes
estaba disponible, como informacin acerca de costos estndares o incrementos en los
costos.
Tambin puede haber menos beneficios intangibles obvios. Un nuevo sistema puede
proporcionar mejor control sobre las operaciones de la organizacin, o puede ser que la
auditoria sea ms rpida a un costo menor. Un beneficio tangible final es que la
experiencia obtenida de la investigacin de sistema y del uso de un sistema ms
avanzado a menudo coloca a la organizacin en una mejor posicin para tomar ventajas
de desarrollos futuros en tecnologa de computacin y sistemas de informacin. Por
ejemplo, es posible que la experiencia obtenida del desarrollo de una base de datos de
personal tenga mucho que valor si la organizacin decide implantar una base de datos
financiera, no slo estar afectado positivamente el diseo de la base de datos financiera,

sino tambin existir una reduccin en los costos de su desarrollo, que es un ahorro en
costos hacia el siguiente proyecto de sistemas que debera considerarse como un
beneficio proporcional por el proyecto actual.
L a mayora de los costos y beneficios intangibles de una alternativa afectan en forma
directa las utilidades, pero esto es difcil de medir. La siguiente es una forma de cuantificar
los costos y beneficios intangibles:
1. Identificar las causas y efectos directos. Por ejemplo, el efecto directo de computarizar
tareas repetitivas puede ser que un nuevo sistema mejore los trabajos y mejore la moral.

552-559
2. Identificar los efectos indirecto. Por ejemplo, una mejor moral puede resultar en cerca
de 5% menos de ausentismo y un 10% menos en el ndice de rotacin de empleados.
3. Estimar el impacto econmico de los efectos indirectos para la vida estimada del
sistema. Por ejemplo, una reduccin en los retrasos de la programacin y horas extras
debidas a la reduccin de ausentismo puede ahorrar casi $ 2000 al ao, y una reduccin
en los costos de entrenamiento debidos a una reduccin en la rotacin de empleados
puede ahorrar $3000 al ao. El beneficio total (ahorro en costos) debido a una mejora en
los empleos seria entonces de $5000 al ao, o $20,000 para una vida estimada de 4 aos
del sistema. (El valor del dinero en el tiempo que no se considera en este ejemplo
sencillo).
Esta forma puede usarse para una gran variedad de costos y beneficios intangibles.
Aunque es arbitraria y subjetiva, es preferible ignorar los intangibles. Esta forma puede
describirse como hacer tangibles los intangibles.
Una forma alternativa es dejar sin cuantificar a los intangibles no se analizan
completamente, y no se hace ningn intento para llegar a un acuerdo acerca de su
importancia.
Factibilidad operacional
Esta factibilidad comprende una determinacin de la probabilidad de que un nuevo
sistema se use como se supone. Deberan considerarse cuatro aspectos de la factibilidad
operacional por lo menos. Primero, un nuevo sistema puede ser demasiado complejo para
los usuarios de la organizacin o los operadores del sistema. Si lo es, los usuarios pueden
ignorar el sistema o bien usarlo en tal formaque cause fallas o errores en el sistema.
Segundo, un nuevo sistema puede hacer que los usuarios se resistan a el como
consecuencia de una tcnica de trabajo, miedo a ser desplazados, intereses en el sistema
antiguo u otras razones. Para cada alternativa debe explorarse con cuidado la posibilidad
de resistirse al cambio al nuevo sistema. Tercero, un nuevo sistema puede introducir
cambios demasiado rpido para permitir al personal a adaptarse a el y aceptarlo. Un
cambio repentino que no se ha anunciado explicado y vendido a los usuarios con
anterioridad puede crear resistencia. Sin importar que tan atractivo pueda ser un sistema
en su aspecto econmico si la factibilidad operacional indica que tal vez los usuarios no
aceptaran el sistema o que su uso resultara en muchos errores o en una baja en la moral,
el sistema no debe implantarse.
Un aultima consideracin es la probabilidad de la absolescencia subsecuente en el
sistema. La tecnologa que ha sido anunciada pero que aun no esta disponible puede ser
preferible a la tecnologa que se encuentra en una o mas de las alternativas que se estn
comparando, o cambios anticipados en las practicas o polticas administrativas pueden
hacer que un nuevo sistema sea obsoleto muy pronto. En cualquier caso, la implantacin
de la alternativa en consideracin se convierte en impractica.
Un resultado frecuente de hallazgos negativos acerca de la factibilidad operacional de un
sistema es que este no se elimina sino que se simplifica para mejorar su uso. Otras
posibilidades son que los programas de relaciones publicas o de entrenamiento estn
diseados para enfocarse a sobreponerse ala resistencia de un nuevo sistema, o se
desarrollan formas para hacer fases en el nuevo sistema en un largo periodo para que el
cambio total, que traumatizara a los usuarios u operadores, se convierta en una serie de
pequeos cambios.
Seleccin de alternativas macro

Se elige un macro diseo como consecuencia de un ciclo de estudios de factibilidad o,

cuando se evala una serie de conjuntos de alternativas de macro diseos, se realiza
secuencialmente una seleccin de cada conjunto. Se presenta al comit directivode
sistemas las alternativas dentro de cada conjunto, junto con la recomendacin de la
alternativa preferible. En este momento se realiza un informe formal. El informe incluye un
anlisis de cada alternativa, la recomendacin del equipo de estudio y la razn de la
recomendacin; por lo general, se incluye un resumen que analiza las alternativas en
menor detalle que el cuerpo principal del informe y que incluye un resumen de la
recomendacin. Si aparecen varias alternativas como buenas elecciones no puede
realizarse una recomendacin de una sobre las dems. Durante la presentacin, los
miembros del comit directivo de sistemas hacen preguntas que reflejan una perspectiva
amplia en la organizacin y sus metas.el comit puede aceptar la recomendacin del
equipo del proyecto, pedir mayor informacin dar importancia a otra alternativa, o bien
pedir que se consideren otras alternativas. Esto tambin es un punto importante en la
investigacin del sistema, y el proyecto debera cesar en este puntoa menos que el comit
directivo de sistemas indique de modo explicito que debe continuar.
Debe realizarse una evaluacin de las alternativas de macro diseos en consideracin de
los resultados de los estudios de la factibilidad econmica, tcnica y operacional. Esta
evaluacin no se basa en un promedio ponderado de los resultados de estos estudios de
factibilidad; debe abandonarse una alternativa que no es factible tcnica u
operativamente.
Despus de que se ha seleccionado tentativamente una alternativa de macro diseo,
puede comenzarse una actividad que normalmente se asocia con la fase de implantacin:
educar y venderla a los departamentos de usuariosy operadores de sistemas. En este
punto, el equipo de trabajo del proyecto conoce la naturaleza general del nuevo sistema y
puede apoyar a su implantacion.esta educacin y venta debe ser cuidadosa y profunda
para poder vencer la oposicin al nuevo sistema y para obtener la mxima cooperacin
posible de los usuarios con el equipo de diseo de sistemas.
Diseo detallado
las actividades del sistema detallado o micro diseo son bastante diferentes para
proyectos de diferentes tipos, como la adquisicin del hardware, seleccin de sistemas
completos, compra de software, y desarrollo de software, que son las principales
alternativas. En una investigacin de sistemas de alcance amplio, tal como el desarrollo
de un nuevo sistema de cuentas por cobrar, la fase de diseo detallado tambin puede
incluir las actividades listadas en la figura 16.5.
El diseo detallado de un sistema se realiza dentro de las fronteras de la combinacin
particular de macro diseos elegida. Entre las tareas de diseo que pueden asociarse con
un proyecto importante se encuentra el diseo de sistema de entrada y salida, el del
sistema de procesamientoy la secuencia de las actividades para procesar los datos y
preparar los informes, y la especificacin de las capacidades de procesamiento de los
componentes del hardware.
En general la secuencia de las actividades varia, dependiendo de la naturaleza del
proyecto. Sin embargo, una forma comn se encuentra en la figura 16.6.en dicha figura se
disea primeroel sistema de salida que produce informes o documentos; con frecuencia
este define los datos que deben reunirse e incluirse en el sistema. Por lo general el
enfoque de las actividades de anlisis esta en definir la naturaleza de la informacin que
debe salir del sistema.

________________________________________________________________________
___________
Compaa Abercrombie
durante los siguientes cuatro meses, con base en el diseo de un nuevo sistema mas
grande con capacidades de base de datos y telecomunicaciones, el equipo de diseo hizo
lo siguiente:
1. Reviso tecnologa de la mejor relacionada con las bases de datos, telecomunicaciones
y sistemas de computo de la generacin mas reciente.
2. Estableci un diseo detallado del nuevo sistema que especificaba las capacidades
requeridas del nuevo sistema, software del sistema y dispositivos perifricos.
3. Desarrollo una configuracin general de telecomunicaciones que detalla la naturaleza
de la red de comunicaciones, la localizacin de las terminales, y la localizacin
eventual de computadoras mas pequeas para cuando el sistema se convierta en un
sistema distribuido.
4. Desarrollo un programa para la implantacin del nuevo sistema y un programa y
prioridades para la conversin de archivos y programas actualesal nuevo sistema.
Alternativas y actividades detalladas de diseo
16.4
ALTERNATIVA
Adquisicin del equipo
Seleccin de sistemas completos
Compra de software
Desarrollo de software

FIGURA

ACTIVIDAD DETALLADA DEL DISEO

Especificar las caractersticas que debe
tener el equipo
Evaluar las caractersticas que tienen el
equipo y software disponibles
Examinar en detalle las caractersticas del
software disponible: disear archivos de
datos
Disear la lgica de los flujos de datos y
disear los archivos de datos

Despus se disea la recoleccin de datos; esta actividad de diseo puede comenzar en

un rea de usuarios mediante la especificacin de que datos se reunirn y como se
convertirn a forma legible por la maquina. El sistema de captura de datos incluye el
diseo de un sistema de entrada que delinea los procedimientos del personal y especifica
los controles de entrada.
Con frecuencia la recoleccin de datos y los sistemas de entrada son extensos y con
mucho trabajo incluyendo hasta 30 actividades manuales separadas.una forma en que
puede mejorarse la eficiencia y control sobre los sistemas de informacin es buscar
formas de automatizar estas actividades; el registro y entrada de transacciones en el
punto de venta que ya se estudio como una tcnica que puede usarse para lograr esto.
Despus se disea el sistema de archivos. Este sistema incluye la determinacin de tipo
de organizacin de archivos (secuencial o secuencial indexado, por ejemplo, y disco o
cinta magntica), la longitud del registro y de los campos
________________________________________________________________________
___________
Actividades tpicas detalladas de diseo
1. diseo del sistema de reunin de datos

FIGURA 16.5

2. diseo del sistema de entrada

3. diseo del sistema de procesamiento de datos
4. diseo de la estructura de archivos
5. diseo de los procedimientos de actualizacin de archivos
6. anlisis de los requerimientos de almacenamiento de datos
7. diseo del sistema de consulta y recepcin
8. diseo del sistema generador de informes
9. diseo de los programas de aplicaciones
10.
diseo del sistema de seguridad
DISEO
DEL
SISTEMA DE
INFORMES
PRODUCCION DE DOCUMENTOS
1. - CONTENIDO DE INFORMACION
2. - FORMATOS DE INFORMES

DISEAR EL SISTEMA DE
RECOPILACION DE DATOS
DISEAR LOS SISTEMAS DE
ARCHIVOS
_
DISEAR LOS PROGRAMAS DE
APLICACIONES
DISEAR EL SISTEMA DE PROCESAMIENTO
DE DATOS
________________________________________________________________________
_____________________________________________________________________
para cada tipo de registro y su formato. Tambin se incluyen los requerimientos para
almacenamiento de datos; deben tomarse medidas de los requerimientos para
almacenamiento de datos; deben tomarse medida de los requerimientos mximos
probables de memoria de datos los registros que deben mantenerse en memoria. El
diseo de los procesamientos de actualizacin de archivos incluye la determinacin de
quien tiene la autoridad de actualizar archivos y parea establecer procedimientos para
borrar registros, agregarlos y realizar otras tareas de mantenimiento de archivos. Si el
sistema tendr capacidad de consulta, el diseo debe especificar como se determina el
derecho para obtener informacin desde terminales remotas, los cdigos de entrada que
se usaran para obtencin de informacin, y el tipo de dispositivos; de salida que se
utilizaran, junto con otras consideraciones relacionadas.
Cuando se ha determinado el diseo de archivos, puede percibirse con mas facilidad la
estructura necesaria y la organizacin de los programas de aplicacin. El diseo de los
programas de aplicacin es una de las tareas principales en la investigacin de sistemas
que implican programacin esta actividad incluye la determinacin del numero de
programas y la funcin de cada uno; por ejemplo, un programa de nominas podra dar de

alta o baja y borrar nuevos empleados del archivo maestro en forma simultanea o bien
cada una de estas funciones podra realizarse con un programa por separado. El diseo
de programas tambin incluye la preparacin de diagramas de flujo de sistemas, que
muestran los flujos generales de informacin a travs del sistema, y diagramas de flujo
de programas, que muestran toda la lgica del nuevo sistema que debe estar contenido
en cada programa. En idea, esta actividad de diseo esta separada de la actividad de
implantacin que consiste en la escritura y correccin de los programas. Sin embargo, en
la practica, estas actividades estn muy relacionadas, y la programacin para algunos
programas se realiza antes de que comience el diseo de otros, lo cual muestra que las
actividades de las fases de la investigacin de sistemas no se realiza en forma
completamente secuencial sino que se realizan en forma simultanea. Por cierto, a
menudo una persona designada como analista programador primero disea con detalle
una aplicacin y en segunda la implanta escribiendo los programas antes de disear con
detalle la siguiente aplicacin del sistema.
Finalmente, como se muestra en la figura 16.6, se disea el sistema de computo de
procesamiento de datos, el cual, por lo general incluye el desarrollo de un manual de
procedimientos para operadores de la computadora que especifica los pasos que deben
de seguir los operadores para procesar una aplicacin particular. Cuando deben escribirse
programas de computo, el diseo detallado del sistema de procesamiento de datos
incluye con frecuencia el desarrollo de diagramas de flujo de datos, los cuales muestran
como fluyen estos a travs del sistema. Durante la fase de implantacin, estos diagramas
de flujo sirven como base para la escritura de los programas de computo.
Como se noto, no existe secuencia en las actividades de diseo detallado: la secuencia
depende de la naturaleza del proyecto. A menudo, varias tareas de diseo detallado se
encuentran en proceso simultaneo. Las actividades de diseo detallado son fluidas e
interactivas por naturaleza; por tanto, por ejemplo, al progresar el trabajo de diseo en las
estructuras de archivos, se proporciona retroalimentacin que afecta las otras actividades
de diseo. Las actividades tpicas de diseo se encuentran listadas en la figura 16.5 sin
ningn orden particular.
Controles de sistemas
durante el diseo detallado, debe ponerse atencin a incluir controles sobre la entrada de
datos, su procesamiento e informes y otros tipos de salidas. Estos controles deben ser
consistentes con un sistema de informacin de control preestablecido que este basado en
la percepcin de la organizacin de sus riesgos de seguridad de datos. Adems, los
controles sobre los sistemas de computo se convierten en una parte del esquema general
de control interno. Si se necesita un control particular en un sistema no incluido en el
sistema inicial, por lo general es difcil incorporarlo despus de que el sistema este
instalado.
Controles generales
Estos controles de sistemas se clasifican en dos clases: controles generales y controles
tcnicos. Los generales son aquellos aplicables a todas las aplicaciones, y constituyen
una gran parte del marco general de controles preexistentes. Las previsiones para la
supervisin de las actividades, las polticas administrativas con respecto ala
documentacin, las practicas de desarrollo de software, las polticas y procedimientos de
correccin de errores, y las polticas de auditorias internas en relacin con los sistemas de
informacin son ejemplos de controles generales.
Controles tcnicos

estos son los que algunas veces son llamados controles de aplicaciones, y son son
controles sobre aplicaciones individuales o conjuntos de aplicaciones. Estos son controles
sobre entrada de datos, procesamiento de datos, salida de datos y distribucin de
informes. Los controles de entradas en lotes son un ejemplo de ello; consisten en llevar
cuentas de los lotes de entrada de transacciones usando tcnicas tales como cuentas de
registros y etiquetas de transmisin de lotes.
Hay una variedad de tipos de controles de procesamiento, muchos de los cuales se
encuentran escritos en los programas. Los programas pueden incluir transacciones, por
ejemplo, que aseguren que los datos de un campo individual del registro sea numrico o
alfabtico, dependiendo en que forma sea correcto. Tambin se incluyen comprobaciones
de limitasen programas para asegurar que las cantidades mximas o mnimas esperadas
no se excedan, por ejemplo, que la paga para una clase particular de empleados no sea
menos del salario mnimo o mayor que $10.00 por hora, que la paga total no exceda
$800.00 por semana para esa clase de empleados, o que las horas totales por semana no
excedan 80 por empleado. Cada uno de estos controles de procesamiento deben
disearlo los diseadores de programas y despus los programadores deben traducirlos a
instrucciones especificas dentro de un programa.
Otros controles de procesamiento estn relacionados con asegurarse que los operadores
de la computadora procesen los trabajos en forma adecuada. El libro de corridas que
detalla los pasos de procesamiento y un requerimiento de que un operador firme un
trabajo de tal forma que la responsabilidad del mismo pueda saberse, son ejemplos de
controles de procesamiento. Hay muchos otros controles de procesamiento.
Los controles de salida consisten en tcnicas para asegurar que todas las transacciones
que entraron han sido procesadas completamente y que estn reflejadas en los informes
u otra salida producida por el sistema. Los controles de distribucin consisten en
procedimientos que aseguren que los documentos e informes se distribuyen a tiempo a
todas las personas en la lista de distribucin y a nadie mas.
Controles usuarios
los controles de usuario son otro tipo de control. Los grupos de usuarios tienen la
responsabilidad de estar tan seguros como sea posible de que el procesamiento de datos
se ha realizado correctamente. Con frecuencia los usuarios desarrollan controles
elaborados, tales como calcular por adelantado lo que deberan ser algunos de los
resultados. Con frecuencia, los controles de usuarios son tan elaborados que son casi una
duplicacionparcial del procesamiento que realiza el sistema de computo, lo cual puede ser
demasiado ineficiente. Los diseadores de sistemas deben ayudar a disear controles
para los usuarios que les permitan saber cuando han ocurrido errores durante la entrada
de datos, procesamiento o salida.
Controles de correccin de errores
La correccin de errores es una tarea compleja. Es seguro que van a ocurrir, sin importar
que tan bueno sea el nuevo sistema. Adems, es mucho mayor la probabilidad de
cometer un segundo error al corregir uno existente que la probabilidad de cometer otros
tipos de errores. Por tanto, los procedimientos de correccin de errores deben disearse
por adelantado y deben hacerse con sumo cuidado. Con frecuencia, los procedimientos
requieren que los errores de un tipo particular se acumulen durante una semana o mas, y
despus se corrijan todos al mismo tiempo. En generalse usan firmas cuando se han

comprobado las correcciones de errores en forma independiente y se han encontrado que

son correctas.
Controles de investigacin de sistemas
Deben controlarse los diseos de sistemas. Nombrar un comit directivo de sistemas,
usar sistemas de control de proyectosy proporcionar buena supervisin son buenos
mtodos de control de investigacin de sistemas. Tambin se requieren mtodos
adicionales. Estos incluyen la institucin de un sistema de autorizacin para cada tarea
dentro de un proyecto de sistemas (como autorizar la escritura de un programa especifico)
y usar controles que aseguren que el nuevo sistema este bien probado y libre de errores.
Durante una investigacin de sistemas son muy importantes los procedimientos que
garanticen que los controles existentes en el sistema actual continen vigentes mientras
se disea e implanta un nuevo sistema. A menudo se tiene la tentacin de no tomar en
cuenta los controles que pronto se van a eliminar con un nuevo sistema. Sin embargo,
cuando un nuevo sistema se esta diseando, probando e instalando, el sistema antiguo
es mas vulnerable debido a la confusin general causada por estas actividades.
Software: Hacerlo o comprarlo?
Una decisin critica durante el diseo de sistemas es si los programas deben comprarse o
si la organizacin debe desarrollarlos. Como ya se indico, las actividades durante la fase
del diseo son muy diferentes si el software se compra o si se disea y programa en la
organizacin.
Hasta hace algunos aos las organizaciones tenan poco para elegir en cuanto a si se
desarrollaban o compraban los programas por que haba relativamente pocos programas
de calidad. Sin embargo, ahora el mercado se ha llenado, y se ofrecen a la venta miles de
programas de alta calidad. Por ejemplo, una organizacin que busca un programa de
cuentas por cobrar, puede ser capaz de elegir entre docenas de programas de buena
calidad en el mercado, aunque por supuesto no todos estaran escritos para, o serian
adaptables al sistema de computo particular de dicha organizacin.

560.567
Cada organizacin ( y cada organismo que s dueo de un sistema de microcomputadora)
debe de decidir si compra el programa de computo deseado o desarrollarlo, diseando,
codificando y despus dejar libre de errores el programa hasta que este completamente
probado. Varias consideraciones influyen en esta decisin. Una es la escasez de
programadores calificados. Si existen muy pocos programadores para desarrollar un
programa, la organizacin puede verse forzada a comprar paquetes que de otra forma
desarrollara.
Otras consideraciones es el incremento en el costo de la programacin y en el retraso de
programas esperando su desarrollo en la organizacin.
En muchos casos los programas disponibles para compra son mas complejos que
los programas que quizs desarrollara la organizacin. Por ejemplo, muchos de los
programas de aplicaciones estn totalmente integr5ados a otros programas de
aplicaciones; por tanto, al adquirir un conjunto de programas de un vendedor, la
organizacin esta adquiriendo un sistema completamente integrado. Un ejemplo de esto
son los sistemas de planeacin de requerimientos de materiales MRP que ya se estudio.
Tambin estn disponibles varios conjuntos de programas de contabilidad integrados a un
sistema de contabilidad general que sirve como la columna vertebral de todo un sistema
de contabilidad. Esta integracin es un incentivo poderoso para comprar un lugar de
desarrollar programas.
Aunque cada decisin de si un programa debe compararse o desarrollarse
depende de circunstancias particulares , existen varias generalizaciones. Una es que para
sistemas de microcomputadoras, en general debe de compararse un programa y no
desarrollarse si se puede encontrar uno adecuado. Esto se debe en parte a que los
programas para microcomputadoras son bastante baratos, casi siempre en el rango de
$100 a $1,500, y en parte a que los usuarios de microcomputadoras tienden ase menos
capases de desarrollar sus propios programas de aplicaciones.
Con respecto a las decisiones para programas para computadoras grandes, son
evidentes d0os tendencias generales. Primero cada vez mas se compran programas de
aplicaciones a grande escala. Es caracterstico de una organizacin mediana o grande
tener su staff de procesamiento de datos de programadores cuya capacidad de modificar
programas comprados llenan las necesidades de la organizacin con mayor facilidad.
Segundo, cada vez mas los programas especializados de tamao menor se estn
desarrollando usando lenguajes de productividad. Se espera que la disminucin en el
costo del desarrollo de estos programas los har mas atractivos sin contar con la
eficiencia de su procesamiento.
Aunque el supuesto de que los programas para microcomputadoras deben
comprarse si es posible, en el caso de programas para computadoras grandes debe de
realizarse un anlisis cuidadoso para determinar a los programas de comprarse o
desarrollarse en general, los pasos de este anlisis son:

1.-Determinar que procesamiento debe de realizarse. (esto se logra durante el anlisis de

sistema.)

consideraciones en decisiones de hacer o comprar software

1.- Hasta que punto cada programa disponible satisface las especificaciones de
requerimiento del sistema.
2.- Capacidad de los programas de modificarse al cambiar las necesidades.
3.- Hasta que punto cada programa pude hacerse especficamente para las
necesidades de la organizacin y el costo de dicho proyecto.
4.- Eficiencia de procesamiento de cada programa.
5.- Caractersticas de seguridad e integridad de cada programa.
6.- Capacidades extras proporcionadas por cada programa que son bonitas pero
no necesarias.
7.- Numero y naturaleza de pasos de procesamiento requeridos por cada programa
y la mano de obra que requieran.
8.- La reputacin de servicio y mantenimiento de cada proveedor de software.
9.- Lo amistoso con el usuario de cada programa.
10.- provisiones del contrato de cada programa.
11.- El costo del paquete y del soporte continuo del proveedor.
12.- La capacitacin proporcionada por cada vendedor.

2.- Examinar el mercado de paquetes que tienen potencial para lograr el procesamiento
requerido.

3.- Comparar los paquetes disponibles entre si, con la alternativa de desarrollar el
programa dentro de la organizacin.
Como parte del paso 3 deben considerares varios criterios. Estos se muestran en la figura
16.7
Los candidatos mas probables para ser adquiridos son los de contabilidad general,
nomina y otros de contabilidad mas o menos estndar, as como paquetes de personal.
Con frecuencia, un programa actual que se desarrollo en la organizacin hace muchos
aos continua funcionando, aunque ya no es satisfactorio y esta ser reemplazado, por
esta en prioridad para su desarrollo; puede ser sensato remplazar tal programa por otro
comprado.
Con frecuencia los programas comprados son mas econmicos, aun cuando
consideramos los posibles costos de modificacin y mantenimiento y los de
entrenamiento. Los programas comprados tambin pueden ser mas confiables que los
escritos por programadores en una organizacin para su propio uso, ya que los
programas comprados han sido probados cientos o miles de veces en otras
organizaciones. Los programas de mayor xito en el mercado estn tan bien escritos que
procesan con eficiencia y utilizan un mnimo de espacio en la memoria, y atributos que
son especial importante para programas de microcomputadoras. Finalmente, muchos
paquetes disponibles para su compra tienen varios extras que la organizacin puede no
necesitar con desesperacin y no decaera pagar para que los programaran pero que
pueden ser tiles y se proporcionan sin costo extra; ejemplos de esto son generadores
de informes y una amplia variedad de tipos y formatos posibles de informes.
Tambin hay desventajas en la compra de organismo. Es raro el caso en que un
programa es exactamente lo que la organizacin necesita. Si se requieren modificaciones
a un programa comprado, nadie en la organizacin tiene la experiencia en su desarrollo y
puede ser que las modificaciones sean muy difciles de realizar, o hasta pueden no estar
permitidas por el contrato de compra.
Muchos programas comprados requerirn modificaciones para satisfacer las
necesidades propias de la organizacin en forma satisfactoria. Una de modificaciones la
revisin del programa, que puede hacer el proveedor o programadores de la organizacin.
A menudo solo se proporcionan los pr0ogramas en cdigo objeto; debido a que este
cdigo es casi imposible de revisar, una organizacin que anticipa que querr revisar el
programa debe de insistir, como parte del contrato, que se le proporcione un programa en
cdigo fuente. Si el comprador tiene que realizar modificaciones, el lenguaje de cdigo
fuente debe ser tal que los programadores de la organizacin deben estar familiarizados
con el. Para la mayora de los programas que devn de revisarse antes de su uso, el
costo de revisin esta entre 10 y 30% de su costo original.
Los programas comprados tienen, por lo general, una receptividad construida
dentro de ellos, al menos para modificaciones menores, o pueden seleccionarse opciones
dentro del programa; esto en muchos casos es mas que suficiente. Por ejemplo, pueden
elejirse varias formulas diferentes de depreciacin, as como la posibilidad de agregar con
facilidad campos a los registros o de cambiar longitudes en ellos, y la opcin de datos
numricos, alfabticos, o alfanumricos. Usando estos y otros cambios que pueden

implantar con facilidad, en general es posible adaptar los programas comprados hasta
cierto punto, pero rara vez pueden adaptarse por completo a las necesidades de la
organizacin.
La alternativa a la modificacin de un programa comprado es cambiar las practicas del
negocio para conformarse a la estructura del programa. Para la mayora de las
organizaciones esta no es una alternativa atractiva, pero en algunas circunstancias se
proporciona algn incentivo por la gran cantidad de ahorro que resultara de usar un
programa comprobado sin revisin. Por ejemplo, el programa puede requerir que ciertos
datos que normalmente no se renen en una organizacin, se introduzcan para que el
programa funcione. Si se tiene la alternativa entre realizar una modificacin costosa para
que el programa opere sin ciertos datos y la reunir rutinaria de ciertos datos para ser
capturados aunque la organizacin no los necesite, puede ser preferible elegir el segundo
curso de accin.
FUENTES PARA COMPRAR PROGRAMAS.
Hay miles de programas disponibles para su compra. Los fabricantes de computadoras,
casas de software grandes y pequeas ( compaas que se especializan en desarrollar
software ), y tiendas de computadoras son posibles fuentes. Con frecuencia, estas se
anuncian en todo el pas en revistas de computacin semanales tales como INFOWORLD
y en revistas mensuales como DATAMATION y BYTE, otros muchos estn disponibles
para comprarse por correo.
Otras fuentes de programas son los grupos de usuarios, o asociaciones de
usuarios de un sistema de computo particular. Los grupos de usuarios reconocen la
necesidad de un programa especifico, cuyo desarrollo pueda hacer un miembro de la
organizacin y ponerlo a la disponibilidad de los dems. Por ejemplo, los programas de
utilitaria y extensiones del sistema operativo actuales los desarrolla, en forma regular un
miembro de la organizacin y los distribuye a travs del grupo de usuarios.
Es arriesgado comprar programas ,algunos son difciles de instalar, puede haber errores
no detectados que aparezcan despus, y muchos no se han desarrollado y probado en
forma adecuada o puede ser que aun no estn disponibles para su entrega cuando se
anuncian. Hay un elemento en el mercado de software que no esta suscrito a las practicas
ticas del mercado, cuando esta es posible, es tratar solo con proveedores conocidos y
que tengan buena reputacin y proporcionen soporte despus de la venta como
capacitacin, respuesta a consultas, y correcciones en los defectos del programa.
ESTUDIO DE PROGRAMAS COMPRADOS.
Es muy difcil el estudian de programas considerados para su compra. Por fortuna, varias
organizaciones independientes estudian objetivamente los programas a la venta y
reportan sus evaluaciones. Dichos estudios estn disponibles por auerbach, Datapro,
y otras compaas de evaluacin por un pago. Tambin, revistas como Datamation
publican peridicamente los resultados de anlisis comparativos de varios paquetes
software de un tipo general. Estas evaluaciones no solo son tales con respecto a la
comparacin de paquetes particulares de software, sino que tambin proporcionan
indicaciones de las capacidades tpicas de una clase de programas.

En primer caso para estudiar un programa es determinar, por escrito, si cuenta con
las especificaciones de requerimientos durante el anlisis de sistemas. Como mnimo,
deben de hacerse las siguientes preguntas.
1.- puede el programa proporcionar los reportes necesarios?
2.- tiene el programa la capacidad adecuada en trminos del numero de transiciones
que puede procesar?
3.- cuantas corridas de procesamiento de datos se requieren para completar una tarea
de procesamiento de datos?
4.- cuanto tarda el programa para procesar?
Los usuarios actuales de un programa son una fuente de informacin valiosa acerca de su
desempeo. En general describen tanto los problemas no anticipados como los beneficios
no esperados de un programa particular. Tambin son una fuente de informacin valiosa
acerca de los servicios proporcionados por los proveedores; por ejemplo, saben si un
proveedor ha cumplidos con las promesas de fechas de entrega de modificaciones ( si las
hay ), si ha sido eficaz en encontrar o corregir problemas, si ha proporcionados mejoras
gratis o a un precio nominal cuando estas estn disponibles. Tambin saber que tambin
ha logrado sus expectaciones de desempeo, que tan fcil puede adaptarse para
satisfacer las necesidades, y que partes del contrato son demasiado restrictivas, as como
que tan fcil es cambiar dichas provisiones del contrato.
Los proveedores de buena reputacin proporcionan listas de compradores
anteriores del programa. Como existe una tendencia natural para incluir en la lista solo los
nombres de los clientes mas satisfechos, es aconsejable aconsejar a cada cliente que se
consigna los nombres de otros compradores. Si los nombres no estn en la lista
proporcionada por los vendedores, es especialmente importante lograr el contacto con
dichos compradores.
Una ultima manera de evaluar un programa es procesar datos con el en la
computadora de la organizacin. A menudo se le llama prueba importante del software,
cuyo propsito es usar las transacciones de la organizacin para estudiar la velocidad de
procesamiento del programa y que tan amistoso es con el usuario y la operacin de
caractersticas especiales, como capacidades de escribir informes.
La preparacin de una de estas pruebas puede considerarse demasiado exigente,
o solo como el programa mas prometedor. Con frecuencia, aunque es til, esta prueba
solo es indicativa, ya que solo la experiencia con un programa en operacin real en un
periodo largo de tiempo proporciona un aprueba completa de sus ventajas y limitaciones.

568-575
Fase de implantacin
Esta fase es el proceso de instalacin del sistema diseado, incluyendo cualquier tipo de
software comprados. Mientras las actividades de esta fase pueden variar mucho, en la
figura 16.8 se muestran las que se encuentran con mas facilidad. Igual que el diseo de
sistemas, la implantacin de sistemas se apoya fuertemente en habilidades tcnicas. En
general la implantacin de sistemas es una actividad demasiado estructurada.
Educacin y entrenamiento personal
Con frecuencia se requiere mucha educacin y entrenamiento del personal con un nuevo
sistema. Los operadores de computadoras deben tener entrenamiento para correr un
nuevo sistema, los programadores pueden necesitar entretenimiento para completar la
implantacin del sistema o para mantenerlo, los operadores de entrada pueden necesitar
entrenamiento, y los usuarios deben educarse acerca de las capacidades del sistema, as
como para saber como reunir y preparar los datos para el mismo.
En general la educacin y entrenamiento se extienden en un largo periodo y, para poder
terminarse en momento en que el sistema este listo para operacin, deben iniciarse tan
pronto se conozcan las caractersticas generales del sistema. Asimismo, la educacin
temprana ayuda a identificar posibles problemas de relaciones personales en forma
rpida, a la vez que asegura que los usuarios y operadores cooperarn y usaran el nuevo
sistema. Durante las sesiones de enseanza se describe el nuevo sistema, se describe el
nuevo sistema y se analizarn las ventajas operadas sobre al sistema antiguo.
Actividades de la fase de implantacin de sistemas
Educacin y capacitacin de personal
Programacin
Preparar el lugar
Instalacin y prueba del equipo
Instalacin y prueba del equipo comprado
Conversin de archivos
Uso del nuevo sistema
Prueba final y aceptacin
Documentacin
El entrenamiento especial de diseadores de sistemas puede proceder a la terminacin
de la fase de anlisis de sistemas. A menudo los diseadores acuden a los programas de
entrenamiento para acudir al conocimiento tecnolgico necesario para realizar estudios de
factibilidad correctos y emitir juicios bien fundados. Si por, ejemplo, una alternativa macro
considerada en un sistema de base de datos, pero nadie en la organizacin tiene la
experiencia
de bases de datos, los diseadores deben recibir entrenamiento
especializado antes de poder decidir si se necesita una base de datos y una estructura de
archivos y un Sig especfico. Al final se requiere an mas entrenamiento especializado
para disear detaladamente los archivos de bases de datos.

Programacin.
La programacin es parte importante de muchas investigaciones de sistemas. Las
especificaciones del diseo de los programas deben desarrollarse con cuidado usando
diagramas de flujo y otras tcnicas, y las actividades de programacin deben monitoriarce
con sumo cuidado. Con frecuencia, el esfuerzo de programacin requerido es mucho
mayor que lo que se anticip, y los programas terminados no satisfacen la calidad
esperada. Tambin, los nuevos mal desarrollados despus de la implantacin, pueden
llavar con facilidad a prdidas de recursos, del mismo modo que al causar errores en los
archivos de la computadora se ocasionan facturas incorrectas.
Los procedimientos utilizados para controlar el desarrollo de programas son similares
tanto al desarrollar los nuevos programas como al modificar los ya existentes a la figura
16.9 muestra un problema de procedimientos de control para uso en ambas situaciones.
El sistema de control rene las actividades de diseo de programas y su implantacin. El
artculo tres de la citada figura sugiere que otra computadora no usada para el
procesamiento de datos de produccin de rutina, puede serlo para el desarrollo de
programas. Esto proviene contra estorbar la programacin del procesamiento da datos de
rutina, y a la vez que facilita la estructura de programas en linea los cual aumenta la
eficiencia de los programadores , y elimina la posibilidad de que estos alteren o interfieran
con el software usando para el procesamiento normal de los datos mientras desarrollan su
propios programas . en general, las grandes organizaciones son las que dedican un
sistema de cmputo por las actividades de desarrollo de programas.
Los esfuerzos de programacin deben conducirse con eficiencia, la cual se promueve con
un bien sistema de administracin de proyectos. La eficiencia tambin se mejora con las
tcnicas de programacin estructurada. Esta ltima reduce un programa, de otra forma
ser monoltico, a varios mdulos pequeos unidos para el procesamiento. Cada mdulo
solo tiene un punto de entrada y un solo de salida (una interface con mdulo precedente
y una con uno siguiente), sin necesidad de realizar ramificaciones, como solo ejemplifican
las instrucciones GO TO de los programas. La lgica de los programas estructurados es
mucho mas simple y sencilla de entender que la de otros programas , lo cual permite su
escritura y revisin mas fcil.
El diseo, la documentacin y los estandares de definiciones de los datos tambin son
ingredientes importantes en la eficiencia de programacin. Los estndares de diseo
tratan de los asuntos tales como los formatos de archivos y las convenciones de
diagramas de flujo. Los estndares de documentacin ponen en papel los requerimientos
para las descripciones narrativas, de diagramas de flujo y otras descripciones de
programas. Un diccionario de datos rene los estndares de datos que eliminan
definiciones mltiples de los datos de los mismo artculos, de otra forma podrian estar
presentes een diferentes archivos y programas.
Ya sea la instalacin del procesamiento de datos sea grande o pequea, se necesita un
programa de estndares. Un programa de estndares es, de modo particular, importante
en pequeas instalaciones, porque una sola persona puede estar relacionada con un
sistema, si esa persona puede estar relacionada con un sistema; si esa persona se va, la
documentacin estandarizada puede permitir, al que lo reemplace, entender el sistema
con mayor rapidez. Desafortunadamente mantener los estndares se convierte en algo
molesto bajo la presin de las fechas lmites de terminacin de sistemas. Para asegurar la
continuacin de un programa de estndares, debera prepararse un manual que detalle

los estndares de la instalacin. Los analistas y programadores deben entenderlos y

asegurarse de su cumplimiento . por supuesto los estndares requieren revisin peridica.
Otra forma de mejorar la eficiencia del desarrollo de programas es mediante el uso de
terminales en la lnea para realizar la programacin. Para algunos grupos de
programacin, se supone que las eficiencias de la programacin en la lnea duplican la
productividad de los programadores.
El desarrollo de software o mantenimiento de proyectos a menudo causa retrasos en el
procesamiento de datos , mayores ndices de error y caos general en la organizacin. La
capacidad de desarrollar programas de procesamiento con sutileza y hacer cambios poco
a poco y en su momento, en general es la base principal sobre la cual la administracin
evalua el desempeo de procesamiento de datos no han sido capaces de lograr en forma
eficiente el desarrollo y mantenimiento de programas.
Sistema de procedimientos para controlar el desarrollo de nuevos y modificados
figura 16.9
1. Debe someterse a un periodo por un usuario o analista de sistemas al gerente de
programacin incluye:
Breve descripcin del programa o cambio al programa requerido
Razn del por que se necesita el programa o el cambio del programa
2. Se establece un presupuesto de tiempo y se asigna un analista de sistemas
programador o equipo al proyecto.
3. Se determina el desempeo del programa, programacin, y leberacin de errores al
programa (quizas se reserva una computadora separada para desarrollo de
sistemas).
4. Se documenta el programa o el cambio, la documentacin generalmente incluye al
menos:
Una descripcin narrativa de los diagramas de flujo del programa o del cambio
Una copia del listado del programa
5. Un supervisor de control de calidad de programas prueba el programa
6. Aprueban formalmente el programa:
Quin realizo el pedido
El analista programador
El supervisor de control de calidad
El gerente de programacin
7. El programa anterior (si lo haba) se desaparece de la biblioteca de programas, y se
reemplaza con el nuevo programa con el programa con el cambio.
Preparacin del lugar para la instalacin del equipo
Si se adquiere equipo nuevo, debe prepararse un lugar para la computadora. La
seguridad fsica debe tener una preocupacin principal cuando se desempea un lugar
para una computadora. La seguridad fsica requiere cuidado de almacenamiento a prueba
de fuego para archivos y programas crticos, cerraduras de seguridad en loas puertas de
lugar e instalaciones de deteccin y prevencin de incendios. La seguridad fsica debe
considerarse como parte de un programa general de seguridad que incluya seguridad con
palabras clave y otras precauciones.
Los sistemas de computadoras grandes requieren un ambiente controlado
cuidadosamente, incluyendo control de temperatura que incluye sistemas de aire

acondicionado, control de humedad y control de polvo. Un aspecto crtico de ambiente es

una fuente de poder continua y estable. Con frecuencia se requieren sistemas de poder
auxiliar y regulacin de la misma para asegurar la obtencin de correinte regulada.
En general, es mnima la preparacin del lugar que requieren las microcomputadoras, sin
embargo. Sin embargo una fuente de poder controlada es importante para las
microcomputadoras. Son muy comunes las variaciones menores en el suministro de la
electricidad de la fuente de poder elctrica ordinaria, lo cual puede daar los delicados
dispositivos elctricos de una microcomputadora .
Es probable que la mayora de las reparaciones de las microcomputadoras se deban a
fallas en el suministro de energa elctrica. Puede proveerse alguna proteccin mediante
dispositivos mediante dispositivos de regulacin de variaciones, disponibles por menos
de $100 dlares. Los componentes electrnicos de las microcomputadoras tambin son
sensitivas al humo, por lo cual generalmente se prohibe fumer cerca de las
microcomputadoras.
As como es importante en el diseo de una cocina u otro espacio de trabajo, la eficiencia
operativa es una preocupacin en el diseo del lugar. El equipo debe estar localizado
fsicamente de tal forma que se minimice la cantidad de esfuerzo requerido para operar
monitorear todo el sistema de cmputo. Tambin debe ponerse atencin a la ergonoma
que pertenece al diseo de estaciones de trabajo personales para que sean menos
fatigantes y mas eficientes en su operacin. La localizacin correcta de los teclados, el
tipo de intensividad de luz las pantallas y su altura relativa al nivel visual, son
consideraciones ergonmicas. Tambin se deben cuidar los niveles de ruido; en particular
muchas impresoras tienen elevados niveles de ruido y debe usarse un sistema depresor
de ruido con una caja aislada. Con frecuencia se pone muy poca atencin a estos otros
factores de comodidad humana al disear sistemas de informacin.
Instalacin y verificacin de equipo de programas.
La instalacin y verificacin de un equipo nuevo y de los programas mas complejos
normalmente estan supervisados por los proveedores. Es caracterstico que los
ingenieros de la compaa vendedora instalen el equipo de hardware y realicen pruebas
para ver si funciona en forma correcta. Por lo general los representantes de los
vendedores colocan los programas adquiridos en la computadora de la organizacin o
proporcionan instrucciones detalladas de cmo hacerlo. Los sistemas operativos de las
computadoras que no son estndares, debido a cambios realizados por los
programadores de la organizacin, a menudo complican la introduccin de paquetes de
software comprados para el sistema; un sistema operativo aun puede requerir
modificaciones a las instrucciones de control de un nuevo programa antes de que el
paquete pueda comunicarse con el.
Conversin de archivos.
Si se disean nuevos archivos para remplazar los actuales, los datos de estos ltimos
deben convertirse para que sean compatibles con el nuevo formato y estructura del
archivo, y despus deben entrarse en los nuevos. Esto puede ser una enorme tarea que
puede ocupar el tiempo de varias personas durante varias semanas o meses. Una
conversin realizada normalmente requiere imprimir los contenidos de los archivos de
datos actuales y el uso de estas impresiones como base para recuperar los datos en

forma alterada segn lo requieren los nuevos estndares del archivo. Por ejemplo los
campos de registros en el archivo nuevo pueden reordenarse, agregarse o borrarse
campos, o bin alterarse su longitud; los datos existentes que se recuperan deben
conformarse en este nuevo formato. Durante la conversin de archivos, son muy comunes
los errores de entrada.
En forma alternada se pueden escribir programas de cmputo para convertir los datos de
los archivos existentes al formato de los nuevos, y pueden hacerse otros programas para
transferir, electrnicamente datos de los archivos viejos a los nuevos. Esta actividad de
programacin puede llevar mucho tiempo y por supuesto despus de que se ha terminado
la conversin , los programas de conversin ya no tienen ningn valor. La desicin si se
debe realizarse en la forma manual o por medio de programas de conversin, es una
desicin importante en el proyecto grande de sistemas.
Documentacin
La documentacin consiste en material que explica las caractersticas tcnicas y la
operacin del sistema. La documentacin es esencial para proporcionar entendimiento de
un sistema a quin lo vaya a usar para mantenerlo , para permitir auditorias del sistema y
para ensear a los usuarios como interactuar con el sistema y los operadores como
hacerlo funcionar.
Existen varios tipo de documentacin. La de programas explica las razones y la lgica de
un programa e incluye descripciones narrativas, diagramas de flujo, listados de programas
y otros documentos. La del usuario en general en menos tcnica y explica a los usuarios
en forma general la naturaleza y capacidades del sistema y como usarlo; esta
documentacin casi siempre esta en forma de manual.
Muchas organizaciones tiene los que se les llama un programa de documentacin. Este
consiste en una poltica formal cuya documentacin se muestra como algo que debe
prepararse en forma rutinaria para cada programa de cmputo , archivo y nuevos
sistemas. Los estndares de documentacin a los cuales deben adherirse tambin son
una parte del programa de documentacin; estos estndares especifican que
documentacin debe proporcionarse y su organizacin. La acepcin formal de un
programa, archivo, o sistema tambin siugnifica que la documentacin casi siempre esta
en forma manual.
Muchas organizaciones, tienen lo que se llama un programa de documentacin. Este
consiste en una poltica formal cuya documentacin se muestra como algo que debe
prepararse en forma rutinaria para cada programa de cmputo, archivo y nuevos
sistemas. Los estndares de documentacin a los cuales deben adherirse tambin son
parte del programa de documentacin; estos estndares especifican que documentacin
debe proporcionarse de su organizacin. La aceptacin formal de un programa, archivo o,
sistema tambin significa que la documentacin ha sido revisada y aceptada. Sin un
programa en documentacin y funcin, existe una tendencia a no proprcionar la
documentacin o solo cuando sea solicitada.
Conversin de sistemas
Cuando el nuevo sistema (o parte de el) esta listo para su operacin, se usa uno de
cuatro mtodos que arranque:

1.
2.
3.
4.

Operaciones directas
Arranque directo
Arranque en fases
Estudio piloto

La menos riesgosa de estas es la de operaciones en paralelo, que usa con frecuencia

cuando se adquiere un nuevo sistema o cuando un nuevo paquete de software reemplaza
un conjunto de programas actuales. El sistema o paquete nuevo se corre paralelamente
con el antiguo por un periodo de das, semanas o meses; esto es, tanto el nuevo sistema
como antiguo procesan las mismas transacciones. Un beneficio de las operaciones
paralelas es que proporciona la seguridad (antes desmantelar o deshacer el sistema
antiguo) de que el nuevo sistema funciona correctamente y de que lograra realizar el
trabajo; el descubrimiento y una falla anticipada o un defecto serio en el nuevo sistema
despus de que el antiguo sea desmantelado puede tener como resultado retrasos en el
procesamiento de datos o un alto gasto adicional.
Adems un nuevo sistema puede causar muchos errores, sin importar que tan bin
diseado e implantado est, correr los datos atravs de ambos sistemas en paralelo
permite la comparacin de los resultados del procesamiento por el nuevo sistema (algo no
se sabe el principo) con los resultados del sstema antiguo. A pesar de sus desventajas , el
sistema antiguo proporciona salidas cuya fiabilidad es conocida, y esta comparacin
proporciona en forma de detectar problemas en el nuevo sistema.
El arranque directo es la forma mas riesgosa porque significa reemplazar el antiguo
sistema con el nuvo sin estar seguros de que el nuevo sistema funciona. El arranque
directo puede causarse cuando la conversin debe realizarse rpidamente, cuando no
hay suficiente espacio o personal para operar ambos sistemas, o cuando existe un alto
nivel de confianza de que el nuevo sistema funcione en forma satisfactoria.
Un arranque en fases comprende la secuenciacin de las actividades de investigacin de
sistemas para que diseen e instalen mdulos separados en momentos diferentes;
entonces cada uno puede comenzar la operacin tan pronto como este listo. Debido a que
cada mdulo solo es una parte de todo el proyecto cualquier problema de operacin con
un mdulo especfico es poco probable que interrumpa las operaciones con gravedad y,
cuando llega a pesar, general puede corregirse antes de que el siguiente mdulo
comience a operar. Por ejemplo una base de datos puede estar completamente diseada
y despus implantarse y ponerse en operacin en mdulos, siendo cada mdulo un
archivo de datos agregado a la base de datos.
El arranque por estudio piloto se usa cuando eventualmente se implantan muchos
sistemas idnticos o similares en varios departamentos, sucursales o divisiones. El
sistema se disea, pero se implanta al principio y se prueba solo en una de las unidades
de la organizacin. Cuando se encuentran y corrigen todos los problemas, el sistema se
implante en otras unidades de la organizacin.
Aceptacin del nuevo sistema
Cuando se ha usado cada una de las funciones de un nuevo sistema o programa y este
libre de errores en procesamiento de datos normal, al menos una vez debe hacerse una
divicin detallada. Esta revisin vincula una determinacin sistemtica de todos los
errores anteriores que han sido resueltos con el nuevo sistema. Despus de la revisin, el

sistema acepta con toda formalidad; y no esta a prueba y se usa en forma rutinaria para
las operaciones. A menudo su aceptacin significa que todas las partes afectadas,
incluyendo los departamentos de los usuarios, firman normalmente un documento en el
cual se especifica que el documento en el cual se especifica que el sistema esta completo
y les es aceptable.
La aceptacin formal de un sistema es escencial para evitar malos entendidos
posteriores. Por ejemplo es comn que un grupo de usuarios al cabo de unos meses o
unos aos se diga el sistema que nos dieron nunca ha funcionado correscamente y es
hora de que los arreglen el personal de sistemas puede responder ustedes no nos
digeron que hubiera algo malo; el momento para corregir cualquier problema era cuando
se termino el sistema, mientras todo mundo recordaba de que trataba el proyecto y antes
que los diseadores comenzaran con proyectos nuevos en los cuales ahora se
encuentran ahora muy ocupados. Lo sentimos pero ahora es demaciado tarde.
Cuando inciste en la aceptacin formal, los dos grupos de usuarios saben cada vez que
acepten el sistema, pierden el derecho de reclamar que no estaba terminado o correcto.
Tambin se da un incentivo a los grupos de sistemas para resolver todos los problemas
que tenga nuevo sistema en forma expedita para que pueda terminarse en forma oficial.
Si el nuevo sistema consiste en parte del hardware o software proporcionado por un
proveedor externo, se puede decir a la organizacin que atestigue el hecho de que las
obligaciones se han terminado completamente. La organizacin debe responder al
pedido de acuerdo con el consejo de su equipo legal. Sin embargo, en el momento de la
aceptacin formal no se ha realizado una evaluacin del desempeo de un sistema, y en
la mayora de los casos la organizacin no debe formar el documento hasta que se haya
realizado la auditora posterior.
Compaa Abercrombie.
Para cuando lleg la computadora nueva, se habia realizado cerca del 80% del os
cambios en el diseo de archivos y modificaciones de programas necesarios para
convertirse al nuevo sistema. Se instal el nuevo sistema de cmputo, y las aplicaciones
actuales se transfirieron en forma gradual durante el periodo de 4 meses con la ayuda del
personal del proveedor. Cada programa de aplicaciones se corrio en paralelo en las
computadoras nuevas y antigua al menos de una vez, y hubo muchas ocaciones en que
se encontraron codificaciones o programas incorrectos durante la conversin, lo cual
causo errores o hizo que el programa no procesara en el nuevo sistema. Despus del
cuarto mes se desconecto el sistema de cmputo antiguo; se haba vendido a otra
compaa que ya tena un sistema de cmputo que era casi idntico a este, lo cual
duplicaba la capacidad de cmputo de dicha compaa.
La conversin de las primeras aplicaciones a un sistema de base de datos se program
para comenzar alrededor de 6 meses despus de que se vendi el sistema antiguo.

576-583
AUDITORIA POSTERIOR
La auditoria posterior no es una fase en la investigacin de sistemas; es mas bien la parte
final que se ha agregado a la fase de implantacin. El concepto de la auditoria
posterior se desarrollo unida a proyectos de presupuestos de capitales ya ha sido
adaptado en forma til a proyectos de investigacin de sistemas que tienen muchas
de las mismas caractersticas que los proyectos de presupuesto de capital.
La auditoria posterior se formaliza con mayor frecuencia para investigacin de
sistemas grandes, largos y complejos, pero sus principios son tiles por igual a
investigaciones pequeas, tales como cambios realizados a una aplicacin de
computadoras actuales, o la adquisicin de un sistema de microcomputadora. La auditoria
posterior descansa en dos proposiciones fundamentales: 1) que tanto una investigacin
de sistemas como el nuevo sistema resultante deben evaluarse, y 2), que una evaluacin
correcta no puede realizarse hasta que "se ha aplacado el polvo.
La auditoria posterior debe realizarse cuando un sistema alcanza un estado
estable en el que todos los errores se han eliminado, los operadores y usuarios estn
profundamente entrenados en la operacin del sistema, este esta operando a un alto nivel
de eficiencia, y todas las partes asociadas con l amplan sus ventajas y desventajas. La
auditoria posterior debe completarse antes de realizar cambios significativos que no sean
parte de la investigacin de sistemas original y antes de que el sistema comience a perder
eficiencia debido a que su medio esta cambiando. Para la mayora de los sistemas
nuevos, la condicin de estado establece se alcanza entre 1 y 6 meses despus de su
instalacin.
En resumen, la auditoria posterior establece si el sistema satisface las
especificaciones de los sistemas y que tan eficientemente se realizaron las actividades de
la investigacin de sistemas; estos propsitos se muestran en la figura 16.10. El estudio
de la investigacin de sistemas esta orientado a 1) obtener informacin para la realizacin
de investigaciones de sistemas posteriores con mayor eficiencia y 2) establecer un
registro para personal profesional de sistemas. El personal de sistemas se evala con
respecto a su experiencia, dedicacin, juicio, capacidad de mantenerse dentro del
presupuesto, e inclinaciones a ser optimista o pesimista acerca de los recursos de tiempo
y de personal requeridos para investigacin de sistemas.
Aunque no hay reglas rgidas acerca de quien debe formar parte de un equipo de
auditoria posterior, la figura 16.11 proporciona algunas sugerencias. El equipo debe ser
pequeo, quiz de tres y cinco personas. Las persona externas que sean objetivas, como
consultores y auditores, por lo general son miembros tiles de los equipos de auditorias
posteriores. Las actividades tpicas del equipo de auditoria posterior se muestran en la
figura 16.12. El enfoque de estas actividades es la preparacin de un informe al comit
directivo de sistemas y al departamento de sistemas de informacin. Una auditoria
posterior tpica se determina en una o dos semanas.

Propsitos de la auditoria posterior de sistemas

FIGURA

16.10

1. Determinar si el sistema resuelve el problema o problemas que tratan de resolver

2. Determinar hasta que punto del sistema satisface las necesidades que se
especificaban en el informe de especificaciones de requerimientos del sistema

3. Determinar, despus de la experiencia con el sistema, si existen nuevas

oportunidades para mejorarlo
4. Establecer si el sistema se termina a tiempo y con el presupuesto asignado y, si no,
porque
5. Evaluar el desempeo de los miembros del equipo de investigacin de sistemas

MANTENIMIENTO DE SISTEMAS
Despus de la captacin del nuevo sistema, comienza la parte de mantenimiento de ciclo
de vida. Durante este periodo, que por lo comn dura de tres a ocho aos el sistema se
mantiene mediante cambios menores o mayores segn sea necesario. En algn punto,
se comenzara una nueva investigacin de sistemas que tendr como resultado el
remplazo del sistema. La necesidad de una nueva investigacin es el resultado de una
combinacin de lo siguiente:
1. El medio a cambiado, por tanto, las principales funciones que realiza el sistema
ya no son necesarios o no son suficientes.
2. Los cambios al sistema lo han hecho un parche de cambios, lo cual causa
ineficiencia en el procesamiento, errores o fallas frecuentes. En este momento
el sistema es como una cmara de llanta vieja; ha sido parchada tan seguido
que existen parches sobre parches y seguirlo parchando en forma efectiva ya
es muy difcil.
3. La tecnologa ha avanzado. Aunque el sistema aun funcione con eficiencia un
nuevo sistema con tecnologa nueva tendr una mejor proporcin
costo/beneficio.

Formacin sugerida del equipo de auditoria posterior

FIGURA 16.11

1. Una o mas personas que estuvieran asociadas con el proyecto en casi toda su vida y
que puedan proporcionar esta perspectiva
2. Uno o mas usuarios que no participen en el nuevo sistema
3. Una o mas personas que tenan conocimiento de sistemas pero que no estuvieran
involucradas en el proyecto en ninguna forma, como un consultor externo
4. Alguien con experiencia en auditoria o experiencia en auditorias posteriores

Actividades del equipo de auditoria posterior

FIGURA 16.12

1. Revisar la explicacin original del problema y el informe de especificaciones de

requerimientos del sistema
2. Revisar la documentacin del sistema
3. Medir el desempeo del sistema (numero de transacciones, retrasos en los informes,
ndices de errores, confiabilidad del sistema, etc.) y capacidad, comparndola con
cada alternativa mencionada en el informe de especificaciones de requerimientos del
sistema, y buscando razones para las diferencias
4. Hablando con grupos de usuarios
5. Revisando los papeles de trabajo de la investigacin de sistemas (por ejemplo,
minutas de juntas y resmenes de asignacin de trabajo) y hablando con los
miembros
6. Determinando que modificaciones o mejoras pueden mejorar aun ms el sistema
7. Llegando a conclusiones acerca de la calidad, beneficios y costos del sistema y
acerca de la calidad de la investigacin de sistemas y del desempeo de sus
participantes y entregando un informe acerca de esto al comit directivo de sistemas

ACTIVIDADES DE LA INVESTIGACION DE SISTEMAS:

UN RESUMEN
Esta seccin proporciona un panorama general del proceso de investigacin de sistemas,
explicando en este capitulo y los dos anteriores. Para facilitar la explicacin, el anlisis se
ha realizado en trminos de las fases de una investigacin de sistemas: la fase de estudio
preliminar, la de anlisis, la de diseo y la de implantacin. Adems, se ha discutido la
auditoria posterior. El estudio que viene a continuacin sigue el formato que proporciona
la figura 16.13.
La fase de estudio preliminar ( y todo el ciclo de vida de un sistema) comienza con
la deteccin de un problema que incluye al sistema de informacin actual, o la necesidad
de un sistema de informacin donde no exista ninguno antes, Sigue una pequea
investigacin inicial, y los resultados de esta se escriben en un resumen del estudio
preliminar. El propsito de esta fase es determinar en forma general lo que esta mal y si
debe comenzar un proyecto de sistemas. La fase termina con la decisin del comit
directivo de sistemas (o de un gerente de sistemas de informacin si es que no se tiene
comit) de comenzar o no una investigacin de sistemas.
Si la decisin es comenzar una investigacin, comienza la fase de anlisis. El
propsito de esta fase es determinar exactamente lo que debe realizar un nuevo sistema.
Aunque se realizan en forma sistemtica, las actividades de esta fase no estn del todo
estructuradas y requieren muchas platicas con los usuarios, as como negociacin y
compromiso. El primer paso es la planeacin de proyectos; despus sigue una
investigacin del sistema o un estudio del sistema actual para conocer su estado,
fuerzas y debilidades. Aqu se requiere buen juicio para reunir suficiente informacin, pero
no ms de la necesaria.

Estudio preliminar

Analisis

Diseo

investigacin de sistemas.

actividades de

Lneas Generales de las

FIGURA 16.13

Implantacin

La tcnica principal aplicada en esta investigacin del sistema es la de entrevistas, la cual

puede aprenderse.
La informacin derivada de la investigacin de sistemas deber permitir la
definicin precisa y completa del problema de sistemas. Este paso es crucial.
A menudo las organizaciones dedican muy poco tiempo y esfuerzo a la definicin del
problema y proceden a resolver el problema equivocado. Cuando el problema se ha
especificado en forma escrita, es buena idea tratar de involucrar a todos para estar de
acuerdo en que en realidad es un problema de sistemas y que a este es a quien debe
atacar el desarrollo del sistema.
El siguiente paso es el anlisis del sistema. La informacin acerca del sistema
actual se estudia en detalle, y se entrevista a los usuarios, se toman medidas, se
desarrollan pronsticos de necesidades futuras y se toman todos los dems pasos
necesarios para determinar lo que el nuevo sistema debe realizar.
Los resultados de esta actividad minuciosa llevan al informe de especificaciones de
requerimientos del sistema, con la cual termina la fase de anlisis de sistemas. (Este es el
punto mas temprano del ciclo de vida de un sistema en el cual se prepara un pedido de
propuesta, o PP. Quiz en este momento un PP pide a los proveedores un sistema
completo.)
Las actividades de la fase de diseo de sistemas son mas estructuradas que las
de las fases anteriores. El propsito del diseo de sistemas es determinar que tipo de
sistema lograra mejor las especificaciones del sistema; en otras palabras, como es que el
nuevo sistema realizara lo que se supone debe realizar.
Se evalan una serie de conjuntos de alternativas de macro diseos en secuencia; en
general, mientras ms amplio sea el alcance original del proyecto, mas sern los
conjuntos de alternativas de macro diseos los que sern evaluados.
Esta evaluacin esta en trminos de factibilidad tcnica, operacional y
econmico/beneficio, y no deben pasarse por alto los costos y beneficios intangibles.
El diseo de sistemas requiere imaginacin para establecer los conjuntos de
alternativas y un alto nivel de conocimiento tcnico para poderlos definir y evaluar en su
totalidad. Las habilidades interpersonales son menos importantes aqu que en las fases
anteriores. Las habilidades interpersonales son menos importantes aqu que en las fases
anteriores. La aceptacin progresiva de alternativas cada vez mas detalladas lleva al
desarrollo de un microdiseo detallado capturado en un conjunto formal de
especificaciones de diseo. Para proyectos que incluyan a proveedores de hardware o
software. Las especificaciones de diseo detallado pueden prepararse en forma de un PP
para distribuirse a proveedores seleccionados.
El propsito de la fase de implantacin es desarrollar e instalar el sistema descrito
por las especificaciones de diseo. El entrenamiento del `personal para usar y operar el
nuevo sistema es una parte importante de las actividades de esta fase que asimismo
incluye seleccin de hardware y software, programacin, preparacin del lugar e
instalacin, conversin, prueba, y dejar al nuevo sistema sin errores. La conversin del
sistema puede realizarse en varias formas, operaciones paralelas, arranque directo, en
fase, y estudio piloto. Despus de verificar y probar el sistema, este se acepta
formalmente como terminado y se convierte en operacional. Las actividades de
implantacin finalizan con la aceptacin formal del nuevo sistema.
Cuando el sistema ha alcanzado un estado estable (esto es, cuando esta
operando a su mayor nivel de eficiencia pero aun no se le han hecho cambios
importantes), se realiza una auditoria posterior. El propsito de esta es determinar si el
sistema realiza lo que se supona deba realizar y si lo ha logrado dentro de su tiempo y
presupuesto estimados. El informe de especificaciones de requerimientos de sistemas
sirve como punto de referencia para medir el sistema.

Un sistema permanece en operacin entre 3 y 8 aos, en cuyo tiempo se realizan muchos

cambios para adaptarlo a las necesidades cambiantes de informacin. Cuando el sistema
requiere ser reemplazado porque ya no sirve o debido a otras razones, comienza un
nuevo ciclo de vida.
RESUMEN
Con una base de sistemas de informacin gerencial, sistemas computacionales e
investigacin de sistemas, el estudiante ya esta en una posicin excelente para participar
con eficacia en una investigacin de sistemas bajo cualquier situacin. Estas bases le
abren oportunidades de trabajo en departamentos de sistemas de informacin u en la
industria de la computacin.
Las actividades de diseo de sistemas son tcnicas estructuradas por naturaleza.
El diseo estructurado incluye la revisin del conjunto de posibles alternativas de diseo
que aun estn en planes del proyecto, la seleccin de una, la revisin de un conjunto
menor de alternativas de diseo que se encuentran dentro del conjunto seleccionado, y
as sucesivamente, hasta que en el nivel mas detallado, s estable un micro diseo, En
cada nivel de la jerarqua de alternativas se consideran la factibilidad tcnica, econmica y
operacional.
Con frecuencia, si se usa el mtodo de diseo detallado, primero se disean los
informes y documentos que deben salir del nuevo sistema. Despus se disean los
sistemas de entrada y recoleccin de datos. Por ultimo, se disean los sistemas de
procesamiento y de archivos. Sin embargo, esta secuencia de actividades no es la
correcta para todos los proyectos. Durante el micro diseo detallado, se incluyen controles
sobre el procesamiento de datos como una parte del sistema.
Un tipo de actividad de diseo incluye primero el diseo de flujos de datos que
sern necesarios y despus la evaluacin de ventajas comparativas de software que se
comprara y de software que se desarrollara en la organizacin. Cada vez mas, la
decisin es comprar software que se compra debe modificarse para satisfacer las
necesidades de la organizacin.
Si se va a adquirir equipo, se enva un pedido de propuestas (PP) a los proveedores cuyo
equipo es satisfactorio potencialmente. Los proveedores preparan sus propuestas y hacen
una presentacin a la organizacin que lo solicita. Si la venta potencial es grande, los
proveedores dedican un gran esfuerzo a desarrollar una respuesta a un PP.
La mayora del entrenamiento de personal para el uso del nuevo sistema se
realiza durante la fase de implantacin. Una de las actividades principales de esta fase,
para la mayora de los proyectos, es la programacin; debido a su alto costo y a su gran
tendencia a exceder el tiempo calculados, la actividad de programacin debe controlarse
en forma sistemtica y cuidadosa. L a programacin estructurada es una forma usada
para aumentar la productividad de un programador. La preparacin del lugar, la instalacin
de equipo y de software; la conversin de archivos y la aceptacin final del nuevo sistema
se realiza durante la fase de implantacin.
Un nuevo sistema puede arrancarse en fases, correrse en paralelo con el sistema
nuevo, o arrancar directamente, o puede implantarse primero como un proyecto piloto; la
eleccin de como introducirlo depende de las circunstancias. Por lo general, el arranque
directo es l ms rpido y l ms riesgoso, en tanto que las paralelas y el estudio piloto
son las menos riesgosas. La auditoria posterior incluye el estudio de que tan bien
satisface el sistema las especificaciones preestablecidas de requerimientos de sistemas,
as como que tan eficiente se realizo el proyecto.

TERMINOS CLAVE
diseo estructurado: comenzar las actividades de diseo de sistemas con el posible
pronosticado de alternativas de diseo y seguir a travs de conjuntos de alternativas cada
vez ms pequeos.
especificaciones de diseo de sistemas: estado completamente detallado de la
estructura y de los componentes de hardware y software de un nuevo sistema.
estudio de factibilidad: examen de la factibilidad tcnica, econmica y operativa de un
conjunto particular de alternativas de diseos de sistemas y la comparacin de la
factibilidad de cada alternativa.
controles generales: control de sistemas que son relevantes para todas las
aplicaciones.
controles de aplicaciones: controles asociados con un trabajo o programas especifico
de procesamiento de datos.
pedido de propuesta (PP): invitacin a los proveedores para hacer una oferta para
proporcionar un sistema o parte de un sistema; un PP contiene toda la informacin acerca
de la naturaleza del sistema buscado para que el proveedor prepare su propuesta.

REFERENCIAS
Bryce, Milton, Information Resources Management, Infosystems, febrero 1983.
Buss, Martin, D,J., y Elaine Herman, Packaged software-Purchase or Perish, Financial
Executive, enero 1983, p. 26.
Feidelman, Lawrence, Buying Packaged Software for Micros and Minis. Infosystems,
enero 1981, p. 54.
Game, Chris, y Trish Sarson, Structured Systems Analysis: Tools and Techniques,
Improved systems Technologie Inc., 1977.
McCracken, Daniel D., The changing Face of Applications Programming. Dtamation,
noviembre 1978. P. 25.
Sanders, G. Larry,Paul Miner y Ronald O. Reed, Selecting s Software Package, Financial
Executive, septiembre 1982.
Whipple, Donald, Typical RFP vs. Vendor, Production & Inventory Management Review
and APICS News, noviembre 1981.
Withington, Frederic G., The Golden Age of Packaged Software, Datamation, diciembre
1980, p. 131.
Yourdon, Edward, y Larry L. Constantine, Structured Design, 2d ed. New york: Yourdon
Press; 1978.

PREGUNTAS DE REPASO
1. Compare el analisis de sistemas y su diseo con la naturaleza de los procesos y la
experiencia requerida para cada tipo de actividad.
2. Que es diseo estructurado? Que es programacin estructurada? En que difieren
del analisis estructurado, segn se analizo en l capitulo anterior?
3. Explique el concepto de macro diseo. Cmo afecta el alcance de la investigacin de
sistemas al macro diseo?
4. Que es un micro diseo? Se realiza siempre un micro diseo?
5. Explique la factibilidad tcnica y la factibilidad econmica. Estas factibilidades se
evalan solo una vez durante una investigacin de sistemas? Explique su respuesta.
6. Que es la factibilidad operativa? En el largo plazo, si un sistema no posee factibilidad
operativa, puede ser factible econmicamente?
7. Que son controles generales? Una poltica a la cual todos los empleados de
procesamiento de datos deben estar ligados, es un control general?
8. Liste varios controles de aplicaciones y explique cada uno.
9. Un archivo de datos se procesa con programas de aplicaciones de nominas
separados. Los controles sobre quienes pueden correr estos programas de nominas
serian controles generales o controles de aplicaciones?
10. Porque existen controles de usuarios?
11. Porque se consideran tan importantes los controles de correccin de errores?
12. Cmo se controlan las investigaciones de sistemas?
13. Que papel o papeles pueden jugar los auditores en las siguientes?
a) Fase de estudio preliminar
b) Fase de anlisis de sistemas
c) Fase de estudio
d) Fase de implantacin
e) Auditoria posterior
14. Cuales son las ventajas y desventajas de comprar programas?
15. Que pasos deberan tomarse en la decisin concerniente a s un programa debe
comprarse o desarrollarse? Si un programa va a comprarse, qu pasos deben tomarse
en la decisin de cual debe comprarse?

584-589
16. Cmo puede una organizacin determinar si existe un programa para su venta
que pueda satisfacer sus necesidades?
17. Explique el proceso de desarrollar un PP y dar un contrato para equipo como
consecuencia del PP.
18. Qu tareas se realizan como parte de la fase de implantacin?
19. Por qu es importante para una organizacin controlar las actividades de
programacin cuidadosamente? Cmo deben controlarse estas actividades?
20. Qu tareas pueden estar involucradas en la preparacin del lugar? Cmo
difieren
stas para computadoras grandes y microcomputadoras?
21. Cules son las cuatro clases de enfoques generales a una conversin de
archivos y cundo se usara cada una probablemente?
22. Por qu es importante la aceptacin formal de un nuevo sistema?
23. Explique los propsitos de la auditora posterior. Quines deben ser miembros
de un equipo de auditora posterior?
CASO
La ciudad de Framington
Por George M. Scott con la ayuda de Rob Rolfe
Una compaa local de contadores lleva a cabo una auditora anual a la ciudad de
Framington, Oregon. Junto con este informe, la compaa de recomendaciones que
piensa mejorarn el sistema de contabilidad de la ciudad. En mayo de 1980, la
compaa recomend a la ciudad comprar una computadora para realizar los
cobros de electricidad, preparacin de impuestos, recoleccin de impuestos, y
operaciones de nmina. El sistema manual entonces usando no era exacto,
consistente y confiable. Los auditores notaron, por ejemplo, que un caso de no
asistencia con frecuencia causaba retrasos y paros en el trabajo, y expresaron su
opinin de que una microcomputadora podra realizar estas operaciones con mayor
velocidad, exactitud y confiabilidad.
Poco despus de recibir estas recomendaciones y despus de comprobar con la
ciudad ms grande y ms cercana acerca de que tanto le gustaba a dicha ciudad su
sistema de cmputo, el consejo de la ciudad de Framington vot en favor de la
compra de una computadora. Despus de breves presentaciones de varios
representantes de microcomputadoras, el consejo decidi comprar una
computadora Computamic IV. Esta decisin se bas principalmente en la seguridad
dada por el vendedor, quien afirm que el modelo IV haba estado en servicio varios
aos ("suficientes para estar libre de errores") y haba ms computadoras
Computamic IV en existencia que cualquier otra computadora recomendada por los
otros representantes; en efectos, los otros representantes comentaron que sus

computadoras eran modelos muy recientes y que an no se haban usado lo

suficiente.
Ninguno de los miembros del consejo haba visto la Computamic IV, pero el
vendedor les asegur que era el modelo ms reciente producido por Computamic y
que era lo que necesitaban para satisfacer las necesidades de la ciudad. Como la
mayora de las instalaciones de esta micro se encontraban en la costa este y en el
medio oeste, no se visit ningn lugar y no se establecieron contactos con ninguno
de los actuales usuarios de este sistema. Una razn para ello fue el hecho de que
ninguno de los actuales usuarios eran municipalidades; por tanto, los miembros del
consejo dudaron que las consultas con estos usuarios tuvieran mucha relevancia
para la situacin de Framington.
Computamic se eligi como el proveedor en parte, porque tambin tena algunos
paquetes de aplicaciones disponibles. Aunque estos programas no haban sido
escritos especficamente para cobrar electricidad y preparacin de estados de
impuestos, el consejo pens que podran modificarse con facilidad para realizar
estas tareas. Se esperaba que uno de los nuevos programadores realizara esta
adaptacin.
John Rushing, el director de finanzas, pensaba que la micro reducira los costos de
oficina y el nmero de empleados de oficina (sin embargo, no estaba involucrado
en la decisin de comprar la Computamic IV). Supona que habra poca dificultad
par entrenar algunos de los oficinistas para ser programadores. En agosto aplic
una prueba de aptitudes a los empleados, a s mismo para determinar quin tena
los atributos necesarios para programar la computadora. Slo tres personas
pasaron la prueba. Estas fueron Bill Richards, Dave Clark y l. Dave Clark dijo no
estar interesado en las computadoras, pero Bill Richards estaba muy entusiasmado
acerca del prospecto de convertirse en programador, aunque no tena ningn
estudio en procesamiento de datos.
Bonnie Miller, la gerente del departamento de contabilidad, se haba opuesto
fuertemente a la adquisicin de una computadora y se haba rehusado a presentar
la prueba de aptitudes; "adquisicin sin representacin!" era la expresin que
haba mostrado su desagrado. Renunci a fines de agosto, colocndose en una
posicin similar, con gran aumento de sueldo, en una ciudad adyacente que la
haba estado buscando durante varios aos. Bill Richards fue ascendido a gerente
de contabilidad, un movimiento poco comn, porque no tena estudios en
contabilidad y slo estaba un poco familiarizado con esta materia. Sin embargo,
como era el nico empleado que quedaba de tiempo completo, recibi el ascenso.
Estaba tomando cursos por las noches, para obtener un ttulo en administracin, y
crea que sus cursos no interferan con su nuevo trabajo.
Como el sistema antiguo iba a ser reemplazado por la computadora, Rushing y
Richards no crean que hubiera ninguna necesidad de "depurar" el sistema antiguo
para hacerlo ms exacto y eficiente. Suponan que todo lo que tenan que hacer
antes de la llegada de la computadora era aprender cmo programar; dadas sus
calificaciones en la prueba de actitudes, pensaban que esto no sera muy
problemtico. El vendedor de la Corporacin Computamic les haba dado lecciones
grabadas en cassettes y textos de programacin, los cuales, indic seran
suficientes para aprender cmo programar.

Bill Richards encabez el departamento de contabilidad en el periodo ms difcil del

ao. Este departamento tena varias responsabilidades. Primero estaban las
cuentas de electricidad, una actividad continua durante el ao. Segundo, el
departamento tena que preparar, imprimir, ensamblar, y encuadernar el documento
del presupuesto de la ciudad. Tambin tena que preparar y enviar los estados de
impuestos. Por supuesto, el departamento tambin tena que llevar el registro de la
ciudad, pagar a sus proveedores, y preparar los estados financieros anuales.
Richards tena que aprender cmo funcionaba el sistema de contabilidad por s
mismo ya que su predecesora no lo haba entrenado para ello. Esta actividad le
tomaba tanto tiempo que no tena oportunidad para estudiar su material de
programacin. No estaba demasiado preocupada porque pensaba que poda confiar
el John Rushing para que le ensaara a programar.
En enero de 1981, la Corporacin Computamic tena una muestra de su
computadora en Portland, y Richards y Rushing fueron a ver el tipo de
microcomputadora que iban a recibir. El vendedor les dijo que se iban a ofrecer
clases de programacin para los compradores de Computamic IV por las noches
comenzando la siguiente semana. Richards y Rushing decidieron ir a las clases.
La primera clase fue la noche de enero 20; despus de la clase, Richards se dio
cuenta que estos cursos estaban dirigidos a personas que ya tenan experiencia en
procesamiento de datos y que saban programar al menos en un lenguaje. Se perdi
en las discusiones tcnicas. Rushing pudo seguir partes de la clase porque se
haba preparado un poco ms.
Como estaba lejos de Framington, Richards decidi que dormira en el asiento
trasero mientras Rushing manejaba. Una hora despus, Rushing se durmi en el
volante y el auto se sali de la carretera. Los dos fueron enviados a un hospital y el
pronstico para Rushing fue que estara hospitalizado por lo menos 6 semanas,
despus de lo cual necesitara que transcurrieran entre 6 y 9 meses para su
recuperacin en casa; Richards comenz a darse cuenta que ahora tena un
paquete mucho mayor sobre sus hombros; era la nica persona en el gobierno de
la ciudad que tena al menos una pequea experiencia en procesamiento de datos.
Chris Haney, el director de obras pblicas, tom el lugar de Rushing como director
de finanzas hasta que ste pudiera regresar a su trabajo. Lo primero que Haney hizo
como director, fue crear un departamento nuevo de procesamiento de datos con Bill
Richards como el gerente y se emple a un nuevo gerente para el departamento de
contabilidad.
En octubre lleg la computadora, 5 meses despus de la fecha prometida par su
entrega y justo al comienzo de la parte difcil del ao. Nadie tena tiempo para
dedicrselo por lo cual se continu usando el sistema manual. Richards estaba
obligado a ayudar a la contabilidad durante este periodo.
En febrero de 1982, Richards estaba listo para modificar los programas de
aplicaciones que el vendedor les proporcion, cuyo propsito era satisfacer las
necesidades de cobro y recoleccin de electricidad, as como facturar y actualizar
las cuentas por cobrar y preparar los estados de los clientes. Richards descubri
muy a su pesar que los programas no estaban acompaados de documentacin.

Despus de pedir ayuda urgente a la Corporacin Computamic , sta acept

proporcionar uno de sus empleados, John Young, para realizar las conversiones.
Por este servicio se cobraba una cuota diaria de consultora ms gastos.
Young lleg a principios de abril y se sorprendi al descubrir que no se haba hecho
ningn trabajo para convertir el sistema alfabtico de clasificacin usando en el
sistema manual de cobro de electricidad al sistema numrico requerido por los
programas empaquetados de la Computamic IV. Tambin necesitaba rearreglarse la
contabilidad general. Young acept quedarse el tiempo que fuera necesario para
convertir el sistema y para modificar los paquetes de aplicaciones para realizar las
tareas requeridas.
Despus de varios meses de trabajo, el sistema alfabtico manual se haba
convertido, y el programa se haba modificado. Despus de las modificaciones el
paquete de aplicacin para realizar el cobro de electricidad era 40% ms grande que
el programa original.
En agosto de 1982, al prepararse para correr los programas de cobro de
electricidad, Richards desmantel el sistema manual reubicando a los empleados,
ya que pensaba que el sistema manual ya no sera necesario una vez instalada la
Computamic IV en la que haba sido la oficina de cobro de electricidad.
Tabla de organizacin de la
FIGURA 16.14
ciudad de Framington 1980
Consejo de la ciudad
Comits

consejos

con

participacin
ciudadana
Alcalde de la ciudad
Staff
Tesorero

Planeacin

Servicios

Oficinista

Servicios
legales
personal
Contabilidad

Compras Reunin de
impuestos de datos

General
Presupuestos
Electricidad
Divisiones operativas

Impuestos de
propiedad
Impuestos de
ventas

Procesamiento

de la ciudad al

Polica
y recreaciones

Fuego

Obras pblicas

Reforzamiento de las leyes de

trfico
Prevencin
Paquetes
Relaciones de la comunidad
Agua y saneamiento
Recreacin
Control de crmenes
de trficoAlbercas

Parques

Ingeniera
Rescate
Supervisin

Control

Inspeccin
Bosques
Limpieza
Calles y drenaje
Al correr el programa, surgi una complicacin y el sistema nuevo no funcion.
Despus de mucho esfuerzo, Richards y Rushing (Rushing haba regresado a su
puesto y estaba completamente recuperado) regresaron a todos los empleados,
mquinas, materiales y formas y lograron preparar las cuentas de electricidad. Sin
embargo, las cuentas de noviembre se retrasaron casi un mes y tenan una gran
cantidad de errores.
En su investigacin para determinar lo que haba fallado, Young descubri que el
programa de aplicacin modificado era demasiado grande para la memoria
principal. Hubo que reescribir el programa en tres programas separados, cada uno
de los cuales poda procesarse por separado.
Despus de 2 meses de reescribir y quitar los errores, el programa de aplicacin ya
estaba listo otra vez (despus de que la ciudad se quej, la Corporacin
Computamic accedi a la reduccin de un 20% en las cuotas de estos dos meses).
Esta vez el sistema manual y los sistemas nuevos se corrieron en forma simultnea.
Se descubrieron un gran nmero de discrepancias, y por fin se decidi enviar las
cuentas manuales en lugar de las preparadas por la computadora para diciembre de
1982. Durante el siguiente mes Young revis cada discrepancia y corrigi la fuente
del problema. La mayora de los problemas los haban causado pequeos errores
en la lgica del programa controles inadecuados en la programacin. En enero de
1983 siguieron el mismo procedimiento de procesamiento dual y encontraron que
las cuentas preparadas por la computadora estaban casi libres de errores, y desde
ese momento usaron la computadora para la creacin de las cuentas de
electricidad. Despus de casi tres aos,, por fin la computadora estaba funcionando
en una de las aplicaciones para la cual la haba recomendado la compaa de
contabilidad.
Debido a que el procesamiento de las cuentas de electricidad llev tanto tiempo
para funcionar correctamente, Richards comenz a pensar si la Computamic IV no
sera demasiado pequea para cuando estuvieran funcionando los otros programas
de aplicaciones. Una maana pregunt a Young: "sabe usted si la Computamic
est desarrollando una Computamic V, de preferencia una con mayor memoria
principal?"

"No", contest Young , "la Computamic IV es nuestro modelo ms grande y ms

reciente, pero dentro de casi 6 meses anunciaremos un sistema completamente
nuevo: una computadora para negocios pequeos con un disco duro fijo y dos
discos flexibles,, capacidad de terminales remotas, y un sistema operativo
totalmente nuevo. El nuevo sistema funcionar, en exclusiva, con nuestro lenguaje
Report-Write, que est ahora en las ltimas etapas de su desarrollo. Ser un
supersistema, el primero de varios modelos relacionados con negocios pequeos.
Me asegurar de que le informemos acerca de ella cuando se anuncie".
Esa noche, mientras manejaba, Richards pens, "me pregunto si tendremos tantos
problemas con el segundo paquete de aplicaciones como con el primero. Hemos
comprado una microcomputadora cuya capacidad ya hemos excedido? Espero que
no hayamos cometido un grave error!"
Nota
A Bill Richards, su experiencia lo interes en computacin. Para el siguiente mes
hizo una prueba para un puesto en procesamiento de datos en una compaa ms
grande de Portland. Se le dijo que su experiencia y entrenamiento en
procesamiento de datos no eran adecuados. Poco despus inform a la ciudad de
Framington y entr en una universidad grande del medio oeste para obtener un
ttulo en ciencias computacionales de tiempo completo (Vase la tabla de
organizacin de Framington, que se muestra en la figura 16.14).

Preguntas sobre el caso

1. Qu problemas restricciones estaban asociados con el sistema Computamic
IV?
2. Qu errores se cometieron en la adquisicin e implantacin del nuevo sistema?
3. Suponga que usted fuera un miembro del consejo de la ciudad y se le
considerara como conocedor en computadoras e investigacin de sistemas. En
cuanto la compaa de contabilidad hizo su recomendacin, el consejo de la ciudad
le dijo a usted que "se encargara de obtener una computadora". Usted interpret
esto como que usted no necesitaba realizar una investigacin de sistemas, sino que
tena que asegurarse de una compra realizada en forma correcta. Mencione los
pasos que usted hubiera tomado y las recomendaciones que hubiera hecho a
travs de toda la investigacin de sistemas.
Captulo 17
CAPACIDAD DE CMPUTO:
FUENTES Y SELECCIN
CONCEPTO BSICO
No debe suponerse que una organizacin debe comprar su propio sistema de
cmputo y usarlo; hay varias alternativas que debe explorarse cada vez que una
organizacin busca mayor capacidad en una computadora.

OBJETIVOS DEL CAPTULO

1. Explicar las ventajas y desventajas de las diferentes formas en que puede
adquirirse capacidad de cmputo.
2. Presentar los principios generales de seleccin de computadoras.
INTRODUCCIN
La primera parte de este captulo considera varios arreglos posibles contractuales
para capacidades de procesamiento de datos. Analiza las ventajas y desventajas de
cad uno, as como los puntos a favor y en contra involucrados en la seleccin de un
tipo en lugar de otro. Las alternativas son:
1. Compra de computadoras
2. Renta de una computadora al fabricante
3. Alquiler de una computadora a un tercero
4. Adquisicin de una computadora usada
5. Centros de servicio de computadoras
6. Compaas de tiempo compartido
7. Compaas de administracin de instalaciones
Las primeras cuatro alternativas implican que la operacin de la computadora sea
hecha por la organizacin que la adquiere; la organizacin, por tanto, puede
controlar la programacin y uso del sistema de cmputo. Las otras alternativas
proporcionan un control reducido de las actividades de procesamiento de datos.
Una ltima alternativa, que no se muestra en la lista, es alguna combinacin de las
de la lista; las combinaciones se emplean mucho en la prctica, pero no se
estudiarn aparte.
La ltima parte de este captulo trata de la seleccin de un sistema de cmputo y
tiene mucha importancia para las primeras cuatro alternativas, aunque tambin
tiene alguna relevancia para las ltimas tres. La seleccin de computadoras se trata
como un tipo especial de investigacin de sistemas. No se incluyen los procesos de
seleccin y evaluacin, en especial relevantes para la seleccin de sistemas de
microcomputadoras; stos se presentan en el siguiente captulo.
COMPRA DE COMPUTADORAS
La compra de computadoras es la forma ms directa de adquirir capacidad de
procesamiento de datos, y es el medio adoptado por la mayora de los pequeos
usuarios, as como por muchos usuarios de computadoras grandes. El arreglo
comn es que el comprador paga en efectivo cuando el sistema de cmputo ha sido
instalado y est operando correctamente. Por lo general el precio est en el rengln
de 35 a 45 veces de lo que sera un alquiler mensual. En el momento de la compra
tambin pueden comprarse un sistema operativo y otros paquetes de software de
sistemas. Tambin pueden comprarse varios programas de aplicaciones para el
sistema de cmputo. Es comn que a los componentes individuales de todo el

sistema de cmputo se les ponga precio por separado aunque se incluyan en el

mismo contrato de compra. Sin embargo, tambin es comn que se realicen
compras de diferentes componentes y pa

???????
Una desventaja de alquiler a un tercero es que se compromete por contrato por un
tiempo mucho mas largo que si la computadora se renta de un fabricante. En algunos
casos una organizacin puede tener menos flexibilidad con un convenio a largo plazo que
con la compra de un sistema de computo; a veces una computadora comprada puede
venderse sin gran perdida; mientras que la penalizaciones financieras por romper un
contrato de alquiler son muy grandes.
La figura 17.1 muestra ejemplos hipotticos para ilustrar los puntos a favor y en contra,
implicados en las opciones de comprar, alquilar una computadora de un fabricante, o
alquilar aun tercero. Si la organizacin mantiene la computadora por 3 aos, la alternativa
menos costosa seria alquilar a un tercero. Si la computadora se mantiene por 6 aos, la
opcin menos costosa seria comprar un sistema de computo.
Cuando la organizacin ha decidido que sistema de computo debe instalarse, los dos
puntos de cruces entre las tres opciones de comprar, rentar de un fabricante o alquilar aun
tercero pueden calculare examinando los diferentes contratos disponibles. La
circunstancia ms sencilla es cuando la organizacin sabe con un alto grado de seguridad
que mantendr su computadora por un periodo definido; as, elegir entre las alternativas
es un asunto sencillo en el que solo se consulta un anlisis de puntos de cruce que ya
sido preparado. Sin embargo, pocos casos son tan claros.

Costos acumulados
De adqisicion y
Operativos.

RENTA
RENTA DE
UN
TERCERO

COMPRAS

6 meses
tiempo

3 aos

5aos

EJEMPLOQUE SE MUESTRA ARRIBA:

COMPRA DE LA COMPUTADORA
RENTA DE LA COMPUTADORA- CONTRATO A 6 MESES

RENTA DE LA COMPUTADORA A UN TERCERO-CONTRATO A

3
AOS

Paquetes de software con distintos proveedores en cuyo caso los contratos y convenio de
pago se hace por separado con cada proveedor .
Casi siempre se encuentra disponible un contrato por separado para servicio , y la
mayoria de los compradores eligen esta opcin. El contrato de servicio puede redactarse
con el fin de satisfacer las necesidades especificas del comprador , y puede incluir , por
ejemplo, una clausula por medio de la cual los ingenieros de servicio se encuentren en las
instalaciones 24 horas al dia o que el personal de servicio este disponible para hacer
reparacion dentro de un periodo maximo de 4 horas despues de la falla . Los contratos de
servicio tambien los tienen disponibles las compaas de servicio a computadoras.
La compra de un sistema de computo puede es en particular para una organizacin que
sabe con precision cuales son sus necesidades y que desea mantener su computadora
por un periodo largo , quiza por mas de 5 aos. S i n embargo el convenio de compra
puede ser no deseable si la organizacin no esta segura que la computadora satisfara por
completo las nesecidades o si esta crezca con rapidez , con el resultado de que una
computadora comprada ahora seria insatisfactoria dentro de poco. Si una organizacin
que espera un crecimiento rapido futuro compra una computadora, es especialmente
importante que esta computadora sea capaz de ampliarse en forma sustancial.
La compra de un sistema de computo puede ser desventajosa para una organizacin que
no ha estudiado correctamente sus nesecidades de cambio interno o las condiciones
cambiantes en el medio externo que dictan las necesidades de un sistema de computo
con diferentes capacidades. Tambien, si se compra una computadora, existe el riesgo de
que la nueva tecnologia la convierta en obsoleta en un futuro inmediato;los valores de

reventa y cambio de una computadora comprada declinan en forma drastica cuando se

introducen computadoras con nueva tecnologia avanzada.
Hay otro riesgo en la compra de computadora recien introducida . Los nuevos sistemas de
computo , como modelos de autos nuevos, quiza no tengan aceptacion en el mercado o
no sean satisfactorios debido al diseo o a otros problemas.Antes de comprar una
computadora una organizacin debe de estar segura que la computadora que va comprar
ha sido probada en operaciones concretas. Si tiene alguna duda , puede preferir rentar
por un periodo con una opcion de compra incluida en el contrato de renta; en general casi
el 60% de renta pagada contara para el precio de compra del sistema de computo.
RENTA DE UNA COMPUTADORA AL FABRICANTE
Esta opcion se elige para la mayoria de las computadoras grandes, aunque muchas
organizaciones compran despues la computadora que rentaron al principio.Las
computadoras se rentan directamente de el fabricante dentro de los terminos de un
contrato que especifica la organizacin es responsable de un pago minimo de renta y que
el contrato puede terminarse, digamos, 90 dias despues de una notificacion escrita.El
contrato de renta tambien puede prever que la computadora este disponible para su uso
un cierto numero de horas al mes y que un uso adicional requiere de pago de renta
adicional.Un contrato de servicio con el fabricante es un requerimiento normal, ya que
este tiene inters financiero en mantener el valor de su computadora.
La renta de computadoras es un arreglo flexible, lo cual cuenta sin duda la gran parte por
su popularidad en casos que involucran sistemas de computo que cuestan millones de
dolares.El alquiler es un arreglo excelente para una organizacin que anticipa el cambio
de computadoras en futuro relativamente cercano o corta anticipacion.por ejemplo, una
compaa con crecimiento rapido o una que esta desarrollando con rapidez nuevas
aplicaciones de computo puede preferir la flexibilidad de un contrato de renta. Ademas,
una compaa que espera la entrega de una nueva computadora puede rentar una
temporalmente. La principal desventaja de la renta de computadoras es que en general la
alternativa es mas cara si la computadora se guarda por un periodo de varios aos.
ALQUILER DE COMPUTADORAS A UN TERCERO
Las computadoras tambien pueden alquilarce de terceras personas. El convenio es casi
identico al del alquiler de un fabricante excepto que el contrato es por un periodo mas
largo, quiza de 3 aos, lo cual permite que los terminos del alquiler sean mas flexibles.
Los terceros son compaias independientes que compran computadoras de un fabricante
y las alquila con un contrato a largo plazo, por lo comun de 3 a 5 aos de duracion. Esta
compaa aveces compra varias computadoras juntas para este proposito a un precio
favorable. Una ventaja de precio para la organizacin que alquila del 10 al 30 % abajo del
costo del alquiler es lo comun, en parte debido a descuentos favorables en los
impuestos.Tambien el precio mas bajo refleja la idea de teceros de que lo9s sistemas de
computo tendran una vida economica mayor de lo que piensan los fabricantes , y por
tanto anticipan recibir alquileres por un periodo mas largo. Durante la decada anterior,
varios terceros han tenido ganancias bajas a que debido a que su juicio acerca de la vida
economica de las computadoras que han alquilado han sido incorrecto.

596-601
Ms esten bien protegidos en el centro de servicio. La seguridad de los datos e informes
que se transportan tambien en un problema con los centros de servicio; no es raro, por
ejemplo, que los informes de un usuario se entreguen por errror a otor usuario.
Otra desventanja de los centros de servicio es que el costo total por la cantidad de
procesamiento realizado sea alto con relacion de los costos de procesamiento hecho en la
computadora de la organizacin. Aunque una tasa alta puede justificarse si se ve al centro
como una conveniencia, puede ser execivo si la cantidad de procesamiento realizado no
es grande. Los informes especiales presentan otro problema; si una organizacin tiene
una necesidad no anticipada de informes debido a un problema operativo no anticipado,
procesamiento de datos requerido puede tratarse como un urgente en el centro de
servicio.
Una ltima desventaja de un centro de servicio es que los programas que se
desarrollan para un cliente no pueden transferirse a otro centro de servicio o al sistema de
computo del cliente. Es una prctica el tratar de encerrar a un cliente para que le sea
dificil descntinuar el uso del centro de servicio, y una tecnica que se usa para desarrollar
programas que slo pude ser procesada en la computadora del centro de servicio.
Aunque existen muchas circunstancias en que los centros de servicio proporcionan
servicios valiosos alas organizaciones, la economia de las microcomputadoras en general
significa que para muchas organizaciones pequeas es ms efectivo comprar un sistema
de cmputo. Aparte de la economia, existen otras consideraciones. Por ejemplo, el
problema de implantar un sistema de cmputo, sobre todo para alguien que es usuario
por primera vez ; puede hacer que una organizacin pequea un centro de servicio.
Ademas, es elevada la probalidad de cometer un serio error en la eleccion o implantacion
de una pequea computadora para dichos usuarios, y el costo indirecto de uno estos
errores pude ser mayor que el costo monetario directo relacionado con el sistema de
cmputo. De acuerdo con esto, cuando una organizacin no tiene confianza en poder
implantar un sistema de informacion efectivo, pude ser inteligente elegir un centro de
servicio.
COMPAIAS DE TIEMPO COMPARTIDO
Las compaias de tiempo compartido son similares a los centros de servicio en cuanto a
que la organizacin se suscribe al procesamiento de datos proporcionando por una
compaa con una computadora. La diferencia principal es que el cliente captura las
transacciones al ser procesadas mediante una terminal de computadora en su oficina, en
vez de transportarlas fisicamente. Los informes puden imprimirse en una impresora en la
oficina del cliente o bien en la compaa de tiempo compartido y entregese al cliente.
Los precios de las compaias de tiempo compartido son similares a los centros de
servicio excepto en que 1) hay cargos adicionales por la renta o compra de la terminal, 2)
se tiene cargos adicionales por comunicaciones de datos. En general, los datos se
transmiten mediante lineas telefonicas, de tal forma que los cargos aparecen como parte
de los costos del telefono del cliente.
El uso de una terminal remota proporciona ventajas al usuario de tiempo compartido,
ventajas que no tiene el usuario en un centro de servicio. Primero, el tiempo compartido
puede proporcionar entrega rapida. El cliente esta linea con la computadora, y por lo
tanto sus archivos pueden permanecer, con provecho, en linea (con cargo extra ) por
transacciones por tiempo real procesadas y preguntadas alos archivos; tambien, pueden
prepararse algunos informes y documentos (como facturas de ventas ) en tiempo real.

Otra ventaja de tiempo compartido es que muchas de estas compaias son locales,
nacionales o internacionales en cuanto a su alcance, lo cual permite a sus clientes usar
su red en tiempo compartido como un sistema de comunicacin de datos entre
operaciones diversas dispersas geograficamente. Por ejemplo, una sucursal de una
compaa
podria capturar transacciones de ventas para su procesamiento ala
computadora de tiempo compartidoque se encuentra ms cerca de ella e imprimir
instrucciones de embarque para una terminal en una bodega de inventarios a miles de
millas de deistancia. Puede ser que el desarrollo de su propia red interna de
comunicaciones por computadora sea de costo prohivitivo para una organizacin
pequea.
Las compaias de tiempo compartido mas grandes tambien tienen muchos
programas para todo proposito disponibles por un costo; a veces hasta miles de
programas. Estos pueden ser aplicaciones matematicas (como inversion matricial o
calculos logaritmicos), de procesamiento de palabras, de ingenieria electrica y estroctural ,
administracion de proyectos, de investigaciones nucleares, curva de aprendizaje, o de
graficas, asi como todo una gran gama sobre analisis financiero. Para muchas
organizaciones en ocaciones se necesita programas especializados especificos que
serian demasiados caros para comprarse. Las bases de datos especializados, con base
en datos economicas o estadisticas, tambien estan disponibles en compaias de tiempo
compartido.
Las compaias de tiempo compartido mas grandes tambien son accesibles por
telefono en una amplia area geografica. Se dice que puede establecer contacto telefonico
con el sistema Mark 111 de General Electric desde mas del 90% de las lineas telefonicas
de negocios del mundo. El sistema GE se compone de ms de 100 computadoras,
incluyendo varias computadoras grandes en super centro en Cincinati, Ohio. Estas
pueden usarse en forma efectiva para unir sistema de cmputo de una empresa
multinacional con las operaciones que pueden ir tan lejos como el sur de Asia o el sur de
Europa.
A menudo los centros de servicio y las compaias ms pequeas de tiempo
compartido se especializan por industria. Las organizaciones con necesidades de
procesamiento de datos, que son nicas en su industria, deben preferir un centro de
servicio o compaa de tiempo compartido especialista en dicha industria. La compaa de
tiempo compartido Bowne en la ciudad Nueva York, por ejemplo, se especializa en
procesamiento de palabras. Computer Sharing Service de Denver se especializa en
servicios de contabilidad de ahorros y prestamos, y Comshare en Ann Arbor en
administracion de personal y programas de aplicaciones de contabilidad.
COMPAIAS DE ADMINISTRACION DE INSTALACIONES
Las compaias de administracion de instalaciones dirigen las instalaciones de cmputo de
un cliente (de all su nombre) y asumen responsabilidad del procesamiento de datos del
cliente con base en un contrato de largo plazo. Estas compaias surgieron debido a que
una gran parte de los departamentos de procesamiento de datos de las organizaciones
realizan el trabajo en forma poco satisfactorio. En muchos centros de procesamiento de
datos, por ejemplo, la preparacin de informes en general se atrasa, hay problemas con
el equipo y software, y las nuevas aplicaciones se terminan mucho despus de sus fechas
de entrega, con lo cual se tiene un costo mucho mayor planeado. Adems, casi siempre
los sistemas se disean o se instalan en forma incorrecta y por tanto no satisfacen las
necesidades del usuarios. Tambin, muchas de las decisiones de equipo, como la e
adquirir una nueva compurtdora no se consideran correctamente; es caracterstico que se

adquieran computadoras
mayores
y ms caras que las necesarias bajo las
circunstancias y algunas veces stas no poseen las caractersticas necesarias para la
organizacin. Por ltimo, ha sido muy alta la rotacin de de personal en procesamiento de
datos en la mayoria de las organizaciones y este y otros problemas de personal no tienen
solucin.
Estas condiciones se dan en gran medida porque los directores generales de la
mayoria de las organizaciones no tienen conocimiento de procesamiento de datos y
administracin de proyecto de sistemas. Estos administradores no son capaces de
distinguir entre el personal capaz y personal imcopetente y no pude y no pude controlar
correctamente el prcesamiento de datos.
Si existen condiciones similares a ests en una organizacn, una compaa de
administracin de instalaciones (AI) puede venderle la siguiente idea: Su compaa no
est en el negocio de procesamiento de datos; usted deberia concentrarse en lo que hace
mejor: proporcionar los bienes o servicios para los cuales se tiene este negocio. Piense
en el procesamiento de datos en la misma forma en que piensa en la cafetera de la
organizacin. Su personal no manejara la cafetera; al contrario, usted llama a una
agencia externa de expertos en servicio de comida. Debera hacer lo mismo con el
procesamiento de datos: llamar a expertos como nosotros para que maneje sus
instalaciones de procesamiento de datos. Debido a que somos profesionales, podemos
bajar sus costos totales, y suscribiremos un contrato que garantice que satisfaremos la
programacin y realizaremos otros servicios por una cuota fija.
Muchas compaias AI se especializan por industria. Por tanto, no slo son
profesionales de procesamiento de datos,sino que tambin tienen conocimiento profundos
de problemas de procesamiento de datos de una industria particular. El contrato tpico
especifica que la compaa de AI comprar el equipo y el software de la organizacin. En
general la compaa de Aiacepta emplear el personal actual de procesamiento de datos, o
al menos una gran parte de ellos. La compaa de AI optimatizar el equipo que adquiera
mediante la alteracin de la configuracin del sistema de cmputo, por ejemplo, o vender
o transfier equipo y cuando sea necesario,lo reemplazar con uno ms adecuado a las
circunstancias. Esto puede aumentar la eficiencia del centro de procesamiento de datos
de otros clientes, o bien un centro de servicio para el procesamiento de datos de un
cliente en otra computadora en otro lugar. Par a aplicaciones especficas de una industria,
es probable que la compaa de AI utilice algunos de sus propios paquetes de programas
de aplicaciones diseados para procesar con eficiencia.
La compaa de AI tambin medir sus recursos personales. Los empleados de la
organizacin usuaria menos capaces en procesamiento de datos puede elegir otro puesto
dentro de la organizacin en lugar de unirse a la compaa AI. Los que eligan unirse a
ella, se retienen mientras sea necesario y se les informa que su desempeo debe ser alto.
Adems, la compaa AI asigna a su propio personal en puestos superiores en el nuevo
centro de datos de la compaa del cliente. Al proporcionar una mejor organizacin, mejor
administracin de proyectos, y mejores decisiones de equipo y al utilizar personal ms
productivo, la compaa de AI mejora porque ahora son empleados de una compaa de
procesamiento de datos profesional, lo cual les abre nuevos caminos en su carrera que
antes no tenan a su disposicin. En cierto periodo, mucho del personal original de
procesamientode datos habr transferido para ayudar al desarrollo de sistemas de otros
clientes de la compaa de AI.
El contrato con la compaa de AI puede escribirse en forma flexible para que, en
efecto, el cliente puede llegar a un arreglo deseado, pero a un precio negociado. Esta
flexibilidad sgnifica que el cliente de poner atencin al alcance y calidad de los servicios
que desea de la compaa AI. Un contrato tpico permanece en efecto de 3 a 5 aos.

La forma de cobro de la compaa de AI vara mucho. Por ejemplo, el precio puede

ser una cuota fija por desempeo fijo,puede ser una cuota fija ms incentivos por un buen
desempeo y penalizaciones por el mal desempeo (como teneer las cosas a tiempo), o
bien pude ser una cuota fija ms de tasa fijada por transaccin procesada. Por lo comn,
la compaa de AI cobra una cierta cantidad por cada transaccin dentro den un rango de
volumen o una cantidad fija por un nivel de activida dentro de dicho rango, y una
cantidad ligeramente menor por los niveles de actividad dentro de dicho rango, y una
cantidad ligeramente menor por niveles de actividad en cada prximo rango, de
volumenes ms alto. Con frecuencia se tiene un precio mnimo total. A menudo la frmula
para establecer el costo se basa en pronstico de la organizacin de sus operaciones
durante el trmino del contrato con el vendedor.
La naturaleza de las operciones de la compaa de AI se muestra en la figura 17.2. en
este ejemplo hipottico, la organizacin cliente tiene un costo promedio compuesto por
transaccin, como se indica en la curva en la posicin extrema izquierda de la figura.
Advirtese que el costo por transacccin aumentaba antes de que la organizacin
cambiara al vendedor AI, lo cual, es natural,sera un asunto para preocupar a la
administracin de la organizacin. Como se muestra, un contrato de precio fijo por
transaccin se negocia entre la compaa de AI y el cliente. En general el precio del
contrato por transaccin est por debajo del costo anterior promedio por transaccin,
motivo por el cual la organizacin contrata ala compaa AI. Puede verse que al comenzar
que al comenzar en al fecha de contrato, la compaa de AI aumenta la efeiciencia de las
operaciones de procesamiento de datos en forma drstica; sin embargo, puede aceptar
una prdida en el contrato por un periodo de pocos meses.

602-607
CRITERIOS PARA ELEGIR
CRITERIOS PARA ELEGIR UNA FUENTE DE CAPACIDAD DE CMPUTO.
1. Control de procesamiento de datos.
2. Costos proyectados:
Costos de adquisicin
Costos de implantacin
Costos de continuacin de operaciones.
3. La flexibilidad requerida para crecimiento futuro, para cambiar sistemas de cmputo,
para tipos nuevos de servicios computacionales, etctera.
4. La experiencia posada de la organizacin con procesamiento de datos.
5. El deseo de la administracin para dedicar atencin al desarrollo de sistemas de
informacin.
6. Las estrategias competitivas de la organizacin.
7. La necesidad de la organizacin de desarrollar un SIG.
8. Los mejores prospectos de desarrollo de software
9. El patrn de actividades de procesamiento de datos.
10. La longitud de tiempo en el que se requiere el procesamiento de datos
11. Consideraciones de contabilidad e impuestos
Con respecto al articulo 1, si la organizacin est preocupada por su capacidad de
mantener el control del procesamiento de datos, debe preferir una de las opciones que
permite que la computadora permanezca fsicamente en la organizacin y bajo su control
administrativo.
El articulo 2 , los costos proyectados, es la preocupacin principal en casi todos los
procesos de seleccin. Cuando se incluyen grandes volmenes de procesamiento de
datos, los centros de servicio y las compaas de tiempo compartido son quiz las
alternativas ms costosas. Si la flexibilidad es muy importante deben evitarse todas las
opiniones que incluyan contratos a largo plazo, as como la compra de un sistema de
cmputo.
Si la pasada experiencia de la organizacin en procesamiento de datos no ha sido
satisfactoria y hay razn para creer que la administracin no desea o no es capaz de
dedicar la atencin necesaria al desarrollo de procesamiento de datos debe preferirse un

centro de servicio, una compaa de tiempo compartido o una compaa de AI. Con
frecuencia es muy difcil para los administradores de una organizacin admitir que no
pueden dedicar suficiente atencin al desarrollo del sistema de informacin; por esta
razn, es muy probable que una organizacin cometa un error al comprar o rentar una
computadora, cuando puede estar mejor usando un centro de servicio, una compaa de
tiempo compartido o una AI.
Por otro lado, si las maniobras estratgicas de la organizacin en persecucin de las
metas a largo plazo dependen mucho de un sistema de informacin que puede moldearse
cuando sea necesario para dar apoyo a los procesos estratgicos, quiz es menos
preferible el procesamiento de datos por una compaa de tiempo compartido o una de AI.
En forma similar, si la organizacin tiene necesidad urgente del desarrollo de un sistema
de informacin para propsitos administrativos, debe evitar las fuentes del procesamiento
de datos proporcionado externamente.
Con respecto al articulo8, los mejores prospectos para el desarrollo del software por lo
general estn presentes si la organizacin controla su propio procesamiento de datos, a
menos que sus actividades de procesamiento no hayan tenido xito en el pasado y que
est en una industria en que una compaa de AI puede proporcionar un gran nmero de
programas probados a bajo costo. Con respecto al patrn de actividades de
procesamiento de datos, si estas actividades son espordicas o intermitentes, si tienen
periodos pico o si existen trabajos ocasionales muy grandes de procesamiento de datos,
con frecuencia lo mejor es usar un centro de servicio o una compaa de tiempo
compartido para que la organizacin pague slo la cantidad de procesamiento de datos
realizada y no su propia capacidad de exceso.
Por otro lado, con respecto al articulo 10, la extensin de tiempo requerido para el
procesamiento de datos, si la organizacin tiene necesidad temporal de procesamiento de
datos quiz deber rentar un computadora, un centro de servicio o una compaa de
tiempo compartido. Por ltimo, las consideraciones contables y de impuestos pueden
influir en la eleccin. Dependiendo en las circunstancias, pueden no ser deseable que el
valor de inversin de la computadora aparezca en el balance de la organizacin, o ser
ventajoso tener el crdito de impuestos de la inversin a que pertenece la adquisicin de
una computadora nueva.
Es claro que los criterios usados pueden tener diferente peso en una variedad de
circunstancias diferentes. Como una parte de su investigacin de sistemas, cada
organizacin debe estudiar sus necesidades de computadora, junto con los criterios

anotados y despus elegir la mejor fuente poder de cmputo, considerando sus

circunstancias particulares.
SELECCIN DE SISTEMAS DE CMPUTO.
Si necesita un sistema de cmputo grande, los procesos de seleccin de software y
equipo de cmputo se realizan en forma muy diferente de cmo se haran si se necesita
un sistema de mocrocomputadora. En el caso de un sistema de cmputo grande, primero
el enfoque estn en la seleccin del equipo, cuidando de asegurarse que el software de
sistemas necesario est disponible para el sistema de cmputo seleccionado. Despus
los programadores de la organizacin desarrollan o compran software de aplicaciones
para el sistema de cmputo adquirido. Rara vez la disponibilidad o falta de ella respecto a
programas de aplicaciones preescritos tiene un efecto decisivo en la seleccin de un
sistema de cmputo grande.
Para sistemas de microcomputadora se recomienda un enfoque casi opuesto. El
software de aplicaciones crticas que sern necesarias, as como el sistema operativo,
deben seleccionarse primero. Despus con base en anlisis tradicionales de adquisicin
de sistemas de cmputo, debe identificarse y elegirse entre las factibles, la
microcomputadora que procese este software. Los programas de aplicaciones preescritos
para microcomputadoras son tan extensos que deben hacerse todos los intentos posibles
para evitar escirbir programas ms tiles y despus comprar un sistema de
microcomputadora en el cual operen estos programas. Asimismo, las organizaciones o
sus departamentos que compran las microcomputadoras rar vez tienen programadores
profesionales; por lo tanto, a menudo la nica alternativa lgica es la compra de software
preescrito, lo cual fuerza el enfoque en la adquisicin de software.
Un tercer factor en la eleccin de equipo es evitar un sistema que no pueda mejorarse.
Debe elegirse un sistema que el provedor mejore en el futuro con programas de software
adicionales o componentes de hardware ms avanzados; el contrato debe garantizar la
disponibilidad de cualquier mejora o programa que afecte de modo signifcativo la decisin
de adquisicin.
De igual modo, se debe evitar un sistema de cmputo configurado a su mxima
capacidad para acomodar necesidades iniciales, ya que por lo general la cantidad de
procesamiento de datos aumenta substancialmente cada ao.
Por ltimo, el sistema de cmputo seleccionado debe ser parte de una familia de
computadoras para que, si el sistema se convierte en demasiado pequeo, haya

compatibilidad hacia arriba y para capacidades adicionales disponibles slo para la misma
familia estn disponibles si es necesario.
Las ventajas de un centro de datos de equipo mezclado son: 1) menor costo total en el
equipo mejor desempeo en los sistemas. Un centro de datos con equipo mezclado
puede tener problemas con las interfaces y otros problemas que pueden ser desastrosos
si el personal de procesamiento de datos no es altamente calificado.

SISTEMAS DE CMPUTO COMPLETOS.

Un sistema de cmputo completo es uno que se compra como un paquete; incluye todo
el hardware necesario, los sistemas de software, y los programas de aplicaciones. El
trmino de "completo" se refiere al hecho de que el proveedor dice que todo lo que debe
hacer el comprador es encenderlo y comenzar a procesar los datos de transacciones.
Los sistemas de minicomputadoras completos se han distribuido mucho durante una
dcada. Hoy en da los sistemas completos de microcomputadoras estn ganando
importancia; cientos de vendedores se especializan en proporcionar sistemas completos.
La organizacin ve el sistema ms como una "solucin de problemas" que como un
sistema de cmputo y tiene muy poco o ningn entendimiento de los componentes del
sistema o de cmo procesan datos los programas; para la organizacin, el sistema y sus
programas son una "caja negra".
En gral. Los sistemas completos de microcomputadoras se venden a organizaciones
pequeas que no tiene personal que entienda de computadoras o que sepa programar.
Esotos sistemas pueden ser una solucin barata a los problemas de procesamiento de
datos de dichas organizaciones, en especial si el proveedor no tiene que escribir
programas para el sistema. Tales sistemas proporcionan procesamiento de datos por
computadora para miles de organizaciones que de otra forma no podran tener un sistema
de cmputo.
CMO ELEGIR UN SISTEMA DE CMPUTO.

Las organizaciones grandes y medianas por lo general dedican suficientes recursos de

una investigacin de sistemas para determinar con exactitud si se necesita nuevo equipo
de cmputo, y si es as, evitar sistemas completos por medio de un anlisis profundo de
las alternativas. Estas compaas pueden encontrar una computadora apropiada y
localizar programas existentes o desarrollar nuevos si es necesario. Estas actividades
demandan un alto nivel de experiencia especializada, y muchas organizaciones emplean
un consultor, ya sea para que gue a su personal, o para que administre y conduzca esta
parte de la investigacin de sistemas.
Los administradores no tienen por qu entender por completo las actividades de
seleccin de sistemas. Sin embargo, les es til tener un conocimiento general de dichas
actividades. Los pasos involucrados son:

1. Preparar las especificaciones del sistema.

2. Preparar y distribuir una PP para elegir a los proveedores.
3. Con base en un anlisis de propuestas, eliminar a los proveedores cuyas propuestas
sean inferiores.
4. Hacer que los proveedores presenten sus propuestas.
5. Realizar un anlisis posterior de las propuestas.
6. Establecer contacto con usuarios actuales de los sistemas propuestos.
7. Realizar pruebas de puntos importantes del equipo.
8. Seleccionar el equipo.

608-613
Inferiores, se le llama comprobacin de especificaciones en el escrito. Por lo comn, es
un proceso de dos pasos y se realiza entes de las presentaciones de los proveedores
(paso 4) y de nuevo despus de las presentaciones (paso 5). Consiste en un anlisis de
las especificaciones tcnicas del equipo propuesto. De las especificaciones evaluadas, de
ordinario se encuentran aquellas que establecen si el equipo propuesto tiene capacidad
adecuada, si puede proporcionar las capacidades especializadas que se encuentran
dentro del informe de especificaciones de requerimientos de sistemas (como preguntas a
la base de datos y grficos de alta resolucin), y si no tiene cuellos de botella obvios,
como un componente particular que opere con mayor lentitud que el equipo con el cual
tiene la interfaces, lo cual disminuira el desempeo de todo el sistema. Asimismo, el
analista debe estar alerta a la posibilidad de que ciertos componentes tenga un precio
mas alto y que otros componentes disponibles con otro proveedor tengan un desempeo
igual o menor.
Por lo general la comprobacin de escritorio tiene como resultado muchas
preguntas acerca de las especificaciones y capacidades del sistema propuesto. Estas
preguntas sirven como base para comenzar las que harn al vendedor durante su
presentacin (paso 4).
Despus de la presentacin, el anlisis de equipo es similar, aunque se realiza con
mayor detalle aun, e incluye las propuestas de solo aquellos proveedores que todava
permanecen en la competencia (por lo general uno a dos). Esta segunda parte de la
comprobacin de escritorio genera mas preguntas, las cuales se contestan en forma
menos formal o bien necesitan una segunda presentacin por parte del proveedores.
En este punto la organizacin debe estar satisfecha de que el sistema en
consideracin pueda resolver sus problemas en forma efectiva en cuanto a costos. Si este
no es el caso, deben considerarse los pasos drsticos de reescribir todas las
especificaciones del diseo y de proporcionar una nueva PP a otros vendedores.
Suponiendo que una o mas configuraciones propuestas se vean como satisfactorias,
quedan dos preguntas. 1) los usuarios actuales considerados estn satisfechos con el
sistema y la asesora del vendedor? 2) Se desempeara el sistema como lo dice el
proveedor y como lo indican las especificaciones? Con respecto a la primera pregunta,
por lo general se hacen preguntas preliminares a los usuarios antes de seleccionar un
proveedor. Aun as, es probable que se realicen preguntas adicionales, quiz a otros
usuarios del proveedor y a su asociacin de usuarios. Adems, puede investigarse la
condicin financiera del proveedor mediante una agencia de crdito o por medio de un
anlisis de sus estados financieros. Es probable que los proveedores en condiciones
financieras pobres tengan deficiencias en su atencin a los clientes y es menos probable
que proporcionen mejoras futuras en hardware y software. De igual modo, el
mantenimiento fsico continuo y las refacciones se convierten en problemas importantes si
el proveedor esta a punto de la bancarrota.
Si los otros clientes del proveedor proporcionan informes favorables y si el estado
financiero del proveedor es fuerte, no hay razn para creer que el sistema ofrecido no sea
satisfactorio. Sin embargo, es imposible detectar cada cuello de botella posible y otros del
sistema al verificarlo en el escritorio, y quiz haya aspectos poco usuales de las
actividades de procesamiento de datos de la organizacin que causen problemas, y
disminuyan el desempeo del sistema de computo. Las pruebas de puntos importantes
del equipo protegen a la organizacin contra varios riesgos; estas pruebas consisten en

procesar las transacciones reales de la organizacin usando el sistema propuesto y

copias de los archivos de datos de la organizacin para ver si las transacciones se
procesan correctamente y para determinar que tan rpido se procesan. Tambin pueden
probarse otros aspectos del procesamiento, como las capacidades de preguntas y
telecomunicacin del sistema propuesta.
En general, las pruebas de puntos importantes se hacen en un equipo idntico
muy similar al equipo que se va a comprar; el proveedor lo presta y lo opera el personal
de la organizacin. Las pruebas tambin pueden realizarse en un equipo que le presente
otro cliente del vendedor. Las pruebas de puntos importantes quiz requieran la
adaptacin de ciertos programas de la organizacin al nuevo sistema. Dada la gran
cantidad de esfuerzo de preparacin necesario, de ordinario se prueban solo los
programas de mayor uso y mas crticos de la organizacin, y debe inferirse que tan bien
corrern los dems programas de los resultados de estas pruebas. A menudo el personal
del vendedor ayuda a modificar los programas que van a probarse.
Las pruebas del equipo, como se describen aqu, necesitan un gran esfuerzo y por
tanto solo valen la pena si se corre el riesgo perder mucho: si el costo del equipo esta en
los cientos de miles o millones de dlares o si las aplicaciones que van a correrse en el
nuevo sistema son criticas y un error en la adquisicin del equipo podra llevar a grandes
perdidas de la organizacin. S no es mucho lo que se va a perder, la organizacin puede
confiar en pruebas de puntos importantes que realicen compaas independientes usando
tipos generales de transacciones. En la figura 17.5 se muestran os resultados de una de
estas pruebas. Cada computadora realizo dos tipos de procesamiento: procesamiento
cientfico y de ingeniera y de cuentas por cobrar. Se advierte que las computadoras
difieren mucho en trminos de velocidad para estos tipos de procesamiento. Si se
hubieran elegido otros dos tipos de transacciones para la prueba, los resultados serian
completamente diferentes; el hecho de que un sistema de computo particular sea bueno
en un tipo de procesamiento no significa que lo sea en todos los tipos.
En general solo los sistemas pequeos se prueban en forma independiente, y los
resultados se publican en una revista de sistemas o se proporcionan mediante una cuota,
Aunque las pruebas de puntos importantes valen la pena, desde el punto de vista de una
organizacin partculas podran tener el problema de que por lo general no se prueban los
tipos de transacciones que la organizacin hubiera preferido se probaran. Por tanto , las
pruebas independientes de puntos importantes proporcionan indicaciones de las
capacidades de un sistema, pero sin decirle a una organizacin, que tan rpido procesara
un sistema de computo particular las transacciones de la organizacin, ni si podra
satisfacer las necesidades poco usuales de la organizacin.
Figura 17.5
Resultados de la serie1
Sistemas hasta $ 15000

Pertec PCC 2000

North Star Horizon
Cromemco System Two
Texas Instruments 771

C1
C3
Cientifico / Cuentas
Ingenieria por
Tiempo
Cobrar
Tiempo
28:48.4
6:04.3
12:01.9
1:57.7
14:52.6
2:48.0
22:05.4
3:38.1

Vector Graphics System B

Dacstation 78
Radio Shack TRS-80 Model II
Apple II

Resultados serie 2 ****

Sistema de $15000 a $25000
IBM 5110
Wang 2200VP
Texas Instrumensts FS990/10
Hawlett Packard System 45
DEC PDP-11V03
Q1 Lite
Univac BC/7-610
Northern Telecom 405
Datapoint 1170
Rand 100
Hewlett Packard 250
Texas Instruments DS990/2

19:30.0
22:35.6
20:00.7
21:11.0

5:56.5
5:04.8
3:38.6
6:17.4

C1

C3

29:47.2
2:05.8
**
4:38.9
14:43.4
6:50.7
12:09.2
**
38:27.5
13:52.4
4:05.9
**

4:11.0
3:20.0
3:16.6
5:05.8
4:14.0
5:03.0
10:37.0
**
6:50.4
10:05.0
2:48.3
2:48.3

* Resultados incluyen tiempo de compilacion y tiempo de corrida

** La prueba no pudo correse debido a limitaciones de memoria
*** La prueba no pudo correse debido a limitaciones de formateo
**** Tanto la serie 1 como la serie 2 se corrieron en los mismos progrmas.

RESUMEN
Este capitulo se considero las alternativas de comprar una computadora, rentarla de un
fabricante o de un tercero, adquirir una usada, usar el sistema de computo de un centro
de servicios o una compaa de tiempo compartido, emplea una compaa de
administracin de instalaciones que proporciona servicios computacionales, y adquirir un

sistema de computo completo. Se examinaron varios criterios de eleccin, incluyendo

costos, flexibilidad organizacional, la necesidad de controlas las actividades de
procesamiento de datos, y el papel que juega el sistema de computo en la estrategia
competitiva de la organizacin, como base para elegir entre dichas alternativas.
Las estrategias de adquisicin de equipo de software son diferentes para sistemas
de computo pequeos y grandes. Mientras que en el caso de computadoras grandes se
pone mayor atencin inicial a la seleccin de la computadora y el hardware, en el caso de
computadoras pequeas y especialmente microcomputadoras, primero deben
considerarse las necesidades de software, y despus debe elegirse un sistema de
computo compatible con el software. Al seleccionar el equipo, una organizacin debe
asegurarse de que la computadora que elija no ser anticuada demasiado pronto, que el
proveedor es fuerte financieramente, desea proporcionar servicios continuos y mejoras,
tiene facilidad de ampliar el sistema, as como de seleccionar diferentes proveedores en
un futuro.
La adquisicin de un sistema completo incluye la seleccin de un sistema de
computo y de programas de aplicaciones como un paquete del proveedor. No se elabora
diseo de sistemas en la organizacin: se le dice el proveedor que salidas debe
proporcionar el sistema, y este elige los componentes de hardware y software necesarios.
La seleccin cuidadosa de un sistema de computo en una organizacin es una
tarea compleja que la realizan mejor los especialistas en sistemas de computo. Se
identifican proveedores probables y se les envan pedidos de propuestas (PP). Estos
proveedores proporcionan informacin en forma de propuestas que recomiendan ciertas
componentes de equipo y paquetes de software que incluyen sus precios. La propuesta
de cada vendedor debe evaluarse antes de aceptar una. Se aplican varias tcnicas para
evaluar configuraciones propuestas de sistemas de computo.
TERMINOS CLAVE
Compaa de centro de servicios: compaa que usan su computadora par proporcionar
servicios de procesamiento de datos por lote a las compaas clientes.
Compaas de tiempo compartido: compaas que proporciona procesamiento de
transacciones en lnea y servicios de acceso de datos a las compaas clientes.
Sistemas de computo: sistemas de computo, que, al entregarse, incluyen todo el
hardware y software listo para operar inmediatamente.
Pruebas de puntos importantes: procesamiento de transacciones con una computadora o
programa particular para evaluar la eficiencia y caractersticas del equipo o del software.
REFERENCIAS
Kafatou, Thalia Cutting the Hidden Costs in Time Sharing Services, Smal Systems
World, Agosto 1980, p, 24.
Miller, Frederick W. Used Computers: A Lower Cost Alternative, Infosystems, marzo
1980, p, 66.
Rockhold, Alan, A Changig and Maturing Market for Used Computers, Infosystems,
marzo 1980 p, 66.
Szatrowski, Ted, Rent, Lease, or Buy Datamation, febrero 1976, p. 56.

Thierauf, Robert J., y George W. Reynolds, Effective Information Systems Management,

Columbus, OH: Merril, 1982.
Timmreck, E.M. Computer Selection Methodology, Computing Surveys, vol. 5, no. 4
diciembre 1973, p. 199.
PREGUNTAS DE REPASO
1. Cules son las alternativas importantes para la adquisicin de capacidad de
computo?
2. Qu criterio determinan que fuente de capacidad de computo debe seleccionarse?
3. Mencione tres de cuatro conjuntos de circunstancias en las cuales una combinacin
de dos recursos de capacidad de computo seria lgica.
4. Si un sistema de informacin computarizado de una organizacin debe organizarse y
manejarse para que sea capaz de adaptarse rpidamente a circunstancias cambiantes
en un medio dinmico, que fuentes de capacidad de computo deben considerarse y
por que?
5. Si la consideracin principal es que el sistema de informacin computarizado debe
permitir que las actividades de procesamiento de datos y preparacin de informes
puedan reprogramarse fcilmente, qu fuentes de capacidad de computo deben
considerarse y por que?
6. Si la mayor consideracin es que el sistema de informacin computarizado debe estar
organizado y administrado como parte integral de la estrategia competitiva de la
organizacin, qu fuentes de capacidad de computo deben considerarse y por que?
7. Si una organizacin necesita mayor capacidad de computo mientras espera la entrega
de su nueva y mas poderosa computadora qu fuentes de poder de computo deben
considerarse, y por que?
8. Si es de suma importancia un alto nivel de seguridad en programas, archivos de datos
e informes qu fuentes de capacidad de computo deben considerarse y por que?
9. Si una organizacin necesita aplicar un conjunto extenso de programas de ingeniera y
cientficos demasiado sofisticados y caros para comprarse o desarrollarse, qu
fuentes de capacidad de computo deben considerarse y por que?
10. Si el sistema de informacin computarizado debe proporcionar una forma de transmitir
datos con rapidez hacia y de gran variedad de lugares en Estados Unidos, Europa y
Asia, que fuentes de capacidad de computo deben considerarse y por que?
11. Si para una organizacin es importante la flexibilidad en trminos de reemplazar sus
fuentes de computo con muy poca anticipacin, qu fuentes deben considerarse y
por que?
12. Si el xito de una organizacin requiere que su sistema de informacin computarizado
este bien organizado y administrado que fuentes de capacidad de computo deben
considerarse y por que?
13. Si una organizacin necesita capacidad de computo adicional pero no desea convertir
sus programas y archivos a un sistema de computo diferente, qu fuentes de
capacidad de computo deben considerarse y por que?
14. Explique en forma narrativa como opera una compaa de administracin de
instalaciones y como logra sus utilidades. En que forma puede ser bueno esto para
una organizacin, y en que formas pueden ser dainos?
15. Qu tipos de necesidad pueden satisfacer con un sistema de tiempo compartido
similar al MARK III de la General Electric?

16. Cundo es preferible seleccionar primero el equipo de computo, y cuando es mejor

determinar primero cuales programas van a usarse? Por qu?
17. Qu factores deben considerarse en la seleccin de equipos?
18. Cules son las ventajas y desventajas de interconectar las componentes principales
de equipo de diferentes proveedores?
19. Cules son las ventajas y desventajas de un sistema de computo completo?
20. Cmo adquiere una organizacin un sistema de computo completo?
21. Explique el proceso de decidir si una computadora debe rentarse de un fabricante,
alquilarse a un tercero o comprarse.
22. Qu espera usted encontrar en un PP de equipo?
23. Qu es una prueba de puntos importantes de un equipo, y en que formas pueden
aplicarse?
24. Explique como se relaciona cada una de las siguientes actividades con las actividades
de la fase de diseo de sistemas y con la de implantacin:
a) Adquisicin de un sistema completo.
b) Preparacin de un PP y seleccionar el sistema de computo propuesto por un
proveedor.