Analisis de sistemas Capitulo Cuotro 103

sistemas
5 simple
'icios df-
itro del -,

Sandra,
'el pro-
trabajo
■ Coino

E�pedficacion�S
de diseno ft'siCD

(iflGURA 4.1 El coritexto del analisis de sistemas'

J
Or
O
e-

(�nfoques de analisis de sistemas

De manera fundamental, el analisis de sistemas trata acerca de la solucion de problemas.
Hay muchos metodos para ello; por lo tanto, no le debe sorprender que haya muchos
enfoques para el analisis de sistemas. Estos enfoques con frecuencia son vistos como
alternativas en competencia. En realidad, ciertas combLnaciones pueden y deben comple- analisis basado en mode¬
mentarse entre ellas. Esto se presento en el capitulo 3 como metodos acelerados. Analice- los Una estrategia de solu¬
mos de manera breve los diversos enfoques. cion de problemas que hace
NOTA: La intencion aqui es solo desarroliar una comprension de alto nivel. En los entasis en trazar modelos de
capitulos posteriores a esta unidad, se ensenaran las tecnicas subyacentes. sistemas de imagenes para
documentar y validar los siste¬
mas existentes o propuestos.
> Enfoques de analisis basados en modelos En ultima instanoia, gI modelo
de sistema se convierte en el
El analisis e st m ct u r ad o, la in gen ieria d e in f orm aci on y el an&lisis orient ad o a obj et os s o n
piano para disenar y construir
ejemplos de un andlisis basado en modelos. Este analisis utiliza imagenes para comu- un sistema mejorado.
104 Parte Dos
m o delo Representacion de
ia realidad. Puesto que "una
imagen vale mas que mis pa-
labras". en muchos modelos
se usan imagenes para repre-
senlar la realidad.
analisis estructurado Tec-
nica centrada en proce so s y
operada por modelos que se
usa para analizar un sistema
existente, para definir los
requerimientos de negocios
de un nuevo sistema o para
ambos objetivos. Los modelos
son imagenes que ilustran los
componentes dei sistema:
procesos, entradas, salldas y
archlvos.
FiGURA 4.2
Modelo do proceso
- Cuentas
simple (tambien
Majnado diagrania
de flujo de dates)
Metodos de analUis de sistemas
nicar problemas de negocios, requerimientos y soluciones. Ejemplos de model os con l<xs '
que p uede ya estar-familiarizado incluyen diagramas de flujo, cuadros de estructura o
jerarquias y organigramas. '
En la actualidad, los enfoques basados en modelos casi siempre se resaltan por el uso
de herramientas automatizadas. Algunos analistas dibujan modelos de sistemas con soft¬
ware grafico de propositos generales como Visio de Microsoft. Otros analistas y organiza-
ciones requieren el uso de herramientas basadas en repositorios CASE o de elaboracion ■
de modelos como System Architect, Visible Architect, Visible Analyst o Rational ROSE. Las i
herramientas CASE ofrecen la ventaja del analisis consistente y completo asi como una
revision de errores basada en reglas.
Los enfoques de analisis basados en modelos se presentan en las metodologias y rutas
basadas en modelos que se presentaron en el capitulo 3. Analicemos de manera breve los
tres enfoques mas populares de analisis basados en modelos.
Metodos tradicionales A1 inicio de la decada de los setenta se desarrollaron diverso.s
metodos tradicionales para el analisis y el diseiio de sistemas. Uno de los primeros me¬
todos formales, que a un es ampliamente utilizado en la actualidad es el analisis estruc¬
turado. El analisis estructurado se enfoca en el flujo de datos a traves de los procesos
de negocios y de software. Se dice que esta centrada en el proceso. "Por centrado en el
proceso queremos decir que el enfasis esta en los componentes (bloques de construccion)
del PROCESO en su marco de referenda del sistema de informacion.
Una de las herramientas clave utilizadas para elaborar modelos de procesos es el
diagrama de f lujo de datos (figura 4,2) que describe los procesos existentes o propuestos
en un sistema junto con sus entradas, salidas y datos. Los modelos muestran el flujo de-
datos entre y a traves de los procesos y los lugares donde se almacenan los datos. Por
ultimo, estos modelos de procesos sirven como pianos para que los procesos de negocios
searx implementados y que el software se adquiera o se constmya.
La practica de analisis estructurado para el diseno de software ha disminuido mucho
en favor de los metodos orientados a objetos. Sin embargo, la elaboracion de modelos
1
Respuesta a pedido
de miembros
s
Evaluacion y li'mite
Evaluacion de credito
Evaluacion
y
Ifmrte
de credito
y limite
de credito
1
jProcesar
pedidos
' d e b o no s
Prooesar
los pedidos Pedido
: autoiti�ticos L que
se
atendera
Pedido que i mmii mi Pedido que
s e atendera se atendera
Detalles de pedidos Pedido automatico
Pedidos revlsado
existentes
 An6lbi$ de sistemas Capitulo Cuatro 105

colocado asignado bajo; -K acucrdo >

FIGURA 4.3
por; lugares aplica a
Modelo de d a f o s
s i m p l i i s (tambi�n
Llamado d i a gt iu ii a
establecido por; enddad-relAd6n)
� vende; genera;
i:Ve'Vcnde en generado por establece

' iPrtjducto se presenta en; patrocina; Club

0<J' iFPromocion
prcsenta "es patroclnado por
5 V

'de proceso disfruta un cierto reavivaimiento gracias el enfasis renovado en el rediseno de

■procesos de negodos, que se arializara posteriormente en este capitulo.
Otro metodo tradicional, llamado ingemeria d e i n f o r m a c io n (IE), se enfoca en ta ingenieria de informa¬
estrLiciLira de datos almacenados en un sistema mas que en los procesos. Por ello, se dijo cion (lE)Unatecnicaope-
de con o c i- rada por modelos y centrada
"que-era centmdo en los datos, al enfatizar el analisis de los requerimientos Gn DATOS, pero sensible a
WENTO Co datos). La herramienta furidaraental para modelar requerimientos de datos es el
■ diagrama de relacion de entidad (figura 4,3). Los diagramas de relaci6n de entidades aun PROCESOS, para ia planeaciori,
el a na l is is y el disGflo de siste¬
.son inuy utilizados en el diseno de bases de datos de relaciones. mas de informacion. Los mo¬
. En un principio, la ingenieria de informacion era vista como un metodo en compe- delos de IE son imagenes que
tencia con el analisis estructurado. Con el paso del tiempo muchas personas los hicieron ilustran y sincronizan los datos
s conlplementarios; utilizan diagramas de flujo de datos para modelar los procesos de siste- y procesos del sistema.
mas > los diagramas de relaciones de entidades para modelar un sistema de datos.

Estrategia orienhida a objetos Los metodos tradicionales separaban las preocupacio-

nes en forma deliberada del con ocim i en t o (dates) de los de procesos. Aunque la mayoria
de los metodos de anllisis de sistemas intentaron sincronizar modelos de datos y proce¬
sos. ese intento no siempre funcionaba bien en la practica. Las tecnologias de objeto han objeto Encapsulacibn de
surgido desde entonces para eliminar esta separacion artificial de datos y procesos. La datos (Hamados.propfedao'es)
estrategia orienta da a o bjeto s ve los sistemas de informacion no como datos y procesos, que describen a una persona,
sino como una coleccion de objetos que encapsulan datos y procesos. Los objetos pueden objeto, sitio o Gvento, con
lodos los procesos (llamados'
: contener atributos de datos. Sin embargo, la unica forma de crear, leer, actualizar o elimi¬
metodos] permitidos para
nar los datos de un objeto es a traves de uno de sus procesos incrustados (llamado meto¬
usar o actualizar los datos y
dos); Los lenguajes de programacion orientados a objetos como Java, C++ y los lenguajes propiedades. La unica forma
NET se vuelven cada vez mas populates, de fener acceso a los datos del
•' La estrategia orientada a objetos tiene un conjunto completo de herramientas de objeto o actualizarlos es usar
elaboracion de modelos conocido como Unified Modeling Language (UML). Uno de los los procesos predefinidos del
"
dicigramas UML de clase de objetos, se muestra en la figura 4.4, Algunas de las herramien- objeio.
■,,tas LML han ganado aceptacion por los proyectos de sistemas incluso cuando el sistema
i. de inlormacion no sea
implementado con tecnologias orientadas a objetos. estrategia orientada a
.> Enfoques de analisis de sistemas acelerados objetos Tecnioa basada en
modelos que Integra los datos
,' El desarrollo de la elaboracion de protofipos de identificacion y de arquitectura rapida son y procesos en conceptos lla¬
ejeinplos de enfoques de sistemas acelerados que enfatizan la construccion de prototipos mados objetos. Los modelos
para identificar con mas rapidez los requerimientos de negocios y de usuarios para un de objetos son imagenes que
sistema nuevo. La mayoria de dichos metodos se derivan de alguna variacion en la cons¬ ilustran los objetos del sistema
truccion de prototipos, muestras funcionales pero incompletas de un sistema deseado. desde diversas perspectivas,
• Los como la estructura, el compor-
prototipos sirven a la forma de pensar de "sabre lo que quiero cuando lo vea", que tamiento y las interacciones
�es caracteristico de muchos usuarios y administradores. Por "incompleto" queremos decir entre eilos.
que un prototipo no incluira la revision de errores, validacion de entrada de datos, segu-
ridad y totalidad de proceso de una aplicacion terminada, Ni tampoco estara tan pulida
ni ofrecera ayuda al usuario como en el sistema final. Pero como puede ser desarrollado prototipo Muestra a pe-
con rapidez, de igual forma puede identificar los requerimientos mas cruciales de nivel quena escala, un ejempio
de negocios. A veces, los prototipos pueden evolucionar para convertirse en los sistemas incompleto pero funcional de
finales, es decir, las aplicaciones completas. un sistema deseado.
106 Parte Dos
FIGURA .4.4
f�lpdelo de qljjeto
(con el estandar
' tiene re�istro de>
del'ljcngLraje
oJa�Qmcion d6
iUG'de] ().s xmificado)
elaboracion de pro¬
totipos de identifica-
cion T6cnica usada para
identificar los requGrimientos
de negocios de.los usuarios
al hacerlos reacclonar a una
implantacion r�pida y no aca-
bada de esos requerimientos.
Metodos de analisis de sistemas
ESTODIANTE i . ~
I -
CURSO .
-Numero dejtJsntifloaoion I"
-Nombre -Tema�'
-Proimedto de estudios D..* -Nutttsrb ' ;
-Tilulo
+A<JmiSr (/ -Credito '
�:-i-Regtstrarsepamc/ases:(): -:' y -r
+flfeftfaree 0 •+CfS3f'on cursa ()
■hCambiar ta direccian () *Eliri}lnar cu/bo msBStro Q
�■Calcularpromedio do estudios (} .•A�Cambtat'Onel-Cuiso Maestro #-
■�Grsduado Q y-j: � �
C eURSO DE TRANSCfflPClbN
-Semcstrc ., r i
�Divisiori-
-Grado
■ ' '
�+Suinar{) - • X'.;:-
+Flenunciar () - i
+Completar () i '
+Cfinnbi8f de grade () .'.'r:
En un sentido, los metodos de analisis acelemdo ponen mucho enfasis en los coraponen-
tes de COMUNICACIONES en su marco de referenda de sistema de infonnacion al construir for-
mas e informes de muestxas. Al mismo tiempo, las herramientas de software utilizadas para
construir prototipos tambien incluyen los componentes de d at os y procesos.
Estos metodos acelerados son comunes en las metodologias de desarroUo rapido de
. aplicaciones (rapid application development, RAD) y las rutas que fueron presentadas en
el capitulo 3. Los metodos RAD requieren herramientas autoraatizadas mientras que algu-
nas herramientas CASE basadas en repositories incluyen instalaciones RAD muy sinaples,
la mayoria de los analistas utilizan verdaderos ambientes de programacion RAD, como
Powerbuilder de Sybase, Access de Microsoft, Visual Basic .NET de Microsoft o Websphere
Studio for Application Development de IBM (basado en Java).
Analicemos de manera breve dos metodos populates de analisis acelerado.
Elaboracion de prototipos de identificacion La ela bo ra cio n de p ro t o t i po s de identi-
ficacion utiliza tecnologia de desarroUo rapido para ayudar a los usuarios a identificar sus
requerimientos de negocios. Per ejemplo, es muy comun que los analistas de sistemas uti-
iicen una herramienta de desarroUo simple como Access de Microsoft para crear en forma
rapida una base de datos simple, formatos de entrada de usuario e informes de muestra
para solicitar respuestas de usuarios en cuanto a si la base de datos, formatos e informes re-
presentan en realidad los requerimientos de negocios. La intencion es desarrollar de manera
normal el nuevo sistema final en una herramienta y un lenguaje de desarroUo de apUcacion
mas sofisticado, pero la herramienta mas simple permite al analista desarrollar los protod-
pos de acuerdo con los requerimientos de los usuarios con una mayor rapidez.
En la elaboracion de prototipos para identificacion, tratamos de desalentar a los usua¬
rios de preocuparse por la "vision y sensacion" final de los prototipos de sistemas, [que
p ueden cambiarse durante el diseno del sistema! Aqui reside la critica primaria de la
elaboracion de prototipos; las plantillas de software existen en las herramientas de ela¬
boracion de prototipos para generar en forma rapida algunos prototipos muy elegantes y
visualmente atractivos. La desventaja es que esto puede alentar un enfoque y compromlso
prematuro con el diseno representado en el prototipo. Los usuarios tambien p ueden ser
llevados a creer en forma equivocada: 1) que el sistema completo puede construirse con
la misma rapidez, o 2) que herramientas como Access p ueden utilizarse para construir el
sistema final. Aunque herramientas como Access p ueden en realidad acelerar el desarro¬
Uo de sistemas, su use en la elaboracion de prototipos es rapido solo p or q ue se omite la
 Anaiisis de sistemas CapUulo Cuatro 107

del detalle de la base de datos y la programacion de aplicaciones requerida

jTjayor pitrte
ra una apHcacion completa y segura. Tambien, por lo general, herramientas como Ac-
los tamanos, numero de usuarios y trafico de red de las bases de
li'SS i'f pueden soportar
se requieren en la mayoria de las aplicaciones empresariales.
Viaios que
obstante, la elaboracion de prototipos de identificacion es un rcietodo preferido y
analistas y desarrolladores de sistenms uti-
tecomendado. Desafortunadamente, algunos
It/an c'laboracion de prototipos de identificacion para reemplazar en forma total el
diseno basado en modelos, solo para darse cuenta lo que los verdaderos ingenieros han
durante aiios; No se puede elaborar un prototipo sin cierta cantidad de un diseno
tnasformal... y es aqui donde entra el anaiisis rapido con arqnitectura.

Anaiisis ra p i d o de a rq u it ect ura El anaiisis rapido de arquitectura es u n metodo de anaiisis rapido de ar¬
„-QgljsjS-'acelerado que tambien construye modelos de sistemas. El anaiisis rapido de arqui¬ quitectura Estrategia que
intenta derivar modelos de
tectura se hace posible mediante la tecnologia de ingenieria inversa que se incluye en
sistemas (como se describe
mucbas herramientas automatizadas como CASE y lenguajes de programacion (como se
el capitulo 3). Las herramientas de ingenieria inversa generan modelos de con antelacion en la misma
presentaron en seccion del capitulo) a partir
sistemas de las aplicaciones de software existentes o los prototipos de sistemas. Los mode¬ de sistemas existentes o pro¬
los de sistemas resultantes pueden entonces ser editados y mejorados por los analistas de totipos de identificacion.
sislemas y los usuarios para proporcionar un plan para un sistema nuevo y mejorado. Debe
icr evidente que el anaiisis rapido con arquitectura es una mezcla de los enfoques basados
ell modelos y de anaUsis acelerado. ingenieria inversa Uso de
Hay dos tecnicas diferentes para aplicar un anaiisis de arquitectura rapido: tecnologia que lee el codigo
f La mayorfa de los sistemas ya han sido automatizados hasta cierto grado y existen de programas a partir de
i - como sistiema de informacifin de heredado. Muchas herramientas CASE pueden leer bases de datos, programas
de aplicacion o interfaces de
j' las estructuras de base de datos subyacentes y/ o los programas de aplicacion, y usuarios existentes y genera
luego, con ingenieria inversa, regresarlos en diferentes modelos de sistemas, Esos automatioamente el modelo
modelos sirven como punto de partlda para definir un anaiisis de requerimientos de de sistemas equivalente.
uiuario basado en modelos.
♦ S i los prototipos han sido construidos en herramientas como Access o Visual Basic
de Microsoft, esos prototipos a veces pueden ser revertidos con la ingenieria inversa
1 d su equivalente en modelos de sistemas. Estos ultimos por lo general se prestan
i para analizar los requerimientos de los usuarios en cuanto a su consistencia, totali-
' tlad. estabilidad, escalabilidad y flexibilidad al cambio fijturo. Tambien, los modelos
1 de sistemas con frecuencia pueden ser cambiados por la ingenieria hacia adelante
ADE (ambientes de desarrollo de
J por medio de las mismas herramientas CASE y los
aplicacion) en las bases de datos y plantiUas de aplicacion o los esqueletos que utili-
zaran las robustas bases de datos de nivel empresarial y tecnologia de programacion.
'V Ambas tecnicas abordan el tema anterior de que los ingenieros rara vez elaboran
pri:ilotipos en la ausencia total de un diseiio mas formal y al mismo tiempo, preservan las
■ veiilaias de acelerar las fases de anaiisis de sistemas.

>, Metodos para identificacion de requerimientos

. . tosmeiodos de anlUsis de sistemas acelerados y el basado en modelos Lntentan expresar los
r-.iiiequenmientos de usuarios para un nuevo sistema, ya sea como modelos o como prototipos.
■ Rero ambos metodos son, a su vez, dependientes de la necesidad mas sutil de identificar y
' adiTiinistrar en realidad esos identificacion de reque¬
requerimientos. Mas aun, los requerimientos para los sistemas
dfepefideri de la capacidad de los analistas para identificar los problemas y oportunidades rimientos Proceso que usan
que existen en el sistema actual, por tanto, los analistas deben volverse habiles para identifi¬ los analistas de sistemas para
car problemas, oportunidades y requerimientos. En consecuencia, todas las estrategias para identificar o extraer proble-
anaiisis de sistemas requieren alguna forma de identificacion de requerimientos. Revise- rtias de sistemas y reque¬
inos dc manera breve un par de estrategias para identificacion de requerimientos. rimientos de solucion de la
comunidad de usuarios.
Tecnicas de identificacion de hechos La identificacion de hcchos es una habiiidad
: esencial para todos los analistas de sistemas. Las tecnicas de identificacion de hechos que
identificacion de hechos
i vSe abarcan en este texto (de hecho, en el siguiente capitulo) incluyen:
-."VrV; i. .
Proceso de recopilar informa-
ci6n acerca de problemas,
PI inuestreo de la documentacion existente, informes, formates, archivos, bases de
oportunidades, requerimientos
' ' datos memorandos.
, y de solucion y prioridades del
Investigacion de bibliografia relevante, sondeo en el mercado de otras soluciones y sistema. Tambien denominado
visitas a sitios. recopilaclon de informacidn.
108 Parte Dos
p]aiieaci6n conjunta de
requerimientos (JRP)
Uso de talleres facilitados
para reunir a todos los pro-
pietarios, usuarios y anaiistas
de un sistema y a ciertos di-
sefiadores y constructores de
sistemas con el fin de realizar
conjuntament9 el analisis de
sistemas. La JRP por lo gene¬
ral se considera como parte
de un m�todo mas ampllo,
llamado desarrollo conjunto
de aplicaciones (J/\0),''que es
una aplicacion m6s completa
d0 las tecnicas de JRP a!
proceso de desarrollo de sis¬
temas en su totalidad.
rediseno de procesos de
negocios (BPH) Aplicacion
de metodos de analisis de
sisternas con ef objetivo de
cambiar y mejorar significa-
tivamente los procesos de
negocios fundamentales de
una organizacion, con inde-
pendencia de la tecnologia de
la inforimacion.
metodo acelerado Integra¬
cion de diversos enfoques del
analisis y disaiio de sistemas
para su aplicacidn segun se
considers apropiado al pro-
blema que se intenta resolver
y el sistema que se estS desa-
rroliando.
Metodos de analisis de sisfemas
• Observacion del sistema actual en acci6n y el ambiente de trabajo.
• Cuestionarios y encuestas de la administracion y la comunidad de usuarios.
• Entrevistas de administradores, usuarios y personal tecnico apropiado.
Planeacion conjunta de requerimientos Las tecnicas de identificadon de hechos lis
tadas con anterioridad son invaluables; sin embargo, pueden consumir mucho tiempo en
sus formas cla�icas. De manera alternativa, la identificacion de requerimientos y la admi-
nistracion pueden ser acelerados en forma significativa al usar una t�cnica de planeacion
conj unta de r eq uer i mi e nt os (joint req�uirements pla nni ng, JRP). Un analista capacitado I
o certificado en JRP en general desempena el papel de facilitador en un taller que nor- i
malmente toma de tres a cinco dias completos de trabajo. Este taller puede reeraplazar'
semanas o meses de las ciasicas juntas de identificacion de hechos y su seguimiento.
Una JRP propordona un ambiente de trabajo en el cual se aceleran todas las tareas y 'f;
los productos del analisis de sisternas, Promueve una participacion mejorada del propieta- :
MO DE SISTEMAS y del usuAEio DE SISTEMAS en cI andlisis del sistema. Pero tambien requiete
que un facilitador con excelentes habilidades de negociacion y conciliacion se asegure de 1
que todas las partes reciban las oportunidades apropiadas para contribuir al desarrollo
del sistema.
La JRP por lo general se utiliza en conjunto con los metodos de analisis basados en
sistemas que describimos con anterioridad y casi siempre se incorpora en las metodologias :
y rutas de desarrollo rapido de aplicacion (RAD), que se presentaron en el capJtulo 3.
> Metodos de rediseno de procesos de negocios
Una de las aplicaciones contemporaneas mas interesantes de los metodos de analisis de
sistemas es el rediseflo de p r oc es os de negocios (b usi nes s pr oc ess redesign, BPR). El '
interes en el BPR fue dirigido por el descubrimiento de que los sistemas de informacion
y aplicaciones mas actuales solo han automatizado los procesos de negocios existentes ;
e ineficientes. La burocracia automatizada sigue siendo burocracia; la automatizacion no
necesariamente aporta valor al negocio y en verdad puede sustraer valor al negocio. Pre-
sentado en el capitulo 1, el BRP es uno de muchos tipos de proyectos disparados por las
tendencias que llamamos de administracion de calidad total (total quality management,
TQM) y mejora continua de procesos (continuos process improvement, CPI).
Algunos proyectos de BPR se enfocan en todos los procesos de negocios, sin impof-
tar su automatizacion. Cada proceso de negocios se estudia y analiza con profundidad en
busca de cuellos de botella, valor de retomo y oportunidades de eliminacion o agUizacion,
Los modelos de procesos, tales como diagramas de flujo de datos (analizados con anterio¬
ridad) ayudan a las organizaciones a visualizar sus procesos. Una vez que los procesos de
negocios han sido redisenados, la mayoria de los BPR concluyen al examinar c6mo seria
major aplicada la tecnologia de la informacion a los procesos de negocios mejorados, Esto
puede crear nuevos proyectos de desarrollo de sistemas de informacion y aplicacion para
implementar o soportar los nuevos procesos de negocios.
BPR tambien se aplica dentro del contexto de los proyectos de desarrollo de infor¬
macion, Es muy comun que los proyectos de IS incluyan un estudio de los procesos de
negocios existentes para identificar problemas, burocracia e ineficiencias que puedan ser
abordados en requerimientos para nuevos y mejorados sistemas de informacion y aplica¬
ciones de computo.
BPR tambien se ha vuelto comun en los proyectos de IS que estaran basados en la
compra e integracion de software listo para usarse (commercial off-the-shelf, COTS). La
adquisicion de software COTS en general requiere que un negocio adapte sus procesos
de negocios para encajar en el software. Un analisis de procesos de negocios existentes
durante el analisis de sistemas casi siempre es parte de dichos proyectos.
> istrotegias de analisis de sistemas FAST
Al igual que la mayoria de las metodologias comerciales, nuestra metodologia hipotetica
ii45rno impone un solo metodo en los analistas de sistemas. En su lugar, Integra todos los
metodos populates presentados en los parrafos anteriores en una coleccion de metodos
acelerados. El caso de estudio de SoundStage demostrara estos metodos en el contexto
de una primera asignacion de un analista de sistemas. Las tecnicas de analisis de sistemas
seran aplicadas dentro del marco de referenda de:
 Analisis de sistemas Capftulo Cuatro 109

Los componentes de su sistema de informacion (del capftulo 2).

irios. , fast (del capftulo 3).
i Las tareas de FAST que implementan una fase (descritas en. este capftulo),
este contexto para estudiar analisis de sistemas, ahora podemos expiorar las
�o hechojj:
Y tareas del analisis de sistemas.
k af �
tos ytieiDjg,
e
faPlaneaf ----
capaci,|.---
• _
cle definicion de alcance
reempi.�
"'iento,
■i3-s tare iecuerde del capitulo 3 que la fase de definicion de alcance es la primera del proceso
iei pjiopj-ie desarrollo de sistemas clasico. En otras metodologias esto podrfa ser llamado fase de
en de estudio inicial, fase de investigacion o fase de planea-
requj�pvestigacion preliminar, fase
aseguj.g|ta«- La fs'se de definicion de alcance responde la pregunta, "�vale la pena realizar este
desarroiroy®*�'-®'"" responder esta pregunta, debemos definir el alcance del proyecto y los
■problemas percibidos. oportunidades y directrices que dispararon el proyecto. Suponga-
'asados linos que el problema se considera digno de investigarse, la fase de definicion de alcance
todoJopjilebe tambien establecer el plan de proyecto en terminos de escala, estrategia de desarro-
xiJo 3 'ilo, programacion, requerimientos de recursos y presupuesto.�
El contexto para la fase de definicion de alcance aparece en un rectangulo punteado
en la figura 4.5. Notese que la fase de definicion de alcance tiene como prioridad el punto
de vista del propietakio d e l sistema del ya existente y los problemas y oportunidades que
'aJjsis f dispararon interes. Los propietarios de sistemas tienden a estar preocupados por la ima-
BPJt) j gen general, no por los detalles. Mas aiin, ellos determinan si los recursos pueden y serin
rjnacift comprometidos con el proyecto,
■istente figura 4.6 se encuenlra el primero de cinco diagramas de tareas que presen-
cion ij taremos en este capltulo para dar un vistazo mas de cerca a. cada fase de analisis de
io. sistemas. Un diagrama de tareas muestra el trabajo ( - tareas) que debe ser realizado
por para completar una fase. Nuestros diagramas de tareas no indican una metodologfa
etneni especJfica, pero describiremos en los parrafos anexos los metodos, herramientas y tec-
nicas que usted podrfa considerar para cada tarea. En la figura 4.6 se muestran las ta-
impor- requeridas para la fase de definicion de alcance. Es importanie recordar que estos
iad ei diagramas de tareas son solo plantillas. El equipo de proyecto y el administrador del
acioij' proyecto pueden expandir o alterar estas plantillas para reflejar las necesidades linicas
terio. cualquier proyecto dado,
□s Como se muestra en la figura 4.6, el producto final de la fase de investigaci6n pre-
serfa-v liminar es el cumplimiento de una c a r t a de dehniciOn del p ro y e ct o . (Esos importantes
Esto productos estan indicados en cada diagrama de tareas en letras raayiisculas.) Una carta de
para definicion de proyecto define el alcance de proyecto, el plan, la metodologfa, los estanda-
res y demas. El completar la carta de definicion de proyecto representa el primer hito en
■
un proyecto.
: (Je Se pretende que la fase de definicifin de alcance sea rapida. La fase completa no debe
sgj. exceder dos o tres dias para la mayoria de los proyectos, En general, la fase incluye las
ca. ; siguientes tareas: r

ja 1.1 Identificar problemas y oportunidades Msicos.

La : 1.2 Negociar alcance base,
Ds 1-3 Considerar el valor del proyecto base,
;s 1.4 Desarrollar un programa y presupuesto iniciales.
1.5 Comunicar el plan de proyecto.

Ahora analicemos cada una de estas tareas con mayor detalle.

� Estos
elementos de planeaci6n forraan parte del proceso utilizado por los administradores de proyecto para
desarrollar un plan de proyecto."
* Nota
del E.T.: Para el lector interesado, se recomienda consultar un llbro sobre administracs6ri de proyectos,
como el PMBOK del PMI.
110 Parte Dos Metodos de analisis de sistemas

(fIGURA 4 . 5 El contexto de la fase de definicion de alcance del analisis de sistemas

 Analisis de sistemas Capitulo Cuatro 111

U COMUNIDAD DE KEGOCIOS
FIGURA 4.6
Tareas para la fase
de definidolt de
alcance del aiiffiste
de sistemas

!
PROPIETARIOSY USUARIOS PE aiSTEMAS
(0 COMITE D6 DIRECCION)

DIAGRAMA
DE PBOY EC TO

Deiinidon del
problema preltminar
"� con alcance
� Reposljbrlo

Definlcl6Rde "
programs [ D�fmlcion
y asignacion � ds probiemas
derecursos \ con alcance
dei proyecto >
detrabajo ]

Plan de proyecto -J
—El proyecto es valioso—-
y pragFama base

> Tarea 1.1: Identificar problemas y oportunidades bdsicas

Una de las tareas mas importantes de la fase de definicion de alcance es establecer una alcance Lfmites de un pro¬
base inicial de los problemas, oportunidades o directrices que dispararon el proyecto. Cada yecto: las areas de un negocio
problema, oportunidad y directriz esta evaluado con relacion a la urgenda, visibilidad, be- que e( proyecto podn'a aten-
neficios tangibles y prioridad. Cualquier analisis adicional y detallado no es relevante en der (o no).
esta etapa del proyecto. Sin embargo, puede ser utH listar cualquier restriccion (limitaci6n)
del proyecto, como fechas liraites, presupuestos maximos o arquitectura tecnologica.
Por lo general un analista de sistemas con mucha experiencia o un administrador de
proyeao dirige esta tarea. La mayoria de los otros participantes se clasifican en general como
PRCPiETAMos DEL SISTEMA. Esto incluye a los patrocinadores ejecutivos, a los administradores
de mas alto nivel que pagaran y apoyaran el proyecto. Tambien incluye administradores de
todas las unidades organizacionales que pueden ser impactados por el sistema y es posi-
ble que incluya a los administradores de sistemas de informacion. Los u s u a h o s de sistemas,
disenadores de sistemas y c o n s t r u c t o re s de sistemas por lo general no participan en esta
tarea.
Como se muestra en la figura 4.6, una soucmiD del PROYECTO O ASTGNACIOn dispara
la tarea. Este disparador puede tomar una o varias formas alternativas. Puede ser tan
simple como un memorando de autoridad de un comite de direccion de sistemas de
informacion. O puede ser un memorando de un equipo o una unidad de negocios que
solicita un desarrollo de sistemas. Algunas organizaciones requieren que todas las soli¬
citudes de proyectos sean remitidas en formato de solicitud de servicio, coino el de la
figura 4.7.
 Porte Dos Metodos de analisis de sistemas

SoundStage Entertainment Club

IGURA 4.7 Information Syst&m Services
Phone: 494-0B6G Fax; 404-0999
UEQIJKST FOU
Internet: ht t p :/ / www. s ou nds ta ge. com INFOUIVIMION
olieitud de Intranet: http:yi'www.soundstag€.coni/iss SVS'IKM SEKVIOIilS Proyecto:
ervicios de sistemas
DATE OF REQUEST SERVICE REQUESTED FOR DEPARTMENT(S)
January 9,2003 M emb er Ser vices, Wa r eh ou s e, Shipping

SUBMITTED BY (key user contact) EXECUTIVE SPONSOR (funding authority)

N am e Sar a h Har tman Name Galen K'srkhoff
Title Business Analyst, M emb er S er vices Title Vice Pr esident, M emb er Ser vices
Office B035 Office G242
P hon e 494-0867 Phone 494-1242

TYPE OF SERVICE REQUESTED:

□ Infor mation Str ategy Planning □ Existing Application E n ha nc em ent
IS Business Pr ocess Analysis a nd R edes ign □ Existing Application M a int ena nce (pr ob lem fix)
N ew Application D ev elop ment □ Not S ur e
□ Other (please specify)__

BRIEF STATEMENT OF PROBLEM, OPPORTUNITY, OR DIRECTIVE (attach additional documentation as necessary)

T he infor mation strategy planning gr oup ha s target ed m e mb er services, marketing, and or der fjifillment (inclusive
of shipping} for business pr ocess r edesign and Integrated application develop ment. Currently serviced by s epar ate
information s ystems, t hes e ar eas ar e not well integr ated to maximize efficient or der ser vices to our me mb er s .T h e
curr ent s yst ems ar e not adaptable to our rapidly changing pr oducts and services. In some cases, s epar ate s yst ems
exist for simNar pr oducts and services. Some of t h es e s ys t ems w er e inherited t hr ough mer ger s t hat ex pa nded pur
pr oducts and s er vices,T her e also exist several marketing oppor tunities to Increase ou r pr esence to our memb er s , One
exa mp le includes Internet c o mm er c e ser vices. Finally, t he aut omat ic identification s ystem being developed for t h e
war ehou s e must ful[y inter operate with me mb er s er vic es . '

BRIEF STATEMENT OF EXPECTED SOLUTION

We envision comp letely new and str eamlined business pr ocess es t hat minimize the r es p ons e time t o member
or der s for pr oducts and services. An or der shall not be cons ider ed fulfilled until it has been r eceived by the
mer nb er.T he new s ystem should pr ovide for ex pa nded club and m e mb er flexibility and adaptabiSity of basic
business pr oducts and services.
We envision a system that ext ends to the des ktop co mp u t er s of both emp loyees and memb er s , with" appr opr iate
shar ed services pr ovided acr oss the network, consist ent with t h e ISS distributed architecture.This Is consist ent with
strategic plans to retire the AS/400 central comp ut er and replace it with servers�_

actio n {tss Office Use Only)

□ Feasi�ilfty a s se ssmen t approved Assigned to Sandra Shepherd
1� FeaslbtJity a s ses smen t waived Approved Budget $_

Start Date ASAP Deadline ASAP

D Request delayed Backlogged until date:

D Request rejected Reason: _

AuthoHzed Signatures: y ;

�ehe£>£>a J. 7"
Chair, ISS Executive Steenng Body

FORM IS5-100KF55 CUsl revised December,

El p roduc t o fundamental de esta tarea, la deelniciOn peelim n ar d e l problema, consiste

en p rob lema s, op ortunidad ea y directrices q u e fu eron identificadas. Las dbhn icion es de
PROBLEMAS se a lmacenan en el repositorio p a ra uso posterior e n el proyecto. La figura 4.8
es un documento muestra que resume problemas, oportunidades y directrices en t&minos
de:

• Urgencia. �En que tiempo debe ser resuelto el problema o debe ser realizada la
opcrtunidad o directriz? Una escala de calificacion puede desarrollarse para respon-
der de manera. consistente a esta pregunta.
• Visibilidad. iA que grado una solucion o u n sistema nuevo debe ser visible para los
clientes o la administracion ejecutiva? De nuevo, podria desarrollarse una escala de
calificacion para las respuestas.
• Beneficios. iAproximadamente cuanto incrementaria una solucion o u n sistema
nuevo los ingresos anuales o reduciria los costos anuales? Esto a menudo es incierto,
pero si todos los participantes cooperan en esta estimacion, demostrara ser bastante
conservadora,
 Analisis de sistemas Capiiula Cuatro 113

Defjnicion de problema

Sistema de inform acion de servicios a miembros Administrador de proyecfo: Sandra Shepherd

�Pro�ecp �
Sandra Shepherd Actualizado por ultima vez por: Roberto Martinez
�reado por

Ipecha de oreacion; 9 de enero de 2003 Fecha de iittima actualizacion; 15 de enero de 2003

---—r rsii'5
Beneficios Prioridad Solucioti
mj�Jefiniclones breves de problema,
0 dlrectriz Urgencia Visibilidad anuales olu gar propuesta
��p�'oportunidad

gl tiempo ds respuesta del pedido medido Tan pronto Alta - $175 0.00 2 Nuevo desarrollo
■
'desde el momento de recepcion, hasta la como sea
■
•entrega del mismo ha aumentado en un posible
"�promedlode15dias.
' <2 Las recientes adquisiciones de Club de 6 meses Mediana 75 000 2 Nuevo desarrollo
Video de monitoreo privado y pantalla
de juego enfatizarars mas aun los
■

requerimientos del sistema actual.

'Actualmente tres distintos servicios de 6 meses Mediana 515 000 2 Nuevo desarrollo
3 entrada de sistemas, audio, video y
divisfones de juego. Cada sistema esta
disefiado para tener una interfaz con un
' sistema de aimacenes
distinto; por tanto,
> la sntencion de fusionar el inventario a un ■

� solo almacen se ha retrasado.

. 4. Hay unafalta general de acceso a la 12 meses Baja 15 000 3 Despufe de que un
tnformacion administrativa y de toma de .
sistema nuevo se
declsiones. t s t o se torna dificil por la desarrolla, es necesarlo
adquisicion de dos sistemas de procesa de proporclonar a los usuarios
� pedidos adicionaies (de filtracibn privada herramientas de reporte
�
y pantalla de juego). taoiles de aprendery utilizar

4 5,4 Actual mente existen inconsistencias de 3 meses Alta 35 000 1 Arreglo rapido; luego
;■ s.i datos en los archivos de miembros nuevo desan-ollo
\ '"i y pedidos-
'
e. lia filtracion privada y los archivos de 6 meses Mediana Desconoctdos 2 Nuevo desarrollo.
- ■* sistemas de
pantalla de juegos son Cuantiflcacion adicionai
" de beneSicio podn'a
Si> incompatibles con los equivaSentes de
SoundStage Los probiemas de datos incrementar la urgencia
■ de
negocios incluyen inconsistencia de
r -iidatos y falta de controles de edicion
I ,■ nde entrada.
siste
S DE 7. Hay una oportunidad de abrir sistemas 12 meses Baja Desconocidos 4 Version futura de un
'
de pedidos en el internet, pare la sistema recien desarrollado
inos segurldad y et coritrol son un tema.
GURA 4
8, El sistema de entrada de pedidos actual 3 meses Alta 65 000 1 Arreglo rapido; luego
i8 Miiestr
; es incompatible con el slguiente sistema nuevo desarrollo
de identificacion automatica {codigo de a de defiruci
. barras) que se desarrolla para el almacen. ones de probl
emas
- -

erto,
ante
114 Parte Dos Metodos de analisis de sistemas

» Prioridad. Con base en las respuestas anteriores, �cuales son las prioridades acordadas
entre todos para cada problema, oportunidad o directriz? Si el presupuesto o el programa
se vuelven un problema, estas prioridades ayudaran a ajustar el alcance del proyecto.
•
Solucionesposibles (OPT). En esta etapa inicial del proyecto, las soluciones posibles se
expresan mejor en terminos simples como a) salir de ello bastante bien, &) utilizar un
arreglo rapido, c) hacer una mejora de simple a moderada del sistema existente, d) redi-
senar el sistema existente o e) disenar un nuevo sistema. Los participantes listados arriba
para esta tarea son los adecuados para un analisis de alto nivel de estas opciones.
El marco de referenda PIECES que se presento en el capitulo 3 puede utilizarse como
marco de referenda para clasificar problemas, oportunidades, directrices y restricciones.
For ejemplo, el problema 1 en la figura 4.8 podria clasificarse de acuerdo con PIECES
como P.B.: Desempeno, tiempos de respuesta. (Vease la figura 3-4 en el capitulo 3.) El
problema 4 en la figura 4.8 podria clasificarse como I.A.2: Informacion, Salidas, Falta de
informacion necesaria.
Las tecnicas basicas utilizadas para completar esta tarea incluyen busqueda de datos y
reuniones con los PROPIETARIOS d e l sistema. Estas tecnicas se ensenan en el capitulo 5.

