CAPTULO

I
QU ES EL ANLISIS Y
DISEO?

INTRODUCCIN
Bienvenido al captulo 1. En este captulo introductorio veremos el propsito del anlisis y
diseo, as como las caractersticas de un buen analista y un buen diseador. Para poner las
bases de los captulos que vienen a continuacin, se revisar la tendencia hacia la
especializacin en nuestra industria, se tratar ei debate de la metodologa de cascada contra la
espiral y se sugerirn algunos criterios sobre lo que hace que una metodologa sea buena".
Finalmente, daremos una panormica de las tcnicas que comprenden al resto del libro, en
particular las actividades y productos para el anlisis y diseo de sistemas cliente/servidor con
interfaces grficas de usuario.
&
2
Captulo 1 / QU ES EL ANLISIS Y EL DISEO?
F:L PROPSITO DEL ANLISISY DISEO
I .l anlisis es el proceso de determinar qu se necesita hacer, antes de decidir cmo debe
hacerse. i/j enseo es el proceso de determinar cul de muchas posibles soluciones es la mejor para
lograr lo que se necesita hacer, respetando las restricciones tecnolgicas y de presupuesto dei
prnyWMO. bl enseno escoge un como espeemeo para anlicarlo al qu. El anlisis es el acto de
II escubrimiento. fcl diseo es el arte del comprom i so.
Tiv.dicionalmente, los esfuerzos de anlisis han tenido una dudosa reputacin en el desa-
rrollo del software. Casi todos saben de algn proyecto al que se le dedicaron incontables meses (o
a veces aos) dibujando miles de burbujas, flechas, cuadros y lneas, slo para ser abandonado en
un librero y comenzar a codificar apresuradamente. Tal vez tambin haya sabido de algn proyecto
que se salt cualquier pretensin de anlisis y comenz la codificacin desde el primer da.
La construccin del software es similar a la construccin de una casa. Muy poca gente en sus
cabales comprara un terreno, contratara a quince carpinteros y les dira: construyanme una casa",
dejndolos en el campo con un montn de madera y una caja de clavos para que lo hagan a su rea!
saber y entender. (Los carpinteros no estaran muy preocupados, debido a que ya han construido
casas, por lo tanto, si se presentan dudas sobre los detai les. tales como la cantidad de cuartos o
pisos que se requieren, con seguridad seran capaces de resolverlos entre ellos.)
El costo de tal tontera podra estar entre los cien o doscientos mil dlares y producira una
estructura bastante extraa. Es muy probable que el propietario no estar completamente satisfecho
con el resultado, y es posible que la casa sea completamente inhabitable.
Aunque parezca tan loca la historia de :ste propietario de casa con sus retos arquitectnicos.
no es nada en comparacin a los millones de dlares perdidos cada ao en proyectos de software,
los cuales fallan para entregar lo que los usuarios necesitan, o se derrumban completamente sin
entregar nada. As como seria tonco culpar a los carpinteros por su falla para producir una casa
decente bajo esas circunstancias, es raro el caso en que un proyecto de desarroilo de software falle
debido a la falta de habilidades tcnicas por parte del personal de programacin. La mayora de los
proyectos que fracasan io nacen por falta de una buena administracin del proyecto y por fallas en
el anlisis de las necesidades del negocio y para disear una solucin antes de realizar la
construccin del producto.
Se podra decir que el propsito del anlisis y diseo es, al menos, evitar que se caiga el
proyecto, y lo ptimo, que articule completamente las necesidades del negocio con base en una
comprensin de sus problemas actuales y que encuemre la solucin que mejor satisfaga las ne-
cesidades y se ajuste a las restricciones presupustales de recursos y tiempo impuestas por el
propio negocio. Un arquitecto residencia! determina los deseos, gustos, problemas paniculares,
necesidades y presupuesto del propietario de la casa y luego explora las soluciones de diseo para
verificar y validar los requerimientos antes de construir. El analista de software define la naturaleza
del problema del negocio y el diseador de software explora las diversas soluciones. tomando
decisiones bien informadas para llegar a un producto que dejar a los usuarios satisfechos.
1
Analista y diseador son ppelos. Pueden ser la misma persona, personas diferentes o equipos cnmpluios
de personas, dependiendo del tamao de! proyecto y del conjunto de conocimientos del personal.
LAS HABILIDADES DE UM ANALISTA 3
Esto se reduce a un concepto muy simple: Encuentre lo que el negocio requiere que se haga
ames de comenzar a imaginarse cmo hacerlo."
El factor que complica todo es que los negocios no son simples y sus problemas intrnsecos
crecen por la presencia de personas con diferentes opiniones sobre la manera de resolverlos (o
incluso si siquiera deben resolverse), y todo el lo est coronado con un laberinto inexpugnable de
sistemas heredados muy enfermos.-
LAS HABILIDADES DE UN ANALISTA
El papel del analista es ir y encontrar qu problemas existen en 1 negocio y determinar lo que
desean que suceda quieneifCSTrtinrcargo ciel mismoTEste es un papel y un conjunto de respon-
sabiltralt!, ladicamLMlc! diferentes a las de, por ejemplo, un programador, cuyo trabajo es es-
cribir cdigo confiable. Es razonable entonces que las habilidades que se requieren en el analista
sean diferentes de las que se requieren en el programador.
No me terminan de gustar los trminos analista de negocios y analista de software,
debido a que los analistas exitosos son una mezcla de ambos. Como analista necesita estar
consciente en forma muy precisa de la manera en que un negocio hace dinero. Como veremos en
el captulo 2, los sistemas de informacin de negocios existen para contribuir a ello. Por otro Indo,
el objetivo del juego es construir el software. Por esta razn, el analista no puede desentenderse
completamente de los principios bsicos de la automatizacin. Necesita estar profundamente
consciente de lo que es posible, factible y prctico en lo que se refiere a la computacin en los
negocios.
En trminos generales, el analista es un investigador, ya que el anlisis es un proceso de
descubrimiento. El analista debe estar a gusto en el papel de arquelogo, desenterrando gemas de
datos desconocidos de entre el naufragio de los archivos planos de un sistema heredado, o
descifrando los jeroglficos de un antiguo algoritmo de algn programador que ya ha muerto.
Muchas veces el analista se convierte en un socilogo que es forzado a aventurarse y vivir entre la
tribu para aprender sus costumbres y dialectos y para separar su mitologa de la realidad.
Tambin son de gran importancia las buenas habilidades para la comunicacin. El anlisis
no es una actividad sosegada y sin sobresaltos". En la fase de anlisis de un proyecto se pasar
gran parte del tiempo sacando informacin de los posibles usuarios del sistema, reorganizando lo
que aprende y volvindolo a presentar para su validacin. Tal vez sea llamado para hacer
diplomacia, resolviendo conflictos y dando soluciones entre facciones del negocio que estn en
guerra, o pasar tiempo en el papel de consejero de campamento aliviando el miedo que los
usuarios tienen al cambio.
Algunas empresas de IT (tecnologa de informacin) tienen la creencia de que si una per-
sona se pasa dos aos encerrada en su cubculo dando mantenimiento a cdigo COBOL, obtiene
mgicamente el conjunto de habilidades mencionadas anteriormente y asciende a un orden de
existencia superior: analista-programador". Desgraciadamente esto no es cierto. Al igual que
muchas otras habilidades en la vida, un buen analista se crea por medio de prctica dedicada y
aptitud pura el trabajo. El analista necesita el entrenamiento adecuado y un ambiente en donde
pueda pulir su talento por medio de la repeticin de las tcnicas analticas.
:
Los sisicntjs heredados snn aquellos que ya existen en In compaa, incluyendo ios sistemas que se
vayan
a reemplazar. Por lo general, lian sido desarrollados nace algn tiempo con tecnologa vieja.
4
Captulo 1 ! QU ES EL ANLISIS Y EL DISEO?
JO TE ?Z.CC'J?. t>\CSSJ &U SrA S UNA PA<Zr DOCH(Vn"ADA
ve Su peotrssci ico".
Muchos programadores talentosos se convierten en analistas excelentes, sin embargo, la
programacin no es un requisito previo para el trabajo del analista. El conjunto de habilidades y
upiiludes que se requieren para hacer ambas cosas es muy dispar y tal vez no siempre se d en la
misma persona. En muchos establecimientos de IT. el ascenso a programador/analista involucra
muy poco o ningn cambio en la cantidad de programacin requerida para el traba- |0, y de hecho,
se pasa muy poco tiempo realizando anlisis. En estas situaciones, analista es un mulo indicativo
nicamente del nivel de salario.
La realidad es que ningn esfuerzo de desarrollo df snfrwnrfl de tamao aprecinhle pn- k
hacerse sin las habilidades de buenos administradores, analistas y teenlogos. Una empre- sii de IT
con buen personal tratar de atraer y cultivar estos fres conjuntos de habilidades dentro ilc la
organizacin y recompensar a cada uno de estos de acuerdo con su experiencia.
Algunos establecimientos han mostrado xito convirtiendo a usuarios de sistemas en
.ui.ilisia.v aunque esto, por lo general, requiere algn grado de entrenamiento sobre los de- i.ill' de
l;i automatizacin. Muchos colegios de educacin superior y universidades ahora un ulnrcicnd
cursos sobre negocios con una concentracin en la tecnologa de la informai mu amilanando su
currculum en ciencias de la computacin con cursos sobre contabilidad, IIH-M adulc nia.
produccin y administracin en generalas te es precisamente el tipo de liiinluiitniiii'i educativos que
forman una base slida para una carrera como analista.
LAS HABILIDADES DE UN DISEADOR
5
LAS HABILIDADES DE UN DISEADOR
El diseador es un bicho ligeramente diferente al analista. Mientras el enfoque del analista est
orientado principalmente hacia los negocios, con una fuerte base en la tecnologa; el enfoque
del diseador es principalmente sobre la tecnologa con una fuerte base en los negocios.
El diseo se refiere casi completamente a los compromisos. El diseador se enrenia con
la enorme tarea de mapear los requerimientos del negocio, con la tecnologa disponible. El
analista se puede dar el lujo de suponer una tecnologa perfecta. l documenta los
requerimientos del usuario como si todos los procesadores fueran infinitamente rpidos y
lodos los datos estuvieran disponibles instantneamente. Sin embargo, el diseador debe hacer
que los deseos y fantasas de los usuarios se ejecuten en el lastimero conjunto de mquinas
que pone a su disposicin e! departamento de IT.
El diseador raza los planos a partir de los cuales se construir el sistema, lo que lo
convierte en parte ingeniero y parte artesano. Un buen diseador es creativo, lleno de recursos
c inteligente al evaluar opciones entre soluciones que no son perfectas. Las habilidades de un
diseador estn mucho ms cercanas a las de un programador. De hecho, !a mayora de los
diseadores proviene del grupo de programadores. Aunque la programacin no es siempre un
reciuisito previo para llegar a ser un buen diseador, se debe tener un buen entendimiento de
las capacinad^: dp.l H. Hestinn para disear sistemas que aprovechan sus
fortalezas
y eviten sus fallas ms notorias.

