1

CÓMO ASUMIR EL PAPEL DE EL

ANALISTA DE SISTEMAS

LA INFORMACIÓN COMO UN RECURSO DE LAS

ORGANIZACIONES
La= organizaciones han reconocido, desde hace mucho, le importancia de
administrar recurso* principales talas como la mano de otra y las materias
primas La ia.'ermedtin se ha colocado en un lugar adecuado como recurso
principal. Lo; tomadores de decisiones están comenzando t comprender
que la irrfcnnición no 63 silo un subproducto de la conducción, sino que a
la vsz alimenta a los negocios y putíde ser el factor crítico para la determi-
nación del éxito o fracaso da éstos.

Manejo de la información como recurso

Pava maximizar la utilidad de la información, un negecio la debí ruarte jar
coñac lamente tal como maneja los demás recursos. Los administradores
necesitan conprender que hsy costos asociados co:l It prodúcelas, distri-
bución, seguridad, almacenamiento y recupera:i<S.'i de Loda información.
Aunque la ¡nfarmación se encuentra a nuestro alrededor ésta no es gratis, y su
uso es estratégico para p03Ícion=i la ccmpe!i:ividad de un negecio.

Mrtieje íte la informiáón g¡mro&a por ccmpv.tatora

La fáci. dispenibitidad de computadoras ha creado uní explosión de infor-
mador, a travos da la sociedad en general v de lew negocioí en particular. El
Eunejc de información generada por computadora difiere en forma signifi-
cativa del m^neio de dalos producidos manualmente. Por lo general, ha}'
mayor cantidad de .nformacidn de computadora a.admir!L',.rar. El costo de
organizaría v mantenerla puede cracer a tasas alarmantes, y las usuarios
frecuentemente !a tratan menos sscépticamente qus la íníormacitín obteni-
da poi otras vías. E¿te capítulo examina los fundamentos de diferentes ti-
pos de sistemas de información, los diversos papeles de los analistas de
sistemas y !as fases del ciclo de vida del desarrollo de sistemas Presenta
además herramientas de ingeniería de software asistido por computadoras
(CASE por sus siglas en inglés),

CONCEPTOS DE ANÁLISIS Y DiSEÑO DE SISTEMAS

Los sis(emas de informacíán son desarrollados con propósitos diferentes
dependiendo de las necesidades del negocio. Los sistemas de procesamien-
to de transacciones (TPS por sus siglas en inglés) funcionan al nivel opera-
ciortat de la organización, Jos sistemas da automatización de oficina (OAS
par sus sigla* en inglés) y los sistemas de trabajo de conocimiento iKV/S por
sus siglas en inglés) que dan cabida al trabajo a nivel de conocimiento. Los
sistemas de más alto nivel incluyen a los sistemas de apoyo a decisiones
(DSS por sus siglas en inglés) así como a los sistemas de información,
gerencial (MIS por sus siglas en inglés]. Lo* sistsmas expertos aplican la
experiencia de los tomadores de decisiones para resolver problemas espe-
cíficos estructurados. Al nivel estratégico de la administracidn encontra-
rnos sistemas de apoyo a ejecutivos (ESS por sus jigias en lng!¿s¡ y los
sistema* de apoya a decisiones de grupo [GDSS por sus siglas en inglés)
ayudan a la toma de decisiones al mismo nivel, en una Forma sin estructu-
ra o semiesiructuiath.

Sistemas fie procesamiento íte transatxíanes

Lo* sistemas de procesamiento de transacciones |TPS) son sistemas de in-
formación computerizados desarrollados para, procesar gran cantidad de
datos para transacciones rutinarias de los negocios, tales como nriraina e
inventario. Los TPS eliminan el tedio de las transacciones operacionales
necesarias y reducen el tiempo que alguna vñ2 se requirió" para ejecutarlas
manualmente, aunque la gente todavía debe alimentar datos a los sistemas
computarizadcs.
Los sistemas de procesamiento de transacciones son sistemas que
traspasan fronteras y que permiten que la organización ínteractüe con am-
bientas externos. Debido a que ios administradores consultan los datos ge-
nerados por el TPS para inFormación al minuto acerca de Jo qua está
pasando en sus compañías, es esencial para las operaciones diarias que es-
tos sistemas funcionen laníamente y sin intemipcidn.

Shtemas ¡te automítizaábn be pierna y sistemas de manejo

de cofiocimietite
Al nivel de conocimiento de la organización hay dos clases de sistemas. Los
sistemas de automat ilación de oficina (OAS) que dan soporte a los trabaja-
dores de datos quienes, por lo general, no crean un nuevo conocimiento
sino que usan la información para analizaría y transformar dalos, o para
manejarla en alguna forma y luegc compartirla o diseminarla fDrmalmente
por toda ¡a organización y algunas veces más allá de elk. Los aspectos
familiares de los OAS incluyen procesamiento de paiahras, hojas de cálcu-
lo, editor de publicaciones, calendarización electrcíiuca y comunicación
mediante cerreo de voz, correo electrónico y videoconferencias.
Los sisearlas de manejo de conocimiento (KWS) dan soporte a los tra-
bajadores profesionales, tales como científicos, ingenieros y doctores, les
ayudan a crear un nuevo conocimiento que contribuya a la organización o
a toda la sociedad.
 de j
Los sistemas Je información geftnaal (MIS] no recüiplazan a los sistemas
de proceí a miento d; Iones, sino que todos los MIS incluyen pro-
cesamiento de transa «i o ¡íes, Los MIS son sistemas da infoimación com-
gutai-izada que trabajan debida a la interacción resuelta entre gentes
y computadoras. Requieren qiie las gentes, el software [programas de compu-
•aílora) y el hardware (computadoras, impresoras, ele.) trabajen al unísono,
Los sistemas da inforraacídn dan soporte a un espedía más amplio da ta-
reas organizacionabí que los sistemas de procesamiento de transacciones,
inc.uyendo al análisis de decisiones y la toma de decisior.es.
Para poder ligar la información, los usuarios de un sistema de infor-
mación gerencial comparten una base de datos ccimjn. La oase de datos
suarda modelos que ayudin. a los usuarios a interpretar y aplicar esos rnis-
tno¿ datos. Los sistemas da información gerancial producen información
que es usnda en la toma de decisiones. Un sistema de infoimacidn gerencia!
también puede llegar a unificar algunas de las funciones de información
computartzada, aunque no exista como una sstraciura singular en ningán
lugar eel negocio.

Sistema íe apoyo a beá&kneí

Lina clase de más alto nivel en los sistemas de información compu',aiÍ2ada
son los sistemas de apoyo a decisiones ¡DSSJ. El DSS es similar al sistema ce
inbrmac:óti gerencial tradicional en que ambos deper.deíl de una baíe
de datos tomo fuente. Un sistema da apoyo a decisiones se aparta t!el siste-
ma de infarmación ge¡encial tradicional c-n que snfatiía el apojij a la toma
de decisiones en todas sus fises, aunque la decisión actual todavía es ds)
dominio del tomador de decisiones. Los sistemas da apoyo e decisiones es-
tán más hechos a la medida de la persona o grupo que los usa que los siste-
mas de información gartiicid tradicionales.

Sistemas expertos e mtí.íiífencia nrtificiat