> Tarea 1.2: Negociar el alcance base

El alcance define los Ifmites del proyecto; aquellos aspectos del negocio que seran in-
cluidos en el proyecto y los que no. El alcance p uede cambiar durante el proyecto; sin
embargo, el plan de proyecto inicial debe establecer el alcance preliminar o base. En con-
secuencia, si el alcance cambia en forma significativa, todas las partes tendran una mejor
apreciacion de por que cambian tambien el presupuesto y el programa. Esta tarea puede
ocurrir en paralelo con la tarea anterior.
Una vez mas, un analista de sistemas experto o un administrador de proyecto por lo ge¬
neral dirigen esta tarea. La mayor parte del resto de los participantes se dasifican de manera
colectiva como PROPiETAmos d e l sistema. Esto incluye al patrocinador ejecutivo, los gerentes de
todas las unidades organizacionales que pueden tener impactos per el sistema y tal vez los
gerentes de sistemas de informacion. Los usuaeios de sistemas, disenadohes de sistemas y cons-
TRUCTORES DE SISTEMAS en general no participan en esta tarea.
Como se muestra en la figura 4.6, esta tarea utiliza la definici6n de problema preliminar
producida por la tarea anterior. Debe tener sentido que esos problemas, oportunidades y
directrices forman la base para definir el alcance. Las definiciok es d e l alcan ce del p ro y ect o
se suman al repositorio para su use posterior. Estas definiciones tambien se documentan
de manera formal como el producto de la tarea, def in icion d e l problema preiiminar c o n
ALCANCE.
El alcance puede definirse con facUidad dentro del contexto de los componentes de
su sistema de informacion. Por ejemplo, el alcance de un proyecto puede describirse en
terminos de:
• iQue tipos de d at o s describen al sistema que se estudia? Por ejemplo, un sistema de
informacion de ventas puede requerir datos acerca de cosas como cuentes, pedidos,
PRODUCTOS y representajsttes de ventas.
• iQue p rocesos de negocios se incluyen en el sistema que se estudia? Por ejemplo,
un sistema de informacion de ventas puede incluir procesos de negocios para admi-
n ist raci6n d e catalogo, administraci6n de clientes, in gres o de pedidos, s at isf acci on
DE PEDIDOS, ADMINISTRACION DE PEDIDOS y ADMIN1STRACI6N DE LA RElACldN CON ICS CLIEN¬
TES.
• �Como debe ser la int erf az del sistema con los usuarios, locaciones y los demas siste¬
mas? Por ejemplo, las interfaces potenciales de un sistema de informacion de ventas
podria incluir cu entes, represeotantes de ventas, empleados y gerentes de ventas, ofici-
NAS EEGIONALES DE VENTAS y los SISTEMAS DE CUENTAS POR COBRAR y SISTEMAS DE INFOEMACi6n
DE CONTROL DE INVENTAKIOS.
Notese que cada definicion de alcance p uede ser descrita como una simple lista. No
"defmimos" de manera necesaria los productos en la lista. Ni tampoco estamos muy pre-
ocupados por un an�isis de requeiimientos preciso. Y en definitiva, no nos interesan los
pasos que toman mucho tiempo como la elaboracidn de modelos o de prototipos.
Una vez mas, las tecnicas primarias utilizadas para completar esta tarea son la identi-
ficacion de hechos y las reuniones. Muchos analistas prefieren combinar esta tarea con la
anterior y la siguiente para realizarlas dentro de una sola reunion.
 Anolisis de sistemas Capitulo Cuatro 115