"UO US6 LA rVMC\tJ DE &OTAC\M fO tA veR&M i.-. IJACC OU : v 'I V>M </< M W
rae. LA UMPAP Ai".
6
Captulo 1 i QU ES EL ANLISIS Y EL DISEO?
QU SE NECESITA PARA UN PROYECTO
CLIENTE/SERVIDOR EXITOSO?
El secreto dei desarrollo exitoso en los ambientes cliente/servidor multiplataforma actuales en
realidad no es ningn secreto. Toma a la gente adecuada, a la administracin sensata y 3 una
buena metodologa. Por supuesto, no hace dao tener una gran bolsa de dinero a la mano, pero
debido a que este libro no trata de la obtencin de fondos para los proyectos cliente/servidor,
regresemos al tema de la gente adecuada".
La gente adecuada
La era del tcnico con conocimientos generales
En alstinas ocasiones, cuando estoy ante un pblico de programadores y gerentes de proyecto
me gusta plantearles la pregunta: cundo fue la ltima vez que sintieron que saban todo en
esta industria?. Los programadores ms jvenes nie han visto como si estuviera loco, pero al-
gunos de los participantes ms antiguos han cado n una ensoacin haciendo un breve recuer-
do y despus de eso.se oyen fechas que se mencionan con aoranza y reverencia. 1967",
1974, junio de 1979*.
A mediados y finales de los setenta, el establecimiento con mainframe tpico tena todo
bajo control desde un punto de vista tecnolgico.- Los lenguajes empleados para mover datos
hacia y desde archivos, el poner pequeos caracteres verdes en pantallas de terminal o procesar
grandes cantidades de datos estaban bien establecidos. Si un proyecto necesitaba ms ayuda. un
gerente poda tomar el telfono y tener un pelotn de guerreros de bits calificados que le
enviaban del semillero local de programadores. Era tpico a principios de los ochenta ver un
currculum que se basaba en ms de 20 aos de experiencia en programacin en un lenguaje
determinado. Si se tenan problemas de hardware se poda llamar a un vendedor especificado
por la empresa y enviaban un equipo de tcnicos vestidos de azul en el siguiente vuelo.
Los mecanismos de la mainframe estaban bien comprendidos y un buen tcnico en ge-
neral poda montar cintas, estructurar archivos, escribir lgica de programacin y manejar pan-
tallas. Aunque haba algunas reas de especialidad que estaban emergiendo en aquella industria,
la mayora de los trabajadores de procesamiento de datos haca un poco de todo. Con un
conjunto de recursos muy homogneo, un gerente de proyecto poda casi siempre salir de
problemas lanzando suficiente gente ante cualquier problema, seguro en la creencia de que ellos
sabran cmo resolverlo y lo haran.
Todos podan ir a casa en la noche sabiendo que el almacn empresarial de todo el co-
nocimiento estaba seguro en la mainframe. Era especialmente reconfortante para los gerentes
de procesamiento de datos de esa era. el saber que sta era la nica alternativa. Su personal era
competente, altamente intercambiable y los usuarios no tenan ningn otro lugar a donde ir.
Todo el sentimiento de control termin con la llegada de la PC (computadora personal
1
).
Las primeras computadoras personales comenzaron a aparecer en las oficinas administrativas de
muchos negocios a principios de los ochenta. Muchos establecimientos de mainframe fallaron al
reconocer la importancia de estas anmicas maquinitas. y las clasificaron junto con las
calculadoras de bolsillo, las mquinas de escribir y las sumadoras. Los usuarios vieron a la PC
-* El que estuviera bajo control desde un cunto de vista metodolgico es un asunto completamente diferente.
QU SE NECESITA PARA UN PROYECTO CLIENTE/SERVIDOR EXITOSO?
7
como su salvador, liberndolos de las garras malignas de las mainframe terrorficas e inflexi-
bles y de sus sirvientes vestidos de blanco en el cuarto de vidrio con aire acondicionado.
No pas mucho tiempo para que cualquier usuario que tuviera un poco de dinero
sobrante pudiera ir a la tienda de la esquina y comprar una PC y una caja de discos flexibles.
Apareci una nueva especie de tcnicos en el planeta que no eran completamente
programadores en el sentida tradicional pero que estaban siendo contratados por los usuarios
en gran cantidad para escribir macros de hoja de clculo, construir pequeas bases de datos
de escritorio y enchufar impresoras lser. E resultado en muchos establecimientos fue caos y
anarqua. La mainframe ya no fue considerada como el vasto ocano de informacin que
alguna vez fue. En su lugar, el depsito de conocimiento empresarial estaba repartido por toda
la empresa en los discos duros y discos flexibles de la PC. como si fueran muchos esteros o
bahas en vez de ese ocano.
La explosin de la PC forz a que el siaiu qno reconociera el poder del software en pa-
quete y de la computacin de usuario final en la comunidad de los negocios. A mediados y fi-
nales de los chenla, los establecimientos de IT se esforzaban por entender lo que los haba
golpeado y as construir una estrategia para que la informacin empresarial volviera a estar ba-
jo control. Por la misma poca comenz a emerger la tecnologa de red confiable, la cual per-
miti que las computadoras personales se enlazaran en grupos de trabajo y pudieran acceder a
la mainframe y a los servidores de archivos compatibles. La tecnologa cliente/scrvidor haba
entrado al gran mercado de la computacin de negocios.
La tendencia haca la especiaiizacin
Los gerentes de la IT que se ocultaron en el refugio antibombas durante el boom de la tecno-
loga de los ochenta, emergieron en un paisaje completamente extrao en los noventa. Un de-
partamento IT robusto ya no est compuesto de repeticiones del mismo conjunto de
habilidades. En forma muy similar a la profesin mdica, el cuerpo de conocimiento requerido
para mantenerse al tanto con la explosin tecnolgica, ha llegado a ser tan grande que la es-
pecializdcin es obligatoria. Un equipo de desarrollo necesita habilidades en anlisis de
negocios, modelado de eventos, modelado de informacin, disciu de iiilciLuccs, dibcilu de ba-
ses de datos, representacin de usuarios, resolucin de asuntos de negocios, administracin
de base de datos, administracin de bibliotecas de clases de objetos, comunicaciones en red.
hardware y operacin de sistemas liost. hardware y operacin de computadoras personales,
programacin de interfaces grficas de usuario, programacin orientada a objetos, experiencia
en SQL. programacin tradicional, intercambio electrnico de datos, administracin de
proyectos, planeacin y ejecucin de pruebas, entrenamiento de usuarios, administracin de
ayuda, administracin de liberaciones de software, control de versiones, etctera. (Disclpeme
si no mencion su especialidad favorita.) -
Esto no quiere decir que al tcnico con conocimientos generales le haya pasado lo mis-
mo que al vendedor de helados. Un equipo de desarrollo estelar casi siempre se mantiene jun-
to por unos cuantos profesionales con conocimientos generales que saben lo suficiente acerca
de cada especialidad para ayudar a orquestar el esfuerzo tcnico. Tampoco quiero implicar que
se tiene que contratar a un grupo diferente para cada necesidad. La mayora de las personas
llega con suficiente experiencia en varias reas, sin embargo, es muy poco probable esperar
que una persona logre ser competente en todas n la mayora de las habilidades que se listaron.
La complejidad de las herramientas de desarrollo actuales, junto con la avalancha de automati-
zacin en cada una de las facetas de la empresa de negocios, demanda un nivel de experiencia
en cada rea que est ms all de lo que es razonable esperar de un solo individuo.
8
Captulo 1 i QU ES EL ANLISIS Y EL DISEO?
La clava para reunir un equipo exitoso no solamente es contratar a la cantidad necesaria de
personas inteligentes y lanzaras ante el problema. En vez de ello, lo que hay que hacer, es construir
una matriz de las habilidades necesarias a lo largo de la duracin del proyecto y determinar cules se
necesitan y en qu momento. Luego el gerente de proyecto puede buscar un equipo medular que
proporcione la continuidad del proyecto y mejore al equipo con especia- lisias que pueden rotarse
por poco tiempo en los distintos grupos, proporcionando as las habilidades criticas solamente
cuando sea necesario (figura 1-1).