La inteligencia artificial (AI por sus siglas en inglés) puoce sar considerada
la meta da los sistemas expertos El empuje general de la Al ha sido desa-
rropar máquinas que se componen de forma inteligen'e. Dos caminos d? la
investigación de la Al son la comprensión del lenguaje natura! v ol análisis
de la .labilidad para razonar un problema y llegar a conclusiones lógicas.
Los sistemas expeitos usan los enfoques del razón i miento da la Al para re-
solvei los problemas que les plantean los usuarios de negocios (y otres).
Los sistemas expertos son un caso muv especial de un sistema de in-
formación, cuyo uso ha siío íat-iible para los negocios a partir de la reciente v
amplia disponibilidad He hardware y seftware ta! ceme las inicrücompu-
tadoras y sisteir.as expertw. Un sistsma experto ¡también üarnadn un sistema
basada en conocimiento) captura en forma efectiva y usa el conocimifinto
de un experto para resolver un problema particular experimentado eit una
organización. Obssrvs que a diferencia del DSS, cus deja la decisión final
al tomador de decisiones, un sistema experto selecciona la mejor solución
a un problema o a una clase específica dñ problemas.
LOÍ componentes básicos de un sistema esperto son la base de cono-
CAP: :
cimiento, una máquina ¿e inferencia qut conecta di usu£rij con el sistema,
procesando consultas pin medio da lenguajes tales como SQL [lijng'oaje de DU El
consultas estructurado), y la intsríaz ds usuario. Gentes llamadas ia^enie- - STE.MAÍ
ros de conccirAieüto capturan la experiencia de los expertos, constrtí•,Í:I 3
f IGUKA 1.1
Un analista de sisLemes
puede «star involucrado
con alguno o can
(odsi éstos sistemas,

un sistema de computadora donde incluyen el conocimiento del experto j

luego lo implsmentan. Es totalmente posible que la construcción e imple-
mentación de sistemas expertos sea el trabajo futuro de muchos analistas
de sistemas.
En la figura 1.1 se muestran la diversidad de sistemas de información
que pueden desarrollar los analistas. Observo que la figura presenta estol
sistemes de abajo hacia arriba, indicando qua el nivel oparacional; o más
bajo, de la organieacidn está apoyado por el TPS, y e] más alio c estratégi-
co, el de las decisiones semiestrucluradas o sin estructura, estí apoyado
poT el ESS en la parte más alta. Este texto usa los términos sisteme de in-
formación gei-enciel, sistema de información, sistema de iji forra acide
compuíarízada y sistema de información de negocios computariZBcJc er.
forma indistinta para raforiríe a sistemas de Información computanzada
que dan soporte al rangt? más amplio de actividades de negocios por medio
de le información que producen.
Sist£v*iús í)e ÍIJJOYJC a decisiones be grujió
Cuando IOÍ grupos necesitan trabajar juntos para tomar decisiones semies-
tructuradas o sin estructura, un sistema da apoyo a decisiones de grupo puede
plantear una solución. Los sistemas de apoyo a decisiones de grupo (GDSS)
son usados en cuartos especiales, equipados en varias configuraciones di-
ferer.tes, que permiten que los miembros del grupo interactúen con apoyo
electrónico, frecuentemente en ferma da software especializado y con wna
persona qus da facilidades al grupo. Los sistemas para decisiones de grupo
estar, orientados para reunir a un grupo, a fin de que resuelva un problema
con la ayuda de varias apoyos como votaciones, cuestionarios, aportación
de ideas y creación de escenarios. El software GDSS puede ser diseñado
para minimizar el comportamiento negativo típico de \in grupo, tal como
la falta de participación debido al miedo a represiones por expresar un
PAKTE I: punto de vista nj popular c conflictlvo, dominación por miembros del gru-
FJNDAMfchTGS
DEL ANÁLISIS
po con loa dominante y la toma de decisiones de "pensamiento en grupo".
DE SISTEMAS Algunas veces loa GDSS son tratados bajo el término más general trabajo
colaborativo apoyado por computadora (CSCW por su; siglas en ingles],
4
que puede Incluir ei apoyo da software llamado "groupware" para la
colaboración en equipo por medio de computadcras en red.

Sistemas Se £?poj7o a ejecutivos

Cuando lo; ejecutivos se acercan a la computadcra, frecuentemente están
buscando formas que les ayuden a tomar decisiones a nivel eslratégico.
Un sistema de apoyo a ejecutivos [ESS) ayuda a éstas, paia organizar tus
interacciones con el ambiente externa, proporcionando apoyo de grádeos y
comuniíacionas en lugares accesibles tales como salas de juntas u oficinas
personales corporativas, Aunque lo; ESS se apoyan en la información ge-
nerada por los TPS y los MIS, los s.stemas de apoye a ejecutivos ayudan a sus
usuarios a que ataquen problemas de decisión sin estructura, que no son
específicos de una aplicación, creando un ambiente que ayude a peosar acer-
ca de los problemas estratégicos de una manera informada. Los ESS extien-
den y dan apoyo a las capacidades de los ejecutivos par* encontrar sentido
en sus ambientes.

La necesM def análisis 5 í'iseño Je sistemas

El análisis y diseño de sistemas, tal como es ejecutado por los analistas de
sistemas, busca analizar sistemáticamant» la entiada de datos o el flujo
de datos, el proceso o transformación ca los datos, el almacenan)ento de
datos y la salida ds infornacidn dentra del contexto de un negocio particular.
Además, el diseño y análisis de sistem&s es. u.sa.d.3 pira analizar, diseíVav e
implementar mejoras en el funcionamiento da los negocios que pueden ser lo-
gradas por Któdío del usa de sistemas de infermacídn compularizados
nstaíacúón de un sistema sin la piitieación adecuada lleva a glan-
des frustraciones, y frecuentemente causa que el siste-ruü deje de ser
usado Ei análisis y diseño da sistemas Heva estructura al análisis y diseño
de siíteniELs de inforaación, ua costoso esfuerzo que d« otra íorma podiía
haber sido hecho de modo casual Puede ser visto como una serie de prece-
sos llevados acabo íislemáticariiente para mejorar un negocio por medio
del nao de sistemas de infouuacíán computarizide». Grar. parta del anílisis y
diseño de sistemas involucra e] trabajo con los tisuarics actuales y Eventuales
sistemas de iníormaclón.
*
üsMíinos finalts
Cualquiera que ¡nteractúe con un sistema de infoLTnacidn en el ccritexto Í'P
su ti-abajo ín h organización puede ser llamado un USULTÍC Bn&l. A lo lar^t
de los afioí se han hecho briosas !a* distinciones entre usuarios Adema;
cualquier categoría de usuarios empleada no der>e ser visticomu excluyeme.
Sin iinpoita; cotnc ¿e hayan clasificado bs usuaiios finales, un ho:nc
es psrtinente al anatisU de sistemas: el irivo.uc'.amiento del usuario a le
largo dsl proyecto, es crítico para e. desarrolle exitoso de lo¿ sistema:- de
información computariz&dos. Los analistas de si Hf« mas, en vos papeles den-
tro de la organizaciórv se :ta.Un a continuaci<ÍH, son si C'.TO componente
esencial para el ¿esarrollodeiisletnas de infcmiaciSn,

EL PAPEL DE EL ANALISTA DE SISTEMAS

Los analistas de stslemas aGiioialmente valoran la manen en que
r.an tos. negocios axaminando la entrada.«! procesamiento de datos y
níbrmacíón cori ul propósito Je niejorar lus pvcr:¿sr>s
 Muchas mejoras involucran naejoi apoya para las funciones de los negocios
por medio del usó de sistemas de información, computerizadas. Esta defi-
nición enfatiza un enfoque sistemático y metódico para analizar, y posi-
blemente mejorar, lo que está sucediendo en el contexto específico creado
por Utl negocio.
Nuestra definición de un analista de sistemas es necesariamente am-
plia. El analista debe ser capaz de trabajar con gentes de todas las descrip-
ciones y debe tener experiencia en. el trabajo con computadora*. El analista
desempeña muchos papeles, balanceando a veces varios al mismo tiempo.
Los ties papeles principales deí analista de sistemas son: consulter, exper-
to de soporte y agente de cambio.

EÍ attaluta 6e sisteméis como consulto!

El analista de sistemas frecuentemente actúa como consultor y, por lo tan-
to, puede ser contratado específicamente para que se encargue de los asun-
tos da los sistemas de información dentro de un negocio. Esto puede ser
una ventaja, debido a que los consultores extemos pueden llevar con ellos
una perspectiva fresca que no poseen otros miembros de la organización.
Pero también puede decirse que los analistas externos están en desvéntala,
debido a que la verdadera cultura organizacional nunca puede ser conocida
per un extraño
Como consultor externo se apoyará en gran forma en los matados sis-
temáticos tratados er. este texto para analizar y diseñar sistemas de infor-
mación y adecuarlos para un negocio en particular. Adicional mente, se
apoyará en los usuarios de los sistemas de información para ayudarse a
comprender la cultura oi^ganizicional a partir de sus puntos de vista.

BÍ amlhta de sistemas como experto íe soporte

Otro papel que tal vez requiera desarrollar es el de experto de soporte en
un negocio donde se está empleado regularmente en alguna actividad de
sistemas. En e»te papel el analista se apoye en su experiencia profesional
relacionada con el hardware y software de computadora y su uso en el ne-
gocio. Este trabajo frecuentemente no es un proyecto de sistema completo,
sino solamente paqueñas modificaciones o decisiones que afectan a un
solo departamento:
Como experta de soporte na está administrando el proyecto, sino sim-
plemente está sirviendo como un recurso para aquellos que b manejan.
Si se es un analista de sistemas empleado por una oiganizacicm de fabricación
o servicios, muchas cíe las actividades diarias pueden ssr desarrolladas en
este papel.

EÍ analista ite sistemas como ¡lásate be cambio

El paael más comprensivo y responsable qu.e toma un analista,de sistemas
es el de agente de cambio, ya sea interno o externo si negocio. Como ana-
lisia se es un Egente de cambio cada vez que se ejecuta cualquiera de las
actividades del ciclo de vida del desarrollo de sistemas (tratado en la si-
guiente sección) y se está presente er. el negocio por un periodo extendido
{desde dos semanas hasta más de un año) Un agente de cambio puede ser
PARTE 1: definido como un. persona que sirve de catalizador para el cambio, desarrolla
FUNDAMENTOS
DEL ANÁLISIS un plan para el cambio y trabaja junto :oo otros para facilitar ese cambio,
DE SISTEMAS La presencia del analista &n el negocio hace el cambio. Como analista
6 de sistemas se debe reconocer este hecno y usarlo como punto de inicio
 FIGUHA 1.