� Tarea 1 <3: Evaluar el beneficio del proyecto bcsse

la la en este proyecto?". En esta
Aqui 6® donde respondemos pregunta; "ivale pena trabajar
inicial del proyecto, la pregunta en realidad podria reducirse a hacer una "mejor
etapa
suposicion". iSolucionar
Ids problemas, explotar las oportunidades o satisfacer las direc-
trices devolvera el valor suficiente para superar los costos en los que incurriremos para
clesarrollar este sistema? Es imposible hacer un adecuado analisis de factibilidad coji base
en los hechos llmitados que hemes reunido hasta el momento.
Una vez mas, un analista de sistemas experto o un administrador de proyecto, por
lo general dirigen esta tarea. Pero los propietahios del sistema, incluidos el patrocinador
ejecutivo, ios gerentes de unidades del negocio y los del sistema de informacion, deben
tomar la decision.
Como se muestra en la figura 4.6, la definicion peeliminar d el probiima con el aicance
dispara la tarea. Esto proporciona el nlvel de informacion requerido para esta evaluacion
preliminar del valor. No hay un producto fisico distinto a la decision de siGUE o no sigue.
En realidad hay varias decisiones altemativas. El proyecto puede aprobarse o cancelarse y el
aicance del proyecto puede renegociarse (aumentar o disminuir). Es evidente que las tareas
restantes en la fase de investigacion preliminar son necesarias solo si el proyecto ha sido
considerado valioso y si tiene la aprobacion para continuar.

> Tarea 1.4: Desarrollar un programa y presupuesto base

Si el proyecto se ha considerado como valioso para continuar, ahora podemos planear la

extension del mismo. El proyecto inicial debe consistir al menos de lo siguiente;
• Un plan maestro preliminar que incluya programa y asignacion de recursos para el
proyecto completo. Este plan sera actualizado al final de cada fase del proyecto. A
veces se llama plan base (baselineplan).
• Un plan y programa detallado para completar la siguiente fase del proyecto (la de
analisis del problema).

La tarea es responsabilidad del administrador del proyecto. A la mayor parte de los