Figura 1-1. Un ejemplo de una matriz de habilidades.
.QU SE NECESITA PARA UN PROYECTO CLIENTE/SERVIDOR EXITOSO?
9
La gran complejidad del ambiente cliente/servidor actual nos fuerza a reconocer que no podemos
apoyamos completamente en tcnicos con conocimientos generales. Necesitamos gente que tenga grandes
habilidades en reas que tienen curvas de aprendizaje amplias y con gran pendiente. Las especialidades se
cultivan con experiencias repetidas. El permitir que un individuo se involucre en el mismo tipo de tareas
una y otra vez es la mejor forma para construir habilidades. Esta aseveracin es un reto para muchas
estructuras organizacionales de IT tradicionales, en donde grupos de programadores construyen un
sistema para una parte particular del negocio y luego se mantienen ah y le dan mantenimiento hasta que el
sistema o los programadores se retiran o mueren de vejez. En vez de ellos, los establecimientos de IT nece-
sitan concentrarse en la construccin de habilidades especficas permitiendo que la gente se mueva de
proyecto en proyecto para que pueda sobrepasar la capacidad apenas suficiente y elevarse al nivel de
experto que demandan los sistemas de negocios actuales.
Administracin slida de un proyecto
La labor del gerente del proyecto es planear y asignar el trabajo, medir el avance continuamente y ajustar el
plan con base en sus mediciones. Esta es una tarea imposible a menos de que se tenga algn plan contra el
cual medir el avance.
Este libro detalla una serie de tcnicas para la realizacin de anlisis y diseo de sistemas
cliente/servidor y aplicaciones de la GUI (interfaz grfica de usuario). Una tcnica es un mtodo
estructurado y repelile para lograr una tarea especfica. Ejemplos ce tcnicas en este libro incluyen
modelado de eventos, modeladcTde ntormacin y diagramado de navegacin por ventanas. Una
metodologa de ingeniera de software es el acomodo ordenado de las tcnicas en un enfoque sistemtico
para la construccin o adquisicin de sistemas de informacin.
Mientras que ios analistas, diseadores y desabolladores individuales son responsables del dominio
y la ejecucin de las tcnicas, el gerente de proyecto sirve como la fuerza conductora para ordenar las
tareas en una metodologa coherente a fin de satisfacer los objetivos del proyecto. El gerente de un
proyecto de desarrollo de software es muy similar al contratista general en un proyecto de construccin. El
gerente de construccin se asegura que las cuadrillas de concreto, los enmarcadores. los que hacen el
techo, los plomeros, los electricistas y las cuadrillas de paredes lleguen al proyecto en la fecha adecuada y
coordina sus esfuerzos. De la misma forma, el gerente de desarrollo de software tiene que hacer
malabarismos con las agendas y calendarios de las cuadrillas de red y de hardware, los analistas de
negocios, los diseadores de interfaces, los especialistas en comunicaciones, los programadores, los
probadores y los entrenadores. Entre ms grande sea el proyecto es ms probable que stos sean equipos
individuales de personas y no simplemente papeles representados por las mismas personas.
Metodologa slida
Sobre espirales y cascadas
Las metodologas vienen en muchas formas y tamaos. Mucho se ha dicho acerca de las ventajas de la
metodologa de espiral* contra la metodologa de cascada. Otros conceptos en el campo de las
metforas metodolgicas incluyen pirmides, remolinos, vrtices y algo que parecen jorobas de cabello
traslapantes. Sus filosofas van desde el enfoque de recetario draco
10
Captulo 1 I QU ES EL ANLISIS Y EL DISEO?
niano. hasta la programacin evolucionara, que es el ltimo eufemismo para denominar a lo que hace
un hacker.
El enfoque de cascada
La cascada tradicional tiene una cierta lgica. Se hace un plan para un provee tu v luego se rea- Iiza el
anlisis del dominio del problema,Cuando se declara la victoria en el anlisis comienza el cliseno, y una
vez que est terminado el diseo comienza la construccin. F as salidas de una etapa son las entradas
para la siguiente, y a esto se debe la metfora de cascada" (figura 1-2).

La cascada' tiene un atractivo ordenado que hace que sea un modelo esnecialmente con-
vcniemeTpara la enseanza tic las tcnicas de ingeniera de software. De hecho, observar que este libro
est dispuesto en una forma similar, con el captulo sobredi pian general del proyecto precediendo a los
captulos sobre anlisis y a continuacin los captulos sobre diseo. Sin embargo, la organizacin para el
aprendizaje de una serie de tcnicas no siempre es igual a la organizacin para el empleo de una serie de
tcnicas en nuestro catico y ambiguo mundo real. Aunque pocos pueden argumentar en contra de que la
planeacin debe preceder al anlisis detallado, y que el anlisis es un precursor lgico del diseo y la
construccin, sera tonto insistir que un proyecto de desarrollo a gran escala termine todo su anlisis
antes de realizar nada del diseo, o que debiera disear todo el sistema antes de construir cualquier parte
de l.
Los instructoras de ingeniera de software han advertido desde hace mucho que. aunque sus
cursos se presentan con un enfoque de cascada, los provectos reales se ejecutan en fases, sucediendo
muchas tareas en forma concurrente y con un grado moderado de iteracin de ajuste mientras se
aprenden cosas sobre la marcha, las cuales causante se revisen tarcas anteriores. Mi teora es que muchos
gerentes de proyectos estaban fuera del saln o hablando por telfono durante esta pltica en particular.
Por lo tanto, la historia de la ingeniera de software est salpicada con fallas monumentales que fueron el
resultado de una mala administracin de las tcnicas, ms que de la falla de adecuacin de las tcnicas
mismas.
QU SE NECESITA PARA UN PROYECTO CLIENTE/SERVIDOR EXITOSO?
11
El desarrollo en fases increnientales y algn grado de ieracin de ajuste, siempre ha sido una
prctica clave en la implemeiitacin exitosa de cualquiera de los llamados mtodos de cascada (11 gura
1-3). Los buenos gerentes de proyecto lo han oslado haciendo durante aos. Las metodologas de
cascada en realidad sufren de una mala analoga. El agua, siendo vctima de la gravedad, no tiende a
regresar hacia arriba ds la colina para dar otro paso por su propia cada. De manera simiiar. la gente
tiende a tratar los regresos hacia el anlisis o el diseo como una falla en vez de ser un paso hacia
adelante.