Las sÍBtc fases del tiel
fie vide del desarroll
de sis'eai^;

paia el análisis. Ésta es la rizón por la que se debe interactuar con los
usuarios y administradores (si es que no san el mismo! desde el inicio del
proyecto. Sin la ayuda de ellos no se podtá comprender lo cue está suce-
diendo en una O7ganizacidn y no se padiá realizar el cambio real.
"S. ai cambio (esto es, las mejoras al negocio qi¡3 puedan ser realizadas
mediante sistemas de información) se ve garantizado después del análisis,
sí siguiente pase es desarrollar un plan para el cambio junto con laE gentes
qut deben realizarlo. Una vez que se logra el consenso para el cambio a
realizar, se debe interactuar constantemente con aquellos que están ha-
ciéndalo. Se facilita el cambio usando la experiencia propi"1. tanto COTÍ los
humanos como con las computadoras, para lograr su integración en un sis-
icTna. de información hambre-máquina.
Actuando si analista de sistemas como agente de cambio se es defensor
de una línea de cambio particular que involucra el uso de sistemas du in-
formación, Adicionalmente se les enseña a los usuarios el proceso del cam-
bio debido a que $2 está consciente de que los cambios en el sistema de
información no suceden independientemente, sino que lambían causan
cambios en s. rea!o de !a organización.

nito De eí finalista Se sistema!

h partir de la descripción anterior de los papeles que desempeña si
analista de sistemas, es fácil ver que el analista de sistemas exitoso dcbft
poseer un alto rango de cualidades. Muchos tipos ce gentes diferentes son
analistas de sistemas, por Jo qaa cualquier descripción quedará corta en algu-
na forma. Sin embargo, hay algunas cualidades que parecen mostrar la ma-
yor:'a de los analistas de sistemas.
Antes que nada, ol analista es un soiucionadur de problemas. Es \ina
•sona que ve el análisis délos problemas carr.o un reto y cue disfruta al
.corilrai- soluciones Funcionales. Cuauda os necesario, el analista daba ser
capaz de atacar sistemáticamente la situación a la mano por medio de la
aplicación hábil de herramientas, técnicas v experiencia El analista tarn-
bién debe ser un comunicador apa-z de relacionarse en ferma signiíic a:
in las demás gentes a través de periodos extensos. Los analista? de slsleníss
bsitan la suficiente experiencia en compuiacíón pare programa!.
a comprender Las capncidades de las computadoras, para recoge/ los : 5 •
querimlentos de información de los usuarios y para comunicarlo que se
necesita a los programadoies.
El analista de sistemas deba ser un individúe a utodiscip tinado y auto-
motivado, capaz ce manejar y coordinar ¡nríümersblís recursos del proyec-
to incluyendo a otras gentes. El análisis de sistemas es una cariara que
demanda mucho, pero en compensación es siampre cambianta y siempre
retadora

EL CICLQ DE VIDA DEL DESARROLLO DE SISTEMAS

A lo largo de este capítulo hemos he;hc referencia al enfoque sí sigmática
que toma el analista para el análisis y diseño do sistemas de ínformación-
Mucho de esto está comprendido en lo cus es llamado el c:clc de vida del
desairolio de sistemas (SDLC por sus siglas en inglés], EJ SDLC es un enfo-
que por fases del anáfisis y diseño que sostiene que los sistemas son desa-
rrollados de mejor manera mediante el uso de uc ciclo específico de
actividades de el analista y del usuario.
Los analistas no están de acuerdo can qué tantas fases exactas hay en
ei ciclo de vida del desarrollo de sistemas, peto, por lo general, alahan su
enfoque organizado. Aquí hemos dividido el ciclo en siete fases, tal como
se muestra en la figura 1.2. Aunque cada fase es presentada en forma dis-
creta, nunca se lleva a cabo jomo un pasa aparte. En vez de ello, varias ac-
tividades pueden suceder simu i tana amenté, y las actividades pueden íer
repetidas. Ésta es la razón por la cual es máí útil pensar que ei SDLC se lo-
gra en fases (con actividades traslapándose y luego disminuyendo) y no en
pasos separados.

]&entífic¡aeiÓK be probemos, oportunidades JI 063'etfwis

En la primera iise del ciclo de vida del desarrollo de sistemas el analista
tiene que ver con la identificación de problemas, oportunidades y objetivos.
Esta etapa eí critica pata el éxito del rssto de proyecto, dabido a que nadie
quiere dísperdiciar el tiempo subsecuente resolviendo al problema equi-
vocado.
La primera fase requiere que el analista obseive honestamente lo que
está sucediendo en un negocio. Luego, junto con los demSs miembros de la
organización, el analista tace resaltar los problemas. Frecuentemente estos
ya han sido vistos por tos demás, y son la razón por la cual el analista fue
llamado inicialmsrste.
Las oportunidades son situaciones que el analista considera que pue-
den ser mejoradas por medio del uso de sistemas de información compu-
tarizados. El aprovechar las oportunidades puede permitir que el negocio
gane un avance competitivo o ponga un estándar de la industria.
La identificación de objetivos es también un componente importante
de ¡a primera fase. £n primer lugar, el analista debe descubrir lo que está tra-
tando de hacer el negocio. Luego será capaz de ver sí algún aspecto de la
aplicación de sistemas de información puede ayudar pira que el negocio al-
cance sus objetivos atacando problemas específicos u oportunidades.
Las personas involucradas en la primera fase son IOÍ usuarios, analis-
tas y administradores de sistemas que coordinan el proyecto. Las actividades
de esta fase consisten en entrevistas a los administradores de los usuarios,
sutuarizacidí; de( conocimiento obtenido, estimación del alcance del pro-
yecto >' cbcvmenucidn de los resultados. La salida de esta fase es mi
estudio de factibilidad que contiene una riefinkidn del problema y la
sumarizacidn de los objetivos. Luego los administradores deben tomar una
decisión pan ver si continúan con el proyecto propuesto. Si el grupo de
usuarios no tier.e los suficientes fondos en su presupuesto y desea aUca:
problemas que no están relacionados, o los problemas no requieren, un sis-
tema tíe cómputo, puede ser recomendada una solución manual y el pro-
yecto de sistemas ya no continúa.

Deíemiifttdcn 5e ios requtr)inkr,wsie mfonmcióM