administradores de proyectos les resulta litil incluir lo mSs posible del equipo del pro¬
yecto, incluidos los propietaeios de sistemas, usuamos, diseSiadores y c on s t ru c t ores . Como
se mostro en la figura 4.6, esta tarea se dispara por la decision de sigue o no sigue para
continuar el proyecto. Esta decision representa un acuerdo consensuado acerca del ai¬
cance, los problemas, las oportunidades, las directrices y el valor del proyecto. (Este "va¬
lor" debe atin ser presentado y aprobado.) Las defimciones (acotad as ) d el problema son la
entrada fundamental del repositorio. El producto de esta tarea es el plan y programa del
proyecto base. La definicion d el tbabajo, el programa d el pkoyecto y asignacion de recur¬
sos tambien se agregan al repositorio para una vigilancia continua y actualizacion, segiin
resulte apropiado. El programa y los recursos se mantienen en forma normal en el reposi¬
torio como un archive de software administrativo,
En la actualidad, las tecnicas utHizadas para crear un plan de proyecto son soportadas
por software de administracion de proyectos como Microsoft Project.*
comite de direccion Un
comite de gerentes ejecuti¬
> Tarea 1.5: Comunicar el plan del proyecto vos de negocios y sistemas
que estudia y jerarquiza
En la mayoria de las organizaciones, hay mas proyectos potenciales que recursos para propuestas de proyectos que
dar fondos y personal a esos proyectos. A menos que nuestro proyecto haya sido prede- oompiten entre si, con el fin de
terminado a ser de la mas alta prloridad (por algun tipo de decision tactica o proceso de determinar cudles generarai
mas valor para la organlza-
planeacion estrategica), debe ser presentado y defendido frente a un comite de direccion cion, de las cuales, algunas
para su aprobacion. La mayoria de las organizaciones utilizan un comite de direccion para se aprobaran para que conti¬
aprobar y vigilar los proyectos y su progreso. La mayor parte de los integrantes de cual- nue el desarrollo de sistennas.
quier comite de direccion debe estar constituida por ejecutivos o administradores que no Tambien llamado comits de
'
fornien parte del area de los sistemas de informacion. Muchas organizaciones designan dheccidn.

*Nota del R.T.'. Al lector snteresado en este tema se le recomienda consultar el PMBOK del PMI.
11 6 Parte Dos Metodos de analisis de sistemas

vicepresidentes para formar parte del comite de direccion. Otras organizaciones asignan
el personal que reports en forma directa a los vicepresidentes del comite de direccion.
Algunas organizaciones utilizan dos comit�s de direccion, uno para vicepresidentes y uno
para su personal directo. Los gerentes de sistemas de informacion trabajan en el comite de
direccion solo para responder preguntas y para comunicar prioridades de vuelta a los desa-
rrolladores y a los administradores de proyecto.
Sin importar si un proyecto requiere o no de la aprobacion de un comite de direc¬
cion, es de igual importancia lanzar y comunicar de manera formal el proyecto, las metas
y el programa a la comunidad entera del negocio. Abrir las Hneas de la comunicacion es
un paso importante para la investigaci6n preliminar. For esta razon, recomendamos las
"mejores practicas" para conducir un evento deproyetto desalida (kickoff) y crear un sitio
Web de proyecto de intranet. La reunion de salida del proyecto esta abierta a la comunidad
entera de negocios, y no solo a las unidades de ne go dos afectadas y al equipo de pro¬
yecto. El sitio Web de proyecto de intranet establece un portal de comunidad para todas
las noticias no sensibles y la documentaci6n relacionada con el proyecto. ■
De manera ideal, el patrocinador ejecutivo debe facilitar en forma conjunta la tarea con
el administrador de proyecto elegido. La visibilidad del patrocinador ejecutivo establece
una credibUidad instantanea y una prioridad para todos los que participan en la reunion de
salida. Otros participantes en la reunion de salida deben incluir el equipo de proyecto com-
pleto, incluidos los propietaiuos, usuaeios, analistas, disenadores y con st ru ct ok es de sistemas
asignados. Es preferible que la reunion de salida este abierta a cualquier miembro del per¬
sonal interesado de la comunidad de negocios. Esto crea conocimiento y hace un consenso
entre los involucrados al tiempo que reduce tanto el volumen como las consecuencias del
rumor y de la mala informacion. Para el componente de intranet, un Webmaster o un autor
Web debe ser asignado al equipo de proyecto.
Como se muestra en la figura 4.6, esta tarea se dispara por el cumplimiento del plan y
PROGRAMA DEL PROYECTO BASE. Las DEnNiciONES DE PROBLEMA y cl ALCANCE estan disponlbles en
el repositorio. El producto es el esquema d e l p ro y ect o y �ste, por lo general, es un docu-
mento. Incluye diversos elementos que definen el proyecto en terminos de participantes,
problemas, oportunidades y directrices; alcance, metodologia, definicion del trabajo que
se debe completar; productos, estandares de calidad, programa y presupuesto. El esquema
del proyecto debe agregarse al sitio Web del proyecto para que todos lo vearaos. Los
elementos del esquema del proyecto tambien p ueden ser presentados como diapositivas
y boletines (por medio de software como PowerPoint de Microsoft) para inclutrlos en el
suceso de inicio del proyecto.
Las habilidades interpersonales y la comunicacion son las claves para esta tarea. Es-
tas incluyen principios de persuasion, compra-venta, creacion de contratos y hablar en
publico.
Con esto terminamos nuestro analisis de la fase de definicion de alcance. En esta fase,
los participantes podrian decidir que el proyecto no vale la pena para proponerse. Tam¬
bien es posible qtie el comite de direccion pueda decidir que otros proyectos son mas im-
portantes. O el patrocinador ejecutivo podria no avalar el proyecto. En cada uno de estos
casos, el proyecto se termina. Poco tiempo y esfiaerzo se ha n utilizado. Por otro lado, con
la bendicion de todos los propietarios de sistemas y del comite de direccion, el proyecto
podria continuar a la fase de analisis del problema,

Fase de analisis del problema

Hay u n viejo dicho que dice: "no trates de arreglarlo si no lo entiendes". Esta declaracion
describe en forma adecuada la fase de analisis del problema del analisis de sistemas. Siem-
pre hay un sistema actual o existente, sin importar a que grado este automatizado con
tecnologia de informacion. La fase de analisis del problema proporciona al analista una
comprension mas completa de los problemas, oportunidades y/o directrices que dispara-
ron el proyecto. La fase de analisis del problema responde a las preguntas, "�*vale la pena
resolver estos problemas?" y "�vale la pena construir un nuevo sistema?". En otras metodo-
logias, la fase de analisis de problemas puede ser conocida como fase de estudio, estudio
del sistema actual, fa se de investigacion detallada o fa se de analisis de factibilidad.
�Alguna vez se puede pasar por alto la fase de analisis del problema? jRara vez! Casi
siempre se necesita un nivel de comprension del sistema actual! Pero puede haber razo-
 Anaiisis de sistemas

la fase del anaiisis del problema. Primero, si el proyecto fue disparado

les p�''� ;icelerar
' a iia estratfegico o tactico, es probable que el valor del proyecto no este en duda,
fjse del anaiisis de problema se reduciria a una comprension del sistema actual, no a
Segundo, un proyecto puede ser iniciado por una directriz (tal como el cum-
aojii/arl"
con una instruccion y vencimiento gubernamental). De nuevo, en este caso el
litniento
no esta en duda. Por ultimo, algunas metodologias y organizaciones de
�jjoi del proyecto
consolidan el anaiisis del problema y las fases de anaiisis de requeri-
jijaaerg. deliberada
acelerar el anaiisis de sistemas.
jjjientos para-
l�'meta: de la fase del anaiisis del problema es estudiar y comprender el dominie
lo bastante bien para analizar a fondo sus problemas, oportunidades y res-
pioblema
tnicciones Algunas metodologias deftnen una comprension muy detallada del sistema
actual y lo documentan con sumo detalle mediante modelos de sistemas como diagramas
(fe'fltijo de datos. En la actualidad, excepto cuando los procesos de negocios deben ser
re d is e na d o s , el esfuerzo requerido y el
valor agregado por dichos modelos detallados se
c ues tfo na n y por lo general se ignoran. For tanto, la version actual de nuestra metodolo-
�jii|}otetica ii45r define un modelado de sistemas suficientemente amplio para refinar
nue�lr;� comprension del alcance del proyecto, la definicion del problema y la definicion
de un vocabulario comun para el sistema.
i FKcontexto para la fase del anaiisis del problema esta sombreado en la figura 4.9.
que la fase del anaiisis del problema trata en su mayor parte con los puntos de
'
vib'� de los PROPIETAWOS y u s u A H i o s DEL SISTEMA acerca del sistema existente. Notese que
conltjaumos sobre las listas creadas en la fase de investigacion preliminar para analizar los
»compQhentes del con ocimient o, proceso y comunicaciones del sistema existente. Tambien
-notcle que determinamos la elaboracion del minimo modelo de sistema. Podemos aiin
■qjt�ai�el marco de referenda PIECES para analizar problemas, causas y efectos en cada
�'compl�ehte del sistema.
4.10 es el diagrama de tareas para la fase de anaiisis de problemas. El pro-
plo e Into de la fase final es producir objetivos d e mejora de siSTEiWAS que aborden los
' .�Memas,eloportunidades y directrices. Segun se conozca el tamano del sistema, su com-
-plgidad y grado en que el proyecto es valioso, las tareas Uustradas pueden consumir de
'
,iii& a.scis semanas. La mayoria de estas tareas pueden ser aceleradas por sesiones estilo
J){l'"|�5fase de anaiisis de problemas por lo general incluye las siguientes tareas;
2 Igiitender el dominie del problema.
2 2;|Malizar problemas y oportunidades.
'l ��SaliKar procesos de negocios.
- timablecer objetivos de mejora del sistema,
- "JM�ualizar o refinar el p l an d e l proyect o.

, - SjCitgiiiinicar resultados y recomendaciones.

tareas con. mayor detalle.
���nalicemos cada una de estas
;ii«d 2.1: Entender el dominio del problema
lUe .la fase de anaiisis de problema, el equipo al inicio intenta conocer sobre el sis-
iacyai. Cada propI£T.4.sio, usuakio y a k a u s t a de sistemas ap.osta un nivet-diferente de
grj,risi6n al sistema —detalle, vocabulario, percepciones y opiniones diferentes—. tin
� 3l0;:bien conducido puede demostrar ser revelador para todas las partes, incluida la
el
.�nistracion y los usuarios propios del sistema. Es importante estudiar y entender
linip delproblema, ese dominio en el que existen los problemas, oportunidades, direc-
'.:y 'restricciones del negocio.
J�sta tarea sera dirigida por el administrador del proyecto pero sera facilitada por el
�sta de sistemas. Es comun que un individuo desempene ambos papeles (como lo
•■je Sandra en el caso de SoundStage). Otros a n a u st a s de sistemas pueden tambien par-
ya que realizan entrevistas, participan en juntas y documentan los resultados. Un
rlio coiiipleto debe incluir frop ietab ios y u su arios d e sistemas representativos de todas
ytidades de negocios que seran apoyados o impactados por el sistema y el proyecto.
fimportante que se incluyan suficientes usuarios para abarcar el alcance total del
S�lfliue se estudia. En algunas organizaciones, uno o mas usuarios experimentados
■�{�eFtados" al proyecto de tiempo complete como analistas de sistemas-, sin embargo,
18 Porte Dos Metodos de analisis de sistemas

DEFIN]C|6N DEL TRABAJO

DEFINICJON DE PROBLEMA (con el inarccj d« rsferencis
gH PIECES)

: ALCANCE
yvisi6n . . .
□E INFORMAClbN

OBJETiVOS DE MEJORA DE SISTEMA.

(con e! marco de referencia PIECES)

definici6n de REQUERIMIENTOS de NEGOCIOS

REQUERIM�ENTOS REQUER1MIENT0S REQUERIMIENTOS

\ DE DATOS
DE NEGOCIOS
DE PROCESO
DE NEGOCIOS
DE INTERFAZ DE
NEGOCIOS Y
DE SISTEMAS
MODELOS MOOELOS MODELOS
l6gi co s lOgicos logicos
DE DATOS DE PROCESO DE INTERFAZ

PROPUESTA DE SISTEMAS (O SOLICtTUD DE PROPUESTA DE SISTEMAS)

APLICACION DE ARQUITECTURA

PROTOTIPOS DE DISENO

mSENO
ESPECIF1CACIONES DEPROCESO ESPECtFlCAClONES
DE DISENO
FI5ICO DE LA
DE NEGOCIOS
ESPECIFICACIOKES
DEL DISENO Fl'SICO
DE INTERFAZDEL V OS

BASE DEDAT05 USUAFIOY

D£ DISEI� DE SISTEMAS
fISICO DE SOFTWARE

SISTEMA PUNCIONAL MATERIALES DE CAPAClTAClON

PAQUETES SOLUCIONES
OE SOFTWARE DE INTERFAZ
SOLUCEON COMERCIAL DE LFSUARIO
DE BASE
DE DATOS SOFTWARE SOLUCIONES
DE APLICACION DE INTERFAZ
A LA MEDIDA DE SISTEMAS

SISTEMA OPERATIVO REVISION POSTERIOR A LA AUDITORfA

Reslriccldn: Restriccion: Restriccion:

TECI40L0GIAS TECNOLOQiAS TECNOLOQIAS
DE BASES DE DEPROCESO DE INTERFAZ
DATOS APROBADAS APROBADAS APROBADAS

RestriGd6n:TECN0L0GIAS DE RED APROBADAS

Arquitectura tecnologica de informacion estrategica empresarial

FIG U R A 4.9 C o nf e xt o de la fase de an �isis de pr ob lem as de l analisis de sistemas

 Analisis de sistemas Cap��ulo Cuatro 119

FIGURA 4.10
Tareat�para la fiise dc;
aniilisis de problemas
del m41isis

es f-Ato que cualquier usuario pueda representar en su totalidad los intereses de todos los
5usuanos. Sin embargo, los analistas de sistemas pueden fungir como facilitadores para
hacer que participen las personas correctas y sostener una comunicacion eficaz de vuelta
con'Ias umJades del negocio y la administracion. Los d isen ad ores y los c o n s t r u c t o re s de
sihTEMAS rara vez participan en esta tarea a menos que sean entrevistados para determinar
.f-udquier limitacion tecnica del sistema actual.
sEn la figura 4,10 esta tarea se dispara per a p ro b a c i 6 n para c o n t i n u a r el p ro y e ct o;
dt-sde la tase de definicion de alcance. (La Imea punteada indica que esta aprobacion
es iin suceso o disparador, no un flujo de datos o informacion.) La aprobacion viene
de los PROPIETARIOS DEL SISTEMA o de un comite de direccion. La entrada de informacion
hiadamental viene de los p rop iet asios del sistema y cualquier d o cu m e n t ac i 6n de sistema
AcfifAL que pueda existir en el repositorio y en las bibliotecas del programa para el sis-
ttma actual. La documentacion del sistema actual no siempre existe. Y cuando existe,
debe ser revisada con sumo cuidado para ver su actualidad; es notorio que la mayor
parte de dicha documentacion es obsoleta debido a que los programadores y analistas
11© siempre son diligentes para actualizarla cuando ocurren cambios a lo largo de la vida
dc un'sistema,.
Los productos de esta tarea son una comprension del dominio d e l problema y del voca-
SPLABio De NEGoaoS. Su comprension del dominio del problema existente debe ser documen-
ftda para que pueda verificarse que se entiende bien. Hay diversas formas de documentar
el doiiiinio del problema. Es cierto, dibujar modelos d e l sistema del que hay en la actualidad
puetlu ayudar, pero eso puede Uevar a un fenomeno Uamado "paralisis de analisis" en el que
; el deseo de producir modelos perfectos se vuelve contraproducente para el cronograma. Otro
120 Parte Dos Metodos de andiisis de si sterna s

jn�todo podria ser utilizar los componentes de su sistema de informacion como marco
4;
referenda para listar y definir el dominio del sistema; .■
• CONOCIMIENTO. Liste todas las "cosas" acerca de las cuales el sistema en la
actualidad
almacena datos (en archivos, bases de datos, formatoSj etcetera). Defina cada co.sa «•'-
terminos de negocios. Por ejemplo, "un peDiekd es una transaccion de negocios en la-
que un clienle solicita adquirir productos".
Ademas, podriamos listar todos los informes producidos por el sistema actual y
describir su proposito o uso. Por ejemplo, "el informe de pedidos abiertos describe;
todos los pedidos que no ha n side surtidos una semana despues de haber side ap-
bados. El informe se utiliza para iniciar una administracion de la relacion con los
clientes a traves del contacto personal".
• Procesos. Defina cada suceso de negocios para el cual una respuesta de negocio.s
(proceso) es implementada en la actualidad. Por ejemplo, "un cliente coloca un
nuevo pedido" o "un cliente solicita cambios a un pedido ya realizado" o "un cliente
cancela un pedido".
• COMUNICACIONES. Defina todas las ubicaciones
que e l sistema actual atiende y todos
los usuarios en cada una de esas locaciones. Por ejemplo, "el sistema es utilizado en
la actualidad en las oficinas de ventas regionales en San Diego, Dallas, St. Louis, In¬
dianapolis, Atlanta y Manhattan. Cada oficina de ventas regionales tiene un gerente
de ventas, un asistente del gerente de ventas, asistente administrativo y de 5 a 10
empleados de ventas, todos los cuales utilizan el sistema actual. Cada region tambien s
es la base de entre 5 y 30 representantes de ventas que viajan casi todos los dias
pero que cargan pedidos y otras transacciones todas las tardes".
Otra faceta de las interfaces son las interfaces del sistema; es decir, aquellas que
existen entre el sistema de informacion acmal y otros sistemas de informacion y apli-'
caciones de computo. Estas pueden ser listadas de manera rapida y ser descritas pot �
el personal de sistemas de informacion.
Por ultimo, ia metodologia de desarrollo de sistemas de la organizacion y el plan de pro-
yecto determinara que tipos y nivel de documentacion son los esperados.
. , El producto de vocabulario de negocios se abrevia con demasiada frecuencia. En-
tender el vocabulario de negocios del sistema es una forma excelente de comprender el
sistema mismo. Construye puentes para salvar la brecha de comunicacion que a menudo
; existe o se desarrolla entre los expertos de negocios y los de tecnologia.
Si elige realizar modelos de sistemas durante esta tarea, sugerimos que si "desea aprender
algo, no debe tratar de aprender todo-, al menos no en esta tarea". Para evitar una paralisis de
analisis, sugerimos que los modelos de sistemas siguientes pueden ser apropiados; �
• CONOCIMIENTO. Un modelo de datos de una pagina es muy litil para establecer voca¬
bulario y reglas de negocios. La elaboracion de modelos de datos se ensefia en el
capitulo 7.
• Procesos. En la actualidad, es muy aceptado que un diagrama de descomposicioii
funcional de una o dos paginas debe ser suficiente para tener la idea del procesa-
miento del sistema actual. La elaboracion de modelos de descomposicion se ensefia
en el capitulo 8.
• COMUNICACIONES, Un diagrama de contexto de una pagina o los diagramas de caso. de
uso son muy utiles para ilustrar las entradas y salidas de un sistema con otras orga-
nizaciones, unidades de negocios y sistemas. Los diagramas de contexto se analizan
mas adelante. Los diagramas de casos de uso se ensenan en el capitulo 6.
Qtras tecnicas y habilidades son utiles para desarrollar una comprension de un sis¬
tema existente. Es evidente que, las tecnicas de bdsqueda de resultados (ensenadas en
el siguiente capitulo) son criticas para aprender acerca de cualquier sistema existente.
Tambien, las tecnicas de planeacion conjunta de requerimientos o JRP (ensenadas en el
siguiente capftulo) pueden acelerar esta tarea. Por ultimo, la capacidad de comunicar en
forma clara a los usuarios lo que ha aprendido acerca de u n sistema tambien es crucial.

Diagrama de contexto El prop6sito de un diagrama de contexto es analizar como el

sistema interactua con el mundo y especificar en terminos generales las entradas y salidas
del sistema. Los diagramas de contexto pueden dibujarse de diversas formas. Eri el capi¬
tulo 8 se presenta el formato tradicional, que ftie hecho cofno el primer pasp para dibujar
'
diagramas de flujo de datos, .
 Andlisis de sistemas Capitulo Cuairo 121

lo marco (

ictualidall
ada cosaf
>cios en ]

la actual!
I descril
r sido apf(
con los

egocios ; p'-:;
'
-Nueva suscripcion Estatus crediticio o
ca un de miembro
'un clienti"

5 y todos Cuentas por cobrar

~ Nllembro potencial
tilizado r�V
Louis, In-
n gerente
i 5 a 10 " Oferta de suscripcion Sistema Pedido de empaque-
o
on tambiii :fd0 servicios

A
-Promocion- -Nuevo programa
OS dias . miembro
- %T

luellas Almacen
don y ap]
;scritas poj Diversas respuestas
de solicitudes Programa 0
de suscripcion
»lan de pfi
Pedido de tniembro -
-Miembro del club
uencia.a, Informes Departamento de mercadotecnia
Qprender e � J<' v.t de miembros
; a menudi o
ea aprendi
paralisis df
A Promocion, suscripcion
Servicios de miembros e informes de miembros

)0SlC10n
J'MRA_4.n IJiagraia a de contexto 0
procesa
se ensena- efcapitulo 6 se muestra un formato diferente para un diagrama de contexto, el que
en la figura 4.11 utiliza un metodo Mbrido. Utiliza simbolos de casos de uso
de ease dj li�fa-yostiado
jut cstos se vuelven una herramienta por lo general aceptada de la fase de anMisis de
'tras orga: fl'ucrmiientbs,
s analizani Hlisistefna mismo se muestra como una "caja negra" en medio dei diagrama. No esta-
��tos para ver dehtro de esa caja. Por ahora, solo queremos ver como todos la utiliza-
I de un si| 4,as figuras de lineas alrededor de la parte externa del diagrama son las personas, las
senadas d �ani7aciones y los otros sistemas de informacion que interactuaran con el sistema. En
1 existenti IS? casos de uso, estos se llaman actores y asi podemos nombrarlos aqui. En los diagra-
iadas en �#&»de Jlujo de datos tradicionales, se llaman agentes externos. En los capitulos 6 y 8
como
municar ��endcra que una vez que usted mira dentro de la caja del sistema, otros factores
� crucial c gl�inpo o aparatos como sensores pueden tambi�n ser actores o agentes externos. Pero
kdiagrama de contexto rara vez se incluyen.
;ar como Imeas indican las entradas (flechas que apuntan hacia el sistema) proporcionadas
as y salii |Fsloi actores al sistema y las salidas (flechas que apuntan hacia los actores) creadas por
En el cap! felerna, Cada entrada y salida se identifica con una frase propia que la describe.
)ara dlbus Py�ara eoiistruir un diagrama de contexto pregunte a los usuarios a que transacciones
Megodds debe responder el sistema; estas son las entradas. Tambien pregunte a los
122 Parte Dos
• . capltulo 2; "utilice un metodo de soluci6n de
_ a analizar el problema antes de afirmar una posible solucion. Analizan cada problema
analisis de causa y
efecto T6cnica en la que se
estudian problemas para de-
terminar sus causas y efectos.
Metodos de anolisis de sistemas
usuarios que reportes, notificaciones y demas salidas debeii ser producidas por el sistema.
Un sistema puede tener muchos reportes o informes que p ueden sobrecargar de manera
rapida el diagrama; consolidelos como sea necesario para mantener legible el diagrama.
Se analizaran en forma separada durante otras fases en el proceso.
Es cierto que no podriamos construir un sistema de informacion a partir de un
diagrama de contexto. Pero es un primer paso solido. Desde este diagrama simple, sa-
bemos a que entradas debe responder el sistema y que salidas debe producir. En otras
palabras, nos ayuda a entender el dominio del problema. Veremos en el capitulo 6 como
detectar casos de uso a partir de un diagrama de contexto. Ese sera el primer paso en abrir
la "caja negra". Seguimos los principios para el desarrollo de sistemas presentados en el
problemas" y "divida y yencera".
> Tarea 2.2: Analizar problemas y oportunidades
Ademas de aprender acerca del sistema actual, el equtpo del proyecto debe trabajar con
los propietarios y los usuarios de sistemas para a n a l i z a r problemas y oportunidades.
Usted p uede preguntarse, "ino se identificaron con anterioridad los problemas y oportu¬
nidades, en la fase de investigaci6n preliminar?" Si, asi fue. Pero esos problemas iniciales
p ueden ser solo smtomas de otros, taJ vez problemas no tan bien conocidos o entendidos
p or los usuarios. Ademas, en realidad no hemos analizado ninguno de esos problemas en
el sentido clasico.
El analisis verdadero de problemas es una habilidad dificil de dominar, especial-
mente para los analistas de sistemas inexpertos. La experiencia sugiere que la mayoria
de los analistas de sistemas (y muchos de los propietarios y usuarios de sistemas) tratan
de solucionar problemas sin analizarlos de verdad. Ellos podrian definir un problema
como este; "Necesitamos..." o "Queremos..,". A1 hacer esto, definen el problema en ter-
minos de una solucion. Los solucionadores de problemas mas eficaces ha n aprendido
percibido para sus c a usas y efectos. En la practica, un efecto p uede ser en realidad un
slntoma de un problema arraigado en forma mas profunda o mas basica. Ese problema
tambien debe ser analizado para enccntrar sus causas y efectos y asi sucesivamente
hasta q ue llegue el me me nt o en que las causas y los efectos no arrojen smtomas de
otros problemas. El analisis de causa y efecto lleva a una verdadera comprension de
los p r ob l e m a s y puede c ond uc i r a soluciones m a s creativas y v�liosas q u e n o eran tan
evidentes.
Los ANALISTAS DE SISTEMAS facilitan esta tarea; sin emba rgo, t od os los prop ietarios y
usuAHios Di: SISTEMAS d e b e n participar de m a n era activa en el p roc es o del analisis de causa
y efecto. Ellos s on los exp ert os de d om ini o del problema. Los disen adoees y con st ru ct ok es
DE SISTEMAS p o r lo general n o participan en este p roc es o a m en o s qu e sean Ilamados pa ra
analizar p rob lema s tecnicos q ue puedan existir en el sistema actual.
Como se mues t ra en la figura 4.10, la c omp r ens i on del e q uip o del d om in io del
SISTEMA Y vocABULARio DE NEGOCIOS dispara esta tarea. Esta c ompr ensi on del dominio
del problema es crucial debido a q ue los miembros del eq u i p o no deb e n intentar ana¬
lizar pr obl ema s a me n o s q ue ent i en da n el domi nio en el q ue estos ocurren. La otra
ent ra da de informacion de esta tarea son las d ef i n i c i o n e s del f ro b i e m a (de la fase de
definicion de alcance). Los p r oduct os de esta tarea son las d e f i n i c i o n e s del prob lem a
(des de la fase de definicion de alcance). Los p r oduc t os de esta tarea s on las defini¬
c i o n e s DEL PROBLEMA actualizados y el�ANAUsis DE causa-efecto p ara cada pr ob l ema y
op ort uni da d. En la figura 4.12 se ilustra una forma de d o c u me nt a r u n analisis de
causa y efecto.
Una vez mas, la identificacion de hechos y las tecnicas JRP son cruciales para esta
tarea. Estas tecnicas, asi como el analisis de causa y efecto se enseiian en el sigulente
capitulo.
> Torea 2.3: Analizar los procesos del negocio
Esta tarea es apropiada solo para proyectos de rediseHo de procesos de negocios (BRP) o
proyectos de desarroUo de sistemas que se construyen sobre un significativo rediseno del
proceso de negocios o que requieren de el. En dicho proyecto, al equipo se le pide exa-
minar sus procesos de,negocios en mucho mayor detaUe para medir el valor agregado o
sustraido por cada proceso en lo que se relacione con la organi2aci6n total. El analisis de
procesos de negocios p uede estar influido por la politica. Los propietarios y usuarios del
 Anialisis de sistemas Capitulo Cuatro 123