Figura lo. Una cascada con iteraciones de ajuste integradas.
Implemeniacin en fases
Es una prctica sensata hacer los proyectos grandes en fases (Figura l-4j. Una de las principales razones
es que di junjiidnajc que sa obtionu micntras-se-tcma una parte del provelo a travs de su ciclo de
vida completo proporciona experiencia valiosa Que ayiliya =! desarmllp fie fases subsecuentes. Otro
beneficio es la entrega temprana de algunas aues del sistema que jmede usar ei negocio.-
1

Muchas tallas de proyectos que han sido achacadas a la cascada, en realidad fueron resultado de
una falla del empleo de buenas tcnicas de modelado en un plan de impiementacin correctamente
dividido en fases. El trmino "parlisis de anlisis" fue acumulo pnra describir proyectos que se
encuentran entrampados en un gran dominio del problema, para su desgracia, sin una conclusin
previsible para el inmenso esfuerzo de modelado. Tales proyectos fueron cancelados, por lo general,
por patrocinadores frustrados convencidos de que el departamento de IT se haba convertido en
estudiantes profesionales analizando el problema en vez de hacer algo pur l. o lo que es peor, las
necesidades del negocio haban cambiado tan drsticamente en Ins siglos transcurridos desde que el
proyecto se inici, que el sistema resultante sera obsoleto antes de que fuera instalado.
1
Emo se conoce iradicionalir.cnte como reyla de Ins IX meses. Cualquier proyecto qiJt: falla en ent regar nl- Qtf cu I 8
meses es probable que so cancele. Desafortunadamente, la ventana de expectulivas de 18 meses se esi
achicando en ius ambientes de nugneios apresurados de estos dias.
I ?
Captulo 1 / QU ES EL ANLISIS Y EL DISEO?

Figura 1-5. Un enfoque de cascada en fases.
/./ titifoque espira/
lnr el contrario, el modelo de desarrollo espiral (figura 1-5) integra las fases y la iteracin de aiusie en la
metfora. El modelo espiral fue desarrollado originalmente en ei Pentgono como mi mtodo para
controlar los costos desbocados de armas masivas y proyectos de desarrollo de .isirmns de defensa. La
idea fue dividir el proyecto en fases ms cortas de anlisis, diseo de-
.in ollo y evaluacin. Despus ce cada evala la: viabilidad tki ti abajo terminado jun-
tn rim una usmnacrn refinada para las siguientes fases. Esta tcnica de presupuestacin mporcion
revisiones de factibilidad cruciales para proyectos en donde frecuentemente estaban haciendo
investigaciones sobre tecnologas completamente nuevas. Se toma una decisin n la fase de evaluacin
sobre si se debe continuar con otra iteracin de ajuste.
La idea de a espiral ha cambiado ligeramente para adaptarse a las sensibilidades peculiares de la
industria del software. En vez de enfocarse en el control del presupuesto. la espiral M* lia empleado
como un mtodo para la entrega lemprana de cdigo en una metodologa que li.i Mocado a ser popular
bajo el termino RAD (Desarrollo Rpido de Aplicaciones).
!!! RAD combina el enfoque espiral con una estrategia de divisin de un proyecio-traiu 'le fi
"cuadros de tiempo" (ligura l-fr). Un cuadro de tiempo es un conjunto de caractersticas ilcl'iiido puese
promete entregar a los usuarios dentro de un marco de tiempo fijo, digamos 90 lu!. Dentro de! cuadro
de iempo se realiza algo de anlisis, un diseo breve y luego, usando Ih-irumenlas de desarrollo de afto
poder, se construye un prototipo funcional. El prototipo es u'\ i Mulo por los usuarios y se solicitan
modificaciones. El ciclo de codificacin y de refinacin 'It'l i'rntnrTprr'.Trrciijrteirfy veces: vtfiiu
rfiresninil
1
volviendo \\ HMlizar, disear, y evaluar. Al lliml II 'n.idro de tiempo se instala 1 aplicacin
resuiiante,
I n la prctica, el RAD sufre de malas aplicaciones igual que la cascada. Muchos geren-
|HIH.'IHiladores ven el modelo espiral como tres iteraciones de ajuste de "codificacin.
1
i puiicipnl
del RAD es a codificacin lemprana, y en muchos establecimientos la
QU SE NECESITA PARA UN PROVECTO CUENTE/SERVIDOR EXITOSO?
13
produccin de cdigo es vista como la nica medida tangible de que se ha realizado una actividad
significativa. Eslo lleva a la mentalidad de fres strikes y ou. en donde cualquier cosa que parezca anlisis
y diseo es rpidamente abandonada, dando como resultado sistemas dbiles que se desempean en
forma dudosa en la fase de mantenimiento de su ciclo de vida.

Figura 1-5. Una metodologa espiral.
Cuad/o e tiempo I Cuadro de Tiempo II Cuadra de tiempo III
Anlisis Evaluacin Anlisis
Diseiio ! Desarrollo
Anlisis ! Evaluacin
Diseo
Diseo
O-
Entreg
a de -
lase I
O
=ntrega de
fase II.,
Entrega de ...
fase n
Figura . Tres iteraciones espirales dentro de cuadros di: tiempo.
Los puntos fuertes dei RAD son que los usuarios se involucran tnien^am^uin. la_eieiiLimi temprana
de prototipos y la implementacin en fases. Sus puntos dbiles incluyen LIIKI tcmlcn cia hacia ia
codificacin temprana, lo que hace que pasen muchas tareas de HIHISM y <lruiln i manos del
programador v. por lo tanlo. depende <jc los lcuicns con conocimiento.
1
) i'iimni' Se apoya en
programadores que son maestros de sus respectivas llenan nenias Ir iltvmifol
1
y
14 Captulo 1 / QUE ES EL ANALISIS Y EL DISEO?
ambientes de programacin y al mismo tiempo son adeptos ai diseo de interface* y al anlisis de
negocios, adems son comunicadores talmosos. El enfoque abrumador sobre el cuadro de tiempo hace
difcil ia construccin de componentes reutilizabies a largo plazo, y cuando se acerca la fecha de entrega
lo primero que se hace es la documentacin. En vez de administrar contra una especificacin tangible, el
administrador se encuentra armado slo con un ltigo y un cronmetro. La medida de avance principal se
convierte en la cantidad de revisiones que se han hecho al cdiso.
Recientemente me encontr con un cliente al que lo haban enviado a un seminario para investigar
el desarrollo espiral. Mientras estaba ah aprendi acerca de las tcnicas RAD y la manera en que el
software es mejorado incrementalmente por la espiral, con cada iteracin de ajuste. Regres a trabajar e!
lunos "iluminado" Y anunciando al equipo del proyecto: la cali dad de un sistema de software es
proporcional a la cantidad de versiones que se han desechado*. Esto me pareci como el estribillo de una
industria que tiene todo pero ha abandonado la idea de construirlo bien desde la primera vez. Su
conclusin, demoledora para el presupuesto, me record la historia de Odius y Tedius. do? constructores
de templos de la antigua Roma.
Odius fue un gerente de proyecto romano establecido cerca de Salisbury. Inglaterra. en el
siglo 11 d.C., de quien se dice que declar, La calidad de un templo es proporcional a la
cantidad de templos que se han desechado". Despus de ordenar la construccin y
subsecuente demolicin de al menos tres versiones del templo del pueblo, fue asesinado
brutalmente en un ataque de sus conscriptos bretones. Resdt que los habitantes del
pueblo le haban ahorrado al emperador el coito de una ejecucin pblica, debido a que
Odius haba sobrepasado su presupuesto de capital v no tena nada que mostrar a cambio
de ello, a excepcin de tres montones de escombros.
Odius fue sucedido oor su primo. Tedius. quien empic un enfoque de cascada estricto
para la construccin del templo. Despus de tres aos de analizar y balancear las
necesidades de los sacerdotes, dioses y fieles, Tedius ha producido rollos y ms rollos de
modelos y diagramas, pero le falta an la materializacin de un templo en !a llanura de
Salisbury. Tedius fue despedido simultneamente del proyecto y de i planeta por su falla en
la entrega.
Tanto el enfoque de cascada como el espiral tienen sus punios buenos. Desafortunadamente
ambos sufren de abusos brutales en el mundo real. Yo creo que la clave para el xito del proyecto se
encuentra en algn lugar entre esos dos extremos. El hecho es que un e:rcnte magnifico ser capaz de
hacer que funcione un enfoque de cascada o espiral. Si tiene que trabajar con el de cascada dividir al
proyecto en varias fases e introducir algn tipo de iteraciones do ajuste controladas. Si le toca un
espiral, continuar empleando buenas tcnicas de cascada" a travs de cada fase e iteracin de ajuste,
para crear unidades ms discretas con las cuales pueda ser administrado e! nrovccto en forma efectiva.
5


Con las personas adecuadas cun habilidades adecuadas, empleando una administracin sensata
en productos en ases y usando una buena metodologa de desarrollo, un proyecto pue-
/
' Es probable quo un mai udremo ile proyecto hasa un enredo do cualquier enfoque.
de gozar ios beneficios de una buena base de modelos sin hundirse en el pantano de la parlisis del
anlisis ni obteniendo soluciones inadecuadas en un frenes de clics del ratn y codificacin.
QU ES LO QUE HACE QUE UNA METODOLOGA SEA "BUENA"?
Una buena metodologa arma a sus practicantes con un juego de herramientas de tcnicas confiables y
repetibles que se adecan particularmente bien a los problemas que estn tratando de resolver. Las
tcnicas del modelador deben permitirle combinar el balance y mezcla adecuados de tcnicas para el
problema. No todos los problemas de negocios se crean igual. Algunos son ricos en datos, pero tienen
muy pocos requerimientos de procesamiento. Otros son ricos en eventos, casi sin procesamiento, pero
comprenden grandes cantidades de datos, y as sucesivamente. Una metodologa balanceada incluye
tcnicas que le dan a los analistas y diseadores una amplia cobertura de todos los aspectos que deban
modelar, pero les permiten desviar su nfasis de modelado para adaptarse a la tendencia del problema
de negocios.
Una buena metodologa de anlisis o diseo debe tener cinco caractersticas principales:
1. Motivar la actividad pretendida
2. Ser completa
3^Ser modificable en su correccin
4. Producir productos contra los que se pueda medir el avance
5. Ser fcilmente aprovechable en la fase subsecuente
Examinemos estas caractersticas de las buenas metodologas de anlisis v diseno, comenzando
con la manera en que se aplican a las buenas prcticas de diseo.
Caractersticas de las buenas metodologas de diseo
El diseo consiste en decidir la manera en que debe construirse el sistema para satisfacer los
requerimientos de los usuarios. Las buenas metodologas de diseo comparten las siguientes
caractersticas:
1. El buen diseo debe motivar la toma de decisiones ayudando a evalu nlurnniiyas. Todb~el
diseo es acerca de compromisos. Como veremos posteriormente en el libro, no hay solucin
perfecta en el ambiente cliente/servidor. Para cada requerimiento esencial del negocio habr
muchas formas posibles de lograrlo. Una tcnica de diseo debe permitir que el diseador
evale su decisin contra otras posibilidades, t'or ejemplo, usando ei modelo de anlllS'de
evenios acoplado con el esquema ded i seo de dalos, el diseador puede simular el volumen de
lecturas y escrituras a la base de datos para cualquier evento de negocios dado fpor ejemplo, el
cliente iuice pedidos). Esio permite que el equipo evale la factibilidad y desempeo proyectado
de una disposicin de labia de base de dalos dada y de un esquema de distribucin de datos
antes de construirlos.
Captulo 1 / QU ES EL ANLISIS Y EL DISEO?
l-l diseo necesita de. tal "olma nik il!li)ij uirn nnn rieJns.psppr.in.i^ti..
i pales de! software CRI C nacesltn rnnctnn^p Esto causar quejig
f ^ n - fcremes de modelos en la documentacin^dei diseo.
En forma similar a los planos arquitectnicos para la cimentacin, enmarcado, sistemas
elctricos y de plomera de una casa, el plano de diseo de software incluye un modelo para la
disno<urin h hn- se de datos, la disposicin de ventanas y reportes, la navegacin en las
ventanas, las especulaciones para cualquier otra miertaz electrnica y modelos estticos v
tiinmims d<e-TwiuintWumeb miemos. Cada modelo est especializado para mostrar un
aspecto particular del sistema. Encontrar que los modeladores son particularmente adeptos
de la articulacin de esos aspectos para los que est orientada la tcnica de modelado, pero
fallan miserablemente cuando se trata de estirar el modelo ms all de su propsito original.
Ningn modelo puede mostrar iodas las facetas del sistema funcional completo. Ese sera el
sistema mismo.
3. El diseo debe ser verifcable antes de su construccin. Uno de los propsitos principa- lgs-
amrcsgfro rsTnusjry elhcutir fcr sulun Times tld trnrairsg la carga y ~codiiicart5~ Fane CL
proceso de vertfi'JM.Cm es su uisueJjil!<l.d. CorniTTiiljuenn espsci/tcacson ue diseo se debe
ser capaz de demostrar que se satisfarn los requerimientos del proyecto y asimismo se
distinguir entre varias versiones del diseo en cualquier momento.
La documentacin del diseo va dirigida a dos pblicos diferentes T as pnrr^s t>ytern:i-
niente visibles riel d5o friisposicioncs ds ventanas, repones, diagramas de navegacin,
ments y especificaciones de botones) necesiten r Tvvi^Hr-.; pnr lr>y. iiftiijirirv; Esto significa
que una gran pane del diseo externo debe ser escrita en una forma no muy tcnica. Las
especificaciones internas de lo que sucede tras hamhnlinr>< PC r>rrn asunto, su pblico se
miia a la comunidad de la T que debe construir, probar y mantener el sistema. La
especificacin interna debe ser escrita directamente para esta audiencia. '
4. TJiia buena metodologa de diseo crea productos diferenciados que son mensurables. Una
de las tareas ms difciles de cualquier proyecto es estimar cundo ss terminara Para hacer una
estimacin e! gerente de proyecto debe tomar medidas, la cual involucra el conteo de cosas
que necesitan hacerse y la aplicacin de algn tipo de medida sobre de ellas para estimar qu
tanto tiempo se llevar el hacerlas. La medicin viene, por supuesto, de haber contado esias
cosas en el pasado y haber medido qu tanto tard el hacerlas anteriormente (o plagiando el
sistema de medidas de otra persona). Por lo tanto, una metodologa de diseno debe producir
componentes discretos lo ms pronto posible. Qu tamas tablas tenemos? Qu tantas
ventanas se requerirn para la interfaz? Qu tantos repones se requieren? Cul es la cantidad
de objetos que necesitamos disear y construir?
1

