Edward Yourdon - Análisis Estructurado Moderno

NALISIS STRUCTURADO ODERNO
LI I

Edward Yourdon

Traduccion:

Revision Tecnica:

Guillermo Levine Gutierrez

Director Facultad de Informatica y Cornputacion Universidad de Guadalajara

PRENTICE+IAll HISPANOAMERICANA, S.A.

Mexico m Englewood Cliffs - Londres - Sydney - Toronto Nueva Delhil - Tokio - Sinqapur - Rio de Janeiro

EDICION EN ESPANOL

DIRECTOR:

EDITOR:

GERENTE DE TRADUCCION:

SUPERVISOR DE TRADUCCION GERENTE DE PRODUCCION:

SUPERVISOR DE PRODUCCION:

Raymundo Cruzado Gonzalez lose Tomas Perez Bonilla Jorge Bonilla Talavera Enrique Palos Baez

£loy Pineda

Teresa Parra Villafana

EDICION EN INGLES

Editorial/production supervision: Sophie Papanikolaou Cover design: Wanda Lubelska Design

Manufacturing buyer: Mary Ann Gloriande

EDWARD YOURDON: ANAUSIS ESTRUCTURADO MODERNO VE

Traduccion de la primcra edicion en ingles de

MODERN STRUCTURED ANALYSIS

Prohibida la reproduccion total 0 parcial de esta obra, por cualquier media 0 metoda sin autorizacion por escrito del editor.

DERECHOS RESERV ADOS © 1993 respccto a la primera edicion en espafiol por PRENTICE-HALL HISPANOAMERICANA. SA

Enrique Jacob 20, Col. Conde

53500 Naucalpan de Juarez, Edo. de Mexico

ISBN 968-880-303-0

Miembro de la Camara Nacional de la Industria Editorial, Reg. Num. 1524

Original English Language Edition Published by Copyright © J 989 by Prentice-Hall Inc,

All Rights Reserved

LlTOGRAFICA INGRAM EX, S.A DE C V CENTENO 162-1

MEXICO, OJ

CP.096lO

ISBN 0-13-598624-9

IMPRESO EN MEXICO I PRINTED IN MEXICO

CONTENIDO

PARTE I 1

:2

3

4

5

6

PARTE II 13

9

HI

'!

:2

13

14

15

15

PARTE !II 17

'IS

H1

PREFAC!O vii

INTRODUCCION lntroducclon 1

La naturaleza de los sistemas '10

los perttclpantes en el [uego de los sistemas 45 Herramlentas del anallsls estrueturado 12

EI ciclo de vida del proyecto 86

Aspectos tmportantes en el desarrollo de sistemas 1 '11 Cam bios en el anattsls de sistemas 136

LAS HERRAMIENTAS DE MODELADO

Caraeterlstlcas de las herramlentas de mcdetado 149

Diagramas de de datos 157

E! dlcclonarlo de datos 211 Eapeclflcaciones de proceso 227 Diagramas de entldad-relaclon 260 Dlaqrarnas de translclon de estados 288 Baianceo de modetes 305

Herramlentas adlclonales de modelade 319 Herramlentas de modelado para admlnlstraclon de

340

El PROCESO DE ANAUSIS EI modele esenclal 352

EI mooelo amblental 368

Construcclon de un modele prettmlnar de cornportamlento 395

v

SEGUIM!ENTO

Pasando al dlsefic 452

Programacion y prueba 470 Mantenimiento de la especificacion 492 E! futuro de! anausls astructurado 499

20 21

PARTE IV 22

23

24

25

Termlnado del modele de eompcrtamlento 408 EI modele de tmptentaelen de! usuarlo 419

APENDICES

A Herramientas automatlzadas 513

B Reg!as de estlrnacton 534

C Ca!culo de costc/benetlclo 549

D Auditorfas e Inspecelones 568

E Tecnlcas de entrevtsta y recolecelon de datos 575

F Oasc de estudio: Yourdon Press 588

G Case de estudlo: EI del elevador 693

Lo que es valioso no es nuevo y 10 que es nuevo no es valioso.

Henry Peter, Lord Brougham The Edinbo/gh Review, 1802

INDICE AlFABETICO 123

P errnltanrne cornenzar par hacer una pregunta muy lmportante: irealmente necesite ef mundo de otro libra de ana/isis de sistemas? Esto pudiera parecer una pregunta pero ha habido muchas ocasiones, usualrnente yo. entrada la no-

al estar trabajando en este libra, que me he prequntado: que estoy ha-

ciendo esto? hay de malo con los dernas hbros que todo rnundo ha estado leyendo durante los ultimos diez afios? .:,C6mo puedo tener la esperanza de afiadir algo 0.1 cuerpo literario existente?"

Obviamente, seran otros los que tengan que juzqar los resultados. Perc sf pienso que es necesario un libro que actualice algo del material clasico de anal isis estructurado que se publico per prirnera vez a finales de 10. decada de los 70. Cuando Tom DeMarco escribio Structured Analysis and Systemas Specification, y Chris Gane y Trish Sarson e scrlbieron Structured Systems Analysis: Tools and Techniques, no existlan los de proqramaclon de cuarta generacion y no nabla herrarnlentas de creacion de prototlpos disponibles para los creadores de sistemas. Las computadoras personates no existian en dias, a excepcion de de las rnaquinas primitivas de Apple y Radio Shack. No nabta productos de software para estaciones de traba]o que pudleran auxiliar al analista de sistemas en

la creaclon de diaqramas de de datos.

EI desarrollo en sstas areas ha tenido un gran impacto en la aceptacion generalizada del anal isis estrueturado: muchos discuten sobre sl el analisis estructurado es pertinente en un arnbiente en el que los usuaries crean sus propias apticaciones en cuestion de horas 0 de dias, Esto por sf solo es razon para crear un nuevo libra que trate el terna del analisis de sistemas: la dlsponibilidad de tecnoloqla enormemente mas poderosa, tanto para analistas de sistemas como para el usuario, ha cambiado nuestro entoque y perspectiva.

Adernas, los creadores de sistemas tuvieron que hacerse cargo de cuestiones como sistemas de bases de datos y sistemas de tiempo real, as! como de los sistemas "orientados a funciones" originalmente tratados POl' el analisis estructural a fines

vi

vii

viii PREFACIO

de la decada de los 70. Este libra analiza los diaqrarnas de entidad-relaclon y de transicion de sstados, ademas de los clasicos diaqramas de flu]o de datos, y muestra como pueden lnteqrarse los tres modelos: esta Inteqraclon de modelos se volvera mas y mas [mportante en los anos venideros. Se han mcluido en este libro varies otros avances recientes en el anal isis ostructurado, incluyendo la particion de eventos y la rnenor importancla del rnodelado de los sistemas tisicos actuates,

Existe una razon mas para escribir otro tibro sobre el anal isis de sistemas: la rnayorla de los libros "clasicos" de analisis estructurado sstan dirigidos a analistas de sistemas adultos y vsteranos, con poca ° ninguna consideracion para la persona mas [oven que apenas cornienza en el campo. AI mismo tiernpo, ta mayoria de los textos unlversltartos que tratan el anallsls de sistemas y que se ascribieron durante los ultimos diez aries prestaban escasa atancion a las nuevas tecnlcas de anal isis ostructurado y han continuado dedicando dernasiadas paqinas a otscusiones sobre las tarjetas perforadas y los codiqos Hollerith. Adernas del hecho de que rnuchos de estos ternas son obsoletes, generalmente se otrece un estudio superficial del hardware de las computadoras, el software y la proqrarnacion per medic de un curso de "introduccion a la oomputacion" que precede ria a un curse a profundidad de analisis de sistemas. Este libro procura ser balanceado al reconocer que es necesario alqun material lntroductorlo para el estudiante que ha lIevado un curse de lntroduccion a las computadoras pero que nunce ha hecho analisis de sistemas, al mismo tiempo que reconoce que los conceptos del analisis astructurado son 10 suficientemente sencillos como para ser presentados en bastante detalle a nivel de bachillerato y a nivel universitario. Sin embargo, la mayor parte del material introductorio se coloco en los apendices, de modo que pueda omitirlo el protesional en la industria.

EI libro debe ser aproplado para un curse de anal isis de sistemas de un sernestre, en el nlvel de llcenclatura; cubre los ternas para el curse CIS-86/5 en el curriculum modele "CIS 86" para la licenciatura en informatica. Sin embargo, no pretends abarcar tanto el terna del analisis de sistemas como el de SL! diserio, a pesar de que varias universidades tratan de cornprender ambos en un solo sernestre. Creo que hay bastante material para discutir en cada una de las des areas; recomiendo, para un curso de un sernestre de disefio astructurado, los siquientes libros:

Practicai Guide to Structured Systems Desing, soqunda adicion, de Meilir Page-Jones (YOURDON Press, Englewood N 1988), 0 bien Structured Design, segunda edici6n, de Ed Yourdon y Larry Constantine Press, Englewood Cliffs, N.J., 1989).

Es posible que los vetoranos del analisis de sistemas quieran leer s610 el primer capitulo para orientarse y saltarse el reSIO de la parte I; los siete capitulos son esenciales para los estudiantes nuevos. Los veteranos estaran familiarizados can los diagramas de flujo de datos, los diccionarios de datos, etc. Sin embargo, en el capitulo 9 hay material que trata de las extensiones de los diagramas de flujo de datos para los sistemas de tiempo real, que pudieran ser novedosos para aquellos que se hayan dedicado exclusivamente a los sistemas de

PREFACIO ix

negocios. Tambien pudieran ser novedosos los diaqrarnas de entidad-relacion para los que esten mas tamiliarizados con los "diagramas de estructura de datos"; el capitulo 13, que trata de los diaqrarnas de transiciones de estados, brinda una herramienta de modelado nueva e importante. Y algo que es de suma irnportancia para el vsterano: los capltulos 19 y 20 brindan un plantearnientc que contrasta enormernente con el enfoque rfgido de arriba-aba]o que han seguido los anallstas durante arias para la construccion del modele esencial (a veces conocido como el modelo loqico); se trata del metoda conocido como petticion de eventos, basado en la obra de MeMenamin y Palmer. E! Capitulo 17 recomienda que se a/imine e! entoque ctesico de modeler el sistema actual del usuerio; los analistas de sistemas cuya tecnica se basa en textos de la decada de los 70 debleran estudiar esto con cuidado.

Entre los apendlces hay dos casos que ilustran las tecnicas y herrarnientas que se tratan en este libro. EI primero es una aplicacion tipica de negocios, basada en la operacion de la editorial YOURDON Press; el segundo es un ejernplo mas caracterlstico de un "sistema de tiernpo real", basado en el sistema de control de un elevador. Ambos se presentan con detalle, aunque esto haga mas qrueso el

es importante para el estudiants vet un ejemplo complete de una especitlcaclon. Ambos modelos pueden usarse para discusiones y ejercicios en clase.

EI sneltets estructureao moderno utillza afios de experiencla con cientos de clientes, miles de estudiantes y docenas de colegas de las ernpresas YOURDON, lnc., y de otras orqanizaciones. Me declare en deuda con todas estas personas, que son dernasladas para poderlas nombrar. Pero hay alqunas que merecen una mencion especial, pues me ayudaron a intentar que este libro fuera mejor. En la actualidad no se puede escribir un libra de anal isis sstructurado sin darle reconocimlento a las obras precursoras de Tom DeMarco, Chris Gane y Trish Sarson. Y me siento igualmente en deuda con Steve McMenamin y John Palmer, quienes dieron un irnportante paso adelants con su obra Essential Systems Analysis; de manera similar, Paul Ward y Steve Melior lntrodujeron varios conceptos y herramientas importantes para los sistemas de real can su obra de tres volumenes, Structured Devefor Beet- Time Systems. Tarnbien me han ayudado los debates que he tenido con otros colegas, al ensefiar anal isis e structurado en Estados Unidos e Aqradezco de manera especial a John Bowen, Julian Morgan, Bob

geon, Nick Mandato y Alex Gersznowicz par haberme rnostrado maneras rnuy elocuentes de explicar el anal isis estructurado que jarnas se me hubieran ocurrido. Adernas, el protesor Peter Brown y un grupo de alum nos suyos de la Universidad depuraron el libro, at utillzarlo como texto para un curso de analisis estructurado; les agradezco sus sufrimientos con todos los errores tipograficos que tetlfcm los primeros borradores.

Tambien agradecerle a Dennis Stipe de la sucursal en Washington

D.C. de YOURDON, Inc., por el intense trabajo de amilisis que hizo en el modelo de snalisis estructurado del sistema de elevadores del apendice G. La mayorfa de los textos actuales solo contienen casos de estudio de sistemas orientados a los nego-

1. Par que es el anansis de sistemas.

que es dittcil el anaiisis de

proqramacion.

que es estar tamlllarlzado can

analisis sistemas.

x PREFACIO

cios: sste libro contiene tanto un case orientado a neqocios (apendlce F), como un

ejernplo de tiernpo basado en la descripcion de la ACM [Association for Compu-

Machinery, N. de! de un problema real. Original mente, Dennis disefio el mo-

dele de analisls estructurado para un serninarlo de de disefio" patrocinado par la seccion Washington de la ACM, en 1 con el proposito de rnostrar como se manejarla el problema del control de un sistema de cuatro alevadores can las direrentes rnetodoloqlas de mqenlerta de software; desde sntonces se ha modificado verias veces.

PARTE

1 :

INTRODUCCION

Peter Brown, Pete Coad, Bob Spurgeon, Steve Weiss, Ron Teemley y Dale Brown mejoraron enormemente el borrador de ests libra can sus revisicnes y comen-

obviarnente, me hago rssponsable de todos los errores cometidos y de las orrusiones que aun Mientras tanto, mi esposa y rnis me dieron un gran apoyo abasteciendorne continuamente de Coca Cola dietstica y papitas (y ocasionalmente cognac, cuando la ocasion 10 para cuando acabe el habia aumsntaoo 10 kilos de peso y tuve que ponerrne a dieta,

En contrasts con 10 que los auto res paranolcos como yo suelen sutrir a manes de los editores, varias personas de YOURDON Press/Prentice Hall hicieron de la produccion de este libro una experiencia encantadora. Pat Jenny y Ed Moura viqilaron el proyecto desde el principia y me die ron anirnos cuando mas 10 necesitaba. Sophie Papanikolaou supervise la produccion del libro y tue un placer trabajar con ella. Bill Thomas se encarqo de ta revision del libro y encontro los miles, 0 millones, de errores tlpoqraficos y qrarnaticales. Despues, mi esposa, Toni, corriqic de buen qrado todos los errores en la computadora, aunque ta escuche murmurar en voz baja que un maternatico no deberla pretender que sabe escribir.

EI comienzo y el final de toda actividad hurnana son desordenados: la construcci6n de una casa, la escritura de una novela, la dernolicion de un puente y, eminentemenle, el termino de un viajs.

John Galsworthy Over the River, 1933

En este capitulo

aprendera:

Finalrnente, me qustarla aqradecerle a mi(s) computadorats) Macintosh per batallar vatlenternente con 131 enorme rnanuscrito. La mayor parte del escrito se hizo con Microsoft Word (verslones 1.0, 1.05, 3.0, Y 3.01) pero tambien utilice MacPalnt, SuperPaint, MacDraw, Microsoft Chart, MacProject, Microsoft ChessMaster, ConcertWare, MORE de Living Videotext, MacBubbles de StarSys lnc., y Design de Meta Software, sin contar varlos fragmentos de "arte de! recorte" de T/Maker y otros editores. Ouienquiera que intente escribir un libro con algo que no sea una Macintosh deberia ir a que le axarninen la cabeza.

Edward Yourdon

Nueva York, agosto de 1988

Aqul estamos al cornienzo de un largo libro. La perspectiva de leer un libro tecnico tan largo probablernente 10 aterrorlce: pero, SI le sirve de consuelo, es aun mas aterradora la perspectlva de estar cornenzando a escribitto. Atortunadamente, as! como los viajes largos se llevan a cabo un dla por vez y, por ultimo, un paso a la vez, de igual manera se acaban de leer los libros largos un capitulo por vez y, a fin de cusntas, una trase a ta vez,

1.1 (,POR QUE ES INTERESANTE El ANALISIS DE SISTEMAS?

Los libros largos a menudo son aburridcs; espero que este no 10 sea. Por fortuna, el terna de sste libro, enetisis de sistemas, es tnterssante. De heche, el analiSis de sistemas es mas interesante que cualquier cosa que yo conozca, can la

4 INTRODUGC!ON

INTRODUCCION 5

Aun cuando no se vaya a dedicar a un ernpleo de oficina decir, si plonsa

ser artista, escrltor, rnusico 0 arleta) , debiera saber de que trata el anal isis de sistemas. Los sistemas cornputactonales de diversos tlpos afectan a toda clase de personas. Aun si [amas piensa construlr un sistema computacional ni hacer que Ie disefien uno, es inevitable que vaya a hacer uso de sistemas computacionales para sus finanzas, su educaclon, SU interacclon con las oflcinas de impuestos y del sequro social, y para cast cualquier interaccion que pueda Ilegar a tener con la sociedad moderna. Como 10 afirrna John Gal en su obra Systematics [Gall, 1977J.

Hemos encontrado una extrana huella en las playas de 10 desconocido. Hemos elaborado profundae teorlas, una tras otra, para explicar su origen. Finalmente hemos tenido exito en reconstruir la crlatura que hizo la huella. Y, [sorpresel. somes nosotros,

Nadie puede, hoy en dia, evitar el contacto con los sistemas. Los sistemas estan en todas partes: sistemas grandes, sistemas pequenos, sistemas mecaniccs y slectronicos, y aquellos sistemas espeelates que consisten en asociaciones organizadas de personas. En defensa propla, debemos aprender a vivir con los sistemas, a contra/arias antes de que ellos nos controlen a nosottos. Como Ie dijo Humpty Dumpty a Alicia (aunque en otro contexte): "La pregunta es: qulen ha de ser el arno, eso es todo."

Otro proposlto de este libro es hacerle entender y apreciar que vivirnos en un mundo de sistemas, y de sistemas dentro de Sistemas, que son parte de otros aun rnayores. Por tanto, todo 10 que hacernos en nuestras vidas personates y protesionales tiene impacto (a menudo inesperado y no anticipado) sobre los diversos sistemas de los cuales tormamos parte. Este entoque de "pensar en sistemas" no s610 es vital para los analistas proteslonales sino para todos los rniernbros de nusstra soeiedad rnoderna,

Como habra adivinadc, uno de los principales propositos de este llbro es

ensefiarle mas ace rca del analisis de sistemas: que es y como se las arreqla uno para llevarto a cabo, Perc aun hay mas: rni verdadero proposito es emocionetto, antusiasmarlo tanto con ernpezar a practicar el analisis de sistemas que querra acabar

este libro a toda y cornenzar a trabajar en su primer proyecto,

hace la siquiente remernbranza en su obra Mindstorms [Papert, t 980],

Encontre un placer particular en sistemas tales como la caja de velocidades diferencial, que no sigue una simple cadena lineal de causalidad, puesto que el movimiento en el eje de transrnision puede distribuirse de muchas formas diferentes a las dos ruedas, de pendiendo de la resistencia que se encuentre. Recuerdo con mucha claridad mi emoci6n al descubrir que un sistema podia ser valido y completamente cornprensible sin ser rigidamente determinlstico.

Desqraciadarnente, este libro no 10 podra convertir en un analista de sistemas con experiencla, como tarnpoco un libro de teorla musical puede convertirlo en pianista experimentado. Para cuando terrnine este libro, sstara arrnado con una tremenda cantidad de informacion que 10 ayudara a desarroilar moaelos precisos de sistemas complejos, y conocera paso a paso las tecnlcas para etectuar un esfuerzo de analisis de sistemas. Sin embargo, necesttara aun una gran cantidad de traba]o concreto para poder desarrollar habilidades: como entrevistar a una variedad de diterentes usuaries para sntender la verdadera esencta de un sistema; como presenter los resultados de su traba]o de analisis de sistemas para que todo mundo pueda darse cuenta de los verdaderos costos y beneficios de desarrollar un nuevo sistema; como diterenclar problemas de sintornas. Como seriate Bohem en su obra clasiea, Software Engineering Economics [Bohern, 19811:

Cada uno de nosotros como ingeniero de software "individual" tiene la oportunidad de causar un irnpacto positlvo en la sociedad, simplsrnente votvlendonos mas sensibles a las profundae implicaciones que nuestro traba]o tiene en las relaciones humanas, y al incorporar esta sensibilidad a nuestros productos y diseRos de software,

Para entatizar esto aun mas, tenqa en mente que la industria de las cornputadoras represento aproximaoamente el 8% del producto interne brute (PIS) de los Estados Unidos en 1985; para 1990 se espera que ropresente 131 15% delPIB 3 Casi todos los productos tabricados hoy por las ernpresas arnericanas involucran una 0 mas cornputadoras, y casi eualquler servicio ofrecido at mercado por las ernpresas nortearnericanas se basa en, 0 es control ado por, un sistema computaclonal.

t.s QUE !-lARA ESTE lIBRO POR USTEIJ

Hacer esto bien requiere algo de practice, as! como aprender a balancear las cuestiones de relaciones humanas con la programaci6n y con los asuntos economicos cuantitativos. La gran cosa que hay que recordar al hacerlo es mantener claras nuestras prioridades entre ta prograrnacion, los presupuestos y las relaciones hurnanas,

1.4

ORGANIZACION DEL lIBRO

Hemos encontrado que donde la ciencia mas ha avanzado, la mente no ha hecho sino recuperar de la naturaleza 10 que puso en ella.

Este libra esta orqanizado en cuatro partes principales, sequidas de una serie de apendices. La parte I sirve de intrcduccion a todo el libro y este cornienza, en el capitulo 2, por una lntroduccion al concepto de sistemas y la naturaleza del anal isis de sistemas; en este capitulo verernos que los sistemas de informacion usualmente estan compuestos por personas, hardware, software (proqramas de computadora). procedimientos, datos e informacion. EI capitulo 3 describe a las personas que normalmente estan involucradas en el desarrollo de un sistema moderno de inforrna-

Y como dijo Sir Stanley Eddington [Eddington, 1987],

3 Para mas detalles sobre esto, as! como para otros anal isis sobre el irnpacto de las computadoras en la sociedad, vease Nations at Risk [Yourdon, 1986].

6 INTRODUCCION

cion: los usuaries, los adrmntstradores, el personal de operaciones, los miembros del qrupo de control de caudad, etc., y el papel especial y las responsabilidades del anatista de sistemas. EI Capitulo 4 introduce las herramlentas de model ado que el analista de sistemas utlliza, incluyendo diagramas de flu]o de datos, diaqrarnas de entldad-relacion y dlaqrarnas de transicion de ostados. EI capitulo 5 prssenta los prooedimientos (0 la metodologia) que el analista sigue cuando desarrolla un sis-

tema.

Aunque usted crea conocer rnuchas de estas cosas va, hay algunos capltulos en la parte I que es importante que lea, porque definen el tono del resto del libro. EI capitulo 2, por ejemplo, prssenta V discute los axlornas V princlplos fundarnentales que esperariamos encontrar en todo el traba]o de analisis de sistemas: el desarrollo de rnodelos de sistemas, la nocion de rtsraclon, V la nocion de particlon de arribaaba]o. Y el capitulo 6 delinea las principales cuestiones que snfrenta el analista de sistemas hoy: ousstiones de productlvldad, calidad de sistemas, mantenlrniento, V utitlzacion sstrateqlca de informacion. Finalmente, 61 capitulo 7 resume los prlnclpales cam bios que han sucedido en el campo del analisis de sistemas en los ultimos

diez aries.

la parte II trata de las herramientas de modelado de sistemas con detalle. los capitulos mdividuales cubren ternas de diaqramas de tlu]o de datos (capitulo 9), dlccionarios de datos (capitulo 10), especificacion de procesos (capitulo 1'1), diaqramas de entldad-relacion (capitulo 12), y diaqrarnas de transicion de estados (capitulo 13). los capitulos t 5 Y i 6 presentan otras narramientas de modelado que utilizan los analistas cuando astudian un sistema: diagramas PERT, diagramas de Gantt, diagramas de tlujo, diagramas HIPO, diagramas de estructura, etc. Como podrernos ver, estas nerrarnientas de rnodelado permttiran enfocarnos selectivamente a los aspectos individuales de un sistema cuyas caracterfsticas es lrnportants entender: las tunciones que el sistema debe desemperiar, los datos que debe rnanejar V su comportamiento en el tlernpo.

Aun cuando usted nunca yea una computadora al tsrmlnar de leer este libro, as harrarnientas de modelado de la parte II pueden serle utiles para modeler (0 describir a imaginarse) practlcamente cualquiertipo de sistema: biolootcos, de neqocios, ecosistemas. sistemas de rnanutactura, politicos, de flu]o de rnateriales, etc. Vivimas en un mundo de sistemas, Y la mayor parte de nuestra vida cotidiana se ernplea tratando de comprender y trabaiar con los multiples sistemas con los cuales entrarnos en contacto: las herramientas de modelado son de snorme ayuda en este as-

pecto.

La parte III se refiere al proceso de analisis de sistemas, es decir, los pasos que un analista lleva a cabo cuando construye el modele de un sistema. Aqui tambien, la informacion que obtendra sera de utilidad independientemente de su profeslon: el material definitivamente se dirige hacia la construccion de sistemas de informacion automattzados. Veremos que el proceso, 0 metodologia, para construir

INTRODUCCION 7

un sistema involucra el desarrollo de dlversos tipos de model os, el ultimo de los cuales sera el producto del analisis de sistemas. En rnuchas ernpresas este producto se conoce como "especificacion funcional'', 0 "docurnento de requerimientos de neqocios", 0 "disefio de sistemas de neqoclos", lndependienternente de su nombre, es el material para los responsables de Ia construccion rnisma del Sistema, es decir, de disefiar la arquitectura general de las computadoras V su software y, finalmente, de escribir y probar los proqrarnas.

Esto nos tleva a 10. parte IV: la vida despues del anallsis de sistemas. Explorersmos el paso desde el anal isis de sistemas hasta el disefio y discuttrernos brevemente los detalles finales de la proqramacion y la prueba, Dado que la mayoria de los sistemas de informacion autornatlzados tienen una vida media de varies anos (y a menudo de varias decadas), tam bien discuttremos el tema del mantenimiento en 81

24: perc nuestra preocupacion no sera la proqremecion para el

sino el mantenimiento del prcducto del analisis de sistemas. EI ulti-

treta del futuro: los carnbios evolutivos en 81 campo del anal isis de sisteesperar vet durante los aries 90 y el

los Apendices que se encuentran al final del libra tratan cuestiones separadas que pueden 0 no !legar a atactarto cuando comience a trabajar como analista de sistemas. EI por mane]a el tema de las estaciones de trabajo basadas en PCs para el anal isis de sistemas, a 10 cual cocos analistas ten ian aceeso a cornienzo de la decada de los 80, pero que se han vuelto cada vez cornunes en los aries 90. EI B expone las formulas de estimacton y 10. rnetnca utllizadas para calcular 81 tamario, duracicn y costo de un proyecto. EI C analiza los calculos de costa-beneficia. EI 0 cubre el tema de los recorridos y las

( que a menudo S6 utilizan para rsvisar los

tecnicos del analisis de sistemas. EI E analiza las tecnicas de entrevista y

de sobre todo para entrevistas que se [levan a cabo entre el

usuario y el analista de sistemas. Todo esto se ha acomodado en apendlces para

que el anallsta pueda saltarse Iacitrnente los que considers

los estudiantes pueden recurrir a los apendices cuando sea con-

veniente para cubrir ternas que surqiran durante los proysctos reales.

Los Apendices F y G presentan dos cases de estudio: uno es un sistema

orientado a los y el otro es un sistema de tiernpo real. Si usted es un es-

tudiante que aJ final de cada capitulo debera reterirse a estes casas de estu-

dio para ver como pueden aplicarse a situaciones reales los principios recien De heche, deberla leer la Introduccion y antecedentes de Gada case de estudlo ahora, para famiiiartzarse con 10. naturalsza de cada apllcacion.

tiene preguntas y ejercicios que 10 ayudaran a revisar 10 que ha ejercicios estan etiquetados como "proyectos de investiqacion", que S8 entocan a hechos que no estan cubiertos directarnente en el perc que son pertinentes en el mundo real del analisis de sistemas. Algu-

8 INTRODUCCION

nas de las prequntas estan entocadas a dlscuslones en clase; no hay respuestas 00- rrsctas 0 incorrectas, aunque sf hay respuestas que son mas taciles de defender que otras.

Terminernos can las introducciones y ernpecernos. Comenzaremos por hablar de la naturalsza de los sistemas.

REfERENCIAS

I. Tom DeMarco. Structured Analysis and ~,,,,,,,p,,,c; Specification. Englewood

N.J.: 1979, paqina 6.

2. New York:

New York Times Book

3. Software Engineering Economics.

ce-Hall, 1981.

N.J.: Pranti-

4.

Papert, Mindstorms. New York: Basic Nations at Ris«. Englewood

i980.

N.J.: VOURDON

5. Edward 1986.

6. Sir Arthur Stanley Eddington, Time and Gravitation An Outline of the Ge-

neral Theory. London: Cambridge University i 987.

PREGUNTAS V EJERC!CIOS

t. Explique como puede serle uti! el analisis de sistemas en su t;;U;I[.""'V 0 protesian, aun si no planes convertirse en proqrarnador 0 analista.

2. Proyecto de investiqacton: l,Cuantas personas empleadas como analistas de sistemas en el pais hoy en dia? l,Cual es su salario promedio? l,Cuai es su nivel promedio de educacion?

3. Proyecto de investiqacton: escasez de prcqramadores y analistas de sistemas? Trate de encontrar estadisticas de industrias 0 del Gobierno (por ejemplo de la Secretarla de Cornercio 0 de alquna tundacion cientifica nacional) que prediqan los requerirruentos nacionales de analistas de sistemas durante los proxirnos 10 arios.

4. De 10 ejernplos de sistemas con los que trata 0 con los cuales interactua en su vida cotidiana,

5. estudiando anal isis de sistemas sl no tuviera la necesidad de hacerlo?

SI su respuesta es "No", expliqua por que piensa que el material 110 sera util 0

INTRODUCCION 9

pertinents. Encuentre . otra persona que estudls sste rnismo material y

un debate construcnvo rsspecto a la utilidad general del anausts de siste-

mas.

6. ,usted lmpcrtanrs que las personas que no utilizan computadoras (0 que

no tienen una proteslon relacionada) astudien anansts de sistemas? tan

conocedoras cree que deban ser en este terna?

es probable que el anal isis de sistemas sea mas interesants que la G Esta de acuerdo con este punto de vista?

GQue casas debe un analista de sistemas aparte de las habilidades

tscnicas para construir rnodelos de sistemas?

90 que pueden ser utiles para estudiar sistemas no

rramientas de rnodelado en este libro?

las he-

Finalmente, pondrernos al Sol mismo en ,el centro del Univ:rso, Todo esto 10 sugiere la sistematica proceslon de sU,cesos, aSI como la armonia del Universo sntero. si tan s610 encararamos los hechos, como se dice, "can ambos ojos abtertos".

Nicolas Copernico De Revo/utionibus Orbium Coeiestfum, i 543.

10 se

este

v

en

5.

7.

10

LA NATURALEZA DE LOS SISTEMAS 11

No podernos decir mucho acerca de! analisis de sistemas hasta que tenqamos una idea clara de 10 que es un sistema: este es el proposito de este capitulo, Como verernos, existe una definicion "oficial" del terrnino en el diccionario, que parecera algo abstracta. Sin embargo hay rnuchos usos comunes del termtno que Ie seran tarniliarss y existen muchos tipos cornunes de sistemas con los que tenemos contacto todos los dlas.

Se pusde sstar prequntando "(_ Y que?", Es irnportante estar tamltiarizado can diterentes tipos de sistemas debido, por 10 msnos ados razones. Primero, aunque su traba]o como anallsta de sistemas probablemente se entoqus en alqun tlpo de sistema de informacion computarizado, general mente torrnara parte de un sistema mayor. Ast, usted tal vez pueda estar haciendo un sistema de nomina que forma parte de un sistema de recursos nurnanos, que a su vez forma parte de alquna orqantzacion (que en sf, es un sistema), que a su vez es parte de un sistema economlco mayor, etc., 0 bien puede estar haciendo un sistema de control de procesos que es parte de una refinerla qulrnica 0 un sistema operative que sea parte de un "paquete" de software suministrado por el proveedor. Asl, para que su sistema tenga exito, debe sntender los dernas sistemas con los que va a interactuar.

Muchos de los sistemas cornputarizados que construirnos son reernplazos 0 nuevas versiones de sistemas no computarizados que ya extsten, Tarnbien, la rnayoria de los sistemas computarizados interactuan 0 tienen interfases con una variedad de sistemas exlstentes (algunos de los euales pueden estar cornputarizados y otros no). Para que nuestro nuevo sistema sea exitoso, debernos entender can razonable detalle como se comporta el sistema actual.

Segundo, aunque rnuchos tipos de sistemas parezcan bastante diterentes, resulta que tienen sirnllitud: existsn principles, teorias y filosoftas comunes que se aplican muy bien, practicamente , a toaos los tipos de sistemas. Por ello, frecuentemente podemos aplicar 10 que hernos aprendido acerca de otros sistemas =-basandonos en nuestra experiencia diaria, y en la de diversos tipos de cientiflcos n'Q,C""_ a los sistemas que construirnos en el campo de la cornputacion. Por uno de los principles importantes de sistemas, prtmerarnente observado en e! campo de la bloloqla, es conocido como la ley de la especializacion: entre mas adaptado se encuentra un orqanisrno a un ambiente especltico, mas diffcil le sera adaptarss a un ambients diferente. Esto ayuda a explicar la desapartcion de los dinosaurios cuando cambia drasticarnente el clirna de Ia tierra 1, Y tambien ayuda a los anallstas a entender que Sl optirnizan un sistema computarizado para obtener la rna-

1 Los paleonl61ogos aun estan dlscutiendo esto: unos piensan que los dinosaurios desaparectsron en el curse de un periodo relativarnente breve, tras el lrnpacto de un gran meteorito con la Tierra, que orlqino una nube de polvo tan densa que mate a la mayorla de las plantas, Otros argumentan que el carnbio iue rnucho mas gradual, ocurrido en el transcurso de casi un millen de anos. De cualquier modo, los dinosaurios estaban altarnente adaptados a un determinado tipo de ambiente y no pudieron adaptarse a otro.

12 LA NATURALEZA DE LOS SISTEMAS

xirna ventaja de un procesador, de un lenguaje de proqramaclon y de un sistema administrador de base de datos, probablernente tendran qrandes dificultades para adaptar dicho sistema de forma que se ejecute en un procesador diterente 0 con un sistema de administracion de base de datos diferente.2

De que sl comprendemos ace rca de la teorie genera! de sistemas

nos ayudara a entender los sistemas computarizados (automatizados! d~ informacion. Esto se vuelvs cad a vez mas irnportante, pues se desea construir ststemas estsbtes y confiables, que tunclonen bien en nuestra compleja sociedad, y existen desde mucnos ejemplos de sistemas no cornputarizados que han sobrevivido durante millones de anos: la humilde eucaracha probablemsnte durara mas que cualquier sistema que se haya podido construir, y mas que toda

ta humanldad tarnbien.

As! empecernos con una definicion del termino basico: sistema. Todo li-

bro de texto que cubra de los sistemas contiene tal definicion; he es-

cogido el New de que ttene varlas detiniciones:

1. de elementos 0 que lnteractuan regular-

mente tormando un todo «un - sistema numerieo »: como

a.

(1) Un qrupo de cuerpos que interactuan bajo la lntluencia de tuerzas ralaclonadas «un - qravltacional>

Un de sustancias que tiendan al equilibrio «un -

terrnodlnamlco»

b.

(1) Un qrupo de orqanos del cuerpo que juntos Bevan a cabo una 0 mas tunciones vttales <e\ - diqestivo»

(2) EI cuerpo, ccnsiderado como una unidad funclonal

e. Un grupo de tuerzas u objetos naturales -cun - de rlos»

d. Un qrupo de aparatos 0 una orqanizacion que forma una red, especialmente para distribuir algo 0 para servir a un proposito cornun <un - telefonico>, <un - de calefaccicn>, <un - de autoplstas», «un - de proceso de datos>

2 Tambien puede ayudar al analista de sistemas a enlender 131 fen6meno del usuario que cornunmente suele realizar actividades tan especializadas que no hay manera de camblarias aunque sean computarizadas. Y le recuerda que si Ilega a desarrollar un sistema computarizado altamonte especializado para la aplicacion actual que quiere el usuario, sera muy dificil adaptarlo lueqo, cuando cambien a evolucionen los raquerimientos de este (y 131 ambiente en 01 cual traba]a).

3 New Collegiate Dictionary de Webster, Springfield, Mass.: G.& C. Merriam Company, 1977.


2. Juego orqanizado de doctrinas, ideas 0 principios, usualmente con

la intenclon de el acomodo 0 traba]o de un todo sistematico

<el - newtoniano de la rnecanlca»

3. a. un procedirniento orqanizado 0 establecido <el - de mecanoqratia al tacto»

b. una rnanera de clasificar, sirnbolizar 0 esquematizar «un - taxonomtco» -cel - decimal>.

4. patron 0 arreqlo armonioso: ORDEN

5. una sociedad orqanizada 0 situacion social ccnsiderada como anuladora: ORDEN ESTABLECIDO

2,1 TIPOS COMUNES DE SISTEMAS

Como podernos ver de la existen rnuchos tipos diterentes

de sistemas; de casi todo aquello con 10 cual ontramos en contacto durante

nuestra vida cotidiana es un sistema 0 bien parte de un sistema (0 arnbas cosas).

l.Significa esto que debernos estudiar tcdo de sistemas 0 intentar conver-

tirnos en sxpertos en sistemas socrates, bioloplcos y iPara nadat

Sin embargo, es util orqanizar los diferentes tipos de sistemas en cateqorlas. Son

rnuchas diterentes tormas de de heche, la definicion obtenida

del diccionario rnuestra una cateqonzacion. Dado que nuestro son los sistemas cornputacionales, empezarernos por dividir todos los sistemas en dos catsqorlas: sistemas naturales y sistemas hechos pot el hombre.

2.2 SISTEMAS

La gran rnayorta de los sistemas no estan hechos per el hombre: existen en la naturaleza y slrven a sus propios fines. Es conveniente dlvidir los sistemas naturales en dos subcateqorlas basicas: sistemas tisicos y sistemas vivientes Los sistemas flsicos incluyen ejernplos tan variados como:

" Sistemas estelares: galaxias,

etcetera.

" Sistemas qeologicos: rlos, cordilleras, etcetera.

" Sistemas rnoleculares:

cornplejas de atomos.

Es interesante estudiar los sistemas ffsicos pues, como humanos entrornetidos que sornos, a veces querernos moditlcarlos. Tarnbien desarrollarnos una variedad de sistemas hechos por el hombre, lncluyendo sistemas computaclonales, que deben interactuar armonlcarnente con los sistemas tislcos: per tanto, suele ser

tante rnodelar dichos sistemas para asequrarnos que los comprendernos 10 mas completarnente posible.


los sistemas vivientes, desde lueqo, cornprenden toda la qama de anlmales y plantas que nos rodean, al iqua] que a la raza humana. como 10 menciona James Miller en su monumental obra, Sistemas vtvientes [Miller, 1978], esta cateqorla tambien cornprende [erarqulas de orqanismos vivientes individuales, por hierbas, manadas, tribus, grupos sociales, cornpafiias y naciones,

EI estudio de los sistemas vivientes es una carrera en una breve lectura de

la obra de Miller rnostrara 10 enorme que es dicho terna. EI proposito de este libra no es estudiar los sistemas vivientes per se; pero algunas de sus propiedades y caracteristicas farniliares pueden utilizarse para ayudar a llustrar y entender mejor los sistemas hechos por el hombre. A menudo utilizamos una analcqla para entender mejor alqo con 10 eual no estarnos tarntliarlzados: entre las mas elocusntes de las anatcqias entre sistemas vivientes y sistemas orqanizaclonales y de negocios, renemos las obras de Stafford Brain of the Firm 1972] y The Heart of Enterprise [Beer, ; 978].

Una analoqia mas elaborada puede obtenerse de la cateqorizaclon hecha por Miller de los 19 subsisternas crfticos de todos los sistemas vivientes. MiHer arqumenta que los sistemas vivos, sean estes de nivel celular, de organa, de orqanismo, de qrupo, de orqanizaclon, de sccieoad 0 de sistema supranacional, contienen los siquientes subsisternas:

.. EI reproductor, que es capaz de dar oriqen a otros sistemas sirnllaras a aquel en el cuat se encuentra. En una orqanlzacion de neqocios, pudiera ser una division de ptaneaclon de instalaciones que hace nuevas plantas y construye oficlnas regionales nuevas,

.. La irontere, que rnantiene unidos a los componentes que contorman el sistema, los protege de tensiones ambiantales y excluye 0 permits la entrada de diversos tipos de rnateria-enerqta e informacion, En una orqanizaclon de neqocics, esto pudiera constituir la planta misma de oficinas, fabrica, etc.) y los quardtas u otro personal de sequrldad que evitan el inqreso de intrusos indeseables,

.. EI inyectot, que transporta la rnateria-enerqla a traves de la frontera del sistema dssde el medic ambiente. En una orqanlzacion de neqocios, este pudiera ser el departamento de cornpras 0 recepcion, que introduce la materia prima, los rnateriales de oficina, etc. 0 pudiera ser el departamento de pedidos, que recibe padidos verbales 0 por escrito de los serviclos 0 productos de la orqanlzacion.

.. EI aistribuiaot, que trae material desde el exterior del sistema y 10 reparte desde sus subsisternas a cada cornponente. En una orqanlzacion de neqoclos, pudiera estar contormado per las uneas teletonicas, correo electronico, mensajeros, band as y una variedad de otros rnecanismos.


.. EI convertidor, que cambia ciertos rnateriales que Inqresan at sistema a tormas mas utiles para los procesos especiales de dicho sistema particular, Nuevamente, se puede imaginar un buen nurnero de ejernplos de esto en una orqanlzacion de neqocios

® EI productor, que forma asociaciones sstables durables por periodos nificativos con la materia-enerqia que ingresa al sistema 0 que eqresa de su convertidor. Estes materiales sintetizados pusden servir para creelrnianto, reparacion de darios 0 reposicicn de cornponentes del sistema, 0 bien para proveer enerqia para mover 0 constituir los productos 0 la informacion de mercado a su suprasisterna.

.. EI subslstarna de etmecensmiento de meterie-enerqie, que retiene en ei sistema, durante diterentes periodos, depositos de diversos tipos de rnateria-enerqla.

.. EI expulsor, que transmits rnateria-enerqia hacia el exterior del sistema en forma de desechos 0 de productos,

'Il EI motor, que mueve el sistema 0 a sus partes en relacion con todo 0 parte del medio amblente, 0 bien que mueve a los cornponentes del ambiente.

.. EI soporie, que rnantiene las relaciones espaciales apropiadas entre los componentes del sistema, de rnanera que puedan interactuar sin ser un lastre 0 estorbo entre ellos,

e EI trensductor de entrada, que trae sen ales portaooras de informacion al sistema, transtormandolas en otras tormas de materia- enerqia adecuadas para su transrnlsion al interior.

" EI trensductor intemo. que recibe de otros subsisternas 0 cornponsntes del sistema seriales que portan informacion ace rca de alteraciones significanvas en dichos subsisternas 0 componentes, transtcrmandotcs en otras torrnas de materia-enerqla transmisibles en su interior.

.. EI canal y fa red, que estan compuestos per una sola (uta en el espacio Hsico, 0 bien por multiples rutas interconectadas, mediante las cuales las senales portadoras de informacion se transmiten a todas las partes del sistema.

.. EI aecodiiicedor, que altera las claves de informacion que Ie es lntroducida por medio del transductor de entrada 0 del transductor interne, para dejar una clave privada que pueda ser utilizada internamente per el sistema.

.. EI esociedor, que lleva a cabo la prirnera etapa del proceso de aprendlzaje, torrnanoo asociaciones duraderas entre elementos de informacion dentro del sistema.

16 LA NATURALEZA DE lOS S:STEMAS

..

La memoria, que lleva a cabo la secunda etapa del proceso de <>""",nrl,

je, alrnacenando diversos tlpos de informacion en el sistema durante dltsrentes periodos.

EI que que recibe informacion de todos los dernas suosisternas y

les transmits informacion que sirve para controlar al sistema complete.

E! que altera la clave de informacion que se le introduce desde otros subsistemas procesadoras de informacion, de una clave. privada utilizada internamente por el sistema, en una clave

que ser por otros sistemas en su media amblente,

EI ttensductor de que ernite senates de mfcrrnacton

desde el transtormando los rnarcadores dentro del sistema en

otras torrnas de materia-enerpia que ser transmitidas por medic de canales en el rnedio ambients del sistema.

Las figuras 2.1 y 2.1 rnuestran un ejernplo de los 19 prlncipales subsis-

ternas de un de comunicaciones en un crucero transoceanico las fi-

~uras 2.2 muestran los principales subsisternas del crucero y las

flguras 2.3 y 2.3 rnuestran los principalas subsisternas de toda Holanda. Vale

la pena estudiarios, pues ilustran el heche de que sl se observe sistema

que tiene componsntes vivientes, es localizar los princlpales subsisternas.

en mente que rnuchos sistemas hschos per el hombre (y sistemas autornatizadcs) interactuan con sistemas vivientes: per ejernplo, los marcapasos cornputarizados tnteractuan con el corazon humane. En algunos cases, se dlsefian sistemas automatizados para a sistemas y en los investlqadores consideran a los sistemas vivos (conocidos como como cornponentes de sistemas automatizados. Veanse [Hall, 1 [Shrady, 1 y 1984] para analisis de este de vista. los sistemas vivientes y los sistemas hechos por el hombre a menudo forman de un metaststerna mayor, y entre mas entendarnos ace rca de ambos, de sistemas serernos.

2.3 SISTEMAS HECHOS POR El HOMBRE

Como pudirnos apreclar de la definicion que se encuentra al cornienzo de este capitulo, un buen numero de sistemas son construidos, orqanizados y rnantsnidos per hurnancs, e

.. Sistemas sociales: Or(1::lrH7~lf;ll"ml~;: de Ieyes, doctrinas, costurnbres, etcetera.

.. Una coleccion orqanizada y cisclpltnada de ideas: el sistema decimal Dewey de orqanizaclon de libros en bibliotecas, el sistema de reduccion de los cuida-kilos, etcetera.

lA NATURALEZA DE lOS SISTEMAS 17

Sistemas de transports: redes de carreteras, canales, aerollneas, buques carqueros, etcetera,

.. Sistemas de cornunicacion: teletono, senates de humo, senates de mana utilizadas per los corredores de bolsa, etcetera.

..

.. Sistemas de manutactura: tabrlcas, lineas de ensamblado, etcetera.

Sistemas financieros: contabilidad, res etcetera.

llbro mayor, bolsa de valo-

En la actualidad, la rnayorfa de estes sistemas incluyen las

hecho, rnuchos no podrlan sobrevivir sin elias. Sin es igualmente

tants sanalar que dichos sistemas existlan antes de que hubiera cornputadoras: de

heche, algunos sistemas continuan per complete sin computarlzar y perrna-

necer as! durante muchas decadas mas. Otros contienen a la como

cornponente, perc tarnbien uno 0 mas no computarizados

per la trase comun, "Juan tiene un sistema para llevar

a cabo su trabajo" 0 "Vaya que Marfa tiene una rnanera sistematica de hacer su tra. Tales Irases no nscesariarnente suqieren que Marfa ha computarizado su o que Juan ha utilizado algunos de los lnstrumentos torrnales de rnodelacion discutidos en los capitulos 9 y i 0 para documental' (0 modeler) como propene hacer su traba]o. Perc ciertamente las trases implican que Juan y Marfa han dividido su en una serie de pasos definidos, la suma acumulativa de los cuales

algl.1n proposlto general.

EI que un sistema de tactura humans deba 0 no ser cornputarizado es una cuestion que discutlrernos a 10 largo de este no es a/go que se debe dar par hecbo. Como analista de sistemas, usteo naturalmente supondra que todo sistema

con el que se encuentre debera y el ciiente 0 usuarlo dueno del

en cuestton) con quien listed rnteractua tal

Como verernos en capttulos posteriores, su labor como analista

de sistemas sera anatizar 0 estudiar el sistema para deterrninar su esencia: su comrequerido, indeperuiientemente de la tecnoloqia utilizada para el sistema+. En la mayona de los cases, deterrninar si tlene santido utilizar una cornputadora para llevar a cabo las funciones del sistema s610 tras haber rnodelado su cornportamiento esencial.

"Por que no debieran automatizarse algunos sistemas de procesarniento de informacion? Puede haber muchas razones; he aqul alqunas de las mas cornunes:

.. Casto. Puede ser mas barato continual' Ilevando a cabo las tunciones y

alrnacenando la informacion de! sistema en forma manual. No es

4 Sa discutiran los modefos esencieles y la esencie de un sistema en 61 capitulo 17.


cierto que las cornputadoras sean mas rapidas y economicas que el mstodo "anticuado'',

..

Conveniencie, Un sistema automatizado puede ocupar dernaslado espacio, hacer dernasiado generar dernasiado calor 0 consumir dernasiada electricidad, a bien, en general, ser una mclestia. Esto va dejando de ser as! con la creciente influencia de los rntcroprocesaoores, pero sigue siendo un factor a considerar.

Seguridad. Si €II sistema de informacion mantlsne datos confidenciales, el usuario pudiera no creer que el sistema autornatizado sea 10 suficientemente sequro; tal vez desee mantener la informacion Hsicarnenta proteqida y ba]o uavs.

Facilidad de mentenimiento. EI usuario pudiera arqurnentar que un sistema de informacion cornputarlzada serfa costeable, excepto por €II hecho de que no hay ning0n miembro del personal que pudiera encarqarse del mantenimiento de! hardware y 0 el software de la computaoora, de manera que nadis podrta reparar el sistema si este sufriera un despertscto, nl habria quien pudiera efectuar carnbios 0 mejoras.

Potttices. La comunidad usuaria pudiera recalar que las cornputadoras amenazan con privarla de sus ernpleos 0 con volver aburrldos o "mecanicos" sus trabajos 0 con una docena de otras razones que el analista de sistemas podrta considsrar Irracionalas. Perc dado que se trata del sistema del usuario, sus recelos son de prlmera importancta. Si no dessan tener un sistema automatizado, haran todo 10 posible por lograr que falle si se les quiere imponer.

2.4 S!STEMAS AUTOMATllADOS

La mayor parte de este libro se concentrara en los sistemas euiometizedos, es decir. en sistemas hechos por el hombre que interactuan con 0 son controlados per una 0 mas cornputadoras. Sin duda, usted ha visto muchos ejsrnplos diferentes de sistemas automatizados en su vida cotidiana: pareee ser que casi cada aspecto de nuestra soctedad modems esta cornputartzado. Como resultado, podernos distinquir rnuchos tipos diferentes de sistemas autornatizados.

Aunqus hay diterentes tipos de sistemas automatizados, todos tienden a tener cornponentes en cornun.

EI hardware de fa computadora: los procesadorss, los discos, terminates, irnpresoras, unidades de cinta maqnetica, etcetera,

EI software de te computsdoru: los proqrarnas de sistemas tales como sistemas operatlvos, sistemas de bases de datos proqrarnas de control de

LA NATURALEZA DE LOS SISTEMAS ,9

Subsistemas que procesan tanto rnateria-enerqla como informacion: frontera de a bordo (80), la pared del cuarto de radio (artetacto).

Subsistemas que procesan la matena-snerqra: El ingestor la carnarera

cue trae comida al cuarto de radio desde la cocina del el distribuidor (01),

~I carnarero que reparte la com ida a los miernbros del equipo de comunicaciones: el convertidor (CO), el camarero que parte €II pan y corta la came y el queso para los sandwiches; el productor (PR), el carnarero que hacs los sandwiches y el ca-

el almacenista de materia-enerqla (MS), el camarero que almacena diversos tlpos de artetactos, incluyendo alimentos en el refriqerador, sacos y qorras de los rniernbros del equipo en el closet, mantas y almohadas en el armario y

herramientas y equipo en una gaveta; el expulsor el camarero que se lleva

los utensitios usados, Ia basura y otros desechos cuarto de radio; el 0

sustentador el las el y los rnuebles del cuarto de radio

Subsistemas que procesan informacion: el transductor de entrada 0 mtroductor el operador de radio que recibe los rnensajes; el transductor inter- I, no el capataz de turno que lntorma al oficial de senates en jefe sobre la 'Ii eficiencia y animo de los miembros del equipo en su turno: el canal y la red

todcs los miembros del grupo que se intercomunican per medic del nabla que se ,

transmite a traves del aire del cuarto de radio; el decodificador el operador

de radio que transcribe a la propia los recibldos en clave

la sscretaria que lleva el de todos los

el decididor el oficial de sefiales en

el codificador en Morse el

al c6digo Morse los rnensajes: el transductor de

"" ... r s-ar trvr de radio que transmlte los mensajss por esta via.

salida

2.

Subslstemas de un

..

telecomunlcaciones, adernas de los proqrarnas de cabo las tunciones deseadas por el usuario,

Las personas: los que operan ei Sistema, los que proveen su material de entrada y consumen su material de salida, y los que proveen actividades de prccesamiento manual en un sistema.

que llevan a

.. Los datos: la informacion que el sistema recuerda durante un periodo.

.. Los procedimientos: las poittlcas tormales e instrucciones de operaclon del sistema.

Una manera de ordenar por cateqortas los sistemas automatizados es por su eoticecion: sistemas de manutactura, sistemas de contabiudad, sistemas de defensa


2.1 (b): Subalstemas de 1J!1 equlpo de eomunlcaclones de un erucero

rnilitar, etc. Sin embargo, esto no resulta muy pues las tecnicas que discutlremos en este libro para analizar, modelar, disefiar e irnplantar sistemas automatlzades generalmente son las mismas, independientemente de su aplicaclon.s

5 Sin embargo, cada aplicacion liene su vocabulario, cultura y procedlmlentos propios. EI usuario per 10 general espera que ei anafista de sistemas sepa algo acerca de los detalles, polltica y procedimientos de la aplicacion, para no tensr que explicarte todo desde el principio. Por 10 tanto, si va a desemperiar el traba]o de anal isla de sistemas en un banco, probablernente Ie sea util aprender cuanto pueda acerca de la banca. No es camino de un solo sentido: los banqueros aprenden cad a dla mas ace rca de la tecnologia de los sistemas de informacion.


Subsisternas que proeesan tanto rnateria-enerqfa como informacion: el

reproductor los representantes de la eorporacion propletaria: la trontera de

a bordo (80), el casco del barco y el personal que 10 protege y Ie da

Subsisternas que procesan la el inqestor la escotilta

cue conduce a la del barco y el personal que ayuda a los a

~bJfdar y que estiba el equipa]e y el carqamento a bordo del barco; el distribuidor

los pasitlos, y escaleras, y los carnareros, rneseros y rnozos que

llevan alimentos, bebidas, equipa]e y otros diversos de materta-enerqta per

dichos paslllos, adsrnas de los que per elias se de un lado

a otro del barco; el convertidor el personal de la las

verduras y prepare otros comestibles para el los que

cocman la comida y los que laboran en la del barco; el

almacenador de la bodega del barco y los tanques de

combustible, y el personal responsable de ellos: 01 expulsor la chirnenea

para desechos qaseosos, salidas para la basura y drenaje para los desechos

> y sotidos, y el personal de responsable de asequrar que los

desechos sean ellminados adecuadarnente: el motor los rnotores del barco,

su helices y todo el casco del barco, que rnuevsn tripulacion y

carqarnento a travss del mar, junto con los ingerueros de loqrar es-

te rnovimiento: el soporte el casco, los tlancos, las paredes y los pusntes

del barco, y el personal que los mantiena.

Subslsternas que procesan la informacion: el transductor de entrada (in), el ooerador de radio y otros miernbros del equipo de comunicactones que reciben

> para el barco; el transductor interne el otlciat que intorma al oficial

de mando sobre el estado de los diversos componantes que forman el barco; el canal y la red (en), el aire que rode a a los oficiales en el puente, a traves del cual

transmiten y reciben rnensajes: el decodificador el operador de radio en el

de cornuntcactones que descifra los mensajes en clave dejandolos

en lenqua propia despues de ser recibidos; la memoria (me), los cuadernos de

bitacora de travesias pasadas, mapas rnarlttrnos y el que los consults en

el cuarto de rnapas: el decididor el capitan y otros oficiales de a el

codificador en clave Morse (en), el operador de radio del equlpo de comunicaclones que traduce los rnensajes de la lengua propia al codiqo Morse para su transmision; el transductor de salida (ot), el operador de radio y otros miernoros del equipc de comunicaciones que transrnlten rnensajes dasde e! barco.

Figura 2.2(a): Prtnclpales suoststemas de un crucero


2.2(b): Prlnclpeles subsistemas de un crucero


Figura 2.3(8):


Los subsistemas que procesan tanto Ia materia-energta como Ia informacion: La frontera <S> . las organizaciones que

defiendcn, cnidan 0 imponen Ia ley en Ia frontera nacional.

Los subsistemas que procesan I" moteria-energfa: EI ingestor ~J organizationes como las acroltneas, cl Ierrccarril. las

compentas de rransporte terrestre de carga y las de transporte marnimo, que importan diversas form as de materia-energfa al interior

del pals; cl distribuidor

, las organizacioncs nacicnales que transportau diversas forrnas de mareria-energfa per mar.

tierra. ferrocarrtl 0 por via aerea; eJ convertldor

, las organizaciones que convierten !<1S formas primas de materia-

1 . d d. el duct [ft'Yfttt.JI!as oruanizaciones que Iabrican productos para el

energia a rormas que puede utilizar a SOCle a ; (;1 pro uctor -

. d .' '1 expolsor rl·.~ ... ~V"> l1Il] . las organtzacioncs que

pres as y plantas electricas que aimacenan diversos upos {' materia- encrgra; e .'

exportan 1,0$ prcductos holandcscs a otros paises , o que descargan desechos en ei mar. y las agendas que deportan a las personas

, las unidades de transporte. la Industria dc hi construccion, las fuerzas armadas 0 la agenda

I

I

[

, los edificios pcbltcos y 1;;; tierra,

espacial; el soporte

Los subsistemas que procesan lu informacion: c! transductor de entrada

, las or ganizaciones que reciben sefiales de

relegrafo, cable, telefouo o radar, 0 bien noticias extranjeras que vicnen de mas aHti de las fronteras holandcsas: el transductcr

interne

, la tejrislatura. los ditigentes de parridos polntcos y las crgamzecicnes de eucuesta publica que reciben

, los sistemas de comunicaciones nacionales; el

informes y cornurricacion de [ado ei pais; c! canal y las redes

la oficina de rclac.iones exteriores que decoditica los meuxajeS secretes recibidcs par las embajadas de

, las instituciones educativas hofandcsas ; la memoria

Holuada en rode el mundo: cl asociador

bihlictecas: el que decide

;;j):;'\

la rein" Y su Gobierno en La Hay"; e l codificador ~W, of Secretano de Prensa

gubernamental holandcs o los autcrcs de discursos; el transducror de salida

las personas que dar; los comunicados

oficiales de Holanda.

Figura 2.3(b):

.jas

LA NATURAlEZA DE lOS SISTEMAS 25

Una division en cateqorias mas uti! de los sistemas autornatlzados es la siguiente:

'" Sistemas en linea

'"

Sistemas de tiernpo real

Sistemas de apoyo a decisiones Sistemas basados en el conocimiento

Examinaremos con cuidado cada uno de estes.

2.4.1 Sistemas en linea

En un libra anterior [Yourdon, 1972], defin! los sistemas en linea de la siquient8 forma:

Un sistema en linea es aquel que acepta material de entrada directarnente del area cones se creo, Tambisn es el sistema en el que el material de salida, 0 el resultado de la computacion, se devuelve directamente a donde es requerido.

Esto usual mente stqnlfica que el sistema computacional tiene una hardware parecida a la de la figura 2.4.

de

Una caractertstlca comun de los sistemas en linea es que entran datos a la computadora 0 se les recibe de ella en forma remota. Es dscir, los usuaries del sis-

tema normal mente interactuan con Ia cornputadora desde terminalesf

que sstar localizadas a cientos de kilometros de fa rnisma.

Otra caractertstica de un sistema en linea es que los datos alrnacenados, es

decir, sus archives 0 su base de usualrnente se de tal rnanera que

los individuales de informacion un reqistro individual de re-

servacion aerea 0 un individual de ser recuperadas rno-

diflcados 0 arnbas cosas y 2) sin tener necesariarnente que etectuar

accesos a otros componsntes de informacion del sistema. Esto contrasta enorrne-

mente con los sistemas tuera de linea 0 en totes que eran mas comunss en

las decadas de los afios 60 y 70, En un sistema par la informa-

cion SUEde recuperarse de una manera que el sistema

cornputacional lee todos los de la base de y actualizando

aUU,""Ub para los cuales La diterencia entre un sistema

6 Actualmente, la palabra "terminal" se usa de manera tan cornun en la sociedad que en realidad no requiere definirse. Sin embargo, entsrese de que hay muchos sin6nimos: "pantalla", "estacion de trabajo", "teclaco", etc. Ademas, hay abreviaturas cornunes (en 61 ingles de usc habitual en intermatica) para describir la unidad de entrada/salida que se emplea para cornunicarse con !a cornputadora, como "CRT" para describir el "tube de rayos catodicos", "VDU" para la "unidad de exhibiclon visual", etc. Estos terminos se utilizaren indislintamente a 10 largo del libro.


nal por lotes y uno en linea es analoqa a la ~iferencia ~ntre ~ncontrar una seleccion musical aspaclfica en un cassette 0 en un disco; 10 pnmero Involucra 131 acceso secuancial a traves de todas las pistas, mientras que 10 segundo parmite el acceso "aleatoric" a cualquiera de las pistas sin tener que oscuchar las dsmas.

Dado que un sistema en linea lnteractua dtrectamente con per~onas (per ejernplo, usuaries humanos en sus terrninales), es tmportante que 131 an.allsta de .slstemas planes cutdadosamente la intertaz humano-computadoraJ Es decir, 131 analista debe tsner alguna manara de moaeter, esto, es, de crear model~s de todos los posibles mensajes que 131 usuario humane puede teclear en su terminal, y de todas :as respuestas que 131 sistema pudiera dar, adamas de todas las respuestas que pudiera dar el humane ante las respuestas de la computadora, etc. Esto usualment~ se Il~va a cabo ldentlficando todos los ssrados en los que la cornputadora y el usuano pudleran sncontrarse, e identificando todos los cambios de estado. Un ejemplo ?e un estado en el que pudiera sncontrarse una cornputadora de un si~tem~ .de cajero ba~cano autornatlco es "el usuario ha insertado su tarjeta y se ha identificado, pero aun no

La informacion se teclea desde 81 lugar de oriqen

~

I

Los datos se organizan de modo que se pue dan recobrar tacilmente

La salida se transmite a donde es requerida

Figura 2.4: Un sistema en linea

7 A menudo se hace referencia a esto como "dialogo hornbre-rnaquina", 0 ."interfaz hombr~-n::aquina", Cad a vez son mas las organizaciones de desarrollo de sistemas que utlllzan la expresion interfaz humano-computadora" 0, simplemente, "interlaz humana" para svitar las lnterenclas sexistas.


me ha dado su clave secreta". Un ejernplo de cambio de estado es "me ha dado su clave secreta Y ahora puedo proceder a deterrnlnar si desea retirar etectivo 0 desea que le inforrne ace rca de su estado de cuenta". Otro carnbio de estado pudiera ser "ha tratado sin exito de inqresar su clave tres veces y ahora voy a hacer sonar la atarme". Estes estados y cambios de sstado sa rnodelan tlplcarnente con dieqremes de trensicion de estedo, que dlscutirernos con detalle en 01 capitulo i 3.

Dado que los sistemas en linea por 10 cornun requieren recuperar datos con -apidez (para poder responder a prequntas y 6rdenes provenientes de terminales en linea), suele ser muy irnportante disefiar los archives y las bases de datos de la rnanera mas eficiente posible. De heche, a menudo las opereciones de computecion Ilevadas a cabo POl' un sistema en linea suelen ser relativamente trlviales, rnientras que los datos (sobre todo, la sstructura y orqanizacion de los datos rnantenida por 81 sistema en linea) suelen ser bastante cornplejos. De aqul que las herrarnientas de modelado de datos discutidas en el capitulo 12 sean de gran irnportancia para 131 analista y para el diseriador de sistemas.

La decision de convertir 0 no un sistema ordinario en un sistema en linea es, en el contexte de este una decision de pueste en preciics, es declr, no es algo que debiera ser determinado por el analista de sistemas sino mas bien por las personas que ponen en practica el sistema. Sin embargo, dado que decidir tal cosa tiene un tan obvio en el usuarto (Ia presencia 0 ausencia de terminates de cornputadora, etc ), es una decision de puesta en practice en la cual habitual mente los

usuaries querran participar. De hecho, es parte del modele de en orectice

de! usuerio que discutiremos en el 21. .

Sistemas de

un sistema en

real es considerado por rnuchos como una variante de muchos usan ambos terrrunos indistintarnente. Sin

utilizarernos la definicion de

as

Un sistema cornputacrona: de liempo real puede detinirse como aquel que controla ambiente recibiendo datos, procesandolcs y devolviendolos can la suficiente rapidez como para influir en dicno ambiente en ese memento.

f-'K'H{~",,",n "con la suficiente desde

sxisten rnuchos sistemas en linea

uno 0 de ya Esto es caracterfstico de los si-


@ Sistemas de control de procesos: los sistemas cornputacionales que se utilizan para verificar V controlar refinertas, procesos quimicos, molinos y operaciones de maquinado.

Sistemas de cejeros eutometicos: las de elective" que muchos

de nosotros usamos para hacer depositos y retiros sencillos en el banco.

Sistemas de alta veiocided para edoutsicion de datos: los sistemas comque obtienen datos de telernetrla a alta velocidad de satell-

tes en orbita 0 las cornputacoras que cantidades enorrnes de

datos de de laboratorio.

Sistemas de

de proyectiies: los sistemas que defer-feW,,,, de un proyectil y nacer ajustes continuos a la de los

orientacion y

Sistemas de conmutecion teletonice: sistemas trolan la transrnislon de voz y datos en miles de llarnadas

tectando los nurneros condiciones de ocupado y todas las

dernas condiciones de una red teletonica

de sistemas que de-

vitales" de diversos pacientes (per ejernplo, temperatura V V que son capaces va sea de ajustar el msdlcarnento

adrrunistrado 0 de hacer sonar la alarrna si los vitales se mantlenen tuera de ciertos umites ,v,:ori<=>,"

Adernas de la existe otra caracteristica que ditsrencia a los siste-

mas de real de los sistemas en linea: estes ultimos suelen interactuar con las

personas, rnientras que los sistemas de con personas COMO con un ambients que en es autonomo y a rnenudo

hcstil. De del analista de sistemas en real

es que, si la no responde con la suficiente el ambtente pudiera

tuera de los datos de entrada pudieran perderse sin remedio 0 un

salirse de su tanto va no fuera recuperarlo,

o bien que un proceso de rnanutactura pudiera exptotar". En cambro, un sistema en linea que no con la suficientemente en no hare. mas que volver irnpacientes V qruriones a sus usuaries. Si tienen que esperar mas de tres sequndos la respuesta de un sistema en las personas "sxplotar" en sentido figurado, perc no en senti do literal. Esto se ilustra en la figura 2.5,

8 Uno de los ejemplos mas interesantes de una sltuaclon de tiempo real es el de un equipo de traba]o cuya rnision era unir una pequeria cornputadora a una bomba nuclear. Cuando se detonara la bomba (como parte de un programa de pruebas), la cornputadora dispondrta tan solo de UIlOS cuantos microsegundos para capturar tantos datos como fuera posible y transmitirtos a un sistema de cornputadoras remoto, antes de que se desintegraran el hardware y software per la explosion, Ese sf que es una real exigencia del procesamiento an tiernpo real.

Dada la con la respuesta instantanea a las entradas del

un analista que traba]a en sistemas de real general mente estara muy preocu-

per el comportemlento del que el sistema Discutire-

rnos las herrarnientas para el rnodelado del del

en el 3.

Paso del


Estimulo

tiernpo

Figura 2.5: un sistema de

real

como

de vista de su puesta en los sistemas de real

sistemas en sa caracterizan por 10

se Ileva a cabo el proceso de

actividades.

Se diterentes a diterentes procesos:

(en servicio inmeciato rnientras que otros pueden razonabtss.

Se una tarea antes de

yor prioridad.

para comerizar otra de rna-

"

Exists gran comunicacion entre especial mente dado que rnuchas tratan diferentss aspectos de un proceso general, como el control de un proceso de manutactura.

Existe acceso stmuttaneo a datos comunss, tanto en memoria como en el atmacenarmanto secundario, por 10 cual se requiere de un elaborado proceso de srncronizaclon V "sernatoros" para asequrar que los datos cornunes no se corrornpan.


'" Existe un uso y asiqnacion dlnamiccs de memoria RAM en 81 sistema computacional, dado que a menudo resulta poco econornico (aun cuando la memoria sea barata) asignar suflciente memoria para rnanejar situaciones pice de alto volurnen.

2.4,3 Sistemas de apoyo a daetstcnes y sistemas de planeaclen estrateqlea

La mayor parte de los sistemas autornatlzados de informacion que se crearon en los Estados Unidos durante los ultimos 30 arias son sistemas operecioneies que ayudan a Ilevar a cabo los detalles del traba]o cotldiano de una orqanizacion. Estes sistemas, que tam bien se conocen como sistemas de procesamiento de trsnsecciones, incluyen ejemplos tan tamiliares como los sistemas de nomina, de ccntabitidad y de manutactura. En rnuchas organizaciones, en todo Estados Unidos, estes sistemas oporacionales se han creado lenta, penosamente y a alto costa. Dado que muchos de ellos se iniciaron hace mas de 20 anos, estan al borde del colapso. De aqui que conttnuamente se esten creando nuevos sistemas operacionales en las principales orqanizaciones del rnundo entero.

Sin embargo, dado que los sistemas operacionales actuates continuan tambaleandose, muchas orqanizaciones se estan ontocando su atencion a un nuevo tipo de sistemas: los de epoyo a fa tome de oecisiones. Como 10 impllca el termino, estos sistemas cornputaclonales no ternan declsiones por SI mismos, sino ayudan a los admlnistradores y a otros profesionistas "trabajadores del conoctmlento" de una or-

ganizacion a tamar decisiones Y docurnantadas acerca de los divsrsos

asnactos de la los sistemas de apoyo a decisiones son pa-

sivos en el sentido de que no operan en forma mas se utillzan de rnacuando se les necesita.

Exists un gran numero de sencillos de sistemas de apoyo a decisio-

nes: proqrarnas de de catculo ejernplo, Lotus 1-2-3, de

Framework de Ashton , sistemas de anal isis ssradlstico, programas de

tico de etc. una caraoterlstlca cornun de los sistemas de apo-

yo a decisiones es que no solo recuperan y exhiben los datos, sino que tam bien realizan varios de analisis maternaticos y estadisticos de los mismos. Los sis-

temas de apoyo a decisiones tam bien tisnen la en la

sos, de presenter la informacion en una variedad de form as

al que en forma de convenclonales. En la fi-

gura 2.6 se rnuestra una de calculo financiers caracterfstlca que

para svaluar las de division dentro de su

:::'.7 es una qrafica las de dicha division com-

de la industria. Notese que en ambos cases la informacion por el sistema no "torna" una decision, sino que proves informa-

cion relevante para que el decidir.

sistemas de apoyo a decisiones son utiles para articular y macanizar

las utuizadas para lIegar a decision de Uno de estes siste-


mas es un programa llarnado .Lightyear (de Liqhtyear, lnc.), que se ejecuta en com~utadoras ~e~sonales compatibles con IBM. Permits 211 usuario (0 a usua(lOs)( describir los detalles de ~n pro~lema ~ue requiem decislones: un ejemplo podr,a ser 61 problema de decidir en donde ubicar una nueva oficina, Primeramente el usuario identi.fica los criterios que se utilizaran para tomar la decision. Para el problema .de ubicar una nueva oticina esto pudiera incluir, por sjernplo, que "debe se: :cce~lbl~ e,~ transports publico': v 9ue "no == estar en una zona de alta probablli?""d sismica. Algunos de los critenos son binaries, en el sentido de que si no se satisface uno de ellos, se elimma una alternativa 0 se ocasiona la selecclon autornatica de otra. Algunos de los criterios pueden clasiticarse en una escala nurnerica: por eJemplo, ~no ~e los criterios pudiera ser la tasa de irnpuestos corporativos, loe euales tornaran diferentes valores nurnericos dependiendo de la ciudad y estado donde ~e ubiqus la nueva oficina. Y los criterios mismos clasificarse entre sf: pudiera ser que la importancia de los irnpuestos sea de 5 puntos en una escala de 1 0, mlentr~s que la conveniencia de tener algun centro comercial cercano pudiera valer 3 '. Habiendo definido los criterios para llevar a cabo una las diversas alternatlvas ser evaluadas y analizadas; la rnejor alternativa autornatlcamen-

te sera seleccionada per el proqrarna La 2.8 ilustra este prcceso.

, . No hay nada rnaqico en esto: el prcqrarna meramente en una forma me-

canlc~ las ,:eglas. de evaluacion provistas por el usuario. Perc el del sistema

va mas all,a del Simple calculo mecanico: Iuerza al usuario a articular su crite-

(10, 10 cua: a menudo no se hace. Tarnbien otrece una neutral de obtener

las de varies usuaries en eituaciones en las que es de

un consenso, En un asunto ernocionalmente delicado, como reubicar una oficina

... , . reuolcar a las Iarnlllas de Ilevan a cabo la s ser

utu no solo articular los criterios de sino tambien la claslficacion de criterios

he~ha po~ cad a persona que en la decision. SI dos miembros del cornlte de

reumcacion de oficinas estan en debiera clare por 10 menos

se basa su oesacuerdc.

acermas

de Ptansacion a

tratarse de una activldad mas infer-

durante la Se-

obviamente la 1 no son programas de cornbinaciones de actividades y

La guerra rnundial desds rnucho

i

Cl C2 C3 C4 TOTAL La forma de la otra caracterlsnca
Ventas nacionales 400 425 250 375 1450 sistemas de informacion que se encontrar en 10. de las
Ventas internacionates 100 150 200 125 575 nes en dla: el temeiio de los sistemas en
Cuotas por licencias 25 60 50 25 160 o en millones de instrucciones de exceds por rnucho al de los sistemas
Ingresos diversos 10 10 15 10 45 de apoyo a la torna de decisiones y 0.1 de los sistemas de Pe-
TOTAL DE INGRESOS 535 645 515 535 2230 (0 esperar que esto cambia gradual mente a 10
Costo de ventas 123 148 118 123 513 da. Como sa rnenciono muchas
Salarios 100 120 120 125 465 uttimos 30 anos sus sistemas en gran el trebe-
Otros gastos de empleo 15 18 18 19 70 de la labor que se lleva a cabo actual mente en
Renta 15 15 15 18 63 de esas conslste en el desarrollo de sistemas
Teletono 20 20 20 20 80 de apoyo a la toma de decisiones y de sistemas de
Correos 5 6 5 7 23
Viajes/diversiones 10 10 10 10 40
Contabilidad/asuntos legales 10 10 15 10 45 -------------
Depreciacion 12 13 13 14 52 9 Existen algunas excepclones: las organizaciones mas psquenas aun no han cornputartzado la
Gastos diversos 5 5 5 5 20 mayor parte de sus operaciones diarias; los viejos sistemas desarrollados per las compafilas Fortu-
TOTAL DE GASTOS 315 365 339 351 1371 ne 500 en ia decada de los aries 60 estan al borde del colapso; los nuevos sistemas que se necesi-
lan para las fusiones de empresas, las adquisiciones ':! los estudios de mercado ':! nuevas
GANANCIAS/PERDIDAS 220 280 176 184 859 productos; adernas la comunidad de la deter.sa aparentemente tiene una lista interminable de nue-
vos sistemas que se necesitan crear. Sin embargo, la tendencia general es Ia de olvidar los siste-
Figura 2.6: tabulado de una de calculo mas operacionales ':! dedicarse a los sistemas de apoyo a las decisiones. 32 lA NATURAlEZA DE lOS SISTEMAS

muchas de los cualss las llevan a cabo hurnanos utilizando informacion obtenida de tuentes externas (estudios de msrcado, y datos tnternos de los sistemas operacionales de la orqantzacion y los sistemas de apoyo a decisiones. Steiner seriala que hay muchos de sistemas de ptaneaclon ostrateqica, sequn el tamano y naturaleza de la orqanizacion.

Las figuras 2.9 y 2.10 rnuestran dos modelos tlplcos. EI sistema de planeacion estratsqica basada en el analisis de brecha de posicion trata de identificar la discre-

panola entre la actual de la (en terminos de qananclas, renta-

y la los accionistas y otros.

Los sistemas de ptaneacton sstrateqica contorrnan por sf solos un terna y no

se trataran con detalle en este libra. Harernos sntasts en los siste-

mas de apoyo a decisiones y los sistemas operacionales.

Notese la relacion existents entre los tres distlntos tipos de sistemas que se discuten en ssta seccion, Como 10 muestra la 2.11, los operacionales ta base sobre la cual se clrnentan los sistemas de apoyo a decisioLos sistemas operacionales creen los datos

por los sistemas de nivel y contmuan actualizando los datos de

una rnanera continua,

lA NATURALEZA DE lOS SISTEMAS 33

Ventas de rnercancias

12

10

8

• Venta de rnereancias

Ventas en millones

6

4

2

o

80 81 82 83 84 85 All 0

2.7: Una

hecha con un sistema de apoyo a la torna de declstones


Sistemas basad os en e! ccnoclrnlentc

Un terrnino relativamente novsdoso en la industria de las computadoras es el de "sistemas 0 "sistemas basad os en 81 conocimiento". Dichos sistemas se asoclan con el campo de la mtellqencia artificial, la cual Elaine Rich defini6 de la slqulente rnanera [Rich,1984]:

La meta de los cientificos de la cornputaclon que trabajan en el campo de la inteligencia artificial es producir programas capaces de imitar el desempei'io humane en una gran variedad de tareas "inteligentes". Para algunos sistemas expertos la meta 8sM proxima a ser alcanzada: para otros. aunqus aun no sabemos construir programas que runcionen bien por sf solos, podemos cornenzar a crear programas cap aces de auxiliar a las personas en la ejecuci6n de alguna tarea.

Calificar las alternatives de acuerdo con los criterios

2,8: EI sistema

Dos erninentes auto res en el campo de la los sistemas basados en ei conocirniento y los sistemas

de ia

y

rnanera:

Los sistemas basados en el conocimiento, por dscir 10 obvio, conuenen grandes cantidades de diversos conocimientos que ernplean en e~ desernpsrio de una tarea dada. Los sistemas sxpertos son una especie de sistema basado en el conocirniento. aunque ambos terminos a rnenuco se utilizan indisnntarnente.

LOUe es preclsarnente un sistema experto? Es un proerarna ce computadora que contiene el corocirniento y la capacidad necesarios para desempefiarse en un nivel de experto. Ei desernpefio experto siqnifica, cor ejemplo, el nive! de dssempefio de rnedi-

y

ex-

LA NATURALEZA DE lOS SISTEMAS 35

Expectativas I Puntos fuertes
- de los de la compafiia i
!
accionistas Crecimiento
y ganancias 1- -
uosecs de la I deseados B Debilidades del
R ! la cornpafiia Puesta 1 Resultados
gerencla E i- Estrategias f- en 1- operacio-
• C I practica nales
I H Oportunidades I ~--
i Factores de A en el entorno i
crecimionto y !
- ~
ganancias
actuates y Amenazas en
I previstos el entorno
I I
I
I I
Problemas c--l
- 2.9: Un modele de ptaneaetcn estrateqlea basado en ei analiais de brecha de posicion

cos que Ilevan a cabo diaqnosticos y procesos terapsuticos, 0 de Hsicos u otras personas de gran experiencia que llevan a cabo tareas de ingenierfa, de adrninistracion 0 cientlficas. EI sistema experto es un apoyo de alto nivel intelectual para el sxperto humane, 10 cual explica su otro nombre, asistente inteligente.

los sistemas expertos por 10 general se construyen de tal manera que sean capaces de explicar las Ifneas de razonamiento que Ilevaron a las decisiones que tornaron. Algunos de ellos pueden ineluso explicar por que descartaron ciertos carnlnos de razenarniento y por que escogieron otros. Esta transparencia es una caracteristica primordial de los sistemas expertos. Los disefiadores trabajan arcuamente para lograrla, pues eomprenden que el uso que se Ie dara al sistema experto dependera de la credibilidad de que disfrute por parte de los usuaries, y la credibilidad surqira debido a un comportamiento transparente y explicable,

Aun se piensa en los sistemas expertos como una especie de sistemas especializados, que utilizan hardware especial y lenguajes especiales, como LISP y PROLOG. Sill embargo, han comenzado a apareeer sistemas expertos sencillos, para cornputadoras personates estandar, y "cascarones" de sistemas expertos, que son estructuras de software para el desarrollo de aplicacicnes especfficas de sistemas expertos, tarnbien sencillos, en arnbientes basados en COBOL estandar,


Expectativas

importantes: de los Analisis Asuntos

accionistas, de la general del f--~ ... I t t' .

entorno es ra eqicos

L_ a_lta __ ge_r_e_nc_ia ~---2---,~----------------I

~

[p;;;;~estos!-, -------'

Figura 2.10: Un modele de

mercado

los sistemas van mas alia de los alcances de este gra-

dual mente se convertiran en un components cada vez mas lmportante de los sistemas en los que trabaja un analista de sistemas, A fines de 1& docada de los

los investlqadores comenzaron a ostudiar la relaclon entre las tecnicas de desarrollo de software clasico y la inteliqencia un estudio es [Jacob y Froscher, 1986]. Keller [Keller, i 987] preve un memento en el futuro cercano en el


Sistemas de planeacion estrateqica

Sistemas de apoyo a las decisiones

Sistemas operacionales

Figura 2,11: la jerarquia de los sistemas de procesarniento del informacion

Qual los sistemas de IA y los sistemas expertos torrnaran parte de la actividad "nor-

mal" del analisis de sistemas; otros, como [Barstow, 1 y Y

i preven que la inteliqencia artificial auxiliara a los analistas de sistemas en la oocumentacton de los requerimientos del usuario para mediados de la decada de los 90. Posteriormente se tratara este

2.5 PRINCIPIOS DE SISTEMAS GENERALES

Todos los ejemplos tienen una cosa en comun: todos son sistemas,

Mientras que puedsn diterir en varias casas, tam bien poseen rnuchas caractsrtsticas cornunes. EI estudio de dichas "caracteristicas cornunes" S8 conocs como teorie genera! de sistemas y es un terna tascmante de , Para obtener un panorama inicia] del terna, vease 1 para un panorama mas consultese

1 y para un panorama mas humorlstico de la trecuentemente per-

versa naturalsza de los vease la encantadora obra de Systementics

i

131 terna de la teo ria general de los sistemas va mas alia de 10 que

existen algunos "generales" que son de interes

lar para quienes crean sistemas autornatizados de informacion, e los si-

1, Entre mas especielizedo sea el Sistema, monos cepez es de edepierse a circunstencies diterentes. Esto a menudo se utiliza para describir los sis> ternas bioloqicos (por ejernplo, los animates tienen dificultad para adap-


tarse a nuevos arnbientes), pero se aplica tarnbien a los sistemas computacionates. Entre mas general sea un sistema, rnenos sera para una situacion deterrninada; perc entre mas optima sea, para tal sltuacion rnenos adaptable sera a nuevas circunstancias. Esto presents un problema para muchos sistemas de tiempo que tienen que ser optimizades para poder proveer respuestas suficienternente rapidas a los estlmulos externos. Pero el proceso de optirnizacion suele aprovechar las idiosincrasias del hardware especial de la cornputadora y del software de sistemas utilizados en el proyecto, 10 cual siqnifica que pudiera ser muy dificil transporter el sistema a un hardware distinto. EI principio tambien es de lmportancia para muchos sistemas de negocios, los cuales "retlejan" la itica del usuario, que pudiera tarnbien ser altamente especiallzada. Entre mas especializados sean los requerirnientos para un

sistema de por ejemplo, menos es que pueda utilizarse

un cornercial.

2 Cuenio mayor sea el sistema mayor es et numero de sus recursos que deben dedicerse a su msnienimiento dierio. La biologfa es, una vez mas, el ejernplo mas familiar de este prlncipio: los dinosaurios pasaban la mayor del su tiernpo llenandoss de alimento para poder rnantener sus enorrnes cuerpos. Esto tam bien se aplica a a comparuas y a una gran variedad de otros sistemas, incluyendo los sistemas autornatizados que estudiara en este libro. Un pequeno sistema de "juquete", del tipo que se puade crear en una sola tarde, por ejemplo, mvotucrara usualmente muy poe a "burocracia", rnientras que un sistema grande re-

de un estuerzo enorme en areas tan como la revi-

sion de errores, la edicion, el raspaldo, 91 rnantenirniento, la sequrldad, y la

3. Los sistemas siempre forman parte de sistemas mayores y siempre pueden divkiirse en sistemas menotes. Este punto es importante por dos razones: primeramente, suqiere una forma obvia de orqanizar un sistema

10 A rnenudo, los usuaries no aprecian este Ienorneno, y esta puciera ser una de las razones por las cuales aclualmente estan fascinados con los lenguajes de cuarta generacion 'I las herramientas para hacer prototlpos, Puede crearse con rapidez un sistema en un lenguaje de cuarta generacion que haga las paries centrales del procesamiento (y que de esta manera recompense instantaneamente al usuario), pero costara mucho trabajo ariadlrte la inteligencia necesaria para revisar errores, respaldar, dar mantenimiento, asegurar, atinar, docurnentar, etc. Debe tomarse esto en cuenta, 'Ia que de no ser aSI probablemente el usuario 10 acosara para que construya un sistema "rapido y sucio" que a fin de cuentas tatlara. Para dar una idea de los alcances de algo tan rnundano como la docurnentacion, considere la siguiente estadlstica, de la que rinde informe Capers Jones en Programming Productivity (Nueva York: McGraw Hill, 1986): Un sistema grande de telecomunicaciones tenia 120 palabras en ingles en cada renglon de codigo fuente, haciendo un total de 30 millones de palabras y de 60,000 paginas; un sistema gubernamenlal grande tenia 200 palabras en Ingles por renglon de codigo fuente, haciendo un total de 125 millonas de palabras y 250,000 paginas de documentacion.


computaclonat que esternos tratando de desarrollar, por el procedirniento de dividlrlo en sistemas rnenores (verernos mucho de esto en capitulos posteriores de este Perc aun mas importante es el heche de que sugiere que la definicion del Sistema que estamos tratando de desarrollar es arbitraria: pudirnos haber escogido un sistema ligeramente menor 0 mayor. Escoger 10 que debera sbercer un sistema y definlrlo cuidadosamente para que todo mundo conozca su contenido es una actividad importante; se discutira con mayor detalle en el capitulo 18. Esto es mas diffcil de 10 que pudiera parecer: tanto los usuaries como los anatistas a menudo piensan que la trontera del sistema es fija e inmutabls y que todo 10 que se encuentrs fuera no merece la pena de ser estudiado. Estoy endeudado con Lavette Teague y Christopher Pidgeon [Teague y Pidgeon, 1985] per haber localizado el siquiente ejernplo de sistemas centro de sistemas, tornado de [Eberhard, 1970]:

Una ansiedad inherente en los rnetodos de diserio as la naturaleza jerarquica de la complejload. Esta ansiedad se mueve en dos direcciones, el escalamiento y la reqresion intlnita. Utilizare un cuonto, La advertencia de la manija, para ilustrar al principio del escalarniento.

Esta fue mi experisncia en Washington cuando tuve dinero hasta para regalar. Si contrato a un dlsenador y Ie digo; "La manija de la puerta de mi olicina no es de buen diserio, carece de imaqinacion. ",Me pod ria usted dlsenar una nueva manija?" EI me contestaria "Si" y, tras acordar un precio, se rnarcha. Una sernana mas tarde regrasa y me dice: "Sr. Eberhard, he estado pensando ace rca de esa rnanija. Primere, debieramos praguntarnos si abrir y cerrar una puerta per medio de una manija as la rnejor forma de hacerlo", Yo Ie contesto, "Bien, crao en la imaqinacion. Haqase usted cargo", Mas tarde, el ragresa y me dice: "",Sabe? He estado pensando en su problema y la unica razon per la cual ocupa una rnanl]a es porque supone que necesita una puerta para su oficina, i,Esta seguro de que una puerta es la mejor rnanera de controlar el acceso y su privacidad?". "No, no estoy seguro de eso", replico. "Bueno, pues qurero dedicarme a esa problema". Regresa una samana mas tarde y me dice: "la unlca razcn por la cual dabemos preocuparnos por el problema de la apertura es porque usted insiste en tenar cuatro paredes en torno a su oflclna i,Esta saguro de que esta sea la mejor manera da organizar este aspacio para el tipo de trabajo que desempefia como burocrata?" Yo le responde:

"No, no estoy seguro en absolute". Bueno, esto "escalaria" hasta que nuestro disenador regresara con una cara muy seria (esto de ilecho sucedi6 en dos conlrat08, aunque no exactamenle por esle mismo proceso) diciendo: "Sr. Eberhard, debemos decidir si la damocracia caoitalista es la mejor manera de organizar nuestro pais, ante~ de qua yo pueda atacar su problema".


Por otro lado tenemos el problema de la reqresicn infinita. Si cuando esta persona se enfrent6 al disefio de la manija hubiera dicho: "Espere, antes de preocuparme por la manija desso estudiar la forma de una mane humana y 10 que el ser humano es capaz de hacer con ella", yo Ie hubiese dicho:

"Bueno". Luego hubiera ragrasado y me hubiera dicho:

"Cuanto mas pense al respecto mas me convene! de que se trata de un problema de ajuste. Lo que quiero estudiar prirnero as como se forma et metal y que tecnologia existe para tabricar objetos con metal, para aSI poder conocer los verdaderos parametres para ajustarla a la mario". "Bueno", Ie hubiera contestado. Pero entonces me hubiera dicho: "",Sabe?, he estado considerando la formaci6n de metales y todo parece depender de las propiedades rnetalurqicas. Quiero pasar tres 0 cuatro meses revlsando el aspecto rnetalurqieo, para poder comprender mejor el problema". "Bueno", Ie hubiese contestado. Despues de tres mesas 81 hubiera vuelto diciendo: "Sr. Eberhard, cuanto mas estudio el problema metalurqico mas me convenzo de que es la sstructura atomica la que se sncuentra en el tendo de todo esto", Y asl, nuestro dlseriador acabaria inmiscuido en la Hsica atornica par la manija. Esta es una de nusstras ansiedades, la naturaleza jerarquica de la complejidad.

4. Los sistemas crecen. Desde luego, esto pudiera no ser verdad para todos los sistemas pues violarla un principia general rnuy familiar, 113 ley de la conservacion de la energia. Perc muchos sistemas can los que €lstames tarnhiarizados sf crecen y resulta importante reconccerlo, pues a rnenudo ornitimos (como analistas y como disefiadores de sistemas) tomar esto en cuenta al cornenzar a crear el sistema. Un sistema de informacion tfpico, por , crecera hasta €ll punto de incluir mas software, mas datos, mas Iunciones y mas usuaries que los que inicialmente hablamos planeado. Par ejemplo, en una encuesta clasica de alrededor de 500 orqanizaciones de procesamlento de datos en los Estados Unidos, l.ientz y Swanson [Lientz y Swanson, 1980] ericontraron que la cantidad de c6digo contenida en un sistema automatizado existents aumenta aproximadarnente en un 10 por ciento al ario y el tarnano de la base de datos se incrementa en alrededor de un 5 por ciento al ano. No S8 puede suponer que un sistema ya hecho pueda perrnanecer estatico: el costo de hacerlo crecer a medida que transcurre el debe incluirse en los calculos de "costo- beneficio", que se discutiran en el capitulo 5 y en el apendics C.

Los analistas de sistemas en la protesion del procesamiento de datos a menudo son vlctimas de la de la especializaclon anteriormente expuesta: se convierten en expsrtos en su proplo campo, sin darse cuenta de la existencia de otros tipos de "constructores de sistemas" y de que se pudieran aplicar algunos principics gene-


rales. EI proposito primordial de este capitulo ha side ampliar su horizonte y otrecer una mayor perspective antes de ahondar mas en el estudio de los sistemas de interautornatizados.

Obviamente, uno no puede eonvertirss en experto en sistemas vivientes, sistemas ttstcos Y todo tipo de sistemas hechos por el hombre adernas de los sistemas de automatizados. Perc dado que los sistemas que es probable que uno cree casi siernprs interactuan con esos otros, es irnportante estar consciente de su AI cornprender que otros sistemas obedecen a muchos de los mismos que observan los sistemas cornputacionales que este haciendo, sera mas probable que tenga ax ito al definir los Hmites entre BU sistema y el rnundo

t , Edward Yourdon, Design of On Line Computer Systems. Englewood N.J ..

1972, Pag.4

2. James Martin, Design of Reel- Time Computer Systems. Englewood N.J.:

1967.

James Grier

Living Systems. New York: McGraw-

1978. 1979.

Steiner, Streteqic Planning, New York: Free

5. Peter Management:

per & Row, 1974.

Responsibilities, Practices. New York: Har-

6, Russell L.

A Concept of Corporate Brain of the Firm. New York:

New York:

970.

7. Stafford

1972.

Stafford

The Heart of Enterprise. New York: Wiley, 1978. Technology, diciernbre, 1983,

H. Garrett DeYoung, "Biosensors", High Technology, noviernbre, 1983.

1. Nicholas Shrady, "Molecular Computing", Forbes, julio 29, 985.

12. David, Olmos, "DOD Finances Case Western Biochio Research Center" Com-

puterwottd, 3, 1984. . ,

13. Elaine Rich, "The Gradual Expansion of Artificial Intelligence", IEEE Computer, mayo, 1984.

14. Edward Feigenbaum y Pamela McCorduck, The Fifth Generation. Reading, Mass.: Addison-Wesley, 1983.


i 5. RJ.K. Jacob y J.N. Froscher, "Software Engineering for Rule-Based Software Systems", Proceedings of the 1986 Felt Joint Computer Conference. Washing.

ton, D.C.: IEEE Computer Press,1986.

16. Robert E. Keller, Expert Systems Technology: Development and Application.

Englewood Cliffs, N.J.: Prentice-Hall, 1987.

t 7. Robert Alloway y Judith Quillard, "User Managers' Systems Needs", CISR Working Paper 86. Cambridge, Mass.: MIT Sloan School Center for information Systems Research, abril, '1982.

18. Ludwig von Bertalanffy, Teorfa General de los Sistemas. Mexico: Fondo de Cultura Economica, "1976.

19. Gerald Weinberg, An tntroduction to General Systems Thinking. New York: Wi· ley, 1976.

20. John Gall, Syetementics. New York: Quadrangle/The New York Times Book Company, 1977.

21. D. Barstow, "Artificial Intelligence and Software Engineering", Proceedings of the 9th international Software Engineering Conference, abril, 1887.

22. M.D. Lubars y M.T. Harandi, "Knowledge-Based Software Design Design

Schemas", Proceedings of the 9th tnternetionel Software Engineering Conference, abril, 1987.

23. Bennet P. l.ientz y E. Burton Swanson, Software Maintenance Management, Reading, Mass.: Addison-Wesley, 1980.

24. Lavette Teague y Christopher Pidgeon, Structured Analysis Methods for Computer Information Systems. Chicago: Science Research Associates, 1985.

25. John P. Eberhard, "We Ought to Know the Difference", Methods in

Environmental Design and Planning, Gary T. Moore, ed. Cambridge, Mass.: MIT Press, 1970, pp. 364-365.

PREGUNTAS Y EJERCiCiOS

t . De dos ejernplos de cad a una de las definiciones de sistema obtenidas del diecionario Webster, expuestas al comlenzo del capitulo 2.

2. De cinco ejemplos de sistemas que hayan durado mas de un millen de an os y que aun existan hoy en dia.

3. De cinco ejernplos de sistemas neches per el hombre que hayan durado mas de 1000 aries. En cad a caso, de una breve explicacion de per que han durado y de si se pudiera esperar que continuen durante los siqulentes 1000 aries.


4. De cinco ejsmplos de sistemas no hechos por el hombre que rante su vida. l,Por que fallaron?

5. De cinco ejernplos de sistemas hechos por el hombre que hayan fallado durante su vida. ;"Por que fallaron?

fal!ado du-

6.

de investlqaclon: lea la obra Living Sistetns, de Miller, y haga una crlti-

ca.

de lnvestlqacion: lea la obra de

Brain of the Firm, y haqa una

7.

erttica.

8. proyecto de investlqacion: lea la obra de una critica.

The Heart of Enterprise, y haga

g. De la seccion 2.3, de un ejemplo de un sistema hecho por el hombre que, en su

opinion, no debiera autornatizarse. LPor que que no debiara autornati-

zarse? pudlera salir mal?

10. De un ejernplo de un sistema no autornatizado que, en su opinion, debiera automatizarse. ;"Por que piensa que debisra autornatizarse? LCuaies sertan los beneficlos? LCuEd serla 131 costa? LQue tanto puede conflar en los beneficios y en los costos?

t. De ojemplos de los 19 subsistemas de Miller para los siquientes tipos de sistemas autornatizados: a) nomina, b) control de mventarlos, c) el sistema teletcnice.

i 2. una pequena orqanizacion con la cual este relativarnente farntliarizado, 0

bien un departamento 0 division de una orqanizacion grande. Para la orqanizacion escoqida, lIeve a cabo un inventario de los sistemas que utiliza. lCuantos de estes son sistemas operacionales? LCuantos son sistemas de apoyo a dscistones? LCuantos son sistemas de planeacion estrateqica? LExisten otras cateqorias utiles de sistemas? Para ayudarlo a entocar su atenclon en esto, consults [Alloway y Ouillard, i 982].

13. De cinco ejernplos de su propia expertancia de a) sistemas de tiernpo real, b) sistemas en linea, c) sistemas de apoyo a la torna de decisiones, d) sistemas de planeacion estrateqica y e) sistemas expertos.

La figura 2.4 muestra una confiquracion de hardware para un sistema en linea. Dibu]e el diagrama para una confiquracion de hardware distinie que sea razonable. L Tiene sentido tener parte de los datos de sistema localizados en las terminales? ,!,En que memento del desarrollo del sistema debiera discutirse esto con el usuario?

5. De un ejemplo de un sistema comercial que se doscriba como de "inteliqencia artificial" 0 como un sistema "basado en el conoclrnlento" y que, en su opinion,

44 lA NATURAlEZA DE lOS SISTEMAS

que la des·

no ssta siendo descrito honesta 0 exactamente. l,Por que cripcion sea enqariosa?

16. l,Podrfa aplicarse el modele estlmulo-respuesta mostrado en la figura 2.5 a otros sistemas que no sean de los sistemas de real? l,No responder, acaso toaos los sistemas a estlmulos? tienen de especial los sistemas de tlernpo real?

17. l,Realmente puede tomar decislones un sistema de apoyo a la toma de declslones? Si no, l,por que no? l,Oue pudiera hacerse para modificar un tlpico ststerna de apoyo a la toma de dscisiones para que pudiere tornarlas? l,Serfa

deseable esto? son los lnconvenisntes?

~ ~
~
~ ~ If Todo el mundo es un escenano,

Y los hombres y mujeres son simples actores:

Tienen sus sntradas y salidas:

Y un hombre, en el transcurso de su vida, Reallza muchos papeles.

Shakespeare.

As You Like It, II, vii

En este capitulo

aprendera:

1. cateqorfas de personas con

lnteractuara a de un

son las tres principales cateqorias de claslflcados sequn su traba]o.

son las reacciones de desarrollo

entre los usuaries novatos y

papel un analista en un

de sistemas.

otros papeles se pusden dar en un proyscto de desarrollo de sistemas.

45

46 LOS PARTICIPANTES EN EL JUEGO

Como analista de sistemas, usted trabajara en proyectos de desarrollo con una variedad de personas. Los personajes cambiaran de un proyecto a otro: las personalidades variaran dramaticarnente, y el numero de personas can las que tendra que interactuar puede ir de una sola hasta docenas, Sin embargo, los papeles son bastante constantes, y vera los mismos una y otra vez.

Ser un analista con ax ito requiere algo mas que una simple cornprension de la tecnoiogfa de las computadoras. Entre otras casas, requiere de habilidades interpersonates: pasara buena parte de su tlempo trabajando con otras pe:sonas, _muchas de las cuales hablan un "idioma" rnuy diterente al suyo y ancontraran sxtrano e intimidante su "idiorna" tecnico computacional. Per eso, es que conozca las expectativas que los dernas tend ran de usted y las que usted debera tener de ellos.

En este capitulo se entoca la atenclcn sobre las caracteristicas de las stquientes cateqorias principales de "jugadores" que probablemente onccntrara en un proyecto caracteristico de desarrollo de sistemas:

I) Usuaries

I) Adrnlnistracion

e Auditores, personal de control de caudad, y verificadores de normae

" Analistas de sistemas

e Dlsefiadores de sistemas

I) Program adores

.. Personal de operaciones

Cada una de estas categorfas se describe a continuacion.

3.1 USUARIOS

EI participante mas irnportante en el juego de los sistemas es alquien que el analista conoce como usuerio. EI usuario es aquel (0 aquellos) para quien se construye el sistema. Es la persona a 10. que tendra que entrevistar, a rnenudo con gran detalle, a fin de conocer las caracterlsticas que debera tenet ei nuevo sistema para poder tsner exito.

Debe nacerse notar que la rnayorla de los usuaries no se refieren a sf mismos como "usuaries" (a rnenudo se utiliza esta palabra en otros contextos para dascribir a un drogadicto). En alqunas orqantzactones se evita ese problema u!ilizando el te~rnino ciiente 0 dueiio para identificar al usuario. EI usuario es el "dueno" en el sentido de que es al quien recibe el sistema cuando se termina de crearlo. Y el usuario

LOS PARTICIPANTES EN EL JUEGO 47

es el "cliente" por 10 rnenos en des sentidos importantes: 1) como en rnuchas otras profesiones, "el cliente siernpre tiene 10. razon", sin importar 10 desaqradable 0 lrracional que pueda parecer y 2) el cliente es el que a fin de cuentas paqa el sistema Y usualmente tiene el derecho de rehusarse a pagar si no esta contorme con 61 producto.

En la mayorla de los casos, es taci] identificar al usuario (0 usuaries): de rnanera oaracteristica, es aquel que formal mente solicits un sistema. En una orqanizacion psquefia, esto susle ser un procedimiento muy informal; pudiera consistir simplemente en que el usuario lIame por tsletono al analista oficial de sistemas y le

"Oye, Adriana, necesito un nuevo sistema para dar sequirniento a nuestra nueva camparia de comercializacton''. En una orqanizacion grande, el inicio de un proyecto de desarrollo de sistemas suele sar mucho mas formal. Por 10 com un, ta "solicitud de consideracion y estudio de sistemas", como se Ie suets conocer, pasa por divsrsos niveles de aprobacion antes de que se involucre al analista de sistemas. EI capitulo 5 trata esto mas a tendo.

Sin embargo, hay un gran nurnero de situaciones en las que no se conoce la identidad del vardadero usuario 0 bien en las que hay poca oportunidad de que este interactue con el anallsta, Un ejemplo muy cornun de esto es el de un sistema en proceso de ser desarrollado por un negocio de consultona 0 per una comparua productora de software: la lnteraccion que exista entre el clients y la campania pudiera llevarse a cabo a traves de administradores de contratos u otras aqencias administrativas, a veces con clausulas explicitas de que el analista no puede tensr comunicacion directa con el usuario. Aun si el sistema se cesarrolla por complete dentro de una sola el "verdadero" usuario pudiera nornbrar a un representante para trabajar con el analista, per estar dernasiado oeupado personal mente con otros asuntos."

Obviamante, en situaclones de este hay una gran posibllidad de mal os

entendidos: 10 que el usuario quiere que el sistema haga pudiera no serle cornunicado de rnanera correcta al analista, y 10 que este crea que ssta construyendo para el usuario pudiera no serle cornunicado tam poco de rnanera correcta, hasta que ya estuviera todo terrninado, cuando ya seria dernasiado tarde. De esto podemos sacar dos conclusiones importantes:

@ Siempre que sea posible, el analista debiera tratar de establecer contacto directo con el usuario. Aun si se encuentran involucradas otras personas como interrnediarios (por ejernplo, para tratar detalles de los contratos 0 asuntos adrninistrativos), es importante tener reuniones con la persona

Una situacion comun de esta naturaleza es la del encargado de contratar proysctos en una orqanizacion gubernamental. En la mayorfa de los casos, esta persona no as al usuario y puede no conocer mucho acerca de las verdadaras necesidades de este, pero resulta ser el nominado para mantenar cualquler cornunicacion oficial con la persona (0 cornpafiia) que oebera desarroilar el sistema.


que en ultimo terrnino reciblra el sistema. De heche, suele sar aun rnejor 5i el usuario forma parte activa del equipo encarqado de! proyecto. En muchas orqanlzaciones, el usuarlo suele ser el qerente de proyectos; incluso, algunos arqurnentan que el usuario mismo debiera llever a cabo el proyecto.

.. Si no es posible comunicarse directamente con el usuario, la documentscion generada por el analista se vuelve aun mas irnportante. La parte II de este libra se dedica a las herramientas de modelado que pueden utilizarse para describir el comportamtento de un sistema de rnanera formal y riqurose. Es esencial usaf este tipo de herrarnientas para evitar males entendidos costosos,

:$.1.1

Uno de los errores mas trecuentes que corneten en el campo de las computedoras sobre todo los proqrarnadores y a veces tarnblen los analistas, es suponer que todos los usuaries son iquales, La palabra "usuario", como sustantivo singular, da a ernender que el anallsta solo tendra que interactuar con una persona. Aun cuanoo sea obvio que debora intervenir mas de un usuario, se tiene la tendencia a pensar en ellos como un grupo de hurnanos amorfo y homoqsneo.

Declr sirnplernente que un usuario ditlere de otro es insuticlente: claro, tlenen dilerentes personalidades, dilerente preparaclon, diterentes intereses, etc. Pero tambien hay dlterenclas impottentes que usted debe tener en mente al trabajar como analista. He aqut dos maneras de clasificar a los usuaries:

.. Por categorla de traba]o 0 nivel de supervision

.. Por nivel de experienciaen el procesamiento de datos

3.1.2 Clasificacion de los usuaries por categorfa de trabejo

En un proyecto tlpico de analisis de sistemas se pasara una considerable cantidad de tiempo entrevistando a los usuaries para determiner los requerimientos del sistema. Pero, Lcw~les usuaries", L,a que nivel? Desde luego, esto dependera del proyscto y de las politlcas de su orqanizaclon. Sin embargo, habltualmente tendra que interactuar con individuos de tres cateporlas de traba]o: usuaries operecioneies, usuaries supetvisores y usuaries ejecutivos.c

Los usuaries ooerecionetes son oficinlstas, adrninlstradores y operadores que son los que mas probablemente tendran contacto diane con el nuevo sistema (a me-

2 Hay variantes de esta terminologfa: [Teague y Pidgeon, 1985], p~r ejemplo, se relieren tambien al "usuario beneficiado", el que recibira los benelicios del nuevo sistema. Esla persona pudiera no te'ner contacta directo con el sistema, pero se beneficiara de alguna manera con el servicio mejorado o la funcionalidad del nuevo sistema.


nos que ?ste ustsd construysndo un sistema de apoyo a las decisionss, en cuyo caso tandra poco contacto con ests grupo). Por eso. en una orqanlzaclon grande, tendra que entrevistar a secretarias, aqentes de sequros, oflcirustas encargados de tletes, personal encargado de solicitudes y "ayudantss" de todos los ramarios, torrnas y colores. En el caso de un sistema de tiernpo real, pudiera tenar que hablar con usuaries operacionales tales como inqenieros, ffsicos, obreros,

tos, operadoras teletonlcas, etc. Debe tener tres cosas en mente cuando se

con usuaries de nivel operacional:

1, Los usuartos de este nivel se preocupan rnucho por las funcionas que tenora el Sistema, pero es mas probable aun que se preocupen por los detalies de la intertez humene. Por ejernplo: l,Que tipo de tsclado estars usando para comuntcarrne con el sistema?; 6es como el teclado de la rnaquina de escrlblr que he sstado usando durante aries: 6como aparecsran las cosas en la pantalla?; l,deslumbrara mucho la pantallav; l,se podran leer facilrnente los caracteres?;3 Lcomo me indicara el sistema si he cornetido un error>: (,tendre que volver a teclear todo>: l,que tal si "borrar" algo que tectee hacs un momento?; cuando el sistema me haga un intorma, l,en donee estara localizada la informacion en la pagina?; l,puedo hacer que se irnprima la Iecha y la hera en la parte superior de cada hoja?, etc. Estes son detalles que el supervisor del usuario de nivel operacional puoiera 0 no tomar en cuenta, pero que, como se podra imaginar, son vitates para el exito de un sistema y se tendran que abordar." Esto siqnifica que, como analista, necesitara tener comuntcaclon directa can el usuario operacional 0, en el peor de los cases, estar muy sequro de que la persona que representa a este tenqa presentes tales detalles. Estes se discutan mas a fonda en el modele de puesta en practice por el usuario, en el Capitulo 21.

2, Los usuaries operacionates tienden a poseer un panorama "local" del sis-

por 10 general son ccnocedoros del traba]o especifico que hacen y de las personas can las que tienen comunicaclon inmediata (ciientes, sucoleqas, etc.). Sin embargo a menudo no estan tamiliarizados con el panorama general; es decir, puede ser que tenqan dificultad para describlr como es que su actividad propia encaja dentro de la orqaniza-

3 Hay argumentos en relacion con esto que hacen hincapie en el hecho de que un sistema nuevo e:.~arte de un sistema aun mayor: el usuario puede prequntar: "l,Me lastirnara la espalda 0 me dara te~dlnltls eI estar sentado frents a una terminal todo el dia?", "l,Necesito preocuparme por la ;,adla~lon proveruents de .una pantalla de video?", "l,Que tal si no S8 teelear?" y, 10 mas irnportante,

"Que tal Sl este nuevo sistema me reemplaza en el traba]o y me deja sin empleo?"

4 E~ cases extrerncs, esl0 tambien signifiea que as el usuario operacional quien puede hacer 0 desnacer un sistema nuevo. Los usuaries operacionales pueden parecer pasivos y puede ser que ~o, tengan I~ autoridad 0 el poder para aprobar un proyecto de desarrollo de sistemas, pero si 10 sacorean, 0 slmplemente no 10 usan, el sistema nuevo habra fallado.


cion qlobal 0 para descrtbtr 131 caracter glo?al de. su ~rganizacion. Esto rara vez se debe a torpeza, sino a que no uenen mteres en el asunto. 0 tarnbien pudiera raftejar que 131 usuario supervisor no les haya dado a c~nocer nada de eso porque as! 10 preliere. Una consecuencia de .esta sttuacion es que el anatista debe poder desarrollar modelos de Sistemas que permitan ambos panoramas (es decir, descripciones de partes pequenas y detalladas del sistema, independientemente ?e otras ~artes) y descripciones globa!es (as deelr, panoramas de alto nlvel del sistema entero

que svitan caer en detalles).

3. los usuaries oparacionales suelen pensar e~ los sistemas en t~r~inos fIsicos, es decir, en terminos de la tscnoloqia de puesta .en pracnca q~e oornunrnente se utiliza para "implantar" 0 hacer uso del Sistema, o. en t~rminos de la tecnologia que lmaqinan que ouaiere utnizarse. las discuslones abstractas ace rca de "tunciones'' y "tipos de datos" pueden rasultar dificiles; de aqul que el analista de sistemas pudlera requerir hablar co~ el usuario exclusivamente en terminos tarniliares. Luego, como una acttvldad aparte, puede traducir esta descripcion fisica a un "modelo esencial", es decir. a un modelo de 10 que et sistema debe hacer, independientemente de la tecnologia usada para realizario. Esto se dis-

cute mas a tendo en el capitulo 17.

Los usuarlos supervisores son, como el terrnino 10 da a ontender, e~pleados como supervisores: usualmente administran a un grupo de u~uanos, operaclo~a~es y son responsables de sus logros (obviarnente, se puede imaqmar mas ~e un nivel de usuaries supervisores en una organizacion grande). Pued~n te~er e! titulo d~ supervisor, perc pueden ser tarnbien jetes de turno, gerentes, eJeeutlv~s, jetes d~ mqeruerla u otra multitud de cosas. Lo importante acerca de los usuanos supervrsores es

que:

"

Mucnos de ellos son usuaries oparacionales que han sido promovidos. Per eso, usual mente sstan tamlliarizados con el trabajo de sus subordinados nparacionales y se puede suponer que sstaran de aeuerdo con. sus necesidades, preocupaciones y perspectivas. Sin embargo, e~to no sternpre es asi, Dado que el rnsrcado, la economia, y la tecno~og~a han camblade tanto, el traba]o operacional de en dia puede otterir mucho de

10 que era hace 20 afios,

Una de las rezones per las cuales pudiera suponerse que no hay ~omunicacion entre el usuario supervisor y el opsracional es porque el pnrnero a msnudo debe regirse pOl' un presupuesto. De aqui q~~ .a menu~o se interesa en un nuevo sistema de informacion poria poslbllidad de Incrementar el volumen de trabajo realizado disminuyendo a la vez el costo de procesar las transacciones, y reduciendo t~mbien los errores e~ el tmb~jo. Tambien pudiera ocurrfrsele que un Sistema nuevo !e dara oportunl-

"


dad de supervisar el traba]o (e incluso la actividad minuto a minute) de cada usuario operaclonal. Dependiendo de como se real ice esto, los usuaries pudieran tener 0 no la misma perspective que el usuario supervisor.

" Debido a este enlasis en la eficlencia operacional, por 10 el usuario supervisor es el que ve al nuevo sistema como una forma de reducir el numero de usuaries operacionales (per despido 0 arrepentirniento) 0 de evitar que aurnente su numero al crecer el volurnen de trabajo. Esto no es ni bueno ni malo, perc a menudo es el punto focal de batallas politicas, en las cuales el analista suele encontrarse en rnedio.>

@ Por las mismas rezones, el usuario supervisor a menudo actua como interrnediario entre el analista y los usuaries arguyendo que estes ultimos estan demasiado ocupados como para perder su tiernpo hablanco con el analista. EI supervisor replicara: "Despues de todo, nscesitames el sistema cornputacional precisetnente porque sstamos tan ocupados". Como se podra imaqlnar, esta es una posicion muy petiqrosa para usted, Despues de todo, el usuario operacional es 81 que se preocupara mas por la intertaz humana del sistema y es poco probable que el supervisor pueda hacerse €leo debidaments de estas necesidades.

" EI usuario supervisor a menudo piensa en los mismos terrnlnos fisicos que el operactonal, y su perspective a rnenudo resulta tan local como la de ests ultimo. uesce iueqo, uno esperara que una persona de nivel administrativo tuviera un panorama mas global; como corolario. pudiera resultar que el usuario supervisor ya no recuerde alqunas de las detalladas politicas de neqocios que los usuaries operacicnales llevan a cabo.

" Finalmente, sera el usuario supervisor con quien usted tenora el contacto cotidiano prirnario. Es el que definira los requerimlentos y las pollticas de la ernpresa que su sistema debera raalizar. Pudiera ser solo un miembro pasivc del equipo (en el sentido de que participara solo cuando se le entreviste), 0 bien un miembro de tiernpo complete 0 incluso, como se mencrone anterlormente, el qerente del proyecto.

los usuaries de nivel ejecutivo en general no se involucran directaments con el proyecto de desarrollo del sistema, a rnenos que el proyecto sea tan amplio y tan importanta que tenqa un impacto de primer orden en la ernpresa. Sin embargo, para

5 Advlertase que esta es una caraoteristica de un sistema operacional (como se definio en el capitulo 2), perc generalmente no 10 es de los sistemas de apoyo a decisiones. N6tese tam bien que los gerentes 0 administradores de nivel superior por 10 general se interesan mas en los sistemas que les ofrecen una ventaja competitiva que en aquellos que reducen personal operacional en una 0 dos personas.


un proyecto normal, el usuario ejecutivo sue Ie estar dos 0 tres niveles arriba de la accion asoelada con el proyecto. En la medida que usted se involucre con ellos, probablemsnts descubrira 10 siguiente ace rca de los usuaries ejscutivos:

@ Pueden proporclonar la iniciativa para el proyecto, pero es mas probable que sirvan solo como autoridad para Iinanciar las solicitudes que se oriqinan en niveles mas bajos de la orqanizacion.

@ Por 10 cornun, no fueron previarnente usuarios operacionales 0, si 10 fueron, habra sido hace tanto tiernpo que cualquier experiencia que tengan al respecto sera obsoleta. Par ello, no se encuentran en posicion que les permits deflnir los requerirnientos del sistema para aquellos que 10 estaran manejando cottdtanarnente. Como excepcion de esto tenernos el sistema de apoyo a decistones que se discutio en el capitulo 2; tal sistema 10

utilizaran primordial mente usuaries y ejecutivos.

@ los usuaries ejecutivos se preocupan mas por los detalles estrateqicos y las qananclas/perdidas a largo plazo. De aqul que, por 10 regular, esten menos interesados en asuntos operacionales tales como abatir los costos de transacclon 0 ahorrarse tres oficinistas. que es 10 que Paul Strassman llama "los beneficlos de la informatica" en su obra [Strassman, 1985]. Esto es, los nuevos rnercados, los nuevos productos 0 la nueva venta]a cornpetitiva que pudiera obtenerse con el sistema.

@ los usuarlos de nivel ejecutivo general mente se interesan mas en el panorama global del sistema. En consscuencia, suelen no interesarse par los detalles, Como ya se rnenctono, esto siqnifica que debernos utilizar las herrarnlentas de rncdelado que permiten dar un panorama global del sistema para los usuaries ejecutivos (y para otra persona que 10 requiem), as! como porciones detalladas del sistema para los usuaries operacionales que son los "expertos locales".

Sirnilarrnente, los usuaries ejecutivos por 10 general pueden trabajar con modelos abstractos de un de heche, ya estan acosturnbrados a

con modelos abstractos tales como modelos model os

de mercedo, modelos orqenizecionetes y modelos de inqenierte nue-

vos produetos, oficinas, etc.), En reahdad, no estaran interesados en los "rnodelos tlsicos" del sistema y S6 prequntaran por se torna usted la molestia de rnostrarselos.

En resumen, usted interactuara con tres tipos 0 niveles diferentes de usuaries, como 10 muestra la figura 3.1. Hecuerda que tienen distintas perspectivas, intereses y prioridades y, a menudo distlnta preparacion, Estos tres tipos de usuaries se pueden caracterizar como 10 rnuestra la tabla 3.1.


En la explicaclon anterior insinue que at usuario no siernpre Ie aqrada la perspectiva de un nuevo sistema; de heche, a rnenudo se opondran activarnents a 61. Est8 es cas! siempre el caso con los usuarios operacionales (dado que son los que 10 tendran que usar), pero tambian se puede encontrar resistencia per parte del usuario (dado que ests pudiera sentir que el sistema tendra un impacto neqativo sabre la eficiencia 0 qananclas del area de la cual es responsable), 0 incluso por

del usuario ejecutlvo, Como 10 sen ala Marjorie Leeson en su obra [Leeson, i 981],

EI analista que entiende de motivaci6n basica, del por que las personas se resisten al cambio y como se resisten a el, puede tal vez superar en parte la reslstencia. La mayorfa de los textos de admlnistracion hacen referencia a la doraderarqufa de las necesidades, de A.H. Maslow. Las cinco categorias, desde la de mas baja hasta de la mas alia prioridad, son

Eiempio

1. Fisioloqica

2. Seguridad y estabilidad econ6mica

Allmento, vestido y casa

Protsccion contra el peligro y la perdida del empleo

3. Social

Poder identificarse con individuos y grupos

4. Egofsta

Reconocimiento, sltuacion social e importancia

5. Healizacion

Kealizarse al maximo en la creatividad y el desarrollo personal

EI usuario ejecutivo

supervisor

EI usuario operacional

Figura 3.1: los tres tlpos de usuaries


Asi, si encuentra que algunos usuaries se resisten a la idea de tener un nuevo sistema, deber psnsar en la posibilidad de que una 0 mas de estas necesidades no se este satisfaciendo. Desde luego, es raro que el usuario se preocupe ace rca del nivel fieiolcqico de la nscesidad, pero no sorprende el heche de que pueda preoeuparse por la perdida de su empleo. Tarnbien es cornun que los usuaries (sobre todo los se preocupen porque el sistema vaya tal vez a llevarlos a no poderse identificar con los qrupos sociales que les son familiares: ternen que estaran sncadenados a una terminal todo el dta y que pasaran todo su tlernpo mtoractuando con una cornputadora en lugar de hacerlo con otros humanos. EI usuario operacional que se haya vuelto experto en la realizacion de determinada labor de procesarniento manual de lntcrmacion pudiera temer que el nuevo sistema Ie perjudique en sus nacesidades "eqolstas"; y el usuario que sienta que el sistema le restara creati-

vidad a su tarnbien se resistira.

Usuario supervisor Puede 0 no tener un panorama local

Usuario ~iecutivo Tiene un panorama global

Usual mente tiene un panorama local

Hace tuncionar el sistema

Generalmenle, esta familiarizado con la operaclon

Provee la iniciatlva para el proyecto

Tlene una vision ffsica del sistema

lo rigen consideraclones presupuestales

No tiene experiencia operacional directs

Actua a menudo como intermediario entre los usuarios y los niveles superiores de administracion

Tiene preocupaciones sstrateqicas

3.1.3 clasttlcaclon de tos usuarios em cateqortas por nlvel de expsrtencla

Deberia ser obvio que los diferentes usuaries tendran diterentes niveles de ex-

periencia; desafortunadamente, es cornun que los anallstas suponqan que toaos los usuaries son idiotas en 10 que concierne al usa de computadoras. Tal vez esta sufuera admisible hace 10 anos, perc es probable que Ie ocaslone rneterse en problemas en rnuchas orqanizaciones hoy en dfa6: actualmsnte se puede diterenciar

6 Aun cuando cad a usuario can el que se encuentre no conozca y no lenga interes par !a tecnologia de las cornputadoras, debiera evitar el error cornun de considerarlos a todos como una forma de vida subhumana. los analistas y programadores [ovenss, sabre todo los experimentadores que empezaron a utilizar las computadoras desde la escuela primaria, suponen que lodos deben eslar fascinados con las computadoras y tener habilidad para usarlas, y que aquellos que no cumplan con esto son 1) retrasados mentales, 0 bien 2) miembros de una generacion anligua y, por tanto, indignos de consideracion 0 respeto. Mientras tanto, el mundo esta Ileno de usuarios que no gustan de las computadoras por una varied ad de razones legitimas, y hay usuarios que estan demasiado ocupados Iralando de ser expertos en su propia profesi6n 0 negocio como para preocuparse por ser expertos en computadoras. Tienen la misma opinion de los programadores de computadoras y de

lOS PARTICIPANTES EN EL JUEGO 55

entre amateurs, novatos presuntuosos y un pequeno (perc creclente) grupo de verdaderos sxpertos.

EI amateur es aquel que jarnas ha visto una computadora y que exctama a todo pulmon y con trecuencia que 61 "no entiende todo este asunto de las computado-

. A menudo, este tipo de usuario sue Ie ser un empleado 0 negociante de median a edad que ha sobrevivido felizmente a 10 largo de 16 afios de educacion y de otros i 0 0 20 aries en un empleo antes de que se introdujeran las cornputadoras. Sin embargo, tambien es comun encontrar usuaries [ovenes (de veintitantos aries) que encuentran a las computadoras aburridas, intlrnidantes 0 inaplicables en sus vidas. Esto presents un reto para et analista de sistemas al que le encanta hablar del "acceso en linea" y los "dialoqos hombre-rnaquina dirigidos por menus" y terrninolo-

per el estilo. Pero si el ana/isla hece bien su trebejo, no hay rezon par te cusl et usuario debe intereserse par tee computsdotes 0 tenet grandes conocimientos ecerce de e/las.

En realidad, el verdadero problema con el usuario amateur es un tanto mas ser que encuentre diffcil de sntender el "Ienguaje" que el analista usa para describir las caracterlsticas, tunclones y opciones que otrece el sistema que se va a implantar, aun cuando se evite la terminologfa obviarnente relacionada con las computadoras. Como verernos en las partes II y III, el traba]o del analista de sistemas cornprende la creacion de varies modelos del sistema que se lrnplantara. Estes rnodelos son representaclones tormales y rigurosas de un sistema computacional y al mismo tiernpo son representaciones ebstrectes del sistema. La mayorta de los rnodelos cornprenden qraftcas (irnaqenes) apoyadas con textos detallados y la representaci6n global (que es necesaria para asequrar una descripcion formal y rigurosa) da a algunos usuaries la irnpresion de ser abrurnadorarnente matsmatlca y por 10 tanto no legible. Pudiera tratarse de usuaries que recuerdan ta dificultad de leer las notaciones qraficas cornplejas utilizadas en qufmica orqanica 0 la notacion igualmente comple]a que se utiliza en el calculo diterencial y en el algebra. Cualquiera que sea la razon el resultado es el mismo: dejando de lade el entendimiento de la tecno-

computacional, sl el usuario ni siqulera puede enterider el modele de un sistema, hay poca probabilidad de que Ie satistaqa el sistema cuando por fin este termi nado. 7

los analistas de sistemas que la que tienen de los electriclstas, carpinteros, plorneros y rnecanlcos ~utomotnces: aprecian las habilidades y destrezas requeridas para lIevar a cabo el trabajo, perc exmoen una total talta de interes en los detalles. Comprender este punto en muchos cases deterrninara si usted tendra exlto 0 no en sus primeros proyectos como analista.

7 Como enalogia: si Ie fueran a cOl1struir su casa, empezarfa p~r discutir las caracterfsticas deseadas con el arquitecto. Tras mucho discutir, esie se iria a su oficina y luego volveria con varios bosquejos 0 maquetas a escala de la casa. Si usted se rehusare a mirar los bosquejos 0 alegara que son "demasiado ;natematicos", el arquitecto tendrfa pocas probabilidades de exilo. Lo que con toda probablhdad haria usted es Ilevario a una cas a existente y decirle "construyame una como esa". De~gracladamente, a menudo no estamos en una posicion adecuada para hacer eso en el campo de ,as compuladoras, aunque, muchas veces, la elaboracion de prototipos es una manera viable de lograr 10 mismo.


Un segundo tipo de usuario es que pudierarnos Hamar "el novato presun-

tuoso": es una persona que ha tenido que ver con uno 0 des de desarrollo

de sistemas 0 es un usuario que posee una cornputadora personal y que

ha escrito uno 0 dos (i proqrarnas en BASIC. Por 10 cornun, saber execte.

mente 10 que quiers que el sistema haga y suele serialar todos los errores que 61 analista cornetio en el ultimo proyecto. Esto esta bien, por una cosa: a menuda se enzerze demasiado en oiscusiones sabre fa tecnoloqie espectiice que ss user para reetizer 131 sistema. Por eso, el usuario pudiera decirle al analista: "Necssito un nuevo sistema de procesarniento de pedidos y quiero que se construya con una red local que conscte a nuestras PCs IBM, y creo que debierarnos usar dBASEIII 0 PC-FOCUS". A la estas pudieren resultar ser las decisiones tecnicas correctas, perc es premature corisiderar lara el hardware, el lenqua]e de proqramacion 0 los de base de datos antes de docurnentar los voroaderos requerimientos del sistema. De en un caso extreme, la "suqerencia" del usuario acerca del hardware y software apropiados pudiera convertirse en "una solucion en busca de , es el descubrimiento de que se tienen recursos de

hardware y software poco uttllzados a los que se les dar otro usc.

Desde algunos usuaries que resimente entiendsn el ,~nalisis de sis-

temas, y tarnbien la de las cornputadoras (adernas de su

un placer trabajar con tales personas; de el unico pudiera

ser que el usuario y el analista tal de la discusion sobre herramlen-

tas y tecnicas del analisis de sistemas, se olvioen per de que su ver-

dadero €Os un

3.2 ADMINISTRACiON

EI termino "adrninistraclon'' es bastante analista de sistemas entre en contacto con diversos

es que el

de admintstradores:

e Administredores usuaries. Son adrnlnistradores que estan a cargo de verias personas en el area operacional don de se ve a el nuevo sistema. Esto se dlscutio anterlormente. Por 10 general son admtnistra-

dares de nivel medic que desean sistemas que una variedad

de intormes internes y de anal isis a corte Los mtorrnes internes

suelen ser intormes operacionales, de tallas, y otros por el estilo.

8 Tarnbien levanta el animo ver que cada vez hay mas de estos "expertos" que estan Ilegando a ocupar pusstos altos en la admlrustracion de organizaciones de negocios, y posiciones clave :~ otras partes de nuestra sociedad. Citibank y American Airlines, adernas de alqunas otras comparuas y organizaciones de alta tecnoloqla, estan dirigidas por personas que ascendieron a traves de los ranges del procesarniento de datos, Hacia mediados de la decada de los 80, habia aproxirnadamente media docena de miembros del Congreso de los Estados Unidos con antecedentes de programacion y anal isis.


Administradores de informatica. Son las personas encarqadas del proyecto en st de sistemas, y los adrninistradores de nivel superior encarqades de la administraelon global y olstribucion de los recursos de todo el n"'r"nn"" tecnico de la orqanizacion de craaclon 0 desarrollo de sistemas.

Adminietrscton general. Son los adrninlstradores de nivel superior que no estan directarnents involucrados can la de informatica ni son de la orqanizacton usuaria. Pudiera ser el presidente de la orqantzacion a

el jefe de administracion tinanclera contralor, el director de

etc.). Generatrnents se interesan mas bien por los sistemas de cion y de apoyo a decisionas que se discutieron en el capitulo 2. A pesar de que la adrninistracion superior sf requiere intorrnes tinancieros internes, no suele necesitar la cantidad de dstalles que ocupan los adrninistradoras usuaries (sobre todo en el area de intorrnes de tallas), Ademas, se concentran mas en la informacion externa: reg las qubernamentales, intorrnes de la cornpetencla por el intorrnes sobre

nuevos productos y etc.

La interaccion entre el analista de sistemas y todos estes adrnlntstra-

cores tiene que vel' con los recursos que se asiqnaran al proyecto, Es tarea del analrsta identiticar y docurnentar los requerimlentos del usuario y las timitsciones centro

de tee cueies se tenare que €I! sistema. Por 10 cornun, estas lirnitacionas

son los recursos: personas, y dinero. De que finalmente el analista hara

un documento que diqa: "EI nuevo sistema debora llevar a cabo las funclonss X, Y Y Z, Y debora oesarrouarss en seis rneses, con no mas de tres y con

un coste maximo de i dolares "

la adrrnrustracton que se le asequre que el de de-

sarrollo del sistema se esta manternendo centro de estes marqenes, es decir, que no S8 esta atrasando ni esta rebasando el presupuesto. Pero esto es un asunto de la admlnistracion de proyactos, no del anal isis de sisternas.? Los adrninlstradores de las diierentes areas funcionales sue len Iorrnar un cornite directivo que a clast-

los de desarrollo de rnanera que se llevsn a

varies puntos que conviene tener en mente ace rca de los adrninistradoras:

Cuanto mas alto nivel ocupen rnenos probable €Os que sepan (0 que les importe saber) de la de las computadoras. Aunque esto sea una generalizacion, suele ser valida, dada la generacion actual de adrninistradores superiores. Esto no debiera afectarls a ustsd como anahsta (es mas diffeil la labor de los dlsefiadores de sistemas), perc debe recor-

-~-------------

9 Sin embargo, en ocasiones el analista puede estar muy involucrado con la administracion. Discutiremos esto con mas detalle en el capitulo 16, al igual que en el apendice B.


dar que ha de concentrarse en tretar de las caracteristicas esencietes del sistema cuando este hablando con elias.

Las rnetas y prioridades de la adrninistracion pudieran entrar en conflicto can las de los usuaries, sobre todo las de los usuaries operacionales y los usuaries supervisores. La administracion pudiera incluso querer imponerles un sistema y obliqartos a usarlo (par ejernplo, si la orqantzaclon usuaria no ha podido responder a los cam bios en el rnercado a si no ha resultado lucrativa).

.. Una variants de 10 anterior es la siquiente: pudiera ser que la administracion no este dando los recursos, los tondos 0 el tiempo que los usuarios crean nscesarios para Implanter un sistema efectivo. Es comedo para el analista y el usuario, en este caso, responder a esto que "la adrninistracion no entienoe", pero a msnudo se trata de una decision consciente y calculada, En el Apendice B se trata mas a tendo el tema de la polltica de proqramacion y financiamiento de recursos.

.. EI termino "adrninistracion" da a entender un grupo hornoqeneo de personas que pisnsan todas de la misma rnanera; desde lueqo, la realidad suele ser muy diferente. Los adrninistradores tienen diferentes puntas de vista y opiniones, y a rnenudo tienen diterentes metas y objetivos. Discuten y compiten unos can otros, Par esto, pudiera suceder que algunos miembros de la administracion esten a favor del nuevo sistema y otros esten rotundamente en contra. Y la inditerencta que sutren algunos proyeetos es aun peor: finalmente mueren tras afios de rodeos y rodeos.

" Tarnbien es comedo suponer que una vez que la administracicn toma una decision colectiva ace rca de un determinado provecto se atiene a dicha decision. Sin embargo, no necesariamente sucede asl: pudiera ser que tuerzas externas obliguen a la adrninistracion a acelerar deterrninado pro-

a quitarle recursos 0, de plano, abandonarlo. Esto suele causar una depresion ernocional enorrne a los que intervienen en el proyecto, incluyendolo a usted como analista.

La relacion entre su proyecto de desarrollo de sistemas y la adrntnlstraclon pudiera depender en gran medida de la estructura adminlstrativa global de su orqanlzacion, score todo de la relacicn de las actlvldades del desarrollo de sistemas con el resto de la orqanizacion. La fiqura 3.2(a) muestra la sstructura orqanizacional clasica. Notese que toda la orqanizacion de procesarniento de datos rinde cuentas al jete de tinanzas y contabilidad. La razon de esto es que rnuchas organizaciones qrandes original mente introdujeron las computadoras para automatizar su contabitidad (norninas, libro mayor y cuentas).

Desde la decada de los 70, alqunas orqanlzaciones ernpezaron a darse cuenta de que esta estructura orqanizacional era bastante desproporcionada: qarantizaba

Ventas


-

Ingel'lieril:l

r- Contadurta

1- f- Flnanzas v It

administracion Proceso de datos

~~~iIMlI

Prestdente

Imrestigacion y

'- desarrollo

;...._ Personal

que el proceso de datos estuviera entocado mas bien a tuviera entoncss poco que ver can otras partes de la

pezar a 61 proceso automatlzado de datos

la comerctattzecton y la lnqeniena), orqanizaciones carnbiaron al esquema


AI obligar al qrupo de proceso de datos a tntormar dide la orqanizacion, es obvlo para todos que el proceso de

datos se vuelve tan crltico para la de la como la manu-

Iactura, la tnqenlerta, las ventas, etc.

Sin embargo, para la decada de los 80, en alqunas orqanizaciones ya hablan a darse cuenta de que el departamento de proceso de datos se habra

convertido en un , con sus poltticas y prioridadas: rnientras tanto,

las usuarias se encontraron con que ten ian toda una lista de nuevos

proyectos retrasados en espera de ser desarrollados per el de infer-

matica.t? Esto coincidio con la tntroduccion y perso-

nales y baratas. Por el en nos departarnentos de usuarios

ernpezaron a pensar que desarrollar sus sin dspender de una Iuncion centralizada. Como resultado de esc, alqunas orqanizaclones tienen

ahora una estructura como la que se rnuestra en la 3.2(c). aun existe

un central de proceso de datos 0 informatica para "clasi-

cas" tales como la nomina y el libro mayor, buena del procsso 10

llevan a cabo grupos de desarrollo de sistemas dentro de los

SI para una orqanizacion por el estilo de la descrita por la 3.2(a),

ancontrarse con que el analista de sistemas y los usuaries de los otros depar-

tarnentos no son tan buenos como de es que descubra

que la de los de desarrollo de sistemas son de de tran-

sacciones", como los que encontrarse en un departamento de contabilidad.

Si su se mas a la de la una buena

dad de que su grupo de desarrollo de sistemas tenqa una razonabls "vistosidad" polltica en los altos ranges de la empress; sin tambien detectar una creciente frustraclon per el rezaqo de los nuevos sistemas en espera de desarrollo.

Y sl en una ernpresa caracterizada por la es que

rnucno mas contacto directo con los usuaries de su sistema; de

que les rinda cuentas directarnente a elias. Y es mas que a

y en pequenas redes de sistemas cornputaclonales, directarnente per el departamento del usuario,

CONTROL DE CAUDAD Y DEPARTAMENTO DE NORMAS 0 ESTANDARES

Sequn sea el tarnano de su proyecto y la naturaleza de la para la

que trabaja, pudiera haber auditores, personal de control de calidad 0 miernbros del departamento de norrnas 0 estandares particlpando en su proyecto, S8 ha agrupado a estas personas en una sola cateqoria porque su y perspectiva se parecen en general, si no es que son iguales.

10 Disculiremos el retraso en la creacion de las aplicaciones can mas detalle en el capitulo 6.

EI general de este squipo revuelto es asequrar que su sistema se de-

sarrolle de acuerdo con diversos sstandares 0 norrnas extetnos (es dscir, externos a

estanoares de contabilldad desarrollados par la contable de su

estandares desarrollados por otros departarnentos de su o per el usuario que recibir su sistema; Y posiblemente estandares irnpuestos por di-

versas gubernamentales raquladoras.


Figura 3.2(b): Un esquema mas comun de

62 LOS PARTICIPANTES EN EL JUEGO LOS PARTICIPANTES EN EL JUEGO 63

"elntas 1t---lDesarrOIIO de alturas, por supuesto, es muy ditlcil tracer cambios lmportantes en el sis-

• sistemas terna.

Informatica

Figura

E! desarrollo de sistemas centro de las

tres problemas que debe prever, cuando este con auditores,

personal de control de calidad 0 miernbros del departamento de norrnas 0 estandares:

1. A menudo no se involucran sino hasta el final en el de

que se ha terminado con el traba]o del anal isis del sistema, el diseno y la cuando se ha comenzado con la prueba formal. A estas

2, A menudo estan farniliarizados con alquna notacion 0 formate antiques para documentacion de requerimientos de sistemas (diaqrarnas de

Por eso, es lrnportante asequrarse de que los rnodelos del sistema que

usted desarrolle sean comprensibles (vease el capitulo 1

3. POl' desqracia, los miernbros de este grupo a menudo se lnteresan mas par la forma que per el contenido: si sus docurnentos no tienen la presentaclon execte que se exiqe pudieran ser rechazados,

3.4 at, ANAUSTA DE SISTEMAS

Este es usted. EI analista de sistemas es el personaje clave en cualquier proyecto de desarrollo de sistemas, y en otras partes de este Capitulo ya se ha rnostrado la manera en la que el analista interactua con otros participantes del juego.

En un sentido mas amplio, el analista desempefia varies papeles:

.. Arque6/ogo y escribeno. Como analista, una de sus principales labores es descubrir detalles y documentar la politica de un neqocio que pudieran existir solo como "tradiciones tribales" transrnitidas de a generadon por los usuaries.

.. tnnovedor. EI analista debe dlstinquir entre slntomas, problemas del usuario y causes. Con sus conoclrnientos de la tecnologfa de las ras, el analista debe al usuario a explorer novedosas y mas utiles de las computadoras as! como torrnas nuevas de hacer neqocios. Aunque muchos de los sistemas antiques s610 se lirnitaban a perpe-

tual' el negocio del usuario, pero a velocidades e''''''''·''''

en dia los analistas se entrentan al desatlo de ayudar al usuarlo a encony rnercados radicalrnente innovadores, con la ayuda de la Pudiera ser aconsejable que lea la obra Leterei

de Edward De Bono [De para conocer tormas nuevas e inte-

resantes de considerar los

Me dieaor. Como se menciono anteriorrnente en este

a rnenuco se encuentra en entre

qramadores, auditores y otros diversos ternente estan en desacuerdo entre sf. Es tentacor para el analista

11 Sin embargo, en por 10 menos algunos casos, esto esta cambiando. POI' ejernplo, rnuchas de las echo grandes empresas contables de los Estados Unidos ya estan bien familiarizadas con las herramiemas de documentaci6n del analisis estructurado descritas en este capitulo; por eso no debieran tenor problema alguno en participar como auditores de alguno de sus proyectcs.


su propia opinion raspecto a como debe ser el sistema 0 cuales

funciones debe cumplir. Perc su labor es obtener un consenso

y esto del delicado arte de la y la

Jete de proyecto. Este no es un universal, perc aparece con la sunciente trecuencta como para ser diqno de mencionarse Dado que 61 analista suele Tener mas experiencia que los proqramadores que laboran

en el y dado que se le al rnisrno antes de que ellos em-

una tandencia natural a al analista las res-

ponsabilidades de la administraclon ""to,'"-,,

Esto ha-

bilidad para y otros tacl-

lidad en el de personas para entrevistar a los usuaries. medlar en

desacuerdos y sobrevivir a las inevitablss batallas que se dan en todos 10

los mas tnviales. Se necesita tener conocimientos de

para sntender y los asuntos del usuario. Se habilidad en

cion para entender los uses del hardware y el software en los asunto

del usuario, Y sa necesita una mente y debe se

capaz de vet un sistema desde diferentes debe dividirlo en nive

les de subsisternas y debe ser capaz de pensar en el sistema en terminos abstracto

adsmas de 2

jNadie

que iba a ser un

tacill

Como hemos dado a entender en discusicnes anteriores, el diseriador de sis-

temas es quien recibe los resultados de su de anatisis: la labor de 61 es

transtormar la libre de consideraciones de ernanada de los re-

del en un diserio de alto nivel que servira de ba-

22 se discutira la naturaleza

En rnuchos cases, el analista y el dissnador son la misrna persona a el rnisrno

qrupo unificado de personas. Aun cuando sean personas es

que se mantenqan en contacto directo a 10 largo de todo el La razon par

cual se necesita esta retroetimentecion continua entre diseriador y analista es la siel analista tiene que ofrecer informacion cetallada suficiente como para el diseriador pueda elaborar un disefio tecnotoqicarnente superior y et disefrador be proveer sufieiente informacion para que el analista pueda darse cuenta de si

12 De hecho, es debido a este requisito de ser experto en much as areas, que ta mayorla de los que se dedican a la computacton sienten que la inteligencia artificial y los sistemas expertos no se podran aplicar a! anallsis de sistemas per muches aries mas. Se discute esto mas a fondo en el capitulo 25.

LOS PARTiCIPANTES EN EL JUEGO 65

que del usuario esta docurnentando son posibles.

en 10. informacion recibida, el analista posiblernente tendra que np',rJC)(;IRI con el usuario para modificar otros

3.0 lOS PROGRAMADORES

arqumentar que en el meier de los rnundos no habrla contacto entre un y un proqramador. Sobre todo en los de desarrollo de sistemas, 8S probable que los diseriadores funcionen como un "arnortiquador" entre

los analistas y los es decir, los analistas sus resultados

no tscntca de los del

los suyos (una software que se usara para poner en

Existe otra razon por 10. cual el analista y el

contacto rnuy 0 nulo, entre sf: a rnenudo, se lleva a cabo el

do una sscuencia rnuy estricta en algunos de desarrollo de sistemas.t?

POl' eso, 10. labor del analista S8 hace y 5e termine pot antes de

que eomience 10. labor de que el analista muy

mente astara incluso antes de que el

vsnqa en el actual.

contacto entre

v

En los proyectos los de diseriadcr y proqrarnador se combinan, de tal manera que una sola persona hace tanto el de analista como el de disefiador y por tanto interactua can el pro-

o suceder que una sola persona malice la labor de di-

EI analista a veces sirve de adminlstrador del concluido su labor de especiticactcn de los rna, aun estara involucrado en el proyecto y tendra proqramador,

A rnenudo es el 81 que descubre errores If en

la "propuesta de entraqada per el anatista, pues es du-

rante la proqramacion, como dice mi coleqa Scott cuando "10.

llanta se adapta al astalto", donee una resefia de los requeri-

rnientos del sistema se traduce en un juego de lnstrucciones rnuy

ficas y detalladas de COBOL. Si algo 0 esta mal 0 contuse, el

,3 Discutiremos en el capitulo 5 algunas alternativas a sste enfoque secuencial, sobre todo las conocidas como desarrollo evelulivo 0 rastreo rapido, De hecho, en algunos proyectos el analisis continua a la vez que se esta Ilevando a cabo la proqrarnacion.


proqramador tiene dos opciones: pedirle una aclaracion al analista 0 bien prequntarts al usuario.t+

$ Como se rnenciono en el capitulo 2, muchas organizaclones se estan viendo en la necesldad de reernplazar los sistemas operacionales oriqina, les que se crearon hace 20 afios. En la gran rnayorta de estes proyectos de reernplazo, casi no hay documentaclon que describa t) como funciona el sistema 0, mas lmportante aun, 2) que es 10 que sa supone que el sistema debe nacer. Y dado que los sistemas tienen 20 aries de antiquedad, hay toda una nueva qeneracion de usuaries involucrados. Los usuarlos que inicialmente especificaron los requerirnientos del sistema ya se jubllaron 0 renunciaron, y la nueva qeneracion tiene pocas nocionss sobra esos requerlmientos. A estas alturas, todas las rniradas se vuelven hacta el proqrsmeaor de mentenimiento, que ha estado manteniendo el sistema durante los ultirnos afios: es probable que sste tarnbien sea un trabajador de sequnda 0 tercsra qeneracion, que nunca haya tenido contacto con los disefiadores y proqrarnadores que construyeron orlqlnatmente el sistema. Como 10 sefiala Nicholas del boletln Software Maintenance News),

Hasta ahora, el profasional clave de la cornputaclon era algulan que pudiera conocer 10 suticiente ace rca de las necesidades de las organizacionas como para expresarlas en terminos computacionales. En el futuro, al computarizarse irrevocablemente nuestra sociedad, el profasional clava sara alquien que pusda aprender 10 suticiente acerca de los sistemas computacionales como para expresarlos en terminos humanos. Sin ese alguien, habremos perdido el control de nuestra sociedad. Ese alguien es el ingeniero a la inversa, Los encargados del mantenimiento de software son los ingenieros a la inversa de la sociedad.

$ estan empezando a cambiar sus equipos de de-

sarrollo de proyectos de una estructura vertical a una horizontal. La distribucion tiplca de responsabilidades se supone a 10 de todo este que todas las tarsas del analista se Ie asiqnen a una sola persona (0 a un solo grupo de de rnanera todas las actividades de diserio se Ie asiqnan 0.1 dlsenador y todas las de pro-

14 De hscho, el ccntacto directo entre el programador y al usuario es mas cornun de 10 que pudiera pensarse. En muchos cases, el anatista nunca Ilega a describir los detalles de bajo nivel del sistema, y los usuaries de alto nivel con los que se comunica el sistema pudisran no estar al tanto ni es-

tar en dichos detalles. Por eso, a menudo el programador debe hablar directamente

con al de bajo nivei para descubrir exactamente que as 10 que se supone que debe hacer el

sistema. Esto es importante, pues muchas organizaciones se quejan del hecho de cue el 50% de sus proysctos de desarrollo de sistemas se dedican a las pruebas; pudiera sucader qua al trabajo que se haee con el pretexto de probar saa de hecho la labor de analisis que se pudiera (y probablemente sa debiera) haber hecho anteriormente.


qramaclon al programador. En la rnedida en que se cumpla esto, ciertamente parecerta que los analistas y los proqrarnadores tienen poco eontacto entre sf. No obstante alqunas orqanlzaciones sstan empezando a percatarse de que en esto exists un confticto inherente: los analistas suelen ser relativamente de alto nivel y de gran experiencia dentro de la empresa; sin embargo se espera que ellos lleven a cabo no s610 las labores de alto nivel, tales como el establecirnlento conceptual de los requerlrnientos del sistema, sino tarnbien labores de bajo nivel, como los engorrosos detalles de los requerimientos del usuario. Existe un contlicto similar con los proqrarnadores, quienes tipicarnente suelen ser empleados rnenores y de menos experiencia. Una soluclon seria darle al personal tecnico superior (cuyo titulo resulta ser el de analista) todes las tareas de alto nivel: el anal isis de alto nivel de sistemas, el disefio de alto nivel, y fa coditicecion de los modules de a/to nivel del sistema. Similarrnertte, a las personas de nivel tecnico inferior se les dara tareas detalladas de ba]o nivel en las areas de analisis, de disefio y de proqramaclon. En la rnedida en que esto se siga, los analistas y los proqrarnadores mantsndran un contacto cercano durante todo el proyecto: de heche, cada uno hara parte del trabajo que anteriormente le correspond fa al otro, Esto se volvera a discutir en el capitulo 23.

3.7 at, PERSONAL DE OPERACIONES

As! como se pudiera argumentar que el analista nunca se encontrarla con un programador, pudiera arqurnentarse tarnbien que no necesitara tener contacto can el de opereciones responsabte del centro de compute, la red de telecomunicaclones, la sequridad del hardware y del software, adernas de la ejecucion de los proqrarnas, el monta]e de los discos y el rnane]o de la salida de las impresoras. Todo 8StO sucede despues de haber sido tanto analizado y diseriado como proqrarnado y probado el sistema.

Sin embargo, hay mas de 10 que parece a simple vista: el analista debe entende: las restricclones irnpuestas al nuevo sistema por el personal de operaciones, pues 8sto influye en la especiticacicn dstallada que produzca, Es decir, el analista pudiera elaborar un documsnto que diga: "el nuevo sistema de pedioos debera ser capaz de llevar a cabo las funciones X, Y Y Z y, para poder setisiecer los reouisiios impuestos par ef departamento de ooereciones, no debe de ocuper mas de 16 megabytes de memoria de fa computedore ptinctpet. E! sistema debe imptsnterse utilizendo terminates IBM 3270 estsnaer comuniceoes con te red XYZ de telecomuniceciones de te compeiiie".

En algunos cases, los detalles operaclonales del sistema pudieran reducirse a una cuestion de neqoclacton entre el usuario y el grupo central de operaclones de la computadora. Esto es muy comun hoy en dfa, dado que a menudo los usuarios es'can en posibilidades de adquirir sus propias computadoras personales 0 minicompu-


tadoras de tarnafio apropiado para sus departamentos. A pesar de que la mayona de estas computadoras pueden ser utilizadas per oficlnistas 0 adrninistratlvo de la orqanlzacion usuaria (es decir, no se rsquiere personal que tenga la especializacion del de operaciones), y a pesar de que muchas de elias pueden trabajar en un arnbiente normal de oficina (es decir, que no requieren del sistema especial de conexiones y del alre acondtcionado que necesitan las qrandes rnaquinas), aun sueie resultar que estas cornputadoras pequerias tendran que comunicarse con la computadora principal (por ejsmplo, para parte de una base de datos 0 para subir los resultados de un catcuto departarnental), y a menudo resultara que las PC 0 cornputadoras personates pequefias 0 las minlcomputadoras tend ran que comunicarse entre sf a travas de una red local 0 de otro sistema de telecomunlcaclones. Todo esl0 usualrnente la interaccion con el personal de operaciones; sin su s610 se pod ria construir un sistema real mente

de la tarea del analidel usuerio. Esto se

Estos asuntos

RESUMEN

Como se vio en este 131 analista de sistemas es un orquestador, un

comunicador y un tacllttador. En las Partes II y III se hara evidente que el analista

Ileva a cabo una gran cantidad de traba]o 61 perc que realiza aun mas trabaio

en armenia con los dernas del de los sistemas. Como analista,

cuanto mas conozca ace rca de las personas con las que tanto le ira.

Todos los participantes son personas y tisnen diferentes rnstas, Y

perspectivas. estar publicamente con el exito del

tenor razones ocultas para oponerse a uno 0 mas de este.

Las y al final de este tienen como hapensar mas ace rca de estes ternas. Tal vez desee consulter el excelente libro

de Block que trata de la politica de los 1982] 0 incluso la obra cla-

sica de Sun Tzu sobre el arte de la guerra

REFERENCIAS

Information Payoff. Nueva York: Free

1985.

The Politics of Projects. Nueva York: YOURDON Press, 1982. Controls into Structured Systems. Nueva York: YOURDON

2. Robert

3. Alan Press, 1982.

4, Sun Tzu, Ef ette de fa guerra. Nueva York: Delacorte Press, 1983,


De Bono, Latera!

Nueva York: Penguin

1970.

5.

6. Leeson, Systems Anetisis and Design Chicago: Science Research As-

sociates, t 981.

7. Lavette C. Teague, Jr. y Christopher Pidgeon, Structured Methods

for Information Systems. Science Research Associates,

1985.

V EJERC!CIOS

Mencione por 10 rnenos un partlclpants adicional con 131 que

en un de desarrollo de sistemas.

interactuar

2, Describa un proyecto en el cual el analista no tenqa contacto directo con el ver-

dadero usuario. l,Cuales son las ventajas y de esta situacion?

otros alternos pudieran haberss hecho?

Ie ocurre alqun otro terrnlno que a cliente?

3.

usarse para 131

adernas de

4. le ocurre alguna situacion donee el analista no debiera hablar can el usua-

rio?

se tendrian al ser el usuario miernbro de

de desarrollo del sistema? Ie oeurre ai-

en el que serla incluir a un

6. son las ventajas y de que el usuarlo sea administrador del

encargado del de desarrollo del sistema? Ie ocurre

especlfico donde Iuera muy tener de administrador del proyec-

to a un usuario?

7. son las ventajas y dssvsntajas de que 131 usuario desarrolle 131 sistema

de informacion 131 solo? Ie ocurre proyscto donde fuera buena qua el

usuano hiciera las veces de analista, proqrarnador y adrninistrador?

8. tendrra que saber 131 usuario de computadoras y software para poder

participar en un equipo de proyecto durante la tase de analisis del sistema? tend ria que saber de las herrarnlantas y tecnlcas del analisls de siste-

mas?

9. tend ria que saber un usuario ace rca de las cornputadoras y 131 software

para poder administrar un equtpo de proyecto de desarrollo de sistemas? necesitara saber acerca del analisis de sistemas para ser buen administrador?

70 lOS PARTICIPANTES EN El JUEGO

10. 6Cuanto debe saber un usuario de computadoras y software para poder llevar a cabo 01 solo un proyecto de desarrollo de sistemas? l,Cus.nto debiera saber ace rca del analisis de sistemas?

11. l,OUe precaucionss especialss tomana como analista de sistemas si no tuviers contacto directo con el usuario? l,Cree que serlan suficlentes las herramientas descritas en este libra?

12. En la seccion 3.1.2 se rnencionan varias de las preocupaciones que pudiera tener el usuario operacional acerca de un sistema nuevo. Mencione las tres mas probables. l,Cree que estas preocupaclones son razonables 0 que solo reflejan la tlpica talta de Iamillarldad del usuario con las computadoras?

i 3. l,Oue responsabilldad etica y moral tiene 61 analista con el usuario operaclonal sl 131 primero esta convencido de que no causara despioos, pero el usuario se preocupa por la posibuidad de que sl los cause? (Vease tarnbien la pregunta 19)

14. Describa el escenarto en el que los usuaries operacionales pudieran ocasionar que un nuevo sistema no tuncione. l,Cree que su escena sea reallsta? l.No podria el usuarlo supervisor slmplemente ordenar que se use el sistema?

i5. l.Cuando cree que deban discutlrse can los usuaries los asuntos relacionados con la interfaz hurnana? l,AI cornienzo del proyecto? l,A finales de este? l,Cu<il es 121 interaccion lndicada? (Puede consulter el capitulo 21 si 10 desea).

i O. l.Cree que sea poco realists que los usuaries operacionales tenqan solo un panorama local del sistema en 61 que participan? Cree que sea seguro para 61 analista dar por un heche ssto? que esto sea posltivo? tratar el analista de proporcionar un panorama global a los usuaries operaclonales?

i 7. De un ejernplo del panorama Ilslco de un sistema 0 de su irnplantacton, que pudiera tener el usuario operacional. l,Le encuentra algun problema a esto?

18. l,Oue debe hacer el analista si 131 usuario supervisor no le permits hablar directarnente con los usuaries operacionales? Como puede el analista manejar situacion?

19. responsabilldad ettca 0 moral tiene 81 analista con el usuarto supervisor

los usuarios operacionales le expresan su preocupacion ace rca de posibles despidos ocasionados par 81 nuevo sistema? (V ease la prsqunta 13.)

20. De un ejernplo de un sistema en el que 81 usuario supervisor pueda no estar millarizado con la polltica detallada de neqocios a la que se esten ateniendo los usuaries.

lOS PARTICIPANTES EN El JUEGO 71

21. que los usuarios tiplcos del nivel ejecutivo normalmenta no se interesan

per .el posible ahorro que representana la reducclon del personal, que se hal'S. posible con ra puesta en practlca 0 la irnplantaclon del nuevo sistema?

22. GQue tanto se deben involucrar los usuaries del nivel ejecutivo en el desarrollo de un nuevo sistema de informacion?

23. GOue opciones uene el analista si el usuario no entiende los model os abstraclos en el papal?

24. debera hacerse cargo el analista del "novato presuntuoso" descrlto en

este capitulo? l,Oue hacer si el usuario lnsists en un determinado hardware 0 software para el nuevo sistema?

25. l,Oue tanta respcnsabllldad debe asumir el analista por la obtencion del con-

sense de los usuaries? tal si el analista no logra hacerlo?

26. l,Oue riesqos cree que atronta el analista provenlentss de la administraclon, sese expuso en la seccion 3.2? l,Que puede hacer el analista para rninimizar estes riesqos?

27. debe hacer 131 analista si las rnetas y prioridades de la adrninistracior: en-

tran en contltcto con las de los usuarios?

28. L.Cuando cree que deba hacerse participante en proyecto a la gente de operaclones?

29. l.Debe la misma persona (0 el rnisrno grupo de personas) lIevar a cabo tanto el anal isis como el disefio (y la proqrarnacionj del sistema? l,Cuales son las veriy desventajas?

©J [D) l
1f~ 'f ~ La naturaleza cuenta con una especie de sistema coordenado geometrico-arttmetico, pues tiene toda erase de model os. Nuestra experiencia de la naturaleza es por medio de modelos y tcdos son muy hermosos. Me di cuenta de que el sistema de la naturaleza debe ser una verdadera belleza, pues encontrarnos en quimica que las asociaciones siempre se dan en llndos numeros enteros. No hay tracctones.

R. Buckminster Fuller De "In The Outlaw Area: Profile by Calvin Tomkins" (En zona prose rita: semblanza por Calvin Tomkins), The New Yorker, 8 de enero de 1966.

Ei hombre as un animal qua emplea herramientas ... Sin elias nada es, con elias 10 as todo.

Thomas Carlyle, Sartor Reesrtus, Tomo I, capitulo 4.

En este capitulo se

un

2,

de

3, 4, 5,

7.

un

!a

72

del

HERRAMIENTAS DEL ANALISIS ESTRUCTURADO 73

G ran parte de la labor que desernpefiara como analista involucra el mode!edo del sistema que desea el usuario. Como veremos en este capitulo y con mas detalle en la parte II, hay muchos tipos diterentes de rnodslos que podernos elaborar, asl como hay muchos modelos diterentes que pueds hacor de una casa nueva un arquitecto, Los modelos de analisis de sistemas que se discuten en este libro son, en su mayoda, modelos en papa! del futuro sistema, es decir, representaciones abstraclas de 10 que at final sera una cornbinacion de hardware y software de cornputadora.

EI termino "rnodalo" pudiera parecerle alqo formal y atemonzanto, pero repre-

senta un concepto que usted ha rnanejado durante la mayor de su vida. Consi-

ders los sipuientes tipos de modelos:

@ Mepes: modelos bidirnansionales de nuestro mundo en que vivimos.

@ Globos tetrequeos: rnodelos tridimenslonales de nuestro mundo,

" Diagramas de tiuio: representaciones esquernaticas de las decisiones y la secuencia de actividades para llevar a cabo un determinado proceoirniento.

Dibujos etquitectonicos: representaclones esquematicas de un 0

de un puente, etcetera,

$; Pettitures musicales: representaciones graficas y textualss de notas musi-

cales y tiernpos de una musical.

no sepa leer el modelo arquitectonlco que se rnuestra en la figura 4.1, el de dicho modele no deberta asustarle: no es demasiado dificil imaginarse que pudiera aprendor a leer y entendar tales rnodelos, aun si jamas piensa crear uno usted rnisrno. De rnanera probabternonts no sepa aun leer 0 lnterpretar muenos de los modelos usados per los analistas de sistemas, perc sabra leerlos y crsarlos euando terrnlna de leer este libro. los usuaries con los que traba]a podran ciertaments leer los modelos una pequefia ayuda inicial) y incluso ser capaces de creartos.

",Por que construimos modelos? LPor que no se construye simplemente el sistema rnismo? La respuesta es que podernos construir rnodelos de manera tal que enlatizamos ciertas propiedadas criticas del sistema, mientras que slrnultaneaments desacentuarnos otros de sus aspectos. Esto nos permlte comunicarnos con el usuario de una rnanera entocada, sin distraernos con asuntos y caracterfsticas ajenas al sistema, Y sl nos dames euenta de que nusstra ccmprenslcn de los del usuarto no fue la correcta (0 de que el usuario cambio de parecer ace rca de sus podemos hecer cembtos en et modele 0 desecharlo y tiecer uno nuevo, de set neceserio. La alternativa es tener alqunas reunionss pretimlnarss con sl usuano y luego construir todo el sistema; desde lueqo, existe el riesgo de que el orooucro final no sea aceptabte, y pudiera ser excepcionalrnents 00St080 hacer un cambia a esas alturas,

74 HERRAMIENTAS DEL ANALISIS ESTRUCTURADO

Por esta razon, el analista hace usc de herramientas de rnodelado para:

.. Concentrarse en las propiedades importantes del sistema y al mismo tiempo restar atencion a otras menos importantes.

.. Dlscutir cambios y correcciones de los requerirnientos del usuario, a bajo costo y con el riesgo mlnimo.

" Verlficar que el analista cornprenda correctamente el ambients del usuario y que 10 haya respaldado con informacion documental para que los disefiadores de sistemas y los proqrarnadores pusdan construir el sistema.

No todas las herrarnientas de modelado cumplen con estes propositos: por ejernplo, una descnpcion narrative de 500 paginas de los requerimientos del usuario

Figura 4.1: un modele arqulteetenlco tlpico

(que es, grosso modo, un modele) podria 1) Contribuir a obscurecer tooes las propiedades del sistema, 2) Costar mas en su elaboracion que el sistema mlsrno y 3) no verificar sl el analista cornprendio 0 no las necesidades males del usuario. En el capitulo 8 se sxploraran con mas detalle las caractertsticas que debe tener una herramienta de modelado para serle utll al analista.

Ahora, presentarernos y discutirernos brevernente tres herramientas de modelade de sistemas irnportantes: el diaqrama de flujo de datos, el diagrama de entidadrelacion y el diagrama de translcion de estados. EI diaqrarna de de datos llustra las funciones que el sistema debe realizar; los diagramas de entidad-relacion hacen entasis en las reteciones entre los datos y el diagrama de transicion de sstados se


enfoca al comportamiento dependients del tiernpo del sistema. Los capltulos 9 at 16 tratan estas y otras herramisntas con mas detalle, Como veremos, las tres herramientas principales conslstsn en graficas (imaqanes) y herramlentas textuales adidonales. las graficas proporcionan una rnanera fadl de leer para que el analista pueda rnostrarle a los usuaries las principales componentes del modele, al iguai que las conexiones (0 interfases) entre componentes. Las herramientas de modelado textuales adicionalos presentan definicionas precisas del significado de los cornponantes y conexiones.

4.1 MODELADO DE LAS FUNCIONES DEL SISTEMA:

EL D!AGRAMA DE FLUJO DE DATOS

Un viejo adagio de la protesion de desarrollo de sistemas dice que un sistema de proceso de datos involucra tanto los datos como el proceso, y no se pueds construir un sistema exitoso sin considerar ambos componentss. EI aspscto de proceso de un sistema ciertamonts es algo importante de modelar y de verificar con el usuario. EI rnodelado que llevamos a cabo puede describirse en una variedad de maneras:

e LCon que funciones debe desernpefiar el sistema? LCuales son las lntsracciones entre dichas tunciones?

I' LQue transformaciones debe llevar a cabo el sistema? LQue entradas se transtorman en que salidas?

.. LQue tipo de labor debe realizar el sistema? GDe donde obtiene la informacion para llevar a cabo dicha labor? GD6nde entreqa los resultados de su labor?

La herramienta de modelado que utilizarnos para describir la transformacion de entradas a salidas es un diagrama de tiujo de datos. En la tiqura 4.2 se rnuestra

un diagrama de de datos tlpico.

Los diaqramas de flujo de datos consisten en procesos, agregados de datos, y terrninadores:

I'

Los ptocesos se representan por medio de circulos, 0 "burbujas", en el diaqrarna. Hepresentan las diversas funcionas individuales que el sistema lIeva a cabo. Las funcionss transtorman sntradas en satidas.

Los tiujos S6 muestran por medio de flechas curvas, Son las conexionss entre los procesos (funciones del sistema) y representan la informacion que dichos procasos requleren como entrada 0 la informacion que generan como salida.

Los agregados de datos se rspresentan por media de dos llneas paralelas o mediante una elipse. Muestran colecciones (0 agregados) de datos que


CLiENTES

Pedidos cancelados

BODEGA

PEDIDOS

I

I pedidos \

Detalles ~

del pedido Detalles

Nombre del cliente, de envfo

RE~'EP- direccion del clients

PCIONDE)

Informacion de cuenlas

( FACTURAS 1

( \~ ~ CO:::N-)

Contabilidad

Nombre del cliente, direcclon del clients

Nombre del cliente, detalles de la factura

Facturas, deciaraciones

cobros, indagaciones

Figura 4.2: Un dlaqrarna de fll.ljo de datos tiplcc

el sistema debe recordar por un periodo de tiempo. Cuando los disefiadores de sistemas y los proqrarnadores terrninan de construir el sistema, los aqrsqados existiran como archives 0 bases de datos.

., Los terminedores muestran las entidades externas con las que el sistern se comunica. Tlpicarnente se trata de individuos 0 qrupos de person (per ejernplo, otro departamento 0 division centro de ta orqanizacion), si ternas de compute externos y orqanizaciones externas,

Los diaqramas de de datos se discuten con mas detalle en el capitulo

(Adernas de los procesos, flujos y aqreqados, un olaqrarna de de datos pu

tener tam bien tiujos de control, procesos de control, y agregados de control. Est resultan utiles para modeler los sistemas de tiempo real y se diseuten con mas det lie en el capitulo 9.)

Aunque el diaqrama de tlu]o de datos proporciona una vision global conveniente de los cornponentes funcionales del sistema, no da detatles de

Para rnostrar detalles ace rea de que informacion se transtorma y de como se forma, se ocupan dos herramientas textuales de rnodelado adicionales: EI rticcions-


iio de datos y ta especiiicecion de procesos. La figura 4.3 rnuestra un diccionario de datos tlpico para 131 diagrama de flujo de datos que vimos en la fiqura 4.2. De manera la figura 4.4 muestra una especiticacion de proceso ttptca para un solo proceso del diaqrarna de flu]o de datos de la fiqura 4,2.

Tratamlerrtc de cortesia 0 titulo + nombre + apetltdos

'rratamlentc de

o titulo =

[Sr. I Srta, I Sra. I Dr. I PreLJ

{caracter valldo] {caracter valldo]

I a-zl ' I - IJ

Figura 4.3: Un dlcclonario de datos

1> SI el monto en dolares de la factura muttipllcado por el nurnero de semanas de retraso en 61 paqo rebasa los 10,000 dolares ENTONCES;

a. Proporcionar una totocopia de la tactura al encarqado de ventas que llamara al cliente.

b. Anotar en 61 reverse de la factum que se Ie dio una copia at vends-

dor, con la techa en la que se hizo esto.

c. Volver a archivar la factum para estudiarla de nuevo dentro de des sernanas.

51 se han enviado mas de cuatro recordatorios

2. EN CASO ENTONCE5:

a. Dar una copia de la tactura al vendedor clients.

para que lIame al

b. en el reverse de la factum que una copia ha side enviada

al vendedor, y la Iecha en la que se hizo esto.

c. Volver a archivar la tactura para reexaminarla dentro de una sernana,

3.

EN CASO CONTRARIO (Ia situacion aun no ha alcanzado proporciones series):

a. Anadir 1 at contador de avisos de moratoria reqistrado en el inverse de la facture (si no se ha reqistrado tal contador, escribir: "cusnta vencida de avisos de moratoria = 1")


b. SI la tactura archivada es ileqible ENTONCES mecanoqrafiar una nueva.

c. Enviar una copia de. la tactura al cliente, can el sella: "n-esimo aviso: paqo de tactura vencido. Favor de rernitir inrnediatarnente", donde n es el valor de avisos de moratoria.

d. Registrar en el reverse de la tactura la Iecha en la que se envlo et nesimo aviso de moratoria.

e. Volver a archivar la factura para examinarla dentro de dos sernanas,

Figura 4.4: Espec:ificacion de proceso tiplca

Queda mucho que decir acerca de los diagramas de flujo de datos, los diccionarios de datos y las especiticaclones de procesos; en los capltulos 9 a 11 se presentan mas detalles de esto. Verernos, par ejemplo, que la mayoria de los sistemas cornplejos se rnodelan con mas de un diagrama de de datos; de heche, pudiera haber docenas 0 centenares de diagramas, acomodados de acuerdo con niveles de [erarqula. Y verernos tam bien que hay convenciones para la manera de etiquetar y numerar los elementos del diagrama, y tam bien hay qulas y reqlas que perrniten distinquir entre diaqramas buenos y malos.

4.2 El MODElADO DE DATOS AlMACENADOS: st, D!AGRAMA DE ENTIDAD=FlElACION

Aunque el diagrama de flujo de datos es una hsrramienta muy util para modelar sistemas, s610 resalta un aspecto principal de un sistema: sus funciones. La notacion de los agregados de datos en los diaqrarnas de de datos muestra la existencla de uno 0 mas qrupos de datos almacenados, perc deliberadamente dice muy poco ace rca de sus detalles.

Todos los sistemas alrnacenan y usan informacion ace rca del ambients en el Qual interactuan; a veces, la informacion es minima, pero en la mayorla de los sistemas actuates es bastante comple]a, No solo desearnos conocer en detalle que informacion hay en cada agregado de datos, sino que tarnbien querernos conocer la relacion que exists entre agregados. Este aspecto del sistema no es resaltado por 81 diagrama de de datos, pero sf 10 hace otra herrarnienta: el diagrama de entidedretecion. La figura 4.5 muestra un diagrama tlpico de entidad-relaclon.

EI diagrama de entidad-relacion consta de dos cornponentes principales:

1. Tipos de objetos. Se representan por media de un rectanqulo en el diagrama. Esto representa una coleccion 0 conjunto de objetos (cosas) del mundo real cuyos rniembros juegan alqun papel en el desarrollo del sistema; pueden adernas ser identificados de manera unica y ser descritos per uno 0 mas atributos.


2. Betecionee. Se representan por medic de rornbos en el diagrama y son la serie de conexiones a asociaciones entre los tipos de objetos que estan conectados con la relacion par medio de flechas.

PEDIDO

LiBRO DE CONTABILIDAD

Figura 4.5: Un diagrama de entldad-retaclcn

AI igual que con el diaqrarna de de datos, hay mucho que decir ace rca del

diaqrarna de entidad-relacion y se tratara can mas detalle en el capitulo 12. Veremos que existen ciertos tipos de objetos especializados, as! como qulas para asequrar que el diagrama de entidad-relacion sea complete y conqruente.

AI igual que can el diagrama de flujo de datos, es necesario acompariar el diagrama de entldad-relacion con informacion textual detallada. EI diccionario de datos que vimos por primera vez en la figura 4.3 tarnbien puede usarse para mantener in-


tormacion apropiada ace rca de los capitulos del i 0 al 12,

y relaciones. Esto se tratara mas a tendo en

4.3 El MODElADO DEL COMPORTAMIENTO DEPEND!ENTE DEL TIEMPO: El DIAGRAM A DE TRANSICION DE ESTADOS

EI cornportarnlento dependiente del tiernpo, es decir, la sscuencla con la cuat se hara el acceso a los datos y se ejecutaran las Iunciones es un tercer aspecto de rnuchos sistemas complejos, Para algunos sistemas cornputacionales de ernpresas este aspecto no es importante, puesto que la sscuencia es esencialmente trivial, Asi, en muchos sistemas computacionales que ni son de tiernpo real, ni estan en linea), la funcion N no pueds Ilevar a cabo su labor hasta que recibe la entrada que requiere: y esta entrada se produce como salida de una funcion N-i, Y as! suceslvamente.

Sin embargo, rnuchos sistemas en linea y de tismpo real, tanto en el campo de los neqocios como en el de la ciencia y la inqenierta, tienen complejas relaciones en el tiernpo que deben rnodelarse tan cuidadosarnente como las funciones y las relaclones entre datos. Par ejernplo, muchos sistemas de tiempo real deben responder dentro de un margen breve, posiblernente de tan solo unos mlcrosequndos, a ciertas sntradas provenientes del ambients exterior. Y debsn estar preparados para recibir diversas cornbinaclones y secuencias de entradas a las cuales S6 debe responder adecuadamente.

La herrarnienta de modelado que utilizarnos para describir este aspecto del cornportamlento de un sistema es el diagrama de trans/cion de que a veces se abrevia (per sus siqlas en inqles) STD. Un diagrama se muestra en la figufa 4.6: modela el comportamlento de una lavadora control ada per computadora. En este diagrama, los rectanqulos representan los estedos en los que se puede sncontrar el sistema ejemplo, "escenarios" 0 "situaciones" reconocibles). Cada estado represents entoncss un durante el cual el sistema sigue algun comportsmiento las Ilechas que conectan un rsctanqulo can otro representan el cambio de estado 0 transiciones de un estado a otro. hay una 0 mas condiciones (sucesos 0 circunstancias que propiciaron el carnbio de sstado) asociadas con cada carnbio de y una 0 mas (0 tal vez ninquna) scciones, as decir respuestas, salidas 0 actividadas que se llevan a cabo como parte del cambio de estado, En el capitulo 13 sa examinara con mas detalle el diagrama de transicion de estados.

4.4

El MODElADO DE lA ESTRUCTURA DE lOS PROGRAMAS: ei, DIAGRAMA DE ESTRUCTURAS

Aunque no las usara rnucho como analista de sistemas, debe estar al tanto de que se utilizan rnuchas herramientas de modelado adlcionales durante la creacion de un sistema complejo. Por ejamplo, los disefiadores de sistemas suelen utilizar los diaqrarnas de de datos, olccionarlos de datos, especlftcaclcnes de procssos y


diagramas de entidad-retaclon y de transicton de estados creados por el analista para crear una arquitectura de software, es decir, una [erarqula de rnodutos (los que a veces se conocen como subrutinas 0 procedimlentos) para realizar los requerimientos del sistema. Una herramienta graiica de modelado cornunrnents utilizada para re-

tal [erarqula de software es el aieareme de estructures; en la figura 4.7 se muestra uno tipico. En este diaqrama, cada rectanqulo representa un modulo

una subrutina de FORTRAN, un procedimiento de Pascal, 0 un parrato 0 de COBOL), Las tlechas que conectan los rectanqulos representan las de modules (per ejernplo, llamados de subrutinas 0 llarnados de proceEI diagrama tarnbisn rnuestra los parametres de entrada que se Ie dan a cada modulo invocado, y los parametres de salida devueltos per cada modulo cuando tarrnlna su labor y le devuelve el control al que 10 llama.

COMENZAR,

DESHABiUTAR EL "LLENADO"

HAB!lITAR EL 'UENADO"

lLENADO

DESHABILITAR EL "LAVA DO"

ALTO,

LAVADORA LLENA,

HABILITAR EL "LAVA DO"

CICLO DE LAVADO

HABILITAR EL "SECADO" CENTRIFUGO

CICLO DE SECADO CONCLUIDO,

DESHABIUTAR EL "SECADO"

Figura 4.6: Un dlaqrams de transtelen de estados


A pesar de que 131 diaqrarna de estructuras es una herramienta excalente para los disenadores de sistemas, no es el tipo de modele que normalmente se mostrarla al usuario, pues modela un aspecto de la impientecion del sistema, no de sus requertrnientos. i Discutirernos nuevarnente los diagramas de estructuras en 131 capitulo 22,

'-::-;---~---' 0 reg,

~

EXTRAER CARACTER

INSERTAR CARACTER EN El REGISTRO

Figura 4.7: un dlagrama de estructuras

4.5 RElACIONES ENTRE MODElOS

Como podra verse, cada modele grafico descrito en este capitulo se enfoca a un aspecto distinto de un sistema: 131 diaqrarna de flujo de datos ilustra las tunciones, 131 diagrama de entidad-relacion resalta las relaciones entre datos y 131 diagrama de transicion de estados resalta 131 comportamiento dependiente del tiernpo del sistema. Dado que los sistemas tlpicos son muy complejos, es util estudiar por separado cada uno de estes aspectos. Por otro lado, estes tres panoramas del sistema deben ser consistentes y compatibles entre st.

1 Como se senalo en el Capitulo 3, algunos usuarios saben mas que otros de cornputadoras, y algunos usuarios desernpefian un papel mas activo en los proyectos de desarrollo de sistemas que otros. Si esta trabajando con un usuario que as miembro de tiempo completo del equipo del proyecto, 0 tal vez incluso si es el jele del proyecto, y si es conocedor del dlserio de sistemas, no hay razon por la que no deba mostrarle un diagrama de estructuras. Sin embargo, si el usuario solo se interesa por describir que tiene que hacer el sistema, probablemente no Ie interese ver un diagrama que describa la organizaci6n de las subrutinas de FORTRAN que cubriran dichos requisitos.


En el capitulo 14 se examinaran alqunas reg las de consistencia que asequran que este caracteristica este presents en los tres principales modelos de sistemas, can sus modelos textuales detallados, Por ejemplo, verernos que cad a aqreqado del diagrama de Ilujo de datos debe corresponder un objeto 0 relacion del diagrarna de entidad-relacion.

4,6 RESUMEN

Los modelos que se muestran en este capitulo son relativaments simples y faGiles de leer 0 interpratar, Se tuvo mucho cuidado para loqrar esto, puss la intenci6n es que puedan leerlos los usuaries sin gran preparacion. Sin embargo, como veremos en los capitulos 9 a 16, se requiere mucho traba]o y cuidado para crear diagramas y asequrarse de que sean completes y consistentes, y que representen de

manera los requerirruentos del usuario.

PREGUNTAS Y EJERCICIOS

1, La introducclon al capitulo 4 menclona rnapas, globos terraqueos, diagramas de flujo de datos, dibujos arquitectonlcos y partituras musicales como ejemplos de modelos, Mencione otros ires ejernplos de rnodelos usados cornunmente.

2, LQue deflnicion da el diccionarlo de la palabra "modelo"? LSe puede aplicar a los sistemas de informacion?

3, LPor que se utilizan rnodelos en 131 desarrollo de los sistemas de informacion?

Msncions tres razones.

4, LComo rssponderta si el usuario le dijera que opina que los model os son un desperdicio de tternpo y que deberfa ernpezar a codificar?

5. que la descripcion verbal que un usuario de ace rca de los requerimientos

de su sistema deba considerarse como un modele? que sf 0 por que no?

6, que seria uti I tener mas de un modelo para un sistema?

7, Todos los modelos que se discuten en 131 capitulo 4 son modelos en papal. GSe Ie ocurre atqun otro tipo de modelo?

8, La mayona de los modelos que se dlscuten en 131 capitulo 4 son herrarnientas graficas (por ejernplo, irnaqenes) LCuales cree que puedan ser las ventajas de utilizar imaqenes como herrarnientas de model ado?

9. LConsidera que las herrarnlentas de modelado qraftco sean suticlentes para representar los rsquerimientos de un sistema de informacion? GPor que sf 0 por que no?

84 HERHAMIENTAS DEL ANALISIS ESTRUCTURADO

10. l,Quien deberla ser el responsable de la creaclon de los modelos necesarios para describir los requerlrnientos de un sistema: de informacion?

11. l,Deberia esperarse que los usuaries crearan sus propios modelos? De ser asl, Len que circunstancias?

12.

son los tres prlncipales

de datos?

de un diagrama de

13. l,Cuales son los cuatro principales componentes de un tos?

de flujo de da-

14. N6tese que los procesos se representan por medio de circulos en un diaqrarna de flujo de datos y los terminadores se representan con rectanqulos. l,Cree que esto sea siqnificativo? i,Que pasaria si los procesos se

15.

Notese que la 4.2 muestra tres diterentes procesos, perc no indica cuantas cornputadoras puedan estar trabajando en el sistema. que esto sea

significativo? cam bios se requerirtan si el equipo encarqado del proyscto

decidiera el sistema con una sola con tres?

16.

Notese que Ia figura 4.2 musstra varies distintos diaqrarnas de entre procesos, perc no indica el medic tisico que se usara para transportal' 10 datos. que esto sea significativo? LQue puede ocurrir si los realizado res del sistema decider, transportar datos entre procesos utilizando lfneas de t tecornunicacion? LQue pasa si deciden transportarlos de un proceso a otro utlllzando cinta maqnetica?

17.

i8. debiera encarqarse de crear el dtccionano de datos?

ser responsable de rnantenerlo al dla?

19. La figura 4.3 rnuestra la definicion que da el diccionario de datos de un nombre,

cree que puedan siqnificar los 0, en dicha definicion?

deberia

20. {_.Cual es el propos ito de la especificacion de procesos?

21. i,Cuantas aspeclficaciones de proceso deberta esperar vet en una especifica cion complete de los requerimientos del usuario?

22. debe ria encarqarse de la especificacion de

actualizarla?

GQuien

23. N6tese que Ia especificacion de procesos rnostrada en el de este cap!

tuto se parece en algo a la codificacion de proqramas. GOue piensa de la idea de usar pseudocodlqo para escribir las especificaciones de nr{)('<''':::n piensa de la idea de utilizer un verdadero lenqua]e de proqramacton (por


como 10 han sugerido muchos, para las especificaciones de proqramas? l,Por que estarla bien 0 mal usar un verdadero lenqua]e de proqrama-

es el proposito de un

de entidad- relacion?

24.

25. 2,Cuales son los principales

tipos de objetos se muestran en la

4.5?

26.

27. relaciones se rnuestran en la figura 4.5?

28. el diagrama de entidad-relacion al lector alguna informacion sabre

las funciones que lleva a cabo el sistema?

29. proporciona el diagrama de de datos al lector alguna informacion acerca

de los de objetos 0 sobre las relaciones entre tipos de en el siste-

ma?

30. deberfan describirse los detalles de tipos de objetos y relaciones que

se muestran en un diagrama de entidad-relaclon?

31. es el proposito de un diaqrarna de transicion de estados?

32,

son los cornponentes de un

de transiclon de estados?

33. utiles los diagramas de translcion de estados para modelar sistemas com-

putacionatss por totes que sf 0 por que no?

34.

de sstructuras?

son los cornponentes qraflcos de un diagrama de estructuras?

36, de esperarse que el usuario sea capaz de leer y entender un diagrama de

estructuras? {_.Deberfa esperarse que el usuarlo sea capaz de crear uno?

37. Describa la relacion existente entre un diaqrarna de entidad-relacion y un dia-

grama de de datos.

38. alguna relacion entre un diaqrarna de tlu]o de datos y un diaqrama de

estructuras? De ser asi, {_.cual es?

Todo error humane es lrnpaciencia, una renunclaclon premature al metooo. una enqafiosa sujecion a un engaRo.

Franz Kafka, Cartas

En este capitulo se aprendera:

1. EI

un proyecto.

vida de un proyecto

Las caracterlsticas de! ciclo

Las diterencias entre proyectos clasicos y sernlestructurados.

cicio

vida

entre

y

conservadores.

Para ser un buen analista de sistemas se rsquiere mas que simples mientas de rnodelado: necesitamos metodos. En la protesion de desarrollo de sistemas, los terminos "metoda", "metodologfa", "ciclo de vida del proyecto" y "ciclo de vida del desarrollo de sistemas" se usan de manera casi indisttnta. En la parte III verernos rnetodos datallados de como otectuar el analisis de sistemas, en el contexte mas arnplio de un mstodo -conocido como ciclo de vida del proyecto ostructurado-. para llevar a cabo el desarrollo globa! de un sistema nuevo.

Antes de presenter el ciclo de vida del proyecto ostructurado, es importante examinar el ciclo de vida del proyecto clasico que se trata en muchos textos y se utiliza en muchas orqanlzaciones para el desarrollo de sistemas hoy en dla, sabre todo

86

EL CICLO DE VIDA DEL PROYECTO 87

para ldentiflcar sus Iimitacicnes y puntos debiles. Despues de este examen harernos una breve exposicion acerca del ciclo de vida del proyecto semiestructuredo: un ciclo de vida de proyecto que incluye algunos, pero no todos los elementos del desarrollo moderno de sistemas. En seguida se presentara el clclo de vida del proyecto estructurado, mostrando una vision global de las principales actividades y de como se [nterrelacionan. Por ultimo, se veran brevernente el ciclo de vida tormedor de prototipoe que popularizaron Bernard Boar, James Martin, y varies vendedores de len-

de proqramacion de cuarta qeneraclon.

Tarnbien exploraremos el concepto de desarrollo iteretivo 0 descendente. En particular, se presentaran los concsptos de desarrollo iterative radical y desarrollo ttarativo conservedor. Dependiendo de la naturaleza de un proyecto de desarrollo de sistemas, puede haber razones validas para adoptar un metodo en lugar de otro, e inclusc algunos proyectos pudieran requerir una cornbinacion de ambos.

5.1 et, CONCEPTO DE CiClO DE VIDA DE UN PROYECTO

Como pudiera esperarse, las orqanlzaciones pequerias de proceso de datos nsnden a ser relativarnente intorrnales: los proyectos de desarrollo de sistemas nacen de conversaciones entre el usuario y el administrador del proyecto (que puede ser a la vez el analista, el proqrarnador, el operario y el conserjs), y el proyecto procede desde el anal isis hasta el disefio e implantaclon sin mayor alboroto.

Sin embargo, en las orqanizaclones mas grandes, las cos as se Ilevan a cabo de rnanera mucho mas formal. La cornunicacion entre los usuaries, la administracion y el equipo del proyecto suele ser por escrlto, y todo mundo entiende que el proyecto pasara por diversas tases antes de cornpletarse. Aun asi, es sorprendente ver Ia gran diterencia entre las rnaneras en que dos adrninistradores atrontan sus respectivos proyectos, De heche, a rnenudo se deja a dlscrecion del administraoor determtnar las tases y actividades de su proyecto, y como se llevaran a cabo."

Recientemente, sin embargo, ha empezado a cambiar el entoque que se Ie da al desarrollo de sistemas. Cad a vez son mas las orqanlzaclones grandes y pequehas que estan adoptando un cicio de vida uniforme y unico para sus proyectos, Esto a veces se conoce como el plan del proyecto, ta metodologfa del desarrollo del sistema 0, sirnplemente, "la forma en la que hacemos las casas aqui". EI manual del cicio de vida del proyecto suele ser un libro tan volurninoso como el cornpendio de normas, que yace (usual mente sin ser lefdo) sobre el escritorio de todo analista y

1 Esto susna como si la anarquia prevaleciera en la mayoria de las organizaciones de proceso electronico de datos. Sin embargo, hay dos situaclones cornunes que lIevan a este enfoque individualista aun en la organizaci6n mas ejemplar: 1) La organizaci6n altamente descentralizada, donde cad a departamento liene su grupo de proceso electronico de datos con sus propias norm as locales y 2) el periodo de varios afios tras de que el ultimo "ciclo de vida oficial del proyecto" se juzgara inutil y se descartara.

88 EL CICLO DE VIDA DEL PROYECTO

EI tercer objstlvo de un ciclo de vida de proyecto normal se retiere a la neceside la admi~i~~raci6n de controlar un proyscto. En los proyectos triviales, el unlco punto de revlsl~n probable mente este al final del proyecto: Gse concluyo a tiempo

y dentro de los rnarqenes del presupussto acordado? (0, mas aun, Gse con-

siquiera?) G Y cumpli6 con los requisites del usuario? para proyectos

mas deberi~ ccntarss con varies puntos intermedios de revision, que permilleran deterrninar SI el proyscto se estuviera retrasando 0 si tueran necesarios recursoS adici~nales. Adernas, el usuario lntellqente tam bien necesitara puntos de

en diversas etapas del proyscto para que determinar si qutere conti-

nuar financiandoio.4


programador. Ese manual of race un procedirniento cornun a sequir para desarroltar un sistema cornputacicnal que puede orienta: a miembro de la orqaniza, cion de desarrollo de sistemas.

EI entoque puede ser casero 0, como alternativa, pudiera ser que la orqanizacion para el desarrollo de sistemas decida cornprar un paquete de adrninistracion de proyectos y ajustarlo a las necesidades de la compafifa.f Parece obvio que, aparts de darle ernpleo a las personas que craan los rnanuales de ciclo de vida de los proyectos (y a aquellos que escriben Iibros de texto al respecto), as conveniente la metodoloqia del proyecto. LDe que sirve entonces tener un ciclo de vida de un Existen tres objetivos principales:

1. Definir las actividades a llevarse a cabo en un proyacto de desarrollo de sistemas.

2. conqruencia entre la rnultitud de proyectos de desarrollo de siste-

mas en una misma orqanizacion.

Oidia todo esto, no queda mas que subrayar que el ciclo de vida del definitivamente no esta a cargo del proyecto, no Ie evitara al admirustrador del proIa diffcil labor de tornar decislones, sopesar alternativas, librar batallas pollti-

negeciar con usuaries recalcitrantes, anirnar a programadores deprirnidos, ni de las dernas tribulaciones relacionadas con los proyectos, EI adrninistrador

todavla tiene que eoministrer, en todo el sentido de Ia La uni-

ce que proporcionar el ciclo de vida del nrr.u""""

zer las actividades del adrrunistrador, aurnentando la los pertinentes en el memento adecuado.

3. de control y revision administrativos de las decisio-

nes sobre continuar 0 no con un

EI es de importancta en una

donde constanternente esta inqreeando personal nuevo a los

cion de proyectos. EI administrador novato no tornar en cuenta 0

la de rases clave del proyscto si se bas a solo en su intuicion. De

suceder que los proqrarnadores y analistas de ranqo no entiendan don-

de y como sus estuerzos individuales en el

les de una adecuada de todes las tases del

5.2 EL CICLO DE VIDA DEL PROYECTO ClASICO

de ciclo de vida de proyscto que se usa actual mente en la de

las difiere de al que estarernos dedicando la mayor de

nuestra atencion en la III. En la 5. i se muestra el ciclo de vida clasico 0

convencional. Cada atraviesa por algt:m tipo de analisis,

aunque no se haqa exactarnente como se muestra en el

vida de proyscto por en la de dlterir

que se muestra en la 5.1 en una 0 en todas las tormas

EI tarnbien es irnportante en una

los niveles mas altos de la adminlstracion pudiera ser bastants contuse

ta de cientos de oiterentes, cada uno de los cualss se lleva a cabo de dis-

tinta manera. si el A define la actividad de anal isis de

sistemas de dlterente forma que el proyscto 8 y 81 8 no una tase de diseno, dares cuenta 61 adrninistrador de segundo 0 tercer nivel de Qual pro-

yecto se esta y cual continua 10

HIPOTESIS 2-1' Los cornponentes de un sistema inca paces de asociarse, 0 que carecen de la experiencia que haya Jormado tales asociaciones, deben tuncionar de acuerdo con una proqramaclon rlgida 0 con reqlas de operacion altamente estandarlzadas. Se sigue que. Sl la rotacion de los componentes rebasa el ritmo con que se estan desarrollando las asociaciones necesarias para su operacion, aumenta la rigidez en ta programaci6n.

4 De heche. los procedimientos de la mayor parte de los prcysctos de proceso de datos son tales que exists solo un punto de control desde el cual el usuario tiene una rnanera obvia y limpia de arrepentlrse: al final de la fase de encuesta 0 del estudio de factibilidad. En teorla, sin embargo, el usuano debena tener la oportunidad de canceler un proyecto de procsso de datos al final de cualqUier rase sl piensa que esta desperdiciandc su dinero.

2 Existen varios de estes paquetes en el mercado, que cuestan entre $10,000 y $100,000 estadounidenses (0 su equivalente en rnoneda nacional), 0 mas. Algunos de los ejernplos mas nocidos son Spectrum (de Spectrum International Corp.), SOM-70 (de AGS Software), y Method/1 (de Arthur Andersen). No cornentare acerca de nlnqun paquete de administracion de proyectos en particular; s610 Ie sugiero que tenga en mente los conceptos presentados en este libro si su orqanizacion utiliza un paquete obtenido en el rnercado.

3 Miller en [Miller, 1978], sefiala que este es un len6meno comunmente observado: de heche, presenta como una "hipotesis" general aplicable a todos los sistemas en activo:

90 LA NATURAlEZA DE LOS SISTEMAS

requerimientos del usuario

~

Figura 5.1(8): 1:1 clcto de vida del proyeeto claslco


Las tases de exploracion y anal isis pudleran [untarse en una sola (sobre tad a en orqanizaclones en las cuales se considera tactlble desde el inicio cualquier cosa que quieta el usuario).

.. Puede no haber tass de estudio de hardware si S6 cree que cualquier sistema nuevo pudiera instalarse con las cornputadoras existentes sin causar mayor problema operacional.

..

.. las tases de disefio prelirninar y de disefio de detalles pudieran juntarse en una sola llamada simplemente de dlserio.

.. Diversas fases de prueba puedsn juntarse en una sola; de hecho, podrlan lncluirse con ta codiflcaclon.

De aqul que e1 ciclo de vida del proyecto en una orqanizacion sola puede tener cinco tases 0 siete 0 dace, perc sequir siendo todavla de tipo clasico.

es 10 que real mente caracteriza el cicio de vida de un proyecto como clasico? 88 distinquen des aspectos: una fuerte tendencia a la ascenderte del sistema y la insistencia en la proqrssion lineal y secuencial de una tase a la

5,2.1

EI uso de la lmptantaclon ascendente es una de las qrandes debilidades del cicio de vida de los proyectos clasicos. Como S8 podra ver en la

pera que los lleven a cabo rnodulares,

del y finalments las

tambien S8 conoce como el ciclo de vida de

1

No esta clare de donde

este

S8 tornado de las lineas de de las industrias rnanutactureras,

cion ascencente es buena para el de automoviles en I tpeto solo

fibre de fal!asj5 Desatortunada-

mente, rnuchas que desarrottan sistemas todavla sistemas

un gran nurnerc de dificultades

ascendsnte

serias:

5 fv1uchos creen que el enfoque ascendente pudiera provenir de la industria computacicnal del nercware porque muchos de los proqrarnadores administrador es de proqrarnacion de los aries 50 y GO

eran ingenieros electroniccs que hab.an que ver previamen;e con el desarrollo de hardware.

92 EL CIClO DE VIDA DEL PROYECTO

.. Nada esta heche hasta que todo este terminado. Per eso, sl el proyeclc

se atrasa y la techa limite cae precisamente en medic del proceso de del sistema, no habra nada que rnostrarle al usuario mas que una enorme pila de llstacos de proqrarnas, los cuales, vistos en su totalidad no le ofrecen nada de valor. '

.. Las tallas mas triviales se encusntran at comienzo del periodo de prueba y las mas graves at final. Esto es casi una tautoloqla: las pruebas modulares dejan al descubierto taltas rolativamente simples denim de los rnodu, los lndividuales. Las pruebas del sistema, por otra parte, descubssj errores grandes de interfaz entre subsistemas, La cusstlon es que ibs errores de interfaz no son 10 que el proqrarnador desea descubrir at final de un proyscto de desarrollo; tales tanas pusden obllqar a la recodifica. cion de un gran numero de modules, y pueden tener un impacto devasta. dor score el calendario, [usto en un momenta en el cual es probable que tcdo el rnundo este alga cansado y rnolesto tras haber trabajado duro duo rante tantos rneses.

.. La etimlnacion de tallas suele ser extrernadarnente diffcil durante las liltimas etapas de prueba del sistema, N6tese que se puede dlstlnquir entre ptuebes y eliminecion de teties. La eliminaclon de tallas es el arte de descubrir donee esta la Ialla (y subsecuenternente como arreglarla) despues de que el proceso de prueba ha determinado que la talla de heche exists. Cuando la talla se descubrs durante la fase de prusba del sistema en un proyecto ascendente, a menudo suele ser extremadarnents diHcil determinar cual modulo la contiens: pudiera tratarse de cualquiera de los cientos (0 miles) de modules que se han cornbinado por primera vez. Localizar una Ialla a menudo es como hallar una aguja en un pajar.

.. La necesidad de prueba con la cornputadora aumenta exponencialmente durante las eta pas finales de prueba. Para ser mas especfficos, el adrninistrador del proyecto a menudo descubre que necesita una gran cantidad de horas-rnaquina para probar el sistema; tal vez 12 horas de labor lninterrurnpida diaria. Dado que suele ser dlficll obtener tanto tiernpo de uso de la cornputadora.f el proyscto suele retrasarse mucho.

5.2.2 Progl'es!6n Secuenclal

La secunda debilidad mas irnportante del ciclo de vida de un proyecto clasico es su inslstencia en que las rases se sucedan secuencialrnente. Ouerer esto es una tendencia natu: al hurnana: desearnos decir que hemos terminedo la fase de anallsis

6 Estey convencido de que aqui se aplica otra mas de las leyes de Murphy: Entre mas grande y mas crltico sea el proyscto, mas probable es que la feeha limite coincide con el proeeso de fin de ano 0 alguna otra crisis orqantzacional que monopoliza todo elliempo de cornputadora disponible.

El CIClO DE VIDA DEL PROYECTO 93

REQUERIM!ENTOS DE SOFTWARE

DISENO DEL PROGRAMA

PRUEBAS

OPERACIONES

Figura 5.1 (b): E~ modele de eascada del desarroilo de sistemas


del sistema y que nunca tendrernos que volver a preocuparnos por ella. De heche rnucnas orqanizaciones tormalizan esto con un ritual conocido como "conqelar" I~ especificacion 0 conqelar el documento de disefio.

EI unico problema que trae consiqo este deseo de progreso ordenado es que no es naoa realista. En 10 particular, el enfoque secuencial no permits el tratamien. to de tenomenos reales como los relacionados con el personal, la politica de la campania, 0 la economia. Por ejernplo, la persona que hizo el trabajo, el analista 0 el diseriador, pudieron haber cometido un error y haber elaborado un producto con tallas. De heche, como hurnanos, rara vez atlnarnos a hacer bien un traba]o al primer intento, perc se suelen hacer repetidas rnejoras del trabajo impertecto. Tambien pudiera ser que la persona que revisa el traba]o 0, como case particular, 81 usuario que revisa el traba]o del analista del sistema pudiera haber cometido un error. 0 tal vez el encarqado de llevar a cabo la labor asociada con cada fase no haya tenido tlernpo suficiente para terminar, no quiera adrnitirlo, Esta es una rnanera amable de decir que, en la rnayorta de los proyectos complejos, la labor de analisis, de diseno y de prueba cuando decide que se ha aqotado el tiernpo, no cuando se quisiera,

Comunrnenta surgen otros problemas asociadas can el ciclo de vida del proyecto clasico 0 secuencial: durante los meses (0 aries) que toma desarrollar el sistema, el usuario pudiera cambiar de parecer respecto a 10 que debe hacer el sistema. Durante el que transcurre para desarrollar el sistema, pueden cambiar ciertos aspectos del ambients del usuario la la los (egubernamentales que afectan a las actividades del

Una caractertsnca adicional del cicio de vida del clasico es que S8

apoya en tecnicas anticuadas. Es tiende a el uso del analisis estructu-

rado la otra tecnica modena de desarrouo

de sistemas. Pero el heche de que el cicio de vida clasicc estas tacnrcas no

que el administrador del no utilizarlas. Dasatortunadarnen-

analistas y de sienten que el ciclo de vida

del es un mandata de la administraclon de alto

no dice nada al del usc de la entonces creen

que no estan

a utilizar rnetodos no clasicos.

5.3 si, CIClO DE ViDA SEMIESTRUCTURADO

Los comentarios de la seccion anterior hacer que parezca que la ma-

de las de proceso de datos todavfa viven en la Edad Media.

De heche, ssto es no todas las utilizan el ciclo de vida clast-

co, Desde fines de los aries 70 y ha crecido tendencia are-

eonocer al diserio la estructurada y la

descendents como del ciclo de vida del Este reconocimlento ha lle-

7 Hesurnirernos ostas tecnicas rnodernas de desarrollo en el capitulo 7,


vade al ciclo de vida del proyecto samlastructurado que se rnuestra en la figura 5.2. Se muestran dos detatles obvios no presentee en el entoque clasico:

t . La secuencia ascsndente de codiflcacion, la prueba de modutos y prueba del sistema se raemplazan por una Irnplantacion de arriba hacia aba]o, que es un entoque en el cual los modules de alto nivel se codifican y prueban primero. sequidos por los de ba]o nivel, mas dotallados. Tambien hay Iuertes indicios de que la proqrarnacion estructurada debe usarse como rnetodo para codificar el sistema.

2. EI dlseno clasico se raemplaza por el disefio sstructurado, que es un entoque de disefio formal de sistemas tratado en textos tales como [Yourdon y Constantine, 1989] v [Page-Jones, 1988],

Aparte de estas diferencias obvias, algunos detalles sutiles ace rca del ei-

clo de vida modificado. Por ejemplo, considers que la lmplantacion descendents siqnifica que se pond ran en ejecucion paralelamente de la codificaci6n y de las Esto difiere rnucho de las tases sscuenctales que vimos en el ciclo de vida

ctasico En 10 puede darse una retroeiimentecion entre 113 la

y la ellrninacion de las tallas. Cuando el proqrarnador alto nivel del sistema, a veces se Ie puede lIegar a olr exclarnar: idea de que la instruccion FRAMMIS de doble tuncionara de esa manera!". Desde se tener la seguridad de que en el futuro usara de manera rnuy

difefente esta instruccion.

el heche de que la descendente

pone en tsntacion a los del sistema (y a los anallstas si aun no han aban-

de no hablar con los usuaries sino basta de haberse

que el usuario senate errores 0

malentendidos en la 0 incluso expresar el deseo de cembisrte y, sl la conversacicn se da dlrsctamente entre el usuario y el que la mohacerse antes de que el adrninistrador del

descendents of race retroalirnenta-

de procsso de datos

y el de anal isis, aunque esto no S0 rnuestre y aunque ei usuario el administrador del nagar que este sucediendo.

a tratar ace rca del ciclo de vida semiestructuraco, tenernos

Como

que una gran que se raaliza el nombre de "disefio astructurado" as en realidad un osfuerzo manual para enrnendar arroneas.

E3tO se 5.3, que muestra los detailes del disefio estruc-

turado. conslste en los detalles del proceso 3 la

ra

5.3, la actividad 3. i al titulo de CODIFICAR LA ESPECIFICA-

la labor que han tenido que desde hace

CiON


~ ~~~~erimientos del

~no

(.\

ENCUESTA

documenlo de factibilidad

presupuesto, calendario

»>: /

requerimientos del /

usuario /

//

pedido del hardware

necesidades de rendimiento

especiflcacion narrativa y funcional del sistema

datos de configuracion de hardware

~ l ~

ESTRUCTURADO

\,pm'b"

diseiio por paquetes

Sistema

Figura 5.2: 1::1 clclo de vida del proyecto semiestn.lctLlrado

El CICLO DE ViDA DEL PROYECTO 97

te que S8 les darla una espsclficacion clasica; en consecuencia, su prirnera tarea, desde su punto de vista, es transtorrnar la especificacion en un paquete de diaqramas de de datos, de dlcclonarios de datos, de diaqrarnas de entidad relacion y de especificaciones de procesos.

ospeclttcacion narrativa funcional

datos de confiquracion

___ ----111>~

\ DIAGRAMA DE ESTRUCTURA

diagramas de flujo de datos, especificaciones de proceso, dlccionarto de datos

especiticacion de base de datos

plan de prueba

diagram a de

estructura

MODULO DE DISENO

/ diagrama de estructura

descripclon de /

__________ moo"!

3.4

DISENO DE PAQUETES

disefio en paquetes

Figura 5.3: Detalles de la actlvldad de disefio


Esta labor es mas dificil de 10 que se pudiera imaginar: historicamente se ha llevado a cabo en el vacfo. En general, los disefiadores ten fan poco contacto con el analista que escribla la especiticacion y definitivarnente [no ten fan contacto con el usuariot

Es obvio que esta situacion arnerita un carnbio. AI presenter el analisis estructurado, que es al sntoque moderno de anal isis de sistemas que se maneja en este Iibro, ademas de sxtenderse con la idea de la retroalimentaci6n entre una parte del proyscto y otra, se crea un tipo total mente distlnto de cielo de vida del proyecto. Este es el ciclo de vida estructurado del proyecto que discutirernos a continuacion.

SA El CIClO DE VIDA ESTRUCTURADO DEL PROYECTO

Ahora que ya hernos visto los ciclos de vida del proyeeto clasico y serniestructurado, estarnos listos para examinar el ciclo de vida estrueturado, que se muestra en la fiqura 5.4.

Exarninarernos brevemente las nueve actividades y los tres terrninadores del ciclo de vida del proyecto, como se muestra en la 5.4. Los terminadores son los usuaries, los adrninistradores y el personal de operaciones; como se recordara, discutirnos sus papeles en el capitulo 3. Se trata de individuos 0 grupos que properclonan las entradas a! equipo del y son los beneficiados finales del sistema. Elios interactuan con las nueve actividades que se rnuestran en la 5.4 .

En las sscciones se resume cada una de las actividades.

Esta actividad tarnbien se conoce como el estudio de factibilidad 0 como el es-

tudio inieial de Por 10

mas de su sistema se autornaticen.

cuando et usuarlo solicita que una 0

Los de la encuesta

ldentiticer a los ueuerios in/del dei sistema. Esto de entrevistas para deterrninar seran atectados desarrollo de un

y creer un de ectiviosa'

la conduccion de una serie en (0 el

8 l.as teen.cas de encuesta se oiscuten en el Apendice E.

9 EI diagrams de contexte es parte del modelo ambientai que se discutira oon mayor detalle en el capitulo 8. Su principal proposito, como se indica aqui, es definir cuanto abarca el sistema, asi como los diversos terminacores (personas, unidades orqaruzacionales, otros sistemas de compute, etc.) con los que el sistema interactuara.

EL CICLO DE ViDA DEL PROYECTO 99

kientiticer las aetictencies actuates en et emoiente del usuerio. Esto en general cornprsndera la lista de tunciones que hacen talta 0 que se estan llevando a cabo insatlstactorlarnenta en el sistema actual. Por ejemplo, esto pudiera incluir declaraciones como las siquientes:

ADMINISTRACION

reporte de costebeneficio

conjunto de prusbas de control de calidad

restricciones

7.

DESCRIPCION DE PROCEDIMIENTOS

base de datos ccnvertida

\ manual ~ del uSUariO\

sistema integrado

~

INSTALACION

sistema aceptado

I sistema l instalado

Figura 5.4: EI clclo de vida del provecto estructurado

100 EL CICLO DE VIDA DEL PROVECTO

*

EI hardware del sistema actual no es confiable y el vendedor se acaba de declarar en quiebra.

EI software del sistema actual no S6 puede rnantener, y no podernos ya contratar programadores de rnantenimiento dispuestos a darla mantenlrmento en el lenquaje que se utilize para desarrollarlo.

*

*

EI tiernpo de respussta del sistema teletonico de pedidos actual es tan malo que rnuchos clientes cuelqan trustrados antes de hacer su pedido.

*

EI sistema actual no es capaz de producir los intorrnes requeridos par la rnodificaclon a los impuestos dscretada el ano anterior.

EI sistema actual no es capaz de recibir los intormes sobre limites de

credito del de y no

formes de de volurnen de que FAr" '"''"'''

menta de rnercadotecnia.

*

..

Estebiecer metes y objetivos para un sistema nuevo. Esto puede ser tambien una simple lista narrativa que las tunclones existentes que deben reimplantarss, las nuevas que necesltan afiadirse y los criterios de del nuevo sistema.

..

Determiner si es tectibte eutometizer e/ sistema y de ser esce-

nerios Esto estimaclones bastante rudi-

mentarias y del costo y el necesanos construlr

un sistema nuevo y los beneficios que se derivaran de tambien in-

volucrara cos 0 mas sscenarios el escenario can una com-

el de a estas

alturas la adrninistracion y los usuaries usual mente

cion y el analista tendra rnucha suerts ai deterrni-

los recursos y los eostos con un error manor del 50% en

ssta del

..

el esquema que se users para sf resto de!

esquema incluira toda la informacion que se lista

de identiticar al adrninistrador del

describir los detalles del ciclo de vida que

Tambien pudiera el resto del proyecto.

En la encuesta ocupa s610 del 5 al i 0 par ciento del y los re-

curses de todo el y para los proysctos pequenos y sencillos pudiera ni si-

quieta ser una actividad formal. Sin embargo, aun cuando no consurna rnucho del

() los calculos de costo-beneflcto se discutiran en el apendice C.

Este


tiernpo Y de los rscursos del proyecto, es una actividad verdaderarnente al final de la encuesta, la adrninlstracion pudiera decidir cancelar el proyscto si no parece atractivo desde el punto de vista de costo-bensficio.

Como usted 0 no estar involucrado en ia encuesta: pudiera ser

que antes de que siquiera se haya emerado del proyecto, el usuario y los niveles de la adrninlstraclon ya la hayan heche. Sin embargo, en proyectos y cornplejos, la encuesta requiere traba]o tan detailado que a menudo el solicitara la colaboracion del analista 10 mas pronto posible.

No discutirernos la encuesta con mayor detalle en este libro. Si Ilega a tener que ver con esta actividad, encontrara de utiltdad los apencnces E y C. Para detalles

adicionales, consults [Dickinson, 1981], [Gore y y

5.4,2 Actlvid@d 2: EI anallsls de sistemas

EI proposlto de ta actividad de analisis es transtorrnar sus dos entra-

das -0 insumos 0 tactores- las politicas del usuario y el esquema del

en una estructurada. Esto implica modelar el ambients del

usuario con diaqramas de de diagramas de entidad- diaqramas

de transicion de estado y dernas herrarniantas que se 4 .

Estas herramisntas se tratan con detalle en la II.

EI oroceso paso a paso del anal isis de sistemas (es decir, las subactividades

de 10. actividad de anal isis de la se discute en la n Como verernos,

el desarrollo de un moaeio embientei 18) y el de-

sarrollo de un modele de se discute en los t 9 Y

Estes dos modelos se combinan para tormar el modele esenciei

el que una formal de 10 que el

debe de 10. naturaleza de la

Adernas del modelo del sistema que del

se prepara un de y calculos de costas y benefi-

cios mas ,",c~,~i,'~~ y detallados 0.1 final de ia actividad de anal isis. Esto se discute

con mas detalle en el C.

como analista del sistema, en esto pasara la mayor parte de su nada mas que se necesite decir ace rca de la actividad de anal isis en este memento, ya que ese es el terna que trata todo el resto del libro.

5.4.3 Actividad 3: el dlseno

La actividad de disefio se dedica a asiqnar de la especiftcacion

conocida como modele esencial) a procssadores adecuados (sean rnaquiy a labores apropiadas (0 tareas, particiones, etc.) dentro de cad a orocesador. Dentro de cada labor, la actividad de diseno se dedica a la creacion de


una [erarqula apropiada de modules de programas y de interfases entre sllos para irnplantar la especificacion creada en la actividad 2. Ademas, la actividad de disefio se ocupa de la transtormacton de rnodelos de datos de entidad-relacion en un diseno de base de datos; vease [Inmon, 1988] para mas detalles.

Parte de esta actividad Ie interesara como anallsta: el desarrollo de alga conecido como el modeio de impientecion del usuerio. Este modele describe los asuntos relacionados can la implantaclon que Ie importan al usuario al grada de que no sa los quiere confiar a los disefiadores y programadores. Los asuntos prlncipales que sue len preocupar al usuario son aquellos relacionados con la especificacion de la trontera hurnano-maquina y la especitlcacion de la intertaz hombre-rnaqulna. Esa frontera separa las partes del modele esencial que llevara a cabo una persona (como actividad manual), de las partes que se implantaran en una 0 mas cornputadoras, De manera similar, la intertaz hombre-rnaquina as una descripcion del formato y de la secuencia de entradas que los usuaries proporcionan a la computadora (par ejernplo, el disefio de pantatlas y el dialoqo en linea entre el usuario y la computadora), adernas del torrnato y la secuencia de salidas -0 productos- que la computadora proporciona at usuario, EI modele de implantacion del usuario se describe en el ca-

21.

En el capitulo 22 se puede encontrar una introduccion al proceso de disefio de sistemas. Se puede encontrar material adicional en [Yourdon y Constantine, 1989], [Page-Jones, 1988], [Jackson, i 975], Y otros.

5.4.4

AcUvidad 4: lmplantaclon

Esta actividad incluye la codificacion y la inteqracion de modules en un esqueleto proqreslvamsnte mas complete del sistema final. Por eso, la actividad 4 incluye tanto proqramacton estructurada como implantacion descendente.

Como podra irnaqinar, el analista tipicamente no se vera tnvolucrado en esta actividad, aunque hay algunos proyectos (y orqanizaciones) donde 81 analisis, el disefio y la implantacion de sistemas los hace la misrna persona. Este terna se discute mas a tendo en el capitulo 23.

5.4.5 Actividad 5: generacion de pruebas de aceptaclon

La especificacion estructurada debe contener toda la informacion necesaria para definir un sistema que sea aceptable desde el punto de vista del usuario. Por eso, una vez generada la especiticacion, puede cornenzar la activldad de producir un conjunto de cases de prueba de aceptacicn desde la especiflcacion estructurada,

Dado que el desarrollo de las pruebas de aceptacion puede sucsder al rnismo tiempo que las actividades de disefio e implantaclon, pudiera ser que al analista Ie sea asiqnada esta labor al termino del desarrollo del modelo esencial en la actividad 2. En el capitulo 23 se discute con mas detalle el proceso de prueba.

EL CICLO DE VIDA DEL PROYECTO ,03

6: garantia de catldad

La garantia de calidad tambien se conoce como la prueba final 0 la prueba de Esta actlvidad requiere como antradas los datos de la prueba de aceptaci6n generada en la actividad 5 Y el sistema integrado producido en la activldad 4.

Ei analista pudlera estar lnvotucrado con la activid~? de qarantla de ~alidad, nor 10 regular no 10 ssta. Pueden tornar la responsabll1dad un~ 0 mas n:lembros de la organizacion usuaria, 0 pudiera usvarta a cabo un grupo mdependl~nte d~ rueba 0 un departamento de control de calidad. Consecuentemente, no se discutira

~on mas detalle la funcion de qarantla de calidad.

Notese, por cierto, que algunas personas Ie llarnan a esta actividad "control ?e calidad" en lugar de "garantfa de caudad". Sin importar la terrninoloqia, se ~eceslta una actividad que veriiique que el sistema tenga un nivel apropiado de ?alldad; Ie Memos lIamado qarantia de calidad en este libro. Notese tarnbien que .e~ importante lIevar a cabo actividades de garantla de caudad en cada una de .Ias actlvld~des ante(iores para asequrar que se hayan rsalizado can un nive~ ~proplado d~.C:lid~d. _Por eso, S8 8speraria que esto se haga durante toda la activldad de anali~I:';, ?Iseno y programacion para asequrar que el analista este. de_sarrollando es.peclflcaclones de alta que el disefiador este producienoo disenos de ~lta cali dad y q,ue el pr~gramador este escribiendo codiqos de alta caudad. La actividad d~ garantl~ de calldad que se men cion a aqui es simplemente la prueba fmal de la call dad del sistema.

Actividad 7: descripcion del procedlrnlento

5,4.7

A 10 de todo este libro nos preocuparnos por el desarrollo de un sisten;a

no solo de 10. porclon automatizada, sino tarnbien de la ,que llevaran

a cabo las personas. Por ello, una de las actividades importantes a raalizar es la generacion de una descnpcion formal de las partes del sistema que se haran en forma

manual. 10 mismo que la descripcion de como interactuaran los usuarios con la automatizada del nuevo sistema. EI rasultado de la actividad 7 es un manual para el

usuario.

Como podra imaqinar, esta tarnbien es una actividad en la que pudiera vers,e involucrado como analista. Aunque no se diseutira mas a fondo en este libra, podria consultar ubros ace rca de rsdaccion tacnica para obtener mayor informacion sobre la escritura de manuales para el usuario.

5.4.8 Actividad 8: conversion de bases de datos

En proyectos, la conversion de bases de datos involucraba mas traba-

jo 1\1 mas planeacion estrategica) que el desarrollo de programas de computadora pa~~ ei nuevo sistema. En otros casos, pudiera no haber existido una base ~e datos que convertir. En el caso general, esta actividad requiere como entrada la case de datos actual del usuario, al que la especificacion del diseno producida par me-

dia de la activldad 3.


Sequn sea de la naturaleza del proyecto, el analista podrla tener que ver COl) la actividad de conversion de la base de datos. Sin embargo no discutirernos esta actividad con mayor detalle en este libro.

5.4.9 Actividad 9: lnstalaclen

La activldad final, desde lueqo, es la instalacion: sus entradas son el manual del usuario productdo en la actividad 7, la base de datos convertida que se creo can actividad 8 y el sistema aceptado producido par la actividad 6. En algunos cases, sin embargo, la Instalacion pudlera siqnificar simplernente un cambia de la nochea la manana al nuevo sistema, sin mayor alboroto: en otros cases, la instatacion pudls. ra ser un proceso gradual, en el que un grupo tras otro de usuaries van reciblende manualss y entrenarniento y comenzando a usar el nuevo sistema.

5.4.HI

Resumen de! etclo de vida de! prcyecto estructurado

Es importante ver la figura 5.4 como 10 que es: un diagrama de ttuio de dato$.

No es un diagrama de flu]o; nada lrnplica que toda la actividad N debe concluir antes de cornenzar la actlvidad N + 1. Por el contrario, ta red de flujos de datos que COnectan las actividades hace ver con claridad que pudieran estarse llevando a cabo diversas actividades paralelamente. Debido a este aspecto no secuencial, la palabra ectiviaed en el clclo de vida del proyscto estructurado en lugar de que es mas convencionat. EI termino tase tradlclonatmente se refiere a un do particular en un proyecto en el cual se estaba dssarrollando una, y solo una, actlvidad,

Hay otra cosa que debe recalcarse acerca del uso de un diaqrarna de flujo de

datos para describir el ciclo de vida del proyecto: un diaqrarna de de datos cia-

sico, como el que se rnuestra en la 5.4, no rnuestra en forma la retro-

alirnentacion, ni el control.!" Practlcamente todas las actividades de la figura 5.4 pueden y suelen producir mtorrnacton que puede llevar a rnodificaciones adecuadas de una 0 mas de las activldades precedentes. De aqui que la actividad de dlsefio

producir informacion que acaso cambie alqunas de las dacisiones de coste-

beneficio en la activldad de de heche, el conoclrniento que se obtiene a par-

tir de la aetividad de disefic pudiera incluso llevar a revisar decisiones ace rca de la factlbilidad basica del proyscto.

Mas aun, en cases extremes, ciertos eventos que pudieran darse en cualquier actividad pueden causar que todo el proyecto terrnine repentinamente. Las entradas de la administracion se rnuestran solo para la actividad de analisis pues esta es la uruca que datos de la admlnistracion: sin embargo, se supone, que la adrnlnistraclon ejerce control sobre todas las actividades.

11 En realidad, hay rnaneras de rnostrar la retroalimentaci6n y el control en los diagramas de flujo de datos, como se vera en el capitulo 9. Las notaclones adicionales (para tlujos de control y de procesos de control) normalmente se utilizan para modelar sistemas de liempo real y hemos evitado su uso en este modelo del "sistema para construir sistemas".


En resumen, la fFigura 5.4 solo sonata la 0 las entradas requ~ridas per c~d~ . 'dad Y la ° las salidas 0 productos que se generan. La secuencia de las activi-

activi , . . ddt

d solo puede suponerse en la medica en que la presencia 0 ausencia e a as

da es . d . 'd d

haga posible cornenzar una dstarmina a activt a .

IMPlANTACION RADICAL CONTRA IMPlANTAC!ON DESCENDENTECONSERVADORA

5.5

En 12 seccion anterior sefiale que el ciclo de vida del proyecto ostructurado que mas de una actlvidad se Ileve a cabo a la vez. Pongamoslo ~e otra rnanera: en la sltuaclon mas extrema, toaes las aotlvidades de! Cicio de vld~ .estrucpudieran estarse reauzando slmultaneamente. En el otro. extreme, el admtntstrador

del pudiera decidir adoptar 131 enfoque se~ue~clal, que terrrunar

completamente una actlvidad antes de smprender la siqutente.

Es conveniente tener terminologfa para discutir estes sxtremos as! como los medios entre ellos, EI sntoque radical del ciclo de vida del proyscto astruces aquel en el que las actlvldades 1 a 9 se llevan a cabo paralelamente desde el del proyecto: la codrtlcacion se inicia el primer dia del proyecto, y la encuesta Y el anal isis contlnuan hasta el ultimo. En carnbic, en el co~servador del cicto de vida del proyecto astructurado, la actividad N cornpleta 5e termma antes de comenzar con la actividad N + .

Obviamente, nlnqun aomlnlstrador en sus cabales adoptarfa de e~-

tos dos extremes. La clave para reconocer esto consiste en que los extremes radical y conservador definidos anteriormente s?n los ~u~t~s eX,tremos de un.a gama de esto se ilustra en la fiqura 5.5. Existe un infinite nurnero de opcrones en.tre los extremes radical y conservador. Un adrninistrador de proysctop d_;cldlr tarminar el 75% de la actividad de oncuesta, sequido por la terrrunacron del 75 Yo del

analisis del sistema, y lueqo del 75% del disefio para poder un esqueleto razonable de un sistema cuyos detalles pudieran postariormente refinarse al pasar por

vez por el clclo de vida entero de! proyecto. 0 bien, el ,administra~or pudiera dscidir tsrrninar todas las actividades de ancuasta y de anal ISIS, sequido por ta termlnacion del 50% del diserio y el 50% de la tmptantaclon. Las posibilidades son

mtermlnables.

ULTRA RADICAL

MODERADAMENTE RADICAL

MODERADAMENTE CONSERVADOR

ULTRA CONSERVADOR

Figura 5.5: Elecciones de implantaci6n radical y conservadora


LComo decide un administrador de proyecto si adoptar un entoque radical Q conservador? Basicamente, no hay respuesta: la decision suele basarse en los 5i. quientes facto res:

LQue tan voluble es el usuario?

l,Bajo que presion labora el equipo del proyecto para producir resultados tangibles e lnmediatos?

{Bajo que presion labora el admlnistrador del proyecto para producir un presupuesto, proqrama, y estimacion de personas y otros recursos?

son los peligros de cometer un error tecnico importante?

Como podra apreciarse, ninquna de estas prequntas puede responderse claramente. Por ejemplo, uno no pusde preguntarle at usuario, en una conversaclon informal, "LQue tan voluble andas . Por otro lade, el adrninistrador del proyecto debiera poder [uzqar la sltuaclon basandose en la observacion, sobre todo si es un vetsrano que ha lidiado antertormsnte con rnuchos usuaries y adrninistradores de alto nivel,

Si el adrninistrador del proyecto juzga que esta tratando con un usuario volUble cuya personalidad es tal que ret rasa la torna de decisiones hasta estar seguro de que el sistema va a tuncionar, entonces probablernente optarta por un entoqus mas radical. . Lo mismo si trata con un usuario sin experlencia, a quien Ie hayan creado pecos sistemas. 2,Por pasar aries desarrollando un perfecto de especlficaclones tan s610 para descubrir que el usuario no cornprendto su significado?

Por otro lade, si el adrninlstrador trata con un usuario veterano que esta absolutamente seguro de 10 que quiere, y si este ultimo trabaja en un area estable y con poca probabilidad de cambiar radicalmente de un mes a otro, entoncas puede darss el lujc de adoptar un entoque mas conservador. Desde luego, hay rnuchas situaciones intermedia~: el usuario puede estar sequro de eiqunss de las funciones de neqoCIOS que debe ran llevarse a cabo, perc al rnismo tiernpo no estar secure del tipo de informes adrninistrativos que desea que el sistema le proporcione. 0 bien, si el usuario esta familiarizado can sistemas cornputacionales per totes (batch), peoria no

estar seguro del impacto que tener en la ernpresa un sistema en llnea,

Adernas de la volubilidad, existe un segundo factor que se debe considerar: la presion a la que se esta sornetido para producir resultados tangibles e mmedlatos

debido a las polfticas u otras presiones externas, el equipo que realiza el proyec· to debe conclUirlo forzosamente para una fecha determinada, entonces se requiere un enfoque un tanto radical. EI administrador del proyecto aun carre el riesgo de que el sistema solo este completo en un 90 por ciento para la fecha limite, perc por 10 menos sera un operante completo en un 90 p~r ciento que puede moS' trarse y tal vez incluso ponerse a producir. Eso general mente es mejor que haber


terminado todo el anal isis de sistemas, todo el disefio y tad a la codificacion, pero nada de las pruebas,

Desde todos los proyectos Ilegan a verse aprerniados a lIegar a resulta-

dos tangibles; la cuestion es el del apremio. Es un asunto que puede ser alqo dinamico: un proyecto que comienza holgadamente con un proqrama comedo puede de repente volverse de alta prioridad y la techa limite adelantarse seis messs 0 un ano. Una de las ventajas de hacer el analisis, diseno, codificacion e implantacion del sistema en forma descendents es que se pusde suspender una actividad en cualquier momento y dejar los detalles rsstantes para conslderacion posterior; mientras tanto, el analisis de alto nivel que 5e haya terminado puede usarse para cornenzar el diseno de alto nivel, y €lsi para los dernas cas os.

Otro factor mas en la adrnirustraclon de proyectos es el requisito siernpre presente en la mayorfa de las orqanlzaclones qrandes de que S6 tlenen que producir programas, estirnaciones, presupuestos, etc. En algunas orqanizaciones, esto suele hacerse de manera bastante informal, normalmente porque los proysctos son relativamente pequenos y porque la adrnfnistracion siente que cualquier error en la estimaci6n tendra poco irnpacto en la orqanlzacion global. En tales casos se puede adoptar un entoque radical, aunque cualquier intento de hacer una estlmacion se tandra que reducir €II nivel de conjsturas viscerales, En carnbio, la mayona de los proyectos requieren estirnaciones relativarnente detalladas de necesidades de personal, recursos cornputacionales, etc., y esto solo se puede realizer tras un sondeo, anal isis y diserio bastante detallados. En otras palabras, entre mas detalladas y prectsas tenqan que ser las estimaciones, mas probable es que el proyecto un en-

conservador.

Finalrnente, el adrninistrador del proyecto debe considerar el peliqro de cometer un error tecnico importante. Por ejemplo, suponga que toda su experlencia pasada en desarrollo de proyectos ha sido con una pequefia cornputadora de procesamiento por totes IBM/36. Ahara, de repente, esta a cargo de desarrollar un sistema de multiprocesamlento en linea para administracion de bases de datos distribuidas, en tiernpo real, que procesara 2 rnillones de transacciones diarias desde 5000 terrninales distrlbuldas en todo el rnundo, En tal situacion, uno de los peligros del enf'oque radical es descubrir alqun error importante en el disefio tras haber realizado una buena parte del esqueleto de alto nivel del sistema.

Pudiera descubrir, por ejemplo, que para que su gran sistema tunclons se requlers que un modulo de nivel lleve a cabo su tuncion en 19 microsegundos, perc sus programadores de repente Ie informan que es imposible codificar un modulo can tanta eficiencia, ni en COBOL, ni en C, ni siquiera (iufl) en lenguaje ensamblador. Por 10 tanto, debe estar alerta al hecho de que seguir un enfoque radical rsquiere que sus analistas y disenadores escojan un "tope maximo" para su sistema en etapa relativamente temprana, y que siempre existe el peligro de descubrir, ya cerca del final, que escogieron un maximo equivocado.


Sin embargo, considere otra situacion: 191 administrador del proyecto ha ~v,_'u,.,,',',',

do construir un sistema electronico de proceso de datos con nuevo, s

operative nuevo, sistema de adrninistraclon de bases de datos nuevo (producido alquien que no sea 191 vendedor), y un paquete de telecomunicaciones nuevo ( cido por otra ernpresa mas). Todos los proveedorss tienen rnanuales brillantes e presionantes que describen sus productos, perc nunca han probado 10. intertaz

sus productos de hardware y software. i,Quien sabe si siquiera fun

naran juntos? l.Quien sabe si las tunciones prornetidas por un proveedor q anuladas por los recursos del sistema que utiliza 191 otro? Clertamente, en un

como el administrador del pudiera eleqir un para

10. version 0 prlmaria del sistema pueda utilizarse para explorar los

bles problemas de interaccion e interfaz entre los cornponentes de los diter

Si el administrador del esta a cargo de un tipo familiar de sistema co-

mo, per sjemplo, su nonaqesirno noveno sistema de norninas, probablernente tenga bastante idea de que tan realistas sean sus rnetas. Es poslble que recuerde, de proyecto que tipo de modules necesitara a nivel detallado, y probablerns recuerde con claridad como se vela 10. estructura de alto nivel del sistema. En tal so, pudlera estar dispuesto a correr el riesqo de cornetsr un error dados los d beneficios que puede traerle un entoque radical.

En resumen, el entoque radical es el mas adecuado para intentos apenas distrazados de investiqacton y desarrollo, en los que nadia esta muy sequro de que as 10 que se supone que debe hacer el sistema final. Y es bueno para los cas os en los que para determinada techa alqo tiene que estar yo. tunclonando, y en situaciones en las que ta percepcion del usuario a 10 que desea que el sistema haqa este sujeta a posibles cam bios. EI enfoque conservador, por otro sue Ie usarse sn proyectos mas qrandes, en los que se invierten cantidades enorrnes de dinero y para los cuales se requiere un anal isis y dissrio rnuy detallados para evitar desastres subsecuentes, Sin embargo, cada proyecto €IS diterenta y rsquiere de su propia combinacion de implantacion descandente consorvadora y radical. Para tratar la naturaleza individual de cad a proyecto, el administrador debe estar dispuesto a modificar su entoque en mitad del camino si es nscesarlo.

5.6 EL CICLO DE VIDA DE PflOTOTIPOS

Se ha vuelto popular en los ultirnos anos una variaclon del enfoque descendente antes dlscutido. En se le conoce como el entoque de ptototipos y 10 populanzaron Bernard Boar, James Martin y otros. Como 10 describe Boar [Boar, 1984]:

Una alternativa de enfoque para la definicion de los requerimientos consists en capturer un conjunto inicial de necesidades e imptantarlas rapidarnente con la intencion declarada de expandirlas y refinarlas iterativarnents al ir aumentando la comprension que del sistema tienen el usuarlo y quien 10 desarrolla. La definicion del sistema se

El CICLO DE VIDA DEL PROYECTO 109

Un

de pantallas

Un generador de rsportes no Un lenguaje de

Un

de consultas no qulado per de bases de datos

_ . d sta a sxamlnar rnodelos abstractos

1::1 usuano no pus €I 0 no e

en tales como diagramas de Ilujo de datos.

EI usuarlo no puede 0 no esta dlspuesto a articular "pre-especificar")

imlentos de ninquna forma y s610 se pueden determmar sus re-

sus requen ror 0 como

querimientos mediante un proceso de tanteo, 0 snsayo Y er . ,

i 10 EL CICLO DE VIDA DEL PROYECTO

~,o die: mi coleqa Bob Spurgeon, es Ia situacion en la que el usuano dice'

No se que es 10 que quiero, perc 10 reconocere cuando 10 vea". .

LlNEAMIENTOS .

NO

IDENTIFICAR NECESIDADES BASICAS

DESARROLLAR UN MODELO FUNCIONAL

DEMOSTRACION

DENTRO DEL

CONTEXTO,OB-~ __

TENER REFINA-

MIENTOS, ETC.

NO

(_SE NECESITAN COMPONENTES E DETALLE?

HACER CORRECClONES

COMPONENTES DE I SI

->""Ii:-----{ LA ESPECIFICACION ..q..I

Figura 5,6,' EI clclo de vide per prctettpos

ENFOQUE DE ESPECIFICACION RIGUROSA

;

II AFlN~R EL I

NO PROTOTIPO Y EL DOCU·

! MENTO

!

1

EL CICLO DE VIDA DEL PROYECTO 11 i

.. Se tiene la intencion de que el sistema sea en linea y con operacion total por la pantalla, en contraposiclon con los sistemas de edicion, actuahzacion y reportes operados por totes. (Casi tooas las herramtentas de software de prototlpos apuntan al enfoque orientado a terminates en linea y manejadas per bases de datos; existen pocas herramientas de software en et rnarcado para ayudar a la crsaclcn de prototipos de sistemas de procesarniento par lotes.)

.. EI sistema no requiere la especificacion de qrandes cantidades de detalies algoritmicos, ni de muchas especlticaclones de procesos para desertbir los alqcritrnos con los cuales se obtienen los resultados. Par ella, los sistemas de apoyo a decisiones, de recuparacion ad hoc (a proposlto) y de adminlstracion de reqistros son buenos candidates para el prototipo, Los buenos candidates sue len ser sistemas en los cuales el usuario se preocupa mas por el formate y distribuclon de los datos de entrada y salida en la pantalla, y pOI' los rnensajes de error, que por los computes que realiza el sistema para lograrlo.

Es irnportante notar que el ciclo de vida de prototipos que se muestra en la fiqura 5.6 concluye con una tase de disefio de un ciclo de vida estructurado "tradicionat" como los que describe este libro. Espectticarnente, esto siqnitica que no S8 tietie fa intencion de que el prototipo haga las veces de un sistema operacionai: la tntsncion es tan solo que modele los requerimientos del usuario.

EI enfoque de prototipos ciertarnente ilene su merlto en muchas situaciones.

En algunos cases, el admlnistrador del proyecto tal vez quieta utilizar este entoque como alternativa at de anal isis astructurado que S8 presenta en este en otros cases, pudiera desear utitizarlo en coniunto con la creacion de modelos en papel, como los diaqramas de flu]o de datos. Tenga en mente 10 siquiente:

® EI entoque descendents descrito en la seccion anterior es otra rnanera de hacer un prototipo, perc en vez de usar nerramientas que se pueden obtener en el rnercado, como generadores de pantallas y lenquajes de cuarta qeneracion, el squipo que realiza el proyecto utiliza el sistema mismo como su propio prototipo, Es decir, las dlversas versiones de un esqueleto del sistema proveen un modelo operative con el cuat el usuario puede interactuar y darse as! una idea mas realista de las tunciones del sistema que la que se pudiera tormar a partir de un modele en

.. EI cicio de vida de prototipos, como se dsscribio anteriormente, involucra el desarrollo de un modele tunctonal, que luego se descarta y se reernplaza con un sistema de produccion. Existe un peliqro considerable de que el usuario 0 el equipo que desarrolla el sistema traten de convertir al prototipo rnisrno en un sistema de produccion. Esto suele resultar un desastre, pues el prototipo no puede trabajar eficienternente con grandes volumenes de transacciones, y porque carece de detalles operacionales



tales como de errores, auditorias, caracterfstlcas de respsj,

documentacion para el usuario y procedimientos de convs-,

sion.

Si de heche se descarta el y se reernplaza con el sistema de producclon, exists el pellqro real de que pudiera concluirse el proyecto sin

un raqistro permanents de los raquertmlentos del usuario. Esto ptabablernente dificulte cad a vez mas el rnantenimiento con el paso del tiern, po (por diez aries despuss de la construccion del sistema, sera dificii que los proqrarnadores de rnanterumtento incorporen alqun carnblo

pUGS a los usuaries de "sequnda qeneraclon" que estan

aotuatmsnte con e\ recordara 10 que se suponla en

que debra EI ciclo de vida que se presenta en este li-

bra se oasa en la idea de que los rnodelos en desarrollados durants

la actividad de analisis no solo seran una entrada para la actividad de Jisene, sino que tarnbien S8 conservaran (y se modificaran vaya siendo durante el rnantenirniento. De heche, los modelos pudieran sobrevivir mas alia del sistema en 81 cual se y pudieran servir como especiticacion para el sistema de

5.7 RESUMEN

EI principal proposito de este capitulo fue proporcionar una vision global de los ciclos de vida de los en general. Si examina el ciclo de vida formal de proyectos en cualqulsr orqaruzacton de desarrollo de sistemas, deberla poder distin-

sl se trata de uno elasico, semlestructurado, 0 de

Si su proyecto solo permits una actividad a la vez, la discusion sabre irnplantacion descendents radical y conservadora de la Seccion 5.6 puede haberlo perturbsdo. Este fue mi prcposito, y 81 objetivo de esa seecion tueehacerle pensar acerca de la posibilided de traslapar alqunas de las principales actividades en el proyecto de desarrollo de un sistema. Obviamente, es mas dificil adrninistrar un pro-

en el cual diversas actividades se llevan a cabo en pero, hasta cierto

eso sucede en todo proyecto. Aun 51 el adrninistrador decide que su gente se concentrara en una actividad a la vez, de todos modes habra varias subactividades que se ilevaran a cabo en paralelo. Multiples analistas de sistemas estaran entrevislando slmultaneamente a multiples usuarios: diversas piezas del producto final del anatisis se sncontraran en diversas etapas de progreso a 10 de toda la tase de anahsls. Una labor del admlnistrador es tener el st.tlciente control sobre dichas subactividades como para asequrar que se coordinen Y en casi cualquier proyecto de proceso electronico de datos, este tipo de actividad paralela se da tambien a alto nlvel: es dscir, a pesar de 10 que pueda haber recornendado el cic!o de vida formal del proyecto de una orpanlzaclon dada, la realidad es que muchas de las principales actividades del proyscto sf se traslapan basta cierto No obstante, si el adrnlnlstrador decide inslstir en una progresion de activldades estrictamente secuencial, aun funcionara el ciclo de vida presentado por este libra.

Para obtener rnayorss detalles acerc~, de olclos de vida de 1981] y [Yourdon, 1988]. ramblen cubren este de software y de llbros de

2.

Yourdon y Larry L. Constantine, Struct~.re~ Applications in Software Engineering, 2a. edlCtOn, Press, 1988.

The Practical Guide to Press,

2'" edi-

1984,

Mass.:

3. 4. 5,

James Grier

Systems, Nueva York: McGraw- Hill, 978. Structured Systems. Nueva York:

Brian Press, 1981,

vourdon, the Systems Lite

N.J.: Prentice-Hall, 1988.

2" edicion,

0,

7,

Systems. Nueva York: McGraw-

1978.

James Grier Miller, Jackson, Principles of Program Design, Nueva York: Academic Press,

8.

9.

1975,

Winston W, Royce, the Development of

iEEE Wescon, aqosto 1970, pp. 1-9.

Boehm, Software Engineering Economics. 1981.

N.J.: Prenti-

Software Systems",

10.

11.

into

Inmon, Information Practice, Englewood Cliffs, N,J,;

!"!Iarvln Gore y John Stubbe, Elements of que, Iowa: William Brown, 1983.

Y

Dubu-

12,

1. 2,

Mencione des sinontrnos de es la dif'erencia entre una herrarnienta. como se utiliza en este libro, y una rnatodoloqla?

son los tres principales propositos del ciclo de vida de un proyecto?

3.


4.

Proyecto de invsstiqacion: Encuentre sl preclo de trss productos para metodoloqia cornerciales ofrecldos por provsedores de software 0 empresas consultoras.

que normalmente las orqanizaciones pequefias de proceso de datos no usan rnetodoloqias formales?

.!.,Por que as uti I para los adrnlnistradores nuevos una metcdoloqia?

GPor que es irnportante tener una rnetodoloqia en una orqanlzaclon en la que se esten llevando a cabo rnuchos proyectos diterentes?

8. l.Como es que una metodoloqta es util para controlar proyectos?

5.

6.

7.

9. ",Cuales son las principales caractertsticas que distinquen el ciclo de vida claslco?

10. ",Que significa la expresion lmplantacion ascendente?

11. l,CuaJes son las cuatro principales dificultades con la estrateqia de lmplantacion ascendsnte?

t 2. GQue tipo de ambients es el adecuado para un entoque de implantaclon ascendente?

13. l.Por que es importante que "nada est a heche basta que todo este heche", que adernas es 10 que caracteriza al sntoque ascendente?

14. GPor que debieran encontrarse los errores triviales primeramente en la tase de de un proyecto?

is. te. 17.

GQue diferencia hay entre prueba y elimlnacton de errores?

que es diffcil la eliminacion de errores en una implantacion ascendente?

GQue se entiende por la frase "proqresion secuencial" cuando se describe el ciclo de vida de un proyecto?

l.Cuales son los dos principales problemas de la progresi6n secuencial? GCuales sen las principales dlterencias entre el clclo de vida serniestructurado y el clasico?

l,Cuales son las des principales consecuencias del entoque de la irnplantacion descendents?

19.

20.

21.

l,Por que, en el ciclo de vida sernlestructurado, el diserio a menudo involucra traba]o redundante?


22.

l,Cuales son las prlncipales diferencias entre los ciclos de vida semiestructurado y sstructuraoo?

Nombre las nueve aotivldades del ciclo de vida estructurado del proyecto.

son los tres tipos de personas que proveen de entradas pnrnarias al cicio de vida del proyecto?

son los cinco principales objetivos de la actividad de ta sncuesta?

es un dtaqrama de contexte?

l,Cual es el principal proposito de la actividad de anaiisis?

son los tipos de modelos producidos por la actividad de anal isis?

es el proposito de la aotividad de disefio?

'dlM'''''' son los cos asuntos principales que normairnente Ie usuario en la actividad de dlsefio?

23. 24.

25. 26. 27. 28. 29. 30.

al

31.

puede comenzar la generacien de pruebas de

dad 5)

32.

es 81 proposito de la actlvidad de descripcion del

33.

se utilize un diaqrama de el ciclo de vida del

de datos en la Figura 5.4 para rnostrar

34.

slnonirno para la palabra aotlvidad?

35.

la

en el ciclo de vida

es del proyecto?

36.

diterencia hay entre los del

radical y conservador para el ciclo de

radical vs. el

37.

son los cuatro princlpales criterios para elegir el conse rvado r?

le ocurre alqun criterio adicional para elegir un enfoque radical vs. un enconservador?

tipo de ontoque (radical vs. conservaoor) de~e escoqer el admi~istra~or

de un provscto si as probable que el usuario carnbie de respevto a lOS

requerimientos del sistema?

de enfoque (radical vs. conservador) debe escoger el si tiene una gran presion de tiernpo?

38.

39.

40.


41. "Que tipo de entoqus (radical vs. conservador) debe escoqer el adrruntstradodel proyecto si se encuentra con riesqos tecnicos importantes?

42. l..Que dlterencia existe entre el ciclo de vida de prototipos y el radical?

43. l..Que caracteristicas tiene ei proyecto de

ideal?

44. "Que clase de totipos?

45. iPor que no son los sistemas por lotes?

46. "Cuales son los peligros del entoqua de prototipos?

buenos candldatos para proyectos de prototipo

47. iComo utilizarsa en cornbinaclon en un proyecto los ciclos de vida es-

tructurado y de prototipos?

[I"'::' IG

II

Los dogmas del tranqutlo pas ado son inadecuados para el borrascoso presente. La ocaslon esta atiborrada de dificultades y debemos estar a la altura. Como nuestro caso es nuevo, debemos pen sal' Y actuar en forma novedosa. Debemos desenredarnos, Y entonces salvaremos a nuestra naclon,

Abraham Lincoln, Segundo Mensaje Anual al Congreso

10

1.

es un asunto

anatista de sistemas, forman} parte de un de personas cuyo

propos ito es desarrollar un sistema de informacion uti! y de alta caudad, que cub~ira las nscesidades del usuario final. AI llevar a cabo su traba]o, usted y sus cornpane-

ros miernbros del sin duda se veran inttuenciados por las

tantss cusstiones:

cornunes al

de errores en un

y el

un

117

118 ASPECTOS IMPORTANTES EN El DESARROllO

., Productividad

., Contiabllldad

., Mantenibilidad

Desde todo rnundo esta a favor de la productividad; es un terrnino utili-

zad.C: de igual forma que la rnaternidad y la leaitad a la patria, Pero hacs una generaclon,. cuando se estaban creando Ia mayetta de los sistemas operatives, la productividad no era algo a 10 que se hiciora rnucho caso, los analistas y proqrama. dores de los aries 60 trabajaban largas hams (aunque no siempre en horarios preds. clbles), pero nadie estaba sequro jarnas de cuanto traba]o loqranan hacer en una sernana, 0 cuanto les tomarta construir un sistema complete. EI sentir comun era que el equipo d~ desarrollo del proyscto trabajarta Duro cada y un dla, ivoilal, ilT1ag1a! el sistema quedaria terminado.

en la es un asunto rnucho mas serio. Asimismo 10 es 61

asunto de la confiabilidad: una talla del sistema en un sistema grande y ""',...,~,~;probablernente tendrta consecuencias devastaooras. Y la manterubilidad se ha vertido en un asunto de importancla tambien: ahora es clare que muchos de los ternas construidos hoy deberan durar por 10 rnenos 20 aries 0 mas antes de pu~da~ volverse a construir, y tendran que sorneterse a constantss revisiones y rnodiflcaciones durante su existencia.

Cada uno de estes asuntos se con mas detalle en este

no~,. c.omo el. asunto del rnantenirniento, aparentan tener poco 0 nada que ver con el anal ISIS de sistemas, perc, como se el analista juega un crucial en el 10-

gro de la una mayor conftabilidad y meier manterubifidad.

6.1 PRODUCTIVIDAIJ: El RETRASO EN lAS APUCACIONES

Tal vez el mas visible 131 que se entrenta actualrnents 113 protesion de

desarrollo de sistemas sea el de la producttvidad. La sociedad y los negocios

demos parecen exiqir cad a vez mas: mas Sistemas, mas y todo mas

Como analista, vera los dos principales aspectos de este problema: el

en los nuevos sistemas que se necesita desarrollar, y el que se

construir un sistema individual nuevo.

En casi orqanizacion de los Estados Unidos don de exista un

centralizado responsable del desarrollo de nuevos exists un retraso de

rios aries de en espera de que se le lIeve a cabo." de heche, rnuchas

zaclonss tienen un retraso de cuatro a siete afios 0 mas. EI retraso se oresenta

tres tipos dtterentes: .

1 Las conversaciones informales que he sostenido con administradores de proceso de datos en radii, Europa, Australia, Sudamerica y otras partes del mundo me Ilevan a ponsar que este problema no es unlco de los Estados Unidos.

ASPECTOS IMPORTANTES EN El DESARROllO 119

., Retraso visible. Sistemas nuevas que los usuaries han pedido oficlalmente y que han sido aprobados y financiados por comites apropiados de admtnistracion. Sin embargo, los proyectos no se han iniciado porque no existen los recursos adecuados (esto es, analistas, proqramadores, etc.).

@ Hetraso invisible. Existen sistemas nuevos que los usuaries saben que necesltan, pero no se han molestado en pedirtos "oflcialmente'', porque aun estan aquardando a que se concluyan proyectos del ret rasa visible.

., Retraso desconocido. Estes son sistemas nuevos que los usuaries ni siquieta saben que quieren todavta, perc que seran identiticados en cuanto se terrnine alguno de los sistemas del retraso visible 0 del invisible.

En un estudio clasico del retraso y de la demands de sistemas de informacion [Alloway y Quillard, 1982], los investiqadores Robert Alloway y Judith Quillard, de la sscuela Sloan del lnstituto de Tecnoloqla de Massachusetts, encontraron que el retraso invisible era tlpicarnente 5.35 veces mayor que el retraso visible de los nuevos sistemas. Esto suqiere que el problema del ret rasa es mas bien como el proverbial iceberg: solo una pequeria porcion es visible, con una gran parte oculta ba]o el aqua. Esto, desde luego, es un problema de primera irnportancia para la orqantzaclon de desarrollo de sistemas que Ileva a cabo su planeacion y sus presupuestos basandose s610 en las exiqencias conocidas y visibles de sus ssrvicios.

Un segundo aspecto del problema de la productlvidad es el tiempo necesario para desarrollar un sistema individuat-' Claro esta que, si el proyecto de desarrollo de sistemas promedio pudiera reducirse de tres aries a uno, €II problema del retraso desapareceria rapidarnente. Pero aqul el asunto es que los usuaries generaimente no se preocupan par el problema global del retraso, sino tarnbien par el problema focal de productividad asociado con un proyecto individual. Se preocupan por si, para cuando el nuevo sistema este listo, habran cambiado las condiciones de negocios tan drasticarnente que los requerimientos originales ya no sean relevantes.

poniendolo en otras palabras, un nuevo sistema se asocia con una oportunidad de negocios que el usuario percibe, y esa oportunidad a rnenudo tiene un margen de oportunidad, es decir, un periodo trae el cual esta habra desaparocldo y ya no se necesitara el sistema nuevo.

Existe un tercer motivo del problema de la productividad en muchas orqanizaclones: algunos proysctos resultan ser inutltes y la adrnlnlstracion los cancels antes de que se terminen. De heche, varias encuestas han mostrado que hasta un 25% de los proyeetos en orqanizaclones qrandes de sistemas de informacion jam as se con-

Existen, desde luego, muchas razones por las cuales puede tallar un pro-

2 Para dar una idea de hasta d6nde abarca este problema, Caper Jones encontr6, en una encuesta de aproximadamente 200 organizaciones grandes en EUA, que el proyecto tipico se retrasaba un ailo y se excedfa en un 100% del presupuesto. Vease [Jones, 1986].

120 ASPECTOS IMPORTANTES EN El DESARROLLO

yecto: problemas problemas adrninistrativos. Ialta

de tiempo para llevar a cabo un buen traba]o de anatisis y diserio cual usual men-

te es un problema de la y falta de participacion por parte de la admtnlstraclon 0 de los usuaries. Para una excelenta exposicion de la razon de las tallas de los proyectos, vease el aqradable libro de Robert Block, The Politics of Projects

19S0J.

EI problema de la productividad ha exlstldo per muchos arios en la proteslon de desarrollo de sistemas, y muchas crqaruzaciones estan buscando de manera

Ia forma de reducir radicalmente su rstraso en las y disminuir

el tismpo requerido para desarrollar un nuevo sistema. Entre las tecnlcas mas cornunments utilizadas sstan las

... Contreter mas proqremedores y eneiistes. Esto es muy comun en las or-

qanlzaciones nuevas y que crecen una orqanlzacion creada

como resultado de una 0 una orqanizacion nueva torrnada

mercados nuevos y nuevos Para

duras, sin este entoque usual mente se

chas slenten que tienen dernaslados

analistas ya y que en realidad 10 que se ocupa es hacerlos mas vos. 4

fa Contra tar y snettstes mas telentoeos y dar/as majores

condiciones de trsbsio. En vez de arrnar un gran de rnediocres

creadores de sistemas, alqunas se concentran en crsar

de altarnente capa-

Este

que

3 Un buen ejemplo de esto ocurrio a mediados de la decada de los arios 80, cuando varies parses liberaron su banca y su bolsa. Australia, Japon e Inglaterra estan entre los parses que de encontraron que cocenas de bancos y bolsas extranjeros abrlan sus puertas. De estes, tue tal vez la localidad mas visible, con su desreqlarnentacion "Big Bang" del 27 de octubre 1986. Estas actividades requirieron del desarrollo de nuevos sistemas grandes de cual general mente se lograba empleando a tantos programadores y analistas nuevos como se pudiera, en el tiernpo mas corto posible.

4 Esto contrasta con las predicciones de una esceeez nacional de programadores hechas per el Departamento de Comercio de los E.U., y la Fundacion Nacional de Ciencia. Para mayores detaH?s vease el Capitulo 28 de [Yourdcn, 1986].

ASPECTOS IMPORTANTES EN EL DESARROLLO 121

crsadores de herramientas, etc.) que apoya a un protesional de talento extraordinario que llevaba a cabo tanto el anal isis como el diseno del sistema. Desde lueqo, la mayoria de las orqanlzaciones no puede construir toda una de desarrollo de sistemas en torno a una persona diez veces superior al promedio.f Sin embargo, tiene bastante de

vo el tratar de volver 10 mas productive poslble al existents, dandole curses de actualizacion, herrarnientas modernas de desarrollo de software (que se tratan posteriormente con mas , y condiciones aproptadas de trabajo.f

fa Permitir a los usuerios deserrolter sus propios sistemas. Es interesante notar que rnuchos otros adelantos tecnoloqicos mterporuan a entre el usuario y el aparato mismo: el choter del autornovit y la operadora de conrnutador tefetonico son dos obvios. Desde luego, la rnayorla de nosotros no tensmos choteres y la mayorla no necesitarnos operadoras para realizar nusstras llamadas: el autcmovil y el teletono son 10 suficienternente "arnistosos" con el usuario como para que los operar nosotros rnismos. De igual rnanera, la combinacion de ras personates, centres de informacion y lenquajes de proqrarnacion de cuarta qeneracion, todo 10 cual fue introducido en rnuchas

estadunidenses a rnediados de los anos hicieron t u ",till!'"

usuaries (incluyendo, como se vio en el capitulo 2, a una

usuaries que aprendleron los fundamentos de la preparatoria a tacultad) el desarrollar sus

sencillas. los inforrnes ad las bases de

nojas de calcuto y ciertos cambios de mantenirniento a los proqrarnas

exlstentes son de los que un usuario motlvado y tetra-

do en pueds desarrollar par sf solo.

de los tenquajes de

sufrido snormes cam bios dasde los an os 50, cuando los creaban los proqrarnas coditicando laboriosarnente los ceres y unos bina-

rios que el hardware Esta primers de! de

dio a una de ensamblador en

los arios 60, y es lnteresante notal' que el lenqua]e ensembteaor aun se utlliza hoy en dla en algunos Sin embargo, los lenquajes de

5 Para una expcsicion detallada del per que no es practice el concepto de superprogramador en la mayona de las organizaciones, vease Managing the Structured Techniques [Yourdon 1988].

6 Una interpretacion obvia cle las condiciones de traba]o apropiadas es dar a cada rniernbro del proyecto una oficina privada, 0 para dos personas, 0 un cubfculo aislado de ruidos para permitir la privacidad y la concentraclon. Esto por sl solo es probable que mejore Ia productividad del analista/ prograrnador en un 10 por ciento 0 mas, en cornparacion con el que traba]a en un area abierta y grande con musica a todo volumen. Otra interpretacion es esta: dejelos trabajar en casa, Para ehcncar mas sobre este concepto de la "cabana electrontca", vease el capitulo 3 de [Yourdon, 1986],

122 ASPECTOS IMPORTANTES EN EL DESARROLLO

procedlmlentos de la tercere qenerecion ernpezaron a prevalecer en los aries 70 y siguen siendo e! tipo mas comun de lenguaje; como ejernplos tensrnos COBOL, FORTRAN, BASIC, Pascal, C, MODULA-2 Y Ada. No obstante que la industria de software continua mejorando estes lenquajss (por ejemplo, la version actual de FORTRAN es mucho mejor que la que usa ban los proqramadores a comlenzos de los aries 70), el sntoque se ha dirigido a una nueva cuerte generaci6n de lenquajes que eliminan la necesidad de preocuparse par engorrosos y rnorosos detalles de edicion y valicicn de sntradas, tormato de los reportes y rnane]o de archives, Ejemplos de esto son FOCUS, RAM IS, MAPPER Y MARK V (al igual que lenguajes como PC-FOCUS, dBASE-III Y Rbase-SOOO para cornputadoras personates). Muchos arguyen que estos nuevos lenquajes pueden incrementar la productividad de ta actividad de proqramacion hasta en un factor de diez. Sin embargo, dado que la proqramacion represents tfpicarnente solo del '10 al 15 por ciento del proyecto global de desarrollo del sistema, la qanancia global en productividad es a menu do mucho menos substancial,

Ataear et problema de! mentenimiento. EI mantenimiento es un asunto de primera importancta en el campo del desarrollo de sistemas, como se discutira en la seccion 6.4. Sin embargo, la mayor parte de la atencion esta entocada actual mente (como era de esperarse) a la rnantenibilidad de los sistemas nuevos: rnientras tanto, como se menciono anteriorrnente, rnuchas orqanizaciones sstan dedicando un 50 a 70 par ciento de sus recursos al mantenlmlento de sistemas viejos. Asl, la interroqante es l,que puede hacerse para volver mas taciles de mantener estes sistemas vie[os, aparte de la idea obvia de desechartos y construir rsemplazos nuevos? Un entoque que crece en popularldad es el de reesiructurecion, es decir, la traduccion mecanlca de los proqrarnas anteriores (cuya loqica ha sido parchada y cambiada tantas veces que a menudo es cornpletamente ininteligible) a proqramas nuevos, sstructurados y bien orqanizadosf Una idea relacionada con esto es el uso de paquetss autornatizados de documentaclon que pueden producir listados de referanclas cruzadas, diccionarios de datos, diaqrarnas de flu]o de datos detallados, diagram~s de estructura, 0 diaqrarnas de Iluio del sistema dlrectamante desde el programa (a esto algunos encargados de mantenimlento Ie Haman en reversal. Otro entoque, como se menciono anteriormente, es

a los usuaries a realizar sus propias modificaciones de

7 Existen diversos productos comerciales en esta area. Entre los mas ccnocidos estan Superetruc: ture, de Group Operation, Inc; Structured Retrofit, cornercializada por Peat, Marwick; y Recorder, de Language Technology, Inc.

8 Esto es particularmenle relevanle, pues de acuerdo con un estudio [Lientz y Swanson, 1 aproximadamente el 42 por ciento de la actividad de mantenimiento en una organizacion tipica


Otro entoque mas es el de docurnentar cuidadosamente la naturaleza especffica del traba]o de mantenimlento: a menudo resulta que tan solo un 5 por ciento de la coditicacion en un sistema operacional es responsable de un 50 por ciento 0 mas del trabajo de mantenlmiento.

Disciptines de ingenieria de software. Otro enfoque mas para la mejor prcductividad es un conjunto de herrarnientas, tecnicas y disciplinas generalmente conocidas como inqenleria de software 0 tecnicas estructuradas que incluyen la proqramaclon estructurada, el disefio estructurado y el anal isis estructurado.? adernas de disciplinas relacionadas con esto, tales como metrica de software, prusbas de correccion de programas, y control de caudad de software. En general, las tecnicas estructuradas han tenido un impacto modesto, tlpicarnente una rnejora de un lOa 20 por clento, sobre la productividad de los protesiotieles del desarrollo de sistemas durante fa isse de desarrollo de! proyecto. Sin embargo, los sistemas dssarrollados utillzando tecnicas estructuradas en general tienen costas de mantenimiento substancialrnente mas bajos y una confiabilldad considerablernente mayor, a rnenudo por un factor de 10 0 mas. Esto tiende a liberar recursos que de otra rnanera estarlan acaparados per el mantenimiento 0 el arreglo de fallas, con 10 cual se msjora ta productividad de toda la orqanlzacion.

Herrsmientes eutomstizedes para et desarrollo de sistemas. Por ultimo, observarnos que una razon del problema de la productividad es que mucho del traba]o de desarrollo de un sistema autornatizado de informacion se ironicarnente, de manera manual. As! como los hijos del zapatero son los ultimos en recibir zapatos, los programadores y analistas tradicionalmente han sido los ultirnos en gozar de los beneficios de la automatizacion en su propio traba]o. Desde luego, se arqurr que un compilador es una herramienta autornatizada para la proqramacion, as! como los paquetes de prusba y los auxiliares en correccion de errores proporcionan una forma de automatizacion. hasta recienternente. ha habido poca ayuda autornatizada para el disefiador de sistemas y cas! nada para el analista. Ahora hay estaclones de traba]o que auto-

siste en "mejorfas del usuario", en comparacion con el 12 per ciento para "cornposturas de ernergencia", el 9 per ciento para "correcciones de rutina", el 6 por ciento para el acomodo de "cambios de hardware", etc. De la porcion invertida en mejorfas, el 40 por ciento se invirtio en tratar de hacer reportes nuevos adicionales, el 27% en ariadir datos a los reportes existentes, el 10 por ciento en moolflcar el formata de reportes sin carnbiar el contenido de datos, y el 6 por ciento en consolidar datos ae reportes existentes y lenguajes de cuarta generacl6n. Es probable que muchos de estos cam bios los hubiera podido hacer directarnente el usuario.

9 EI entoque del analists discutido en este libro representa la forma actual del anahsis estructurado. Como veremos en 81 capitulo 7, ha habido cambios desde que se introdujera por primera vez en los lextos a fines de ios anos 70.

124 ASPECTOS IfvlPORTANTES EN El DESARROllO

rnatizan la mayor de la tedlosa labor de desarrotlar V rnantener dia. gramas de de datos, diaqramas de entidad-relacion V otros modelos

que virnos en el 4. Estas herramientas

tam bier; se encarqan de una variedad de actividades de revision de erro-

res, 10 cual asequra que la producida por el

no e internamente firrne. Y, en

herramientas autornatlzadas incluso genera:

de la elirninando de esta rnansra la activldad manual de manera absoluta. En el A se tratan detalles de estas herramisntas autornatizadas para el anal isis de sistemas.

se encontrar una excelente sobre el

tativo, de estes metodos as! como de un gran numero de facto res de

sef: G Por es re-

levante esto?" De parece que la de los asuntos relacionados con la

tiene que ver con la la y el mantenlmlento. Nin-

guno parece tener que ver con el analists de sistemas. Sin existen tres ra-

zones par las como debe ser muy sensible al asunto de ta

La calidad del heche por el analista tener un ire-

mendo sobre el que se invierte en dado que el 50 per

ciento de los errores (y el 75 per ciento del coste de su usualrnente se asocian con errores en el anal isis. Pudiera

de la por el que invierten en re-

alizar pero a rnenudo esto es un indicia de la poca caudad de la

labor realizada por el analista.

2. de las tecnicas de -rnas V

condiciones de y, sabre herrarnientas

son de relevancia directa para el analista. Vale la pen a pensar

hacerse para volver a usted y a su mas

3, La del analisis de sistemas es un asunto deli-

cado, pues a rnenudo Ie parecs al usuario (y a vecss a los administradores del qrupo de desarrollo de sistemas y de otras de la que se hace muy poco durante la rase de analisis. Con Irecuencia se escucha el comentario: "GCuando van a cornenzar con la proqrarnacion? [No podernos dames el de estar sentados para slernpre platicanoo ace rca del sistema; ya necesitamos que se real Ice!"


Y los usuaries no Ie gran valor a la que es el del anal isis del sistema. La reaccion que se da a la espe-

cltlcaclon a veces sera: "GPara tanto alboroto con todas estas

nes y Le 10 que queremos que el sistema, GPara

tuvo que sscnbir todo esto?".

no se etaborar un sistema que de buen de

si no se sabe y con suticiente se

hacer. As! que, a pesar de que usuaries y adminis-

tradores de que el analisis es rneramente un

so" mientras se prepare para la verdeders labor del el

as que debe hacerse de manera cuidadosa

hacerse con tanta eficieneia y ccnviene

analista no pensar que el anal isis es

CONFIAB~UDAD

al que se entrentan los que desarrotlan sistemas es el de

que se invlerte en y la de erro-

50 per ciento del de desarrollo de un y la

muchos sienten que se relaciona con el

en ser si el resultado fuesen sistemas

y tacurnente rnantenibles. La evidencia de los ultirnos 30 aries

contrario: los sistemas todo el mundo estan

Otro gran la confiabilidad.

Estar "llenos de errores" cosas drterentes para diterentes personas.

En el software desarroltado en los Estados Unidos tiene entre tres y cinco

errores per cad a 100 instrucciones del proqrarna. de que software

ha y al -vease Unos cuantos pro-

de desarrollo de software de tres a cinco erro-

he. habido

que tener hasta de tres a cinco errorss

que el software estadounidense por cads 0 instrucciones del proqrarna.

Los errores de software van oesde los sublimes basta los ridlculos. Un error

trivial consistir en salidas correctas, pero que no se

presentan tan bien como el usuario desearia. Un error rnoderadarnente serio

ra ser case en el cual el sistema se rehusa a reconocer ciertos

perc el usuario final nallar forma de salta: el

series sen que ocasionan que todo el proqrarna deje de can una

asociada de dinero 0 de vidas humanas, de errores series

relaeionados con software que se han ide documentando en el transcurso de los aries son los


e En 1979, 191 sistema SAC/NORAD (siqlas en ingles de Comando Aereo Estrateqico/Detensa Asrea Norteamericana) reqistro 50 Ialsas alarmas, incluyendo un ataque simulado, cuyos resultados 0 salidas cornenzaron accidentalmente una "escararnuza" en vivo.

" Un error en el programa simulador de vuelo del Fi 6 bacia que 191 avion volara en posicion invertida (cabeza aba]o), cad a vez que cruzaba 191 ecuador.

.. Un proyectil Fi8 cornenzo su propulsion estando todavia unido al avi6n e him que sste perdiera 6 000 metros de altitud.

.. Las puertas del sistema de trenes controlado por cornputadora en San Francisco, se abren a veces en trarnos largos entre estaciones.

" Una serial de alerta de la NORAD, del Sistema de Advertencia Rapida de Proyectiles Balisticos (8MEWS), detecto a la Luna como un proyectil que Ilegaba.

4> EI lndice de la Bolsa de Vancouver perdio 574 puntos en un perlodo de 22 meses debido a redondeos (por ejemplo, redondear 3.14159 a 3.1416)

.. EI 28 de noviernbre de 1979, un avion de Air New Zealand se estrello en una montana. Las investigaciones posteriores rnostraron que se habra detectado y correqldo un error en los datos de curse de la computadora, perc que [arnas se intormo de esto al piloto.

Desatortunadamente, la lista y sigue. Para ver mas ejernplos, remitase

a [Neumann, 1985]. Muchos errores de software se reportan porque 191 individuo 0 la orqanizacion "culpables" preterirlan no adrnitirlo pubtlcarnente. AI rnornento de escribirse este libro, habla gran preocupaclon per 191 heche de que errores de este tipo pudieran Ilegar a consecuoncias larnentables con el proqrarna Guerra de las Galaxias, del Departamento de Detensa de Estados Unidos, 0 con algunos otros tamas complejos control ados per software de detensa aerea: vease [Jacky, 1985] y [Adams y Fischetti, 1985]. De heche, aun si la confiabllidad del software de la Guerra de las Galaxias fuese 100 veces mayor que la de los sistemas promedio desarro!lados en Estados Unidos, pudiera todavfa tener alrededor de 10 000 errores, 10 cual no es una perspective tranquilizante si se considera que cualquiera de esos errores pudiera acabar con la vida en este planeta.

En rnuchos cases, nadie esta muy seguro respecto a cuantos errores tiene un sistema, pues t) algunos errores jarnas se encuentran antes de que caduque el sistema y, 2) el proceso de documentacion y reqistro de srrores es tan descuidado que fa mitad de los errores encontrados no se reportan,"? aun dentro de la orqanizaclon rnisrna de desarrollo de sistemas. En cualquier caso, el Ienomeno ttpico de descu-

10 Esto se basa en la encuesta hecha por Lientz y Swanson [Lientz y Swanson, 1980J.


brimiento de errores, en un periodo de varios anos de utilidad de un sistema de software, usualmente toma la forma rnostrada en la figura 6.1.

La forma de esta curva recibe lnfluencias de buen nurnero de facto res. Par ejemplo, cuando el sistema se entrega per primera vez a los usuaries finales, a menudo no pueden ponerlo a trabajar a su maxima capacidad. Lleva tiempo convertir su sistema anterior (que pudisra haber sido un sistema manual) y capaeitar a su personal. Adernas, descontian un poco de la computadora y no la quieten usar dernasiado, par 10 que se descubrsn pocos errores. AI convertir su operacion anterior al nuevO sistema, a medida que su personal operacional ya esta mejor preparado y que dejan de sontirse intirnidados, smplezan a usar mas el software y S8 ancuentran cada vez mas errores. Desde luego, si esto continuara indefinidarnente, si se encontraran cad a dia mas errores, los usuaries final mente dejarian de usar 81 software y 10 desecharian.11 En la rnayorla de los cases, los programadores arreglan treneticamente nuevos errores al irlos descubrisndo los usuaries. En la mayo ria de los ca- 50S, Ilega un memento en 191 cual 191 sistema ernpieza a estabilizarse y los usuaries encuentran cada vez menos errores.

Existen tres aspectos deprlmentes en la figura 6.1. Primero, la curva jamas regresa a cere: as decir, cast nunca encontrarnos una situacion donde transcurra 191 Hem po sin encontrar nuevos errores, Segundo, 191 area ba]o la curva, que representa

Tiempo transcurrido

Figura 6.1: Enores descublertos como funclon del

11 Desde iuego, hay excepciones al acoplamiento gradual, sobre todo cuando un nuevo sistema tiens que aceptar de una vez todo el trabajo (transacciones) del anterior. Como un ejemplo interesante, en el cuai se renovo el sistema de bonos de cobertura nacionai de Dinamarca, vease [Hanser, 1984].


el nurnero total de errores descubiertos en funcion del es atrozmenta orands. su es de tres a cinco errores per cada cien instruccionee del proqrama, '1' t~rcer~, la curva final mente cornienza a subir de nuevo, par 10 cornun de va:

nos anos. Per tad os los sistemas de software a un estado de

do t~l. que intento de elirninar un error introduce otros des nuevas y las

rnodificactones necesarias para eliminarlos mrroouctran y aSI en adelante.

Exists un ultimo que cabs sefialar acerca de los errores de

no son taciles de enmencar, Cuando ya sea , usuario final 0

dsscubrs que el software no funciona

debe identificar el

error y~ debe encontrar la mansra de

lnstrucciones de

atectar otro

el

La correcclon de errores sobre la rnarcha es un aspecto del Lientz y Swanson y i encontraron que en esto consisttan mas del 21 per ciento de los esfuerzos de mantenimiento en las estadounidenses proceso de datos,12 EI mantenimiento tam bien involucra la modifi-

cacion de un sistema para el modificaciones oars

apresurar ciertos aspectos oara cambio~ en

los de! usuario final del sistema. '

EI mantenimiento de software es un en rnuchas

entre el 50 y £11 80 por ciento del que se hace en la

de desarrotlo de sistemas se asocia con la

o correccton de errores an programa de

fa que otra persona escribio hace mucho. es caro: a comienzos de los afios

de la Def'ensa de Estados Unidos mtorrno Que el coste rw",",."",,,,

rrotlar proqrarnas de en un proyecto era de 75 dolares estadouniden-

ses par instruccion de 81 costa de mantener 81 sistema hasta

los 4 000 dclares estadounidenses por instruccion.

Para poner ssto de una manera rnucho mas clara considers los

de la del Social de los Estados Unidos:

2 Dado que la industria de la computaci6n represents aproximadaments un 8 0 10 por ciento del PIS de los EUA, esto Signifies que se estan gastando aproximadarnsnts 75 d61ares estadounldenses por cabsza al afio en mantenimiento de software.


Calcular el incremento en el coste de la vida de 50 millones de COf'o"tf'>

de los beneficics del Social el uso de 20 000 horas de

del Sistema

Cuando el Sistema de Social aumento sus sistemas de

de cinco cltras a de seis

de y 2 500 horas de

ra rnodificar 600 proqrarnas distlntos.

La moral del de mantentmiento del Social estaba tan en un momenta dado que se a uno de los proqramadares orlnando sobre un paquete de discos en la sala de esto detlnltivamente es una rnanera novedosa de

no resulta muy busno para el discos.

EI

cada vez mas interesante: en la medida

encontrarnos una analoque se estanca el software se estancara 121 cornpa-

o 121 sociedad a 121 que sirve elcho software.

es peer aun. Si tuera considerar desecharlo t""Lc'UU su software

de adrninistracion y de los sistemas

en de las no existe una

se supone que los sistemas deben nacer, La documentacion existents suele ser ob-

solete y confusa. En cuando idea de como

tunciona ei software, pero no de cue! es su de

se supone que debe rsalizar.

",I<:",n,o,,,j'o un caso de que el software Pero muchas

que la rnantenibilidad es enterarnente

funcion de la algo que preocupa a los es irn-

mantensr un sistema si no existe un modele y actualizado de sus re-

a fin de cuentas, es labor del analista. Como se vera en el funcionales desarrclladas por los analistas han pro-

desde novelas victorianas absoiutarnente inrnantenibles

a rnodelos sistema hecnos a mana, y

hasta modelos y mantenidos por ta Tambien se discutira el

asunto del rnantenlmiento continuo de las del sistema en el ca-

24,

130 ASPECTOS IMPORTANTES EN El DESARROLLO

6.4 OTROS ASUNTOS

6De que tiene que preocuparse 131 analista adernas de la productlvldad, la con. fiabilidad y la mantenibuidad? La lista varia de una orqanlzacion a otra y de un pro. yecto a otro, pero por 10 cornun lncluye 10 siguiente:

<& Eticiencis. Un sistema debe operar mediante satidas 0 productos (0 resultados) apropiados (usual mente rnedidas en transacciones por sequndo) y con un tiempo de respuesta adecuado para las terminates en linea. Este no suets ser asunto del que se tenga que preocupar el anatlsta, puesto que los disefiadores y programadores tend ran la influencia prlnepal en ia eficiencia global del sistema ya realizado. De heche, se esta volviendo un asunto cad a vez rnenos importante para los sistemas modernos, dado que los costas de hardware se vuelven rnenores cada afio, mientras que la potencla y la rapidez aumentan conttnuamente.P

® Trensportetntidea. La mayorla de los sistemas nuevos se realizan en una maroa de computadora, pero pudiera habet necesidad de desarrollar 61 sistema de tal manera que se Ie pueda mudar tacilmente entre computedoras, Nuevamente, este no es asunto que deba preocupar al analista, aunque pudiera requerir que se especifiquen las necesidades de transportabilidad en el modele de implantacion.

® Seguridad. Dado que los sistemas rnodernos de cornputacion son cada vez mas accesibles (pues tienden a estar en linea), y dado que se utiltzan para administrar bienes cad a vez mas delicados de la orqanizacion, la seguridad se esta convirtiendo en un asunto de importancla para rnuchos proyectos de desarrollo de sistemas. EI nuevo sistema debe evitar el acceso no autorizadc, adernas de la actuallzaclcn y la eliminacion no autorizadas de datos delicados.

6.5 RESUMEN

Varies predicen que la razon rnaternatica 0 proporcion precio/rendi-

miento del hardware de cornputadora mejorara por un factor de mil y posiblemente hasta de un en los proxirnos lOa 15 anos. Desatortunadarnente, la historia del desarrollo de software en las ultimas tres decadas llevaria al observador prornedio a concluir que la tecnotoqta de software s610 en una cantidad modesta.

13 Hay algunas excepciones a esta atirmacion optimista. Para algunas apticaciones cnticas (predicci6n del clima, mvestipacicn nuclear, modelado de propiedades aerodinamicas de aeroplanes y autom6viles, stc.), aun no es adecuada la tscnoloqta eomputacional actual. Para una mayor exposici6n de esto vease [Yourdon, 1986]. Para muchos sistemas de tiernpo real e intarconstrulcos, la tecnoloqia sf es adecuada, pero los disefiadores y programadores deben trabajar duro para lograr un nivel de efieieneia aceptable. En algunos cases la tecnoloqia de hardware parece adecuada, pero el nuevo software (per ejemplo, lenguajes de cuarta generacion) resultan ser ineticientes a tal grado que el sistema global no es aceptablemente eficlente.

ASPECTOS IMPORTANTES EN El DESARROLLO 131

.' t la "ruta crtttca" de muchos sis-

Dado que el software se ha vuelto el pr~~I~~~~i~:~~se aceplable. En lad a la indus-

temas, una m~ioral ta~ tmeOudneset:f~~r~~~norme v concertado para rsallzar mejoras de

. omputaclona eXls , f

tna c. d aqnitud en el proceso de desarrollo oe so tware.

un orden em t

t rb son parte de dicho ssruerzo.

Las tecnicas de analisis presentadas ent eSd e I~ :rogramaci6n a dtsefio del sis-

Como se ha visto, parte del e~ffUer~? e~e~s~i~t~m: crea los cimientos en los cuales

. oero una buena especi IcaClon . ,

~~:~ 'sostenerse el dlsefio y la programaclon.

REFERENCIAS

. '11 d "User Manager's Systems , CISR War-

1. Robert Alloway YCJUdblt~dQUI Ma~S~ . M!T Sloan School for Information Systems

king Paper 86. am n ge ..

Research, abril 1982.

2.

. E G nt "Exploratory Experimental Stu-

Harold sackr:'an'OWI·.J· ErnlcdkSoo~ii~e Epr~gr~~~ing Performance", Communicadies Comparing n me a

tions of the ACM, enero 1968, pp. 3-11.

. " t E 'neering Concepts and

J, Aron, "The Super-Programmer PrDJectN so_twar~ ~~nde!1. Nueva York:

Techniques. sds. J.M. Buxton, P. au; Y .

Petrocelli/Charter, 1976, pp. 188-190.

F.T. Baker, "Chief Programmer Team, Managment of Production :s~~~~amming'"

IBM Systems Journal, volumen i 1, nurnero 1 (enero 1 pp.

H.D. Mills Y FT Baker, "Chief Programmer Teams", Datamation, volumen 19,

numero i 2 (diciembre, i pp, 58-61.

Yourdon, Alfanaging the Structured Techniques: Strateglp'es for S1'o9~~are

dl .. N eva York' ress,·

Development in the 19908,3913 teton, u .

Bennett P. Lientz y E. Burion Swanson, Software Maintenance Management. Mass: Addison Wesley, 1980.

T. Capers Jones, Programming Productivity. Nueva York: McGraw-Hili, 1986. "'t survey" dtscurso en 10. Pnmera T. Capers Jones: "A SOHwarce ~~o~U~~V~~f;ware y' Productividad, WilliamsConferencia Nacional score a I a

Virginia, marzo 1985.

3.

4.

5.

6.

7.

8. 9.

1 o.

Edward vourdon, op cit. F.T. Baker, op cit.

" N w York Times 4 de julio de

David Sanger, "Software Fears on Star Wars, e '

1985.

1i. 12.


13.

"Some Computer-Related Disasters and Other Egregious

Software enero 985.

"The Star Wars Defense Won't Compute", Atlantic Monthly,

i 4. Jonathan nio de 1985.

15.

John A. Adams y Mark A. "Star Wars-SDI: The Grand

IEEE septiernbrs de 1985, pp. 34-64.

Articulo del New York Times, alrededor del 16 de septiernbrs de 1986 que

mentaba el numero de errorss en la Guerra de las Galaxies. '

17. Dines

18. Edward

and Running. Nueva York: YOURDON op cit.

1984.

i 9. Bennett P. Lientz y Burton

20. Jack Rochester y John ({OW, 1983.

op cit. The Naked

Nueva York: William Mo-

21. Edward

22. Robert

at Risk. Nueva York: YOURDON The Politics of Projects, Nueva York: YOURDON

1986.

i 981.

1. Examine un

2. una

doras para su continuar cion.

que sea obvio que de

diaria. Estims cuantos sernanas 0 meses

la empresa si se detuvieran sus sistemas de

3. son los tres

mente?

del desarrollo de sistemas

4. es probable que la

desarrollo actual de sistemas?

mas visible en e!

o.

de retraso que se pueden encontrar en una

6.

ASPECTOS Ifv1PORTANTES EN EL DESARROLLO 133

7. es ta diterencia entre retraso visible e invisible?

8. l,Cuando exlste un retraso desconocido?

9. es probable que el retraso invisible sea rnucho mayor que el visible?

10.

son las siets principales soluciones que siquen las orqanizactones pa-

ra resolver sus problemas de productivldad? otras?

cree que una ernpresa deba medrr la de desarrollo de sistemas?

de su orqanizaclon

2. tan rssulta solucionar el

do mas proqramadores y analistas?

que sea practice resolver el problema de

o analistas con mas talento? que sf 0 por

14. que hubiese un diez veces mas

promedio que percibe 250 mil dolares de anuales.

18. admintstraclon de una orqanlzaclon este dispuesta a

dolares de anuales en el con talento?

13.

pro-

estar dispuestos a ello?

no?

15.

i6. de sistemas serian mas

rrollaran por sf solos? cree que sea

8. en su

cinco anos si se cornenzara a utilizar un nuevo len-

de se veda atectado esto por el existenie

y por 10. "cultura" existente de los y analistas?

un lenqua]e de proqrarnaclon de cuarta una

en la que uno ccnvenclonat de tercera genera-

9.

cion?

2(L

mejorarla la en una

miento pudiera reducirse en un factor de O?

si el mantenl-


134 l\SPECTOS IMPORTANTES EN El DESARROllO

Proyecto de investiqaclon: Utilice un prcducto comercial de tipo "maquina de estructuraclon" para reestructurar un proqrarna existents en su orqanizacion, y mida ta reduccion de los costos de rnantenirniento, GQue Ie dice esto acerca de los beneticios potenciales de una maquina 0 rnetodo de estructuracion?

22. e,Cree que la reestructuracion pueda convertir proqrarnas buenos en malos? que sf 0 por que no? Si su respuesta es no, sntonces, ",cuill es el proposito de la reestructuracion de proqramas?

21.

23. GPueden los usuaries llevar a cabo su propio mantentmiento de software? ",Que se ocupa para que esto funcione? Hablando en forma realista, Gcucinto traba]o de rnantenlrniento de software cree que los usuaries pudieran ser capaces de hacer?

24.

que la lnqenlerla de software puede

la productividad?

25. .:,Por que pueden mejorar la productividad las herramientas autornatizadas de desarrollo de software?

26. ",En que puede afectar at traba]o del anatista la productividad en un proyecto de desarrollo de sistemas?

27. ",Que tanto de un proyecto se invierte en pruebas y correccion de errores?

28. Proyecto de investiqacion: es el nurnero promedio de errores en los sistemas desarrollados por su organizaci6n? .:,CuE'ti es la varianza: la diferencia entre el peer y el mejor?

29. Proyecto de investiqacion: encuentre per 10 rnenos des ejernplos documentados de tallas en el ultimo afio en sistemas que hayan causado perdidas de vidas 0 que hayan costado mas de 1 millen de dolares de EUA. ",Como pudieron habarse evitado sstas fallas?

30. que tiende a eumenter el numero de errores en un sistema despues

que se pone a Iuncionar por primsra vez?

31. ",Por que tiende a aumentar el nurnero de errores gradual mente tras haber tado funcionando varies anos el sistema?

32. Proyecto de investiqacion: ",que porcentaje de los recursos de su orqanizacicn de desarrollo de sistemas se invierten en rnantenimiento? ",Esta al tanto la adrninlstracion superior de estas cifras?

33. e,Que factores, adernas de la productividad, calidad y confiabltidad, son importantes en la orqanlzacion tlpica actual de desarrollo de sistemas?

34. ",Que papel representa el analista en la determinacion de la eficiencia de sistema de informacion actualmente?

35.

papel juega 81 anatlsta en la determinacion de la transporiabilidad de un sistema de informacion en la actualidad?

papel tiene el anallsta en la determinacion de la seguridad en un sistema de informacion actualmente?

36.

Se han acunado nuevos termlnos. tales como tecno-stress y tecno-shock, para definir las manifestaciones psicol6gicas de un publico avasallado por toda erase de cosas, desde homos de microondas hasta juegos caseros de Pac-Man. Desalortunadamente, estes terminos no describen adecuadamente el progreso en la industria del procesamiento de datos, en 10 relacionado con el desarrollo de software. Para muchos profesionales del proceso de datos, el tecno-stress se define mejor como la trustraclon que tras el lento carnbio que se esta dando en los rnetodos de desarrollo de software, ante la siernpre creciente demanda de servlcios de procesamiento de datos.

Aunque no hay duda de que se ha tenido algun progreso orientado hacia mejores rnetooos de desarrollo de sistemas durante los ultirnos 30 aries, tampoco la hay de que, en general, cualquier proceso de cambro es lento y discontinuo. Desde una perspectiva historica, parece ser que para que se logre un verdadero progreso debe haber un replanteamiento peri6dico y colectivo de las ideas basicas. Los lapses que hay entre cada gran salto de avarice pueden ser de decenas a cientos de aries.

F.J. Grant, "EI software del siglo XXI" Datamation, 1 Q de abril de 19S5

En este

10 se

1.

sistemas,

136

CAM BIOS EN EL ANALISIS DE SISTEMAS 137

metodos y herrarnientas de analists de sistemas que se prssentan en este libro representan un de 10 mas avanzado que se usara en la mayorla de las de desarrollo de sistemas durante 61 resto de los afios 80 y comienzOS de los 90. Para meoiados de los 90 as que el analisis de sistemas haya evolucionado sustancialrnente: en el capitulo 25 se discute 10. probable natura-

leza de dieha

Pero no es suficiente estar 0.1 tanto de las tecnicas actuates de analists de sis-

temas. 'rarnoten deben cornprenderse los que han en los ultirnos

cinCO a diez que han conducido a tecnicas y harramientas que explorare-

mos con mayor detalle en las partes II y III. Existen tres razones por las wales debe estar familiarizado con la evolucion del anal isis de sistemas.

Primero, ser que sncuentre que la crqanizacion de desarrollo de siste-

mas para la que traba]a no ha evolucionado y que nadie tiene intencion de hacer los carnbios que se discuten en este capitulo ocurrieron en aproxi-

madamente un 80 % de las de proceso de datos de Estados Unidos,

y otras partes del mundo, aun qusdan aquellos baluartes de la me-

que no ven razon alguna para cambiar la forma en la que han venido tradssde hace 20 aries. Si se sncuentra en esta situacion, 10 logieo seria

buscarse otro empleo: 0, si se siente con valor, pudiera adopter un de IIder y

a su orqantzacton a entrar al rnundo moderno del analisis de

Segundo ("1 mas probablemente), pudiera encontrar que su orqanizacton ha

a implantar algunos de los cambios que se tratan en este pero

que el proceso de carnbio durara otros cuantos afios mas. Un buen de esto

5S 61 desarrollo de herrarnientas automatrzadas para el anal isis de sistemas. Casi todos los analistas Ie dlran que estas herramientas basadas en PC (computadoras son una buena idea, y algunos adrninlstradores de proceso de datos estan cornenzando a apoyar el concepto. Perc las herramientas son relativamente nue-

vas; cas! no existian antes de 1984. Y las orqanlzaciones son lentas en hacer 61

para fines de 1987 se sstimaba que rnenos del 2 por ciento de los analistas de sistemas en los Estados Unidos ten ian acceso a las herrarnientas que sa tratan

en este para 1990 se estima que aproximadarnente el 0% de los analistas las

sstaran y probablernente no ocurrira una verdadera saturaclon del merca-

do hasta mediados de los anos 90. Por 13110, aunque usted. y otros rniernbros de su organizaci6n sepan que herrarnientas "1 tecnicas se instalaran centro de tres afios, es posible que el actual del anal isis de sistemas sea algo diterente. Es importante que sepa que entoque estuvo utilizando anteriormente la orqanizacion y

ttpo de transiclon esta ocurriendo.

1 Esta suqerencia no es trtvola. Si estas organizaciones no carnbian, qusdaran fuera del rnercado en algun periodo de los aries 90.

138 CAMBIOS EN EL ANALISIS DE SISTEMAS

Tercero, la nocion de trensicion es importante aun si traba]a en una de las Or. ganizaciones "llderas" que han irnplantado cornpletamente el entoque de anal iSis que se prssenta en este libro. EI campo del anal isis de sistemas, como todosl08 dernas aspectos de las computadoras, es dinarnico: la manera en la que se llevs el anal isis de sistemas en 1995 indudablemente sera diferente de como se hace ahora. Para dilucidar los cam bios que sucederan durante la ultima mitad de los aries 90se requiere una buena apreciaclon del oriqen de este campo de as! como de hacia donde se dirige.

7.1 El MOVIMIENTO HACIA El ANAUSIS ESTRUCTURADO

Hasta fines de los afios la gran mayo ria de los proyectos de desarrollo de

sistemas empezaban con la craacion de una "novela victoriana" de requerlmlento, del usuario. Es decir, el analista eseribla 10 que entendia de los requerirnientos del usuario en un enorrne documsnto que consistia primariamente en una narrative. Los

autores de textos de "analisis estructu rado", sobre todo Marco, 1978],

y Sarson, 1977J y [Weinberg, 1978], sefialaron que estes pesados tomoS(a menudo conocidos como "especlficacion funcional") se velan atectaoos por diversos problemas irnportantes:

.. Eran monolfticos: habra que leer completamsnte la especiticacion, principle a fin, para poder entenderla, Como en una novela victoriana.isl no se lela la ultima paqina, S8 tendrla poca idea de como terminaria la rnstoria.s Esta es una falla tmportante, pues existen rnuehas situaclonss en las que el analista quisiera leer y cornprender una parte de la especiflcacion sin tener necesartamente que leer las comas.

.. Eran redundantes: a msnudo se rspetia la misma informacion en diversas partes del docurnento.v EI problema con esto es que sl cambia cualquisr aspecto de los rsquertmientos del usuario durante la tase de anal isis .(0 pear aun, despues de declararse terrninada esta), el cambia debe reflejarse en diversas partes del documento, Este seria un problema menor puss basta la orqanizacicn mas primltiva cusnta can arnptio acceso a trurnentos y rnedlos de procesarniento de palabras; pero en los anos 70, la mayo ria de las orqantzaclones creaban sus especiticactones nates con nada mas elaborado que una maquina de escribir

20, para ponerlo de otro modo, nunca hay sexo sino hasta la ultima paqina,

3 Existen diversas teorfas en cuanto a par que la redundancia resulta ser una caractertstica tan comun. En mi propia experiencia, la especifioaoion funoional servia para tres propositos en la zaoion (y p~r 10 tanto la misma informacion se presentaba de tres maneras distinlas): primero,era la d 3claraoion "oficial" de los requerimientos del usuario; segundo, era un manual extraoficial de entrenamiento, con la intencion de explicar como los "tontos" usuarios operarfan el sistema; y tercero, era una herramienta de ventas orlentada politicamente, con la intencion de fljar en las mentes de la administracion la impresion de que el sistema serfa tan maravilloso que bien valdria su oosto.

4 Tal vez uno de los mejores ejemplos de esta problema se dio en la organizacion de proceso de datos de un banco neoyorquino importante a mediados de los arios 70. Embarcado en un proyecto

CAMBIOS EN EL ANALISIS DE SISTEMAS 139

Debldo a que era tan dltlcil actualizar y reviser un do.cumen.to, la .red~n~ dancia inherente lIevaba a un problema aun peer: la mconsisten?!a. SI como es poco probable que una persona que teng~ muchos rel~Jes sepa exactamente que nora es, una especlficaclon tunciona! que r~plta tre~, 0 cuatro veces la misrna informacion es probable que tenga tntorrnacton

err6nea en diversos cases.

Eran ambiguas: el reporte detallado de los requerimientos ~odia ser .(y a menudo era) mterpretadc de diterente manera par el us~ano, el analt~ta, el dlsenador y el programador. En astudios hechos a fines de los ano~

se encontro que el 50 por clento de los errores que fmalmente ~p~re dan en un sistema operacional y el 75 par ciento del costo de su .e.II~I~~cion podian atribuirse a males entendidos 0 arrorss en la especiticacion

funcional.

Eran imposibles de msntenet: par todas .Ias razones dascritas anteriormente, la especificaci6n tuncional era cas I obsoleta pa_ra cuando lleqaba el final del proceso de desarrollo del sistema (es decir, para cua.ndo el sistema se ponia en operacicn), y a menu do er~ obsolete .para el tinal de la tase de analisis. Esto significa que la mayona d~ los slstem_as que ~e desarrollaron durante los aries 60 y 70, que ahora tlen~~ 20 anos 0 n:as de sxistir no tienen definiciones aotualizadas de las pollticas de neqocios

ue se s~pone que uevan a cabo. Y dado qu~, los analistas y usuanos ~riginales de! sistema han desaparecido, la realloa,d es que n~dle sa.be ~o que fa meyorie de los principales sistemas de computo esien haclenao

actualmente.

--------------. . "horda mongoliana" el grupo de anaJisis entrevist6 a caracteristico de desarrollo de sistema llP~ualmenle desarrollo 'una especificaci6n tipo novela vicdocenas de usuanos en todo el banco y gra soribir el documento Ie IIev6 dos sernanas aJ grupo de toriana de ~Igantescas proporcl~nes. TranonoPolizaron durante dias para poder nacer duplicados mecanografla y todas las copia: oras se mdiO una semana a 10. comunidad usuaria para leer toda la suficientes .~ara tooos los ~suanos. Se Ie . s 0 eorreceiones deseados . Un tanto para su sorpresa especljloaCI~n tunctonal e mdicar los cambio no recibieron comentario alguno de Jos usuaries p~(pero tarnbian para su gran ativio) los ~nal~sr~~congelada" la especificacion y se dio inicio al diseno ra la tecna mdlcaoa. Por 10 tanto, se ec "'. . . mbros de la comunidad anunclaron que final'! a 10. programacion. Tres semanas despues. .~els ml~, uantos e uerios cambios que

mente habian log_rado I~er toda la ~spe~lfl.c~CI?n ~'I!ld~ebn~~: ~:~:rc a la esge~fieaCion? Tras des senalar. De aqui SlgUIO un leve panico: G ~e s insultaron mutuamente a sus respectivas paacaloradas juntas en las q~~ los usuanos Y an:~!~a~e etirse en un libro como este, se Ilego a una rentelas e mtellgenclas en (ermlno~ que no IPu T p cion escrita (pues eso resultaria demasiado decision: los carnbios no se I~trodujeron en a espec~ca ra pone rio de otro modo: el equipo enear-

dillei') pero sf se incorporarlan al sistema mlsmo. ,pa . 1 .

gadO'del proyeeto encontro que era mas facil modificar el COBOL que el Ing es.

5 Vease James Martin, An Information Systems Manifesto (Englewood Cliffs, N.J.: Prentice-Hall, 1984).



Mientras se debatlan tooos estes problemas, ya se estaba un con,

junto comptementarto de ideas en el area de procrarnacton y disefio. Estas ideas normalmente conocidas como diseiio y proqremecion esttucturedos, prorneuan gran: des en la orqanlzacion, codiflcaclon, prueba y mantenlmiento de los progra.

de sf han demostrado ser utiles, aunque cad a

de procesamiento de datos han ernpezado a

se de que no tenia case escribir proqrarnas brillantes y disenar sistemas alta. mente modulares st nedie ssbi« rea/mente que era to que se suponie que et sistema

hecer. En realidad, se arournentar que el disefio y la programaci6n

estructurados les permit ian a algunos equipos de encarqados de proyectos lIegar "un dssastre mas rapidamente que antes, al construir una brillante solucion al proble· ma

Como resultado, ha habido un rnovimiento gradual (puesto que aceptarlo leha

Ilevado a la profeslon de desarrollo de sistemas alredecor de diez tendients a

hacer tunclonales que sean:

$ Gretices: de una varledad de diaqrarnas, apoyadas can material textual detallado que, en rnuchos cases, sirve de material de refe· rencia mas que como cuerpo principal de la

Perticionedes: de tal manera que se individuales de la especiftcacion.

leer

$ Mfnimamente reduntisntes: de tal rnanera que los cam bios en los requs-

rimientos del usuario normatmente en solo una parte

de la especiticacion,

Este at que per 10 general S6 conocs como analisis

utiliza ahara en la mayoria de las orqamzaclones de desarrollo de sistemas

dos a los al igual que en gran numero de las orientadas hacla la inqenle-

rta. Se pueden encontrar aun orqanizaeiones que

novela vlctonana, perc son rninorla y, como los

1,2 CAMBIOS EN El ANAUSIS ESTRliCTliRADO

el analisis tradicional de sistemas

caracteriza pOI novela ernpezo a cambiar a

los aries 70. La mayo ria de las orqantzaciones que ahora usan el analisls

rado basan su en los prirneros textos de Gane y

y otros, al igual que en serninarios, videos y otros materiales de basados en dichos libros.

Sin embargo, varios aries de experlencia practica con el analisis estructurado clasico han serialado un buen nurnero de areas en las que es necesario hacer earnbios 0 extensiones. Los princlpales cambios son:

Cada vez son mas las estructurado para

go, 81 anal isis

d ., de tiernpo real del capitulo 2.

6 Recuerde la definicion Y ejemplos e SISlemas l

. . ue [DeMarco 1978] Y [Gane y Sarson, 1977] dedlcan u,n

7 Esto tal vez sea un poco mjusto, dado que j: taci ("d'lagramas de estructura de datos 'J

~ , d datos Pero su no aClon

caottulo 0 mas a las estructuras e· d I . tasis de los primeros textos era con res-

v,, . d ' 'a mayor parte e en I I

ahora se consicera obsolete; a amas, I.. 1 de datos a la tercera forma norma, a

peeto a la convers'lon de un coniunto arbitrano 1e estruc u~:shaya meoanizado y, 2) mas bien una cual 8S 1) bastante sencilla como para que. e proceso

cuestlon de implantacion que de analisis de Sistemas.


7.3

ba 0 incluso se 10 ignoraba. Mientras tanto, mas y mas organizaciones han encontrado que sus sistemas comprenden tunclones, relaciones entre datos .Y caracte~fsticas de tlernpo real, todas elias cornplejas. Como he~os VISto, los dlagramas de trensicion de estedos se han afiadido al anaIISIS estru~t~rado para perrnltlr 81 rnodelado de sistemas en tiernpo real. Y para p~rmltlr ~I rnodetado de sistemas can relaciones cornplejas entre datos se tntroduieron los diagramas de entkied-retecton. E! heche de que las tre~. herrarniantas irnportantes puedan inteqrerse, es decir, que puedan utilizarse juntas de modo que cada una apoye a las dernas, es mas importante que el afiadir una 0 dos herramientas adicionales de rnodela. do. Los diaqrarnas de en~idad-relaci6n se exptican en et capitulo 12, y 611 eoncepto de los modelos inteqrados se trata en el capitulo 14.

EI ?:~ceso del anausts estructurado ha carnbiado ascrnbrosamente. EI ~nallsls .estructurado claslco suponia que el analista empezaria por dibuJar un diaqrama de contexte, es decir, un diaqrarna de de datos con una sola burbuja que representa a todo el sistema, y luege 10 dividirta en varias funciones y almacenos de datos, en una forma estrlctaments cen~ente: ,Por desgra~ia, esto no ha tuncionado bien, per los motives que se discutlran en el capitulo 20, En consecuencia, se ha ariadido un nuevo enfoque: conocido como division de eventos. La terminologla y el concepto basico de la division de evsntcs los introdujeron [McMenaminy Palmer, 1984] y los extendieron [Ward y Mellor, i 985].

st, SURGiMIENTO DE HERRAMIENTAS AUTOMATIZADAS DE ANAllSIS

. Cuando a finales de los aries 70 y cornienzos de los 80 se extsndleron las tee-

rucas de rnodelado qrafico del analisis sstructurado en las organizaciones de desarroll~ de .sistemas.' los anali~tas comenza~on a percatarse de que existla un gran ~rO?lema. el ~r~bal~ necesano para crear diaqramas de flujo de datos, diaqrarnas erttidad-relacion, diaqrarnas de estructura, diaqrarnas de transiclon de estados otros modelos qraficos a menudo era abrumadora, EI problema, en la rnayona lo~ cases, no era .Ia creac!o~ inicial de los diaqrarnas, sino su rsvtslon y m!e~t,o. Crear el diaqrarna inicial consume tiernpo, perc par 10 rnenos exists la f~~clon de qu.e es una actividad intelectual creative y desatiante. En un nrr"",',l"'''' t~PICO, el analista sncuentra que tiene que volver a dlbujar los modelos qraficos nas vsces antes de que el y los usuaries puedan lIegar a alqun acuerdo sabre los querimlentos del sisterna.f

E~ un sisten:a muy grande puede haber 50, 100 0 mas diaqrarnas de flujo datos, dlversos diaqrarnas de entidad-relaclon y, potencial mente, varies diaqrarnas

8 Esto pudiera no serl,e evidente aun, pues s610 hemos visto unos cuantos diagramas de analisi$ es~ructurado en el capitulo 4. Sin embargo, para el final de la parte II debiera ser abundantemenlo eVldenle; Sl no, espere aver el final de su primer proyecto "real" de anal isis estructurado.


de transicion de estados; as! que la cantidad de traba]o manual puede ser en verdad intimidante. La consecuencia practica de esto, en rnuchas es que el estructurado clasico no fue tan exitoso como dsbiera ser. Se plantearon los siguientes problemas:

@ Tras la secunda y tercera correcionss de un diaqrama, el analista se velvia cada vez mas opuesto y renuente a hacer mas carnbios. Par ello, se pod Ian encontrar dlaqrarnas "conqelados" que no retlejaban los verdadsres requerimientos del usuario.

® Debido a la cantidad de traba]o requerido, el analista dejaba a veces de dividir el modelo del sistema en rnodelos de rnenor nivel: es decir, en lugar de desarrollar un modelo que consistiera por en cinco nivetes de diagramas de Ilu]o, se detenia en el cuarto nivel. EI modele resuttante contenla funciones "primitivas" (esto es, las burbujas que S8 muestran en el cuarto que no eran prirnitivas en 10 mas mfnirno; de heche, resultaban ser tan cornplejas que el proqrarnador tenia la necssidad de llevar a cabo un analisis adicional del sistema antes de que pudiefa escribir proqramas.?

@ A rnenudo no se incorporaban en el modelo del sistema los carnbios en los requerimientos del usuario sino hasta oespues de la tase de analisis del proyecto. Muchos de estes cam bios se daban durante las tases de disefio, proqrarnacion y prueba; otros se daban despues de implantado el sistema. EI resultado era una especificacion obsolete.

Adernas del traba]o que se necesita para crear y mantsner los diaqrarnas, el analisls sstructurado clasico requiere de una gran cantidad de traba]o para veriticer

los diaqrarnas con el fin de asequrar sean consistentes y esten completes: estas

reg las se discuten en el capitulo 1 Durante los aries 70 y la mayor parte de los

80, los analistas tuvieron que de tecnicas de verificacion manual (es decir,

inspeccionar visualmente los diaqramas para encontrar errores), Debido a que esta labor es detallada y aburtida, tiende a estar plaqada de errores. En consecuencia, no se encontraban rnuchos de los errores de especificacion que S6 debieran haber snccntrado.

9 Como se vera en el capitulo 11, debiera haber una especlficacfon del proceso (normalmente escrita como labia de decisiones, diagrema de flujo 0 en un formato estructurado en espafiol) para cada burbuja primitive de ultimo nivel del diagrama de flujo de datos. Si el sistema se ha dividido correctarnente, la rnaycrla de las especificaciones de proceso deberian ser de menos de una pagina.

10 Ejemplos de reg las de verificaci6n: todos los flujos de datos en un diagrama de flujo de datos deben tener nornbrs, y los nombres deben estar definidos en el diccionario de datos. Todos los nombres en el diccionario de datos deben corresponder con flujos de datos 0 almacenes en el diagrama. Cada burbuja en el diagrama debe tener por 10 menos un flujo de datos que entra y uno que sale, etcetera.


Muchos de estes problemas se pueden resolver con apoyo automatizado ade. cuado. Esto era bien conocido aun desde que par vez se el anal iSis estructurado perc el coste deIa autornatizacion estaba por snclma de las

posibilidades economlcas de la rnayorla de las Sin embargo, el de,

sarrollo de podsrosas estaciones de trabajo a rnediados de los anos 80 Ilevo

a una nueva industria lIamada CASE (stqlas que significan Computer-Aided <.:"",,,~,

de software auxiliada per Varies proveedors,

otrscen productos basados en que dibujan diaqrarnas de flujo de

datos y otros, adernas de llevar a cabo una varied ad de labores de revislon de

res. Las y de estas herramientas se presentan en el ap€mdi.

ce A.

Como se mencion6 anteriormente, solo el 2 por cisnto de los analistas de sis. ternas en los Estados Unidos tentan acceso a estas herramientas en i 987, Y ss estima que s610 el 10 por ciento 10 lend ran en 1990. Sin embargo, este as in· dlscutiblernente el camino del y podernos esperar que todos los analistas protesionales mststiran en tales herrarnlentas al transcurrir el Esto lIevara primordial mente a un nivel mas elevado de caudad en los modelos de sistemas producidos. de rnansra llevara a modelos grrificos del sistema vi· sualrnente mas atractivos. En la medida en que los conceptos de revision de errores que se en 131 capitulo 14 sean pod ran eliminar la necesidad de que los analistas aprendan el material del capitulo i 4. Y en la medida en que las herramientas CASE cornlencen a general' proqrarnas Pascal, o tal vez en un lenqua]e de cuarta directemenie desde las especificacienes, tarnbien incluso se reducira la necesidad de proqramadores.

1,4 El USO DE PROrOTIPOS

Como se serialo en el 3, algunos usuaries ttenen ditlcultades al tratar

con los modelos qraficos del analisis sstructurado y prefieren alguna otra forma de modetar los requerirnientos y cornportamtento del Las herrarnientas de gEineracion de prototipos, que ernpezaron a ser muy accesibles a mediados los afios 80, se han considerado como una alternatlva al anal isis usuarios.

otra razon de la popularidad de los prototipos: en rnuchas orqanizaclo nes se considera que el analisis estructurado clasico consume dernasiado tiernpo;

para cuando la lase de anal isis, el usuario habra olvidado para que

en un el sistema. Esto suele ser resultado de alquno de los

blernas:

®

EI equipo encarqado del proyecto tarde dernasiado en desarrohar modelos del sistema actual y se tuvo que tardar aun mas modelandc.el nuevo. Como se menctono anteriormente, ahora considerarnos el modelado del sistema actual como una actividad pouticamente peligrosa.


® La orqanlzacion lnvirtlo poco 0 nada de tiampo, en hacer

anal isis, pues prefirio codificar 10 antes En tal arnbiente, el

traba]o de analisis, que no produce nada tuera de rnuchas

trnaqenes con circulos y rectanqulos, pudiera

® Los prirneros proyectos que se han realizado utilizando el analisis estructuraoo pudieran consurnir mas tiernpo de 10 normal, los analistas estan aprendiendo nuevas tecnicas y discutiendo respecto a 113. forma de aplicar dichas tecnicas.

Las nerramientas de de prototipos (herramientas de software que

al anausta construir un slmulacro del sistema) se ven, per como una

soluci6n etectiva a estes problemas. Notese tambien que el uso de tiende

a concentrarse en el aspsctc de la intertaz humans en los de desarrollo de

sistemas.

Desafortunadamente, las herrarnientas de de a veces se

utilizan para evitar los detatles del analisis y de! disefio. En la sscclon 5.6 se mostr6

un usc de prototipos.

7,5

El

Como se menciono anteriorrnente en este capitulo, las en la irrqenie-

ria de software comenzaron con la proqramacion y el disefio estructurados. De hecho, estes des ternas estuvleron sujetos a un considerable debate en las

de desarrollo de sistemas durante la rnitad de los arios 70.

Tambien tue durante este textos sa-

bre sstructurado [Myers, 1 y [Yourdon y 1975]} Los

libros no hacian reterencla al analisis astructurado (puesto que aun no se

habian desarroliado los rmantras que libros posteriores, como

nes, 1 tncluian una breve resena del tema. EI traba]o en analisis sstructurado cornenzo a mediados de los 70 y los primeros textos ernpezaron a aparecer a fines de esa pero bebi« poce 0 no habra conexion entre el discutso de! ana/isis estructuredo y el del oteetio estructuredo. EI principal problema era que el analisis

estructurado trataba con la de sistemas grandes y complejos, mien-

tras que ei disefio estructurado ser mas para el diseno de proqra-

mas individuates que se ejecutaban en una rnisrna cornputadora. EI entre 191 analisis del sistema y 191 diseno de los proqramas, es hacta talta 191 aiseno de sistemas.

Este problema 10 han tratado muchos consultores, autores y orqanizaciones de

desarrollo de sistemas durante los aries 80< Libros recientes, como el de y

Mellor, i 985], aSI como las ediciones nuevas de 1 Y Y

i 989], tratan ahora puntos del disefio de sistemas al igual que de pro-

146 CAM BIOS EN EL ANALISIS DE SISTEMAS

7.6

RESUMEN

Como cualquler campo de la ciencia 0 la lnqenlerfa, el analisis de sistemas ha pasado por una serie de carnbios evolucionarios durante los ultirnos 20 afios, Como se indico al cornienzo de este capitulo, es importante saber cuales han side estes cambios porque la industria de la computacton es 10 suticientemente amplia como para que no todo rnundo practique las rnisrnas tecnicas at mismo tiernpo. La orqaru. zacion de usted pudiera estar a la vanguardia de la tecnologfa 0 al triste final de la cola.

Se pusde esperar que el campo del analisis de sistemas continue. Las tecnicas que se pressntan en sste libro habran evolucionado aun mas en en los proxlmos cinco a diez arias. En el capitulo 25 se aborda la probable naturaleza de dichos earnbios evolucionarios.

REFERENCIAS

t. Tom DeMarco, Structured Analysis and System Specification. Nueva York:

YOURDON Press, i 978.

2. Chris Gans y Trish Sarson, Structured Systems Ana/ysis and Design. Nueva York: Improved Systems Technologies, lnc., 1977.

3. Victor Weinberg, Structured Analysis. Nueva York: YOURDON

1978.

4. Paul Ward y Steve Mellor, Structured Development for Real- Time Systems.

Volurnenes 1-3. Nueva York: YOURDON 1985.

5.

Steve McMenamin y John Palmer, Essential Systems Analysis. Nueva York:

YOURDON 1984.

6.

Glen Myers, Reliable Systems through Composite Design, 1 g sdtclon. Nueva York: Petrocelli/ Charter, 1975.

7. Edward Yourdon y Larry Constantine, Structured Design, 1 g edicion.

York: YOURDON Press, 1975.

8. Meitir The Practical Guide to Structured Systems Design, 1 i! edicion, Nueva York: YOURDON Press, 1980.

9. Meilir Page-Jones, The practical Guide to Structured Systems Design, 29 Englewood Cliffs, N.J.: Prentice-Hall, 1988.

10. Edward Yourdon y Larry Constantine, Structured Design, 2§ edicion, Englewood Cliffs, N.J.: Prentice-Hall, 1989.

CAM BIOS EN EL ANALISIS DE SISTEMAS 147

1 .

V EJERCICiOS

son las tres principales razones por las cuales debe sstar familiarizado con 113 svolucion del anal isis de sistemas?

. Que cree que deba hacer si la orqanlzacion para la que traba]a no ha Ilevado c 't I ?

a cabo los carnbios que se sxponen en este capnu o.

Mencione cuatro problemas irnportantes de una especificacion narrativa clast-

2.

3.

4.

ca.

i Por que no es deseable 113 rsdundancia en una especificac.i?n d.~ s~stemas? ~ES pcsible eliminar por complete ta redundancia de la ospecificaclon .

.!"Se le ocurre alguna razon per 113 cual serla util la rsdundancia en la especificacion de un sistema?

. Cuaies son las tres prlnclpales razones por las que aparace redundancia en ~na especificacion clasica?

poroantaje de errores en un Sistema, ?peracional pue~en atribuirse a errores que ocurrieron durante la fase de analisis del proyecto.

Proyecto de investigaci6n: .!"Que porcenta]e de errores pue?e .atribuirse en s~ organizacion a errores que ocurrleron durante 113 tase de anal ISIS del proyecto.

.!"CuaJes son las consecuencias de una especificacion imposlble de rnantener? Describa breve mente la proqrarnacion estructurada.

Describa brevemente el disefio sstructurado

que algunas organizaciones no tuvieron ex ito al utilizar la programaci6n y el disefio astructurados?

son las tres principales caractertsticas de una especificacion estructu-

5.

6.

7.

8.

9. 10.

11 .

12.

13.

rada?

14. LCuales son los cinco principales cam bios que se han dado en el anal isis estructurado clasico?

15.

problemas sntrenta el anal isis sstructuraoo clasico cuando trata can sistemas de tiampo real?

. Cuales son los peligros asociados con modelar el sistema actual del usuario? c . d di t ?

.!"Cuanto tlempo se debiera e rear a es o.

.!"Cuales son los tres pnncipales problemas a los que es proba~le que el anaIista se anfrente si no tiene apoyo autornatizado para su trabajo

16.

17.

148 CAMBIOS EN a, ANALISIS DE SISTEMAS

18. contar can apoyo automatlzade para proyectos

desarrollo de sistemas de informacion? loPor sf 0 por no?

19. G Que problemas es probable encontrar sl el analista tiene que llevar a cabo la revlsicn de errores>

20

LPor que cree que tan s610 el 2 por ciento de los analistas de sistemas de los Unidos ten fan estaciones de trabajo automatizadas de ami/isis de Sis. ternas en 198??

21.

beneficios adicionales podernos esperar al introducir una red

rnientas automatizadas de analisis de sistemas? (Per uno

es 81 corrao electroruco.)

22. L,Cwiles son los tres problemas que han surgido en las organiza-

clones al el analisis estructurado clasico?

herra· estos

23. problemas de intertaz exisnan entre el analisis estructurado y 191 diseno

estructurado en los arios 70 Y de los 80?

de

PAR

E II: LAS HERRAMIENTAS DE MODELADO

--,-----------------------

Cualquier cosa es facil si puede asimiiaria a su colecci6n de modelos Seymour Papert, Mlndstorms

10

En

ayudan las a rnodelar

149

,50 CARACTERISTICAS DE LAS HERRAMIENTAS

Los siguientes capitulos de este libro descnben las djversas herramientas de ~odelado que usted usara como analista. Antes de ahondar en los detalles de los diaqrarnas de de datos, de entidad-relacion, etc, existen puntos intro, ductorios que necesitamos repasar,

. Se recoroara del capitulo 4 que un modelo es un simulacro a bajo costo de un

sistema que se desea estudiar. Se construyen modelos de sistemas POr

tres motives:

I. Para entocar caractertsticas importantes del sistema, a la vez que para rnirumizar las caracteristicas menos impcrtantes.

2. Para discutir cam bios y correcciones a los requerfmlentos del usuarto, a

bajo costo y con mtnimo.

3. Para verificar que se entienda el ambients del usuario, y que se ha docornentado de tal rnanera que los disefiadores y programadores puedan construir el sistema.

Sin embargo existsn muchos tlpos diterentes de modelos que S8 pueden construir para el usuarlo: modelos narratives, rnodetos de prototlpos, modelos graficos di, versos, etc. De hecho, 131 sistema final que se Ie construira al usuario pudiera resultar ser un modele, en el sentido de que puede representar, per prtrnera vez, una manera de que el usuario visualice 10 que desea.

. En este libro n~s concsntramos en los modelos en pape/ (0 en rnodetos en pa-

pel producidos por sistemas CASE automatizados), Pero, nuevamente, existe una gran variedad. Como se apreciara con mas detalle en los siguientes capltulos, existen dlagramas de flujo, diagramas HI tablas de decision, diagramas de flujo de datos, diagramas de de sistemas, diaqrarnas de transicion de estados, arboles de decisiones, diagramas de entidad-relaclon, diagramas de dtaorarnas de H~milton-Zeldin, diagramas PAD y una interminable serie de dlaqramas, tablas y graficas que se le pueden presenter al usuario. (_,Cual debernos usar?

. La . b~sica de este libra es que debe usarse cueiquier modelo que fun-

clone en 113 situacion en 113 que se encuentra. Los diferentos usuaries pudieran requerir distintas herrarnientas de rnodelado, sea por su experiencia pasada 0 porque crertos tipos de ~Ia~ramas los contunden 0 intlmldan." Diferentss proyectos pudieran requenr de distlntas herramientas para cumplir con los estandarss de docurnentacion impuestos por organizaciones externas. Y diferentes de sistemas

-------------

1 Un corolario de esto es que las buenas herramientas de modelado suelen emplear una notaclon sencilla, con pocas reglas, simboios y vocabulario nuevo que el usuario tenga que aprender. Un pU,nsta pudiera argumentar Incluso que una buena herramienta no requiere explicacion ni preparaCion. De cualquier modo, no deberfa ser necesario leer un libra de 700 paqinas como este para poder aprender a leer y entender un modele desarrollado par el analista.

CARACTERISTICAS DE LAS HERRAMIENTAS 151

udieran requerir de model os diversos para poder destacar adecuadaments caracte~sticas tmportantes.

Para llevar mas lejos esto, la mayoria de los sistemas requieren de multiples modelos: cada modelo se entoca a un nurnero limitado de aspectos del sistema, a la vez que mlnimiza (0 ignora totalmente) otros de sus aspectos. Esto se da sob~e todo en muchos de los sistemas que se estan eonstruyendo actualm~nte, pues t.lenen caracteristicas funcionales cornplejas, estructuras de datos cornplejas, y consideraciones complejas de iiempos.

Cualquier herramianta que use debtera tener las slquientes caractertsticas:

.. Debe ser qrafica, can detalles textuales de apoyo apropiados.

.. Debe perrnitir que 131 sistema sea visto en seqmentos, en forma descendents.

.. Debe tener redundancia minima.

.. Debe ayudar al lector a predecir 131 cornportamiento del sistema.

.. Debe ser transparente para 61 lector.

A continuacion discutirernos con mas detalle cada uno de estes puntos,

1:1.1 MODElOS GRAFICOS

La mayo ria de los modelos populares de sistemas, y todos los que se presentan en este libra, se apoyan rnucho en qratlcas, No es requisite usar qraficas en un modele de sistemas, pero el viejo adagio de que "una imagen vale mas que mil palabras" es una buena explicacion de nuestra preterencia por las graficas en luqar de texto narrative. Una imagen bien escoqida puede transmitir de rnanera concisa y compacta una gran cantidad de informacion.

Esto no significa necesariarnente que una imagen pueda describir todo 10 reterente a un Sistema; hacerlo norrnalmente siqruficarta tener un desorden que nadie qulsiera mirar. En general, se utilizan los qratlccs para identificar los componentes de un sistema y su intertez. Todos los demas detalles (esto es, las respuestas a prequntas tales como "l,CuantosT y "(_,En que orden?", etc.) se presentan en documentos textualss de apoyo, Los textos de apoyo que se describen en esle libra son la especiticecion del proceso y el diccionsrio de datos.

Esto no siqnifica que todos los analistas deban usar el conjunto particular de nerramlentas qratrcas y de textos que se presentan en este libro: 81 Gran Analista de Sistemas que esta en el cielo no 10 fulminara con sus raves sl no utiliza diagramas de flujo de datos. Sin embargo, es probable que 10 fulmine el rave si opta por uno de los extremes de unicemenie graiicos (sin textos de apoyo) 0 de solo texto (sin material grafico). Y sequrarnente Ie tocarla aunque sea un pequerio relarnpaqo si hiciera

,52 CARACTERISTICAS DE LAS HERRAMIENTAS

que 191 texto fuera ta parte dominante del modele, y que los graficos tuvieran un papel pequefio y subordtnado. Uno 0 mas qraticos debieran ser 191 documento al que se dirige el usuario para poder entender 61 sistema; los documentos textuals, debieran servir de material de referenda para consults en case de necesidad.

802 MODElOS SEGMENTABlES EN FORMA DESCENDENTE

Un segundo aspecto importante de una buena herrarnienta de modelado essu capacidad de mostrar un sistema por partes en forma descendents. Esto no es im· portante para sistemas psquefios, pues de ellos se puede decir todo 10 necesario en una ados paqinas, y cualquiera que necesite conocer alqun aspecto del sistema bien puede conocerlo en su totalidad.

Sin embargo, los proysctos reales en el rnundo real qeneralmente no son pequenos.f De heche, rnuchos de los proyectos en los que es probable que se involuere ssran desde medlanos hasta enorrnes. En consecuencia, sera imposible que alquien, sea usuario, analista 0 proqramador, se entoque a toco el sistema at misrno tiernpo. Tampoco sera posible presenter un modelo grafico de un sistema grande y complejo en una sola hoja de papel, a monos, claro, que se considers el extreme de tsner una microficha de 2 x 3 metros. Por eso, nuestras herrarnientas deben permttlrnos rnostrar individuales del sistema de manera independiente, junto con

una forma sencitte de moverse de una a otre de! modele de! sistema.

Sin embargo, se neceslta mas que esto: no seria apropiado, por crear

un modelo grafico enorme de 30 x 30 metros y luego conaria en pedazos indi·

vidualss de media metro cuadrado, con miles de conectores de a hoja,

equlvaldria, a grandes rasqos, a un mapa de las callas de todo un pais en

una sola hoja y luego en miles de pedacitos del tamario de una paqtna,

De heche, nuestra con rnapas y atlas Ilustra como debe orqanlzar-

se un modele de un sistema complejo. Por ejemplo, un atlas de los Estados Unides

por un solo diagrama de una de todo el como

rnuestra en la figura 8.1. Dicha paqina muestra los estados individuates, y

tarnbien mostrar las interfaces entre los estados int

Iineas de terrocarrll, rutas Las se dedi

normal mente a cad a estado individual, en conde cada paqina muestra las ciudad

condados individuates del al igual que las locales que no

cen en el mapa de nivel nacional. Podriamos imaginar rnapas de nivel rnenor

2 0, dicho de otro modo, los usuaries estan desarrollando cada vez mas proyectos "pequefios" nacesidad de analistas 0 programadores. Con el gran acceso a computadoras personates,

tes de hojas de calculo y Jenguajes de cuarta generacion, muchos trabajos que hubieran raquerido dfas (0 incluso semanas) de dedicacion de un profesional de las computadoras el usuario puede hacerlos actualmente en cuesti6n de minutes 0 de horas. Sin embargo, aun ccntinuan desarrollahdose muchos sistemas que requteren de mas de 10 mil/ones de instrucciones para lIevar a cabosu proposito.


. narian detalles de cada con dado de cad a ciudad centro de un condado de-

proporclo ' .

·nado Y de cada barrio dentro de una ciudad dada.

terml ,

Figura 8.1: Mapa de Estados Unidos

154 CARACTERISTICAS DE LAS HERRAMIENTAS

l,Por que lmporta esto a quien construye un modele? Slmplemente, porqus es deseable mentenetio en forma actualizada y precise. Si el sistema cambia, enton. ces debe carnbiar el modele, sl ha de tenerse actualizado. Obviamente, si solo carn. bia un aspecto local del sistema, preterlrlarnos carnbiar solo un aspecto lOcal correspondlente del modele, sin tener por fuerza que cambiar alqun otro. De hecho si se requieren multiples cambios, exists una buena probabilldad de que no se ha: qan 0 de que se haran desordenadamente, Y esto siqnifica que el modelo se volve. ra gradualmente menos precise.

Para itustrar esto, considere nuevamente nuestro ejernplo del atlas de los Es. tados Unidos . Podernos irnaqinar, en el case mas simple, una paqina que muestre todo el pais, y 50 paqmas slquientes que rnuastren los detalles de cada estado, Ahora, imagine sucederia si desapareciera el estado de Nueva Jersey:3 el mapa de nivel nacional tendrla que volver a dlbujarse para rnostrar el nuevo pais de 49 esta. dos, y el anterior mapa de nivel estatal de Nueva Jersey tendrla que descartarse.

Sin embargo serla un poco mas ditlcll can los atlas de verdad, pues, como es caracterlstlco de rnuchos modelos de Sistemas, existe alquna redundancia. Cada mapa de nivel estatal muestra no solo el estado que se describe sino tarnbien parte de los que tienen trontera con el. Esta informacion se tiene en el mapa de nlvelna. clonal, perc es uti] en el nivei estatal tambien. Esto signitica que si desapareclsrs Nueva Jersey, probablemente tendrtarnos que redibujar los mapas de Nueva York y Pennsylvania, e incluso tal vez Delaware y Maryland. Que rnolestia.

Los cartoqratos proteslonales pudieran objetar esto y argumentar que se necesita una cierta cantidad de redundancia para hacer el atlas facil de leer, Pero deberia ser evidents que cuanto mas redundante sea el modelo mas diflcll sera de rnantener. Imagine, por ejemplo, que nuestro atlas rnltico muestra las autopistas interestatalss en el mapa nacional y en todos los mapas de nivel estatal. Imagine tarnbien que algun emprendedor fabricante de mapas ha decidido rnostrar la longitud complete de cad a autopista interestatal en cede mapa estetel que etreviese. De as· ta forma, la carretera intersstatal 95, que va de Maine a Florida, apareceria en alrededor de una docena de estados, y en cada uno se escrlbirta el heche (redundante) de que la autopista mide 2,700 kilometros. Y l,ahora que sucede si descubrimos que esta citra estaba equivocada 0 que parte de la autopista se extendio 0 se desvio de ruta? Obviarnente, se tendrian que rnodificar una docena de mapas estatales.

8.4

MODELOSTRANSPARENTES

Finalrnente, un buen modelo debe ser tan facil de leer que el lector no tenga que detenerse a pensar siquiera que se trata de la representecion de un sistema y no del sistema rnismo. Esto no siernpre es taclt de lograr y a menudo requiere de practice y preparacion por parte del lector, Piense por ejemplo en un mapa: .:.que tan

3 Si vivi6 en Nueva Jersey 0 liene alguna otra conexi6n patol6gica con esla estado, sientase libre de usar cualquier otro para este ejemplo. Mis disculpas a Bruce Springsteen.


a menudo se pone a pensar en que esta mirando una rspresentaclon abstracta d_el

stado de Nueva Jersey y no la realidad mlsrna? Por otro lado, observe a un nmo e e ueno que sste viendo un mapa mientras sus padres 0 su maestro prstenden exp.q I que 61 estado de Nueva Jersey tlene trontera con el estado de Nueva York y plica: 6 . Y k "N ' to"

Newark esla a quince kttornetros de la ciudad de Nueva or, 0, no es cier 0 ,

~~r: el nino, "Newark esta a dos centimetres de t'lueva York".

AI crecer, nos tamrltarizamos cad a vez mas con el concepto de las re~res~.nta-

. es abstractas, siempre que nos perezcen comodes menta/mente. Los cientificos ~I~~ estudiado el comportamiento y la orqanizacion del cerebro. humane y h~,n encontrado que 61 hemisterlo izquierdo realiza los procesos sec.uenclales. Tarnbien se hace cargo de los textos: per sjernpto, las palabras ~u~ esla leyendo, una tr~s otra, ~n

t agina. EI hemisferio derecho trata can las irnaqenes y el procasamiento asrn-

es a P don de "todo sucede a la vez", Esto indica que si estamos tratando de modeI algo que es intrinsecamente lineal y secuenciat, como el tlu]o de control en un ar ama de cornputadora, debemos usar una herramienta de modelado textual que

progr 'I· ioad t

pa Comodamente en el hemisterio izquierdo, que sera et rnejor equipa 0 para ra-

que . , ttidlmensi

I Y si estamos tratando de modelar algo que es Intrmsecamente mu I ImenSIO-

tar o. , . t

nal, con muchas actividades que se dan a la vez, debemos usar una nerramien a

8,5 RESUMEN

Sin duda estara tan ocupado aprendiendo las harrarnientas de modelado que se presentan en este libro que no pensara en la posibilidad .de otras. Sin embargo,

si sxlsten, y en el 15 axaminaremos brsvemente vanas otras.

Mas como analista se vera ante una variedad de herrarnientas

de modelado en del rnundo real. los detalles (y de sstas

herramientas varian rnucho, can cuidado sl los basicos

que se en este

PREGUi\ITAS Y EJERC!C!OS

1.

son las tres principales razones por las que se hacen rnodelos de un

sistema?

2.

Describa tres

diferantes de modelos de sistemas.

son las earacteristicas prlncipales que debe tener una herramienta de rnodelado de un sistema?

3.

que se prefieren

las herramientas qraficas a las tsxtuales?

4,

5.

LEs necesario usaf herramientas de modelado grafico para desarrol!ar un sis~ lema de informacion? Is ocurren situaciones donde no usar dlchas herramientas?

156 CARACTERISTICAS DE LAS HERRAMIENTAS

6.

"Que cosas normalmente no rnuestran los modelos gnHicos acerca de un si

tema? IS·

7.

G Por que es irnportants que una herrarnienta de rnodetado rnuestre 61 slstern

de manera descendents? l,Existen situactones donde no importe? a

G Hequiere la aescripcion descendents de un sistema que este se disefia d

manera descendents? e

Describa una situacion en la que debiera ser aceptable incluir redundancta e

et modele del sistema. n

8.

9.

La forma slernpre sigue a la funci6n.

Louis Henri Sullivan "EI gran edificio de oficinas, considerado artistlcamente", Lippincott's Magazine, marzo de i 896

En este capitulo se aprendera:

datos.

un diaqrama de

1.

cornpcnentes

En este capitulo explorarernos una de las tres herramientas gnificas de modelado mas importantes del analisis estructuraco: el diagrama de de datos. Esta as una herrarnienta que permits visualizar un sistema como una red de procesos tuncionales, conectados entre sf por "conductos" y "tanques de almacenarniento" de datos. En la literatura computacional, y en sus conversaciones con otros analistas y usuaries, puede utilizar cualquiera de los siqulentes terrninos como slnonimos de

de de datos:

dibujar un diaqrama

de

3. fa para

datos.

4. Como volver a dibujar diaqramas niveiedos flujo

diaqrarnas eficaces

de

157

158 DIAGRAMAS DE FLUJO DE DATOS

..

Carta de burbujas

DFD (Abreviatura que se usara en todo este libra) Diagrama de burbujas

Modelo de proceso

Diagrama de flujo de traba]o

Modelo de funcion

"

" "una imagen de 10 que esta sucediendo aquf"

EI diagrama de flujo de datos es una de las herrarnlentas mas comunmente usadas, sobre todo por sistemas operaclonalss en los cualss tes funciones del sistema son de gra~. importancia y son mas complsjas que los datos que este maneja. Los DFD se utilizaron por pnmera vez en la inqenleria de software como notacion ~ara 61 estudio del diserio de sistemas (par ejemplo, en los librcs y articulos de diseno ~structurado tales como [Stevens, Myers y Constantine, 1974], [Yourdon y Constan,tme, 1975],. [Myers, 1975], y otros). A su vez, la notacion se tome prestada de a:tlCulos anterioras sobre teorta de gnHicas, y continua siendo utilizada por los ingemeres de software que trabajan en la implantacton directa de modelos de los requerimientos del usuario.

, Estes son antecedentes int~resantes, pero con toda probabilidad no seran muy i elevantes para los usuanos a quienes usted mostrara los modelos de DFD del sistsm~; .de hecho, probable mente 10 pear que pueda usted hacer sea "Sr. Usuario, qursiera mostrarle un modelo grafico-teorico descendents y par partes de su sistema". En reahdad, rnuchos usuaries estaran con el concepto basico de OFD, pues la rrusrna notacion ha sido empleada per investiqadoras de d.urante los uttirnos 70 arios para construir modelos de de de orqanizaclones. E~ impcrtants tenor esto en mente: los OFD no s610 se puecen utilizar para

modolar sistemas de sistemas de proceso de sino tarnbien como mane-

ra de ,modelar ,organizaciones es como una para la pla-

neacron estrateqica y de negocios.

nuestro estudio de los DFO examinando los de un

?ia~rama tipico de tlujo de datos: el proceso, el €II almacsn y el terminador.

Utitizarernos una notacion bastante siquiendo los textos ctasicos de

co, 1978J, Y 1977], Y otros. Sin embargo, tarnbien incluirernos la

tacion de OFD para modelar sistemas de tiernpo real (es decir, flujos de control procesos .de Esta notacion acicional no se ocupa en los sistemas diriqidos a los negocios, perc es crucial cuando se modela una variedad de sistemas cientificos y de inqenterta,

DIAGRAMAS DE FLUJO DE DATOS 159

En seguida, revisarernos algunas de las guias de elaboraclon de diaqramas de

flujo de datos para minirmzar las posibilidades de construir un DFD. inco-

60tO 0 inconsistente. Flnatrnente, discutirernos 61 concepto de DFO niveledo como

rr . I .

metodo de rnodelar sistemas cornp ejos.

Tenga en mente que 191 OFD es tan s610 una de las herramientas de model ado d'sponibles Y que unicarnente proporciona un punto de vista de un sistema, el orient~dO a las funciones, Si se esta desarrollando un sistema en ~onde la~ relacion~s entre datos son mas importantes que las funciones, tal vez se de menos lI~po~ancla al DFD (0 lncluso ni nos molestemos en elaborarlo), para concentrarse mas bien en desarrollar un conjunto de diagramas de entidad-relacion, como se expone en el ca- 12. De otra manera, si el comportamiento dependiente del tiernpo de un siste-

ma domina sobre cualquier otro tal vez nos concentrernos mas en el diagrama

de transici6n de estados que se discute en el capitulo 13.

9.1 LOS COMPONENlES DE UN DFD

La figura 9. i rnuestra un DFD tipico para un sistema minar sus componentes en detalle, notese 10 siguiente:

@ Practicarnente no requiere explicacion; se puede simplemente mirar el diagrama y entsnderto. La notacion es seneilla y clara y, en cierto sentido, intuitivarnente obvia. Esto es particularmente irnportante cuando recordarnos quien se supone que esta viendo la 9. i: no el analista, sino el usuario, Si el usuano necesita una enciclopedia para leer y antender el modele de su sistema, probablemente no se tamara la moles-

tia de hacer de las des casas.

Antes de exa-

'" EI diaqrama cabe tacilmente en una Esto dos cosas: 1)

puede rnirarlo sin of us carse y 2) el sistema que se esta rnodelan-

do no es rnuy se hace sl €II sistema es intrtnsecamente

tanto -por ejemplo- que hubiera literalmente cientos de circu-

los y uneas en 81 Discutirernos esto en la seccion 9.4.

.. EI se dibujo con computadora. Nada tiene de malo un diaqrarna heche a mana, pero la 9.1 y muchos de los otros DFD que se

muestran en ests libro se hicieron con la de un proorama de la Ma-

cintosh llarnado MacDraw. Esto que el diagrama

se hara de manera mas ordenada y estandar que 10 que en

a mane. Tarnbien que se hacer cambios y pro-

ducir nuevas versiones en cuestion de rninutos.t

1 Sin embargo, la desventaja de MacDravll (y de otros prcqramas genericos per el estilo) es que no sabe nada de la naturaleza especial de los DFD 0 de otros modelos de sistemas que se presentan en este libro. S610 rnane]a figuras primitivas como rectanqulos, circulos y Ifneas. Los paquetes de herramienlas para analistas que se discuten en el Apsndice A son mas poderosos, pues manejan mucho acerca de DFD,


Pedidos cancelados

CLiENTES

PEDIDOS

Contabilidad

Detalles del pedido

\

Detalles

InlormaCi6~ / de cuentai

Contabilidad

Nombre del cliente, detalles de la factura

cobros, indagaciones

Figura 9. 1; DFD tfplco

9.1.1 1:1 procesc

EI primer cornponente del OFO se conoce como proceso. Los sinonimos comunes son burbuie, iuncion 0 trenstormecion. Ei proceso rnuestra una parte del

que transtorrna entradas en salidas: es decir, muestra como es que una 0 entradas se transtorrnan en salidas. EI proceso se represents qraflcamente

circulo, como se rnuestra en la figura 9.2(a). Algunos analistas usar

ovalo 0 un rectanqulo con esquinas radondeadas. como se rnuestra en la 9.2(b); y otros prefieran usar un rectanqulo, como se rnuestra en la figura Las diterencias entre estas tres tormas son purarnente cosmeticas, aunque

mente es lrnportante usar la rnisrna forma de rnanera consistente para '~~Ad",

todas las funciones de un sistema. A 10 largo de este libro utilizarernos el burbuja-'

2 La figura que 81 analista utilice para el proceso a menudo ee asocia con una "escuela" particular de analisis estructurado. EI circulo se asocia con la "escuela Yourdon/DeMarco", pues se uliliz;;ten varies textos publicados por YOURDON Press, 10 rnismo que en las actividades de consuna.r adiestramiento de YOURDON Inc. De manera similar, el ovalo se asocia a menudo con la "escuela Gane/Sarson", pues 10 introdujeron Chris Gane y Trish Sarson en su libra [Gane y Sarson, 1977], Y


CALCUlAR DE VENTAS

Figura 9.2(a): Ejemp!o de un proceso

AlCUlAR PUESTOS

I DE VENTAS

Figura 9.2(b): Representacion alternatlva de un proceso

CALCUlAR iMPUESTOS DE VENTAS

9.2(c): Una representacton mas de un proceso

Notese que el proceso se nornbra 0 describe can una sola palabra, frase u oracion sencilla. En casi todos los OFO que se discutiran en este libra, el nornbre del proceso descrlbira to que tiece. En ta seccion 9.2 hablaremos mas ace rca de la nomenclatura correcta para burbujas de proceso. Par ahara es suficiente decir que un buan nornbre general mente consiste en una trass vsrbo-objeto tal como VAUDAR ENTRADA 0 CALCUlAR !MPUESTO.

fue usado por McDonnell Douglas Automation Company (McAulo) y vartas organizaciones mas. La figura rectangular suele asociarse con la escuela "SADT", puss la popularizaron diversos articulos acerca de la tecnica de Softech para Dlseno y Analisis Estructurado (SADT); vease, por ejemplo, [Ross y Schoman, 1977].

162 DIAGRAMAS DE FlUJO DE DATOS

.En algunos casos, 61 proceso co~t~~?ra el nornbre d~ un~ persona 0 un grupo (por ejernplo, un departa~~nto ° una dl.vlslon de una orqanizacion), 0 de una compu_ tad?ra 0 un aparato ,mecamco. ~s .declr, el proceso a veces describe quien 0 qw§ 10 esta etectuando, mas que describir el proceso mismo. Discutirernos esto con m' detalls en el capitulo i 7 cuando veamos el concepto de modelo esencial, y mas ad:~ lante en la parte IV, cuanoo vearnos los modelos de irnplantaclon.

9.1.2 EI tlu]o

Un tlujo se re~resenta qraflcamente par media de una flecha que entra 0 sale de un pr~ceso; un ejernplo se rnuestra en la figura 9.3. EI flujo se usa para describir el movirruento d~ bloques 0 paquetes de informacion de una parte del sistema a otra. Por ella, los !IUJOS rspresentan datos en movirniento, mientras que los almacenes

(que se describan en la seccion 9.1 representan datos en repose.

DE UN CUENTE

9.3:

del.l!1

En la mayona de los sistemas que modele como los realments

representaran datos, es decir, caracteres, mensajes, nurneros de tlotante

. los diversos otros tipos de informacion can los que 'las cornputadoras pueden ira. tar. Pero los OFO tambien pueden uttllzarse para rnodelar otros sistemas

los auto_::natizados y cornputarizados: pudiera escoqerse, par usar un

10 de OrO para modalar una linea de ansamblado en la que no haya co~putarizados. En tales casos, los paquetes 0 rnostrados por los saran msterieles tisicos. Un ejernplo de esto se rnuestra en la

9.4. Para muchos sistemas cornplejos del rnundo el OFD rnostrara el flujo

materiales y datos.

Notese que los de las 9.3 y 9.4 tienen nombre, EI nornbrs

senta el del paquete que se mueve a 10 largo del flujo. un corolario

esto es que el solo lIeva un tipo de paquets, como 10 indica su nornbre. EI

Iista no debe dar al un nombre como MANZANAS Y NARANJAS Y

lOS Y VARIAS COSAS MAS. Sin embargo, veremos en la parte III que excepciones a este converuo: a veces es uti 1 consolidar varies Ilujos elementales en

DIAGRAMAS DE FlUJO DE DATOS 163

uno solo. Por 19110, se pudiera ver un solo tlu]o llarnado VEGETAlES en luqar de diversOs flujos llamados PAPAS, COLES DE BRUSElAS Y CHICHAROS. Como veremos, asto requerira de alquna explicacion en el diccionerio de datos, que se discutira en el capitulo 10.

HARINA PARA PASTEL

PASTEL

HORN EAR PASTEL

LECHE

Figura 9.4: DFD con flujo de materlales

Aunque parezca obvio, tenga en mente que el mismo contenido pudiera tener distintos slqnificados en distintas partes del sistema. Por ejernplo, considere el Iraqmento de sistema que se rnuestra en la figura 9.5.

EI mismo fragmento de datos por ejernplo, 212-410-9955) tiene distinto significado wando viaja a 10 largo de un lIamado NUMERO TElEFONICO que cuando via]a a 10 largo de uno llarnado NUMERO TElEFONICO VAUDO. En el primer caso, slqnifica un nurnero teletonico que pudiera ser 0 no valido; en el segundo caso, significa un numero telefonico que, dentro del contexte de este sistema, se sabe que es valido. Otra forma de verlo es que el flu]o denorninado "numero telsfonico" es como un ducto, 10 suficientements poco discrirninador como para perrnltir el paso de nurneros no validos al igual que validos; el flu]o denorninado NUMERO TElEFONiCO VAUDO es mas estrecho, 0 mas dtscrimlnador, y permlte pasar datos definldos mas estrecnamente,

Notese tambien que los flujos muestran la direcclon: una cabsza de Ilecha en cualquier extreme (0 poslblernente ambos) del flujo indica si los datos (0 el material) se ssta moviendo hacia adentro 0 hacia afuera de un proceso (0 arnbas cosas). EI tlujo que se rnuestra en la fiqura 9.6(a), por ejernplo, indica clararnante que el nurnero se esta mandando hecie el proceso denominado VAUDAR NUMERO TElEFONICO. Y el flujo denominado HORARIO DE ENTREGA DE CHOFERES de la fiqura 9,6(b) clararnente indica que es una salida qenerada per el proceso GENERAR HOFiA.R!O DE ENTREGA DE CHOFERES. Los datos que se mueven a 10 largo de di-



I aso de un diverqents, esto siqnifica que se estan mandan do capias par du-

e C . d I . t bi

r ado de un paquete de datos a diterentes partes e SIS erna, 0 len que un pa-

pIC te complejo de datos se esta divldiendo en varios paquetes individuales mas, qU~a uno de los cuales se esta rnandando a dlterentes partes del sistema, 0 que el ca de tlujo de datos lleva articulos can distintos valores (per ejsmplo, veqetales

os valores pudieran ser "papa", "col de bruselas" 0 "ejote") que estan siendo se-

euy .. 'f'

oarados. De manera inversa, en el caso de un flujo converqente, siqm rca que v?-

'. s p~quetes elernentales de datos se estan uniendo para formar agregados mas no a .. .

complsjos de paquetes de datos. Por ejemplo, la flgura 9,7(a) muestra un OFO en el

cLlal ei denominado DETAllES DE ORDENES diverge y lleva copias de los

'smos a los procesos GENERAR DOCUMENTOS DE ENVIO, ACTUAU-

l1'l1 !NVENTARIO Y GENERAR FACTLIRAS. La figura 9.7(b) rnuestra como el ftu]o DE CUENTE se divide en 103 paquetes mas elernentales NUMERO TECODIGO CALLE Y los cuales sa mandan a tres

NUMERO TElEFONICO

=>.

/ VAll DAR

NUMERO TELEFONICO

NUMERO INVALIDO

Figura 9.5: DFD tfplcc

c~o tlu]o viajaran y.~ sea a otro proceso (como entrada) 0 a un almacsn (como discutira en la seccron 9.1 0 a un terrninador (como se indica en la secclon 9.1.4), EI fluJo de dos cabezas que se muestra en la 9.6(c) es un dieloqo, es declr, un ,.,w_~~'v conveniente de des paquetss de datos (una pregunta y una respusstaj en En el caso de un dialcqo, los paquetes en cad a extreme de la flecha como se ilustra en la figura 9.6(c).3

NUMERO TElEFONICO

F~

! NUMERO j

\. ;

\~

los tlujos de datos esto es a!go as! como un rio

rios que se unen.

OFO tlpico en el cuat

divergir 0 converqer en un que se divide en vanes mas

Sin embargo, esto tiene un en

de datos que se mueven a travss del sistema:

3 Una alternativa aceptabls en lugar del dialogo es el usa de cos flujos diferentes, uno que las entradas (preguntas) a un proceso y otro que rnuestra las salidas (respuestas). Esto es, de cho, una mejor forma de manejar las cosas si una entrada puede ltevar a diversas accionas (y puestas) del proceso .. En el caso de una sttuacion sencilla de pregunta-respuesta, el usa ilujo de dlalogo a de fluJos de entrada y salida separaoos es cos a de gustos. La mayorta de anallst?s prefieren la notacion de dialoqo porqus 1) recalca al lector que los flujos de entrada y de estan relacionados entre sf }I 2) reduce la complehcao del diagrama.

GENERAR \ ITINERARIO DE ENTREGA DE

ITINERARIO DE l-C_O_N_D_U_C_T_O_R ..

, ENTREGA DE I

~

PREGUNTA SOBRE STATUS DE PEDIDO

RESPUESTA DE STATUS DE PEDIDO

9.

4 Como se realiza exactarnente este proceso de duplicado 0 descornposicion de paquetes de datos S6 considera asunto de la imptantacion, es decir, alqo de 10 que se tandra que preccupar el diseriacor, pero que el anatista no necesita rnostrar en el modele del sistema. A la larga pudiera llevarse a cabo POl' hardware 0 software, rnanuatmente, 0 por maqia negra. Si el analista esta rnodelando un sistema ya existents, puede haber tentacion de mcstrar el mecanisme (as decir, el proceso) que lleva a oabo la duplicaci6n! descomposfcion de datos. Se discutira esto mas a tendo en la parte III.


Notese que sl flu]o no responde a muchas dudas de procedirntento que pu ra tener cuando este viendo un DFD: no responde a dudas ace rca de peticion de tradas 0 de flujos de salidas, por ejernplo. La figura 9.8(a) muestra el caso sen de un flujo de entrada que sale del proceso denorninado PROCESAR ORDEN. i", ro como sucede esto? (,PROCESAR ORDEN pide expllcitarnente al usuario las tradas? se rnueven los paquetes a 10 largo del flu]o por su propia voluntad, ser pedidos? Sirnilarmente, la figura 9.8(b) rnuestra un flujo de salidas senclllo ernana de GE.NERAR REPORTE DE. FACTURAS. l,Acaso las FACTURAS se m ven a 10 largo del Ilujo cuando GENERAR REPORTE DE FACTURAS los qui rnandar, 0 cuando alquna otra parte del sistema pide el paquete? Finalmente, co dere la situacion mas comun que se muestra en la figura 9.8(0), en donee hay m pies tlujos de entrada y de salida: Len que secuencis lleqan los paquetes de data

en que secuencia S8 generan los paquetes de salida? Es (.el proceso Q

quiere exactamente un paquete de los flujos A, B Y C para exactaments

paquete de salida para los tlujos Y Y Z? (.0 existen dos Aes para cad a tres Bes?

PEDIDO

I PRODUCIR PEDIDOS

~~::;

PEDIDOS NO VALIDOS

GENERAR DOCUMENTO

~

DETALLES DE PEDIDOS

/

, ACTUALIZAR \ INVENTARIO

GENERAR PEDIDO

Figura 9.7(a): Fll.lj@ dlverqente


DOMICILIO DEL USUARIO

<>. ( 6~L~~;~ \

V

\ CALLE

\

VAll DAR NUMERO TELEFONICO

VAll DAR CALLE

Figura 9.

/~

__ P_E_D_ID_O 4~~~

Figura 9.8(8): Flujo de entrada

Figura 9.8(b): Flujo de salida


B

z

x

y

c

de un a!macen

----------------

5 La notaci6n DI en la 99(b) ;' ....

atrnacen de otros que en; di as s,mplemente una. numeracion que strve para distinguir sste

numorar los almacen ' .. i er ,agrama. La convene-on que slgue este libro no pide etiquetar 0

veremos en la secci6~s9(~~)m~i~nmveOnIUlec pOlrque no ha parecido necesano, ni siquiara util), pero (como

. , ra a numeracion de las burbujas.


Figura 9,9(b): Notacion alternatlva para un almacen

Figura 9.9(0): Notacion usada en el apendlee F

Para el analista con conoclrnlentos de proceso de datos es tentador referirse a los armacenee como erchivos 0 bases de datos (por ejernplo, un archive en. cinta magnetica 0 un archive de disco orqanizado con IMS, OB2, 10MS, 0 alqun otro sistema de manejo de bases de datos. De es as! como a menudo se irnlos alrnacenes en un sistema cornputarizado; pero un alrnacen tam bien pu-

diera consistir en datos almacenados en tarjetas rnicrofichas,

o mas de otras posibles tormas electronicas. Y un almacen tam-

bien de fichas de papel en una caja de nombres y do-

micilios en un directoric, diversos archives en un archivero, 0 varias torrnas no

La figura muestra un caractsrtstlco de "almacen" en

un sistema manual existente. Es ",rC>f"C'''' de un alrnacen que deliberadamente

y abstracts as! como 61 tsrrmno alrnacen en

de la forma ttstca que toma el tam bien existe la cuestion de

su &Existe el sistema POl' causa de un fundamental del

usuario ° por conveniente de la resiizecion del sistema? En el

caso, la base de datos existe como un area de almacenarniento diterida en el tiernpo, necasaria entre dos procesos que ocurren en mementos diterentes. Por

la 9.10 muestra un de un sistema en el cual, como

usuetio de la tecnoloqra que se use para

el proceso de entrada de ordenes opera: en tiempos diferentes (0

mente en el mismo) que el proceso de investiqacion de ordenes. EI alrnacen de ORDENES debe existir en alguna ya sea en disco, cinta, 0 inscrito en

G Tambien es cornun referirse a un paquete de informaci6n del almacen como registro, y raferirse a sus componsntes como campos. Nada tiene de malo esta terminoiogia, pero sa usa tan a menudo en 81 contexte de las bases de datos que es probable que ocasione el tipo de problemas discutido anteriorment8. Por ahara, utilizarerncs 81 termino paquete para describir una sola instancia de una ccleccion de objetos reiacionados en un alrnacen.


Figura 9.9(d): Otro tlpo de almacen

La figura ~,i 1 (a) muest,ra ~n tipo distinto de almacen: el almacen de implahta. cion. Podemos nnaqmar at disefiador del sistema interponiendo un alrnacen de OR. DENES entre ENTRA ORDEN V PROCESA ORDEN porque:

Se espera que ambos procesos se ejecuten en la mlsma computadd-, perc no hay sufici,ente ~emoria (0 alqun otro recurso de hardware) par~ cubrir a~bo~ al mlsrr:o tiernpo. As!, el almacsn de ORDENES se creaeo. mo archive lntermedio, puss la tecnoloqla de implantacton disponibleha torzeoo a que los procesos se ejecuten en tiempos distintos.

Se ~spera, ~ue cualquiera de los procesos, 0 ambos, se ejecuten en una contiquraclon de hardware que es poco confiable. As], el alrnacen de OR. DENES se crea como respaldo en case de que cualquiera de los procs. sos se aborta.

D\E PEDIDO_S_P_ED_IDO

PREGUNTA

PEDIDO

( INGRESAR PEDIDOS

'--~'__-'---'---

RECONOCIMIENTO

(, RpERS:~UN~:AR )

a

RESPUE~

Figura 9.10: un almacen necasarlo

PEDIDOS

DIAGRAfv1AS DE FlUJO DE DATOS 171

se espera que diterentes proqramadores implantsn los dos procesos

en un caso mas extreme, que 10 hagan diferentes grupos de proqrarnadores que trabajan en luqares qeoqraticos distintos). Asi, el almacen de ORDENES se crea para probar y correqlr, de manera que si el sistema complete no traba]a ambos qrupos puedan ver los contenidos del almacen y detectar el problema.

® EI analista 0 el disefiador pensaron que el usuario pudiera alqun dla hacer accesos al alrnacen de ORDENES par alquna otra razon, aun cuando no haya expresado tal interes. En este caso, el alrnacen se crea anticipando necesidades tuturas del usuario (V dado que costara algo implanter el sistema de esta rnanera, el usuarlo acabara paqando por algo que no

e

S8 pidto).

Si fueran a excluirse los asuntos y rnodelar solo los requerimientos esenctetes del sistema, no exlstina neeesidad de un alrnacen de ORDENES; en lugar de eso se tendrla un DFD como el que se rnuestra en la figura 9. i 1 (b).

Como hemos visto hasta ahora, los alrnacenes se conectan per flujos a los procesos. Asi, 61 contexte en el que se rnuestra un almacsn en un DFD es uno de

los (0 ambos):

® Un flu]o desde un almacen

® Un tlu]o tiecis un alrnacen

DETALLES DE PEDIDOS

PEDIDO

PEDIDO

(

f INGRESAR \

b /

PEDIDO INVALIDO

I PROCESAR I

~

RESPUE~

PEDIDOS

Figura 9.11 (a): A!macsn "de tmplantaclcn"

172 DIAGRAMAS DE FLUJO DE DlHOS

~LES DE PEDIDOS

(::E~

PEDIDO i--------li>

PEDIDOS

RESPUESTA

Figura 9.1

ellmlnadc

En la mayorfa de los cases, los tlujos se etiquetaran como ae discute en la seccion 9.1.3. Sin embargo, rnuchos analistas no se molestan en etiquetar el tluje si una instenoie complete del paquete hacia 0 desde el almacen.? Por la 9.12 muestra un fragmento tipico de un DFD.

Normalmente se interpreta un flu]o que precede de un sistema como una leclu. ra 0 un acceso a la informacion del almacen. Esto significa especmcarnents que:

® Se recupera del alrnacen un solo de datos; esto es, de heche, 81

mas comun de desde un almacen. por ejemplo,

un almacen llamado CUENTES, conde cada paquets contlens nornbre,

dornicillo y numaro teletonlco de los clientes individualas. un tf·

del almacen pod ria implicar la recuperacion de un complete

de informacion ace rca de un cliente.

Se na mas de un paquets del almacsn. Por ejsmpto, el flujO poena recuperar paquetes de informacion ace rca de todos los cnentss.de la ciudad de Nueva York del almacsn CUHnES.

Se tiens una de un paquete del almacen. En algunos cases, por

ejernplo, solo se recuperar la informaci6n del numoro teletonico del

cliente del almacon CUENTES.

7 Mencfonaremos varias convenciones de este tlpo en este capitulo, 10 mismo que diversas mas re· lacionadas con otras herramientas de modelado. EI adrninistrador del proyscto, el manual de es' tandares 0 la herramienta CASE que este usando para su proyscto (vea el apendice A) pudieran obligarlo a usar una convencion U otra, pero debe ver que existe una cierta flexibilidad en cuanto a las herramientas y notacion que se presentan aquf. La importante es la conslstencie: lodos los flu' jos portadores de paquetes que sntran 0 salen de un alrnacen deben stiquetarse 0 no etiquetarse de manera consistents.


INGREDIENTES PARA PAY /

~AS ROJAS PEQUE"AS

MANZANAS

I

I

J NO SON MANZANAS

\ \

PAY DE \

MANZANA ~

Figura 9. 12: AJmacenes con

no

® Se tienen porciones de mas de un paquets del almacen. Por tlu]o pod ria recuperar del almacen CUENTES la porcion del de todos los clientas que vlven en ei estado de Nueva York.

Como notamos antes cuando examinamos los que entraban \f sallan de

un proceso, tendrernos rnuchas praquntas de procedimiento cuando examine-

mas los que entran y sal en de un almacen: 61 un solo paque-

le, de dlvsrsos paquetes? En

viendo la del si el

un

de informacion se esta

una convenclon si 10.

que 5e recupera todo un paquete (0 multi-

del e5 dlterente del nornbre del

uno 0 mas cornponentes de uno 0 mas

8 i,Como podemos saber que las etiquetas del flujo tienen que ver con los componentes de un pade informacion del atrnacen? i,Como saber, por ejemplo, que el flujo etiquetado como NU-

TELEFONICO tiene alga que ver con los paquetes de informacion del alrnacen de CUEhlrES? Es tentador, sobre lodo en un proyecto real donde todo mundo esta relativamente familiarizado con el terna, decir simplemente "Es que es obvio", Par supuesto que el nurnero de teletone forma parte del paquete del cliente. Pero, para estar seguro, se requiere una definicion rigurosa de la composiclon del paquete CUENTES. Esto se encusntra en el dlccionario de datos, que se discutira en el capitulo 10.


A pesar de que alqunas de las prequntas de tipo procedimiento pueden res. ponderse viendo con cuidado las etiquetas del flujo, no ssran svidentes todos los detalles., De hec~o, para con?cer todo 10 deseado ace rca del que ernana del alrnacen, tendran que exarrunarse los dstalles: la especiiicecion del proceso al cUal se conecta el tlu]o. Las especificaciones de proceso se examinan en 131 capitulo 11.

Existe un detalle de tipo procedimiento del cual podernos estar sequros: sial. rnacen es pasivo, y los datos no viajaran a 10 largo del flujo a rnenos que el proceso 10 soHel.ts explf~itamente. Existe otro detalle de tipo procedimiento que suponen, por converuo, los sistemas de proceso de datos: el etmecen no cambia cuendo uri pa. quete se mueve del etmecen a 10 del tlujo. Un proqrarnador pudiera referirse a esto c0r:'0 una lectura no destructiva 0, en otras palabras, del almacen se recupera una copra del paquete y el alrnacen mantiene su condicion oriqinal.?

Un flujo bacia un alrnacen habitual mente se describe como una escrltura, una actualizaclon 0 posiblernente una elirninacidn. Especfficarnente, solo puede signiiicar que se tiene una de las situaciones siquientes:

Se estan guardando uno 0 mas paquetes nuevos en 131 almacsn. Depsn, diendo de la naturaleza del sistema, los paquetes nuevos pudieran anaxsrse (es de alguna manera acomodarse para que esten "despues' de los paqustes existentes); 0 pudieran colocarse en alqun lade entre los paquetes existentes. Esto as a menudo un asunto de la tmplantacion (es declr, controlado por el sistema especlfico de adrnlrustracion de bases de datos), per 10 que el anatista no debiera preocuparse acerca de ella. Podna ser, sin embargo, cuestion de una polttica del usuario.

'" Uno 0 mas paquetes se estan borrando 0 retirando del almacsn.

Uno 0 mas paquetes se estan modificando 0 cambiando. Esto pudiera traer consiqo un carnbio de todo un paquete, 0 (mas comunrnente), de so- 10 una porclon, 0 de una porcion de multiples paquetes. Por ejemplo, suponga que la policia tiene un alrnacen de sospechosos y que cada paquets contiene sus nombres y domlcllios: puede otrecersele una nueva "identidad" a un sospechoso que coopera, en cuyo caso tode la intorrnacion relacionada con su paquete carnbiarla, Como alternativa, considere un almacen CliENTES que contenga informacion acerca de los cfientes que residen en Manhattan; si la oficina de correos decidiera cambiar 61 c6digo postal para un area de Manhattan (como sucedio en 1983, cuando

9 Si esta usance un DFD para medelar algo que no sea puramente un sistema de proceso de informacion, esto pudiera no darse. Por ejemplo, un alrnacen puede contener cosas ffsicas, y el flujo puede ser un mecanisme para transferir materiales del almacen al proceso. En este caso, se sacaria ifsicamente un paquete del almacen y, como resuttado, tendria menos contenidos. En un mode- 10 de sistema que contenga almacenes de informacion y almacenes Iisicos. es importante nacer anotaclones en el DFD (0 dar explicaciones en el diccionario de datos) para que el lector no se con· funda.


el area de Manhattan donee yo vivta carnbio de c6digo '10028 a '101 se necesitarla un cambio a una porcion de diversos paquetes,

En todos estes casos as evidente que el alrnacen carnbio como rasuttado del

lIujo que EI proceso (0 procesos) con ectad os con el otro axtrerno del

as el responsable de rsalizar el cambio al almacen.

Un punto que debiera ser evidente de todos los ejemplos que se han rnostrado nssta ahora es 131 siguiente: los flujos conectados a un alrnacen solo pueden transportar paquetes de informa?i6n que el alm~cen sea capaz de quardar. ~?r ello, ~n lluio conectado a un alrnacen CUENTES solo puede transporter tntormacion relacionada con los cllentes contenidos por el almacen; no puede transporter paquetes de inventarios 0 paquetes de manutactura 0 datos astronornicos.

9,1.4 EI Termlnador

EI siguiente components del DFD es un termfnador; graricamente se representa como un rsctanqulo , como se muestra en la fiqura 9.13. Los terminadores representan snttdades externas con las cuales el sistema se comunica. Comunmente, un terminador es una persona 0 un qrupo, per ejemplo, una orqanizaclon externa 0 una agenda gubernamental, 0 un grupo 0 departamento que este dentro de la misrna compania u orqanizacion, perc fuera del control del sistema que se esta rnodelando. En cases, un terrninador puede ser otro sistema, como otro sistema computacional con el cual se comunlca este.

LlDAD

Figura 9. 13:

Suele ser muy Tacil ldentificar los terminadores en el sistema que se esta modelando. A vecas el terminador es el es decir, en sus discuslones con el usuario, este dira "Pretendo surrunistrar al sistema los datos X, Y Y Z, Y espero que me regrese los datos A, B Y C". En otros cases, el usuario se considera parte del sistema y ayudara a identificar los terminadores rolevantes: per ejemplo, Ie dira "Tenemos que estar listos para recibir las tcrrnas tipo 321 del departamento de contaouria, y debemos enviar reportes flnancieros sernanales al cornite de tlnanzas". En sste ultimo caso, es evidente que el departamento de contaduria y el oomite de tinanzas son terrninadores separados con los cuales se cornunica el sistema.

176 DIAGRAfVlAS DE FLUJO DE DATOS

Existen tres cosas irnportantes que debernos recordar ace rca de los dores:

1. Son externos at sistema que se esta rnodelando; los que conectan los torminadores a diversos procesos (0 alrnacenes) en el sistema sentan Ia intertaz entre el y el mundo externo.

2. Como consecuencla, es evidente que ni el analista nl el disefiador del sistema estan en posibilidades de cambiar los contenidos de un terrninado- 0

la manera en la que En el lenguaje usado por diversos librosde

texto clasicos sobre analisis el termtnador esta tuera del do-

minic del cambio. Lo que esto siqnifica es que el analista esta modelam:Jo un sistema con la intencion de perrnitir una considerable flexibitidad y Iibertad al disefiador para elegir la rnejor lmptantacion posible (Ia mas eflciente 0 la mas confiable, etc.), El disenador puede lmplantar €II sistema de rnanera bastante diferente de aquella en la que actualmente esta im· plantado: €II analista escoqer rnodslar los requerimientos del sistema en forma que se vea considerablernente diterente de Ia manera la que actualments €II usuario visualiza mental mente el sistema (se

mas ace rca de ssto en la seccion 9.4 y la parte I Sin embargo, ef

tiste de sistemas no moditicer los fa orqenizecton

procedimientos intetnos asociadas can los terminsdores.

3. Las relaciones que existan entre los terrninadores no S8 rnuestran en 81

modelo de DFD. Pudieran existir de heche diversas perc, por

no son del sistema que se esta estudiando. De rnanera

inversa, s! existen relaciones entre los terminadores y si es esencial para

€II analista modelarlos para poder docurnantar los del sistema, entonces, por los terminadores son en realtoad parte del sistema y debieran modelarse como procesos.

En los sencillos que se han discutido hasta ahora hemos vista s610

uno 0 dos terminadores. En un sistema real existir docenas de terrninadores diterentes lnteractuando con 81. ldentificar los terrninadores y su Interaccicn can €II sistema €IS parte del proceso de construir el modele del que se dis-

cutira en 81 17.

9.2 GUiA PARA LA CONSTRUCCION DE DFD

En la seccion anterior vimos que los de de datos constan.de

cuatro sencillos: procesos (burbujas), tlujos, alrnacenes y terminadores. Armado can estas herramientas, puede comenzar a entrevlstar a los usuaries y a construlr rnodelos de DFD de sistemas.

Sin embargo, existe un nurnero de adicionales que se rsquieren para

utilizar DFD con exito. Algunas de estas reglas ayudaran para no elaborar

DFD erronsos ejernplo, incomptetos 0 loqicamente inconslstentes). Aigunas de


eglas tienen la finalidad de ayudarle para que un .DFD a I~ vista, y

las r par tanto, tenga mas probabilidades de que 10 lea con cuidado el usuarro.

Las reglas lncluyen las slqulentes:

1 .

Escoger nornbres con significado para los procesos, flujos, almacsnes y terminadores.

2.

Numerar los procesos.

Redibujar el DFD tantas veces como sea necesario esteticamente.

Evitar los DFD excesivamente cornplejos.

Asequrarse de que el DFD sea internamente consistente y que tam bien 10 sea con cuaiesquiera DFD ralacionados can el.

3.

4.

5.

nombres con almacsnes y terrntnaderes.

Como S8 ha visto, un proceso en un DFD puede rspresentar una =-: que sa lIevando a cabo, 0 pudiera indicar como se esta "?v.ando a cabo, !dentlflcan-

do a la grupo 0 mecanisme involucrado. En el ultimo caso, obviarnente es

stiquetar con precision el proceso, de modo que quienes teen €II ~~-

los usuaries, confirmar que se trata de un modelo ~m

si el proceso 10 nace una sola persona, rscomiendo qu~ . . , A

que dicha persona esta rapresentando, mas que su nornbre 0 idenudad. ASI, en

de un proceso como €II que se muestra en la 9. icon 81 nom-

ore de Paco inmortallzado a la vista de todos, suqerlrnos que el proceso

como se rnuestra en la 9.1 La razon de esto tiene tres

sernana nor Marfa 0 per Juan, susceptible de volverse obsolete?

2.

Paco ser reemplazado la

i,Para lntroducir en el modelo

Paco pudiera estar realizando diversas labores dltarentes en €II sistema. En de dibujar tres burbujas distintas, cad a una como Pa-

co perc con distinto es indicar la labor misma que

se esta loqrando, 0 par 10 menos el que Paco. ssta en el

momenta (como se model a en cada una de sus burbujas).

3.

Identificar a Paco es probable que atraiga atencicn hacia la manera

cular en la que realiza la labor dada. Como veremos en la parte III, generalmente desearernos ooncontramos en la poiitice de que debe sin reterirnos a los procedimlentos (los cuales pueden basarse en costumbres e historia que ya no sean relevantes) que se utihzan para

dicha


pedrdos

pedldos inWl!idos

Figura 9.

pedidos

pedidos invalidos

Figura 9. 14(b): Nombre de procase mas

. . Si tenemos suerts de svitar nombres de personas (o d

liticos, entoncss podernos etrquetar los r e y papsles

tificar las funciones que el sistema est? I~cesods de tal manera que s~ puedan ide

puede utilizar para nornbrar procesos e: u:~~~n °v:r~~bO. Un .buen slstem~ que

un verbo activo verbo transitive uno' . y un objeto. Es decir,

ra Iorrnar una trase descriptiva pa'r I que tenqa ?bJeto) y.un objeto aproplado nombres de procssos: a e proeeso. i.os SlgUientes son ejernplos

CALCUlAR TRA YECTORIA DEL PROYECTIL PRODUCIR INFORME DE INVENTARIO

VAll DAR NUMERO TElEFONICO

ASIGNAR ESTUDIANTES A lA CLASE


Encontrara, al sequir estas reg las, que es considerablernente mas tacil utilizer verbos Y objetos especlficos si el proceso misrno es relativarnente simple y esta bien definido. Sin embargo, aun en los cas os sencillos hay la tentacion de utillzar nombres ambiguos como MANEJAR y PROCESAR. Cuando se utilizan verbos tan "elasticos" (verbos con siqniflcados para cubrir cas! cualquier situacion), a menudo significa que el analista no esta sequro de cua) funcion se esta llevando a cabo 0 que se han aqrupado diversas tunciones que en realidad no debieran aqruparse. Estos son algunos nombres de procesos poco adecuados:

., HACER ALGO

® FUNCIONES MISCELANEAS

" MANEJAR ENTRADAS

.. ENCARGARSE DE CliENTES

" DATOS DE PROCESOS

" EDICION GENERAL

Los nombres de los procesos (at igual que los nornbres de y de termina-

deben provenir de un vocabulario que tenqa alqun para el usuario.

Esto sucedera de manera muy natural si el DFD se dibuja como resultado de una sefie de sntrevistas con los usuaries y st el analista tiene alqun entendimiento rntnimo de la materia de aplicacion subyacente. Perc se deben tener en cuenta dos precauclones:

i < Hay una tendencia natural de los usuaries de utilizar abreviaturas y aeronimos especlticos con los que estan tamtllarlzados; esto es cierto tanto para los procesos como para los que describen, Por desqracia, esto suele rssultar en un DFD tuerternente orientado a la manera en la que se hacen las cos as anora. Por ello, el usuario pudiera decir: se consique una copia de la forma 107, la forma rosada, usted sabe, y se la rnandamos a Jose una vez llena". Una buena rnanera de evitar tales terminos idlosincrasicos es escoqer verbos (como "llenar") y objetos (como "forma lOT') que tendrian significado para alquien de ta misrna industria 0 aplicaclon, pero que trabaje en una cornpafiia u orqanizaclon oiterente. Si se esta creando un sistema para bancos, los nornbres de procesos y de tlujos debieran, idealmente, ser cornprensibles para alquien de un banco distinto.

2. Si el DFD 10 dibuja alquien que tenga bases de proqramacion, habra la tendencia a utilizar terminologia orientada a la proqramaclcn. tal como:

"RUTINA", "PROCEDIMIENTO", "SUBSISTEMA" Y "FUNCION", aunque dichos terminos pudieran no tener significado alguno en el mundo del usuario. A menos que olga a los usuaries utihzar estas palabras en su propia conversaclon, evite utilizarlas en su DFD.


SUL2 Numeral' el procesc

Como una forma convsnlente de referirse a los procesos en un DFD, analistas nurneran cada burbu]a, No importa mucho como se haga esto, de a derecha, de arriba aba]o ° de cualquier otra rnanera servira, mienttes nsye tencie en la forma de epticer los numeros.

La unica cos a que se debe tener en mente 6S que el sistema de

implicata, para lectores casuales de su DFD, una cierta secuencie de

cion, Esto es, cuando S6 rnuestre el DFD a un usuario, este pudiera

"(,Acaso la numero 1 sueede la 2 y la 37", De heche

otros analistas y proqramadores pudieran nacer la misma cualquiera qU~

sste famluarizado con un diagrama de flujo puede corneter el error de suponer qUe

los numeros asociadas con las burbujas implican secuencia.

Esto no es as! en absolute. EI modelo de DFD es una red de procesos asin. cronicos que se 10 cual es, de una representacion precise de la rnanera en la que en realidad muehos sistemas operan. secuencia pudiera

impncarse por la 0 ausencla de datos ejernplo, pudiera resultar la

burbuja 2 no realizar su tuncion sino hasta que reciba datos de la

pero el esquema de numeracion no tiene nada que ver con eso.


una excepcion importante a 8StO, que dlscuttremos en el capitulo 18: un es scial conocldo como dieqreme de contexte, que rspresenta el slste~a ente-

P n solo proceso 'I destaca las interfaces entre el sistema 'I los termmadores (0 C~~:s u La figura 9,15 muestra un de contexte tipico 'I, como pue?s verexte~on ~I basta para asustar a rnuchos analistas, por no mencronar al usuano des-

S8, los diagramas de contexte como el que S8 muestra en la

9,15 no se pueden puss describen, con el mas alto una re-

es intri nsecamente cornpleja.!"

LPara numerar entonces las burbujas? En como se lndlco

mente, es una manera muy conveniente de referirse a los procesos, Es mas facll en una discusion anirnada sobre un DFD decir 1" en de "EDITAR TRAN· SACCION Y REPORTAR ERRORES", Perc de mayor

de que los numeros se convierten en base para la numeracion cuanoo se

mtroduzcan los de per nivsles en 113 seccion 9,3,

Evltar los OFD demasladc

Ei

Ilevar a cabo un sistema y las interacciones entre elias.

es ser leldo y no s610 par el analista que

los usuarios que sean los en la materia de

debe set tacurnente facllrnente asirnilado y

Tratarernos sobre varias esteticas en Ia

una que se debe tener en mente: no cree un DFD con

procesos, tiujos, eimecenes y terminedores. En 113 rnayona de los casos, esto ca que no debisra habsr mas de media docena de procesos y flujos y terrninadores relacionados en un solo diaqrama.t? Otra rnanera de decir esto es que el DFD debe caber comodarnente en una hoja normal.

10 Esta regia proviene de "The Magical Number Seven, Plus or Minus Two", de George Mi!ler, Psychology Review, 1956,

\VENDEDORi ~I ------

I _ ' AGENCIA DE \

CLiENTE ~. LpUBLlCIDAD

"'" / =<>"

r----~COR \

I HACIENDA I I i'~

! ~\ J ..------

- /\____~~ 'L,___' SE_____.JC

/ I ,,,g~':'"

Is~NCOS 1 I CUENT~

. ._. -_ ... _-_.

>--_ ..... _--_ .... ,

9.15:

9.2,4

real de anal isis de sistemas, ei DFD que se analiza en este ca-

volvarse a a menudo hasta 0 veces 0

para el usuario y 3) estar 10

En un tsndra que antes de ) ser tecnicamente correcto, 2) ser

~~ realidad, hay algo ;~podemos hacer: st hay diversos tlujos distintos ;nt~e un lermin:~~~ y una sola burbu]a del sistema, pueden consolidarse en un solo flu]o de d~tos .. ~1 d:cclona:lo d_f . tos cue ae discute en 191 caottuto 10, se usara para explicar la corn POSIcion y Significado ae un ,iuIIO

, lju , " t d un m"y dlverso (per ejem!) 0,

agregado. Y, si 191 diagrama de contexto se esta rnos ran 0 a .. .,~'~ , .. con-

distintos orupos de usuaries con dilerentes mtereses). se pueoen dibular van os diaqrarnas de P texto oue~ sntaticen los tlujos particulares que puedan interesarie a cada grupo de usuanos. . erf' en ia mavorta de los cases. no hay escapatorta: si ei sistema glooal es Intrlnse~amente complejo, 0

, ..' " , f do esto en 191 capitulo 18,

sera tambien 191 diagrama de contexte. Se otscunra mas a on


suficienternente bien dibujado como para que no sea ernbarazoso rnostrarlo a la: oi. reccion de la orqanizacion. Esto pudiera parecer mucho traba]o, perc bien vals el esfuerzo de desarrollar un modele precise, congruente y aqradable, de los requeri. rnientos de su sistema. La mismo se cumple para cualquler otra disciplina de inge. nieria: Lquerrfa usted volar en un avion disefiado per inqenieros que se aburrieroh de sus dibujos de ingenierfa tras la sequnda iteracion?12

LOUe hace esteticarnente agradable a un DFD? Esto es obviamente!.ll'la cuestion de qustos y puede determinarse por norrnas dispuestas per su organizaC:i6n o por las caractertsticas particulates de cualquier paquete que utilice de disefio de diaqrarnas basado en una sstacion de traba]o autornatizada. Y la opinion del U5Uario pudiera ser un tanto diferents de la suva; loqicarnente, cualquier cosa que ei usuario encuentre aqradabte debe determiner la rnanera en la que se dibu]e el diagrama. Algunos de los asuntos que surgen para ser tratados en esta area son los 5iguientes:

Tamafio y forma de las burbujes. Algunas orqanizaciones dibujan diagramas de tlu]o de datos con rectanqulos u ovalos en lugar de ctrculos: esio es obviarnente una cuestion de estetica. Adernas, algunos usuariospu, dieran rnolestarse sl las burbujas del DFD no son del misrno tamario: ereen que si una burbu]a es mas grande que otra eso siqnifica que esa parte del sistema es mas importante 0 que difiere del resto de una manera signiflcativa. (De heche, per 10 cornun sucede s610 debido a que el nombre de la burbuja era tan largo que el analista tuvo que dlbujarla mas grande para poderlo abarcar.)

cutvos VS. rectos. Para ilustrar esto, considere los DFD de la Figuras 9.16(a) y 9.16(b). LCual es mas agradable? Muchos observadorss se eneoqeran de hombres y diran "en realidad da igual". Pero otros, yas· te es el meollo del asunto, escoqeran uno y recnazaran violentamente el otro. Obviamente, seria una buena idea conocer de antsrnano opcion sera aceptada y cual sera rechazada. EI asunto de las flechas cruzadas es similar. LSe permiten 0 no se permiten?

Dieqremes hechos a mana VS. los dieqremes generados por meautne. Dentro de algunos anos, casi todos los DFD y rnodelos de sistemas relacionados se dibujaran can sistemas graficos por computadora; sin embargo, rnuchos de los diagramas todavia hoy sa dibujan a mana porqus

12 En caso de que piense que los aviones son diferentes de los sistemas autornatizados, 0 que son mas entices, tenga en mente que en la actualidad la mayo ria de los aviones estan controlados par computadora; un avi6n grande de pasajeros puede tener una docena 0 mas de sistemas computacionales complejos a bordo, que a su vez tienen interfase con sistemas de tiempo real complejos tales como el que usa la administracion federal de aviaci6n para revisar el espacio aereo en la va· cindad de los aeropuertos.


analistas no tienen acceso a tales herrarnientas. No obstante, el asunto aqul es la reaccion del usuario a estes dlaqrarnas: algunos prefieren marcadamenta los diagramas generados por la maquina pues son mas ordenados, rnientras que otros prefieren los dibujados a mario porque los hace sentir que el diagrama no se na "congelado" aun, y que tooavta pusden introducir cambios.

5 Ase"'lirese de que su DfD sea logicamente conslstente

9.2. ~

Como se vera en el capitulo 14, existen reglas que ayudan a asequrar la con-

. toncia del DFD con los otros modelos de sistemas: el diagrama de antidad-rela-

SIS v ., • ddt .

ci6n, el diagrama de transicion de e stados , el dlcclonalrlo e at os, ~ ra

especificacion de procesos. Sin emb.argo, existen atqunas reg as respec 0 ~ co~o asegurar que el DFD mismo sea consistente. Las principales reglas de consistencra

son:

..

Evite sumkieros intinitos, burbujas que tienen antradas perc no salidas. Tambien son conocidos por los analistas como "agujeros neqros", en analoqia con las sstrellas cuyo campo gravitaeional es tan intense que ni la luz se les escapa. Un ejemplo de vortlcs infinite S8 da en la figura 9.17.

Evite las butbujes de qenerecion espontetiee, que tienen salldas sin tener sntradas, porque son sumamente sospechosas y generalmente incorrectas. Un ejernplo Iactible de una burbuja que s610 tiene salidas es un generador de numeros aleatorios, pero es dificil imaqmar alqun otro ejernplo razonable. Una burbuja tipica que solo tiene salidas se muestra en la rag.iS.

Tenga cuidedo con los flujos y procesos no etiouetedos. Esto sU,ele S?f un indlcio de Ialta de esrnero, pero puede ascender un error aun mas grave: a veces el analista no stlqueta un flujo 0 un proceso porque simclemente no se Ie ocurre alqun nombre razonable. En el caso de un

no atlquetado, pudiera significar que diversos datos elementales no rel~cionados S9 aqruparon arbitrariamente: en el caso de un proceso no etiquetado, pudiera siqnificar que el analista sstaba tan confundido. que dibu]o un diagrama de flujo disfrazado en tuqar de un diagrama de Ilujo de datos.t-

13 Hay un convenio idiornatico que viola esto, que S6 discutira en la seccion 9.1:3: un f.lujo no ~tiquetaco que sale 0 entra de un alrnacen es, por acuerdo, un indicio de que una mstancia (0 registro) completo se esta metiendo 0 sacando del almacen.


A

c

Figura 9. 16(a): Version de un OFD

c

B I

\~ I

U

Figura 9. 16(b): Version diferente de un OFO

DiAGRAMAS DE FLUJO DE DATOS 185

x

PROCESAR COSAS

y

Figura 9.17: Ejempio de eumldero Inflnlto

x

Figura 9.18: Ejemplo de burbuja unlcamente de salida

.., Tenga cuiosdo con tos etmecenes de "s610 tecture" 0 "s6/0 esotiture". Esta regia es analoqa a la de 10s procesos de "unicarnente entradas" 0 "unlcarnente salidas'', Un atmacen tiplco debiera tsner tanto entradas como salidas.t+ La unlca excepclon a esta regia es el alrnacen externo, que sirve de intertaz entre et sistema y alqun terminador externo. La figura 9.19 muestra un de un sistema de bolsa con un almacsn leqitirno que s610 es para escrltura,

-------------------

14 A veces pudiera no ser evidente inmediatamente si el alrnacen tiene tanto entradas como salidas, Como verernos en la slqulente seccion, a menudo los DFD se dividen en partes, por 10 que pudierarnos encontrar que una parte del sistema parece s610 teller alrnacenes de iinicamente leetura (0 untcamente escritura). Alguna otra parte del sistema, documentada en otro DFD, pudiera teller la actividad de unlcamente escritura (0 untcamente lectura) correspondiente. Para verincar que alquna parte del sistema lea y alguna otra escriba en el almacen se requiere de una labor muy tediosa de revision; es aqul donde los paquetss de anallsis automanzado de sistemas que se discuten en el apendice A se vuelven extremadamente valiosos.


datos de mercado

CLiENTE

CliENTES

CORPORATIVOS reports anual

DATOS DE MERCADO

datos de rnercado

SEC

AGENCIAS DE INVESTIGACiON

reportes r-----, 10-K

SiSTEMA DE INVESTiGACION DE MERCADO

datos de lnvestiqacion

Figura 9.19: Caso iegitimo de almacen de unlcamente escrltura

9.3 OFD por nlveles

Hasta donee hemos Ilegado en este capitulo, los unicos diaqramas de datos completes que hemos visto son el sistema sencillo de ires burbujas de la figu· ra 9.1 y el sistema de una burbuja de la figura 9.19, perc los DFD que vsremos en proysctos reales son conslderablemsnte rnayores y mas cornplejos. Considere por ejemplo el DFD que se rnuestra en la figura 9.20. l,Puede irnaqinarse mostrandols esto al usuario tipico?

La seccion 9.2.3 suqiere que deben evitarss diaqramas como el de la fiqura 9.20. GPero como? Si el sistema es intrlnsecamente complejo y tiene docenas 0 lncluso cientos de funciones que modelar, l,como puede evitarse el tipo de DFD rnuestra la figura 9.20?

La respuesta es orqanizar el DFD global en una serie de niveles de modo cad a uno proporcione suceslvamente mas detalles sobre una porcion del nivel rior. Esto es analoqo a la orqanlzacion de mapas en un atlas, como se discutio capitulo 8: esperarlamos ver un mapa global que mostrara un pais complete, 0 vez incluso el mundo complete; los mapas subsecuentes mostrarian los dstalles los parses indfviduales, los estados individuales centro de los palses, etc. En 191

so de los la orqanlzacion de los niveles se muestra conceptualmente en la

ra 9.21.

EI DFD del primer ntvet consta solo de una burbuja, que representa 131 sistema complete, los flujos de datos rnuestran las interfaces entre el sistema y los termi8~' dorss externos (junto con los almacenss externos que pudiera haber, como 10 ilustra


ta figura 9.19). Este DFD especial se conoce como diagrama. de contexto y se expllea en 191 capitulo 18.

Figura 9.20: DFD complejo

EI DFD que sigue del diagrama de contexte se conoce como la fiqura O. Rela vista de mas alto nivel de las principales funciones del sistema, at igl)al interfaces, Como se discutlo en la seccion 9.2.2, cad a una de debiera numerarse para una referencla conveniente.

Los nurneros tambien slrvsn como una manera adecuada de relacionar una

burbuja con el nivel del DFD que la describe mas a rondo. Por ejemplo:

e 2 en la 0 se asocia con un DFD inferior conocioo como

Las burbujas de la figura 2 se numeran 2.1, 2.2, 2.3, etc.

e La burbuja 3 de 161. 0 se asocia con un DFD inferior eonocido como figura 3, las burbujas de la figura 3 58 numeran 3.1, 3.2, 3.3, etc.

m La burbu]a 2.2 de la figura 2 5e asocia con un DFD de nivel inferior conocido como figura 2.2. Las burbujas de esta se numeran 2.2.1, 2.2.2, 2.2.3, etc.

Edward Yourdon - Análisis Estructurado Moderno

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Edward Yourdon - Análisis Estructurado Moderno

Transféré par

Droits d'auteur :

Formats disponibles

NALISIS STRUCTURADO ODERNO

Vous aimerez peut-être aussi

Edward Yourdon - Análisis Estructurado Moderno

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Edward Yourdon - Análisis Estructurado Moderno

Transféré par

Droits d'auteur :

Formats disponibles

﻿NALISIS STRUCTURADO ODERNO

Vous aimerez peut-être aussi

NALISIS STRUCTURADO ODERNO