MATRIZ DE PROBLEMAS, OPORTUNIDADES, OBJETIVOS Y RESTRICCIONES

Siste ma de informacion de servicios a miembros Administrador del proyecto; Sandra Shep he rd

Actualizado la ultima vs z por: Roberto Martmez

Roberto Martinez

Actuafizado por ultima vez el: 31 de enero de 2003

creacl6n: aide enero de 2003
J%4a"'de

ANALISIS DE CAUSA Y EFEGTO OjSJEtlVOS DE WlEJORA DEL SISTEMA

■
■■ ; ■ ■

Tt-,'- V
.roblerna
%pfunici�d i Causas y efectos ObjetivQ del sistema Restriccion de sistema

itiempo de respuesta La entrada de pedidos ha aume nta- Disminuir el tiempo requerido 1, No habra un a ume nto en la
do al tiempo q ue el niimero de para procesar un- solo pedido fuerza de trabajo de
emp leados de pedidos ha disminui- en 30 por ciento. proceso de pedidos.
do. El tiempo pa ra procesar un solo Eliminar la entrada de datos en 2. Cualquier siste ma desarro-
pedido SG mantiene relativamente el tablero en 50 por ciento para llado de be ser compatible
constante. todos los pedidos. con e! esta nda r de
El sistema es demasiado dependiente escritorio Windows 95
Para los pedidos pendlentes,
del teclado. Muchos de los mismos existente.
. reducir en lo posible los golpes
valores tlenen clave para la mayoria El nuevo siste ma de be ser
de teclado al reemplazarios por
de los pectidos. H resultado neto toma
objetos de sena la r y dar d ie en compatible con el sistema
en cuenta {con ei sistema actual) que
la pantalla de despliegue de la de identificacion automatico
cada pedido toma mf e tiempo del
computadora. ya aprobado (para el codigo
requerido para procesarse. de barras).
Mover la edicion de datos de
La edicion de datos e s p ro cesa da
una computadora'compartida al
por una AS/400. Mientras e s a escritorlo.
computadora va saturando su
capacidad, las res p uest as de Ree mp laza r las tarjetas
edici6n de pedidos s e van retrasan- perforadas existentes con un
do. Mientras los e mp leados tratan sistema de comunicacion entre
d e trabajar ma s rapido para los seivicios proporoionados y
ma nte ners e al paso con el volumen el almacen.
de pedidos, el nijmero de errores
aumenta.
El almacena miento de tarjetas
perforadas nunca fue diseliado para
maximizar la eficiencia de la
satisfaccion de orde nes (pedidos).
Cuando crecieron las operaciones
del almacen, los retrasos en cuanto
al llenado de pedidos fueron
inevitables.

�12 M�estra de analisis de causa y efecto

m

igiiil puedfn volverse muy defensives acerca de sus procesos de negocios

J-os analistas que participan deben mantener el enfoque en los procesos y no
los realizan y recordar de manera constante a todos que la meta es
�ftpt»6rtuiiidades para un cambio de negocios fundamental que beneficiara al ne-
�to'dos.lo que estan dentro de el,
analistas de sistemas o de negocios facilitan la tarea, De manera ideal, los
deben ser experiraentados, capacitados o certificados en los nietodos BPR, Los
��Bfeipatees ie st an t e s deben ser propietarios y usuaeios de sistemas. El analisis de
ncg<jciqs debe evitar cualquier lentacion de enfocarse en soluciones de tecno-
124 Parte Dos
objetivo Una medicion del
exito. Es algo que se espera
lograr, si se tienen recursos
suficientes,
■festriccion Algo que limita
la flexibilidad en la definici6n
da una solucion segun los
objetivos que se tengan. En lo
esencial, es imposible modifi-
car las restricciones.
Metodos de analisis de sistemos
login de informacion hasta mucho despiies de que ios procesos de negocios ha n sido rediJ
seiiados para una maxima eficienda. Algunos analistas ejticuentran util asumir ia existericiai
de "personas perfectas" y "tecnologia perfecta" que pueda hacer "posible" cualquier cosap
Preguntan, "si el mundo ftiera perfecto, inecesitariamos ese proceso?"
Como se describe en la figura 4.10, una tarea de analisis de proceso de negocios;!
dep ende solo de cierto conocimiento' del dominio d e l problema (de la tarea 2.1). Los pro.;-:
ductos de esta tarea son m od elos de p roc es os y an alisis d e p rocesos "tal como son" dei;
negocio. Los modelos de proceso pueden parecerse mucho a diagramas de flujo de datos-'
(figura 4.2) excepto que se escriben en forma caracterlstica para mostrar 1) el volumeti i
de flujo de datos a traves de los procesos, 2) los tiempos de respuesta de cada proceso '
y 3) cualquier retraso o cuello de botella que ocurre en el sistema. Los datos del analisis«
de proceso proporcionan informacion adicional tal como d) el costo de cada proceso, &)
el valor a�egado de cada proceso y c) las consecuencias de eliminar u orientar el pro�
ceso. Con base en los rnodelos "tal como son" y sus analisis, el equipo desarrolla modelos
"como seran" que redisefian los procesos de negocios para eliminar la redundancia y la
burocracia e incrementar la eficiencia y el servicio.
Diversas tecnicas son aplicables a esta tarea. Una vez mas, las t�cnicas de identifi--
cacioti de hechos y las reuniones del equipo (capitulo 5) son muy utiles. Tambien, las
tecnicas de elaboracion de modelos de procesos (capitulo 8) son critkas para el exito
del BPR.
> Tarea 2.4: Establecer objetivos de mejora del sistema
Dada nuestra coraprensi6n del alcance del sistema actual, los problemas y oportunidades,
ahora p odemos establecer los objetivos de mejora del sistema. El prop6sito de esta tarea
es establecer el criterio en contra del cual cualquier mejora al sistema sera medida y para
identificar cualquier restriccion que pueda limitar la flexibilidad en lograr esas mejoras. El
criterio para el exito debe ser medido en terminos de objetivos. Los objetivos represen-
tan el primer intento por establecer expectativas para cualquier sistema nuevo. Ademas
de identificar objetivos, debemos tambien identificar cualquier restriccion conocida. Las
restricciones colocan limitaciones o delimitaciones para lograr los objetivos. Los venci-
mientos, objetivos y tecnologias requeridas son ejemplos de restricciones.
Los ANALISTAS DE SISTEMAS facilitan esta tarea. Otros participantes incliiyen a los
mi s mos PROPIETAHIOS DE SISTEMAS y usuARios que h a n participado en otras tareas en
esta fase de analisis de problemas. Nuevamente, no estamos aiin p r eoc up a dos p or la
tecnologia; p or tanto, los d ise n ad o re s y los constructores d e sistemas no participan en
esta tarea.
Esta tarea es disparada p or el anAjusis de problemas completado en las tareas 2.2 y 2.3.
Para cada problema verificado y significativo, los analistas y los usuarios deb en definir
OBJETIVOS DE MEJORA DE SISTEMAS espccificos. Deben tambien identificar cualquier RESnucaON
que pueda limitarlos o evitar que logren los objetivos de mejora del sistema.
Los objetivos de mejora del sister&a deben ser definiciones precisas y medibles del
desempeiio del negocio que definan las expectativas del nuevo sistema. Algunos ejem¬
plos son:
Reducir el numero de cuentas incobrables de clientes en 50 por ciento dentro del
siguiente afio.
Aumentar en 25 p or ciento el numero de solicitudes de prestamo que p ueden ser pro-
cesadas en u n t u mo de ocho horas.
Disminuir en 50 por ciento el tiempo requerido para reprogramar un lote de produc-
cion cuando una estacion de trabajo tiene un mal funcionamiento.
Lo siguiente es un ejempio de un mal objetivo;
Crear u n informe de cuentas morosas.
Este es un mal objetivo porque afirma solo u n requerimiento y no u n objetivo real.
Ahora vamos a replantear ese objetivo:
Reducir perdidas de credito en 20 por ciento a traves de la identificacion temprana de
cuentas morosas.
 Analisis de sistemos

r Jibs brinda una mayor fiexibilidad. Si, el informe de cuentas morosas funcionaria.
vniL investigacion de la morosidad de un diente podri'a proporcionar una forma to-
fl��a 'mejor de lograr el mismo objetivo.
M�®iLos objetivos de mejora de sistemas pueden ser acotados por restxicciones identifi-
cIRcs- Las restricdones caen dentro de cuatro categorias, como se listan a continuacion
ejemplos);
fe ! ; :
-i I Programa: El nuevo sistema debe ser operativo para el 15 de abril.
Costo: El nuevo sistema no puede costar mas de 350 000 dolares.
Tecnologla- El nuevo sistema debe estar en linea o todos los nuevos sistemas deben
'SL.utilizar el sistema de administracion de base de datos DB2.
''�f�.Polttica-. El nuevo sistema debe utilizar tecnicas de inventario de doble dedinadon
balance.

�Itimas dbs.columnas de la figura 4.12 documentan los objetivos y restricdones dc

|Bra de un sistema tipico.
2.5: Actualizar o refinar el plan del proyecto
�jferde que el alcance del proyecto es un objetivo movil. Con base en nuestro programa
.�ilt'esupuesto base de la fase de definicion de alcance, el alcance puede haber crecido o
rhsniiniiido en tamano y complejidad. (jEl crecimiento es mucho mas comun!) Ahora que
®��fo��aproxjraamos a la terminacion de la fase del analisis del problema, debemos reevaluar
�iitcince del proyecto y, en consecuencia, actualizar o refinar el plan de proyecto.
administrador del proyecto, en conjunto con los prop iet arios del sistema y el
completo del proyecto, facilitan esta tarea. Los an al ist as del sistema y los pro-
SfejAlibs DEL SISTEMA son los individuos fundamentales en esta tarea. Los analistas y los
�ropietarios deben considerar la posibilidad de que no todos los objetivos pueden ser
Vlfsffdibs por el nuevo sistema. iPor que? El nuevo sistema puede ser mas grande de lo
"sp�fadp y puede requerirse reducir el alcance para cumplir con una fecha Hmite. En este
5.�asd;pl propietario del sistema clasiiicara los objetivos en orden de importancia. Luego,
-?i�T?alcance debe ser reducido, los objetivos de mayor prioridad le diran al analista que
O'o'mas importante.
Como se muestra en la figura 4,10, esta tarea se dispara como resultado de la defi-
igLon de los objettvos de mejora d e l sistema. El plan d e p ro y e c t o inicial es otra entrada
idamental y el plan de p ro ye ct o ACTUALIZADO es la salida principal. El plan actualizado
��ahora incluir un plan detallado que se debe seguir en la fase de analisis de requeri-
�
pi tos
�Tarea 2.6: Comunicar resultados y propuestas
que con la fase de definicion de alcance, la fase de analisis de problema concluye
_;»itsuna tarea de comunicacion. Debemos comunicar resultados y propuestas a la comu-
T�d:del negocio! Otra reunion en la que los participantes deben induir al equipo del
�ecto completo, induyendo propietarios, usuarios, analist as, disen adores y c on st r u c -
'■c®s 0E SISTEMAS asiguados. Y, como siempre, la reunion debe estar abierta a cualquier
m|leado interesado que forme parte de la comunidad del negocio. Tambien, si se esta-
�ecjo un sitio web en la intranet para el proyecto, debe haberse mantenido a lo largo de
pfase de analisis del problema para asegurar la comunicacion continua del progreso del
s p�wyecto.
jrsEsta tarea se dispara por la terminacion del PLAN del p ro ye ct o ACXUAnzADO. Las entra-
"SJas��de informacion incluyen los anAlisis
de problemas, cualquier m od e l o d e sistemas, los
'�sPBjmvos DE mejora de sistemas, el principal producto de la fase de analisis de problemas.
H fefmato puede ser un informe, una presentadon verbal o una inspeccion por un audi-
grupo de companeros (llamado gnipo de revision). En la figura 4.13 se muestra un
§lquema de.un informe escrito.
..jl�las habilidades interpersonales y de comunicaciones son basicas para esta tarea, Los
J�aKs'tas de sistemas deben tener la capaddad de escribir un informe de negocios formal
5'de hacer una presentadon de negocios sin entrar en temas o alternativas tecnicas.

9t�\del R,T.t Las .tecnicas y los pasos para mejorar el plan de proyecto se ensenan en el PMBOK del PMI.
126 Parte Dos Metodos de analisis de sistemas

FiGURA 4.1 3 Fsquema para objetivos de niejora de sistemas e info.rme

derecomcndaciones .
Analtsis del sistema -actOd!

!. Resumen.ejecutivo (aprpximadqniehte,dps pagirids)