Tan pronto como e! gerente pueda tener producios firmes que contar, puede comenzar a
refinar las estimaciones de los esfuerzos requeridos y los conjuntos de habilidades necesarias
para lograr la tarea. Conforme el proveen*avanza tendr producios intermedios con los que se
pueda medir el avance. Cuntas ventanas se han diseado? Cuntas faltan de disear?
Cul es la tasa de productividad del equipo? Cul es c tiempo promedio que se lleva
codificar y probar una ventana y sus funciones de fondo? Cmo influye esto en nuestra
estimacin originai?"
GUE ES LO QUE HACE QUE UNA METODOLOGA SEA "BUENA"?
17
5. Por ltimo, pero no menos importante, el diseo debe ser fcilmente aprovechado en ei
producto final. Debe expresar el uso ^fTstructura del sistema en una forma muy cercara al
resultado pretendido. Este punto puede parecer obvio, pero lie visto proyectos que trataron
de usar tcnicas de diseo que fueron completamente inadecuadas para el lenguaje de
destino en el que se codific el sistema. Usted no querra que su arquitecto casero le
presentara un plano que fuera tan esotrico que no le diera idea de la forma que tendra la
casa en su terreno. El lema del diseador es: hacer un mapa de h tcnica hacia el destino. Si el
sistema va a operar con una base de datos re acin al se deben escoger tcnicas que sean
particularmente adecuadas para el diseo de bases de datos relacinales. Si el sistema
emplear un lenguaje orientado a objetos, entonces se debern usar tcnicas de diseo
orientado a objetos para las panes del sistema que requieren objetos para lograr sus tareas.
Si el sistema incluir componentes ms tradicionales, tales como funciones estructuradas en
las anias cliente o por lote en el servidor, entonces son adecuadas tcnicas de diseo
estructurado ms tradicionales para esas partes dei sistema.
Muchos de los sistemas de negocios cliente/servidor actuales incluyen todos los paradigmas
del lenguaje anteriormente mencionados, tratando valientemente de vivir en armona. Si esto
es cierto para su sistema, entonces su documento de diseo incluir una diversidad de
tcnicas de diseo que van desde la relaciona! y la orientada a objetos, hasta la tradicional,
cada una establecida de acuerdo con sus respectivas partes de destino en el sistema.
Caractersticas de las buenas metodologas de anlisis
El anlisis consiste en comprender y documentar las necesidades del usuario. La comprensin tfiene
de hacer pTeguntas y escribir las respuestas, examinar las respuestas y hacer ms preguntas. Un
analista que no hace preguntas est realizando un anlisis dudoso. Un analista que no escribe nada
no ha hecho ningn anlisis, sino que simplemente est en un curso de auto- ayuda expandiendo
su conocimiento personal del negocio. La falta de documentacin de los descubrimientos analticos
sabotea los cinco beneficios de un anlisis exitoso. El resultado no es ni analtico, ni completo, ni
verificable, ni mensurable, ni aprovechable. Suponiendo entonces que un buen anlisis est escrito,
una metodologa de anlisis exitosa presentar las siguientes caractersticas:
i. Una lcnica de anlisis debe motivar ei acto del descubrimiento proporcionando un marco ae
traoajo en el que 1 analista puede escribir lo que ellos saben y evaluar lo que tienen que
aprender. Esto incluye el tener inventiva para guiar el anlisis. Por ejemplo, a tcnica de
anlisis del modelado de informacin indica que ei analista descubre la poltica del negocio
para los cuatro puntos cardinales de cada relacin.
6
El modelo proporciona un lugar para
registrar esta informacin y el resultado est a la vista para su revisin en el diagrama
entidad-relacin.
* Los concepios sobre e! modelado lie informacin se ciibrcn sn el captulo 5.
Captulo 1 / QU ES EL ANLISIS Y EL DISEO?
La metodologa de anlisis debe ser completa respecto a que cubra adecuadamente
c . Lomo veremos posteriormente en
cesamiento y comportamiento definible. La metodologa de anlisis necesita ser lo
suficientemente rica para modelar los tres puntos de vista. Debido a que ningn modelo puede
servir adecuadamente en todas las situaciones, necesitamos emplear un conjunto de modelos
entrelazados, especializados que nos permita cambiar nuestra perspectiva para cada faceta del
dominio del problema.
un pblico dual. Los usuarios son el pblico principal para aprobar los documentos como una
representacin precisa de sus necesidades. La mayora de los modelos de in-
va a descubrir una relacin de cardinalidad que no sea exacta en un modelo de informacin, como
tampoco va a poner en duda el empleo de la herencia mltiple en los diagramas de clase
orientados a objetos. En vez de sujetar a los usuarios a los mode-
Es imperativo que los usuarios comprendan lo que ha descubierto el analista. El anlisis no debe
realizarse en los calabozos oscuros del departamento de IT y enviar el tomo resultante para que
los usuarios lo firmen. En vez de ello, los usuarios necesitan estar involucrados personalmente
con el proyecto desde el inicio y, en la medida de lo posible. deben unirse a las JAR {Sesiones de
Requisitos de la Aplicacin) y el analista debe realizar revisiones e inspecciones peridicas del
anlisis en presencia de un grupo de usuarios. Un analista experto no se detendr por nada para
asegurarse de que los usuarios estn en la misma frecuencia que ei equipo dei proyecto. Yo le
llamo a esto la parle de danza interpretativa" del proyecto, en donde puede encontrarse
enfrascado en gesticulaciones, pegando imgenes prediseadas encima de un diagrama entidad-
relacin o invitando a los usuarios a llenar datos reales con plumones de colores er. los ace- lutos
en los que aparecen las ventanas.
III otro pblico del documento de anlisis es. por supuesto, el propio equipo del proyec- m. I a
calidad del anlisis impactar a ia calidad del diseo. Las tcnicas de anlisis necesitan ser
precisas y no ambiguas de forma tal que el diseador pueda concebir una solucin sin tener que
volver a hacer todo el proceso de anlisis.
I..i metodologa de anlisis tambin debe crear unidades medibles para el gerente dei proyecto. Al
inicio de la eiapa de anlisis, el tamao y alcance del proyecto pueden ser nn poco difusos. El
negocio quiere saber cundo se le entregar el software y el "' i < * 111 o del proyecto todava no
conoce la dimensin del problema. Los modelos de
imli:iis .mranos ptii
1
d
,
'
,p
'""'hr rr
111
'- pira i-*^
:
------------------- 1' rgn--.
liir I .ios comeos iniciales se utilizan para extrapolar el esfuerzo que se requiere para <1 iesio
del proyecto. El gerente deber preguntarse, qu tantas entidades estn in- vo|ucr:i<lu.s7
Nuestro sistema crea. lee. actualiza o borra todas esas entidades? Qu uiros eventos de
negocios significativos deben reconocerse de acuerdo con el plan cutral del sistema? Estos
eventos necesitan actualizaciones de tablas simples o re- (|uieren un procesamiento
.significativo? Qu tanto nos lleva analizar problemas de

ue deben recordarse, reglas de pro-

geniera de software falla para satisfacer este requerimiento. El usuario promedio no
los tcnicos, un?, hnena. remen rmnKrir.i ser fcilmente convertible en algo con lo

QU ES LO QUE HACE QUE UNA METODOLOGA SEA BUENA"?
19
este tamao? Dada la cantidad de entidades que esperamos mantener, qu tantas ventanas
se necesitarn disear?
. Es So nos lleva al punto final de la posibilidad de su aprovechamiento. Nadie en esta industria
puede negar que una metodologa de anlisis debe motivar al propio anlisis, ser completa,
verifiable y mensurable. E? qu tanto deba ser fcilmente convertible en un diseo y, por lo
tanto, pueda tener tendencia hacia un tipo de diseo particular, ha probado ser el
catalizador para muchos debates de conferencias acaloradas y conflictivas.
La sabidura convencional ha dicho desde hace mucho que el anlisis debe ser una ar-
ticulacin de 3a esencia del problema, completamente libre de cualquier solucin particular,
de ah viene el trmino anlisis esencial. En la prctica, la gente ha encontrado que algunas
tcnicas de anlisis estn predispuestas para convertirse en un diseo particular. ms
fcilmente que otras. Si se enfrenta con un conjunto de metodologas de anlisis
competitivas, cada una de ellas repleta con tcnicas que motiven el buen anlisis, tengan
una cobertura balanceada de ios datos, el procesamiento y el comportamiento, sean
igualmenic verificables y produzcan resultados mensurables, entonces lo que !o impulsar a
tomar una decisin, probablemente ser su capacidad de aprovechamiento.
En mi propia carrera todava no he encontrado una tcnica de modelado de anlisis que
carezca completamente de alguna tendencia tcnica. El anlisis estructurado,
7
y su nfasis
sobre la diagramacin del flujo de datos est muy orientado a procesos. Es muy fcil
convertir un conjunto de diagramas de flujo de datos en una grfica de estructura para un
sistema 3GL. Esto est bien para la construccin de sistemas orientados a procesos. No es
tan fcil convertir un conjunto de diagramas de flujos de datos a un diseo orientado a
objetos. La tcnica es tambin bastante problemtica para el diseo de interfaces grficas de
usuario.
En una forma muy similar, el OOA (anlisis orientado a objetos),

goza de un factor de
convertibilidad mucho mayor si el destino es un completo sistema orientado a objetos. Si el
destino no es un sistema orientado a objetos o tal vez es un sistema de paradigma
mezclado (por ejemplo, relaciona!. 4GL y algunos objetos), entonces el anlisis orientado a
objetos tendr un factor de convertibilidad menor y puede, de hecho, hacer ms di fcil la
labor del diseador. El OOA es simplemente otra forma para organizar la misma informacin
esencial que debe ser articulada en cualquier esfuerzo de anlisis exitoso. La organizacin
OOA puede estar bien adecuada para proyectos orientados a objetos sio por ser ms
directamente aprovechable en el diseo orientado a objetos, y no porque goce de ninguna
superioridad como tcnica analtica! o sea en alguna forma ms completa, verifiable o
mensurable.
7 De Marco. 1979.
?i Qooch, 994 Jacubscn et al.. 1*3^2. ftunibauyh el al.. 1991.
20
Capitulo 1 / QU ES EL ANLISIS V EL DISEO?
La habilidad para convertir fcilmente un modelo de Anlisis a un diseo atraviesa una lnea
tina nlre la amculidtin dl problema y e ordenar una solucin. La forma de los
rnodtl3r3i"andlisi.s puede influir profundamente a forma dei diseo. Una metodologa de
anlisis particular puede diciar un tipu de diseo particular, ya que escoger cualquier otro estilo
de diseo podra representar la reescritura del documento de anlisis. En este caso, el anlisis
prohbe, de hecho, la imaginacin de un paradigma de diseo alterno. El peligro de esta
situacin es que el analista puede tomar prematuramente decisiones de diseo en nombre del
anlisis, cancelando opciones que pueden ser pospuestas con seguridad hasta un momento
en que exista mejor informacin sobre !a cual basar una decisin. Un ejemplo comn se da en
ios modeles de anlisis orientados a objetos, en donde el analista trata de asignar un mtodo
particularmente preocupante a su nico mejor ambiente, slo para encontrar que el proceso
puede vivir en una diversidad de ciases, y teniendo cada una de las soluciones sus respectivos
pros y contras/
9
Este tipo de compromiso es indicativo de una decisin de diseo y no de un
descubrimiento de anlisis.
Por otro lado, una metodologa de anlisis particular puede motivar o permitir ina variedad
de diseos proporcionando suficiente material de anlisis que se ensambla fcilmente en
formas distintas. Es probable que si una metodologa de anlisis motiva determinados tipos
de diseo, puede desmotivar otros. (Por ejemplo, un modele de informacin puede motivar
un diseo relacional y desrncttvar el uso de, digamos, tecnologa de arreglos
tridimensionales.)
Por ltimo, una tcnica de anlisis puede ser completamente neutral respecto a las diversas
opciones de diseo que puedan emplearse. La conversin hacia un paradigma u otro podra
realizarse con igual facilidad o dificultad.
Para este libro he escogido especficamente un conjucto de tcnicas de anlisis, modelado de
contexto, modelado de eventos, modelado de informacin y creacin de prototipos de interfaz. las
cuales creo que son adecuadas para la gran mayora de sistemas de negocios ciente/servidor
actuales, y se apegan bien a los cinco criterios de una buena metodologa. Cada modelo tiene un
firme fundamento histrico en la ingeniera de software y un largo registro de xitos en la industria.
Se ha probado que motivan el bue:i anlisis y tratan una amplia gama de procesos, datos y
comportamiento del sistema. La inclusin del prototipo de imerfaz tiene un argo camino para hacer
que los resultados del anlisis sean vcrificablcs por la comunidad de usuarios. Los modeios tambin
producen unidades discretas que pueden ser contadas y medidas. tales como entidades, eventos,
ventanas y reportes. Estas unidades ya llevan el tiempo sufriente para lograr una base modesta de
mediciones dentro de la i ndusLri u.
Entonces, dnde destacan los tcnicas de este libro en el tema del aprovechamiento? Las
actividades de anlisis, que se detallan en ios siguientes captulos fueron seleccionadas con el
aprovechamiento en mente. Siendo alguien que ha pasado casi el mismo tiempo diseando sistemas
que analizando, la habilidad para la transicin fcil del anlisis al diseo es muy importante para m.
/
Las lcnicas orientadas a obji:ics se iratarc en si captulo 12.
RANORAMJCA DE LASTCNICAS DE ESTE LIBRO
21
La premisa tecnolgica de ejjte libro os que el sistema de negocios de destino =s muy pro-
bable que incluya una base de datos relaciona], una interfaz grfica de usuario y una diversi-
dad de lenguajes de programacin, que pueden ir desdi? los orientados a objetos, los bagados
en objetos, en SQL y los 3GL tradicionales, tendiendo la industria cada vez ms hacia las cons-
trucciones orientadas a objetos. Los modelos de anlisis necesitarn convertirse fcilmente en
diseos para este ambiente. He incluido tcnicas que caen en la categora de motivadoras y fa-
cilitadoras para el diseo del destino, sin mandar absolutamente un paradigma de diseo par-
ticular o prohibir otros.
He escogido el modelo de informacin como el modelo de datos principal, debido a su
excelente registro de xitos para la creacin de diseos de bases de daros relacinales bien nor-
malizadas. Esta es una tcnica que ha sido muy popular y exitosa y, por consecuencia. Ir. dis-
ciplina goza de un amplio campo de profesionales expertos. Ei modelo de informacin muestra
muy claramente lo que el sistema necesita recordar, sin sobrecargarse con elementos procesa-
les que los sistemas de administracin de bases de datos relacinales existentes no son capaces
de manejar.
Se incluye el modelo de eventos debido a que es particularmente adecuado para organi-
zar la especificacin del anlisis en una manera tal que se presta muy bien para el diseo de la
inieriaz grfica de usuario manejada por eventos, una tarea que consumir mucho tiempo del
proyecto. El diccionario de eventos proporciona el marco de trabajo para la especificacin de
procesos internos del sistema. Junio con el modelo de informacin, contiene las materias
primas necesarias para declarar una estructura de clase para un sistema orientado a objetos,
disear grficas tradicionales de estructura para componentes del sistema o para disear pro-
cedimientos almacenados para ei servidor de base de datos.
El modelo !e contexto se incluye como una tcnica aceptada desde hace mucho para la
determinacin y representacin Jel alcance del proyecto. Es principalmente una herramienta
de planeacin que ayuda a clarificar ei rea de estudio y determina qu es lo que se encuentra
dentro y fuera de su propio control.
PANORMICA DE LAS TCNICAS
DE ESTE LIBRO
Entremos a la tarea importante da ver en forma previa lo que se encuentra entre esta pane y e!
ndice.
Usar la pirmide como metfora geomtrica principal para organizar las actividades de
desarrollo de sistemas (figura 1-7). Hay un gran significado asociado a la pirmide. Tambin
podra usar un cuadrado, un crculo o un conjunto de nubes sin forma, pero encuentro adecuada
Ir. representacin piramidal por varias razones.
La pirmide nunca permite que se olvida que el cdigo que se construye es simplemente la
hase de una estructura que est especificada para que alcance un conjunto de objetivos del
negocio. En la parce superior de la pirmide est el pan general del proyecto. Esto irchi- ye la meta
del proyecto y los objetivos que la soportan. Estas son las razones por las que <-l proyecto existe
en primer lugar. Bajo el plan, en una forma descendente, se encuentran lod.i las actividades que
necesitan suceder entre la identificacin de los objetivos tlel proveno y la coiocacin de los unos y
ceros en la parte interior de la pirmide que son el soluvmr u* suifante.
22
Capitula 1 / QU ES EL ANALISIS Y EL DISEO?
f
Modelo Modelo Modelo
de contexto de informacin de eventos
/Prototipo de interfaz
Modelo arquitectnico
/
Diseo de base de datos \\
/
/ Diseo de interfaces externas
Diseo de componentes internos \\
Construccin y prueba
Fijjura 1-7. La pirmide de desarrollo del software.
Si piensa sobre el tiempo que se lleva viajar de norte a sur, la pirmide describe grficamente un
conocimiento cada vez ms expandido acerca de un tema especfico, conforme se desciende de las
alturas del anlisis hacia el diseo en la pane inferior y luego comenzar a pro- h indi zar en el cdigo.
Los gerentes de proyecto, los patrocinadores del negocio y los ms c- mii un de nosotros preferimos
imaginar la pirmide como el cada vez ms amplio gasto de dinero que se hace conforme avanza el
tiempo.
L.i estructura de la pirmide no pretende de ninguna forma diciar un enfoque de cascada i espiral
para llegar de arriba a abajo. En vez de ello muestra cmo el cdigo final y el anli- p. intermedio y los
productos del diseo soportan el plan general del negocio. El que haga su proyecto en fases o que lo
desarrolle de un solo golpe depender del tamao del proyecto y las
cxiuencius del negocio.
4 1