La siguiente fase a la que entra «1 analista es la de la detarminacidr. de los
requerimientos de inforniacicin para los usuaiios particulares invalucra-
dos. Entre las herramientas utilizadas para definir los requerimientos de
información en el negocio se encuentran; mueslreo s investigación de loí
dato* relevantes, entrevistas, cuestionarios, al compoitaiaietito de los to
ladoras (i© decisiones y su ambiente de oficina y lias:a la elaboración de
atipas.
En esta fase el analista está esforzándose por comprender qué infor-
cidn necesitan los usuarias para realizar su tinliajü. Se puede ver qus
ios de los métodos para determinar los requerimientos de información
crao la interacción directa con los usuario*, Esta fase sirve psrafoi-
la imagen que el analista tiene de la organización y sus olájetivos.
.lgunas veces solamente se completan las dos primeras lases del ciclo ds
vida del desarrollo de sistemas. Este tipo de estudio puede terier diferentes
propósitos, y es realizado típicamente por un especialista llamado analista
de informa ciún [IAJ.
Las personas involucradas en esta fase son los analistas y los usua-
rios, tfpicarestits les administradores de las operaciones y los [rebajadores
de ias operaciones. Ei analista da sistemas necesita saber los detallos da las
funciones actuales dei sistema: quién (las perssn&s que están involucra-
das), qué (la actividad del negocio), dónde leí ambiente donde se lleva a
cabo el trabajo), cuándo [en qué momento) y c<5mo (de qué manera se des£-
rro Jan los precudimientos actuales) del negocio bajo estudio. El analista
debe pregun:ar porqué el negocio usa el sistama actual. Puede haber muy
buenas razones para desarrollar el negocia usando los métodos actuales, y
deben ser consideradas cuando se diseña cualquier sistema nuevo.
Sin ambargo, si la rczón de las operaciones actuales es qu« J"siempre
se han hecho así", el analista puede desear ia mejora de los procedimien-
tos LE leingeniería de procesos del negocio puede ayudar a ecniarcar un
enfuque para volver a pensar en el negocio en forma creativa. Al téi-niina
de esta fese, el analista debe comprender el por qué de las funciones de]
negocio y tener mformadcSn completa sobre las personas, objetivos, datos y
procedimientos involucrados.

Avüáíiíis 3c (its necesidades Í)e( ststs«tó

La siguiente fase que realiza el a ralis'a de sistemas involucra el análisis de las
necesidades del sistema. Nuevamente, hflrrarciisntas y técnicas especíales
ayudan para que el analisla haga las determinaciones de los requerimientos,
na herramienta de rsUs es el uso de diagramas de flujo de daios para
agramaí la entrada, proceso y salida de las funciones del negocio an for-
gráfica estructurada. A partir de los diagramas de flujo de datos se de-
rrolla un dic;ionario de datos, que lista todos los conceptos de datos
CAPÍTULO i:
ados en el sistema, asf como sus especificacicnei. si son aiftLmirriéYiios y ASUMIR EL-AFEL
é tantc espacio ocupan cuando se impiimen. DESL AJÍ ALISTA
Durante esta fase el analista úf ristemas tambiáu analiza las dedsia- Di SISTEMAS
•s estructuradas que se hacen. Las decisiones estructuradas son aquellas 9
para las que puuden ser determinadas las condiciones como alternativas do
condición, acciones y reglas de acción. Hay tres métodos principales pata
él análisis de decisiones estructúralas: lenguaje estructurado, tab)ís de
decisión y árboles de decisión.
No ledas las decisiones de la orgirtiEacíón son estructuradas, pero to-
davía es importante que el analista de sistemas las comprenda. Las decisio-
nes semiestruciuradas (decisiones temadas bajo riesgo) son sustentadas
frecuentemente por lo; sistemas de apoyo a decisiones. Cuando ss finalizan
decisiones semi estructura das, el analista examina las decisiones con base en
el grado de habilidad para la toma de decisiones requerida, el grado de
complejidad del problema y la cantidad da criterios considerados cuando
se toma ía decisión.
El análisis de las decisiones de criterios múltiples (decisiones en las
que deben ser balanceados muchos factoresl también parle dü esta fase. Se dis-
pone de muchas técnicas para el análisis de decisiones ce criterios miíltiples,
incluyendo el proceso de compromiso y el uso de métedos ponderados
En este punto del ciclo de vida del desarroJlo de sistemas, el analista
prepara una propuesta de sistema que sumarlza lo que ha sido encontrado,
proporciona análisis da costo/beneficio de las alternativas y nace recomen-
daciones sobre lo que debe ser hecho [en caso de haberlo). Si alguna de las
recomendaciones es aceptable para la administración, el analista continúa
sobre ese curso. Cada problema de sistema es tínica y mines hay una sola
solución conecta. La manera en que se formula una solución o recomenda-
ción depende de la capacidad y entrenamiento profesional individual de
cada analista.

Diseño Seí íistewia recomettflaiSí)

En esta fase del ciclo de vida del desarrollos de sistemas, el analista usa la
información recolectada atitariormente para realizar el diseilo lógico deí
sistema de información. El analista dissña procedimientos precisos para la
captura de datos, a fin ds que los datos que van a entrar al sistema de infor-
mación sean correctos. Además, el analista también proporciona entrada
efectiva para el sistema de información mediante el uso de técnicas pata eí
buen diseño de Forma; y pantallas.
Parte del diseño Idgico dal s;srema de información es diseñar la interfaz
de usuario. La ¡nterfaz conec'a al usuario con el sistema y es, por lo tanto,
extremadamente importante. Ejemplos de interfaces ce usuario incluyen1
un teclado pera introducir preguntas y respuestas, menüs en pantalla para.
elegir comandos del usuario y un ratón para seleccionar opciones.
La fase de diseño también incluye el diseño de archivos o bises de
datos que guardarán la mayor parte de los datos necesarios para los
tomadores de decisiones de la organización. Una base de datos bien organi-
zada es la base para todos ios sistemas de información. En esta fase, el
analista también trabaja con :os usuarios para diseñar la salida (ya sea er.
pantalla o impresa) qu6 satisfaga sus necesidades de información.
Por Ultimo el anaiista debe diseñar procedimientos de contrcl y respal-
do para proteger al sistema y a los datos y producir paquetes de espec incalió-
Ees de programa para los programadores. Cada paquete debe contener diseños
de eotiada y salida. Especificaciones de archivos y detalla de procesamiento,
y también puede incluir árboles o labias de decisión, diagramas de flujo de da-
tos, un diagrama de fiujc del sistema y ios uembres y funciones de cualesquier
de las rutinas de código que ya hayan sido escritas.
 FIGURA l . :
Algunos ¡tivestigadore;
estimtn tino la cantidad O
tiempo empleada en e
[iiLiileniniitr.to del ilstemí
puede ser basta He 80% do
[lempo fatal ftmpltadc en Io¡
prrjyoclos de sistrui.i-

iocvmtntaáón
En la quinta fese del ciclo de vida del desarrollo de sistemas el analista Ira-
baja con los progiamadores para desarrcllar cualquier software original que
s; necesite. Algunas de las técnicas estructuradas para el diseña y docu-
mentación de software ineluyen diagramas estructuradas, el n;élcdo HIPO,
diagramas de fhijo, diagramas Nassi-Schneiderman y Warnier-Orr y
siudocódigo. El analista de sistemas usa uno o más de es¡os dispositivos
para comunicar al programador lo qua necesita ser programado.
Durante esta faje, el analista también trabaja con les usuarios para de-
sarrollar documentación efec:iva pira si software, inctuyando manuales
de procedimientos. La documentación ie dice al usuario la minera de usar
el scftivare y también qué hacer si se suceden problemas con el software.
Los programa dores tienen un papel principa! en esta fase conforme
diseñan, codifican y eliminan errores de sinlaxis de los programas ce compu-
tadora. Si el programa va a ser ejecutado en un ambienta de raacro-
computadoia, se debe crear el lenguaje de ccntrol de trabajos (JCL1. Paca
asegurar la calidad, un programado! puede realizar ya sea un diseño o un
ensaya del código, explicando Las partes complejas del programa a un equipo
de c:ro5 programadores.

Pmefcas j mantenimiento Sef sistema

Antes de que pueda ser usado, ©1 sis:ema de iníbrmaiión debe ser probado.
Es mucho menos costoso encontrar problemas antes de que el sistema sea
entregado a los usuarios. Algunas de las pruebas son realizadas por los pro-
gnmadores solos, y otres por los analistas da sistemas ¡unto ecn los progra-
madores. Primero se ejecuta una serie de pruebas para que destaquen los
problemas con datos de ejemplo y eventualmínte con datos reales del sis-
tema actual.
El mantenimiento del sistema y de su documentación comienzan en
esta fase y es efectuado rutinariamente a lo largo de la vitld del sistema de
información. Mucho del trabajo rutinario A»', programado!1 consiste en el
mantenimiento, ya qus los negocios gaslan grau canlidad de dinero en
dicho mantenimiento. Muuhos de kis procedimientos sistematices qie em-
plea el analista a lo largo de) ciclo de vida del desarrollo dal sistema pue-
den ayudar a asegurar que e! mantenimiento se mantenga al mínimo.

Ivnf;íement-ici<m y evaluación bel sistema

En esta fase del desarrolla d«l sistema el analista ayuda a implemeuíaL ?1
sistema de infonnacíón. Esto mrluye el enrernrnÍPnto de Jos usual ios para
FIGUJIA1.4
Ccnsumo de recursos a lo
largo de h vida del lísteme.

que manejen el siüema. Algún entrenamiento es hecho por los proveedoras,

pero la supervisión del entrenamiento es responsabilidad del analista de
sistemas. Adicionalmanta, el analista necesita un plan psra una conversión
suave del sistema antiguo ai nuevo. Este proceso incluye la conversión de.
archivos de formatos antigüe* a nuevas o la conítniccitin de una base de da-
tos, la Instalacidn dé equipa y la puesta del nuevo sistema en producción.
La evaluación se muestra como parte de esta fase final de ciclo de vida
dal desarrollo del sistema, principalmente pira efectos de discusión. De he-
cho, ia evaltiacián se raali2a durante cada fase. Un cñterio principal que debe
set satisfecho es si los usuarios pretendidos ya están usando el sistema.
Debe hacerse notar que a veces los sistemas trabajas en forma cfclica.
Cuando un analista termina una fese del desarrollo del sistema y pasa a la
siguiente, el descubrimiento de un problema puede otügar a qu? el analista
regrese a la Fas» anterior y modifique el trabajo que a'iá hizo. Por ejemplo,
durante la fase de prueba el programsdoT puede descnbrir que ai programa
ao trabaja correctamente, ya sea debido a que no se escribid código para
apoyar determinadas partas cel diseño del sistema o aquel diseño fue
incompleto. En cualquier caso deben ser modificados los programas, y
el analista puede tener que cambiar algunos de los materiales del diseño
del sistema. A su. vez, esto puede necesitar qia el analista se reúna con
el usuario y vuelva a investigar cdmo funciona una actividaá específica del
negocio.

La iwjwrtjhcw ctet mantenimiento

Después de qus el sistema está instalado se le debe dar mantenimiento,
esto significa que los programas ds computadora deban ser modificados y
mantenidos actualisados. La figura 1-3 muestra la cantidad promedio de tiem-
po gastada en mantenimiento en una instalación MIS tfpica. Las estimacio-
ne» del tiempo gastado pen los departamentos en mantenimiento ha ido de
48 al 60 por ciento del tiempo tota! empleado en el desarrollo de sistemas.'
Queda muy poco tiempo para nuevo desarrollo de sistemas. Conforme aumen-
ta, la cantidad de programas ascritcs. también aumenta la cantidad de man-
tenimiento que .ec miren.
1
S. Yoo y K- E, Kendall. "Pseudocode-Box: An Approaqh to More Untlerítaiidabte,
Producti<re, aocj Adaptable Software Design and Coding." Intertwlional fournal an
Poücyand Information. Vol. 13. No. 1, junio de 1986. pp. 39-51.
 El mantenimien'o se realiza pot des razonas. La primara de estas as
para corregir errores de software. Sin importar que tan completamente se
pruebe el sistema, se deslizan errores en IOÍ programas de computadora. Los
errores del software comercial para roicroccniputadoTas son a veces docu-
mentidos come "ationalías conocidas", y SOEI corregidos cuandu sen lanza-
das nuevas versiones del software o versiones intermedias. En el software
persoTializado los errores deten sai corregidos conforme son detectados.
La otra razón, parí realizar el manteíiimisiita del sistema es par; mejorar
las capacidades del softwaie en respuesta ¿ las necesidades crganlíacio-
nales cambiantes y, por lo general, involucran algunas de las siguiónos
tres situaciones:

1. Los usuarios frecuentemente solicitan características adicionales des-

pués de que se familiarizan con el sisiema de cómputo y sus cepací-
dades. Esías características solicitadas puedan ser tan simples :o:no
al desplegado de totales adicionales en un reporte o tan complicadas
como el desarrollo de nuevo software.
2. El negocio cambia a través del tiempo. Se debe modificar el software
para abarcar cambios ¡ales como nuevos requerimientos de reportes
gubernamentales o corporativos, la necesid&d de producir nueva in-
formacidri para clientes, etcétera.
3. El hardware y software están cambiando a un ritme acalorado. Un sis-
tema que usa tecnología antigua puede ser modificado para usar las
capacidades de una tecnología más nueva. Un ejempb di tal cambio
es el remplazo de una terminal de rriacrocomp.it adora con una esta-
ción de trabajo de microcomputadoTa. o uní microcomputadora con
una computadora ce escritorio.

La figura 1.4 ilustra U cantidad de recursos, per lo general tiempo y dinero,

gastados en el desarrolle y mantenimiento dol sistema. El atea bajo la curva
representa la cantidad total de ddlaxas gastada. Se puede vei que B lo targo
del tiempo es probable que el costo de manlenimientc exseda al del desairo-
Ib del sistema. En cierto punto eí más conveniente realizar un nuevo estudio Hel
sistema, debido a que «I costo Je mantenimiento cont invado es claramente
mayor que !a creación de un sistema de información completan en: e nuevo.
Resumiendo, el manten ¡miente es un proceso continuo a lo largo del
cicle de vida de un sistema de información. Después de que es instalado el
sistema de infarraación. el mantenimie^o por lo general toma la forma de
corrección de errores de programa no detectados previamente Una vez
que son corregidos, el sistema alcanza un eslade establ8 proporcionando
servicies confiables a sus usuarics. El mantenimieiiío durante este poiiodo
puede consistir en la eliminación de unos cuantos eriores no deteclaHns
anteriormente y la aítuilizccitín del siatema con una cuantos mejoras ma-
nores. Sin embargo, conforme jiasa si tiempo y cambia el negocio y la tec-
nología, ios esfuerzos (le mantenimiento se incrementan dramáticamente.

USO DE LAS HERRAMIENTAS CASE

A lo lais(o de este libro enfatuamos 'a necesidad de in. enfoque 3Lstemá:icú
CAPÍTUIO ]:
y profunde al análisis, diseño e imptemantacídn de los sistemas da informa- ASUMIR EL PAPE!.
ciriu. Reconocemos que paia ser productivos los analistas de sistemas debíin DE EL ANAUSTA
ser organizados, precisos y completos en lo que se prnpcr.en hacer. En los DE SISTEMAS
li aáoa los analistas hau comenzado a ¿enaficiarse da nuevas herra- 13
FIGURA í.5
Los aaa¡Utas pueden mejorar
su comunicación con los
usuarios con la ayuda de
diigramas generados por la
computadora.

mientas de productividad que han sitio croadas implícitamente para mejo-

rar mi trabajo rutinario medianía un apoyo automatizado. A estas SÍ les lla-
ma herramientas CASE, que significa herramientas para ingeniaría de
software asistido por computadora. Un paquete CASE popular es Excels-
rator. Debido a que está basado en microcomputadoras, en vez de estar li-
mitado a tnacrocomputadcnas como sucedió con sus predecesores de los
aflos setenta, Excelerator ha llegado a aer la herramienta rundamsntal de
trabajo de muchos analistas.
Los analistas se apoyan en las herramientas CASE para aumentar ia
productividad, comunicarse más efectivamente con los usuarios e integrar
el trabajo que realizan en el sistema, desde al principio hasta el fin del ci-
clo de vida.

Aumento be ¡a proinaivibad bel analista

Excelerator permite que sos usuarios tracen y modifiquen diagramas fácil-
mente. Por nuestra definición, ei analista puede entonces llegar a ser más
productivo simplemente por la reducción, del tiempo considerable, que es
gastado típicamente en el txaio namial da diagramas de flujo de datas hasta
que son aceptados.
Un paquete de herramientas tal como Escelarator, XperCASE o Visible
Analisl también mejora la productividad del grupo, peraítieado que los
analistas compartan fácilmente su :rabajo con otros miembros del equipo,
que puedan sirnplenieate dar acceso al archivo en su microcomputadora y
revisar o modificar lo que ha sido hecho. Esto reduce el tiempo necesario
para reproducir y distribuir los diagramas de flujo de datos entre los miem-
bros del equipo. Ademís. permite que los miembros del equipo del anaiísta
de sistemas trabajen coa los diagrimas cada ves que tengan tiempo, en VEZ da
obligar a una cJendarízación estricta de la distribución y a la respuesta
rea ¡intentado ra.
Las herramientas CASE también facilitan le interacción entre los
miembros del equipo al hacer de la diagr-mucidn un prcceio dinámico a
¡nteiactivo en vsz de ser uno en donde los cambios son ptoblemiticos y
que, por lo tanto, tienden a convertirse en una pérdida de productividad.
En sstt caso. ta herramienta CASE para el trazo y registro de los disgramas
dé flujo proporciona un registro de .os cambios en la manera de pensar del
o co.i respecto a los flujos de dalos.

fAttorc iit (íi comunicación del' dHíifijM-nsuario

Parí que el sistema propuesto se convierta en realidad y sea usado de he-
cha, es esencial una ccmunicacióii excelente entre los analistas y usuarios
i lo largo iel ciclo de vida del desarrollo del sistema. El éxiío de una even-
tual implementacidn del sistema depende de la capacidad da los analistas
y usuaiioi para comunicarse en una forma significativa, Hasta aiora les
analistas que actualmente usan las nuevas herramientas CASE han experi-
mentado que su uso promueve una comunicación mayor y más significati-
va entre usuario y analistas.

PROPORCIONA UN MEDIO DE COMUNICACIÓN. Tanto los analistas como

los usuarias reportan que las herramientas CASE les han proporcionado un
medio de comunicación, aceica ríel sistema durante Sü conc^pt j.al¡tfición,
tal ;omo se nmastrs en la figura 1.5. Mediante el uso del apoyo aatcnietiza-
do que proporciona salida en pantalla, los clientes pueden ver fácilmente
cdriio son representados los flujos de datos y otros conreptos del sistema, y
solicitan coitecciones o cambios que SÍ hibríanllávado demasiado tiempo
cor. un sistema manual.
El que un diagrama en particular sea considerado útil pr>L los usuarias o
analistas al Elna": del proyseto es cuestionable Lu que es importante es que
tal apoyo automatizado para muchas actividades de diseíío del ciclo de
vida [frecuentemente imperceptibles a los usuarios) sirve como un media
pasa lograr un fin, actuando como catalizador para ta interacción analista-
usuaiio. Los mismos argumentos usados para apoyar el papel de las b«m-
mientas CASE un la productividad aumentada son igualmente válidos en
ests campo: ssto es, las tareas manuales de trazado, reproducción y;.distri-
bución se llevan mucho meaos tiempo y, por lo tanto, el trabaje en ¿narcha
puide sei compajtido más fácilmente con los usuarios.

iHtejjrrtciÓH te fas actrvibadei ie[ ciclo Se T>idd

La tercera raaón para el uso de herramientas CASE es para intefirer las ac-
tividades y proporcionar continuidad de ur.a fase n la siguienle a lo largo
de. ciclo de vida del desarrolle! dé sistemas.
Las herramientas CASE son especialmente útiles citando uní fase
particular del ciclo de vida requiere varias interacciones o let-oaümantación
y Modificación. Tome en cuenta que es importantí el involucramienlo del
usuario durante todas las fases. Li integración de las actividades por me-
dio del uso de lecnologíss de ambientes integrados da "hí ir [amientas, faci-
lita que los usuarios comprendan la man?ra en que están iuterreLa^ionadas
e intel'dependientes todas las fases del ciclo de vida.

ETWIWCIJH precisa oe los cnmoios reí maiitenmuento

i

La cuarta finan, y posiblemente una de las más importantes p i r a sí uso tío he- ,a
rramientas CASE, es que permite que l o s u s u a n o s a n E l í c í n y valoren el im- A.SUMlt<Ei PAPEL
p a c t o d e los c a m b i o s de maiiífíiiiuLiL-tilo P Ü I q e r r : p ! t , puRHí í e i q i i K el tf.mafto : •• •
[ de ur¡ eismant^. tal como un numero da cliente, necesite ser agrandado. DESISTEüAS
LE herramienta CASE liará u.ia refeiencia cruzadi de t-ccta-=; las pauta- 15
lias, reportes y archivos en dcside es usado el elemento, produciendo un plan
de mantenimiento comprensivo,

CASE DE NÍVLL SUPERIOR E INFERIOR

Las herramientas CASE sor. clasificad** cómo CASE de nivel Inferior,
CASE de nivel superior y CASE integrado, que combina el CASE inferior y
superior en un solo juego de herramientas. Aunque los expartos no están
de acuerdo can lo que constituye precisamente una herramienta CASE su-
perior y una inferior, puede ser útil conceptual izar las herramientas CASE
superiores de acuerdo con quienes dan soporte. Las herramientas CASE supe-
riores ayudan principalmente a los analistas y diseñadores. Las herramien-
tas CASE inferiores son usada* más Eracuentemen!e por programadoies y
personal, que deben ímplementer el sistema disaflado poi medio de las he-
rramientas CASE superiores. La figura 1.6 lista algunas de las herramientas
CASE más populares.

Herramientas CASI Be nivel

Una herramienta CASE superior permite que el analista cree y modifique el
diserto de sistema. Toda la información acerca del proyecto es guardada
an una enciclopedia llamada el depósito CASE, que es una gran colección
de registros, elementos, diagramas, pantallas, reportes y otra información, tal
como se ilustra en lá figur* 3.7. Los reportes de análisis pueden ser produci-
dos usando la información del depósito, que mostrará qué parte del diseño
está incompleta o contiene errores.
Las herramientas CASE superiores también pueden ayudsr a dar so-
porte al modalaje de los Tequerimientos funcionales de t n a organización,
asistir a los analistas y usuarios en el trazo de ÍES Erontens de un proyecto
dado y ayudarlos a visualizar la manera en que el proyecto engrana con otras
panes de la organÍ2acic5n. Además, algunas herramientas CASE superiores
pueden dar soporte a la elaboración de prototipos ce diseíios de pantalla y
repartes.
 FIGURA 1.7
El concepto de depósito

rramientíís CASE &; tiii-el inferior

i hcrramisntís CASE -.nfericres son usadas para gsnerar cdáigo fuente
i computadora, eliminando IE necesidad de programar el aistema. La°e-
eración de código tiene varias venia as:
1. El sistema puede ser producido más rápidamente q¿e mediante la es-
tructura ds programas de computadora. Sin embargo, si familiarizarse
con la metodología usada por el generador de cádigo frecuentemente se
lleva mucho tiempo, pir lo que la generación de pngrainas puede ser
;mnalmejite Tiás lenta. Además, &l diseño duba ssr csdo completamen- CAPÍTULO t:
PA?EL
te en e! juego de hemuiiientaa, loque pueda requerir ur, tiempo laigo. DE EL ANALISTA
2. Le cantidad de llempo empicada en el mantenimiento disminuye con la DI
generación del cídigo No hay necesidad de modificar, probar y 17
 flcia *« «Ma tfal ¿«arrollo til litums USE
programas do rompufnriori. £n vez de aJ3o, e] diseño en CASE a mo-
dificado y el código es regenerado. La di3m:nacidn del üenpo em-
pleado en el mantenimiento da como resultado más tiempo para
desarrollar nuevos sistemas y ayuda a reducir si trabajo pendiente de
ios proyeclos que se tienen considerados a desarrollar.
3. El cddígo pyede ser generado en más de un lenguaje de computadora
por lo que es más fácil emigrar sistemas de una plataforma, tal como
una macrocomputadora., a otra, tal vez ana microcomputadora. Por
ejemplo, Excelerator puede generar código en COBOL, C, BASIC y ?LJ1
usando ei mismo daptísíto, o enciciopedia.
4. La generación de código proporciona una fonda encienta en costo
para adecuar sistsmis comprados a proveedores da teñeras partes, y
así satisfacer las necesidades de la organización. Frecuentemente Ja
modificación de software adquirido requiere un esfuerzo tan grande
que el costo de hacerlo excede al del software. Con software de gene-
racidn de código, la compra cié un diseño CASE y su deposite para la
aplicación petmife que el analista modifique el diseño y genere el sis-
tema de cómputo revisado.
5. Ei cddigo generado está libe de errores de programación úe compu-
tadora. Los tínicos errores potenciales son erreres de diseño, que pue-
den ser minimizados por la ejecución de reportes de análisis CASS
para aseguraras que sí diseño de sistemas saa completo y correcto.

FIGURA 1.9 Corporación Nombra del Producto

He-rjant.entfls de iagciueiía
inversa.- selección,: .Bachman Information Systemj. Inc. Analyst Capture
Cadre Tecruiofogies, \K Teamwork
PAKTE 1 CGI Systems, Inc. • "acRflvírsft
FUNDAMENTOS Intersoh Xt flecover
DEL ANALISK Desígn Recove/y
DE SISTEMAS Siemens AS- XpetCASF.
18
 FIGURA 1.10
Conceptos

La figura 1.6 ¡lustra el ciclo de vida del desarrollD ds sistemas tradicional y

el ciclo de vida CASE. Observe que las partes de codificación, prueba y de-
puración de programas de! ciclo son eliminadas en el ciclo de \\do CASE.

INGENIERÍA INVERSA Y REIN6ENIERÍA DE SOFTWARE

La ingeniería inversa de software y la reingfnierfa son métodos para enten-
der la vida de programas antiguos, llamados iofwaie legado. Ambos enfo-
ques usan software CARE (reingeniería asistida por computadora) para
analizar y reestructurar el código de computado: a existente. Se dispone de
varios juegos de herramientas para ingeniería inversa. Se encuentran rt;iu-
midos en la figura 1.9.
Tome e.i cuenta que el térranio ieír.g$meiía es usado en varios con-
tex'.os diferentes de ingeniería, programación y negocios Fiecuyuieineíite
es usado para o^e signifique "reingenierís de procesos de negocio", que ES
forma de recrienlai una organización alrededor de procesos principales.
Los analistas de sistemas pueden desarrollar un papel importante tn la
reingeniería de procesas de negocios, debide a que muchos de los cambios
varios son posibles solamente debido a 1¿ disponibilidad de tecnología
de iiifciLTnariín mnovativa Mudioi aiiaiisias eslán siendo educados en Ter-
ina tal que faciliten los cambios organizadonales
La ingeniaría inversa es lo opuesto a la ger.eíaiíidn de «5digv> VA ¡
go Euente de la compuLadora es sxaminado. titialiíado y canvertk'o en en'i-
dades dfíl depósito, tal como se muestra en la figura 1.10. El prime: paso eti
la ingeniería inversa de software es cargar el código existente de pfogramus
ele computadora, til cuino está escrito en COBCL. C \i sitie lenguaje do alto
nivel, en el juepo de henamíentns. Dependiendo del juego de h aira mientas
de ingeniería ir.veisa utilizado, el ectiigo es analizado y el juego dn herra-
rnisntas produce parte o todo de lo siguiente

. Estructuras y elementes de datos que describen los artíiivoi y

tros guardados pnr ti sistema
2 Diseños rift pantalla.;, si es que e! pragiDma trabaja en línea,
3, Diseños de leporte pura los programas por lotes.
4 Una gráfica di estructura tmiesira IE jerarquía de los módulo? del pro-
grama.
Diseño y relaciones de la base de datos. CAPfTVLO 1:
ÁSUMIHELFAPEL
El diseño guardado anel depósito puede ssr modificado o incorpuiaJu DE EL ANALISTA
i otra información de proyecto CASE. Cuando se han lenninado tcxlcts las DE SISTEMAS
puede ser re=e:iei£dc- el ¿üdigo d«l nuevo sistema La tein- 19
geniería se refiere al proceso completo de convertir el código de programa
al disefto an CASE, la modificación del diseño y ia regeneración del nuevo
código ÚB programa.
Las ventajas de utilizar un juego de hsrramientas de ingeniería inver-
sa son numerosas:

1. Se reduce el tiempo requerido para el mantenimiento del sistema, li-

berando tismpo para nuevas desarrollos.
Z. Se produce documentación, que puede no habar existido o ser míni-
ma paca los programas antiguos.
3. Se crean programas estructurados a partir de código de computadora
sin eslructuTa o débilmente estructurados.
4. Es mí* fácil realizar cambios fniuros de mantenimiento, debido a que
ios cambios pueden ser hechos al nivel de diseño en vez de a! nivel de
cddtgo.
5. Se puede realizar el análisis del sistema para eliminar partes da có-
digo de computadora no utilizadas, que pueden existir en programas
antiguos y que ya son obsoletos par revisión de los programas a la lar-
go de los años.

ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS

Un nuevo y muy diferente enfoque al análisis y diseño de sistemas es el
análMs y disefio de sistemas orientados a objetos (O-O). Las técnicas orien-
tadas a objetos, que están besadas en los conceptos de programación orien-
tada a objetos, pusden ayudar a responder las demandas oiganizacicnales
para nuevos sistemas que requieren mantenimiento, adaptación y rediseño
continuos. Básicamente, an la programación orientada e objetos son creados
objetos que incluyen :io solamente cddigo acerca de lp$ dato$ sino tambián
instrucciones acerca de lis operaciones que se pueden realizar 30H ellos.
Usando el enfoque Coad y Yourdon al análisis D-O, empleamos un mo-
delo de cinco capas consistiendo de: [1) capa cías a/ob jet o, (2) capa da estruc-
tura. (3) capi de atributos, (4) capa de servicia y [51 capa de áreas. El análisis
y dtseñú orientada ¿ objetas puede ser vista como el desarrollo y ensamble de
estas cinco capas en un paquete de diseño que comprende a todas. Las acti-
vidades de diseño son agrupadas en los cuatro componentes principales del
sistema fina'.: el componente de problema, componente de interiaz humara,
componente de manejo de datos y componente de manejo de tareas.
Durante la fase de diseño son frecuentemente usados los prototipos
operacionales [tratidos en. el capítulo 8). El capitule 22 proporciona una
explicación gráfica del análisis y diseño orientado a objetos, que tona
como punto de partida al análisis y diseño estructurado presentado en ios
veintiún capítulos anteriores.

LA NECESIDAD DEL ANÁLISIS Y DISEÑO ESTRUCTURADO

El anáiisis y diseño estructurado proporciona un enfoque sistemático paca
el diseño y construcción de sistemas de cómputo de calidad. A lo largo de
las fases de análisis y diseña, el analista debe preceder paso H paso obte-
niendo retroilimentación de los usuarios y analizando el diseno, bascando
omisiones y ercoi-ef. El pasar demasiado ripido a la siguiente fase puecte re-
querir que el analista lenga que regresar para volver a trabajar en partes an-
teriores del diseño.
 ICC
FIGURA].Ti
50 Cosl3 ds la cumpoitura de
unertcsr)' la Tas;
10 detecta el errar.
Ccsm relativo
para cotniMpe/
el error 5

Fase iel sst»na en donde

es ds$cutrero un trror •

1.a figura 1.11 ilustra el cosió de coiregír un error detectado en cada una
de las fases. Observe que se requiere mucho ruás esfuerzo paia corregir ur,
error en cada fase siguiente Par ejemplo, supongamos que se omitieran va*
ríos elementos ciando el analista estaba examinando los detalles de los da-
tos usados en el sistema. S^ el atislista se dio cuenta que estos elementos se
olvidaron después de que habían sido escritos les programas tendrán que
ser modificadas las presentaciones de archivos repoites y panlaLas, así
como los archivos de dates de prueba, programas y documentacitSa. Esas
correcciones pueden llevarse 100 horas y, en cambo, la adición de cllcs a
los materiales de diseño y i íes programas para que fueran paite del riiserlo
original desdé el principie hubiera tomado solamente cuairu horas. Obser-
re las sugerencias a lo largo de los siguientes capítulos que indican cuándo
te debe realizar el análisis y la manera Je determinar si el diseño del siste^
ma es preciso y completo.
Los anaUstis tienen a <n disposición varias herramientas de soft-
ware de njicrocomputadora que puedan ser usadas para ayudarles en el
desurdió de sislcmas. Además de las herrr amientas CA.SE y de ingeniería
inversa, se puede usar lu siguiente sn diversas fa¡"t=s dp.l tríelo de vida de
análisis y diseño: software de administración, para optiirizar la u b i c a d ^ do pei-
sonas y tenui-sos de proyecto, Soft wire pata crea: ptotetipos rápiáeirieri.le.
pauta Lis y reportes qua revisen y modifiquen lis usuarios, henamieotas psra
el diseño de Eormas pare que ayuden en el diseño de formas o áz documentos
fuente y software de gráfiejs v de presentación que ayude en h creación de
ilustraciones y produzca una presentación profasiona! para los usuarios.

METODOLOGÍAS ALTE.RNAS
Aunque esle texto es el enfoque indi ampliamente usado en la práctica, ha-
rá veces en que el analista re&onozca que la organización puede benefi-
ciarse más con el usu de un enfoque alternativa. Tal vez un proyecto de
sistema que usa un enfoque estructurado ha fallado lecietiternente, o tal
vez [jas subcultuias de la organización, compuestas da varios grupos dr-
üsuarios diferentes, mantengan mejor el paso con M\ método alternativo.
No podemos valorai justamente a e-;tos métodos er» un espacie pequeño, ya
que cala une de ellos >e merece y ha inspirado sus propioí libios « [nvei-
tigación. Sin embargo, al mencionar aquf «tos enfoques esperamos ayuder CAPfTLLÜV
\SUhiIRULF
a que se esté consciente di que, bajo ciertas dreunstancus, una orgaBiza- DE t i . ANA i • i •
ción quiera considerar urw akernaíiva o suplemento al análisis y diseño yUS
estructurado v al ciclo de vida del desarrolla de sistemas. 21
modificación y mantenimiento de los sistemas de información, ti análisis
v diseño de sistemas proporciona eslo.
Se xequier; que IDS analistas de sistemas desempeñen muchos papeles
on el o í r » dé su trabajo. Algunos de estos papeles son; (1] consultores exter-
nos para negocios, (2) experto de soporte dentro de un negocio y (3) agente
de cambio en situaciones tamo internas cenno exlernas.
Los analistas poseen un amplio rango de habilidades La primara y
principal es que el analista soluciona problemas, le gusta el neto de analizar
un problema y encontrar una respuesta funcional. Las analistas de sistemas
requieren habilidades de ccmunicacirfn que les permitan relacionarse en
forma significativa con muchos tipos de gunto diariamente, asf como habili-
dades de compitacida. Para su óxito es necesario que se involmre el usua-
rio final.
Los analistas proceden sistemáticamente. El marco de referencia paia
su enfoque sistsmático es proporcionado por le que es llamado el ciclo de
vida dül dusa rrollo de sistemas (SDL-C). Ésre puede ser dividido en siete
fases secuenciaíes, aunque ?n realidad las fases están ¡nterrelacionaias y
frecuBntemente ss llevan : cabo simultáneamente. Las siete fases son.:
identificación <ie problemas, oportunidades y objetivos, determinación de
los requtrimientOí de información, ar.álisis de las necesidades del sís-eir.a.
diseño del sistema recomendado, desarrollo y documentación del soít-
. prueba y mantenimiento del sistema e implementscidn del mismo.
Los paquetes de software basados en raicracomputadora autornítiza-
para al análisis y diseña de sistemas son llamados herramientas CA?E.
cuatro razones para la adepción de herramientas CASE son el incre-
to de la productividad del analista, la mejora de la comunicación entre
y usuarios, la integración de actividades del ciclo de vid* y el
rilísis y valoración del impacto de los cambies por mantenimiento.
Los analistas también usan enfoques CARE [re ingenien/a asistida por
iputadoia) para hacer ingeniería inversa y «ingeniería de software para
extender la vida del íoftivaie legado,
Un enfoque nuevo y ciferente al análisis y diseñe de sistemas es el
análisis y diseño de sistemas orientados a objetos (O-O), Estas técnicas es-
tán basadas en conceptea de programación orientada a objetos en Jos cua-
les los objetos, que son creados incluyen no solamente cfdigo acerca de
los datos sino también instrucciones acerca de las operaciones que SE pue-
den realizar cen ellos.
Cuando la situación organiíacional lo demanda, el analista puede
apartarse del SDLC para inlenlaruna metodología alterna, lal como la ela-
boiacio'if de prototipos. ETHICS. el enfoque de campeón de proyecto, la
dl Soft Systems c Miltiview.

PALABRAS Y CONCEPTOS IMPORTANTES

i n f orno a c i di» genera da p oí sistemas de apoyo a decisiones
computadora tDSS]
sistemas de proccssrnienio de inteligencia artificial {Al)
:ransaccione5 (TPS' sistemas expertos
sisEemasde infornwcibti generado por computadora
gersncial (MIS) sistemas de apoyo a
sistemas de automatización de ejecutivos {HSS) CAPfniO 1:
oficina [OAS) sistemas de apoyo a d DE Et. .^^^'^Lll^T.^
sistemas de manejo d» de grupo (GDSS] Ut SISTEMAS
conocimiento IVA'S) groupware 23
 Entre las alternativas más populares se encuentran: elaborad jn de
prototipos [distinta ala que tratamos en el capítulo 8), ETHICS, ei enfoque
de campeón de proyecto, la metodolagta de Soft Systems y Miiltiview. Ls
elaboración de prototipos, establecida en otras disciplinas y aplicada a
la IS, fue proporcionada como una respuesta a los tiempos de desarrollo
largos, asociados con ei enfoque del cido de vida de] desarrollo de sís:e-
mas y a la incertidumbre que frecuentemente rodea los requerimientos de
las usuarios. ETHICS fue introducido como una metodología íociote'cni-
ca que combina soluciones sociales y técnicas. El enfoque de campean
de proyecto-concepto tomado de '.a nercadotecnia. adopta la estrategia de
involucrar a una persona clave de cada área afectada por el sistema, para
asegurar el éxito del sistema. U metodología Soft Systems fue vista como
una forma para moáalar un jnundo que a veces es caótico mediante si uso
de diagramas "visión rica", que consiste en ideogramas que capturan ca-
racterísticas narrativas de la organización. Multiview fue propuesto como
una forma para organizar y usar elementos de varias metodologías compe-
titivas.

RESUMEN
La información puede se: vista como un recurso de la organización. Como tal,
debe ser müiejada cuidadosamente, el igual qua con los demás recursos. La
disponibilidad de poder d; computo al alcance de las organizaciones ha
dado como resultado tina explosión, de infoimacidri y, por consecuencia, se
debe dar más atención ai manejo de !a informecidn generada.
Todos los sistemas de información computar-izados tienen en sa base
una base de datos q¿e guarda los datos necesarios para dar soporte a las
fundones del negocio. Un sistema de proceso da transacciones (TPS) da
soporte a lis transacciones rutinarias y de gran volumen de los negocios,
tales como la ndmir.a y el inventario. Los sistemas de automatización de
oficina (OAS) dan soporte a los que trabajan con datos y que usan procesa-
miento de palabras, hojas de cálculo, etc., para analizar, transformar o ma-
nejar datos. Las sistemas de ti^abajo de conocimiento (KWS) dan soporte a
profesionales tales como científicos e ingenieros que crean nuevo conoci-
miento. Los sistemas de información gerencia! [MIS] son siitemaj de infor-
mación computarizadas que d<in soporte a un rango más amplio de
funciones de! negocio que el que dan los sistemas de procesamientos de tran-
sacciones. Muy frecuentemente el MIS produce reportes para los
tomadores de decisión. Los sistemas de apoyo a decisiones fDSS) son siste-
mas de mfomacirin cuya lívida está hecha a ia medida ds sus usuarios y
que ayudan a dar seporte a lo; tomadores de decisión en !a loma de deci-
siones semiestructuracia. Los 5i.¡temas expertos capturan la experiencia de
los tomadores de decisiones pan ser usada en la resolución de un proble-
ma o de una clase de problemas Los sistemas de apoyo a decisiones de
grupo (GDSS) juntan a los miembros de un grupo en lugares electrónicos es-
pedales para ayudara qsie el g r u p mueivs problemas semiesrructuiados o
sin estructura. Los sistemas de fcfoyo a ejecutivos (ESS) ayudan a que los
ejecutivos organicen su interactíit con el ambiente externo proporcionan-
do gráficos y soporte de comunicarones en ubicaciones accesibles.
El análisis y diseño de sísteni;s ss un enfoque sistemático para la
PARTE 1:
FUNDAMENTOS idenriBcacidn de problemas, oportuniv.des y objetivos analizando los flujo?
DEL ANÁLISIS de información en 1*5 erganizaciemes y -liseñando sistemas de información
DE SISTEMAS contputerizados para resolver un prablL'.-ia. Conforme prolifeía la informa-
22 ción, es ejenciaJ un enfoque planeado y istomático para la introducción.
 análisis y diseño de inversa
sistemas de software
amiis:a ce sistemas «ingeniería
consultor de sistemas CARE (reingeniería asistida por
agente de cambio computadora)
ciclo de vida del desarrollo software legado
de sistemas (SDLC) análisis y diseño de sistemas
herramientas CASE orier.tados a objetos
paquete de especificaciones ETHICS
de programa Multivíew
depósito CASE Elaboración de prototipos
mantenimiento metodología Soft System
generación de cídigo campeón de proyecto
amigrecidn de sistemas

PREGUNTAS DE REPASO
1. Describa porque es laés tíiil pensar sobre k información como un recur-
so de la organizacidn en vez de un subproducto de la organización.
2. Defina lo que significa un sistema de procesamiento de traasacciones.
3. Explique la diferencie entre los sistemas de automatización de ofici-
na (OAS) y los sistemas de manejo de conocimiento (KWS).
4. Compare la definición de sistema de información gerencial {MIS) con
la definición de sistema de apoyo a dacisiones (DSS).
5. Defina, el término sistemas experros. ¿En que difieren los sistemas
expertos de los sistemas de apoyo a decisiones?
6. Liste los problemas de interaccitín de grupo para los que fueron dise-
ñados los sistemas de apoyo a decisiones de grupo (GDSS)
7. Liste las ventajas del uso de las técnicas de análisis y diseño de siste-
ma en el enfoque de los sistemas da información computarizada p«a
negocios.
8. Liste ttes papeles que debe representar el analista ¿e sistemas. Di
un* definición de cada uno de ellos.
9. ¿Qué cualidades personales so:i útiles para el analis:a de sistemas?
Lístelas
10. Liste y defina libremente las siete fases de ciclo de vida del desarrollo
de sistemas (SDLC].
11. Defina la ingeniería inversa de software y la reingenien'a tal como se
aplica a la CARE (rsinganiería asistida por computadora.)
12. Liste las cuatro razones para la adopción de herramientas CASS.
13. Defina ei término análisis y diseñe de $jítemss orientados a objetos.

BIBLIOGRAFÍA SELECCIONADA
Alavi, M. "An Assessment of the Prototyping Approach to Information
Systems". Communications of the ACM. Vol. 26, No. 6 Junio de 1984,
pp. 555-553.
Avison, D. E. y A. T. Wood-Harper, Multivíew: An Expiotetion JH
Information Systems Developtnent. Oxford: Blackwelt ScíeEitífic
Publications. 1S90.
PARTE 1:
FUNDAMENTOS Beath, C. M. "Suppcrting '.he Information Technology Champion". MIS
DEL ANÁLISIS Quarterly. Val. 15, No 3, septiembre de 1991, pp. 255-372.
DE SISTEMAS Che-ckland. P. B. "Soft Systems Methodoíogy". Human Systems
24 f. Vol. 8r No, 4, 1989, pp. 271-289.
Chacicland, P B Sys'eiss Thilikir.g Systsm Practico. Chichestcr, U. K.J John
Wiley. 1991.
Coad. P. y E Yourdon. Object-Oriented Analysis, segunda edición
En^lewood Clif:s. N¡: Yourdon, 1991
Da vis. G. B. y M. H. Gho¡i Mangemenl informa tion Systems: Conceptual
Foundarjon. S'.rnctuie, ana DeVBlopmsnt, segunda adición. Nueva
York. McGraw-Hill Boak Company, 1935
Holsappíe, C. W. y A B. Whinston. Business Experí Svstems. Homewond.
IL:Ir\dn. 1937.
Jackson, M A, SystemsDevelopment. Englewood Cliffs. NJ: Prentice Hall,
16B3.
Ksncall K. E. "Behavioral Implications íor Systems Analysís and Destgn:
Piospects for the Ninsties". /o.irn^i of Mar.gement Systems, Vol 3,
No. 1.1991, pp 1^4.
Laudon, K. C. y J P. Laiidon . Managenier:! Information Systems, tercera
edición, Nueva York: McCraw-Hill BooV Company, 1994,
Muioford, E. y M. Weir. Computer Systems ¡n Work Design-the ETHICS
Methcd. Associated Business Press, London. 1979.
Naumasn, J. D.. y A. U, Jenfcins. "Ptototyping. Tlia New Paradigm Eor
Systecis Development". MiS Qusrtedy. Vol. 6. No. 3, septiembre
de 1982, pp. 29-44.
Whitten. J. t., L. D, Bently y V. M. Barlon', Systems Analysis & Design
Methods, terceri edición Hornewood IL: Iiwin, 1Q94.
. E. Aíodem Slructured Analyiis, Englewood Clífts, Nj: Prentice
Hall, 1989.

CAPÍTULO l:
ASUMIR f.L ['APEI.
DE EX ANALISTA
DE SISTEMAS
25