Ay ■Resurneri.de recomehdacion v\::
B. Resumen de problemas; oportiiniciodos y directrices . .
- . G, Breve definici6nde;ob|etivos dc me|ora de sisiemas .: .
D. cxplicacion breve de contenidos de informos' \�
i!. Infofmacion de antecedenfes (aproxirncdamente dos paginas)
A. Liila de entrovjstos y facilitacion* de reuniones de grupo reali'-Jados . '
'y &. lista de olra�i fueiilcs de inforrr.acion qii# fueroti explotodas 7't-'yi' - J-" i'
. C,; Descripcion de tecnicas analfficas uhlizadas ■. ■, ■ •:•..••• . .
III.' Pcnorcima del s'sternci cidual joproximadarneiite cinco pdgincjs)
A. Inspiicacioncs estrategicds |5i ei proyecifo es. porte de o Jmpacta un plan eslrategico
de sistemas d e informacion exis;ente(
;t:v; \Bw��del9s d�Ui5temd'acty0l ../�/�:y�:-;;���!X
i , 1.. , Modeio de intei Faz [muesha c! alcance del proyecto) ■ > , . •:
' 'v:
V�;S -: 2. Modeio de datqs jiriuisstrd el olcance del proyecto) . ,
3. AAodelos gosgrcificos (mucslra el alcdrice del proyecto) �j �
■ 'l- Modeio dc
: prcceso .(muettra >,6lo !n desCoinposicioh.furidonnl) ,....
'■
lY-' Analisis.del.sistema actual [aproximadoriiente 5v)0 paginas) v v' ;-. Ci V.
J A:: Problemas He desempeno, oportunidades y analisis causa-efccto ■ •. a-;
B. Problennqs de inlonnucion, oportunidades y d'nalisis cdusa-efecto
C.' Problemos economlcos, oportunidades y analisis causa-efecto , . / :
. D. Probleriids do control, oportunidades. ypriiliiis cciusa-efecto ■
t." Problsinbs do eficiencia/oportunidcidesy bnalisis ccusp-�fectp ■ ./ / .v"-
!' :?■ - - F;Problemas de servicio,opCrtunidades y andlisis causa-efecta ■ ■; �
V. ReconendaiSionfis cietalladds'(aproximadamerite 5-10 poginas) ■' ' •' .
:: ; A. Objotivosy prioridodes de mejoro de sistemas .: ■ ■' \

CW Plan de prpyectQ'.jXi�-j'i-'S��v;�"
■1. Rocvaluocion y rofinomiento del alcance
■ • ; • ■ ■' ' ■
; . 2. Plan niaosiro revisqdo . ■ .
. 3. Plan detaibdo pard Id tase de definlclon ■' ' ;

. VI. Apandicos,-- . , 'V-:; W: -'il'

A. Cuaicjgier modeio de sUtema detallado.;. . \ - � � ;/ ■:Vi\;:r;.V-
B Otros documentos segon resiilte oproprado v

Esto concluye la fase del anSlisis del prbblema. Una de las siguientes decisiones debe
realizaxse luego de la conclusion de esta fase:

• Autorizar que el proyecto continue, tal como esta, a la fase de analisis de requeri-
mientos,
• Ajustar el alcance, costo o programa para el proyecto y luego continuar con la fase
de analisis de requerimientos.
• Cancelar el proyecto debido a; 1) falta de recursos para continuar el desarrollo del
sistema, 2) darse cuenta de que los problemas y oportunidades simplemente no eran
tan importantes como se habia anticipado, o 3) comprension de que no es probable
que los beneficios del nuevo sistema excedan los costos.
Con cierto nivel de aprobacion per parte de los pkopieiabios d e l sistema, el proyecto puede
ahora continuar hacia la fase de analisis de requerimientos.
 Andlisis de sistemas Capitulo Cuatro 1 27

de anaiisis de requerimientos
jHuchos analistas inexpertos cometen un error critico luego de completar la fase de ana¬
lysis del problema. La tentacion en ese punto es comenzar a considerar alternativas de
iolucion, particularmente tecnicas, Uno de los errores citados con niayor frecuencia en los
nuevos sistemas de inforraacion se ilustra en la frase "segurO; el sistema fundona y tecni-
-cain ent e es impresionante, pero no hace lo que nosotros necesitamos". La fase de andlisis
requerimientos define los requerimientos de negocios para un sistema nuevo.
�Noto la palabra clave en la oracion citada? es "que" jy no "como"! Los analistas con.
frcKiiencla estan tan preocupados per la soludon tecnica que inadecuadainente definen
l3S requerimientos de negocios para esa solucion. La fase de anaiisis de requerimientos
—
lesponde la pregunta, ";Oue necesitan y desean los usuarios de un sistema nuevo?
la fase de anMisis de requerimientos es critica para el exito de cualquier sistema
iiiievo de informacion. En distintas metodologias la fase de anaiisis de requerimientos
� ser Ilamada fase de definicidn o fase de diseno logico.
�Se puede alguna vez pasar per alto la fase de anaiisis de requerimientos? iDefiniti-
Wmente no! Los nuevos sistemas siempre seran evaluados, primero y sobre todoj acerca
de si cumplen o no con los objetivos y requerimientos del negocio, jsin importar que tan
iinpresionante o compleja pueda ser la solucion tecnica!
DeLie reconocerse que algunas metodologias integran las fases de anaiisis del pro-
„' blema y anaiisis de requerimientos en una sola fase.
Una vez mas, sus componentes de sistemas de informacion (figura 4.14) pueden servir
(.oino un marco de referencia utll para documentar los requerimientos de sistemas de infor-
niacjon. Notese que seguimos ocupados con las perspectivas de los USUAWOS del sistema. Los
�Iguferimientbs pueden ser definidos en t�rminos del marco laboral PIECES o en terminos
�jieilos tipos de datos, procesos e interfaces que deben ser incluidos en el misrao.
- ■ ' En la figura 4.15 se ilustran las tareas tipicas de la fase de anaiisis de requerimientos.
|S;|5roducto y la meta a alcanzar de la fase final permitiran crear una definicion de los
: p��RMiENTOs DEL NEGOCIO que satisfaga los objetivos de mejora del sistema identificados
=®jl� fase anterior. Una de las primeras cosas que puede notar en este diagrama de tareas
i ||||u e la mayoria de las tareas no se dan en forma secuencial como las de los diagramas
ffle'tareas anteriores. En lugar de eso, muchas de estas tareas ocurren en paralelo mientras
|el?equipo trabaja hacia la meta de completar la definicion de requerimientos. La fase de
anaiisis de requerimientos generalmente incluye las siguientes tareas:
,
i 1 Tdentificar y expresar los requerimientos del sistema.
2, Pnorizar los requerimientos de sistema.

Actualizar o refmar el plan de proyecto,

Comunicar la definicion de requerimientos,

I�Qra'analicemos cada una de estas tareas con mayor detalle.

■
Mi-'.

Wi-
?� Tarea 3.1: Identificar y expre sar los requerimientos del sistema
J !.1,1area inicial de la fase de anaiisis de requerimientos es identificary expresar requeri-
Bjjerafos. Mientras que esto puede parecer como una tarea facil o trivial, a menudo es la
�ente de muchos errores, omisiones y conflictos. La base para esta tarea se establecio
la fase de anaiisis del problema cuando identiflcamos objetivos de mejora de sistemas. En
Jofma rnlnima, esta tarea traduce estos objetivos en im esquema de requerim ien to s funcio- requerimiento ftmcional
Descripcion de las activida-
SJ�s.y no fimcitmales que se neqesitaian para�mplir-con-los-objetivos. Los�reqijerifflien- des y servicios que debe brin-
pfTfi�oonales son frecuejiteflient.e4den�cados,,gn.temiinos.de,_eattadas.r.saUd� dar un sistema.
��GroslSGn�acenados que son necesarios para satisfacer los objetivos de mejora del sistema.
iiifeplos de requerimientos no funcionales incluyen desempeno (tiempo de desempeno y
pe respuesta); facilidad de aprendizaje y uso; presupuestos, costos y ahorros de costos; cro-
feogramas y vencimientos; documentacion y necesidades de capacitacion; administracion de requerimiento no fun-
cional Descripcion de otras
da caHdad y controles de auditoria interna y seguridad.
oaractaristicas y restricciones
Rara vez esta tarea de definicion identifica todos los requerimientos de negocios fun- que definen un sistema satis-
toTiales y no funcionales. Pero este esquema emnarcara su pensamiento mientras procede factorio.
tareas posteriores que agregaran nuevos requerimientos y detalles al mismo. Por
to, ni la totalidad ni la perfeccion son una meta en esta tarea.
128 Parte Dos Metodos de andlisis de sistemas

A
P \
R
DEFINlClbN DE R E Q U E RI M 1 E N T O S DE NEGOCIOS
O
P
REOUERIMIENTOS REQUERIMIENTOS REOUERIMIENTOS
U
DE DATOS DE PROCESO DEINTERFAZ DE
EDE NEGOCJOS DENEGOCiOS NEGOCIOSY
S DE SISTEMAS
T MODELOS MODELOS MODELOS
A LOGJCOS LOGICOS LOGICOS

V
DE DATOS DE PROCESO DE INTERFAZ

D
E
Si ST E Nl AS (o SOLICIT UD DE PROPUESTA DE S IS T E M A S)

APLICAO16N DE ARQUITECTURA

PHOTOTIPOS DE DISENO

[XSENO

Reslriccion: Restriccidn: Restriccidn:

TECNOLOGiAS tscnologIas TECWOLOGIAS
DE BASES Oe DE PBOCESO DE INTERFAZ
DATOS APRODADAS APROBADAS APROBADAS

Resln'ccion:TECNOLOGIAS DEFIED APROBADAS

ss m
O Z. TTl �
oo O z
n >

ESPECJFICACIONES DE PROCESO ESPECIFICACIONES O3,

DE DiSEfiO DE NEGOCIOS DE DISENO FISICO Oq
FISICO DE LA DE INTERFAZ DC
ESPECIFICACIONES USOAWO Y
BASE D£ DATOS
DEDiSENO DE SISTEMAS
FiSICO DE SOFTWARE

� V>
SISTEMA FUNCIONAL MATERIALES DE CAPAC1TAC|6n
C 3}
m c
o o
> o
PAQUETES SOLUCIONES ®o.
DE SOFTWARE DEINTERFA2
SOLUCION COMEHCiAL DE u s u Ani o
DE BASE
DE DATOS sorrwAHE SOLUCIONES A
DE APLiOACldN DE INTERFAZ
A LA MEDIDA DE SISTEMAS

SISTEMA OPERATIVO REVISION POSTERIOR A LA AUOITORIA

FIGURA 4.14 Contexto de la fase de analisis de requerimientos del an�lisis de sistemas

�

H �

Arquitectura tecnologica de intormacion eslr ategioa empr esar ial

 Andlisis de sistemas Capitulo Cuatro 129

Jtii CoMUNioad de negocios

FI6URA 4.15
:Taife$S; V;
fase do analisis do i
(aprobacion para
continuar el proyecto xequ&iirufen�
de la fase de analisis /analisis dfe: sisteirias :'
de problemas)

1
DE SISTEMAS
��qpflrARiOSY USUARtOS

definicion d e Esquema
de requerEmi&nto$
�REQUERIMIENTOS □bjetivos do majora luncionales
DE NEGOCIOS de etstemas, reqyenmtentos y no

1
funciorsales y no funcionales funcionales

requenmientos m requerimientos
y pnofldades ~ —: vaiidados con - . Priorizarlcs
finales prroridades requerimientos
Dcpo ito delsistema

p!an de!
proyscto

Requerimientos

�
Plan fevisado eompletado I Actuatizar
y pfioridades
completados
J
orefinar
el plarr del
.proyecto

T.OS ANALISTAS DEL s isT E M A facilitan la tarea. Tambien d oc u me n t a n los resultados.

'ideTiiftnente, los u su a ri o s del sistema son la fuente principal de los requerimientos
'"��gpcios. Algunos p rop i et ar ios del sistema p u e d e n elegir participar en esta tarea ya
que tLivieron un papel e n la estructuracion de los objetivos de mejora del sistema que
pran i a tarea. Los d is en ad o re s y constructores d e sistemas no deb en participar por-
ifetienden a redirigir pr ema t ura ment e el enf oque a la tecnologia y a las soluciones
■ Kicas.
■ I i- " ■
:■ se muestra en la figura 4.15, esta tarea (y fase) se dispara cuando se tiene
'��obaciGn para c o n t i n u a r el p r o y e c t o dura nt e la f ase de analisis d e l problema. La
'|f�da: fundamental son los ob jet ivos de mejora del sistema definidos desde la fase de
alisis del problema (via repositorio), Desde luego, toda la informacion relevante ob- ca$o d e u s o Escenario de
ifla, durante la fase de analisis de problemas esta disponible para su r ef er enda segun negocios o evento respecto
a rt-querido. del cual el sistema debe
''ti-El linico producto a obtener en esta tarea son los requerimient os eun cion ales y n o proporcionar una respuesta
definida. Los casos de uso
cionales. Diversos formatos p ueden funcionar. En su formate mas simple, el esquema
evolucionaron a parti r del
ede set dividido en cuatro secciones logicas; la lista original de los objetivos de mejora
analisis orientado a objetos;
sistemas, una sublista de a) entradas, b) procesos, c) salidas y d) datos almacenados pero su utilizacion se ha vuelto
-r�satios para satisfacer el objetivo. Sin embargo, cada vez mas, los analistas de sistemas comun en muchos otros me-
teian requerimientos funcionales mediante una herramienta de elaboracion de mode- todos de andlisis y disefio de
' llamada casos de use. Los casos de uso elaboran modelos de escenarios de negocios sistemas.
130 Parfe Dos
timehoxing TScnica que
entrega funclonalidad y re-
querimiBntoE de sistemas de
informacion mediante si con¬
trol de versiones. El equipo
de desarrollo selecciona ei
subconjunto mas pequeno
del sistema que al ser puesto
en prSctica por completo ge¬
nera valor inmedlato para ios
propietarios y usuarlos del sis¬
tema. Se desarrolla ese sub¬
conjunto, de preferencia en
seis a nueve meses o menos,
En forma subsiguiente, se de-
sarrollan versiones del sistema
con valor anadido, en marcos
cronol6gicos similares.
Metodos de andlisis de sis�emas
y sucesos que deben ser manejados por iin sistema nuevo. Se presentan en el capiUilo G \
se utilizan a lo largo de este texto.
El marco de referenda PIECES que fiie utilizado anteriormente para identificar pro-
blemas, oportunidades y restricciones tambien puede utilizarse como marco laboral p in
definir los requerimientos del borrador,
Diversas tecnicas son aplicables a esta tarea. La planeacion de requerimientos con-
juntos (joint requirements plarming, JRP) es la tunica preferida para delinear con rapide�.
los requerimientos del negocio. De manera alternativa, los analistas podrian utUizar otros
metodos de identificacion de hechos como encuestas y entrevistas. Tanto el JRP como la'
identificacion de hechos se ensenan en el siguiente capitulo.
> Tarea 3.2: Priorizar los requerimientos del sistema
Anteriormente comentamos que el exito de un proyecto de desarrollo de sistemas puede ■
ser medido en terminos del grado en el que se satisfacen los requerimientos del negocio
Pero no todos los requerimientos se crean igual. Si un proyecto se retrasa en horario o so-%
bre el presupuesto, puede ser util para reconocer que requerimientos son mas importantes
que otros. For tanto� dados los requerimientos validados, los propietarios del sistema y los j
usuarlos del sistema deben pr ioriz ar los requerimientos del sistema. i
■
Otorgar prioridades a los requerimientos puede facilitarse por medio de una tecnica
popular llamada t i me box i ng. El timehoxing intenta dividir requerimientos en "partes" >
que puedan ser implementadas dentro de un periodo que no acabe con la paciencia del
usuario y de la comunidad administrativa. El timeboxing obliga a que las prioridades sean
.definidas claramente.
Los ANALISTAS DE SISTEMAS facilitan la tarea de clasificacion de prioridades. Los pro-
piETAEios y us uAKios DEI SISTEMA establccen las prioridades actuales. Los diseiSadores y los
CCNSTRUCTORES de sistemas no participan en la tarea. La tarea es realizada cuando los
requerimientos son validai>os. Debe resultar evidente que usted no pueda otorgar priori¬
dades adecuadamente a un conjunto de requerimientos incompleto. El producto de esta
tarea es obtener requeejmientos con peiomdades. Las prioridades pueden ser clasificadas dc
acuerdo con su importancia relativa:
• Un requerimiento obligaiorio es aquel que debe ser satisfecho por la minima version
del sistema (version 1.0.) El sistema es inutil sin el, iTenga cuidado!, existe la tenta-
cion de etiquetar demasiados requerimientos como obligatorios. Un requerimiento
obligatorio no puede ser clasificado porque es esencial para cualquier solucion. De
hecho, si un requerimiento obligatorio puede ser clasificado en orden de importan¬
cia, en realidad es un requerimiento deseable.
• Un requerimiento deseahk es aquel que no es absolutamente esencial a la version
minima del sistema (version 1.0). Puede aun ser esencial para la vision de alguna
version futura. Los requerimientos deseables pueden y deben ser clasificados. El use
de numeros de version como esquema de clasificacion es una forma eficaz de comu-
nicar y categorizar los requerimientos deseables.
> Tarea 3.3: Actualizar o refinar el plan del proyecto
Nuevamente, recordemos que el alcance del proyecto es un objetivo movil. Ahora que he-
mos identificado los requerimientos del sistema, debemos regresar y redefinir nuestra com-
prension del alcance del proyecto y actualizar en consecuencia nuestro plan de proyecto. El
equipo debe considerar la posibilidad de que el nuevo sistema pueda ser mas grande de
lo originalmente esperado. Si es asf, en consecuencia, el equipo debe ajustar el programa,
presupuesto o alcance. Debemos tambien asegurar la aprobacion para que el proyecto
continue hacia la siguiente fase. (Puede que el trabajo ya se haya iniciado en las fases de
diseiio; sin embargo, las decisiones todavia requieren una revision.)
El administrador del proyecto, en conjunto con los propietarios del sistema y el equipo
de proyecto completo, facilitan esta tarea. Como siempre, el administrador del proyecto
y los propietarios d el sistema son los individuos clave en esta tarea. Deben considerar la
posibilidad de que los requerimientos ahora excedan la vision original que se establecio
para el proyecto y el nuevo sistema. Pueden tener que reducir el alcance para cumplir con
un vencimiento o incrementar el presupuesto para que el trabajo se realice.
Como se muestra en la figura 4.15, esta tarea se realiza cuando los requemmientos son
pmohizados y completados. El plan d el proyecto. actualizado es la otra entrada clave y se
actualiza en el repositorio cuando se considere apropiado.
 Anaiisis de sistemas Capitulo Cuatro 131