Comencemos en la parte de arriba y vayamos hacia abajo:
Indo proyecto necesita un plan general (figura 1-8) que contiene las rdenes de marcha ili.l
negocio que articulan la meta final y los objetivos del proyecto. El plan general del proyecto iv, una
herramienta de organizacin que es desarrollada en conjunto por el grupo de IT y el negocio. I*s viiul
para definir y controlar el alcance. Sin un plan general del proyecto el analis- itt no nene direccin o
prioridades claras de lo que debe analizar, adems no tiene idea de Imulr dibe detenerse. En el
captulo 2 se cubrir especficamente el plan general del proyecto.
I al ve/, tenga curiosidad de saber por qu estn los siguientes tres modelos alineados en I
misino nivel de la pirmide. El modelo de contexto, el modelo de eventos y el modelo de in- tcn
nun:ii'm son tan inierdependienles que es imposible terminar uno sin tener buena parte de los III I .
Ilnmo los ires grandes", debido a que juntos forman el conjunto de ios requerimiento') del sistema
I I intuirlo de contexto (figura 1-9) define las fronteras del sistema y muestra la mane- i i ''ii que
rain minado dentro del ambiente del negocio. Esta es una tcnica de modelado muy .imiima c|U<~
viene desde los das del anlisis estructurado. Es particularmente til en el mundo luMiU/si'rvidur p:ua
explorar el impacto del movimiento de la frontera as la automatizacin I'II rl nry.ociu. hsic: tema se
trata en el captulo 3.
PANORMICA DE LAS lECNICAS DE ESTE LIBRO
23
Mode!
de contexto de informacin
Prototipo de interfaz
Modelo arquitectnico
Diseo ce base de dates
Diseo de interfaces externas
Diseo de componentes internos
/ Consruccin y prueba
-'If'TItlUiMMti;
Figura 1-8. El plan general del proyecto.