J, Tarea 3.4: Comunicar la definicion de requerimientos

tom'iiii(.arion es una tarea continua de la fase de anilisis de requerimientos. A lo largo
"de U debemos comunicar requerimientos y prioridades para la comunidad de nego-
cios I usii-ii lOb y administradores con frecuencia abogaran per una consideracion de
v prioridades. La comunicacion es el proceso a traves del cual se deben
retiuentnieritos
i difetLiicias de opinion. El administrador del proyecto y el patrocinador ejecutivo
jjicdur las
deben facilitar esta tarea. Actualmente, una intranet o un portal de proyecto
conjuntamente
Lon frecuencia para comunicar Ids requerimientos. Algunos sistemas permiten
J los ubuanob v administradores acceder a ios documentos de requerimientos para asegu-
de Ser notificados conforme ocurran los cambios. Las habilidades interpeisonales, de
�fojnurucation > negociacion son esenciales para esta tarea.

fjl�anejo de requerimientos p e r ma n e n t es
Cl-afase de analisis de requerimientos esta ahora completa.�O no? �guna vez fue popular
del negocio antes de empezar las fases de disefio de sistemas
'i��rongelar los lequerimientos
''1 'y fas de const!uccion. Pero la economia actual se ha vuelto cada vez mas acelerada. Los
f�egocios se miden de acuerdo con su capacidad para adaptarse con rapidez a requeri-
timientos y oportunidades constantemente cambiantes. Los sistemas de informacion no
,Upue< ser menos cambiantes que el negocio mismo. Por tanto, el analisis de requeri-
ijnifntos leahiiente nunca termina. Mientras que hacemos una transicion sUenciosa hacia
de nuestro proyecto, continiia una necesidad constante de mane jar
Jas' fasfes jestantes
h
iw-li.VctiucpmicntO'i a ti'aves del curso del proyecto y la vida del sistema.
4lEl-�rtiane)o de ios requerimientos define un proceso para los propietarios, usuarios,
s. ctiseiiadores y constructores del sistema para enviar los cambios propuestos a los
eSniientos de un sistema. El proceso especifico como se deben solicitar y documentar
:ambio.si como se registraran y rastrearan y cuando y como se evaluarSn para saber su
�ilt�idad V la forma en que eventualmente seran satisfechos (si alguna vez sucede).

iFase de diseno logico

Ko todos los prbyectos aceptan el desarrollo basado en modelos, pero la mayoria incluye
ppco tic elaboracion de modelos de sistemas. TJn diseno logico documenta mas aun
A'requerimientos de negocios por medio de los modelos de sistemas que ilustran las es-
.iciuras de dates, procesos de negocios, flujos de datos e interfaces de usuarios (cada vez
por medio de modelos de objetos, como se presento anteriormente en el capitulo). En
ti|§�tido,7ralidan los requerimientos establecidos en la fase anterior.
"JiljUiia vez mas, los componentes de sus sistemas de informacion (figura 4,l6) pueden
un marco litil para documentar los requerimientos de sistemas de informacion.
�Korno
e�: qiie todavia estamos ocupados por las perspectivas de los usuarios del sistema. En
Rise,pelalx)ramos diverscs modelos de sistemas para documentar los requerimientos
isisteriia riuevo y mejorado. Los modelos describen diversos aspectos de nuestros
|�;�neiites. pe manera altemativa, los prototipos podrian ser construidos para "identifi-
p�fterii� Los prototipos de identificacion fueron presentados anteriormente en
ftiio! Recuerde que a algunos prototipos se les puede aplicar una ingenierfa inversa
�oiirertiirios en modelos de sistemas.
-n la"figura 4.17 se ilustran las tareas tipicas de la fase de diseno logico. El producto y
fase final es producir una definicion de eeqijerimientos del negocio que satisfa-
Sbjetivos de mejora de sistemas identificados en la fase previa. Una de las primeras
Ip'que usted notara en este diagrama de tareas es que la mayoria de las tareas no son
�.yShcias como en los diagramas de tareas anteriores. En lugar de esc, muchas de estas
�r�as oturren en paralelo mientras el equipo trabaja hacia la meta de completar la defini-
de .requerimientos.
fase de diseno logico generalmente incluye las siguientes tareas:

ES���eriinientos funcionales de estructura

S'����uerimientos funcionales del prototipo
��■alklar requeriniientos funcionales
casos de prueba de aceptacion
iSi!'»,\aualiccmos cada una de estas tareas con mayor detalle.
132 P a r t e Dos Metodos de analisis de s i s f e m a s

Restrioclin: Restiiccldn:
TECNOLOGfAS TECNOLOGfAS TECNOLOGIAS
DH BASES DE DEPROCESO DE INTERFAZ
DATOS APROBADAS APROBADAS APROBADAS

Restricxaon; TECNOLOG/AS DE RED APROBADAS

Arquitectura tecnol6gica de informacion estrategica empresarial

4,16 Contexto de la fase de diseno logico del analisis de sistemas

 Analisis de �is�emas Capitulo Cuatro 133

NEGOCIOS
%>LA COMUNiDADillDE•"■■ I FfGURA 4.17
Cada requerimiento
funcional Tareas l&fas& v;
dtr c3 iseno lo�cn del
iuuilisis de .sisteirias..:

Y .US'JAf''"® SISTEMA
�pIp�S,

�''' Modelos
',
f ! y prototipos
de sistemns

mcjdelos
Valtdar <j__ y prolotipos de
requerimientos proceso
funcionales de trabajo

�J �
■» . ..4. -

.♦T�i.JIT-.cvf.—»-—!r--i

M Definir
; casos de pnieba
de acepfacidn

I 4.1a: Requerimienfos funcionales de estructura

para el diseno logico es definir los requerimientos funcionales de estructura.
(jiie, por medio de metodos acelerados, usted debe elaborar o actualizar uno
TOdclos de sistemas para ilustrar el requerimiento funcional. Estos pueden induir
�J'lconibinacion de datos, procesos y modelos de objetos que describan con preci-
�goao y ios requerimientos de los usuarios (pero no una solucion tecnica). Los
��plJlistemas no estan completos hasta que todos los requerimientos funcionales
�XiSiiados han sido modelados. Los modelos con frecuencia se complementan con
logicas detalladas que describen los atributos de datos, reglas y politicas
�|i,uos.
I��.ajialistas de sistemas faciUtan la tarea. Ellos tambien documentan los resultados. Evi-
|JSWl<-,.Ios nsuAEios DE SISTEMAS son la fuente primaria de detaUes de hechos necesarios
�borar los modelos. Como se muestra en la figura 4.17, esta tarea (y fase) es realizada
"���QUerimientc f u n c i o n a l . Las saUdas son los modelos del sistemas y
ESPEOFicAaoNES

��s.reales. El nivel de detalle requerido depende de la metodologia que se sigue.

:�Odds»acelerados generalmente requieren de documentacion "unicamente esencial".
te�csencial? Eso es discutible, pero los expertos habiles en metodos sostienen que
��ticto sera esencial para las siguientes fases de diseno y programacion. En este
�ft�nara una diversidad de herramientas y t6cnicas de elaboracion de modelos
ffl��ra'aplicarse a un diseno idgico.
134 Parte Dos Metodos de ana!isis de sistemas

> Tcirea 4.1 b: Requerimientos funcionales

del prototipo (alternativa)
La elaboracion de prototipos es una alternativa Cy a veces un requerimiento previo) para Ig
elaboracidn de sistemas. Algunas veces los usuarios tienen dificultad para expresar los'
hechos necesarios para elaborar los modelos de sistemas adecuados. En tal caso, una al •
temativa o un enfoque complementario a la elaboraci6n de modelos de sistemas es cons
truir prototipos de identificacion. La elaboracion de prototipos normalmente se utiliza en
la fase de analisis de requerimientos para constniir entradas y salidas de ejemplos. Estas ■
entradas y salidas ayudan a construir la base de datos y los programas para introducir y
generar datos hacia y desde la base de datos. Aunque la elaboracion del prototipo es op
cional, frecuentemente se aplica a los proyectos de desarrollo de sistemas, en especial en
cases donde los usuarios tengan dificultad en comunicar o visualizar sus requerimientos
de negocio. La filosofia del prototipo afirma que los usuarios reconoceran sus requeri
mientos cuando los vean.
Los CONSTRUCTORES DE SISTEMAS fadlltan esta tarea de analisis. Los an alist as Dfi sistemas
documentan y analizan los resultados. Como siempre, los usuarios de siste.mas son la fuente
primaria de la entrada de hechos a la tarea. En la figura 4.17 se demuestra que esta ta¬
rea depende de uno o mSs requerimientos fu ncion ales que han side identificados por los
usuarios. Los constructores y los analistas de sistemas responden construyendo prototipos
Como se describio anteriormente en este capitulo, es posible aplicar una ingenierta inversu
a algunos m od el os d e sistemas basandose en los prototipos de las bases de datos y las bi-
bliotecas de programas.

> Tarea 4.2: Validar requerimientos funcionales

Tanto los m od e l os d e sistemas como los p ro t o t i p o s son representaciones de los requeri¬
mientos de los usuarios. Estos deben ser validados para que esten completos y correctos.
Los an alist as d e sistemas facilitan la tarea de asignacion de prioridades al comprometer en
forma interactiva a los usuarios del sistema para la identificacion de errores, omisiones y
aclaraciones.
> Tarea 4.3: Definir casos de prueba de oceptacion
Aunque no es una tarea requerida, la mayoria de los expertos estan de acuerdo en que no
es demasiado adelantado comenzar a planear las pruebas del sistema. Los modelos y los
prototipos de sistemas definen muy eficazmente los requerimientos de proceso, reglas de
datos y reglas de negocios para el nuevo sistema. En consecuencla, estas especificaciones
p ueden ser utilizadas para definir cas os d e prueba que p ueden finalmente ser utilizados
para probar que los programas esten correctos. Tanto los analistas como los con st ru ct ores
DE sistemas pueden desempenar esta tarea y validar los casos de pruebas con los usuamos de
sismiAs.
Recuerde que los objet ivos de mejora de sistemas fueron definidos anteriormente en
el proyecto. Los casos de pruebas pueden ser definidos para probar estos objetivos tam-
bien.

Fase de analisis de decision

Una vez que se tienen los requerimientos del negocio para un sistema de informacion
mejorado, es posible abordar la implementacion tecnologica del nuevo sistema (incluidas
las alternativas basadas en computadora). El proposito de la f a s e de analisis de decision
es identificar las soluciones alternativas, analizarlas y recomendar un sistema objetivo que
sera disenado, construido e implementado. Es muy posible que alguien ya haya detectado
una posible solucion tecnica. Pero las soluciones alternativas, lo que es mejor, casi siempre
existen. Durante la fase de analisis de decision, es necesario que usted identifique opcio-
nes, las analice y luego venda la mejor solucion con base en el analisis.
Una vez mas, los component es de sistemas de informacion (figura 4.18) pueden
servir como un marco de referenda util para la fase de analisis de decision. Una de las
primeras cosas que usted debe notar es que la tecnologia de infoirmacion y la arquitectura
comienzan a influir en las decisiones que debemos tomar. En algunos casos, debemos
trabajar con estandares. En otros casos, p odemos intentar aplicar tecnologia distinta o
 paralal
:sar loli
una al '
's cons;;!
iliza I
s.
Esta|i
■ducir� ••
' es
Op-|
:cial LTi %
niento�
■eqiietii
jISTEMSS
L fuenip
esta ta�j
por loa
roTiposf
inversM
' las bil
136 Parte Dos Metodos de analisis de $i$temas

LA COMUNfDAD DE NEGOOOS
FIOURA 4.1�

I'axe'as p a r a la I'ase de
/ arialisis dedec isi oB ' V-
del aiidlisis de '

en surgimiento, Usted tambien debe notar que las perspectivas (puntos de vista) de los
usiiAKios DEL SISTEMA estan en transicion con respecto a las de los disenadokes d e l sistema. .J
Nuevamente, esto refleja nuestro interes por los negocios o la tecnologia. Pero aun asi, no I
estamos en el diseno, los componentes indican nuestxa meta de desarroUar una propuesta J
que cumpla con todos los requerimientos. i|
En la figura 4.19 se Uustran las tareas tipicas de la fase de anilisis de dedsi6n. El |
producto y meta de la fase final es producir una propu esta del sistema que satisfaga los |
requerimientos de sistemas identificados en la fase previa. La fase de analisis de decision |
normalmente incluye las siguientes tareas: I
5.1 Identificar soluciones alternativas |
5.2 Analizar soluciones alternativas ;|
5.3 Comparar soluciones alternativas !•
5.4 Actualizar el plan del proyecto
5.5 Recomendar una solucion del sistema s

Ahora analicemos con mayor detalle cada una de estas tareas.

> Tarea 5.1: identificar soluciones alternativas

Dados los requerimientos de negocios establecidos en la fase de definicion del analisis de
sistemas, debemos primero identificar las soluciones alternativas. Algunas soluciones alter- :
nativas seran planteadas por las ideas y opiniones de disefio de los propietarios y usuaeioS
DE SISTEMAS. Otras vendran de diversas fuentes incluyendo a los an alist as de sistemas, dise-
 Andlisis de sis te ma s Capitulo Cuolro 137
'
pi'- consultores tecnicos y otros profesionales de sistemas de informacion.
S \.|iOi ■ ■■ DE sistemas,
pueden estar limitadas por una arqmtectura de tecnologia aprobada,
I ' lie I iioida intencion de esta tarea no evaluar las opciones, sino simplemente deflnir
l"'-nobibles alternativas de solucion que se van a considerar.
' , '
' 11 IS AK'i.nsrAS DE SISTEMAS facilitaii esta tarea. Los p eopiet ak ios y usu arios de sistemas
iiinSinente no participan de manera directs en esta tarea, sine que pueden con-
comienzan la tarea, Por ejempIOj un propietario o
fnbuii ton ideas y opiniones que
■' Ju'�tib puedf haber leido un articulo o haber escuchado o sabido de la forma en que
Ci un sistema similar de un conocido o un competidor. En cualquier ease,
"' iniplt'uit'jito
.Uricanient<-" el considerar las ideas. Los d i sen ad o re s y constructores d e
"" administradores de bases de datos, los administradores de redes y los
rviAS i:onio
tecnologia y los programadores tambien son una fuente de ideas y opi-

(1 Sfio "se mostro en la figura 4.19, esta tarea es formalmente realizada cuando se
fnry> IS'�SPROBACION PARA CONTINUAR EL PROYECTO DE LA EASE DE ANAUSIS DE REQUERIMTENTOS.
Vt jlidad,''las ideas y opiniones han sido generadas y capturadas desde la fase de in-
'lij�lpyhpreliminar; es humane sugerir soluciones a lo largo de cualquier proceso de
« p'roblemas. Notese que, ademas de venir del equipo de proyecto mismo, las
iCVRpiSio�s pueden ser generadas de fuentes internas y externas. Cada idea generada
I'mi-jiiiera conio una soiucioN a l t e k n a t w a para los kequekimientos d e l n eg oci o.
catititlad de informacion que describe las caracteristicas de cualquier solucion op-
nl plede resultar abruraadora. Una matriz de alternativas, como la figura 4.20, es una
ilJJY'r iinienta mil para capturar, organizar y comparar eficazmente las caracteristicas de las
Tislinj I ■■ "bpciones de solucion.
j.( Dino ha sido el caso a lo largo de este capitulo, las tecnicas de identificacion de
■tl? iV�' de facilitacion de grupo como JRP son las tecnicas principales utilizadas para
igar soluciones alternativas de sistemas. Las tecnicas de identificacion de hechos y
liWeion de grupo se ensenan en el siguiente capitulo. Asimismo, en el capitulo 9,
;SI.S dc factibilidad y propuesta del sistema", se le enseiiara la forma de generar y
iVtltar las soluciones alternativas de sistemas en la matriz.

larea 5.2: Analizar soluciones alternativas

naliZLirse la factibilidad de cada solucion altemativa de sistemas. Esto puede ocu-
fprme .se identifique cada posible solucion o despues de que todas las soluciones
u&aales
L'.' J• han sido identificadas. Los analisis de factibilidad no deben ser limitados a los
......
beneficios. La mayoria de los analistas evaliian soluciones contra al menos cuatro
if OS de aiterios:
Val tinthdad tecnica. �Es la solucion tecnicamente practica? iNuestro personal tiene
Sgpencia tecnica para disenar y construir esta solucion?
irbihdad qperativa. iLa solucion cumplira con todos los requerimientos de los
yaiioh? iA c�ue grado? iComo cambiara la solucion el ambiente de trabajo. del usua-
�A�Gomo se sienten los usuarios acerca de dicha solucion?
"thilulad economtca. ;La solucion tiene un costo-beneficio?
�ibilulati deprograma. iPuede la solucion ser disenada e implementada dentro
-penodo aceptable?
''completar esta tarea, los analistas y usuarios deben tener cuidado de no hacer
�aciones- entre las diferentes soluciones. El analisis de factibilidad se realiza con
STliicion altemativa sin importar la factibilidad de las demas soluciones. Este enfo-
fes�Uenta al analista y a los usuarios de tomar una decision en forma prematura con
tora:una solucion.
los ANALISTAS DE SISTEMAS facilitan la tarea. Normalmente los prop ietaeios del
USUARIOS, DEL SISTEMA analizan la factibilidad operativa, economica y de pro-
®ps DISENADOEES y CONSTRUCTORES DEL SISTEMA normalmente contribuyen al analisis y
gH!. papel fundamental para analizar la factibilidad tecnica,
�a�figura 4,19 se muestra que la tarea es realizada cuando cada solucion altemativa
i4?:ada;.sih embargo, es aceptable retrasar esta tarea hasta que todas las soluciones
v,siclo idcntificadas. Las opiniones sobre los analisis de factibilidad provienen de
participantes en el equipo; sin embargo, es comiin que los expertos externos (e
138 Parfe Oos Me to do s de analisis dc sist e mas

F1 G,U.RA; .4:.20 Matiizdesoj�udonesalterriativasdfeLsistema�� >

'
Caracteristicas � Solucion Solution Solucion !: 1 Solucion
alternativa 1 dlternativa 2 olternotiva 3 alternativa.;.

Porcion de s i s t e ma compu|oriziado ■
Pqquete COTS Plafinum Plus Servidps y bperadpnes del ! Igud a.b. .V
Breve descripcton de porcion del sistema Cjue send. , ae EntertatnmcjnJ SufvAsre almoccn en relocion con el solucion . s
Solutions se qdqyiririq ' ■
computarizada en esta .soludon alterndtiyo... . llenqdd de pedidbs. ;; alterhativq 2.
serfd peridndlizadb parq „. '
satisfdcer la funcionati.dqd.
rsquenda pam sdtisfqcer;
ios servicios del negocio.

BeneficFOs •••' • Esto sbludon puede ser;. ; - : Respqldd iptajmenteips p� igOdl a la

Brsye descnpd�n de Ips behe�cios de negqctos que se impiementodd de negocios rcquoridos para solucion X • :
iogranan can estd spluci6n atern<ativa. ; . : . porque es cbmprqdq, . SpundStqge jnCi.j Mas ihteracqion/' alterrjatiyd.;?�:- �.;;•
mds eficiencid cpri iqscuehtas d��
negpcio. -. .. , ; ; . .
Se r vi d o r e s y e s t q c i o n e s de trabajo .. La qrquitechjra t�cnlcd' Iguol a la splucipn alternafiva�\. . •. lgucl d1a>
Descripcion de los servidor�sy las estaciones de trabajo: sugiere utilizer un.d � , isoluciori. . .
1
necescrias paro respddar esta solua6n alfern�iHya. compOiddora cori dlternqtfvq
pr�j�odor P(sntium Pro/ .' 'r
servidores de cbs� cori • ' •
'
Ms,Windows NT y CPU L ;
Peritiurn;, estoqipnies de
.trabq]o;c»ri MS�
NT 4.0 (dientes).
�
HeiTarnien�5 de softwpre necesarlas MS.Visual C-H- y MS Access MS Visuai Basic 5.6 MS. Vi�udi
las heTrarnientas de software neceMrids jaard diseficir y para propordonar jei System Architi�t 3J • 50
Internet Explorer ■ / � : . " ■ System
■ •
consthjirla solucionahematiyg [pare[emplp, sistemade: reporie yla integrqcion. Afthite t
adminisiracion de base de datos, emulad.6res> sisfernds
operatives/ ierjgua[es; eicetera). Ho son generalrriente / Internet, �plpref■
aplicqbles sr los, poqu�es de ajsliccicidn'de software $e :
vGrt a odquirir, .
Software de apllcacio n Solucion del paquete Soiudoh i�sonqlizqdd !: Mgual q la,
Descripdon del software que se va o ddquirir, soluoon
desarrpllar, accesar .6 alguna combinacion de esias dlierridtiyq
tecnicas.

Metodoi de p r d c e s o de dqtos .: Cliehte/servidor' •igual a la solucion qlterhativq 1 ; igual b'la ,7--: / :

Generolmenfe dlguno combinaclon dd procesamiento
en lmea> por lotes, loies difendoV I'�tes Ternotosy tieinpo qlternqHvo .1 - ,
fedl.
'
Dispositivos e implicdciones de soKda (2} HP4MV impresoras laser- (2) HP4MV impresbnas laser por Igual q l q ; ' •;::
Descripcion de disppsjtiyos de salida que se utilizorfan, del deportatnento \ deporiamehto. . . ; spludoti ;•: ; •V
■
requerimlentosde.salida especiales (pdr eje'mplo, . • (2) impr�spras laser HP55I: (21 HP5SfiAN ppresbra „ .qli�naiiyd 2,." ■;•-
•
formqtos preimpresbs, etcetera) y doKsiderdcidnes de . (i) PRINTRQNlX iitipresord ;■
sdlida (por ejemplo, restrlcdones de fiempo). ;■ � de codigo de barras {incloyc
progfqrndS' y��ntrbladpres).; .....
las: pqginqs.Web deben�s�� �
drsengdds para .rewlgcion VGA/';
Tddqs'lds pahtdlbs (hter��
dfseikjdas paro resolucion SVGA.

bispositi vos e Implicanones de entroda Tabfetd y rqton ; Apple i'�Quick.Take" carnqra S�uald Iq V"
drgtJul y softworc. »oluci6:N
Descripdon de rnefodcs de entmdq.que se van a , ■
utiiizdo dispositivos de en�radd (tablero, rat6n;etc�ra), (15) PSC QiilckscqniesCqiiers de dlterriativq
requerimientos espedales de entrada (por ejempb, cipdigpde.bart'ds laser.,, : . o
formatps nUevos o revi$ados de los cudles se ingresarati (lj HP S.cqnjet.4C escdne�
dqtos) y consideradohes de entrada (por ejempio, . : flatbed. •
T�laddyrdt66.
- ' • -' .
tiempos de las entradas reales).. , >
'
Pispbsiti vos e i mpl icdciones de Servidpr MS SQLDBMS.con Solucion qlternqtivq 1'- . ; : ..Igy.al d Iq : . �
d 1mac e n a nilento capacidad de 1 q6 . s<�LicT6n .. s. / -s
Breves descripciories de que datos debeh iSi" :; :alterrtdtivd Ti..
■ olmacenados, que datos serfep tonsultdcbs de" las • • • :• •»:•>» •.• V • •• v.

Henda.s �Utentes/ que medios de almocendrfliento ie

•
uiilizancjn�. cuanta cajxiddad de a!macenamiento seria :• ..V.-I'VU' . ••• I,.' X- :• ■•••

y cu6r\tos dqtos sericrn organizadbs. .

i�ecesaria
 Andlisis de sistemas Capitulo Cucttro 139
M

I� ���iifluencias) tambien proporcionen informacion al respecto. El analisis de factibilidad de

se guarda en el repositorio para hacer una comparacion poste-
■
'i da solucjon alternativa
con las demas opciones de solucion.
las tecnicas de identificacion de hechos, desempenan un papel impor-
.. a.*,-
la tarea de analisis de sistemas. En consecuencia, la realizacion de un analisis de
'��gggHidad para cada solucion alternativa del sistema es esencial. Esa tecnica se enseiia en
'vS� c'ipitulo 9, "Analisis de factibilidad y propuesta del sistema".

.'/farea 5.3: Comparar soluciones alternativas

ve/ que cl analisis de factibilidad ha sido completado para cada solucion alternativa,
�H�nos compararlas y elegir una o mas soluciones para recomendarlas a los propietaiuos
��-asuAWOS-DE SISTEMAS. En este punto, cualquier solucion no factible normalmente se
i�una de cualquier consideracion posterior. Debido a que estamos buscando la solucion
iyactiblo de Ms soluciones restantes, identificaremos y recomendaremos la solucion que
ra la mas completa combinacion de factibilidad tecnica, operativa, economica y de cro-
ii _ itriebe entenderse que durante la seleccion, es raro que se encuentre una solucion
'�S�te la factibilidad mas operativa, tecnica, economica y de cronograma.
�tVei nias, los anaiistas del sistema facilitan la tarea. Los disenadoees y c onstkucto-
1.�1 i��aSTEMA deben estar disponibles para responder cualquier pregunta de factibilidad
caf Hero finalmente, los peopietabios y los usuabios dei sistema deben estar facultados
Hingir isl analisis final y la recomendacion.
n�'la figura 4.19, esta tarea se lleva a cabo cuando se finaliza el analisis de factibili-
t lodiis las soluciones alternativas (no mAs soluciones alternativas). La informacion
®a dS ' s6n TODOS LOS anAlisis de factibilidad de las soluciones axteenativas. Una vez
„jg pufede litilizar una matriz para comunicar la gran cantidad de informaci6n que se
de solucion. La matriz de factibilidad de la figura 4.21 permite
��&ljre las opciones
ff�ra�aracion lado a lado de los diversos analisis de factibilidad que se tienen sobre
|]i;erpnteS soluciones altematiyas.
si producto de esta tarea es Ia(s) soluciOnCes) qu e se recomendara(n). Si se recomienda
Be,Ma solucion, se deben establecer prioridades.
�cjiuevo, las tecnicas de analisis de factibilidad (y la matriz) se ensenaran en el capi-
�4fe�;|iisis de factibilidad y propuesta de sistema".

5.4: Actualizar el plan del proyecto

|q.
del tema recurrente a lo largo de este capitulo. Conti-
& �'i�os qtie se haya percatado
>»j4a actuaUzamos nuestro plan de proyecto al tiempo que aprendemos mas acerca de
�®cina, stis problemas, sus requerimientos y sus soluciones. Ajustamos el alcance en
Por tanto, con base en nuestras soluciones recomendadas, debemos una vez
��uar d alcance del proyecto y, en consecuencia, actualizar el plan del proyecto.
admmi.strador dei proyecto, en conjunto con los PROPiETAmos de sistemas y el equipo
|o:dcl:.proyecto, facilitan esta tarea. Los anaiistas de sistemas y los propietakios de
��on lbs individuos fundamentales en esta tarea. Pero como estamos en transicion
de sistema t�cnico, necesitamos comenzar a incluir a los diseSadores y
��discno
�TORES DE sistemas en las actuaUzaciones del plan del proyecto.
no se muestra en la figura 4.19, esta tarea se dispara por la terminacion de la(s)
�fes) que.se recomendarACn). El mas reciente progkama de proyect o y asignacion de
ser revisado y actualizado. El plan de p royec t o a c tu a li za d o es el producto
plan actualizado debe ahora incluir un plan detallado para la fase de disefiio de
�las�que scguira.*

lajS.S: Recomendar una solucion del sistema

im
con, las fases de investigacion preliminar y de analisis de problemas, la fase
�lisis de decision concluye con una tarea de comunicacion. Debemos recomendar
para la comunidad del negocio.

i" Para el lector interesado en el tema, las ticnicas y pasos para actualizar el plan de proyecto se

�fliyel PMBOK del PMI.

140 Porte Dos Metodos de analisis de sistemas

FIGURA 4«21 Mdti'iy dc suluaones tiltenuti\ as del sisfcma

Criterio" Solucion Solucion Solucion Solucion
dc factibilidad P�so alternative! 1 alfernativa 2 alfernativa 3 alternativa...
Facribilidad oper'ativa ' 30% Respalda unicamente loS Respdda totaimente-ia ■, ,. ; i Igual a la �lucion altemciiiva 2,
Funcionalidad Destrip-" requerimientos de semcios yo EuncionalTdad. requenda del . :
ci6n de a que gradp la soly - >■ que lps-procesos:de negocios
■■■■ usuono
. aon;altenia}iva?benetiGiarJa ♦ actagles tendnan: que ser■
a Iq-oigonizaciori y'que-,tans modlficados para.aprovechar .
bien-trabapria elsistemaii-; fa funcionahdadidel software:...
PoliHea.;DeSGFjpcion-de KK-i-:- N >-
'
.<que San bsen. recibrdatterfq
esio ioluciQn potpaifc de:la ■ J V -l-'
, admiRislracion de.ij&arros; j; {
i 1 Calificacion; 100
y-el leslttde la orgdqtzsjcion�: Califtcacion: 60 Calificacion; 100
Faclibilidad tecnita 30% la'ltberacion etctual del pacjuete Aurtque el personal tecruco Aunque el peFst)ni3l»i> 'v- v y

• Pftrtinum Plus es la.version-il.jO aci(jat,f!ene;s6lo experjencid j - : tecnico actual se siente

Tfecnologfo.~"EvnluaEl6rtM;je:.<
Jo'madurez/.disportljslidad-Aa f b ■yi;tia1esfc!do.�.el mercodo pofx • en Powerbuilder; los anoiistas comado-Con Eowerbuilderf ;■ ■
: (o. GQpticidacj-de adquirirly :s6loiieis;semanas\'La-madumz':- senjor que-vieron la demostrtsr:. ia administracifin esf6
necesidad de la Itjcmalogio' » rdel firoducfo es un riesgo y� , cion y pfosentacion dc MS ' preocupada con la recietite;: •
-de connputo.t'�querida petto prov�edor CQrga unocu&ta : ?■: > Visual Basic,han ocordado s�: is adquisicion :de iPowerbuilder:
.'•rcspaldai .esta solucion■-.?» ':5- n\eq5U0t:otlic>onal al tinonto-del " rque la Iransirion seru SfTiiplc de Sybase.lnci'.MSSQL Server
Ijlterrtcrhva � i sofhvOre ppr induir el so�rte /.que encftntrar programado* • es un-"est6ndar pctuai'de la ■«■•
J (eanao del mismo ,res experimentados en ■
� -4 cotnpanfoycompile con-vi -;v
EXp�riencia Eyol��cidrt ,
< J,
Se r�ulera-contrafar o VB.sera mas; factl que encon?";-" iS¥BASE;?nelmerGado de'bs>;. t
J *

�k»"l|>tpefienna w prtafetronal' fraiijprogrdmQdores.d&.Powgf'i- D�MS: diente/serytdofr: Debido.

' buildec a on Ebstojmucho ;ss: ia ssto nq fenetnos
n&cesaiJujjgra deSjarrolbij,. iX\ quefeoga �jerfencra en y gartinfia de
6|5erary'm&enef lefi��ai© C++para reoiizar menor � qlife las version0s futurcfs de.
>.�,"1 #4'
soluri� ajterpohvS��p! �' mo�i�cocl<)ne.sp6ra los - _ M5> Visual. Bn.'jici-Oesrunct.si::. Poweitwitder "correrariL bien' ;■
"jistemo� VC jFeijuenmieftpisdejnlsgraeiqsnvi iecnGlogiasmadura basada 0ni:r cqn-nuestra Version nefuaLdev;
-i. '' f -- el i�umcro de version
' � '
f. -L •<* l�St�a' jr, SQL SeryeF,
� J. C�ificaeidn; SO' Calificacion; 95 " � Calificacion: 60 "
Facttbitidad�jeconpinica •

: CosloipordidesarrolloKi X > Api:�madament? $350�(00 Aproximcfdantjertfe $418 040 AproxittKjdamente $400000

•s. � ~ � ' -v -
Periodo ideirefriBiicion
' ' i V '
r 'i " 5 ar»s i Apr�ltpbdomeflte� 3 ;5::clnos : Aproximodamente 3 3 aflos
n " "J'
(desconltido): � ' :�rOTHtigclQnieftfe�4
A})��!nudarnqnT%-$2T0 000; Apr&xiniadomente $306 7�1? Aproximadameflte $3�5 500
Valor neto prescntc! •
Cotci�os detallados; }i�ease el Anexo A � � � V6ase el�Anexoi A \ .

,
•rt-
' i"
Af Caliticacran: 60 " V
i-
Calificacion:,S5 �, Calificacion: 90 -f
� ri - '
Fact.t»l.daddel W�SjdetresLmfe�,!- 9<Jl2Tneses y meses �■ i

.pnigrama��
-
. *3 » -J ■■ ' ' f \

;fvalu(fe!on;dfcjal6nto.to/nafa. T

disendr � irtlbieenenfar la
iblua�n orarnativcrj- • ) Calificacion: 95 Calificacion: 80 Calificocion'j 85
Clasificocion '-V "■�"�>='51 , V - '"92
100%' *60,5
V ' -�f{ ' � s.c � •? � 1 WV ■!■ 1

El administrador de proyecto y el patrocmador ejecutivo deben realizar conjunta-

mente esta tarea. Otros participantes en la reunion deben incluir al equipo completo del
proyecto, asi como a los propietakios, usuamos, an altstas, d iseS ad ores y c o n s t r u c t o re s de
SISTEMAS asignados. Como siempre, la reunion debe estar abierta a cualquier empleado in-
teresado de la comunidad del negocio. Tambien, si se establecio un sitio Web de intranet
para el proyecto, debe ser actualizado a lo largo de las fases de analisis de problemas para
asegitrar una comunicacion continua del progreso del proyecto.
Esta tarea se realiza cuando se tiene el plan d e l p ro y ect o AcxuALizADO. La s o l u c i o n de
SISTEMA OBjEnvo (de la tarea 4.3) se reforma para su presentacion como una propuesta de
SISTEMA. El formato puede ser un informe, una presentacion verbal o una inspeccion por
un auditor o un grupo de colegas (llamado walkthrough'). En la figura 4.22, se muestra un
esquema de un informe escrito.