Figura 1-9. El modelo de contexto.
El modelo de eventos (figura I-10) define el eomportamienlo del sistema mostrando la
manera en q.ie se espera que responda ste para cada evento del negocio establecido en el plan
general del proyecto. El modelo de eventos no solamente mapea las entradas y las salidas, sino que
tambin incluye la especificacin de procesamiento para cada evento, la cual proporciona detalles
cruciales para el diseo interno de las funciones, mtodos y procedimientos de! sistema. El
modelado de eventos es una tcnica analtica vital para el descubrimiento y la documentacin de las
reglas del negocio. Debido a que las interfaces grficas de usuaria son, por definicin, "manejadas
por eventos, el modelo de eventos proporciona el marco de irabajo y la racionalicad para el diseo
de la interfaz grfica de usuario. El captulo 4 de este libro est dedicado al modelado de eventos.
Modelo de
eventos
Prototipo de interfaz
Modelo arquitectnica
Diseo d base de datos
Diseo de interfaces externas
Diseo de componentes internos
Construccin y prueba
" ir'flTTiiaBEig
Figura 1-10. El modelo de eventos.
E! modelo final de los tres grandes es tal vez el crucial. El modelo de informacin (finia 1-11)
contiene el mapa esttico de los datos que requiere recordare! sistema. Influye profundamente el diseo de
base de datos e impacta virtualmente en todos los aspectos del isicma. Las tcnicas de modelado incluyen
la diagramacin entidad-relacin, la definicin de nii ibutos y la diagramacin de transicin de estados. Los
modelos de informacin tampoco respetan las fronteras del proyecto. Muchos de los datos que se modelarn
para el sistema tam- lmn aparecern en oros sistemas dentro de la organizacin (y tal vez tambin fuera de
ella). Por esta razn es imperativo que los esfuerzos del modelado de informacin tengan alguna \
nordinacin a nivel de toda la empresa. Ei modelado de informacin siempre debe realizarse mi un fuerte
sentido de contexto, limitado por el alcance de los eventos del negocio. En caso < mira rio, podr modelar
datos por siempre o hasta que se le acabe ei tiempo o el dinero. El iiHnldado de informacin es el tema del
captulo 5.
/X

PANORMICA DE LASTCNICAS DE ESTE LIBRO
25
El prototipo de interfaz (figura I-12) se encuentra inmediatamente abajo de los tres grandes
modelos. Soy un gran partidario de la creacin temprana de prototipos, en especial de los que son
rpidos y fciles. El prototipo pone una cara para los modelos abstractos mostrando cmo se podrau
ver las ventanas y reportes en el nuevo sistema. Aunque la creacin de prototipos comienza :emprano
en la fase de anlisis, es el primer avance hacia el diseo de sistemas. En la prctica he encontrado que
es virtualmentc impasible terminar a los tres grandes sin verificar los requerimientos con algn nivel
de prototipo de interfaz. En algunos proyectos he usado la creacin de prototipos an antes, para
obtener los requerimientos de eventos del negocio y el modelo de informacin. Tal vez se encuentre
usted yendo y viniendo entre los tres grandes y el prototipo varias veces hasta que usted y sus
usuarios estn convencidos de que comprenden sus necesidades. Un sistema robusto puede tener
muchos tipos diferentes de prototipos. La clave para la creacin de prototipos exitosa es identificar
primero el objetivo de aprendizaje y luego escoger el mtodo ms efectivo en costo de creacin de
prototipos para alcanzar ese objetivo particular. La creacin de prototipos es el tema del capitulo 6.
/ Plan >
general
^Modelo
deyVerrto
s
Modelo arquitectnico
Diseo da base de datos
Diseo de interfaces externas
y . *'* ' : Diseo
de componentes miemos
- -
Construccin y prueba
Modelo de
informacin
Modelo de
contexto
Prototipo de interfaz
Figura 1-12. El prototipo de interfaz.
El captulo 7 hace una breve pausa en el modelado para discutir el importante tema de la
resolucin de asuntos del negocio. Uno de los ms insidiosos depredadores de proyectos en el
ambiente ciiente/servidor es ei costo oculto de la reingeniera del negocio. El enfoque cliente/servidor
proporciona frecuentemente estandarizacin y automatizacin a fronteras del negocio que antes eran
dominios de la hoja de clculo, del procesador de palabras, de la nota amarilla adherible y de las
servilletas de coctel garabateadas. Carro analista tal vez se en cuentre en la posicin desafortunada de
descubrir huecos que afectan los objetivos del negocio, en Jas prcticas o polticas, sin tener ninguna
autoridad para resolverlos. El cnpilu lo 7 plantea un proceso de resolucin de asuntos que puede
usarse para diminu nilur. obstculos del proyecto.
En el captulo 8 regresamos a nuestra pirmide con el modulo arquitectnico. I iin ni" dlo es el
proceso de mapear los requerimientos del negocio articulados en lir, mudidun dn iimi
26
Capitulo 1 / QU ES EL ANLISIS Y EL DISEO?
lisis hacia una diversidad de configuraciones de hardware y la seleccin de la ms adecuada o la
menos restrictiva. Para esta tarea, los modelos de anlisis necesitan complementarse con algunas
estadsticas, tales como los volmenes de transacciones, las tasas de eventos, tamaos de registros y
las expectativas de los usuarios en cuanto a los tiempos de respuesta y actualidad de los datos. No hay
respuesta correcta en este modelo arquitectnico. Cada negocio y cada ambiente de programacin
de destino tiene sus imperfecciones. La clave para un modelado arquitectnico exitoso es ser capaz de
usar los modelos para evaluar los compromisos de diseo y el desempeo relativo de diferentes
esquemas de distribucin geogrfica, as como la distribucin entre niveles de hardware dentro del
mismo sitio de negocios.
Aunque muchas de las actividades de anlisis y diseo pueden ser fcilmente divididas y
realizadas en fases, es probable que gran parte de la arquitectura cliente/servidor general del proyecto
completo se decida antes de la primera fase del diseo. En la prctica tambin es poco probable que se
escoja el hardware despus de que se haya realizado todo el anlisis. La va arquitectnica por lo
general corre paralela con los esfuerzos de anlisis. En algunos proyectos tal vez no se pueda escoger
el hardware ms adecuado, y en vez de ello se est forzado a exprimir el software en la desvencijada
coleccin de mquinas que ya se encuentran en el cuarto de computadoras. El modelo arquitectnico
(figura 1-13) ocupa esta posicin tarda en la pirmide debido a que es el ltimo punto hasta el que se
pueden diferir en forma segura las selecciones arquitectnicas, y es tambin el punto en el cual ya se
est armarlo con la mejor informacin sobre la cual basar estas decisiones.

/Plan ^ general
Modelo Modelo pdelo de contexto de informacin de Santos
Prototipo de interfaz
z
Modelo arquitectnico
Diseo de base de datos
Diseo de interfaces externas
Diseo de componentes internos
t Construccin y prueba
Fisura 1-13. El modelo arquitectnico.
El diseo de base de datas (figura 1-14) transforma el modelo de informacin a un esquema
fsico de base de datos. El que disee toda la base de datos de un golpe o en fases, puede depender de
si el proyecto se compone de fases o no. Al igual que muchos de los temas de este libro, una discusin
completa sobre el arte del diseo de base de datos podra llenar un libro completo. El objetivo del
captulo 9 es mostrar la manera en que el modelo de informacin se iransforma en un diseo de base
de datos relacional inicial y discutir las diversas opciones de que se dispone para optimizar el
desempeo.
PANORMICA DE LASTCNICAS DE ESTE LIBRO
27

Figura 1-14. El diseo de base de datos.
Los captulos O y 11 tratan el diseo de la interfaz grfica de usuario. El captulo 10 comienza con
una discusin sobre lo que hace que una GUI sea buena. Muchos de los conceptos representan un
cambio significativo dei mundo de pantalla verde de la mainframe. La ltima parte del captulo 10
presenta el concepto de cohesin de ventanas. He aplicado la medida de cohesin de mdulos del diseo
estructural de Larry Constantine,
1
'
1
y la he adaptado como una calificacin del impacto sobre las
capacidades de uso y mantenimiento para combinar varios eventos de negocios en la misma ventana.
El diseo de interfaz externa (figura 1-15) se trata en el captulo 11. Esto incluye ladia gramacin
de la navegacin por ventanas, una tcnica importante y efectiva en costos para a determinacin de tipo
de ventana, la navegacin y la definicin de la unidad de trabajo adecuada del usuario. El diseo de
interfaz externa refina el prototipo de anlisis hacia una especificacin de diseo formal a partir de la
cual puede codificarse la interfaz. Una especificacin escrita es crucial para la prueba de una GUI y para el
posterior entrenamiento de usuarios y documentacin. Muchas veccs he realizado desarrollos de GUI con
y sin una especificacin escrita. Ya no necesito convencerlo de que la especificacin escrita del diseo
extemo es vital para la construccin, prueba e implementacin del proyecto.
El diseo de componentes internos (figura 1-16) del sisema incluye modelos que ma- pean
directamente hacia el paradigma del lenguaje de codificacin de destino. Si e sistema incluye cdigo
orientado a objetos, entonces el diseo interno incluir modelos de case y modelos de comunicacin de
objetos dinmicos para esa parte del sistema. Si el sistema incluye funciones ms tradicionales y
procedimientos de bases de datos, entonces se encontrar trazando grficas de estructura y escribiendo
especificaciones para procedimientos almacenados. El captulo 12 muestra la manera en que se
aprovecha el modelo ce anlisis en las actividades de diseo interno.
10
Yourdon. Constamine. 1979.
/Plan'l- / generaP
/ _
Modelo Modelo '^&yiodelo
de contexto de informacin devenios j.K
fPrototipo dfl interfaz Modelo
arquitectnico
Diseo de base de datos
Diseo de interfaces externas
Disfio da componentes memos
Construccin y prueba
Figura 1-15. El diseo de interfaz extema.
^Modelo
ce^tyento
Modelo Modelo
de contexto de informacin
/ _ . . . .
/
Prototipo de interfaz
Modelo arquitectnico
/
Di

iseno de base de datos
Diseo de interfaces externas
Diseo de componentes internos
Construccin y prueba
Figura 1-lf. El diseo de componentes internos.
En !a parre inferior de la pirmide est la Fase de construccin, la cual incluye la codificacin, la prueba y
la distribucin. Aunque la codificacin y la prueba no son temas principa- le. de csic iibm, incluye una
discusin al final del captulo 11 sobr<* los retos de la prueba de tina interfaz grfica de usuario y la manera
en que se puede usar la especificacin de anlisis v diserto para crear scripts y escenarios de prueba.
FJ libio concluye con ei captulo 13, el cual incluye algunos asuntos para gerentes. La re' iiucin cliente/servidor
ha difundido una cantidad de milos y promesas exagerados. En este ca- iJimludc cierre manifiesto lo que
opino, desbancando diez mitos del desarrollo diente/servidor.
Hl-SUMLN 29
RESUMEN
El anlisis es un viaje de descubrimiento en el que los participantes determinan los datos, procesos y
requerimientos de comportamiento de un sistema de negocios. El diseo es el acto de decidir la manera
de implementar un sistema que satisfaga esas necesidades. Estamos experimentando una tendencia
hacia la esoecializacin en nuestra industria, la cual est manejada por el universo siempre en
expansin del conocimiento requerido para realizar un desarrollo de software. Las habilidades
necesarias para ser un buen analista no tienen que ser las mismas habilidades que se requieren para ser
un buen programador. Cada da los gerentes de proyecto tienden ms a administrar equipos de
especialistas que a grupos de tcnicos con conocimientos generales que tendan a ser empleados en los
proyectos de desarrollo tradicionales.
Un miembro del proyecto es un profesional competente en sus tcnicas respectivas, el trabajo
del gerente del proyecto es muy similar al del contratista, coordinando las actividades de los
especialistas de acuerdo con una metodologa sensata. Las metodologas se dan de muchas formas. Los
modelos tradicionales de enfoques de cascada y espiral tienen muchos puntos favorables, pero ambos
sufren de abusos en la prctica. Un gerente sensato dividir los provectos largos en fases e integrar un
grado de iteracin de ajuste en el plan general del proyecto. Aunque he escogido a la pirmide en este
libro para representar la organizacin de los modelos, sus dependencias y el nivei de interrelacin cada
vez ms grande del proyecto a travs del tiempo, no implica una cascada ni una iteracin de ajuste
radical
Imagine que su equipo de desarrollo es depositado por un helicptero en la cima de una
pirmide en Egipto. No tratara de descender directamente hasta abajo, sino que en vez de ello
explorara el terreno a diversos niveles y a veces regresando en su eventual viaje hacia la parte baja. Sin
embargo, hay una progresin lgica de actividades en el desarrollo de software. Como nuestro
descenso imaginario de la pirmide, sera muy riesgoso saltar desde la cima hasta abajo de un solo
paso. El brincar del plan general del provecto directamente hasta el cdigo, lieva un riesgo similar.
Queda en manos del gerente del proyecto el decidir si es adecuado guiar a sus tropas en masa en un
descenso directo desde la cima hasta abajo o dividir y conquistar la pirmide con varias jomadas y viajes
laterales iterativos para asegurar una cobertura completa del terreno.
Cualquier metodologa buena deber motivar la actividad que se pretende proporcionando un
marco de trabajo en donde se registre el conocimiento. Las tcnicas empleadas deben ser completas,
por lo que se refiere a que deben cubrir todos los aspectos del dominio del problema y la solucin. Los
modelos creados deben ser verificables por su pblico pretendido para ver que sean correctos. Este
pblico puede ser tanto tcnico como no tcnico. La metodologa debe producir unidades contra las
cuales se pueda medir el avance, formando una base para la estimacin del nivel de esfuerzo. Por ltimo,
los productos deben tender por s mismos a ser fcilmente aprovechados en las fases subsecuentes del
proyecto.
El modelo y las actividades de la fase de anlisis incluyen el plan general del proyecto, el
modelado de contexto, el modelado de eventos, el modelado de informacin, la creacin de prototipos
de interfaces y la resolucin de asuntos del negocio. Las actividades de diseo producen un modelo
arquitectnico, un diseo de base de datos, un diseo de interfaz externa y un diseo de componentes
internos, los cuales forman los planos para la construccin y prueba del sistema.