Analisis y Diseno de Sistemas

Anlisis y Diseo de Sistemas
Estructurado Moderno
ADSEM
Texto Preparado por Oscar A. Nez Madrid

Para los Alumnos del CFT Simn Bolvar
Marzo - 2006
Santiago - Chile
1.
Introduccin
La informacin es inherente a la existencia de las personas y de las sociedades. Permite conocer la realidad,
interactuar con el medio fsico, apoyar la toma de decisiones y evaluar las acciones de individuos y de grupos. El
aprovechamiento de la informacin propicia la mejora de los niveles de bienestar y permite aumentar la productividad y
competitividad de las naciones.
El mundo de hoy, est inmerso en una nueva revolucin tecnolgica basada en la informtica, que encuentra su
principal impulso en el acceso expedito y en la capacidad de procesamiento de informacin sobre prcticamente todos
los temas y sectores de la actividad humana. La nueva revolucin tecnolgica ha contribuido a que culturas y sociedades
se transformen aceleradamente tanto econmica, como social y polticamente, con el objetivo fundamental de alcanzar
con plenitud sus potencialidades.
Debemos tomar conciencia que la informtica tiene un carcter estratgico. Sus aplicaciones ya han afectado
prcticamente todas las actividades humanas, modificando las estructuras de produccin y comercializacin, la
organizacin de instituciones, la generacin de nuevas tecnologas y la difusin de conocimientos, as como la
prestacin de servicios. A todo ello se estn sumando transformaciones igualmente importantes en el mbito social,
bsicamente en la forma en que se llevan a cabo innumerables actividades cotidianas y personales.
En la actualidad, la informacin, obtenida en forma completa y oportuna dentro de cualquier tipo de
organizacin, constituye un elemento esencial que garantiza la gestin eficaz de los recursos de la misma, as como la
calidad de los servicios que presta y la adecuacin constante al entorno que lo rodea. A medida que se difunde con gran
rapidez el uso de las Computadoras dentro de una Organizacin, surgen muchas inquietudes acerca de la forma de
usarlas para mejorar la productividad y objetivos de la Organizacin.
En Chile la mayora de las instituciones y empresas carecen de una poltica de informtica adecuada,
constituyendo as una de las caractersticas negativas del desarrollo de sistemas informticos. Frente a la importancia de
la informacin, dentro de una organizacin y el incremento del uso del computador y la carencia de una poltica de
informtica adecuada, se ve por conveniente emitir metodologas orientadas al desarrollo de Sistemas de Informacin,
en tal sentido, la literatura tcnica propone una serie de metodologas orientada a las Fases de Anlisis y Diseo de
Sistemas de Informacin, la cual constituye el cuerpo del presente libro
La filosofa implcita en la Metodologa, es que el Anlisis y Diseo de Sistemas es un Proceso en el que se
aplican muchas tcnicas orientadas a mejorar el negocio mediante la implantacin o el cambio de los sistemas de
informacin existentes. La Metodologa propuesta, tiene sus fundamentos en la Teora General de Sistemas (TGS), y
debe de considerarse como herramienta y gua para asegurar su efectividad.
En muchas organizaciones los Sistemas de Informacin se encuentran en la fase de expansin y todava no se
ha establecido una metodologa efectiva de Planificacin de los mismos. En estos casos no ser posible implantar
directamente una metodologa activa de generacin de Planes Estratgicos de Empresas y de Sistemas de Informacin
simultneamente al carecer la organizacin de la cultura organizativa correspondiente. En esta circunstancia hay que
llegar al mtodo activo por va evolutiva mediante la implantacin de una metodologa pasiva en una primera fase que
ayude a la creacin de una cultura necesaria (el trmino pasivo hace mencin que solamente requiere el conocimiento de
las estrategias que la institucin desee llevar a cabo independientemente del proceso que se haya seguido para llegar a
ellas) es difcil de implantar si no existe los siguiente consideraciones:
1. Una cultura corporativa en la Institucin que sea sensible al uso del potencial de las tecnologas de la
informacin.
2. El conocimiento por parte del Centro Informtico, de los objetivos y estrategias corporativas de la
Institucin, en trminos que permita buscar un alineamiento del plan de sistemas con las estrategias de la
institucin (mtodo pasivo).
Sin embargo, cabe la posibilidad de desarrollar una integracin o planificacin en paralelo de ambas estrategias
(estrategias empresariales y en tecnologas de Informacin), Siendo el objetivo bsico de cualquier procedimiento
sistemtico de planificacin paralela (estrategias - TI/SI) es el aprendizaje organizado asociado a la utilizacin de tal
procedimiento. Incorporar el pensamiento estratgico y desarrollar la sensibilidad acerca de las posibilidades de la TI/SI
a todos los niveles directivos de la organizacin es extraordinariamente importante para asegurar la continuidad efectiva
2
del procedimiento en cuestin. En consecuencia, es responsabilidad de la Alta Direccin procurar que existan las
condiciones para que ste aprendizaje pueda desarrollarse efectivamente.
El Plan de Sistemas de Informacin, responde a la necesidad de lograr que el tratamiento de la informacin
(considerado en trminos de disponibilidad), ayude al cumplimiento de los objetivos generales definidos para cualquier
Unidad organizativa de la Institucin. Con esta perspectiva, los planes de sistemas de encuadran dentro del marco ms
general de la Planificacin Estratgica, como el fin de concretarse a corto y medio plazo de sta. As, la Planificacin
Estratgica tiene como finalidad principal, definir los objetivos a largo plazo de una organizacin, en cuanto a:
Servicios futuros a prestar.
Perspectivas de crecimiento y previsiones de evolucin, entre otros. As mismo, trata de estimar las
necesidades de informacin en funcin de dichos objetivos. Para ello se considera tanto la situacin de dicha
organizacin frente a su entorno, como la visin de los responsables de la misma.
La Planificacin de Sistemas se puede considerar como la realizacin tctica de los objetivos estratgicos ya
definidos para la Planificacin Estratgica, los cuales tiene por caracterstica:
Definicin precisa de los Sistemas de Informacin identificados.
Una planificacin ajustada para la Implantacin de dichos sistemas, considerando prioridades y recursos
necesarios.
Dentro de cualquier tipo de organizacin, el disponer de informacin completa, confiable en el momento
oportuno, constituye un elemento esencial para garantizar la gestin eficaz de los recursos de la misma, as como,
mejorar la calidad de los servicios que presta y adecuarse constantemente al entorno que lo rodea. Por lo que se requiere,
una administracin adecuada de la informacin, que se planifiquen, desarrollen y mantengan sistemas de informacin
eficientes, es decir, sistemas que produzcan en trminos de calidad, cantidad y oportunidad la informacin que ayude o
facilite el cumplimiento de los objetivos y funciones de la organizacin. A medida que crece el volumen de la
informacin a manejar en la administracin, aumenta la necesidad de disponer de una Tecnologa de la Informacin que
soporte dinmica y eficazmente el funcionamiento normal de las distintas reas o departamentos que la constituyen. Uno
de los problemas existentes en los Departamentos de Sistemas, es la ausencia de polticas en informtica, y de
metodologas modernas de desarrollo de sistemas, pudindose resumir tal situacin de la siguiente forma:
Desarrollo de Sistemas de Informacin sin responder a un Planeamiento de Sistemas de informacin.
Escasa o nula documentacin de los sistemas, lo que dificulta la tarea de desarrollo, implantacin y
especialmente la de mantenimiento.
Escaso nmero de estndares de Desarrollo de Sistemas.
Se justifica, por tanto, la implantacin de una Metodologa de Desarrollo de Sistemas en las organizaciones,
en las que se define un conjunto de mtodos, actividades, tcnicas y herramientas que faciliten la
construccin de Sistemas de Informacin con el fin de:
o Satisfacer las necesidades de los departamentos y/o reas usuarias implicadas.
o Generar la documentacin asociada, la cual comprende instrucciones de operacin, documentacin
del mantenimiento, explotacin, entre otros.
o Elaborar sistemas eficientes en trminos de calidad, que produzcan informacin oportuna y
confiable para la adecuada toma de decisiones.
Debido a la importancia que reviste contar con metodologas para el desarrollo de sistemas, se ha considerado
conveniente proponer una metodologa para la elaboracin de las Fases de Anlisis y Diseo de Sistemas, el cual es la
consecucin del conocimiento emprico.
La metodologa tiene por objeto establecer las directrices a las que debe ajustarse la elaboracin del Anlisis de
Sistemas en los distintos organismos, empresas y/o gobierno. As mismo, es importante sealar que la Metodologa se
encuentra dividida en los siguientes captulos:
Captulo 2: Generalidades
Captulo 3: Definicin del Proyecto de Sistemas
Captulo 4: Anlisis, Determinacin y Especificacin de Requerimientos
Captulo 5: Anlisis Estructurado
Captulo 6: Diseo
Captulo 7: Programacin
Captulo 8: Prueba
Captulo 9: Implantacin
Captulo 10: Mantencin
2.
Generalidades del Anlisis de Sistemas de Informacin.
2.1.
El Enfoque Sistmico
El concepto de sistema arranca del problema de las partes y el todo, ya discutido en la antigedad por Hesodo
(siglo VIII a.C.) y Platn (siglo IV a.C.) Sin embargo, el estudio de los sistemas como tales no preocupa hasta la
segunda guerra mundial, cuando se pone de relieve el inters del trabajo interdisciplinario y la existencia de analogas
(isomorfismos) en el funcionamiento de sistemas biolgicos y automticos. Este estudio tomara carta de naturaleza
cuando, en los aos cincuenta, L. Von Bertalanffy propone su Teora General de Sistemas.
La aparicin del enfoque de sistemas tiene su origen en la incapacidad manifiesta de la ciencia para tratar
problemas complejos. El mtodo cientfico, basado en reduccionismo, repetitividad y refutacin, fracasa ante fenmenos
muy complejos por varios motivos:
El nmero de variables interactuantes es mayor del que el cientfico puede controlar, por lo que no es
posible realizar verdaderos experimentos.
La posibilidad de que factores desconocidos influyan en las observaciones es mucho mayor.
Como consecuencia, los modelos cuantitativos son muy vulnerables.
El problema de la complejidad es especialmente patente en las ciencias sociales, que deben tratar con un gran
nmero de factores humanos, econmicos, tecnolgicos y naturales fuertemente interconectados. En este caso la
dificultad se multiplica por la imposibilidad de llevar a cabo experimentos y por la propia intervencin del hombre como
sujeto y como objeto (racional y libre) de la investigacin.
La mayor parte de los problemas con los que tratan las ciencias sociales son de gestin: organizacin,
planificacin, control, resolucin de problemas, toma de decisiones,... En nuestros das estos problemas aparecen por
todas partes: en la administracin, la industria, la economa, la defensa, la sanidad, etc.
As, el enfoque de sistemas aparece para abordar el problema de la complejidad a travs de una forma de
pensamiento basada en la totalidad y sus propiedades que complementa el reduccionismo cientfico.
Vase una excelente presentacin de las ideas de sistemas en "Systems Thinking, Systems Practice" (P.
Checkland, Wiley, 1999).
Lord Rutherford pronunci la frase que refleja ms claramente el xito del mtodo cientfico reduccionista
durante el primer tercio de este siglo: "Hay Fsica y hay coleccionismo de sellos". El objetivo ltimo era explicar
cualquier fenmeno natural en trminos de la Fsica.
Fueron los bilogos quienes se vieron en primer lugar en la necesidad de pensar en trminos de totalidades. El
estudio de los seres vivos exiga considerar a stos como una jerarqua organizada en niveles, cada uno ms complejo
que el anterior. En cada uno de estos niveles aparecen propiedades emergentes que no se pueden explicar a partir de los
componentes del nivel inferior, sencillamente porque se derivan de la interaccin, y no de los componentes individuales.
En los aos cuarenta comienza un vivo inters por los estudios interdisciplinarios con el fin de explorar la tierra
de nadie existente entre las ciencias establecidas. Estos estudios ponen de manifiesto la existencia de analogas (ms
bien isomorfismos) en la estructura y comportamiento de sistemas de naturaleza muy distinta (sistemas biolgicos,
mecnicos, elctricos, etc.) As es como Wiener y Bigelow descubren la ubicuidad de los procesos de realimentacin, en
los que informaciones sobre el funcionamiento de un sistema se transmiten a etapas anteriores formando un bucle
cerrado que permite evaluar el efecto de las posibles acciones de control y adaptar o corregir el comportamiento del
sistema. Estas ideas constituyen el origen de la Ciberntica, cuyo objeto es el estudio de los fenmenos de comunicacin
y control, tanto en seres vivos como en mquinas.
Un concepto previo al de comunicacin es el de informacin. Los trabajos en este campo de Wiener y

especialmente de Shannon llevaron a establecer una teora estadstica de la informacin.
En esta misma dcada, Von Bertalanffy propona los fundamentos de una Teora de Sistemas Generales y en
1954 se crea la Sociedad para la Investigacin de Sistemas Generales. El programa de la sociedad era el siguiente:
1.
Investigar el isomorfismo de conceptos, leyes y modelos en varios campos, y promover transferencias

tiles de un campo a otro.
2.
Favorecer el desarrollo de modelos tericos adecuados en aquellos campos donde faltaran.
3.
Reducir en lo posible la duplicacin de esfuerzo terico en campos distintos.
4.
Promover la unidad de la ciencia, mejorando la comunicacin entre los especialistas.
El objetivo ltimo de Von Bertalanffy, el desarrollo y difusin de una nica meta-teora de sistemas
formalizada matemticamente, no ha llegado a cumplirse. En su lugar, de lo que podemos hablar es de un enfoque de
sistemas o un pensamiento sistmico que se basa en la utilizacin del concepto de sistema como un todo irreducible.
2.1.1.
Qu es un Sistema
Mostramos a continuacin la definicin de Sistema propuesta por varios autores.
L. Von Bertalanffy (1968):
"Un sistema es un conjunto de unidades en interrelacin."
Ferdinand de Saussure (1931):
"Sistema es una totalidad organizada, hecha de elementos solidarios que no pueden ser definidos ms
que los unos con relacin a los otros en funcin de su lugar en esa totalidad."
Mario Bunge (1979):
Sistema es una terna ordenada [C(), E(), S()] en la que:
C() (composicin de ) representa el conjunto de partes de .
E() (entorno o medio ambiente de es el conjunto de aquellos elementos que, sin pertenecer a
C(), actan sobre sus componentes o estn sometidos a su influencia.
S() (estructura de ) es el conjunto de relaciones y vnculos de los elementos de C() entre s
o bien con los miembros del entorno E().
IEEE Standard Dictionary of Electrical and Electronic Terms:
"Sistema es un todo integrado, aunque compuesto de estructuras diversas, interactuantes y
especializadas. Cualquier sistema tiene un nmero de objetivos, y los pesos asignados a cada uno de
ellos pueden variar ampliamente de un sistema a otro. Un sistema ejecuta una funcin imposible de
realizar por una cualquiera de las partes individuales. La complejidad de la combinacin est
implcita."
Estndar X3.12-1970 (ANSI), Estndar 2382/V, VI (ISO) Vocabulary for Information Processing:
"Sistema es una coleccin organizada de hombres, mquinas y mtodos necesaria para cumplir un
objetivo especfico."
Resumiendo, de las definiciones se pueden extraer unos aspectos fundamentales del concepto Sistema:
2.1.2.
La existencia de elementos diversos e interconectados.
El carcter de unidad global del conjunto.
La existencia de objetivos asociados al mismo.
La integracin del conjunto en un entorno.
Las Ciencias de la Complejidad
El enfoque de sistemas ha dado lugar a estudios tericos y aplicados. Entre los primeros se encuadran algunos
de los citados anteriormente: la Ciberntica y la Teora de Sistemas Generales, de los Sistemas Dinmicos, de los
Sistemas Auto-organizativos, de la Informacin y de las Jerarquas. Todos ellos se pueden englobar bajo la
denominacin genrica de Ciencias de los Sistemas.
Los estudios aplicados son por su parte aquellos que emplean el enfoque sistmico para la resolucin de
problemas, y entre ellos se encuentran la Ingeniera de Sistemas, la Gestin de Sistemas, la Investigacin Operativa o la
Dinmica de Sistemas.
En los ltimos tiempos se est extendiendo el uso del trmino Ciencias de la Complejidad para referirse a
todas las disciplinas que hacen uso del enfoque de sistemas. En general, las Ciencias de la Complejidad comparten
bastantes de las siguientes caractersticas:
Han sido establecidas por grupos interdisciplinarios de investigadores interesados en explorar los
aspectos invariantes de la complejidad y la sistemicidad fuera de las fronteras establecidas entre los
distintos campos del saber.
Hacen hincapi en el estudio de la estructura (interconexin entre componentes) y su importancia en el

comportamiento de los sistemas. Esta estructura puede conllevar aspectos de paralelismo o
circularidad (realimentacin).
Destacan el carcter de totalidad o unidad global de los sistemas objeto de estudio.
Manejan aspectos no materiales de los sistemas, en particular aquellos que tiene que ver con
informacin, comunicacin u organizacin. Los conceptos de complejidad e incertidumbre suelen ser
bsicos.
Suelen tratar con sistemas abiertos, aquellos que intercambian materia, energa o informacin con el
entorno. En este contexto son especialmente importantes la interaccin con el observador y la toma de
decisiones.
El ordenador es la herramienta fundamental de las ciencias de la complejidad debido a su capacidad

para modelar y simular sistemas complejos.
2.1.2.1. Ingeniera de Sistemas

La primera referencia que describe ampliamente el procedimiento de la Ingeniera de Sistemas fue publicada
en 1950 por Melvin J. Kelly, entonces director de los laboratorios de la Bell Telephone, subsidiaria de investigacin y
desarrollo de la AT&T. Esta compaa jug un papel importante en el nacimiento de la Ingeniera de Sistemas por tres
razones: la acuciante complejidad que planteaba el desarrollo de redes telefnicas, su tradicin de investigacin
relativamente liberal y su salud financiera. As, en 1943 se fusionaban los departamentos de Ingeniera de Conmutacin
e Ingeniera de Transmisin bajo la denominacin de Ingeniera de Sistemas. A juicio de Arthur D. Hall, "la funcin de
Ingeniera de Sistemas se haba practicado durante muchos aos, pero su reconocimiento como entidad organizativa
gener mayor inters y recursos en la organizacin". En 1950 se creaba un primer curso de postgrado sobre el tema en el
M.I.T. y sera el propio Hall el primer autor de un tratado completo sobre el tema..
Para Hall, la Ingeniera de Sistemas es una tecnologa por la que el conocimiento de investigacin se traslada a
aplicaciones que satisfacen necesidades humanas mediante una secuencia de planes, proyectos y programas de
proyectos. Hall definira asimismo un marco para las tareas de esta nueva tecnologa, una matriz tridimensional de
actividades en la que los ejes representaban respectivamente:
La dimensin temporal: son las fases caractersticas del trabajo de sistemas, desde la idea inicial hasta
la retirada del sistema.
La dimensin lgica: son los pasos que se llevan a cabo en cada una de las fases anteriores, desde la
definicin del problema hasta la planificacin de acciones.
La dimensin del conocimiento: se refiere al conocimiento especializado de las diversas profesiones y

disciplinas. (Esta dimensin, ortogonal a las anteriores, no ha sido incluida en la tabla a efectos de una
mayor claridad.)
Para Wymore, el objeto de la Ingeniera de Sistemas es el "anlisis y diseo de sistemas hombre-mquina,

complejos y de gran tamao", incluyendo por tanto los sistemas de actividad humana. En estos casos el inconveniente
habitual suele ser la dificultad de expresar los objetivos de manera precisa.
Encontramos una definicin muy general en el IEEE Standard Dictionary of Electrical and Electronic Terms:
"Ingeniera de Sistemas es la aplicacin de las ciencias matemticas y fsicas para desarrollar sistemas que
utilicen econmicamente los materiales y fuerzas de la naturaleza para el beneficio de la humanidad."
Una definicin especialmente completa (y que data de 1974) nos la ofrece un estndar militar de las fuerzas
areas estadounidenses sobre gestin de la ingeniera.
"Ingeniera de Sistemas es la aplicacin de esfuerzos cientficos y de ingeniera para:
(1) transformar una necesidad de operacin en una descripcin de parmetros de rendimiento del sistema y una
configuracin del sistema a travs del uso de un proceso iterativo de definicin, sntesis, anlisis, diseo, prueba y
evaluacin;
(2) integrar parmetros tcnicos relacionados para asegurar la compatibilidad de todos los interfaces de
programa y funcionales de manera que optimice la definicin y diseo del sistema total;
(3) integrar factores de fiabilidad, mantenibilidad, seguridad, supervivencia, humanos y otros en el esfuerzo de
ingeniera total a fin de cumplir los objetivos de coste, planificacin y rendimiento tcnico.
Como vemos, en la literatura se pueden encontrar tantas definiciones del trmino como autores se han ocupado
del tema. A pesar de ello, podemos dar otra basada en las ideas de Hall, Wymore y M'Pherson:
Ingeniera de Sistemas es un conjunto de metodologas para la resolucin de problemas mediante el anlisis,
diseo y gestin de sistemas.
Como era de esperar por el amplio espectro de sus intereses, la Ingeniera de Sistemas no puede apoyarse en
una metodologa monoltica. Cada una de las metodologas que comprende puede ser til en una fase concreta del
proceso o para un tipo concreto de sistemas; lo que todas ellas comparten es su enfoque: el enfoque de sistemas.
2.1.2.2. Anlisis de Sistemas

El Anlisis de Sistemas trata bsicamente de determinar los objetivos y lmites del sistema objeto de anlisis,
caracterizar su estructura y funcionamiento, marcar las directrices que permitan alcanzar los objetivos propuestos y
evaluar sus consecuencias. Dependiendo de los objetivos del anlisis podemos encontrarnos ante dos problemticas
distintas:
Anlisis de un sistema ya existente para comprender, mejorar, ajustar yo predecir su comportamiento.
Anlisis como paso previo al diseo de un nuevo sistema-producto.
En cualquier caso, podemos agrupar ms formalmente las tareas que constituyen el anlisis en una serie de
etapas que se suceden de forma iterativa hasta validar el proceso completo:
Conceptualizacin: Consiste en obtener una visin de muy alto nivel del sistema, identificando sus
elementos bsicos y las relaciones de stos entre s y con el entorno.
Anlisis funcional: Describe las acciones o transformaciones que tienen lugar en el sistema. Dichas
acciones o transformaciones se especifican en forma de procesos que reciben una entradas y producen
unas salidas.
Anlisis de condiciones (o constricciones): Debe reflejar todas aquellas limitaciones impuestas al

sistema que restringen el margen de las soluciones posibles. Estas se derivan a veces de los propios
objetivos del sistema:
o
Operativas, como son las restricciones fsicas, ambientales, de mantenimiento, de personal, de

seguridad, etc.
De calidad, como fiabilidad, mantenibilidad, seguridad, confidencialidad, generalidad, etc.
Sin embargo, en otras ocasiones las constricciones vienen impuestas por limitaciones en los diferentes recursos
utilizables:
Econmicos, reflejados en un presupuesto.
Temporales, que suponen unos plazos a cumplir.
Humanos.
Metodolgicos, que conllevan la utilizacin de tcnicas determinadas.
Materiales, como espacio, herramientas disponibles, etc.
Construccin de modelos: Una de las formas ms habituales y convenientes de analizar un sistema

consiste en construir un prototipo (un modelo en definitiva) del mismo.
Validacin del anlisis: A fin de comprobar que el anlisis efectuado es correcto y evitar en su caso la
posible propagacin de errores a la fase de diseo, es imprescindible proceder a la validacin del
mismo. Para ello hay que comprobar los extremos siguientes:
El anlisis debe ser consistente y completo.

9
Si el anlisis se plantea como un paso previo para realizar un diseo, habr que comprobar
adems que los objetivos propuestos son correctos y realizables.
Una ventaja fundamental que presenta la construccin de prototipos desde el punto de vista de la validacin
radica en que estos modelos, una vez construidos, pueden ser evaluados directamente por los usuarios o expertos en el
dominio del sistema para validar sobre ellos el anlisis.
2.1.2.3. Diseo de Sistemas

El diseo de sistemas se ocupa de desarrollar las directrices propuestas durante el anlisis en trminos de
aquella configuracin que tenga ms posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista
funcional como del no funcional (lo que antes hemos denominado constricciones). El proceso de diseo de un sistema
complejo se suele realizar de forma descendente:
Diseo de alto nivel (o descomposicin del sistema a disear en subsistemas menos complejos).
Diseo e implementacin de cada uno de los subsistemas:

o
Especificacin consistente y completa del subsistema de acuerdo con los objetivos

establecidos en el anlisis.
Desarrollo segn la especificacin.
Prueba.
Integracin de todos los subsistemas.
Validacin del diseo.
Dentro del proceso de diseo de sistemas hay que tener en cuenta los efectos que pueda producir la
introduccin del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseo a las
caractersticas del mismo. En este contexto est adquiriendo una importancia creciente la adaptacin de todo sistemaproducto a las capacidades de las personas que van a utilizarlo, de forma que su operacin sea sencilla, cmoda, efectiva
y eficiente. De estas cuestiones se ocupa una disciplina, la ergonoma, que tiene por objeto la optimizacin de los
entornos hombre-mquina. Si bien en un principio estaba centrada en los aspectos antropomtricos de la relacin
hombre-mquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (anlisis,
interpretacin, decisin, comunicacin y representacin del conocimiento). As, con respecto al diseo de herramientas
software, la ergonoma tiene mucho que decir en cuestiones relacionadas con la disposicin de informaciones en
pantalla, profundidad de mens, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta,
manejo de errores, estructuras de datos, utilizacin de lenguaje natural, etc.
2.1.2.4. Gestin de Sistemas

La Gestin de Sistemas se ocupa de integrar, planificar y controlar los aspectos tcnicos, humanos,
organizativos, comerciales y sociales del proceso completo (desde el anlisis y el diseo hasta la vida operativa del
sistema). Los objetivos principales de la Gestin de Sistemas suelen ser:
Planificar y controlar el proceso completo de anlisis, diseo y operacin del sistema dentro del
presupuesto, plazo, calidad y restantes condiciones convenidas.
Controlar la validez de los criterios de diseo.
Controlar la adecuacin del producto del diseo a los requisitos establecidos en el anlisis.
10
Planificar y desarrollar las necesidades de mantenimiento.
Planificar y desarrollar las necesidades de formacin del personal que va a operar el sistema.
Planificar la supervisin del funcionamiento del sistema.
En grandes proyectos de ingeniera, y dentro del mbito de la gestin, el ingeniero de sistemas suele funcionar
como asesor del director del proyecto, obteniendo, elaborando y presentando informaciones en un formato adecuado
para que ste pueda tomar las decisiones pertinentes.
2.2.
Sistemas de Informacin.
La edad de los sistemas -la edad de la sntesis Sistemas abiertos Ciberntica Sistemas homeostticos
Reglas de decisin Retroalimentacin de informacin Control automtico Diseo de sistemas Sistemas de
informacin a la gerencia.
stas y otras frases semejantes forman parte del dialecto y vocabulario de la nueva ciencia de los sistemas de
informacin a la administracin, misma que ofrece grandes promesas para enfrentarse al enorme crecimiento del
tamao, complejidad y diversidad de las operaciones de la organizacin moderna. Ese incremento de la complejidad y
del tamao, que caracteriza la moderna organizacin en gran escala, ha hecho que las funciones administrativas de
planeamiento, organizacin y control sean ms difciles de ejecutar, aunque cada vez ms indispensables para la
estabilidad y el crecimiento de las empresas actuales, en un mundo que evoluciona a pasos acelerados.
Ya sea evolutiva o revolucionaria, la era de los sistemas est con nosotros. Durante ms de cien aos -desde la
Revolucin Industrial- la administracin se ha considerado como un arte que ha progresado mediante la adquisicin y el
registro de la experiencia humana. Mediante un estudio de las situaciones administrativas y un examen de las
experiencias pasadas registradas en la literatura, se ha esperado que los gerentes y los estudiantes obtengan un
conocimiento intuitivo de los principios fundamentales de los problemas a los que tendrn que enfrentarse. Sin embargo,
los gerentes de nuestra poca necesitan ms ayuda que la que pueden encontrar estudiando las experiencias de otros. Lo
que se necesita es una ciencia fundamental o por lo menos, un enfoque mucho ms estructurado para la toma de
decisiones.
El enfoque de sistemas proporciona el proceso para reconciliar las complejidades de la -empresa moderna. Los
sistemas de informacin: a la gerencia, manuales o basados en computadoras, proporcionan los instrumentos.
Considerados en conjunto, la estructura del enfoque de sistemas y los instrumentos de los sistemas de informacin a la
gerencia suministran a los gerentes, tcnicas y modernos mtodos para el planeamiento, la organizacin, la integracin y
el control de sus operaciones en una forma, ms efectiva.
2.2.1.
Concepto de sistema, caractersticas que lo definen y su enfoque.
En el sentido ms amplio, un sistema es un conjunto de componentes que interaccionan entre s para lograr un
objetivo comn. Nuestra sociedad est rodeada de sistemas. Por ejemplo, cualquier persona experimenta sensaciones
fsicas gracias a un complejo sistema nervioso formado por el cerebro, la medula espinal, los nervios y las clulas
sensoriales especializadas que se encuentran debajo de la piel; estos elementos funcionan en conjunto para hacer que el
sujeto experimente sensaciones de fro, calor, comezn, etc. Las personas se comunican con el lenguaje, que es un
sistema muy desarrollado formador por palabras y smbolos que tiene significado para el que habla y para quienes lo
escuchan. Asimismo, las personas viven en un sistema econmico en el que se intercambian bienes y servicios por otros
de valor comparable y en el que, al menos en teora, los participantes obtienen un beneficio en el intercambio.
Una organizacin es un sistema. Sus componentes mercadotecnia, manufactura, ventas investigacin,
embarques, contabilidad y personal trabajan juntos para crear utilidades que beneficien tanto a los empleados como a los
accionistas de la compaa. Cada uno de estos componentes es a su vez un sistema. El departamento de contabilidad, por
ejemplo, quiz est formado por cuentas por pagar, cuentas por cobrar, facturacin y auditoria entre otras.
11
Todo sistema organizacional depende, en mayor o menor medida, de una entidad abstracta denominada sistema
de informacin. Este sistema es el medio por el cual los datos fluyen de una persona o departamento hacia otros y puede
ser cualquier cosa, desde la comunicacin interna entre los diferentes componentes de la organizacin y lneas
telefnicas hasta sistemas de cmputo que generan reportes peridicos para varios usuarios. Los sistemas de informacin
proporcionan servicio a todos los dems sistemas de una organizacin y enlazan todos sus componentes en forma tal que
stos trabajen con eficiencia para alcanzar el mismo objetivo.
Caractersticas que lo definen.

La finalidad de un sistema es la razn de su existencia. Existe un sistema legislativo, por ejemplo, para estudiar
los problemas que enfrentan los ciudadanos y aprobar la legislacin que los resuelva. El sistema de encendido de un
automvil tiene el claro propsito de quemar el combustible para crear la energa que emplean los dems sistemas del
automvil.
Para alcanzar sus objetivos, los sistemas interaccionan con su medio ambiente, el cual est formado por todos
los objetos que se encuentran fuera de las fronteras de los sistemas. Los sistemas que interactan con su medio ambiente
(reciben entradas y producen salidas) se denominan sistemas abiertos. En contraste, aquellos que no interactan con su
medio ambiente se conocen como sistemas cerrados. Todos los sistemas actuales son abiertos. Es as como los sistemas
cerrados existen slo como un concepto, aunque muy importante como se ver ms adelante.
El elemento de control est relacionado con la naturaleza de los sistemas, sean cerrados o abiertos. Los sistemas
trabajan mejor -"se encuentran bajo control"- cuando operan dentro de niveles de desempeo tolerables. Por ejemplo, las
personas trabajan mejor cuando su temperatura es de 37 grados centgrados. Quiz una desviacin de 37 a 37.5 grados
no afecte en mucho su desempeo aunque, en algunos casos, la diferencia puede ser notable. Una mayor desviacin, sin
embargo, tal como una fiebre de 39.5 grados, desencadena un cambio drstico en las funciones corporales. El sistema
deja de funcionar y permanece inactivo hasta que se corrija su condicin. Si esta condicin se prolonga demasiado, los
resultados pueden ser fatales para el sistema.
Este ejemplo muestra adems la importancia del control en los sistemas de todo tipo. Todos, los sistemas tienen
niveles aceptables de desempeo, denominados estndares y contra los que se comparan los niveles de desempeo
actuales. Siempre deben anotarse las actividades que se encuentran muy por encima o por debajo de los estndares para
poder efectuar los ajustes necesarios. La informacin proporcionada al comparar los resultados con los estndares junto
con el proceso de reportar las diferencias a los elementos de control recibe el nombre de retroalimentacin.
Para resumir, los sistemas emplean un modelo de control bsico consistente en:
1. Un estndar para lograr un desempeo aceptable
2. Un mtodo para medir el desempeo actual
3. Un mtodo para comparar el desempeo actual contra el estndar
4. Un mtodo de retroalimentacin
Los sistemas que pueden ajustar sus actividades para mantener niveles aceptables, continan funcionando.
Aquellos que no lo hacen, tarde o temprano dejan de trabajar.
El concepto de interaccin con el medio ambiente, que es lo que caracteriza a los sistemas abiertos, es esencial
para el control. Recibir y evaluar la retroalimentacin, permite al sistema determinar qu tan bien est operando. Si una
empresa, por ejemplo, produce como salidas productos o servicios con un precio elevado pero de baja calidad, entonces
es probable que las personas dejen de adquirirlos. En este caso, las figuras o grficas de ventas bajas son la
retroalimentacin que indica a la gerencia que es necesario efectuar ajustes, tanto en la calidad de sus productos como la
forma en la que stos se fabrican, para mejorar el desempeo, volver al camino y recobrar las esperanzas.
En contraste, los sistemas cerrados sostienen su nivel de operacin siempre y cuando posean informacin de
control adecuada y no necesiten nada de su medio ambiente. Dado que esta condicin no puede sostenerse por mucho
12
tiempo, la realidad es que no existen sistemas cerrados, El concepto, sin embargo, es importante porque ilustrar un
objetivo en el diseo de sistemas: construir sistemas que necesiten la menor intervencin del medio externo para
mantener un desempeo aceptable. Por consiguiente, la autorregulacin y el propio ajuste son objetivos de diseo en
todos los ambientes de sistemas.
Los componentes que forman un sistema pueden ser a su vez ms pequeos; es decir, los sistemas pueden estar
formados por niveles de sistemas o subsistemas. El cuerpo humano, por ejemplo contiene subsistemas tales como los
sistemas respiratorio y circulatorio. Un automvil tiene sistemas de combustin, elctricos y de control de emisiones. En
general, en situaciones de sistemas, es comn tener varios niveles de sistemas interactuando entre s.
Enfoque de sistemas.
Esencialmente, el enfoque de sistemas para la administracin se disea para utilizar el anlisis cientfico, en las
organizaciones complejas: a) para desarrollar y administrar los sistemas de operacin (por ejemplo, flujos de dinero o
sistemas de fuerza humana), y b) para disear sistemas de informacin para la toma de decisiones. Es evidente el
eslabonamiento entre esos dos procesos: el objetivo del diseo de sistemas de informacin consiste en ayudar a la toma
de decisiones relacionadas con la administracin de los Sistemas de operacin.
Un concepto fundamental del enfoque de sistemas para la organizacin y la administracin es la relacin
recproca de las partes o subsistemas de la organizacin. El enfoque comienza con una serie de objetivos y se dedica al
diseo, del todo, a diferencia del diseo, de los componentes o subsistemas. La caracterstica sinrgica del enfoque de
sistemas es muy importante. Los sistemas de organizacin e informacin se disean para lograr la sinergia, la accin
simultnea de las partes separadas, aunque recprocamente relacionadas, que produce un efecto total mayor que el de la
suma de los efectos considerados independientemente. Los resultados obtenidos por un equipo o un "sistema" de once
jugadores de ftbol son mayores que el que pueda lograr once jugadores individuales que acten sin esfuerzo integrado.
La analoga con una organizacin de negocios es muy clara.
Anteriormente, las organizaciones de negocios no alcanzaban su eficacia ptima porque no relacionaban entre
s las partes o funciones (subsistemas) ni tampoco con el todo. A veces la funcin de ventas se ejecutaba sin una
consideracin adecuada de la de manufactura. El control de produccin no se coordinaba con el planeamiento financiero
o de personal y el sistema clsico de informacin a la gerencia consista de la tabla de cuentas. El sistema de
contabilidad tradicional se ocupaba principalmente de suministrar informacin posterior a los hechos para los, estados
financieros, no de una torna de decisiones administrativas proyectada hacia lo futuro.
Ese enfoque en funciones separadas y la falta de una relacin recproca entre las partes para formar un todo
unificado-, pueden atribuirse a varias causas, principalmente a la estrechez de opiniones de los especialistas (o sea los
ingenieros, contadores y empleados de inventario), que no pueden o no quieren relacionar sus especialidades o sus
"cuadros" en la tabla de organizacin con el resto, de la compaa. Otras causas son una organizacin impropia, un mal
planeamiento o la falta de integracin de los componentes de la organizacin mediante el enfoque de sistemas. El
enfoque en el diseo del todo, a diferencia del de los componentes y subsistemas -una premisa fundamental del enfoque
de cisternas se demuestra en la figura siguiente. La lnea gruesa continua ndica las relaciones de autoridad y la
estructura jerrquica de la organizacin clsica. La principal preocupacin la constituyen las relaciones formales de la
autoridad y la cadena de mando, no las relaciones recprocas de las partes. Las lneas de puntos muestran la misma
estructura de la organizacin, con las rutas unidas en un sistema, mediante el flujo de informacin y el enfoque de
sistemas para la organizacin y la administracin.
13
La figura no debe hacer que el lector llegue a la conclusin de que la distincin entre el enfoque "clsico" y el
de "sistemas" sea clara y absoluta. En realidad, el enfoque clsico siempre ha tenido en cuenta el intercambio de rutina
de informacin a travs de la cadena de mando. Las copias de las rdenes de ventas se han enviado a los departamentos
de crdito, planes de produccin, embarques y cuentas por cobrar. Los presupuestos se han hecho con vista a lo futuro y
han incluido las partes separadas de la organizacin. Sin embargo, aunque proporcionan cierto grado de integracin y de
coordinacin, esos mecanismos no, fueron sinrgicos y no lograron el grado de refinamiento de las tomas de decisiones
que queremos obtener con el enfoque de sistemas.
El enfoque de sistemas para la solucin de problemas incluye 1) una filosofa de enfoque, y 2) un mtodo de
diseo de sistemas para la solucin de problemas. La filosofa consiste en ver siempre el problema y sus componentes en
su totalidad relacionada, no como partes. Thome y Willard han descrito ese enfoque:
El enfoque de sistemas es una forma ordenada de valorar una necesidad humana de ndole compleja, en un
estado de nimo de esperemos y estudiemos la situacin desde todos los puntos de vista", preguntndonos:
Cuntos elementos distinguibles tiene este aparente problema?
Qu relaciones de causa y efecto hay entre esos elementos?
Qu funciones hay que ejecutar en cada caso?
Qu intercambios pueden requerirse entre los recursos despus de que se definan?
Como el enfoque de sistemas se dedica al diseo, del todo, se ocupa de las relaciones antes de perfeccionar los
componentes. Para explicar este punto consideremos el "ardiente" expendio de carnes al carbn. De acuerdo con el
antiguo enfoque de componentes, la administracin trataba de hacer lo siguiente:
14
1. Optimizar la zona de cocimiento y el proceso.

2. Optimizar el proceso de servicio.
3. Optimizar la zona del comedor y el proceso de recoleccin del dinero.
As, pues, las instalaciones de cocina podran ser excelentes, pero seran muy inconvenientes e ineficientes para
dar servicio a los clientes. El proceso de servicio podra ser excelente, pero la zona del, comedor pudiera estar dispuesta
de tal modo para atender a los clientes y para el cobro del consumo que el servicio no podra adaptarse o integrarse a la
misma.
En este caso, qu hizo la gerencia? Expres los objetivos del sistema o sea, servir al cliente alimentos bien
preparados en un ambiente agradable. Mediante la revisin de todo el sistema la gerencia decidi que los clientes
deberan ordenar primero sus alimentos fros y luego los calientes, ambos en un mostrador de cafetera. Mientras la
carne se prepara al gusto, los clientes pagan la cuenta y se les da un recibo numerado. Llevan los alimentos fros a la
zona del comedor y recogen sus platillos calientes cuando se les llama por nmero. Con ese diseo, de sistema se logra
la eficiencia del sistema total de produccin a bajo costo para la clientela. Hay que notar el intercambio entre el manejo
material de los alimentos por el restaurante y la economa para el cliente. Adems, el mtodo de toma de pedidos, cobro
del consumo y cocinado queda estrechamente integrado en el sistema.
Es imposible dar instrucciones exactas para el diseo de un sistema como el que acabamos de citar; en vez de
ello puede desarrollarse un procedimiento generalizado y una serie de lineamientos que sirvan de gua. El diseador de
sistemas desarrolla el arte de enfrentarse a los problemas de un sistema, en gran parte mediante la experiencia, y sus
mtodos pueden variar desde un sencillo razonamiento de sentido comn hasta las tcnicas ms refina-das de la
investigacin de operaciones. Bsicamente, sin embargo, el enfoque de sistemas es una aplicacin sistemtica del
intelecto, de las tcnicas y de los instrumentos a fin de lograr la integracin de los componentes para un fin especificado.
2.2.2.
Concepto y funcin de un sistema de informacin.
En la prctica se dispone de una gran variedad de, sistemas de informacin que soportan los aspectos
administrativos y de control de las organizaciones: por ejemplo, en una fbrica se tendran los siguientes sistemas
principales:
Funcin
Sistema
Almacn.
Control de inventarlos.
Produccin.
Planeacin y control de la produccin.
Compras.
Proceso de rdenes y seguimiento de las compras.
Ventas
Facturacin y control de crditos.
Contabilidad.
Registro de afectaciones contables y emisin de informes.
Personal.
Nminas y administracin de personal.
Por lo general, en estos sistemas los datos se registran en documentos fuente que representan las actividades y
acontecimientos ocurridos durante el flujo de operaciones de la organizacin. Estos sistemas pueden pasar por un flujo
que permita su procesamiento electrnico y con ello tratar de satisfacer las necesidades de informacin de la
organizacin. Cabe hacer notar que estos sistemas normalmente estn relacionados unos con otros; las salidas de un
sistema pueden ser transacciones de entrada de otro sistema y durante el diseo de sistemas es de vital importancia
identificar estas relaciones.
15
Los sistemas, segn su naturaleza, se clasifican en los grupos siguientes:
Determinsticos.
Probabilsticas.
Abiertos.
Cerrados.
Hasta cierto punto la clasificacin no tiene mayor importancia, pero es imperativo que dentro de los sistemas
exista la dinmica suficiente para responder a los cambios que emanan, ya sea de forma externa y/o interna. Esto es
esencial en las organizaciones modernas, pues en la poca actual se registran cambios sustanciales, ya sean sociolgicos,
tcnicos, econmicos o legales, que modifican las polticas y funciones de las organizaciones.
El proceso de diseo de los sistemas de informacin comprende tanto el diseo de uno nuevo como el rediseo
de un sistema que se encuentre en operacin. Un nuevo sistema se requiere cuando la organizacin inicia sus
operaciones o cuando una nueva divisin solicita por primera vez el proceso de datos de un cierto sistema. Los sistemas
en operacin normalmente necesitan ser rediseados o modificados parcialmente en forma peridica para asegurar que
estn acordes con lo actual y no con los requerimientos histricos. Una organizacin se puede clasificar como un sistema
total, y sus subsistemas son:
Subsistema administrativo.
Subsistema operativo.
Subsistema de informacin.
stos deben interrelacionarse para lograr las metas y objetivos de la organizacin.
El subsistema de informacin tiene una funcin muy importante dentro de la organizacin:
16
1.
Debe proporcionar informacin confiable y oportuna para que el subsistema administrativo tome un
nivel adecuado de decisiones.
2.
Debe monitorear el subsistema operativo para conocer los resultados reales obtenidos y proporcionar
informacin sobre las operaciones que da con da tiene que realizar la organizacin.
3.
Debe comparar los resultados reales con los planeados y proporcionar informacin que ayude a
corregir las desviaciones incurridas.
Tradicionalmente los sistemas computacionales de informacin se han desarrollado bajo metodologas distintas,
producto de la experiencia del personal especialista; sin embargo, en los ltimos aos ha nacido una serie de nuevas
disciplinas (tecnologa de informacin, ingeniera de software, etc.) que tienen como finalidad proporcionar una
metodologa formal e ingenieril para desarrollar sistemas computacionales de informacin de manera eficiente y
efectiva.
2.2.3.
Tipos de sistemas de informacin.
Aunque muchas compaas y organizaciones estn haciendo grandes esfuerzos para extender las aplicaciones
de las computadoras fuera de las zonas que actualmente se consideran comprobadas y de rutina, de todos modos la gran
mayora de los sistemas de informacin (ya sean manuales o basados en computadoras) continan en las categoras que
veremos a continuacin. Ordinariamente la obtencin y diseminacin de la informacin es el problema ms difcil de la
compaa. La informacin es voluminosa, esparcida, y a menudo difcil de obtener. Si los gerentes quedan envueltos en
el papeleo, no tendrn tiempo para llevar a cabo la valoracin, el planeamiento o la toma de decisiones. Su trabajo ser
una constante bsqueda de informacin para manejar las diversas crisis que se presenten, adems del flujo normal del
trabajo.
Con el transcurso del tiempo las empresas tpicas han desarrollado los sistemas principales de informacin que
muestra la tabla 1-1, para proporcionar informacin de planeamiento, de operacin y de control para los tomadores de
decisiones de toda la organizacin. Esos sistemas principales son los siguientes:
1.
financiero,
2.
de produccin o de operaciones,
3.
de mercadotecnia,
4.
de personal,
5.
de control de proyectos y
6.
otros sistemas secundarios.
Esos sistemas no son separados ni distintos, sino que conectan, interactan y renen los subsistemas de la
organizacin con el medio de la informacin. Tambin hay que notar que aunque esos sistemas principales sirven para
integrar las funciones bsicas de planeamiento, operacin y control, la mayor parte de los mismos se disean y utilizan
primordialmente para una o dos de esas funciones.
17
SISTEMAS Y SUBSISTEMAS PRINCIPALES DE INFORMACIN

SISTEMA
USOS PRINCIPALES
SUBSISTEMA
Planeamiento
Operacin
FINANZAS
Presupuestacin de efectivo
x
x
Presupuestacin de capital
x
Contabilidad de costos
x
Planeamiento de utilidades
x
x
Contabilidad de responsabilidad
x
x
Contabilidad de costeabilidad
x
x
PRODUCCIN/OPERACIONES
Planeamiento de produccin
x
x
Inventario,
x
x
Compras
x
x
Distribucin
x
x
MERCADOTECNIA
Planeamiento de ventas
x
Ventas y facturacin
x
Anlisis de ventas
x
Control de crdito
Investigaciones de mercado
x
PERSONAL
Registros de personal
x
Nmina
x
Empleo
x
Colocacin
x
Adiestramiento
x
Mantenimiento y materiales
x
CONTROL DE PROYECTOS
PERT/CPM, costo, tiempo, etctera
x
x
OTRAS INVESTIGACIONES
Y DESARROLLOS
x
Planeamiento, estratgico
x
Simulacin
x
2.3.
Control
x
x
x
x
x
x
x
x
x
x
Importancia de los sistemas de informacin en la toma de decisiones
La toma de decisiones es un trmino reservado para la accin de elegir entre varias alternativas. La toma de
decisiones es un proceso de pensamiento que ocupa toda la actividad que tiene por finalidad la solucin de problemas.
Todo aspecto que refleja el esfuerzo humano involucra actividades con un propsito en las que deben resolverse
los problemas y tomar decisiones. La toma de decisiones puede verse como un procedimiento, un ciclo que contiene
varios crculos.
La toma de decisiones es necesaria cuando tenemos un problema que resolver, o necesidades que satisfacer. El
paso para definir el problema, puede considerarse como un subproblema del problema principal, es decir, un circuito
dentro de otro circuito, en el ciclo de la toma de decisiones.
Los sistemas de informacin son de vital importancia en cualquier tipo de informacin ya que nos proporciona
las herramientas necesarias para que un tomador de decisiones pueda realizar su trabajo ptimamente.
Ya que dichos sistemas al proporcionar la informacin necesaria en el preciso momento y con la mayor
eficiencia posible, ayuda a que la empresa crezca y se desarrolle.
18
2.3.1.
Teora de la Informacin
Es la teora relacionada con las leyes matemticas que rige la transmisin y el procesamiento de informacin, es
decir, la teora de la informacin se ocupa de la medicin de la informacin y de su forma de representarla, y de la
capacidad de los sistemas de comunicacin para transmitir y procesar informacin.
La codificacin se refiere tanto a la transformacin de imagen o voz en seales elctricas, como al cifrado de
mensajes para asegurar su privacidad.
Esta teora de la informacin, fue desarrollada por 1948, por el ingeniero Claude E. Shannon. La necesidad de
una base terica para la tecnologa de la comunicacin, surgi del aumento de la complejidad y de la masificacin de las
vas de comunicacin (telfono, radio, redes). La teora de la informacin abarca todas las formas de transmisin y
almacenamiento de informacin, como la televisin, en la grabacin de imgenes.
El trmino informacin, se refiere a los mensajes transmitidos: voz o msica transmitida por radio o telfono,
imgenes transmitidas por televisin, informacin digital, en sistemas y redes de computadoras.
La teora de la informacin ha sido aplicada en diferentes campos como la ciberntica, la lingstica, sicologa,
etc.
2.3.2.
Por que necesitan informacin las empresas
Las organizaciones operan en un mundo de desaciertos e intervencin gubernamental, de polticas

impredecibles a nivel monetario, fiscal, impositivo y regulador; de ciclos de negocios y recesiones; de cambios abruptos
en las polticas comerciales; de competencia domstica e internacional; y de crecientes costos laborales. A decir
verdad, este es un ambiente implacable y competitivo en el que deben sobrevivir las organizaciones.
Para evitar el fracaso, sobrevivir, y lograr el xito, las organizaciones deben explorar las dimensiones de la
oportunidad de una gerencia informada, de la diferenciacin de productos y servicios de una creciente productividad.
Claramente, la informacin es el arma principal que ayudar a la gerencia, a los productos, a los servicios y a la
productividad a penetrar en el ambiente competitivo.
El encanto de la tecnologa informtica no har avanzar estas dimensiones, pero s lo har la necesidad de
contender y sobrevivir en un ambiente competitivo y violento, un ambiente que incluye una competencia internacional
ms fuerte. Debe quedar claro que las computadoras, la tecnologa informtica y la informacin de calidad no son los
fines sino simplemente las armas competitivas que apoyan a las organizaciones para alcanzar las metas de los gerentes
triunfadores, de productos y servicios excelentes y de una mayor productividad, y del xito a final de cuentas.
Cualquiera que sea la organizacin, las compaas que producen la informacin de la ms alta calidad,
permanecern como las ms fuertes competidoras del ramo. Por otra parte, si una compaa no puede mejorar su
informacin, quedar a la zaga de aquellas que si pueden.
2.4.
Conceptos y Anlisis.
Es un conjunto o disposicin de procedimientos o programas relacionados de manera que juntos forman una
sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan
lgico en la unin de las partes. Un mtodo, plan o procedimiento de clasificacin para hacer algo. Esto se lleva a cabo
teniendo en cuenta ciertos principios:
Debe presentarse y entenderse el dominio de la informacin de un problema.
Defina las funciones que debe realizar el Software.

19
Represente el comportamiento del software a consecuencias de acontecimientos externos.
Divida en forma jerrquica los modelos que representan la informacin, funciones y comportamiento.
El proceso debe partir desde la informacin esencial hasta el detalle de la Implementacin.

La funcin del Anlisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que
pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadoras hace uso de
seis (6) elementos fundamentales:
1.
Software, que son Programas de computadora, con estructuras de datos y su documentacin que hacen
efectiva la logstica metodologa o controles de requerimientos del Programa.
2.
Hardware, dispositivos electrnicos y electromecnicos, que proporcionan capacidad de clculos y

funciones rpidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.),
que proporcionan una funcin externa dentro de los Sistemas.
3.
Personal, son los operadores o usuarios directos de las herramientas del Sistema.
4.
Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al Sistema a las que se
accede por medio del Software.
5.
Documentacin, Manuales, formularios, y otra informacin descriptiva que detalla o da instrucciones

sobre el empleo y operacin del Programa.
6.
Procedimientos, o pasos que definen el uso especfico de cada uno de los elementos o componentes
del Sistema y las reglas de su manejo y mantenimiento.
Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente:
Identifique las necesidades del Cliente.
Evale que conceptos tiene el cliente del sistema para establecer su viabilidad.
Realice un Anlisis Tcnico y econmico.
Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema.
Establezca las restricciones de presupuestos y planificacin temporal.
Cree una definicin del sistema que forme el fundamento de todo el trabajo de Ingeniera.
Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del Hardware y el Software, as
como de la Ingeniera humana (Manejo y Administracin de personal), y administracin de base de datos.
2.5.
Objetivos del Anlisis.
2.5.1.
Identificacin de Necesidades.
Es el primer paso del anlisis del sistema, en este proceso en Analista se rene con el cliente y/o usuario (un
representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las
20
perspectivas del cliente, sus necesidades y requerimientos, sobre la planificacin temporal y presupuestal, lneas de
mercadeo y otros puntos que puedan ayudar a la identificacin y desarrollo del proyecto.
Reconocimiento del problema.
Evaluacin y Sntesis.
Modelado.
Especificacin.
Revisin.
Antes de su reunin con el analista, el cliente prepara un documento conceptual del proyecto, aunque es
recomendable que este se elabore durante la comunicacin Cliente analista, ya que de hacerlo el cliente solo de todas
maneras tendra que ser modificado, durante la identificacin de las necesidades.
2.6.
Metodologas y Herramientas para el Anlisis y Diseo de Sistemas.
El desarrollo de sistemas pequeos, en la cual participan una o dos personas, es una tarea simple. Los cambios
naturales que surgen durante el ciclo de desarrollo del sistema no producen una gran propagacin de cambios en el
sistema. Sin embargo, si el sistema es grande y en su desarrollo participan varios grupos de personas desarrollando una
tarea especfica, hay que tener en cuenta no solo la comunicacin con el usuario sino tambin la interrelacin entre los
distintos grupos de trabajo.
Algunos de los problemas comunes que los desarrolladores encuentran en la construccin de software de cierta
complejidad son los siguientes:
El dominio de aplicacin no es conocido.
La comunicacin con el usuario.
La comunicacin con el grupo de desarrollo.
La carencia de buena documentacin.
Por esta razn, es necesario seguir una serie de pasos sistemticos para que los diferentes grupos de desarrollo
posean una buena comunicacin. Estos pasos son brindados por los modelos de ciclo de vida, los cuales estn
constituidos por diferentes etapas, por ejemplo:
Especificacin de requerimientos: Se realizan entrevistas con el usuario identificando los requerimientos y
necesidades del usuario.
Anlisis: Modela los requerimientos del usuario.
Diseo: Se modela la solucin del sistema, teniendo en cuenta el ambiente de implementacin a utilizar, por
ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar, lenguaje de programacin, performance
deseada, etc.
Implementacin: Dado el lenguaje de programacin elegido se implementa el sistema.
Testeo: En esta etapa se verifica y valida el sistema teniendo en cuenta algunos criterios determinados por el
grupo correspondiente.
21
Mantenimiento: Es la etapa ms difcil de desarrollo del sistema, actualiza y modifica el sistema si surgen
nuevos requerimientos.
Existen varios mtodos para describir el ciclo de vida de un sistema, uno de ellos es el desarrollo estructurado
en cascada.
2.6.1.
Modelo en Cascada.
Fig. 2.1.: Modelo de ciclo de vida en Cascada.
En un principio fue de gran utilidad pero el problema es que para pasar de una etapa a la otra haba que terminar
la primera, produciendo un gran problema si algn cambio era requerido. La etapa de Mantenimiento consuma el 80%
del costo de produccin.
Debido a los nuevos requerimientos en el desarrollo de software, surgieron muchos otros modelos que trataban
de solucionar los problemas existentes, que se basaron en el modelo en Cascada. Por ejemplo, el Modelo en Espiral, en
el cual el sistema se desarrolla incrementalmente (Fig. 2.2.).
Los modelos propuestos poseen bsicamente las mismas etapas, pero varan en:
los mtodos y herramientas utilizadas en cada actividad
los controles requeridos, paralelismo en las actividades
las salidas de cada etapa
22
No es aconsejable elegir un modelo y seguirlo al detalle sino que se debe adaptar a las caractersticas del
proyecto que esta siendo desarrollado.
Fig.2.2.: Modelo de ciclo de vida en Espiral
2.6.2.
Modelo Espiral.
El modelo espiral para la ingeniera de software ha sido desarrollado para cubrir las mejores caractersticas
tanto del ciclo de vida clsico, como de la creacin de prototipos, aadiendo al mismo tiempo un nuevo elemento: el
anlisis de riesgo. El modelo representado mediante la espiral de la figura 2.3, define cuatro actividades principales:
1.
Planificacin: determinacin de objetivos, alternativas y restricciones.
2.
Anlisis de riesgo: anlisis de alternativas e identificacin/resolucin de riesgos.
3.
Ingeniera: desarrollo del producto del "siguiente nivel",
4.
Evaluacin del cliente: Valorizacin de los resultados de la ingeniera.
Fig. 2.3.: Modelo Espiral
23
Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y
se analizan e identifican los riesgos. Si el anlisis de riesgo indica que hay una incertidumbre en los requisitos, se puede
usar la creacin de prototipos en el cuadrante de ingeniera para dar asistencia tanto al encargado de desarrollo como al
cliente.
El cliente evala el trabajo de ingeniera (cuadrante de evaluacin de cliente) y sugiere modificaciones. Sobre la
base de los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. En cada bucle
alrededor de la espiral, la culminacin del anlisis de riesgo resulta en una decisin de "seguir o no seguir".
Con cada iteracin alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se
construyen sucesivas versiones del software, cada vez ms completa y, al final, al propio sistema operacional.
El paradigma del modelo en espiral para la ingeniera de software es actualmente el enfoque ms realista para el
desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniera de software,
permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creacin
de prototipos como un mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a quien lo desarrolla
aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin de prototipos.
2.6.3.
Modelo Prototipo.
Este modelo se describe de la siguiente manera: Una alternativa de enfoque para la definicin de los
requerimientos consiste en capturar un conjunto inicial de necesidades e implementarlas rpidamente con la intencin
declarada de expandirlas y refinarlas iterativamente al ir aumentando la compresin que del sistema tienen los usuarios y
quien lo desarrolla. La definicin del sistema se realiza el descubrimiento evolutivo y gradual y no atrevas de la
previsin omnisciente... Este tipo de enfoque se llama "de prototipos". Tambin se le conoce como modelado del
sistema o desarrollo heurstico. Ofrece una alternativa atractiva y practicable a los mtodos de especificacin para tratar
mejor la incertidumbre, la ambigedad y la volubilidad de los proyectos reales.
Dentro del enfoque de prototipos se pretende que el modelo sea operante, es decir, una coleccin de programas
de computadora que simulan algunas o todas las funciones que el usuario desea. Para lograr lo anterior se utilizan las
siguientes herramientas de software:
Un diccionario de datos integrado
Un generador de pantallas
Un generador de reportes no guiado por procedimientos
Un lenguaje de programacin de cuarta generacin
Un lenguaje de consultas no guiado por procedimientos
Medios poderosos de administracin de base de datos
El modelo de prototipos se muestra en la figura 2.4 Comienza con una actividad de sondeo; de esto sigue una
determinacin de s el proyecto es un buen candidato para un enfoque de prototipos. Los buenos candidatos son aquellos
que tienen las siguientes caractersticas:
El usuario no puede o no est dispuesto a examinar modelos abstractos en papel, tales como
diagramas de flujo de datos.
El usuario no puede o no est dispuesto a articular sus requerimientos de ninguna forma y slo se
pueden determinar sus requerimientos mediante un proceso de tanteo, o ensayo y error.
24
Se tiene la intencin de que el sistema sea en lnea y con operacin total por la pantalla, en
contraposicin con los sistemas de edicin, actualizacin y reportes operados por lote.
El sistema no requiere la especificacin de grandes cantidades de detalles algortmicos, ni de muchas

especificaciones de procesos para describir los algoritmos con los cuales se obtienen resultados.
Fig.2.4.: Modelo Prototipo

Este modelo concluye con una fase de diseo. Con el cual se tiene la intencin de que se modelen los
requerimientos del usuario.
2.6.4.
Metodologa ASML (A System Modeling Language)
ASML es una metodologa de desarrollo estructurado de sistemas que cubre todo el ciclo de vida de desarrollo.
Esta metodologa integra las principales ideas del Anlisis Estructurado y el Diseo Estructurado en un marco
conceptual nico y consistente.
Si bien la definicin original de la metodologa puede reconocerse en los libros de Ward y MacMenamim, le
cabe una mejor definicin al ser interpretada como: la conjuncin del Anlisis Estructurado Moderno y el Diseo
Estructurado, con extensiones para el modelado de sistemas de tiempo real.
Estructura de la Metodologa
ASML es una metodologa que integra todas las ideas involucradas en el anlisis y diseo estructurado.
Conjuga las tcnicas y herramientas de modelado usadas en el Anlisis EstructuradoModerno y en el Diseo
Estructurado dentro de una organizacin que destaca los diferentes modelos necesarios para: obtener una buena
comprensin del problema, y disear una solucin de buena calidad (mantenible, adaptable, etc.). Separa el modelado de
un sistema en una jerarqua de modelos necesarios para comprender diferentes propiedades del mismo. Dicha jerarqua
de modelos se presenta en la Fig. 2.5.
25
Fig. 2.5.: Jerarqua de Modelos
El Modelo del Sistema est dividido en dos modelos generales:
El Modelo Esencial: Representa la etapa de Anlisis Estructurado. Construccin de un modelo libre de

detalles tecnolgicos.
El Modelo de Implementacin: Representa la etapa de Diseo Estructurado. Instanciacin de un

Modelo Esencial con una tecnologa dada.
1.
El Modelo Esencial
Puede ser considerado como la aplicacin de la metodologa de Anlisis Estructurado Moderno de Yourdon. La
idea fundamental con la que el modelo esencial es concebido es la de Tecnologa Perfecta en la cual no hay restricciones
de cantidad de memoria, tamao del disco o velocidad del procesador. Dos modelos componen el modelo esencial:
El Modelo del Ambiente: Declaracin de los objetivos. Creacin de un Diagrama de Contexto y de

una Lista de Eventos, describe los estmulos que recibe el sistema y las respuestas generadas por los
estmulos. Definicin del Diccionario de Datos inicial. Tabla de Estmulo-Respuesta.
El Modelo de Comportamiento: Creacin de un DFD, y un ERD por cada uno de los eventos de la
Lista de Eventos. Los DFD's por eventos se unen en un nico DFD (el Modelo Funcional) y los DER's
por eventos se unen en un nico ERD (el Modelo de Datos). Se acostumbra, tambin, modelar el
comportamiento externo del sistema con DTE, rboles de pantallas o menes, etc. La creacin
simultnea del modelo de datos, modelo funcional y modelo de interfaz o comportamiento externo,
ayuda en la validacin y completitud del modelo esencial (descubriendo, por ejemplo, eventos no
considerados).
26
Todos los criterios de modelado y, principalmente de validacin, descriptos en la metodologa de Anlisis

Estructurado Moderno pueden (y deben) ser aplicados en esta etapa para obtener un modelo esencial de calidad y que
sea consistente.
2.
El Modelo de Implementacin
A partir de esta etapa, el modelo esencial es instanciado en una tecnologa dada. Se debe considerar ahora, las
imperfecciones de la tecnologa y determinar: la cantidad de procesadores necesarios, las cualidades de estos
procesadores, el tamao de disco necesario de acuerdo al volumen de la informacin a ser almacenada, etc. Luego se
disea la solucin sobre la base de esas restricciones tecnolgicas.
La creacin del modelo de implementacin se fundamenta en la creacin de tres modelos, uno de ellos en forma
independiente (el modelo del usuario o de la interfaz hombre-mquina) y los otros dos en forma encadenada en un
proceso incremental de refinamiento e incorporacin de detalles:
El Modelo del Usuario: La interfaz hombre-mquina es modelada en todos sus detalles, estilo (rboles
de mens, lenguajes de comandos, manipulacin directa, etc.), lay-out y formato de pantallas, formato
de informes y listados, diseo de pantallas para el ingreso de datos y presentacin de resultados, estilo
de mensajes de error, secuencialidad, etc. La creacin de este modelo es independiente del resto de los
modelos que conforman el de implementacin, y puede ser desarrollado en paralelo. Las interfaces
deben ser diseadas para cada uno de los procesadores (del modelo de procesadores) y para cada una
de las tareas (del modelo de tareas).
Es el punto de inflexin entre la etapa de anlisis y la etapa de diseo. El modelo de
implementacin del usuario especifica un conjunto de restricciones que el usuario desear
imponer al grupo de desarrollo y condicionarn al diseador.
Define la interfaz hombre-mquina que es modelada en todos sus detalles, estilo (rboles
de menes, lenguajes de comandos, manipulacin directa, etc.), lay-out y formato de pantallas,
formato de informes y listados, diseo de pantallas para el ingreso de datos y presentacin de
resultados, estilo de mensajes de error, secuencialidad, etc. La creacin de este modelo es
independiente del resto de los modelos que conforman el de implementacin, y puede ser
desarrollado en paralelo. Las interfaces deben ser diseadas para cada uno de los procesadores (del
modelo de procesadores) y para cada una de las tareas (del modelo de tareas).
Los aspectos ms importantes que se especifican en el modelo de implementacin del
usuario son:
o
Delimitacin de la frontera de automatizacin: distribucin del modelo esencial entre

personas y mquinas: el usuario puede tomar diferentes actitudes frente a este punto, pero
lo que debe tenerse presente es que siempre es el usuario el que finalmente tiene la
responsabilidad de fijar la frontera de automatizacin. El usuario puede fijar entre las
siguientes alternativas
Al usuario no le interesa donde est la frontera de automatizacin, dejando librado

al diseador la decisin de establecerla.
El usuario escoge un sistema totalmente automatizado
El usuario escoge un sistema totalmente manual
Detalle de la interaccin humano-mquina: especifica todos los aspectos del diseo de la

interfaz entre el sistema y el entorno. Los aspectos mas importantes a considerar en este
punto son:
Eleccin de dispositivos de E/S

27
Formato de las entradas que fluyen desde los terminadores hasta el sistema
Formato de las salidas que fluyen desde el sistema hacia los terminadores
Secuencia y tiempos de entradas y salidas en un sistema en lnea, navegaciones de

pantalla
Mtodos de codificacin a utilizar para el ingreso de datos
Actividades de apoyo manual que se podran requerir: actividades no esenciales que

deben agregarse al sistema por no disponerse de una tecnologa perfecta e ideal. Pueden
representarse como burbujas adicionales en el modelo esencial. Los casos tpicos son:
Controles de posibles fallas humanas/tcnicas (ingreso de datos al sistema,

realizacin de clculos, dispositivos de almacenamiento, salida de datos del
sistema)
Operacin del sistema en produccin
Restricciones operativas que el usuario desea imponer al sistema: son restricciones que
afectarn la configuracin de hw, sistema operativo, telecomunicaciones, lenguaje de
programacin. Los aspectos tpicos son:
Volumen de los datos
Tiempo de respuesta en sistemas On-line
Restricciones polticas sobre modalidades de implantacin
Restricciones ambientales
Restricciones de seguridad y confiabilidad (mtbf, mttr)
Restricciones de seguridad (controles de acceso al sistema)
Agregado de procesos de arranque y apagado del sistema.
El Modelo de Distribucin: Describe todas las decisiones relativas a la arquitectura de hardware

(modelo de procesadores) y a la estructuracin general de la arquitectura de software (modelo de
tareas). Se incorporan, en los modelos creados hasta este punto algunas Distorsiones destinadas a
optimizar el uso de esa tecnologa. El criterio fundamental es: Minimizar todo lo posible las
distorsiones agregadas.
El Modelo de Procesadores: Asigna el modelo esencial a distintos procesadores y determina la

arquitectura de comunicacin entre ellos. Implica la asignacin de procesos y almacenes a los
procesadores.
El modelo comportamental (modelo de datos, modelo funcional y modelo de
comportamiento externo o de interfaz) es subdividido por procesadores. Se aplican criterios
cualitativos (por ejemplo: necesidad de monitores de alta resolucin grfica) y cuantitativos (por
ejemplo: velocidad del procesador, volumen de informacin almacenada, etc.) para seleccionar los
procesadores, sistemas operativos, software y hardware de red, etc. Las distorsiones agregadas
corresponden a la particin del DFD, ERD, DTE en procesadores, refinamiento de procesos y
entidades o depsitos de datos (para asociar parte en un procesador y parte en otro) y a la
incorporacin de procesos para el control de la comunicacin entre procesadores (siempre que la
tecnologa no solucione el problema de manera transparente).
28
Segn la cantidad de procesadores utilizados y las formas de comunicacin entre ellos se

tienen distintas configuraciones.
Tipos de configuracin tpicas:
o
Centralizada (host based)
Descentralizada
Mixta
Distribuida
Cliente/Servidor
Centralizada: Asigna el modelo esencial completo a un nico procesador central.
Descentralizada: Se asignan partes del modelo esencial a diferentes procesadores

los cuales trabajan en forma independiente.
En el caso de almacenes que deban ser compartidos por procesos asignados a
diferentes procesadores, los mismos debern duplicarse, y mantenerse copias actualizadas
en cada procesador.
Mixta: Puede darse una combinacin de los casos anteriores. Es comn la
existencia de un sistema central que consolida toda la informacin de la organizacin y
que en diferentes unidades operativas que no este conectadas a dicho procesador central
existan sistemas satlites que implementan algunos procesos con almacenes con datos
locales.
Distribuida: Se asignan partes del modelo esencial a diferentes procesadores los
cuales estn comunicados de alguna forma y sobre los que corre un sistema operativo
distribuido. En este caso el usuario ve al conjunto de procesadores como un nico recurso
computacional.
Cliente/Servidor: Se distribuyen partes del proceso en diferentes procesadores. El
esquema ms genrico de distribucin cliente-servidor distribuye el modelo del sistema
en tres niveles: presentacin, lgica del negocio, y acceso a base de datos. Los dos
esquemas cliente-servidor ms utilizados en la actualidad son:
C/S 2 niveles: Servidor de B.D. / Aplicacin-Presentacin en Estacin de
Trabajo C/S 3 niveles: Servidor de B.D. / Servidor de Aplicacin / Presentacin en
Est.Trab.
Tipos de configuracin de comunicacin entre procesadores:

o
Conexin directa entre procesadores (canal / red local / otros)
Enlace de telecomunicaciones entre procesadores
Enlace indirecto: los datos son transferidos de un procesador a otro va algn

medio de almacenamiento (cinta, cd, diskette, etc.)
Factores que influyen en la configuracin de procesadores:

29
Costo
Eficiencia
Seguridad (procesadores y datos en lugares seguros)
Confiabilidad (separar los procesos en varios procesadores,

redundantes) - Restricciones polticas y operacionales.
procesos
El Modelo de Tareas: Los modelos resultantes de la creacin del modelo de procesadores son
estudiados por separado (un procesador por vez), para determinar tareas diferentes (que sern
programas diferentes de manera tal que se pueden ejecutar concurrentemente o no). La distorsin
agregada en esta etapa representa la subdivisin del modelo funcional de un procesador (el DFD) en
distintos DFD's (uno por tarea), agrupando procesos batch, interactivos o de tiempo real, partes del
DFD aisladas del resto (comunicacin solamente a travs de depsitos de datos), etc. Adems, es
probable que sea necesario agregar procesos de control de concurrencia y sincronizacin para el
acceso a recursos compartidos (como por ejemplo los depsitos de datos).
Dentro de cada procesador definido en el modelo anterior, deben asignarse procesos a
diferentes tareas o particiones.
En muchos sistemas operativos modernos, el manejo de tareas es transparente al
desarrollador.
Las tareas pueden categorizarse tpicamente en Interactivas, Batch, y en Tiempo Real.
Para la mayora de los sistemas administrativos es importante determinar que partes del modelo
esencial se asignaran a tareas interactivas y cuales a tareas batch.
La comunicacin entre tareas normalmente es provista va el sistema operativo.
El Modelo de Programas: La estructura del programa que implementa cada una de las tareas
resultantes de las etapas de modelado de procesadores y tareas, es diseada mediante la aplicacin de
las tcnicas y estrategias descriptas por el Diseo Estructurado (por ejemplo: Anlisis de
Transformaciones y Transacciones) y mejorada con la aplicacin de criterios de calidad (por ejemplo:
Cohesin, Acoplamiento, etc.).
30
Fig. 2.6.: Secuencia de Creacin de Modelos
2.7.
Mtodos de desarrollo de Software.

Los mtodos de desarrollo de software pueden dividirse en dos grupos: funcin/dato y orientados a objetos.
Orientado a Funcin/Dato.
Aquellos mtodos en los cuales las funciones y/o los datos son tratados como entidades independientes. Estos
sistemas resultan difciles de mantener. El mayor problema es que las funciones generalmente dependen de la estructura
de los datos. A menudo diferentes tipos de datos tienen distintos formatos y se necesita verificar el tipo del dato (con
sentencias If-Then o CASE), produciendo programas difciles de leer y modificar. Si se desea hacer alguna modificacin
en la estructura de los datos se debe modificar en todos los lugares donde es utilizado.
Otro problema es que una persona no piensa naturalmente en trminos de una estructura. La especificacin de
requerimientos se hace en lenguaje comn, se especifica la funcionalidad que debe tener el sistema y no en cmo se
deben estructurar los datos.
Orientado a Objetos: Son aquellos mtodos en los cuales datos y funciones estn altamente relacionados. El
nfasis est centrado en la abstraccin de datos. Se piensa en forma natural, los objetos son mapeados a entidades del
mundo real. Los programas son fcilmente mantenibles y extensibles por medio de la construccin de subclases.
31
3.
Definicin del Proyecto de Sistemas.
3.1.
Razones para iniciar proyectos de Sistemas de Informacin
La siguiente tabla muestra las causas por las cuales las organizaciones toman la decisin estratgica de bordar
proyectos sobre sistemas de informacin en funcin de los parmetros mejorables de sta.
Capacidad.
Mayor velocidad de procesamiento
Incremento en el volumen
Recuperacin ms rpida de la informacin
Control.
Mayor exactitud
Mejora de la consistencia
Comunicacin.
Mejoras en la comunicacin
Integracin de reas de la empresa
Costos.
Monitorizacin de costos
Reduccin de costos
Ventajas competitivas.
Atraer clientes
Dejar fuera a la competencia
Mejores acuerdos con los proveedores
Desarrollo de nuevos productos
Por todo ello es importante conocer como se deben iniciar este tipo de proyectos, as como las distintas formas
de adquirir la informacin necesaria para su posterior realizacin.
32
3.2.
Inicio de proyectos
3.2.1.
Proceso de solicitud de proyecto
La solicitud de proyecto, aunque no existe un formato nico y depende de la Organizacin, debe contener la
informacin mnima, a fin de poder ser estudiada por el comit. Esta informacin a contener es:
3.2.2.
Cul es el problema?
Detalles del problema
Importancia del problema
Cul es la solucin aportada por el usuario?
En qu medida ser de ayuda un sistema de informacin?
Qu otras personas conocen el problema y se puede contactar?
Fuentes de solicitud de Proyectos

Existen cuatro fuentes primarias de solicitudes de proyectos.
Los ejecutivos
Los jefes de departamento
Los analistas de sistema y,
Entes externos a la Organizacin.
Los jefes de departamento buscan mejorar la eficiencia del trabajo o reducir costes en su departamento,
implantando para ello un sistema informatizado, sin considerar la interaccin con otros departamentos.
Los directivos plantean proyectos globales a toda la Organizacin, normalmente multidepartamentales con un
periodo de desarrollo ms amplio, y normalmente asociado a polticas de empresa.
Los analistas de sistemas buscan reas donde desarrollar proyectos, normalmente para la mejora de un
departamento. El hecho de no partir la propuesta de proyecto por el jefe del departamento, obedece a un mejor
conocimiento de la tecnologa y las posibilidades de los equipos por parte del analista de sistemas.
Las solicitudes de nuevos proyectos pueden partir de grupos externos, siendo estos proyectos tan importantes o
mas como los originados dentro de la Organizacin.
3.3.
Planificacin de un proyecto de sistemas.
3.3.1.
Que es un proyecto de Sistema o Software?
Es el Proceso de gestin para la creacin de un Sistema o software, la cual encierra un conjunto de actividades,
una de las cuales es la estimacin, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de
incertidumbre.
33
Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto, sino que se toma en
cuenta los recursos, costos y planificacin.
El tamao del proyecto es otro factor importante que puede afectar la precisin de las estimaciones. A medida
que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del Software.
La disponibilidad de informacin histrica es otro elemento que determina el riesgo de la estimacin.
3.3.2.
Objetivos de la Planificacin del Proyecto.
Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y
planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto
de software, y deberan actualizarse regularmente medida que progresa el proyecto.
El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a
estimaciones razonables.
3.3.3.
mbito del Software.

Es la primera actividad de llevada a cabo durante la planificacin del proyecto de Software.
En esta etapa se deben evaluar la funcin y el rendimiento que se asignaron al Software durante la Ingeniera
del Sistema para establecer un mbito de proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos
Describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalan las funciones del
mbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin.
El mbito se define como un prerrequisito para la estimacin y existen algunos elementos que se debe tomar en
cuenta como es: la obtencin de la informacin necesaria para el software. Para esto el analista y el cliente se renen
sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo.
3.3.4.
Recursos:
La segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para
acometer el esfuerzo de desarrollo de Software, esto simula a una pirmide donde las Herramientas (hardware y
Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la
pirmide se encuentran los Componentes reutilizables.
Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el recurso humano).
Cada recurso queda especificado mediante cuatro caractersticas:
Descripcin del Recurso
Informes de disponibilidad
Fecha cronolgica en la que se requiere el recurso
Tiempo durante el que ser aplicado el recurso
34
3.3.4.1. Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado
despus de hacer una estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y seleccionar
la posicin dentro de la organizacin y la especialidad que desempeara cada profesional.
3.3.4.2. Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin, esto es la creacin
y la reutilizacin de bloques de construccin de Software.
3.3.4.3. Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniera de Software,
incorpora Hardware y Software.
El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los
productos que son el resultado de la buena practica de la Ingeniera del Software, un planificador de proyectos debe
determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estn
disponibles.
3.3.5.
Estimacin de costos del Proyecto de Software.
En el principio el costo del Software constitua un pequeo porcentaje del costo total de los sistemas basados en
Computadoras. Hoy en da el Software es el elemento ms caro de la mayora de los sistemas informticos.
Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la
estimacin del costo y del esfuerzo del software nunca ser una ciencia exacta, son demasiadas las variables: humanas,
tcnicas, de entorno, polticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:
Deje la estimacin para ms adelante (obviamente podemos realizar una estimacin al cien por
ciento fiable despus de haber terminado el proyecto.
Base las estimaciones en proyectos similares ya terminados.
Utilice tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costos y
esfuerzo del proyecto.
Desarrolle un modelo emprico para l clculo de costos y esfuerzos del Software.
Desde el punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas usando cada una de ellas
como comprobacin de las otras.
Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito del software a construir
y generar una estimacin de su tamao.
35
3.3.5.1. Estudio de Factibilidad.

Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son
realistas para su materializacin sin tener prdidas econmicas y frustracin profesional. La viabilidad y el anlisis de
riesgos estn relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de
calidad se reduce, sin embargo se deben tomar en cuenta cuatro reas principales de inters:
Factibilidad Operacional
Factibilidad Tcnica
Factibilidad Legal
Factibilidad Financiera y Econmica
El estudio de factibilidad lo lleva a cabo un equipo de personas (una o dos) que estn familiarizados con
tcnicas de sistemas de informacin, normalmente es gente experta en los procesos de Anlisis y Diseo de Sistemas.
Hay tres aspectos relacionados:
Factibilidad Operacional
Las preguntas formuladas para este apartado sern:
Trabajar el sistema cuando est terminado e instalado?
Existen barreras importantes para la implantacin?
Existe apoyo por parte de los usuarios y la administracin?
Los mtodos que actualmente se emplean en la Organizacin son aceptados por los usuarios?
Han participado los usuarios en la planeacin y desarrollo del proyecto?
Factibilidad Tcnica
Los aspectos tcnicos a considerar, son:
Existe o se puede adquirir la tecnologa precisa para realizar el proyecto?
El equipo propuesto tiene la capacidad tcnica para soportar todos los datos del sistema?
Puede crecer con facilidad el sistema?
Existen garantas tcnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de los datos?
Se implementarn funciones de auditoria en el futuro sistema.
Factibilidad Legal
Los aspectos legales a tener en cuenta, son:
El sistema es afectado por leyes del medio ambiente o normativas internas?

36
La construccin de todo sistema esta determinado por polticas predefinidas?
El software de construccin posee el licenciamiento para tal efecto?
Quines participan en el desarrollo, conocen las caractersticas de la propiedad del producto de

software?
Factibilidad Financiera y Econmica

Los aspectos financieros y econmicos a considerar, son:
El costo de llevar a cabo la investigacin completo de sistemas
El costo del hardware y software para la aplicacin que se est considerando
Beneficios en la forma de reduccin de costos o de menores errores costosos
El costo, si el proyecto no se lleva a cabo
3.3.5.2. Anlisis Econmico.

El anlisis econmico o anlisis costo-beneficio proporciona a la gerencia una visin de los costos y riesgos
asociados con alternativas de inversin. Para los sistemas de informacin automatizados que requieren de la adquisicin
de equipo de cmputo, es necesario evaluar la conveniencia econmica de adquirirlos ya que cumplen con las
caractersticas que definen a una decisin de inversin:
Involucra sumas importantes de dinero
Se comprometen erogaciones futuras de fondos.
Los resultados continan sobre un perodo largo de tiempo
Usualmente la decisin es irreversible.
Depende de pronsticos.
En este tipo de decisiones, se involucran dos tipos fundamentales de costos: los necesarios para implantar o
echar a andar el proyecto, y aquellos que se erogarn durante la vida del mismo y que debern ser comparados con los
beneficios esperados del proyecto. A los primeros se les conoce como costos de desarrollo o inversin inicial y a los
segundos, como costos de operacin.
Para evaluar un proyecto de inversin, se deben comparar los costos con los beneficios asociados a los mismos.
A continuacin se muestran algunos ejemplos de costos y beneficios que pueden presentarse en la adquisicin de equipo
de cmputo:
Costos de desarrollo:
Personal:
Equipo:
Software:
Materiales:
Otros:
analistas, programadores, operadores, administrativos

costo, instalacin, pruebas, conversin
costo, instalacin, mantenimiento
publicaciones (documentacin), formas, papelera, discos, tinta
capacitacin, Luz, renta, etc.
37
Costos de operacin:
Personal:
Hardware:
Software:
Materiales:
Otros:
operador, capturista, soporte tcnico

mantenimiento
mantenimiento
papel, formas, discos
auditoria, renta
Beneficios:
Reduccin en costos
Reduccin de errores
Mayor velocidad
Mayor flexibilidad
Mejora en la planeacin y en el control
Las decisiones de inversin se pueden clasificar de acuerdo a la relacin que puede presentarse entre proyectos
en:
1.
Independientes. Cuando la decisin de llevarlos a cabo no afecta a otros proyectos.
2.
Mutuamente excluyentes. Cuando la aceptacin del proyecto excluye a otro proyecto en estudio (existe
restriccin de capital).
3.
Complementarios. Cuando la aceptacin de un proyecto incluye la aceptacin de otro que lo

complementa.
El objetivo primordial de la evaluacin de proyectos es la determinacin de la alternativa de inversin ms

adecuada en funcin de la maximizacin de utilidades, y para alcanzarlo, es recomendable desarrollar previamente las
siguientes tres fases.
3.3.6.
1.
Estimar la inversin neta o inicial representada por la integracin de los costos de desarrollo del
proyecto.
2.
Estimar los flujos de efectivo generados durante la vida del proyecto y asociados a ste (beneficios
menos costos de operacin).
3.
Evaluar la conveniencia del proyecto de acuerdo con la comparacin de la inversin neta y los flujos
de efectivo a travs del uso de los mtodos de evaluacin existentes para ello.
Inversin Neta o Inicial.

Para el clculo de la inversin inicial, se pueden considerar los siguientes conceptos con la adquisicin del
activo:
1. Precio del nuevo activo
2. Costo de instalacin
3. Otros gastos o ingresos en que si incurran como puede ser la venta del bien antiguo (reemplazo),
gastos de entrenamiento, etc.
4. El beneficio o prdida fiscal que se genera por la venta de activos antiguos (reemplazo)
38
3.3.7.
Mtodos de Evaluacin de Proyectos.
Una vez conocidas la inversin neta o inicial y los flujos de efectivo que se esperan genere el proyecto, ser
necesario compararlos y determinar si el proyecto conviene o se debe rechazar.
Para fines de estas notas, se consideran los mtodos ms usuales con sus principales inconvenientes y
caractersticas: Payback, Valor Actual Neto (VAN) y Tasa interna de Rendimiento (TIR).
Payback o Perodo de Recuperacin.
Este mtodo calcula el nmero de aos necesarios para recuperar la inversin inicial, su inters radica
solamente en el tiempo necesario para recuperarla, por tanto su criterio de decisin ante alternativas mutuamente
excluyentes ser elegir el proyecto que recupere la inversin inicial en el menor tiempo.
Para calcular el payback, cuando los flujos de efectivo son iguales:
Payback = Inversin inicial / Flujo de efectivo anual
Ejemplo: se tiene un proyecto con inversin inicial de $ 20.000 que se espera produzca rendimientos anuales de
$ 4.000 (flujos de efectivos). Cul sera su perodo de recuperacin o payback?
Payback = 20.000 / 4.000 = 5 aos
Cuando los flujos netos de efectivo no son iguales, el payback se calcula acumulndolos hasta que la suma sea
igual al desembolso inicial.
Ejemplo: se tiene una propuesta de inversin que requiere de una salida inicial de $ 10,000 los rendimientos
esperados para la misma son los siguientes:
Ao
1
2
3
4
5
Flujo de Efectivo
$ 2.000
$ 4.000
$ 3.000
$ 3.000
$ 1.000
Si se acumulan los flujos de efectivo del ao 1, 2 y 3, se tendra 2000+4000+3000 = 9000 por lo tanto para
recuperar la salida inicial, es necesario considerar $ 1000 a recuperar en el ao 4. Para calcular el perodo de tiempo
proporcional del ao que corresponde a la cantidad de $1000, se puede hacer uso de la regla de tres en la cual puede
variar el uso de la unidad de tiempo (semestre, trimestre, cuatrimestre, meses o das). En este caso se har uso de meses
y el planteamiento es: si $ 3000 corresponden a 12 meses, a cuntos meses corresponden $ 1000?
3000 12
1000 x
(1000 * 12) / 3000 = 4 meses
Esto quiere decir que el perodo de recuperacin o payback del proyecto es de 3 aos y cuatro meses. Otra
manera de calcular el residual del ao, es en base a la proporcin de los $ 1000 que hacen falta a considerar del ao 4,
esto es, 1000/3000=0.33 o 1/3 del ao que representan los 4 meses.
Las principales ventajas y desventajas del payback son las siguientes:
Ventajas
Es simple
39
Desventajas
No considera el valor del dinero en el tiempo.
No considera flujos de efectivo despus del payback
Valor Actual Neto (VAN)

El mtodo de valor presente neto, considera el valor del dinero en el tiempo y resulta de comparar el valor
presente de los beneficios de un proyecto menos el valor de la inversin inicial.
Cuando el valor presente neto es positivo, el proyecto es viable ya que cubre la inversin y genera beneficios
adicionales. Cuando el valor presente neto es negativo, el proyecto debe rechazarse ya que los beneficios esperados no
cubren la inversin inicial. Para seleccionar entre proyectos mutuamente excluyentes el criterio es elegir el de mayor
valor presente neto.
Entonces, el criterio de decisin es el siguiente:
Si VAN > 0 el proyecto se acepta (es positivo)
Si VAN < 0 el proyecto se rechaza (es negativo)
Este mtodo, elimina la desventaja de los dos anteriores en relacin con el valor del dinero en el tiempo, pero su
clculo requiere de tiempo y comprensin de este concepto adems de una tasa de descuento para realizar los clculos.
La frmula que permite calcularlo es la siguiente:
n
Rj
VAN =
j
j =1 1 + i )
I0
donde:
Rj = flujos de efectivo (beneficios costos, del perodo j)
t = perodos de tiempo que van desde 1 hasta n
i = tasa de rendimiento esperada
I0 = inversin inicial
Para ejemplificar el valor del dinero en el tiempo, considrese que se tiene efectivo por $ 400 y se invierte en el
banco a una tasa del 10% anual, al final del primer ao el efectivo se habr incrementado en $40 que representa el
rendimiento anual que se ofrece al inversionista por depositar su dinero en la institucin bancaria. Si esta nueva suma de
$ 440 se deja por otro ao ms, entonces al final del segundo ao se obtendr un rendimiento de $ 44 que conjuntamente
con los $ 440 darn un total de $484.
40
Lo anterior significa que si una persona quisiera recuperar dentro de dos aos la cantidad de $ 484, necesita
tener en el presente $ 400 e invertirlos a una tasa de inters compuesto del 10%.
Para facilitar el clculo del valor presente, existen tablas en los libros financieros o en los libros de matemticas
financieras que presentan el resultado de aplicar la frmula anterior como un factor para una tasa y un perodo de tiempo
especfico.
Ejemplo: se tienen dos proyectos de inversin el A y el B:
PROYECTO A
Ao
Flujo neto
Factor 10%
1
500
0,9091
2
400
0,8264
3
300
0,7513
4
100
0,6830
Suma del valor actual de los flujos
Inversin Inicial
Valor presente de los flujos

90,91
165,28
225,39
273,2
+ 1078,80
1000
+ 78,80
PROYECTO B
Ao
Flujo neto
Factor 10%
1
100
0,9091
2
200
0,8264
3
300
0,7513
4
400
0,6830
5
500
0,6209
6
600
0,5645
Suma del valor actual de los flujos
Inversin Inicial
Valor presente de los flujos

90,91
165,28
225,39
273,2
310,45
338,70
+ 1403,93
1000
+ 403,93
Si los proyectos son independientes, ambos son factibles de realizarse desde el punto de vista econmico
porque su valor presente neto es positivo (78,80 y 403,93). En el caso de que los proyectos fueran mutuamente
excluyentes, el proyecto B ser el que se deber seleccionar ya que el valor presente neto de este proyecto es superior al
valor presente neto del proyecto A.
En resumen, las principales ventajas y desventajas del mtodo son las siguientes:
Ventajas
Considera el valor del dinero en el tiempo.
Considera todos los flujos de efectivo.
Considera la contribucin esperada en trminos absolutos.

41
Desventajas
Dificultad de clculo
Requiere de una tasa de inters para realizar el clculo.
Ejercicio:
La compaa Margar tiene en estudio la adquisicin de un sistema de cmputo que le servir para controlar su
lnea de productos. El costo de instalacin del sistema es de $700.000 en el ao 0 y de $1.000.000 en el ao 1 por
mantenimiento. Se esperan ahorros en mano de obra y materiales de $250,000 en el ao 2, $300,000 en el ao 3,
$350,000 en el ao 4 y $400,000 cada ao posterior hasta el ao 10 que es el tiempo de vida estimado para el sistema.
a) Cul es el perodo de recuperacin del proyecto?
b) Cul es la tasa promedio de retorno del proyecto?
c) Si la tasa de rendimiento requerida es de 15%, Cul es el valor actual neto del proyecto? Es aceptable?
b) Cul sera la situacin con el VAN si la tasa requerida fuera del 10%?
Tasa interna de rendimiento (TIR)

La tasa interna de rendimiento (TIR) es un mtodo que considera el valor del dinero en el tiempo y determina la
tasa de rendimiento en la cual el valor presente neto de un proyecto es igual a cero.
La frmula que permite representar al mtodo es la siguiente:
n
Rj
TIR =
j
j =1 1 + i )
I0 = 0
donde:
Rj = flujos de efectivo (beneficios costos, del perodo j)
t = perodos de tiempo que van desde 1 hasta n
i = tasa de rendimiento esperada
I0 = inversin inicial
Cuando la TIR es mayor al costo de capital requerido para el proyecto, debe aceptarse. Cuando TIR es menor al
costo de capital, el proyecto debe rechazarse ya que los beneficios esperados no cubren la inversin inicial. Para
seleccionar entre proyectos mutuamente excluyentes el criterio es elegir el de mayor TIR.
El clculo de la TIR es similar a la de valor presente neto, nicamente que en este caso se recomienda seguir los
siguientes pasos:
1.
Se determina una tasa en la que el valor presente neto sea positivo

42
2.
Se determina una tasa en la que el valor presente neto sea negativo
3.
Se interpola para calcular la tasa en la que el valor presente neto sea cero
El motivo para efectuar estos pasos, se puede observar grficamente relacionando el valor presente neto de un
proyecto con diferentes tasas de inters:
Como puede observarse, a medida que las tasas requeridas de inters aumentan, el valor presente neto
disminuye hasta volverse negativo. Por lo tanto cuando VAN es igual a cero, se encuentra la TIR del proyecto. (Usar
Excel).
En resumen las principales ventajas del mtodo son:
Ventajas
Considera el valor del dinero en el tiempo
Considera todos los flujos de efectivo
No requiere de una tasa de descuento
Desventajas
3.4.
Muy difcil de calcular
Planificacin de las actividades.
En la planificacin de un proyecto, tanto las tareas como los recursos disponibles son igualmente importantes, a
menos que se disponga de manera ilimitada de stos, tanto en nmero como en funcionalidad y valor, cosa que no suele
suceder en el mundo real.
Un buen punto de partida para la planificacin y control de actividades de un proyecto, es dividirlo, desde el
punto de vista administrativo, en las actividades del ciclo de vida clsico de desarrollo de sistemas de informacin.
En cuanto a las tareas en que se divide el proyecto, es importante considerar la relacin entre ellas:
Tareas Independientes: posibilidad de realizarse en paralelo con otras tareas (no ests condicionadas)
Tareas Dependientes: condicionadas a otras.

43
Secuenciales: deben guardar un orden de ejecucin. Dependen de un o varias anteriores.
Solapadas: en principio, independientes, pero se consideran as cuando no se pueden iniciar

simultneamente. Se trata de una independencia relativa
La secuencia de tareas y, por lo tanto de trabajo, viene condicionado por tres tipos de restricciones: lgicas,
estratgicas y de recursos.
Estimacin de Tiempos.
Una vez identificadas las tareas, hay que asignarles un tiempo de ejecucin. En general, resulta prctico
planificar en base a das (jornadas laborales completas) y convertirlo a horas cuando se precise esta medida de tiempo.
No resulta prctico planificar con menos detalle que das de trabajo, en todo caso, convendr agrupar tareas para
considerar, al menos, un da en la planificacin.
Tcnicas Grficas para Itinerarios y Control.
El plan de trabajo debe ser elaborado y expresado mediante tcnicas que, adems de suponer una ayuda en la
planificacin misma, aseguren su coherencia y la comprensin rpida y eficaz por parte de quienes deban conocerlo y
controlarlo.
Existen dos tcnicas de definicin de itinerarios, las cuales se pueden considerar clsicas, que son la base de la
mayora de los mecanismos de definicin de planes de trabajo y control: la tcnica PERT y los grficos GANTT.
3.4.1.
PERT (Proyect Evaluation and Review Technique)
Tcnica de evaluacin y revisin de programas. La grfica PERT, tiene gran valor cuando se planifica y disea
el sistema. Cuando se termina la grfica de relaciones, se puede determinar la ruta crtica. La grfica se basa en crculos
que representan acontecimientos y lneas que muestran actividades (puede haber ficticias con tiempos ceros). Tambin
muestra la interdependencia de las tareas y ayuda a responder:
Qu actividades deben preceder o se deben completar antes del inicio de una actividad especfica?
Qu otras actividades se pueden llevar a cabo en tanto una actividad especfica se encuentra en proceso?
Qu actividades no se pueden iniciar hasta despus de terminar una actividad especfica?
Para desarrollar la red PERT primero se deben determinar las tareas y los tiempos relacionados con cada
actividad. A continuacin, se debe identificar la secuencia de realizacin de las actividades. Esto es: Qu actividades se
pueden realizar al mismo tiempo?, Cules deben preceder a otras? y cules deben ir despus de otras?
Ejemplo:
A Alejandro Limn se le ha asignado la tarea de preparar el reporte anual de la compaa. Alejandro ha
identificado 7 actividades, sus antecedentes y el tiempo necesario para realizarlas.
Actividad
A. Tener preparados los estados financieros
B. Escribir los artculos de los estados financieros
C. Auditar los estados financieros
D. Organizar el reporte anual
E. Obtener la aprobacin del presidente
F. Imprimir el reporte
G. Distribuir el reporte
Antecedente
----A
C, B
C, B
D
F, E
Tiempo semanas
4
6
3
2
3
5
8
44
A continuacin se muestra el diagrama PERT y CPM para que Alejandro cumpla con su funcin de una mejor
manera.
En el ejercicio, la ruta crtica es el camino formado por las actividades A, C, D, F y G ya que requieren de
mayor tiempo, para lograr el objetivo del proyecto.
3.4.2.
Cronogramas, Diagramas de Tiempo o Grficas de Gantt.
Es una tabla de doble entrada que asocia tiempo y actividades y muestra en la interseccin de las lneas con las
columnas, la duracin de cada actividad. De todas las tcnicas de planificacin, la ms conocida y utilizada es, sin duda,
el diagrama de GANTT, que recibe el nombre de su inventor.
45
Esta representacin bsica admite variaciones sin cambiar su estructura, tal como representar, con otro tipo de
lnea, fases o conjunto de tareas y luego detallar las tareas o subtareas, que quedarn dentro de los mrgenes de la fila de
conjunto.
Como puede verse, la carta Gantt presenta en gran medida el mismo tipo de informacin que el diagrama Pert;
su principal diferencia es el hecho de que muestra grficamente la duracin de una actividad, mientras el diagrama Pert
no lo hace.
Dado que es una representacin un tanto ms tabular del proyecto, a menudo puede usarse para representar una
gran cantidad de informacin en una forma relativamente compacta.
46
3.5.
Anlisis Econmico y Tcnico.
El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios, significa una valoracin de la
inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o
sistema.
En el Anlisis Tcnico, el Analista evala los principios tcnicos del Sistema y al mismo tiempo recoge
informacin adicional sobre el rendimiento, fiabilidad, caractersticas de mantenimiento y productividad.
Los resultados obtenidos del anlisis tcnico son la base para determinar sobre si continuar o abandonar el
proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan perfectamente
unas con otras.
3.6.
Manejo de proceso de seleccin y revisin de proyectos
Se generan muchas solicitudes para el desarrollo de sistemas de las que las Organizaciones pueden emprender,
obliga a un proceso de seleccin y priorizacin.
Uno de los mtodos ms comunes para revisar y seleccionar proyectos para su desarrollo es por medio de un
comit. Podemos hablar de varios tipos de comit:
Comit Directivo
Formado por ejecutivos, jefes de departamento y analista de sistemas. Normalmente corresponde con el
personal con mayor responsabilidad, autoridad y con pocos miembros especialistas en sistemas. Reciben y evalan las
propuestas. Para la toma de decisin en firme necesitan mayor informacin que la contenida en la propuesta, por lo que
deciden realizar un estudio preliminar.
Comit de Sistemas de Informacin
El comit formado por profesionales del departamento de sistemas de informacin. Este comit aprueba o
rechaza proyectos y fija las propiedades y tambin indica qu proyectos son ms importantes, dndoles atencin
inmediata. Esta composicin del comit se puede utilizar para servicios rutinarios o mantenimiento de aplicaciones
existentes.
Comit de Grupos de Usuarios
En algunas organizaciones la responsabilidad de la toma de decisiones con respecto a los usuarios se deja en
manos de stos. Algunos departamentos contratan sus propios analistas y diseadores. Pero puede ocurrir que varios
departamentos pequeos que trabajan de forma independiente para alcanzar la misma meta pueden estar, de manera
inconsciente, desperdiciando recursos y perdiendo la oportunidad para coordinar la planificacin de un sistema de
informacin, compartido e integrado que podra beneficiar a toda la empresa.
Aprobacin de la solicitud
No todos los proyectos solicitados son factibles. Algunas organizaciones reciben tantas solicitudes de sus
empleados que solo es posible atender unas cuantas. Sin embargo, aquellos casos que son deseables y factibles deben
incorporarse en los planes de desarrollo de la organizacin, para ser atendidos lo ms rpido posible, segn los recursos
de la organizacin.
Dentro de los beneficios que el sistema podra brindar tenemos:
Obtencin de informacin no disponible actualmente
Elaboracin ms oportuna de la informacin

47
Mejoras en las operaciones de la organizacin
Posibilidades de efectuar clculos o estimaciones que actualmente no es posible
Reduccin de costo
Obtencin de una posicin competitiva dentro del mercado
Mejoras en la toma de decisiones.
Mejoras en la imagen, atencin, seguridad, etc.
48
4.-
Anlisis, Determinacin y Especificacin de Requerimientos
4.1.-
Anlisis de Requerimientos
La tarea de anlisis de los requerimientos es un proceso de descubrimiento y refinamiento de la informacin. El

contexto del programa establecido previamente es refinado en detalle.
Tpicos:
funcin y comportamiento de los programas
interfaz con diferentes partes del sistema
tcnicas de revisin
Actores del proceso: Cliente (s), Analista, Equipo de desarrollo
Tareas del anlisis:

1.
Reconocimiento del problema se realiza mediante entrevistas con el cliente para reconocer elementos
bsicos del sistema a desarrollar
2.
Evaluacin del problema y sntesis de la solucin se refiere a la evaluacin de flujo y estructura de la

informacin, refinamiento en detalle de todas las funciones del programa, y finalmente elaboracin de
una o ms alternativas de solucin del problema.
3.
Especificacin es un documento que se elabora para ser revisado y aprobado para el cliente
4.
Revisin son los criterios de validacin del programa terminado
Analista de sistemas, diseador jefe de proyecto, programador/analista etc., deben tener
Habilidad para comprender los aspectos abstractos, reorganizarlos en divisiones lgicas y sintetizar
"soluciones" basadas en cada divisin
Habilidad de cristalizar hechos importantes de fuentes conflictivas o confusas
Habilidad para comprender entornos de usuario/cliente
Habilidad para relacionar elementos hardware y/o software a entornos de usuario/cliente
Habilidad para comunicarse en forma escrita y verbal
Habilidad para evitar que "los rboles no dejan ver el bosque"
49
reas de problemas:
Ya que anlisis de requerimientos es una actividad intensiva de comunicacin, siempre existe ruido (mala
interpretacin, omisin). Conforme crece el tamao del problema, crece tambin la complejidad de la tarea de anlisis.
Cada nuevo elemento puede tener efecto sobre otros elementos. Problemas:
pobre comunicacin, que hace difcil la adquisicin de la informacin
tcnicas y herramientas inadecuadas que producen especificaciones inadecuadas e imprecisas
tendencia a acortar el anlisis de requerimientos, conduciendo a un anlisis inestable
un fallo en considerar alternativas antes de especificar el software
La tarea de anlisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y especificacin. Se

refina en detalle en detalle el mbito del software, inicialmente establecida por el ingeniero de sistemas y refinada
durante la planificacin temporal del proyecto. Se crean los modelos de los requisitos de datos, flujo de informacin y
del comportamiento operativo. Se analizan las soluciones operativas y se asignan a diferentes componentes del software.
Tanto el desarrollador como el cliente tienen un papel activo en el anlisis y especificacin de los requisitos. El
cliente intenta reformular su concepto a veces confuso de funcin del software y rendimiento en detalles concretos. El
desarrollador acta como un interrogador, como consultor y como la persona que resuelve el problema.
El anlisis y la especificacin de los requisitos puede parecer una tarea relativamente sencilla, pero las
apariencias engaan. El contenido de comunicacin es muy denso. Abundan ocasiones para las malas interpretaciones o
falta de la informacin. Es muy probable que haya ambigedad. El dilema al que se enfrenta el ingeniero de software
puede entenderse muy bien repitiendo la famosa frase de un cliente annimo S que cree que entendi lo que piensa
que dije, pero no estoy seguro de que se d cuenta de que lo que escuch no es lo que yo quise decir.
El anlisis de requisitos permite al ingeniero de sistemas especificar la funcin y el rendimiento, indica la
interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
La primera reunin entre el analista y el cliente tiene que ser planificada cuidadosamente: se sugiere que se
empiece por preguntar por cuestiones de contexto libre. Es decir, un conjunto de preguntas que llevarn a un
entendimiento bsico de problema, que solucin busca, la naturaleza de la solucin que se desea y la efectividad del
primer encuentro. Estas primeras preguntas enfocan en el cliente, los objetivos generales y los beneficios esperados. Por
ejemplo, el analista podra preguntar:
Quin esta detrs de la solicitud de este trabajo?
Quin utilizar la solucin?
Cul ser el beneficio econmico del xito de una solucin?
Hay alguna otra alternativa para la solucin que necesita?
El segundo conjunto de preguntas permite al analista obtener un mejor entendimiento de problema y al cliente
comentar sobre sus opiniones sobre la solucin.
Cmo caracterizara un buen resultado generado por una solucin?
A qu tipo de problemas va dirigida la solucin?
Puede mostrarme (o describirme) el entorno en que se utilizar la solucin?
Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la
solucin?
50
Y el ltimo conjunto de preguntas esta enfocado en la eficacia de la reunin:
Es Usted la persona adecuada para responder a estas preguntas? Sus respuestas son oficiales?
Son adecuadas las preguntas para el problema que tiene Usted?
Estoy preguntando demasiado?
Hay alguien ms que pueda proporcionar informacin adicional?
Hay algo ms que debera preguntarle?
Estas preguntas (y otras) ayudarn a romper el hielo e iniciar la comunicacin tan importante para el xito del
anlisis.
Despus de esta entrevista inicial se procede a tener entrevistas regulares con diferentes personas dentro de la
organizacin para obtener la informacin ms fidedigna sobre la organizacin, resolviendo los posibles conflictos de
informacin, preparando cada una de estas reuniones y haciendo especificacin las cuales deben ser autorizados por el
cliente antes de pasar a la fase de diseo.
4.2.
Determinacin de requerimientos
Determinar requerimientos consiste en estudiar un sistema para conocer como trabaja y donde es necesario
efectuar mejoras.
Un requerimiento es una caracterstica que debe incluirse en el nuevo sistema. Esta puede ser la inclusin de
determinada forma para capturar o procesar datos, producir informacin, controlar una actividad de la empresa o brindar
soporte a los directivos.
Los analistas de sistemas no trabajan como directivos o empleados de los departamentos de usuarios, no tiene
los mismos conocimientos, hechos y detalles que los usuarios y directivos de estas reas. Por lo tanto el primer paso del
analista es comprender la situacin.
El primer paso del analista es comprender la situacin actual.
4.2.1.
Actividades de la determinacin de Requerimientos
Anticipacin de Requerimientos
Prever las caractersticas del sistema con base en la experiencia previa. Esto puede llevar al analista a
investigar reas y aspectos que de otra forma no seran tomados en cuenta.
La experiencia permite anticipar requerimientos para el nuevo sistema.
Investigacin de Requerimientos
Estudio y documentacin del sistema actual utilizando para ello tcnicas para hallar hechos, anlisis de
flujos de datos y anlisis de decisin.
Es la actividad ms importante.
51
Especificacin de Requerimientos
Anlisis de los datos que describen el sistema para determinar qu tan bueno es su rendimiento, qu
requerimientos deben satisfacer y las estrategias para alcanzarlos.
4.3.
Investigacin de Requerimientos.
Los analistas estructuran su investigacin en base a 4 preguntas:
1. Cul es el proceso bsico de la empresa?
2. Qu datos utiliza o produce este proceso?
3. Qu frecuencia y volumen del proceso existe?
4. Qu controles utiliza para su realizacin?
4.3.1. Cul es el proceso bsico de la empresa? Las siguientes preguntas se utilizan para adquirir la
comprensin necesaria:
4.3.2.
Cul es la finalidad de esta actividad en la empresa?
Qu pasos se siguen para llevarla a cabo?
Donde se realizan estos pasos?
Quienes los realizan?
Cunto tiempo tardan en efectuarlos?
Con cuanta frecuencia lo hacen?
Quienes emplean la informacin resultante?
Qu datos utiliza o produce este proceso?

Este paso consiste en detectar qu datos se utilizan para llevar a cabo cada actividad.
4.3.3.
Qu frecuencia y volumen de proceso existe?
Los analistas deben investigar con cuanta frecuencia se repite una actividad. Esto cambia mucho dependiendo
de la actividad ya que por ejemplo el pago de la nmina se repite mensualmente o semanalmente pero el pago de
impuestos es anualmente.
La manera ms fcil de obtener esta informacin es identificar el objetivo de la actividad, es decir, cul es la
causa de la actividad.
El volumen de los procesos puede aumentar el tiempo de realizacin de las actividades, es decir la cantidad
total de pasos que puede constar una actividad puede generar problemas an ocurriendo con poca frecuencia.
52
4.3.4.
Qu controles utiliza para su realizacin?

La falta o debilidad de los controles es un descubrimiento importante en cualquier investigacin del sistema.
El analista debe examinar los mtodos de control preguntando:
Quin se encarga de comparar lo realizado con los estndares?
Cmo se detectan los errores?
Cmo se corrigen los errores?
Respuestas concisas a estas preguntas proporcionan un conocimiento amplio de una actividad en particular y
muestra tambin su objetivo. Pero analista no se detiene ah, todava no existe informacin para comprender en su
totalidad la actividad; ms bien lo que se tiene son los antecedentes que permiten a los analistas formular preguntas ms
detalladas.
Durante esta, debemos identificar muy claramente los siguientes elementos:
procesos
flujos de datos entre procesos
datos de cada flujo de datos
almacenes de datos
datos de los almacenes de datos.
Para ello el cuestionario que se aplica debe requerir la siguiente informacin:
nombre de la entidad
nombre los campos
descripcin
fuente y sensibilidad (= seguridad)
valor o importancia de los datos
relaciones de los campos y entidades
Criterio de retencin y almacenamiento.
53
4.3.5.
Preguntas clsicas para una determinacin de requerimientos:

Preguntas generales:
Cuntos empleados laboran para la organizacin en el rea(s) que se pretende desarrollar el sistema?;
o sea, cuntos tienen relacin directa con el proyecto que se est investigando?
Cules son las personas claves en el sistema? Por qu son importantes?
Existen obstculos o influencias de tipo poltico que afectan la eficiencia del sistema?
Existen manuales de procedimientos, polticas o lineamientos de desempeo documentados oficial o

no oficialmente? Si los hay, Se cumplen en forma cabal en el 100% de las ocasiones?, es decir, se
respetan dichos procedimientos?
Existen mtodos para evadir el sistema?, Por qu se presentan?
Qu reas necesitan un control especfico?
Qu criterios se emplean para medir y evaluar el desempeo?
Por otra parte:
Existen actividades que considere podran mejorarse?, De qu manera?
Tiene alguna idea de actividades que podran implementarse para mejorar el rendimiento del sistema
en general?
Determinacin de procesos:
Cules son las principales actividades que se realizan en la organizacin y que tienen relacin con el
proceso que se est modelando?
Descripcin de cada proceso identificado
Qu es lo que da inicio a la actividad?
Cul es el objetivo de la misma?
Cunto tiempo se tarda en realizarla?
Qu retrasos ocurren o pueden ocurrir?
Qu mtodos se emplean para medir y evaluar el desempeo de esta actividad?
Se toman precauciones especficas de seguridad para la proteccin contra alguna actividad impropia
que se pudiera presentar?
Qu tan frecuente es el ciclo con el que se desarrolla dicha actividad?
De acuerdo al ciclo con el que se presenta la actividad, Cul es el volumen de informacin que aqu
se procesa?
Qu pasos, sub-procesos, o funciones constituyen la actividad? (describir la actividad paso a paso)
Existe algn tipo de control desarrollado en el proceso en cuestin?

54
Determinacin de datos (flujos y contenido de los flujos) - hacer la pregunta por cada proceso o actividad
identificada
De dnde proviene la informacin que se utiliza en esta actividad? (fuentes)
Cules son especficamente los datos que recibe esta actividad? (detalles de flujos)
De qu manera ingresan a este proceso? (flujos)
Qu tablas de referencia y diagramas u otros datos intervienen en la actividad? (documentacin

involucrada)
Qu informacin se genera en esta actividad? (producto de la actividad)
El resultado identificado anteriormente producto de los datos que se procesan Hacia qu o quin van
dirigidos?persona o entidad- (destinos)
Con qu finalidad la utilizan?
Cules datos se conservan o almacenan en este proceso? Y en qu forma quedan almacenados?
Existe informacin que se genera pero que no es utilizada nunca por nadie? (partes extraas)
Para cada dato identificado:
Qu formato posee cada dato que interviene en esta actividad?
Para qu es usado?
Se interpone algn tipo de seguridad para la verificacin de la veracidad del dato en mencin?
Qu tan importante es dicho dato?
Por cunto tiempo es importante mantener el dato en el sistema?
Por otra parte si el sistema que se est investigando es para el soporte de decisiones se deben, adems de las
anteriores, formular otras preguntas para determinar los requerimientos de las decisiones, un esbozo de las mismas bien
podra ser:
Qu informacin se usa para tomar la decisin?
Cul es la fuente de esa informacin? Qu sistemas transnacionales producen los datos utilizados en
el proceso de decisin? Qu otros datos son necesarios y no es posible obtener del procesamiento de
transacciones? Qu datos se originan en fuentes externas a la organizacin?
Cmo se deben procesar los datos para producir la informacin necesaria?
Cmo debe presentarse la informacin?
Una vez que se tenga recopilado el conjunto de hechos que se generan con relacin al sistema que estamos
modelando, es posible dar una especificacin de requerimientos, mediante como se dijo un anlisis de los datos
obtenidos durante la recopilacin de hechos. Es despus de esto entonces, que se puede ya dar un conjunto de
requerimientos que nos servirn para modelar el sistema mediante un DFD y del que surge el diagrama E-R
55
4.3.1.
Mtodo de trabajo para la recopilacin de informacin
La recopilacin de informacin, especialmente en un sistema grande y complejo, puede ser una tarea ardua. La
informacin se debe reunir siguiendo un camino organizado para asegurar que no hay redundancias y que se recogen
todos los detalles del sistema. Para ello se debe consultar a todos los usuarios para asegurarse de que todo problema del
sistema, necesidad de usuario y objetivo est identificado. La bsqueda se debe hacer de tal forma que se eviten los
trabajos repetitivos y que un mismo usuario no sea interrogado por diferentes analistas pidiendo la misma informacin
Una de las actividades ms importantes para los participantes en desarrollo de sistemas de informacin
automatizados es la obtencin de informacin que permita comprender el esquema de trabajo en donde se encuentra el
sistema, por lo que, es necesario identificar dnde y cmo es posible obtenerla. El dnde, se refiere a los lugares en los
cuales se encuentra disponible y que denominar fuentes que pueden ser internas o externas al organismo y, el medio,
son los instrumentos a travs de los cuales es posible recopilarla.
Las fuentes de informacin se pueden clasificar en internas y externas, las primeras, se encuentran disponibles
dentro de la organizacin y las segundas, se refieren a las fuentes de informacin que pueden ser localizadas fuera de la
misma.
Fuentes de informacin internas
Informacin verdaderamente til en el desarrollo de sistemas de informacin automatizados, se encuentra en las
siguientes fuentes:
Sistema Actual.
El sistema actual es la fuente ms importante de informacin para los involucrados en el desarrollo de los
sistemas de informacin automatizados. A pesar del costo y tiempo requeridos para obtener informacin acerca de su
funcionamiento, presenta las siguientes ventajas:
1. Conocerlo, permite al analista definir si el sistema es correcto, si solamente requiere de pequeas
modificaciones, si requiere de importantes cambios o bien, si es necesario sustituirlo totalmente.
2. Al adentrarse en el funcionamiento del sistema actual el analista puede generar ideas para el diseo.
3. Se conocen a profundidad, los recursos humanos, materiales y de equipo con los cuales es posible
implementar el nuevo sistema. Adems de la formacin intelectual del elemento humano (Know how)).
4. En la fase de implementacin facilita las pruebas ya que el analista sabe cmo eran las cosas.
5. Permite comparar el nuevo sistema con el anterior, establecer sus similitudes y de con conocimiento,
evitar la reaccin negativa al cambio.
Personas.
El recurso humano relacionado directamente con el sistema es el ms capacitado para opinar sobre las fallas o
beneficios de los procedimientos y por tanto, el que puede ofrecer posiblemente las mejores opiniones sobre las mejoras
necesarias al sistema actual. Por otra parte, el elemento humano involucrado indirectamente con el sistema actual puede
aportar consideraciones importantes sobre el ambiente que rodea al sistema.
Otros sistemas.
Los sistemas dentro de la organizacin que puedan relacionarse con el nuevo sistema, proporcionan
informacin sobre las caractersticas de los estndares de diseo que el sistema deber adoptar, as tambin pueden
aportar informacin valiosa en la fase de anlisis para conocer las polticas institucionales respecto a hardware, software
y recursos humanos.
56
Documentos y archivos.
En todas las organizaciones, existen por escrito elementos que pueden permitir al analista establecer el diseo
del nuevo sistema en un marco acorde con el funcionamiento de la organizacin. Estos elementos pueden ser
reglamentaciones, polticas, estructura organizacional, procedimientos, descripcin de funciones, etc. todos ellos
generalmente se encuentran en forma de manuales o reglamentos, los cuales es conveniente solicitar para su anlisis
desde la fase inicial del desarrollo de sistemas.
Los archivos integran documentalmente toda la informacin que se maneja en un rea de trabajo. El analista de
sistemas, debe recurrir a los archivos para obtener informacin sobre el desarrollo normal del trabajo del rea en estudio,
conociendo los formatos usados, verificando su llenado, analizando sus problemas, etc.
Fuentes de informacin externas.

Otros sistemas similares al que se piensa desarrollar, los proveedores, los clientes, los distribuidores, los cursos
o los libros, pueden ser fuentes de informacin valiosa para el diseo del sistema considerando que son algunos de los
involucrados en las operaciones de la organizacin y por tanto los que cuentan con informacin valiosa para ser
considerada.
Otros Sistemas.
Puede tenerse conocimiento de sistemas similares al que se encuentra en estudio, estos sistemas pueden
proporcionar informacin sobre factores importantes a considerar tanto en el anlisis como en el diseo del sistema.
Aunque no debe perderse de vista que los sistemas se disean de acuerdo con las condiciones propias de cada
organizacin.
Proveedores, clientes y distribuidores.
Tanto proveedores como distribuidores y clientes son personas relacionadas con los procesos que se realizan en
la organizacin, adems de que en el caso de clientes y distribuidores son los que reciben el servicio final de la
organizacin, por tanto, pueden emitir opiniones interesantes y que sirvan de apoyo al analista sobre fallas o sugerencias
de mejoras que podra contemplar el nuevo sistema.
Libros e instructivos.
Los libros en los cuales algunos estudiosos de la materia presentan sugerencias sobre determinados sistemas o
sugerencias en base a su experiencia, pueden aportar informacin valiosa para desarrollar mejor la tarea del analista.
Adicionalmente, todas las mquinas al adquirirse, proporcionan instructivos sobre su uso los cuales son otra fuente de
informacin con la cual se puede conocer con facilidad el equipo o software actualmente en uso as como sus principales
caractersticas.
Cursos o Seminarios.
Cuando el analista de sistemas acude a cursos o seminarios sobre el tema, puede contar con informacin valiosa
que le permita desarrollar su trabajo de manera estructurada y por tanto con mayor facilidad.
4.3.2.
Medios para la recopilacin de Informacin.
Hasta aqu, se han considerado las fuentes de informacin ms relevantes para el analista de sistemas. Sin
embargo, es necesario sealar los medios a travs de los cuales la informacin puede ser recopilada de entre estas
fuentes, los cuales pueden se describen en las siguientes lneas.
57
1.
Revisin de Documentos.
Uno de los medios ms importantes de recoleccin de datos, es la revisin tanto de manuales, como de formas,
procedimientos y en general de cualquier documento que contenga informacin relevante para el desarrollo del sistema.
La revisin de documentos provee de informacin sobre errores que se cometan en los procesos normales de trabajo y
sobre las tareas que no se terminen por lentitud en el desempeo del trabajo. Los documentos pueden ser revisados en su
contenido cuantitativa y cualitativamente, algunos ejemplos de los primeros son: informes financieros, informes de
desempeo; la revisin cualitativa puede hacerse a memorandos, avisos y manuales que ofrecen informacin sobre la
ideologa de la institucin. En esencia este medio permite obtener informacin acerca de lo que es en contraposicin a lo
que debera ser.
Formularios
Los formularios son transportes de datos y existen en todas las formas y tamaos.
Se usan para muy diversos propsitos, por ej.: pedidos de provisiones para un restaurante, saldo de una cuenta
bancaria, informe de fabricacin de ciertos artculos, solicitudes de inscripcin, actas de exmenes, etc.
Se debe obtener una copia de cada formulario usado en el sistema, ya sea que se origine dentro o fuera de la
organizacin. El mejor modo de ver cmo se usa un formulario, es obtener una copia del formulario vaco y otro lleno.
De cada formulario se debe conocer:
Cul es el objetivo del formulario?
Quin lo llena?
Dnde es enviado? De dnde viene?
Quin usa el formulario?
Qu autoridad lleva?
Muestreo
Esta tcnica consta de reunir slo un conjunto representativo de los datos. Por ejemplo, en lugar de observar a
75 empleados llenando pedidos en una hora, tome una muestra de 3 o 4 de ellos. O en casos de salidas impresas de
mucho volumen, tal como facturas a clientes, podra reunir una muestra al azar de algunas de ellas.
Es apropiada cuando hay un gran volumen de datos. Puede ser muy costoso controlar todos los datos, pero la
misma informacin puede obtenerse usando muestreo. Saber cunto y qu dato seleccionar es un trabajo para
especialistas que usan tcnicas estadsticas.
2.
Entrevista.
La entrevista es un medio de obtener informacin de las personas conocedoras a travs de preguntas que
propone el entrevistador, dicho de otra manera, es un intercambio de informacin cara a cara, con un propsito
especfico.
En el desarrollo de sistemas, la entrevista es el medio ms significativo y productivo del que disponen los
participantes en la recoleccin de informacin, adems, tiene la ventaja de permitir que el analista entre en contacto
desde el principio con las personas involucradas en el uso del sistema y establezca relaciones de simpata con ellas, lo
cual es benfico para el desarrollo del estudio.
58
Como todo trabajo, el entrevistador debe planificar la entrevista antes de realizarla y contemplar al menos los
siguientes puntos:
1. Anlisis de antecedentes
2. Determinacin del objetivo de la entrevista
3. Seleccin de entrevistados
4. Preparacin del entrevistado
5. Seleccin y tipo de preguntas: Las entrevistas pueden efectuarse estructuradamente o no.
Entrevista estructurada se refiere a que previo a la realizacin de la entrevista, el entrevistador prepare la lista
de preguntas que se van a proponer.
Entrevista no estructurada se refiere a que la entrevista se efecte de manera libre, en forma de pltica durante
la cual el entrevistador permitir que espontneamente surja el tema de su inters. Las ventajas y desventajas que
presentan cada una de stas alternativas son:
Entrevista No Estructurada.
Ventajas
El entrevistador tiene mayor flexibilidad al realizar las preguntas.
Puede utilizarse negativamente el tiempo, tanto de quien responde como del entrevistador.
El entrevistador puede explotar reas que surgen espontneamente durante la entrevista.
Desventajas
Los entrevistadores pueden introducir sesgos en las preguntas o al informar de los resultados.
Puede producir informacin sobre reas que se minimizaron o en las que no se pens que fueran
importantes
El anlisis e interpretacin se dificulta y requiere de tiempo.
En general se necesita de ms tiempo para su desarrollo.
Entrevista Estructurada.
Ventajas.
Asegura la elaboracin uniforme de las preguntas para todos los que van a responder.
Alto costo de preparacin
Fcil de administrar y evaluar. Los que responden pueden no aceptar un alto nivel en la estructura y el
carcter mecnico de las preguntas.
Evaluacin ms objetiva tanto de quienes responden como de las respuestas a las preguntas.
59
Desventajas
Un alto nivel en la estructura puede no ser adecuado para todas las situaciones.
Se necesita un limitado entrenamiento del entrevistador.
El alto nivel de la estructura reduce responder en forma espontnea, as como la habilidad del
entrevistador para continuar con comentarios hacia el entrevistado.
Resulta en entrevistas ms cortas en tiempo.
Cuando la entrevista es estructurada, es conveniente ocuparse del tipo de preguntas a usar las cuales
dependiendo de la forma en que se espera una respuesta pueden ser: abiertas, cerradas o mixtas. En las primeras, la
respuesta se expresa libremente (son tiles para explorar el problema), en las segundas, la respuesta se presenta en forma
opcional de entre una serie de alternativas propuestas y por ltimo el tercer tipo es una combinacin de las dos
anteriores.
A continuacin se describen algunos factores a considerar Antes, Durante y Despus de realizar una entrevista:
Antes de La Entrevista.
1. Organizar y preparar la entrevista considerando :
1.1. La posicin que ocupa en la organizacin el futuro entrevistado
1.2. Las actividades bsicas y responsabilidades del futuro entrevistado
1.3. Preparar las preguntas que van a plantearse y los documentos de apoyo necesarios.
2. Confirmar la cita
3. Conseguir que alguien lo introduzca.
4. Llegar temprano.
5. Vestirse adecuadamente
Durante la Entrevista.
1. Al efectuar la entrevista tomar en cuenta los siguientes pasos :
1.1. Comenzar por presentarse y sealar la naturaleza del proyecto sobre el cual se est trabajando, sus
propsitos y sus objetivos.
1.2. Explicar la funcin del analista y lo que se espera del entrevistado.
2. En relacin al comportamiento del entrevistador durante el desarrollo de la entrevista se recomienda:
2.1. Ser un buen escucha. Escuchar atentamente y no anticiparse a las respuestas. Dejar hablar al
entrevistado.
60
2.2. No probar reacciones.

2.3. No creer que sabe ms que el entrevistado porque el experto es l.
2.4. Evitar terminologa tcnica, como por ejemplo hablar de cerebros electrnicos, sistemas
operativos, UNIX, LINUX, memoria RAM, campos de la base, SQL, compilar, etc.
2.5. Conservar el control de la entrevista evitando divagaciones y comentarios al margen de las
preguntas.
2.6. Evitar externar opiniones o crticas cuando se encuentren fallas o deficiencias.
2.7. No juzgar los hechos.
2.8. Evitar dar sugerencias.
2.9. No tomar decisiones.
2.10. No entrar en polmica con el entrevistado.
2.11. Seguir las reglas de cortesa y de trato amable como: ser puntual, corts, calmado, paciente,
profesional, mostrar inters fijando la vista en el entrevistado, preguntar cuando no se entienda algo,
ser amigable (pero no demasiado).
2.12. No despreciar el trabajo del entrevistado ni humillarlo presentndole formas complejas y
desconocidas para l o cuestionarios con tecnicismos.
2.13. Si el entrevistado externa fatiga o inquietud, dar por terminada la entrevista aunque no de
manera cortante.
3. Al final de la entrevista resumir para confirmar la informacin con el entrevistado y verificar que se
han considerado todos los temas preparados.
4. Expresar al entrevistado agradecimiento por la ayuda proporcionada, concertar una nueva cita o bien,
dejar la puerta abierta de ser necesario.
5. Ofrecer al entrevistado el resumen de la entrevista.
Despus de la Entrevista.
1. Escribir lo recopilado, analizarlo y obtener conclusiones
2. Verificar si hay confusiones.
3. Reportar los resultados y enviar una copia al entrevistado solicitando su confirmacin, correcciones o
adiciones.
4. De ser necesario solicitar nuevamente cita.
5. Archivar los resultados de la entrevista para referencias posteriores.
61
3.
Cuestionario.
El cuestionario es una tcnica que permite recoger opiniones, posturas, conductas y caractersticas de personas
o situaciones a travs de un conjunto de preguntas formalizadas en un documento. Las preguntas pueden ser abiertas,
cerradas o mixtas (ver entrevista). En el desarrollo de sistemas, el uso del cuestionario es limitado a aquellos casos en los
que la entrevista no puede ser utilizada debido a la distancia fsica o bien, cuando el grupo del cual se obtendr la
informacin es numeroso (grupo de vendedores) o como posible medio de verificacin de la informacin obtenida por
otros medios.
En la elaboracin de un cuestionario, es necesario definir:
1. Qu datos se desean conocer (Objetivo) y quines son las personas ms calificadas para
proporcionarlos.
2. Seleccionar el tipo de preguntas ms adecuadas: abiertas, cerradas o mixtas.
3. Desarrollar un conjunto de preguntas (considerando la forma de anlisis de las respuestas (tabulacin
manual o electrnica)).
4. Revisar el cuestionario para encontrar fallas o defectos como pueden ser :
4.1. Interrogantes innecesarias
4.2. Preguntas que puedan malinterpretarse
4.3. Preguntas que no se puedan responder
4.4. Preguntas que llevan a determinada respuesta
4.5. Preguntas mal establecidas que lleven a varias respuestas
4.6. Falta de opciones en preguntas cerradas
4.7. Desorden en la secuencia de preguntas
4.8. Falta de espacio para responder
4.9. Tendencia central, indulgencia y efecto de halo al usar escalas
5. Probar el cuestionario
6. Analizar las respuestas del grupo de prueba y realizar correcciones
7. Realizar cambios finales de edicin y de presentacin.
8. Aplicar el cuestionario considerando :
8.1. Distribuir el cuestionario de ser posible con los nombres de cada persona (solamente si la
informacin no implica compromisos).
8.2. Distribuir el cuestionario con una explicacin del propsito del mismo, as como del uso que se
dar a las respuestas y si es necesario especificar el carcter confidencial de las respuestas.
8.3. Agradecer la sinceridad de las respuestas remarcado la importancia de las mismas.
8.4. Considerar de ser necesario instructivo para el llenado del cuestionario.
62
8.5. Establecer de forma amable el tiempo lmite para la devolucin del cuestionario.
9. Codificar y capturar la informacin.
10. Analizar la informacin recopilada
4.
Observacin.
La observacin es una tcnica que permite obtener informacin en forma directa a travs del sentido de la vista.
Permite al observador determinar qu se est haciendo, cmo se est haciendo, quin lo hace, cundo se realiza, cunto
tiempo ocupa en realizarse, dnde se hace y por qu se hace.
La observacin, brinda informacin al observador acerca de las diferencias entre lo que debera suceder de
acuerdo con los procedimientos normales de operacin, controles establecidos, requisicin de formas y perodo de
tiempo para la realizacin de alguna tarea en particular y lo que realmente ocurre como puede ser: retraso al hacer el
trabajo, etapas de procedimientos omitidas, trabajo extra innecesario, documentos mal requisitados, informacin
manejada de memoria, informacin sin archivar, etc.
Existen varios mtodos de llevar a cabo la observacin. Se puede observar alguna persona o actividad sin que el
observado se d cuenta y sin que el observador realice ninguna interaccin con el observado, tambin se puede observar
sin intervenir el observador pero con pleno conocimiento por parte del observado y por ltimo, se puede observar y a la
vez estar en contacto con la persona observada.
Para obtener mejores resultados del proceso de observacin, es conveniente considerar los siguientes
lineamientos:
1. Determinar lo que se va a observar
2. Estimar el tiempo necesario de observacin
3. Obtener autorizacin para efectuar la observacin (por parte del jefe)
4. En su caso, explicar a las personas que van a ser observadas lo que se va a llevar a cabo y las razones
para hacerlo.
5. Desarrollar la observacin considerando :
5.1. Familiarizarse con los componentes fsicos del rea en observacin
5.2. Mientras se observa, tomar el tiempo en forma peridica
5.3. Anotar lo que se observa de manera especfica evitando generalidades y descripciones vagas (ser
objetivo).
5.4. Si se est en contacto con las personas observadas, evitar hacer comentarios de cualquier tipo.
5.5. Observar las reglas de educacin y seguridad en su caso.
6. Documentar y organizar formalmente las notas de la observacin.
7. Es conveniente, revisar al final de la observacin, los resultados y conclusiones de la misma tanto con
las personas observadas como con sus superiores inmediatos.
63
Como un comentario general, a las personas no les gusta ser observadas por lo cual tienden comportarse de
manera distinta a la que normalmente lo hacen, por ello, se recomienda que la observacin se utilice conjuntamente con
algn otro medio de recopilacin de datos como puede ser la entrevista (con la finalidad de prepararla o bien, de
estructurarla).
La observacin es costosa ya que requiere de tiempo y experiencia por parte del observador.
En realidad la observacin es ms efectiva cuando se realiza en niveles operativos ya que en stos niveles las
actividades que se realizan son de tipo repetitivo y generalmente no involucran el proceso de decisin el cual es a veces
es ms fcil de entender a travs de otros medios como por ejemplo el de la entrevista.
A continuacin se presenta un conjunto de comportamientos que el observador debe tener en cuenta en la
observacin de la conducta del tomador de decisiones.
4.4.
Instruye a sus subordinados

Instruye a sus colegas
Instruye a sus superiores
Consulta a sus subordinados
Consulta a sus colegas
Consulta a sus superiores
Reprende a sus subordinados
Reprende a sus colegas
Reprende a sus superiores
Abre la correspondencia
Contesta el telfono
Realiza llamadas
Lee informacin externa
Lee informacin interna
Procesa su propia informacin
Le pide a otros que procesen su propia informacin
Especificacin de Requerimientos.
Es un proceso de representacin que esta basado en los siguientes principios:
Separar funcionalidad de implementacin: la especificacin es una descripcin de lo que se desea, en

vez de cmo se implementa.
Se necesita un lenguaje de especificacin de sistemas orientado al proceso, que es un modelo de

comportamiento deseado en trminos de respuestas funcionales a distintos estmulos de entorno.
Una especificacin debe abarcar el sistema del cual el software es una componente. Solo dentro del
contexto del sistema completo y de la interaccin entre las partes puede ser definido el
comportamiento de una componente especfica.
Una especificacin debe abarcar el entorno en el que el sistema opera.
Una especificacin de sistema debe ser un modelo cognitivo, que es la descripcin del sistema tal
como es.
Una especificacin debe ser operacional, en el sentido de ser lo suficientemente completa y formal
como para poder evaluar diferentes alternativas de implementacin.
64
4.4.1.
Una especificacin del sistema debe ser tolerante con la incompletitud y complementable.
Una especificacin debe ser localizada y dbilmente acoplada frente a las posibles modificaciones a
sta.
El formato de representacin y el contenido deben ser adecuados al problema
Debe aadirse la informacin contenida dentro de una definicin, en capas de informacin para
representar el nivel de detalle adecuado para comprenderla
Debe restringirse el nmero de formas notariales y ests deben ser consistentes en su uso.
Las representaciones deben ser revisables.
Herramientas para documentar procedimientos y decisiones.

Se presentan 3 herramientas para documentar procedimientos:
1.
rboles de decisin
2.
Tablas de decisin
3.
Espaol estructurado
Antes de explicar estas herramientas hay que comentar lo que son las condiciones y las acciones.
Condiciones.
Son los posibles estados de una entidad. Las condiciones cambian y por eso los analistas les llaman variables de
decisin. Una factura puede ser descrita por las condiciones siguientes: autorizada o no autorizada, importe correcto o
importe no correcto, con firma o sin firma. El analista debe identificar las condiciones que pueden presentarse en
cualquier situacin, pero solo se incluyen en el estudio aquellas que sean relevantes.
Acciones.
Cuando se conocen las condiciones, entonces se debe determinar qu hacer cuando se producen. Las acciones
son procedimientos que puede elegir una persona cuando se encuentra con las condiciones.
4.4.1.1. rboles de Decisin.

Caractersticas de los rboles de decisin.
El rbol de decisin es un diagrama que representan en forma secuencial condiciones y acciones; muestra qu
condiciones se consideran en primer lugar, en segundo lugar y as sucesivamente. Este mtodo permite mostrar la
relacin que existe entre cada condicin y el grupo de acciones permisibles asociado con ella.
La raz del rbol, aparece en la parte izquierda del diagrama y est es el punto donde comienza la secuencia de
decisin. La rama a seguir depende de las condiciones existentes y de la decisin que debe tomarse. Al avanzar de
izquierda a derecha por una rama particular, se entiende una serie de toma de decisiones. Despus de cada punto de
decisin, se encuentra el siguiente conjunto de decisiones a considerar. De tal forma que los nodos del rbol representan
condiciones y sealan la necesidad de tomar una determinacin relacionada con la existencia de alguna de estas, antes de
seleccionar la siguiente trayectoria. La parte que se encuentra en la parte derecha del rbol indican las acciones que
deben realizarse, las que su vez dependen de la secuencia de condiciones que les preceden.
65
Uso de rboles decisiones.

El desarrollo de rboles de decisin beneficiado analista en dos formas. Primero que todo, la necesidad de
describir condiciones y acciones llevan a los analistas a identificar de manera formal las decisiones que actualmente
deben tomarse. De esta forma, es difcil para ellos pasar por alto cualquier etapa del proceso de decisin, sin importar
que este dependa de variables cuantitativas o cualitativas. Los rboles tambin obligan a los analistas a considerar la
consecuencia de las decisiones.
Se ha demostrado que los rboles de decisin son eficaces cuando es necesario describir problemas con ms de
una dimensin o condicin. Tambin son tiles para identificar los requerimientos de datos crticos que rodean al
proceso de decisin, es decir, los rboles indican los conjuntos de datos que la gerencia requiere para formular
decisiones o tomar acciones. El analista debe identificar y elaborar una lista de todos los datos utilizados en el proceso
de decisin, aunque el rbol de decisin no muestra todo los datos.
Si los rboles de decisin se construyen despus de completar el anlisis de flujo de datos, entonces es posible
que los datos crticos se encuentren definidos en el diccionario de datos (el cual describe los datos utilizados por el
sistema y donde se emplean). Si nicamente se usan rboles de decisiones, entonces el analista debe tener la certeza de
identificar con precisin cada dato necesario para tomar la decisin.
Los rboles de decisin no siempre son la mejor herramienta para el anlisis de decisiones. El rbol de
decisiones de un sistema complejo con muchas secuencias de pasos y combinaciones de condiciones puede tener un
tamao considerable. El gran nmero de ramas que pertenecen a varias trayectorias constituye ms un problema que una
ayuda para el anlisis. En estos casos los analistas corren el riesgo de no determinar qu polticas o estrategias de la
empresa son la gua para la toma de decisiones especficas. Cuando aparecen estos problemas, entonces es momento de
considerar las tablas de decisin.
Sirven para organizar la informacin recopilada con respecto a la toma de decisiones y no haya malas
interpretaciones.
Condicin
Accin
Condicin
Accin
Condicin
Condicin
Raz
Condicin
Condicin
Accin
Accin
Fig. 4.1: rbol de Decisin
4.4.1.2. Tablas de Decisin.
La tabla de decisin es una matriz de renglones y columnas que indican condiciones y acciones. Las reglas de
decisiones, incluidas en una tabla de decisin establecen el procedimiento a seguir cuando existen ciertas condiciones.
Este mtodo se emplea desde mediados de la dcada de los 50, cuando fue desarrollado por General Electric para el
anlisis de funciones de la empresa como control de inventarios, anlisis de ventas, anlisis de crditos y control de
transporte y rutas.
66
Caractersticas de las tablas de decisin.

Las tablas estn integradas por cuatro secciones: identificacin de condiciones, entradas de condiciones,
identificacin de acciones y entrada de acciones. La identificacin de condiciones seala aquellas que son relevantes. La
entrada de condiciones indican qu valor, as es que lo hay, se debe asociar para una determinada condicin. La
identificacin de acciones enlista el conjunto de todos los pasos que se deben segua cuando se presenta cierta condicin.
La entrada de acciones muestra las acciones especficas del conjunto que deben emprenderse cuando ciertas condiciones
o combinaciones de estas son verdaderas.
Las columnas de lado derecho de la tabla enlazan condiciones y acciones, forman reglas de decisin que
establecen las condiciones que debe satisfacerse para emprender un determinado conjunto de acciones. El orden de la
secuencia se omite, cosa que no sucede con los rboles de decisin. La regla de decisin incorpora todas las condiciones
que deben ser ciertas y no slo una a la vez.
Ejemplo:
Pago de los servicios mdicos
La atencin sanitaria en un hospital es de carcter obligatorio, sin preocupar la financiacin de la asistencia. Si
el paciente dispone de seguridad social, su asistencia estar exenta de pago, sino es as pero dispone de un seguro
mdico slo har frente al pago de la consulta. Slo en el caso de no disponer el paciente ni de seguridad social, ni de
seguro mdico pagar todos los servicios.
1
2
1
2
3
Condiciones
El paciente tiene seguro mdico
El paciente tiene seguro social
Acciones
Pagar la consulta
Exento de pago
Pagar todos los servicios
Reglas de Decisin
SI
SI
NO NO
SI
NO
SI
NO
X
X
X
X
Fig. 4.2: Pago de los servicios mdicos
Cmo construir tablas de decisin?

1. Identificar las condiciones en la decisin.
2. Identificar las acciones.
3. Estudiar las posibles combinaciones de condiciones. Si N condiciones 2N Combinaciones.
4. Llenar la tabla con las reglas de decisin.
5. Marcar las entradas correspondientes con una X.
6. Examinar la tabla para detectar reglas redundantes.
Pensemos en una tabla de decisin con el siguiente formato:
67
C1
C2
C3
A1
A2
Condiciones
Suficiente efectivo
Crdito bueno
Desea "hacerse a un lado"
Acciones
Seleccionar el artculo a comprar
No seleccionar ningn artculo
R1
SI
SI
SI
R2
SI
SI
NO
Reglas de Decisin
R3
R4
R5
R6
SI
SI
NO NO
NO NO
SI
SI
SI
NO
SI
NO
X
R7
NO
NO
SI
R8
NO
NO
NO
X
X
Fig. 4.3: Tabla de decisin con contradicciones

Verificacin de tablas de decisin
Despus de construir una tabla debe comprobarse:
1. Que sea completa: es decir que no se haya omitido ningn posible estado de las condiciones.
2. Que no tenga redundancias ni contradicciones:
Redundancia:
Es cuando aparece repetido el mismo estado de condicin con el mismo tratamiento, es decir, dos
reglas de decisin son idnticas salvo para una condicin y las acciones para las dos reglas son
idnticas. R1 y R2.
Contradiccin:
Es cuando aparece repetido el mismo estado de condicin con distinto tratamiento. R5 y R7.
3. Que no haya condiciones indiferentes: cuando toda una fila en la entrada de condiciones tiene guiones.
Una vez eliminadas las redundancias y contradicciones
C1
C2
C3
A1
A2
Condiciones
Suficiente efectivo
Crdito bueno
Desea "hacerse a un lado"
Acciones
Seleccionar el artculo a comprar
No seleccionar ningn artculo
R1
SI
SI
-
Reglas de Decisin
R2
R3
R4
R5
SI
NO NO
SI
NO NO NO
SI
SI
SI
NO
R6
SI
NO
NO
X
X
Fig. 4.4: Tabla de decisin filtrada
4.4.1.3. Espaol Estructurado.

Consiste en expresar los procesos en espaol con restricciones, es decir, formar sentencias en espaol. Tambin
se le conoce como lenguaje de diseo de programas. El fin de esta herramienta es crear un equilibrio entre la precisin
de un lenguaje formal de programacin y la informalidad del lenguaje espaol.
Una sentencia en lenguaje espaol puede consistir en una ecuacin algebraica como X = (Y * Z) / (Q + 14) pero
tambin podemos utilizar los verbos siguientes:
68
Leer, Escribir, Buscar, Sumar, Restar, Multiplicar, Dividir, Borrar, Asignar, Reemplazar, Clasificar.
Ejemplo:
Obtener la cantidad total del dinero de facturas recibidas en un fichero de facturas, para el da de hoy.
Abrir (factura)
Leer (r, factura)
total = 0
Mientras (NO(fin(factura))) y (fecha = "hoy") Hacer
Leer (r, factura)
Escribir (r. importe-factura, r. nombre-cliente)
total = total + r. importe-factura
Fin-Mientras
Escribir (total)
Cerrar (factura)
Veamos las distintas sentencias en lenguaje espaol.
1.
2.
3.
Operadores
Aritmtico:
+ - * / Div() Mod() Raiz() Cuadrado()
Relacional:
= <> > < >= <=
Lgicos:
Y O NO
Asignacin:
=
Sentencias de Lectura y Escritura

Lectura desde dispositivo de entrada cualquiera:
Leer( )
Escritura a dispositivo de salida cualquiera:
Mostrar( ) o Escribir( )
Sentencias de Seleccin
Si-Entonces-Sino.
Es usada para describir alternativas y puede tomar las 2 formas siguientes:
Si (condicin) Entonces
sentencia (1)
Fin-Si
Si (condicin) Entonces
sentencia (1)
Sino
69
sentencia (2)
Fin-Si
En Caso de.
Es usada para describir alternativas basadas en mltiples decisiones. Toma el formato siguiente
En caso de
variable = valor 1
sentencia (1)
variable = valor n
sentencia (n)
etoc
sentencia (n+1)
Fin-en-caso
4.
Sentencias de Repeticin
Mientras-Hacer.
Es usada para describir una sentencia que repetir las acciones hasta que la condicin evaluada sea falsa.
Mientras (condicin) Hacer
sentencia
Fin-Mientras
Repetir-Hasta.
Es usada para describir una sentencia que repetir las acciones hasta que la condicin evaluada sea verdadera.
Repetir
sentencia
Hasta condicin
Para-Hacer.
Es usada para describir una sentencia que repetir las acciones una cantidad de veces determinada por los
valores de inicio y trmino.
Para variable = valor-inicio hasta valor-final hacer
Sentencia
Fin-Para
5.
Sentencias de Archivos
Apertura de archivo:
Abrir (archivo-lgico)
Cerrado de archivo:
Cerrar (archivo-lgico)
Lectura de registro:
Leer (registro-lgico, archivo-lgico)
Almacenado de registro:
Escribir (registro-lgico, archivo-lgico)
Asignacin de valor a un campo de registro:
registro-logico.campo = valor
70
4.5.
Otras Tcnicas en el desarrollo de Sistemas
4.5.1.
Grficas Administrativas
La graficacin, es una tcnica que representa a travs de figuras en forma esquemtica y simplificada, algunos
de los aspectos de una empresa, o una actividad de la misma. De todas las herramientas y tcnicas que se utilizan en el
desarrollo de los sistemas de informacin automatizados, la graficacin es la que se identifica ms estrechamente con
este trabajo, ya que es til no solo en la recopilacin de informacin sino tambin en el anlisis, diseo, implementacin
(comunicacin) y en la documentacin.
Sin considerar que son todas las que existen, las grficas administrativas en este trabajo se clasificarn en:
1.
Organigramas
2.
Diagramas de Distribucin
3.
Diagramas de Flujo
4.
Diagramas de flujo de datos y;
5.
Otras grficas.
4.5.1.1. Organigramas.
Los organigramas son la expresin grfica de los niveles de autoridad y responsabilidad de las unidades que
conforman una organizacin o a una parte de ella (estructura). Los organigramas, consisten fundamentalmente de un
cierto nmero de casillas que representan puestos, personas, o unidades administrativas colocadas jerrquicamente y
relacionadas mediante lneas. Dependiendo de la forma en que se presentan grficamente se conocen cuatro tipos:
verticales, horizontales, circulares o mixtos. Verticales, cuando las lneas de autoridad parten de arriba hacia abajo;
horizontales, cuando las lneas de autoridad parten de izquierda a derecha; circulares, cuando las lneas de autoridad
parten del centro hacia la periferia y mixtos, cuando se hace cualquier combinacin de las anteriores presentaciones. En
la Fig. 4.5., se muestra un ejemplo de cada uno de ellos.
Para elaborar un organigrama es conveniente seguir ciertas reglas para su presentacin:
Utilizar nomenclatura jerrquica uniforme es decir, a cada nivel de la estructura debe de corresponder
igual denominacin (todos directores o jefes o supervisores o bien, todos puestos o funciones).
Las funciones parecidas o relacionadas deben de agruparse juntas.
No usar diferentes tamaos o formas de las figuras geomtricas para representar la importancia de las
unidades administrativas ya que el nivel dentro de la jerarqua es el que la determina.
Algunas veces, no es recomendable incluir en un solo organigrama todos los niveles de la organizacin
ya que la presentacin puede ser confusa, motivo por el cual se recomienda que el organigrama se
muestre una presentacin general y posteriormente cada una de las reas administrativas ms
importantes por separado, y de esta manera simplificar el entendimiento del mismo.
No mezclar estructura con flujos de informacin dentro de ella, ya que el organigrama slo debe de
mostrar unidades administrativas y relaciones de estructura y no las relaciones de informacin entre las
unidades.
Identificar claramente el organigrama. Esto es, la empresa a la que corresponde y el nombre de la

unidad que representa.
71
Establecer el momento de la elaboracin y el autor del diseo ya que las estructuras cambian con el
tiempo y es conveniente conocer quin lo elabor para posibles aclaraciones.
Fig. 4.5: Tipos de Organigramas
72
4.5.1.2. Diagramas de Distribucin.

Los diagramas de distribucin fsica o arquitectnicos, son grficas que representan el conocimiento del
entorno fsico en el que se desarrolla una actividad por lo cual, aportan informacin respecto al espacio y recursos
disponibles.
Estas grficas, son tiles para analizar la ubicacin fsica de los sistemas electrnicos y del equipo perifrico
que los acompaen, tambin, pueden usarse para determinar los flujos de movimientos efectuados por las personas para
llevar a cabo un determinado procedimiento.
4.5.1.3. Diagramas de Flujos o Flujogramas.

Tcnica que facilita la descripcin del trabajo administrativo especialmente en lo que se refiere a sistemas y
procedimientos y tienen como objetivo, facilitar la comprensin de los mismos. Muestran grficamente y con diversos
grados de detalle la secuencia y el curso de las operaciones, las personas, los materiales, los datos o las formas de que se
compone un procedimiento o parte de l.
73
Clasificacin
Existen smbolos especiales para elaborar los diagramas, los cuales, se pueden clasificar en:
1. Abstractos.
1.1. ASME (American Society of Mechanical Engineers). Esta simbologa, es recomendada para el
flujo de materiales y es mas utilizada por los ingenieros.
1.2. ANSI (American National Standard Institute). Se recomienda para representar flujos de
informacin, datos, formas y son los ms utilizados por las personas en el rea de la administracin.
2. Figurativos.
2.1. Fotografas
2.2. Dibujos
2.3. Caricaturas
Por la forma de presentacin y contenido, los diagramas pueden ser:
Verticales: cuando el seguimiento del flujo se presenta de arriba hacia abajo.
Horizontales: cuando el seguimiento del flujo se muestra de izquierda a derecha
Panormicos: cuando presentan una visin completa del sistema.
Analticos: cuando describen algn procedimiento del sistema o alguna parte en especial del
mismo.
A continuacin se muestra un ejemplo de la simbologa ANSI y la comparacin de simbologa abstracta y

figurativa en un procedimiento de salida de documentos de correspondencia.
74
Ventajas y Desventajas.
Las ventajas asociadas a los diagramas de flujo, se refieren a:
Son concisos y por tanto mas fciles de entender de una mirada que una descripcin narrativa. Sin
embargo para fines de documentacin es conveniente acompaarlos de dicha narracin para
complementar su entendimiento.
Presentan una visin grfica y por tanto objetiva del flujo.
Expresan claramente la secuencia y la lgica de modo que facilitan la correccin.
Muestran si se han cubierto todas las posibilidades.
Facilitan la comunicacin entre el elemento humano.
Sin embargo, sus principales desventajas son:
Es necesario definir el significado de los smbolos usados porque pueden causar confusin.
Su elaboracin, requiere de tiempo.
Cuando se llevan al detalle, pueden ser difciles de entender.
La informacin dentro de cada smbolo es muy generalizada.
Para disearlo, se deben de contemplar ciertos convencionalismos como son:

75
Se recomienda que los diagramas vayan de arriba hacia abajo y de izquierda a derecha.
Evitar hasta donde sea posible, el cruce de lneas.
Si un diagrama no es claramente comprensible para quien lo contempla, debe de simplificarse

o dividirse en dos o ms partes.
La simbologa utilizada, debe de contribuir a su comprensin y no a dificultarla.
Es recomendable que cuando los diagramas sirvan para documentacin, lleven una
descripcin.
Deben de evitarse los smbolos especiales.
Es conveniente previa a la elaboracin del diagrama, elaborar el algoritmo correspondiente.
Cuando el diagrama ocupe ms de una pgina, cada una de stas se numerar en secuencia y
se debe dejar espacio suficiente para el ttulo el cual debe ser breve y claro.
El diagrama debe de ser legible y para fines de presentacin, deber estar limpio y contar con
el tamao adecuado para que todos los asistentes a su presentacin, puedan leerlos.
El diagrama debe ser identificado con el ttulo del diagrama, fecha de elaboracin y
responsable de su elaboracin.
Un problema que se presenta en el diseo de diagramas de flujo, es la identificacin de lo que se va a

representar ya que en los procedimientos administrativos, se involucran no solamente actividades sino tambin por
ejemplo, formas o materiales, en mi opinin, el tratar de incluir en los diagramas, la secuencia lgica de otros elementos
adems de las actividades, solamente produce confusiones en quienes los leen, por tanto, es muy importante definir
claramente el proceso o procedimiento que se necesita diagramar y lo que el diagrama va a representar en la secuencia
lgica del mismo. En este sentido, los diagramas pueden seguir:
76
1.
Formas.
En algunas ocasiones se acostumbra combinar la descripcin de un procedimiento con la distribucin de

formas, lo cual la mayora de las veces complica el entendimiento en lugar de facilitarlo. Si la distribucin de
formas es importante en una organizacin, es recomendable considerarla en un procedimiento por separado, o
bien, una propuesta para hacerlo se muestra en la siguiente figura.
2.
Materiales.
La forma que probablemente sea la ms conveniente para representar la secuencia de materiales es a travs
del uso de dibujos.
77
3.
Personas.
Representar la secuencia de actividades que debe realizar una persona se ejemplifica mediante el siguiente
diagrama.
4.
Lgica.
Aunque los diagramas no son un lenguaje de programacin, en realidad en algunos casos, ayudan en la
descripcin de la secuencia de la lgica que debe de seguir un programa.
78
5.
Datos.
Los diagramas de flujo de datos han sido utilizados como herramientas del modelo desarrollado por
Edward Yourdon como metodologa para el desarrollo de sistemas de informacin. Por la importancia de estos
diagramas para el analista de sistemas, sern considerados en un punto por separado (DFD, Diagramas de
Flujos de Datos).
79
5.
Anlisis Estructurado.
5.1.
Concepto
Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de informacin, tienen que
profundizar en un rea de la Organizacin, de la cual tienen poco conocimiento. Del trabajo del analista se espera que se
produzca una mejora en el sistema. As que el analista debe ser capaz de:
Aprender los detalles y procedimientos del sistema en uso.
Prever necesidades futuras de la Organizacin, en funcin del crecimiento, cambios futuros en el

sector, introduccin de nuevas tecnologas etc.
Documentar detalles del sistema actual para su comprensin y discusin por otros profesionales de la
organizacin.
Evaluar la efectividad y eficiencia del sistema actual y sus procedimientos.
Recomendar modificaciones del sistema actual, o proponer un nuevo sistema completo, justificndolo
en cada caso.
Documentar las caractersticas del nuevo sistema con un nivel de detalle que permita comprender a
otros sus componentes.
Fomentar la participacin de gerentes y empleados en todo el proceso.
A todas estas tareas, se les une la de cumplir los plazos establecidos. De modo que una de las claves del xito
ser la de estructurar el proceso para el desarrollo del nuevo sistema.
5.1.1.
Anlisis estructurado Para qu?
Por la propia naturaleza los sistemas de informacin, stos no estn bien estructurados, no siguen leyes como
las ciencias, dependen de muchas circunstancias para su funcionamiento (personas, influencias polticas de la
organizacin, restricciones, etc.). El analista debe luchar contra estas circunstancias y determinar los requerimientos de
los sistemas de informacin.
Ante esta realidad, surgen preguntas como: Deben dos analistas desarrollar una lista idntica de
requerimientos cuando estudian de forma independiente la misma situacin? Para una situacin dada, tenemos un nico
diseo correcto posible? La respuesta es que dos analistas que examinan de forma independiente una situacin, sin
herramientas y tcnicas preestablecidas, recopilan informacin diferente que describa el sistema y por lo tanto en
determinacin de requerimientos diferentes.
Esto obliga a normalizar, a estructurar el anlisis de sistemas de informacin. Podemos definir anlisis
estructurado como:
El mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones
para sistemas nuevos o para efectuar modificaciones a los ya existentes.
El anlisis estructurado permite al analista conocer un proceso (actividad) en una forma lgica y manejable al
mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente.
80
Por otra parte una de las claves del xito de un buen anlisis ser el que exista una buena comunicacin entre
usuarios y analistas, esto obliga a disponer de un lenguaje comn, sencillo y fiable de modo que permita minimizar
costes y errores, y maximizar calidad.
5.1.2.
Qu debemos estructurar?
El objetivo que persigue el anlisis estructurado es organizar las tareas asociadas con la determinacin de
requerimientos para obtener la comprensin completa y exacta para una situacin dada. A partir de aqu se determinan
los requerimientos que sern la base de un sistema nuevo o modificado.
La palabra estructura significa:
5.1.3.
1.
El mtodo intenta estructurar el proceso de determinacin de los requerimientos comenzando con la

documentacin del sistema existente.
2.
El proceso intenta incluir todos los detalles relevantes que describen al sistema en uso.
3.
Fcil verificar cuando se han omitido datos relevantes.
4.
La identificacin de los requerimientos ser similar entre varios analistas e incluir las mejores
soluciones y estrategias para las oportunidades de desarrollo de sistemas.
5.
Los documentos de trabajo generados para documentar los sistemas existentes y propuestos son
dispositivos de comunicacin eficientes.
Componentes del anlisis estructurado.

El anlisis estructurado hace uso de los siguientes componentes:
1.
Smbolos grficos. Iconos y convenciones para identificar y describir los componentes de un sistema
junto con las relaciones entre esos componentes.
2.
Diccionario de datos. Descripcin de todos los datos utilizados en el sistema.
3.
Descripciones de procesos y procedimientos. Declaraciones formales que emplean tcnicas y lenguajes

que permiten a los analistas describir actividades importantes que forman parte del sistema.
4.
Reglas. Estndares para describir y documentar el sistema en forma correcta y completa.
El mtodo de anlisis estructurado es sinnimo de anlisis de flujo de datos que es una herramienta para
documentar el sistema existente o actual y determinar los requerimientos de informacin de forma estructurada.
5.2.
Qu es anlisis de flujo de datos?
Los analistas desean conocer las respuestas a cuatro preguntas: Qu procesos integran el sistema? Qu datos
emplea cada proceso? Qu datos son almacenados? Qu datos entran y salen del sistema?
Como vemos el elemento fundamental en una Organizacin (sistema de informacin), van a ser los datos. Los
datos son las guas de las actividades de la Organizacin, inician eventos, son procesados para dar informacin til al
personal, etc.
81
Seguir el flujo de datos por todos los procesos de la organizacin, adems de ser la finalidad del anlisis de
flujo de datos, proporciona a los analistas informacin de cmo se alcanzan los objetivos en la Organizacin.
El anlisis de flujo de datos estudia el empleo de los datos en cada actividad. Se basa en los diagramas de flujo
de datos que muestra de forma grfica la relacin entre procesos y datos, y en los diccionarios de datos que describen de
manera formal los datos del sistema y los sitios donde son utilizados.
5.2.1.
La estrategia de los flujos de datos
El anlisis puede pensarse de tal manera que se estudien actividades del sistema desde el punto de vista de los
datos, donde se originan, cmo se utilizan o cambian, hacia dnde van. Los componentes de la estrategia de flujo de
datos abarcan tanto la determinacin de los requerimientos como el diseo de sistemas. Una notacin bien establecida
facilita la documentacin del sistema actual y su anlisis por todos los participantes en el proceso de determinacin de
requerimientos.
5.2.2.
Ventajas del anlisis de flujo de datos.
Los analistas deben trabajar con los usuarios para hacerles comprender el funcionamiento del sistema actual y
el sistema futuro, para ello se hace aconsejable utilizar un lenguaje comn, sencillo y fiable, estas son las caractersticas
de los diagramas de flujo de datos. Los usuarios pueden hacer sugerencias para modificar los diagramas con la finalidad
de describir las actividades con mayor exactitud, y permitir evitar los errores desde el inicio pudiendo prevenir una
posible falla del sistema.
5.2.3.
Herramientas para el anlisis de flujo de datos
Las herramientas tienen el objetivo de ayudar a entender las caractersticas del sistema. Por lo tanto no deben de
ser un fin, sino un medio para el estudio del sistema.
Las herramientas utilizadas en el anlisis de flujo de datos son:
1.
Diagrama de flujo de datos.
2.
Diccionario de datos.
3.
Diagrama entidad-relacin.
4.
Miniespecificaciones o Especificacin de Procesos.
82
5.3.
Diagramas de Flujo de Datos
5.3.1.
Concepto
Los diagramas de flujos de datos (DFD), es una tcnica de modelado, que nos muestra un sistema como una red
de procesos conectados entre ellos por flujos y almacenamientos de datos.
Es un modelo que proporciona el punto de vista funcional de un sistema.

5.3.2.
Por qu anlisis de flujo de datos?
Los analistas deben trabajar con los usuarios para hacerles comprender el funcionamiento del sistema actual y
el sistema futuro, para ello se hace aconsejable utilizar un lenguaje comn, sencillo y fiable, estas son las caractersticas
de los diagramas de flujo de datos. Los usuarios pueden hacer sugerencias para modificar los diagramas con la finalidad
de describir las actividades con mayor exactitud, y permitir evitar los errores desde el inicio pudiendo prevenir una
posible falla del sistema.
5.3.3.
Notacin de los Diagrama Flujo de Datos
Los mtodos para el anlisis de flujo de datos fueron desarrollados y promovidos por dos organizaciones al
mismo tiempo, Yourdon Inc (compaa de consultora) y Mc Donnell-Douglas (Gane and Sarson). En nuestro libro la
notacin utilizada ser la de Yourdon. Los DFDs se pueden dibujar con slo cuatro elementos grficos sencillos, que
son:
Procesos: El primer componente del DFD. El proceso muestra una parte del sistema que transforma
entradas en salidas, suelen ser personas, procedimientos o dispositivos que utilizan o transforman
datos. El proceso se representa grficamente como un crculo. Los sinnimos comunes son burbuja,
funcin o transformacin.
Fig. 5.1.: Proceso
Flujo de datos: Se representa grficamente por medio de una flecha que entra o sale de un proceso. El
flujo se usa para describir el movimiento de bloques de informacin de una parte del sistema a otra.
Por ello, los flujos representan datos en movimiento, mientras que los almacenes representan datos en
reposo. En algn modelo puede representar movimiento de material. Los flujos muestran la direccin;
segn si los datos se est moviendo hacia adentro o hacia afuera de un proceso (o ambas cosas).
Fig. 5.2.: Flujo de Datos

Podemos hablar de varios tipos de flujos de datos, segun direccin/sentido de los datos, respecto al
proceso:
83
1. Entrada.
Nmero telefnico
Validar
Nmero
Telefnico
Fig. 5.3.: Flujo de Entrada
2. Salida.
Generar
Itinerario
Conductor
Itinerario Conductor
Fig. 5.4.: Flujo de Salida
3. Divergente y Convergente.
Cuando una misma informacin se enva a procesos diferentes, o cuando una
informacin compleja se descompone en varios datos mas sencillos cada uno de los cuales va
a un proceso diferente (divergente). Varios paquetes de datos se juntan para formar parte de
paquetes de datos ms complejos (convergente).
Fig. 5.5.: Flujo Divergente

A partir del contenido de los flujos podemos encontrar:
1.
Dato Individual
Se refiere a que el flujo representa a slo un dato, indivisible
84
2.
Grupo de Datos
En este caso el grupo corresponde a un conjunto de varios datos individuales, que por
necvesidad del sistema no pueden separarse.
3.
Paquete de Datos
El caso del paquete, se refiere a un grupo de grupos, esto es, un conjunto repetitivo
de un grupo en particular.
Almacn de datos: El almacn se utiliza para modelar una coleccin de datos en reposo. Se representa
por dos lneas paralelas. Es tentador asociar a los almacenes los archivos o bases de datos, es as como
a menudo se implantan en un sistema informtico, pero un almacn tambin puede consistir en datos
almacenados en cualquier soporte que contenga datos (archivos de papel, tarjetas, etc.).
Fig. 5.6.: Almacenamiento
Entidad Externa (Terminador): El siguiente componente del DFD es un terminador; representado

grficamente como un rectngulo representan fuentes (origen) o destinos externos de datos que pueden
ser: personas, programas, organizaciones u otras entidades que interactan con el sistema pero se
encuentran fuera de su frontera. En algunos casos, un terminador puede ser otro sistema con el cual se
comunica ste.
Fig. 5.7.: Entidad Externa
Existen tres cosas importantes que debemos recordar acerca de las Entidades Externas:
Son externos al sistema que se est modelando; los flujos que conectan los terminadores a diversos
procesos (o almacenes) en el sistema representan la interfaz entre l y el mundo externo.
El analista de sistemas no puede modificar los contenidos, la organizacin ni los procedimientos

internos asociados en posibilidades de cambiar los contenidos de un terminador o la manera en que
trabaja. El terminador con lo que representa est fuera del dominio.
Las relaciones existentes entre los terminadores no se muestran en el modelo DFD. Si existen
relaciones entre los terminadores y si es esencial para el analista modelarlos para poder documentar los
requerimientos y si es esencial para el analista modelarlos para poder documentar los requerimientos
del sistema, entonces, por definicin, los terminadores son en realidad parte del sistema y debieran
modelarse como procesos.
Deberemos respondernos una serie de preguntas como cmo se piden los datos?, en qu secuencia se reciben
los datos?, en qu secuencia se generan?, no deben ser respuesta de los DFDs, estas respuestas forman parte del
procedimiento.
85
Cada componente en un diagrama de flujo de datos tiene una etiqueta con un nombre descriptivo. Los nombres
de los procesos tambin reciben un nmero para poder identificarlo.
Los diagramas de flujo de datos se concentran en el movimiento de datos a travs del sistema, no en los
dispositivos o el equipo. Se identifican y describen los datos que fluyen por todo el sistema, explicando porque los datos
entran o salen y cual es el procesamiento que se realiza con ellos (guardan y recuperan de almacenamiento de datos).
5.3.4.
Directrices para la construccin de DFDs
Hay una serie de reglas que son necesarias para poder construir los DFDs correctamente. La finalidad de estas
reglas es ayudar a confeccionar DFDs correctos, y permitir dibujar un DFD agradable a la vista y por tanto que tenga
mas probabilidades de que sea estudiado por el usuario con el objetivo de ayudarle a su comprensin.
Las reglas a seguir para la construccin de un DFD son:

1.
Elegir los nombres representativos para los procesos, flujos de datos, almacenamientos y entidades
externas de forma que describa lo ms precisamente posible al objeto que representa.
Procesos: en el caso de los procesos debemos identificar las funciones que el sistema est llevando a
cabo, es decir el nombre del proceso describir lo que se hace:
Funcin: Verbo + objeto. El verbo no debe estar conjugado (terminaciones ar, er e ir)
Verbo significativo (Validar, Registrar, etc.).
Evitar palabras de uso exclusivo por parte de usuario.
Evitar terminologa informtica (Proceso, Funcin, Rutina, Procedimiento, etc.).
Flujos: los flujos deben identificar la informacin y/o los datos que fluyen a travs del sistema.
Se deben evitar el uso de las palabras informacin y dato.
El nombre es una unidad, por lo tanto, si el nombre esta compuesto por ms de una palabra, deber
unirlas por un guin bajo (_).
Almacenes: Los almacenes deben nombrarse con nombre que representen la informacin y/o datos que
estos contienen.
Evitar el uso de palabras como Archivo, Almacn, etc.
Entidades: su nombre debe ser el que se utiliza tanto interna como externamente al sistema, y no debe
crear un nombre nuevo o particular de ella, sino que usar el nombre universal de la entidad.
86
2.
Numerar los procesos para identificarlos de forma rpida y unvoca.
Los nmeros no indican secuencia. El modelo de DFD es una red de procesos asincrnicos que se
intercomunican, lo cual es, una representacin precisa de la manera en la realidad muchos sistemas operan. El hecho que
exista procesos no pueda realizar su funcin por falta de algn dato de otro proceso no implica correspondiente con la
numeracin. Son la base para crear la jerarqua de diagramas cuando se introduzcan los diagramas de flujo por niveles.
3.
Evitar DFD excesivamente complejos y recargados, es decir, con muchos elementos grficos juntos.
El propsito de un DFD es modelar de forma precisa las funciones que se deben llevar a cabo un sistema y las
interacciones entre ellas. Pero otro propsito del DFD, de igual importancia, es que sea ledo y comprendido, no slo por
el analista que construyo el modelo, sin por los usuarios que sean los expertos en la materia de aplicacin. Esto significa
que el diagrama debe ser fcilmente entendido, fcilmente asimilado y placentero a la vista.
Existe una excepcin, un DFD conocido como diagrama de contexto, que representa el sistema entero como un
solo proceso y destaca las interfaces entre el sistema y los terminadores externos.
4.
Consolidar flujos para ganar en legibilidad.
5.
Re-dibujar el DFD tantas veces como sea necesario, con el objetivo de:
Conseguir un DFD tcnicamente correcto.
Aceptado por el usuario
Estar lo suficientemente bien dibujado como para que no sea embarazoso mostrarlo a la direccin de la
organizacin.
6. Asegurarse que el DFD es consistente.

Existen reglas para asegurar la consistencia del DFD con otros modelos de sistemas; el diagrama de entidadrelacin, diagrama transicin de estados, diccionario de datos, y la especificacin de procesos. Las principales reglas de
consistencia son:
Evite sumideros infinitos, procesos que tienen entradas pero no salidas. Evite burbujas de generacin
espontnea, procesos que tienen salidas sin tener entradas. Situacin normalmente incorrecta.
Cuidado con flujos y procesos no etiquetados, ya que puede esconder errores importantes.
Tener cuidado con los almacenes de slo lectura o slo escritura, ya que todo almacenamiento
debe tener un flujo entrante y uno saliente, es decir, la informacin se almacena se consume.
Las entidades externas no pueden acceder directamente a ningn almacenamiento. Siempre debe
mediar un proceso que haga de intermediario y extraiga o inserte la informacin pertinente.
87
Sumidero de informacin
Fuente de informacin
Fig. 5.8.: Sumidero y Fuente de Informacin
5.3.5.
Niveles de un DFD
Cuando nos enfrentemos ante un modelo real, nos enfrentaremos ante un DFD grande y complejo. Deberemos
evitar diagramas complejos y poco legibles, de acuerdo, pero cmo? Si el sistema es intrnsecamente complejo y tiene
decenas de funciones que se constituyen de decenas de funciones menores.
La respuesta es organizar el DFD global en una serie de niveles de modo que cada uno proporcione
sucesivamente ms detalles sobre una porcin del nivel anterior. Esto es
De modo que se construir una jerarqua de diagramas, en donde cada nivel inferior es una expansin de un
proceso del nivel superior.
5.3.6.
Construccin de los niveles del DFD
Como podemos ver lo que se pretende es descomponer un todo en piezas con el objetivo de reducir la
complejidad. Pero debemos responder una serie de preguntas:
1.
Cmo saber cuntos niveles debe haber en un DFD?
No hay ninguna regla para decidir cuantos niveles ha de tener un DFD. Pero dado que un DFD es
aconsejable que no tenga ms de media docena de burbujas y almacenes relacionados, si nos aparece un nivel
que contenga un nmero muy superior deberemos insertar un nuevo nivel a los que hubiere. Hay que procurar
que haya equilibrio en la distribucin de todos los elementos grficos entre todos los niveles del DFD.
2.
Deberemos de dividir todas las partes del sistema con el mismo nivel de detalle?
La respuesta ser que no. Algunas partes del sistema pueden ser ms complejas que otras y pueden
requerir uno o ms niveles de particin. En el caso que nos encontremos con desigualdades respecto a la
divisin de un proceso respecto a otros, deberemos nivelar el DFD para lograr un equilibrio.
88
3.
Cmo nos aseguraremos que los niveles del DFD son consistentes entre s?
Esta cuestin es importante, ya que normalmente existe un desarrollo entre distintas personas en un
proyecto real, as como una divisin del trabajo. Para asegurarse que cada figura es consistente con su figura de
ms alto nivel se sigue una regla sencilla: los flujos entrantes y salientes de una burbuja en un nivel dado
deben corresponder con los que entran y salen de toda la figura en su desagregacin, a esto se le llama
balanceo de malla.
4.
Dnde deben aparecer los almacenes?
La regla es la siguiente: mostrar un almacn en el nivel ms alto donde primeramente sirve de interfaz
entre dos o ms burbujas; luego mostrarlo de nuevo en cada diagrama de nivel inferior que describa ms a
fondo dichas burbujas de interface. Por lo tanto los almacenes locales, que utilizan slo las burbujas en una
figura de menor nivel, no se mostrarn en niveles superiores, dado que se incluyen de manera implcita en un
proceso del nivel inmediato superior.
5.
Cmo se realiza de hecho la particin de los DFD en niveles?
La situacin que nos imaginamos como ideal es la de comenzar con el diagrama de contexto y luego
desarrollar cada figura para trabajar de forma progresiva hasta los niveles de bajo nivel. Sin embargo ste
planteamiento nos dar problemas, de modo que el enfoque ms aconsejable es identificar los acontecimientos
externos a los cuales debe responder el sistema y crear un primer DFD borrador. Veremos como esta primera
aproximacin del DFD puede suponer un punto de partida hacia arriba o hacia abajo.
6.
Cul ser el ltimo nivel de desagregacin?
Para decidir cul es el ltimo nivel no debemos seguir profundizando mientras halla procesos que
puedan ser descompuestos en subprocesos, ni entrar en descripciones de tal detalle sobre los procesos que
estemos desarrollando su algoritmo. Es decir, los ltimos niveles del DFD no deben convertirse en un
organigrama del algoritmo de cada proceso.
5.3.7.
Explosin de un proceso
A medida que vayamos conociendo ms las actividades de un proceso, podemos representarlas con otro DFD.
Para ello seguiremos las siguientes normas:
Se debe explosionar un solo proceso cada vez.
Se representa una caja de proceso grande para ver con ms detalle su funcionamiento.
Todos los procesos a que da lugar la explosin del proceso n, se van numerando como n.1, n.2, n.3,
n.4, etc.
Todos los flujos de datos que llegaban al proceso n tienen que llegar al conjunto n.1, n.2, n.3, etc.
Todos los flujos de datos que salan del proceso n tienen que salir del conjunto n.1, n.2, n.3, etc.
89
Al estudiar en ms detalle el funcionamiento del proceso n, y tener en cuenta el tratamiento de errores

y excepciones es posible que surjan nuevos flujos de datos del conjunto de procesos explosionados con
el exterior.
Si estos flujos son fruto del tratamiento de errores y excepciones se marcan con una X para resaltar el
hecho de que no tienen que aparecer en el DFD original (donde se defini el proceso n).
Si hay otros flujos adicionales con el exterior se tendran que reflejar en el DFD original.
Todas las entidades externas han de estar fuera del marco de la explosin.
Fig. 5.9.: Explosin de un Proceso
5.3.8.
Tipos de diagramas de flujo de datos

Los diagramas de flujo de datos son de dos tipos:
1.
Diagramas fsicos de flujo de datos.
Proporcionan un panorama del sistema en uso, muestra las tareas que se llevan a cabo y como se
hacen. Las caractersticas fsicas incluyen:
Nombre de personas
Nombre o formatos de documentos
Nombres de departamentos
Archivo de maestro y de transacciones
90
Equipo y dispositivos utilizados
Ubicaciones
El empleo de estos diagramas es aconsejable por tres razones:
2.
Para los analistas de sistema es ms fcil describir la interaccin entre los componentes
fsicos que comprender las polticas empleadas. De modo que identifican las personas, lo que
hacen, los documentos que inician las actividades y el equipo para su procesamiento.
Los diagramas fsicos de flujos de datos son de utilidad para comunicarse con los usuarios.
Estos relacionan con facilidad alas personas, las ubicaciones y los documentos ya que
trabajan todos los das con estas entidades (Los diagramas lgicos van a resultar abstractos
para los usuarios).
Los diagramas fsicos proporcionan un camino para validar o verificar el punto de vista del
usuario sobre la forma en que opera el sistema en uso.
Diagramas lgicos de flujo de datos.
Proporcionan un panorama del sistema independiente de la implantacin, que se centra en el flujo de

datos entre los procesos sin considerar los dispositivos especficos y la localizacin de almacenes de datos o
personas en el sistema. Los diagramas fsicos de flujos de datos, no son un fin en si mismos, sino son un medio
para describir la implantacin del sistema existente. El diagrama lgico es una visin retrospectiva de la
implantacin actual y proporciona la base para examinar la combinacin de procesos, flujo de datos, almacenes
de datos, entradas y salidas, sin importarnos los dispositivos fsicos, personas o aspectos de control que
caracterizan la implantacin.
As que el diagrama lgico se obtiene del diagrama fsico al llevar a cabo lo siguiente:
Sealar los datos necesarios en este momento para un proceso, no documentos que los
contienen.
Indicar los flujos entre los procedimientos y no entre personas, oficinas o localidades.
Eliminar herramientas y dispositivos.
Eliminar informacin de control.
Consolidar los almacenes de datos redundantes.
Eliminar los procesos innecesarios (los que no cambian los datos, independientes de los
dispositivos donde ocurren, los que representan un proceso nico dentro del sistema).
Cuando se inicia el estudio de sistemas en un rea de la Organizacin, el analista necesita obtener una visin del
sistema. Primero los elementos fsicos: personas, documentos, listados. No es difcil recordar lugares o personas
importantes (Este trabajo lo realiza Prez, La autorizacin del pago de facturas se realiza en el departamento de
contabilidad, etc.), los diagramas fsicos representan estos elementos.
Una vez superada esta primera fase de conocimiento del sistema actual, es necesario descifrar los aspectos ms
importantes de cada actividad. Los diagramas lgicos nos permiten describir los datos, procesos y eventos de forma
abstracta, ya que el analista debe conocer el trabajo que debe realizarse ms que las personas que en la actualidad lo
realizan. Los analistas generalmente comienzan por la construccin de un modelo fsico por que los componentes fsicos
se pueden identificar realmente durante el anlisis y despus lo convierten a un modelo lgico
91
Durante la conversin, primero se pasan todos los procesos que hacen referencia a actividades fsicas.
El resto de los procesos fsicos se expanden despus dentro de sus funciones lgicas. Para ello se toma cada
proceso fsico, se busca qu es lo que hace y se reemplaza por un DFD de funciones lgicas expandido que represente
las actividades de un objeto fsico.
Despus se examina este ltimo DFD, y cualquier funcin comn o similar se combina para formar un proceso
de nivel ms alto que se convierte el DFD superior.
5.3.8.1. Deduccin del diagrama lgico

Los diagramas fsicos de flujo de datos son un medio para alcanzar un fin, no un fin en s mismos. Se elaboran
para describir la implantacin del sistema existente, con el objetivo de tener la comprensin correcta de la implantacin
real del sistema existente.
El panorama lgico es una visin retrospectiva de la implantacin actual y proporciona la base para examinar la
combinacin de procesos, flujo de datos, almacenes de datos, entradas y salidas sin tomar en cuenta dispositivos fsicos,
personas o aspectos de control que caracterizan la implantacin.
5.3.8.2. Reglas generales para el dibujo de diagramas lgicos de flujo de datos

Las reglas a tener en cuenta, para el dibujo de los diagramas lgicos de flujo de datos:
1.
Cualquier flujo de datos que abandone un proceso debe estar basado en los datos que entran al
proceso.
2.
Todos los flujos de datos reciben un nombre, el nombre refleja los datos que fluyen entre procesos,
almacenes de datos, fuentes o destinos.
3.
Slo deben entrar al proceso los datos necesarios para llevarlo a cabo.
4.
Un proceso no debe saber nada de ningn otro en el sistema, es decir debe ser independiente, la nica
dependencia que debe existir es aquella que est basada en sus propios datos de entrada y salida.
5.
Los procesos siempre estn en continua ejecucin, no se inician, ni tampoco se detienen.
6.
La salida de los procesos puede tomar una de las siguientes formas:
Flujo de datos con informacin aadida por el proceso (por ej. anotacin en la factura).
Una respuesta o cambio en la forma de los datos (por ej. cambio en la forma de expresar los
datos).
Un cambio de condicin (por ej. de no autorizado a autorizado).
Un cambio de contenido (por ej. integracin o separacin de la informacin contenida en uno

o mas flujos entrantes de datos).
Cambios en la organizacin (por ej. separacin fsica o reacomodo de datos).
92
5.3.8.3. Expansin de los procesos para mayor detalle

Dado que la informacin contenida en el diagrama de contexto, es inadecuada para explicar en su totalidad los
requerimientos del sistema, es deseable describir el panorama lgico del procesamiento de facturas por pagar con mayor
detalle.
Para identificar los procesos utilizamos los nmeros 1.0, 2.0 y 3.0. Podemos hacer referencia por su nmero
(1.0) o por su nombre (Autorizacin de facturas).
Los diagramas de flujo de datos no tienen utilidad si se dibujan en forma inapropiada o ser manejados sin
cuidado. Aunque no hay leyes que establezcan el nmero de niveles, el nmero de procesos por niveles, la norma comn
es definir cada nivel inferior en trminos de tres a siete de procesos por cada proceso de nivel superior. La utilizacin de
ms de siete procesos hace que el diagrama sea difcil de manejar y dibujar.
Lo importante es entender que los diagramas de flujo de datos lgicos son una herramienta de ayuda para
ayudar la comprensin del sistema de la Organizacin. De modo que un diagrama deja de ser til cuando no es
comprensible. Por lo tanto, debe primar el sentido comn, y no determinar normas estrictas para su construccin.
5.3.8.4. Mantenimiento de la consistencia entre procesos

Si comprobamos el diagrama de contexto, y el diagrama de primer nivel, el primer proceso tiene los mismos
flujos de entrada, as como los flujos de salida, esto se debe a que la explosin es consistente; los flujos de entradas o
salidas del proceso de nivel superior estn presentes en el diagrama de nivel inferior, y apareciendo nuevos flujos,
almacenes. Esto es precisamente uno de los puntos importantes de la expansin hacia niveles inferiores: encontrar ms
detalles relacionados con los procesos internos.
5.3.8.5. Convenciones de nivelacin significativas

Nivelacin es un trmino que se refiere al manejo de archivos locales (los empleados dentro de un proceso).
Los detalles relacionados con un solo proceso en un determinado nivel deben permanecer dentro del proceso. Los
almacenes y flujos de datos que son relevantes nicamente para el interior del proceso, son ocultados hasta que el
proceso se extiende con mayor detalle.
Si nos fijamos en el diagrama de contexto, aparece un almacenamiento de datos (datos del vendedor). Este
almacn se crea fuera del sistema de facturas por pagar. Por otro lado los almacenes de datos de facturas por pagar,
rdenes de compra y cuentas por pagar estn contenidos dentro del proceso, y aparecen en el prximo nivel cuando se
expansione el proceso. La convencin de nivelacin seala que estos almacenes son internos al proceso, no entradas
para l.
5.3.8.6. Aadir los controles slo en los diagramas de bajo nivel

Hasta el momento los diagramas de flujos de datos desarrollados no incluyen informacin sobre controles. No
se hace referencia sobre como manejar errores o excepciones, por ejemplo como procesar facturas incorrectas. Aunque
esta informacin no es importante para identificar todos los flujos de datos, deben aparecer en segundo o tercer nivel
deben aparecer el manejo de errores y excepciones del proceso.
Los errores ms comunes cometidos al incluir los controles fsicos en los diagramas lgicos de flujo de datos.
Por ejemplo: El copiado de nmeros para documentos (copia 1, copia 2, copia para contabilidad), de instrucciones
(encontrar el registro, revisar el registro), o das para el inicio de actividades (hacerlo el lunes) no tienen nada que ver
con los aspectos lgicos y de datos de determinacin de requerimientos.
93
5.3.8.7. Asignar etiquetas significativas

Todos los flujos de datos deben tener un nombre que refleje con exactitud su contenido. Los nombres dados a
los flujos de datos deben reflejar los datos de inters para los analistas, no los documentos o el lugar donde residen. Por
ejemplo, una factura contiene varios elementos diferentes de informacin. Los analistas estn interesados en aquellos
que son importantes para un proceso en particular. Estos pueden ser el nmero de la factura y la fecha de expedicin, o
la firma de autorizacin de la factura. Lo importante no es la hoja de papel. Los datos que fluyen hacia los procesos
experimentan cambios. Por consiguiente, el flujo de datos de salida tiene un nombre diferente al de entrada.
5.3.8.8. Asignar nombre a los procesos

Se deben asignar nombre a todos los procesos que les digan a los usuarios algo especfico con respecto a la
naturaleza de las actividades del proceso. Los nombres Control de Inventarios, Compras y Ventas, es mejor utilizar
Ajustar cantidad, preparar orden de compra o corregir pedido de ventas.
Consideraciones para dar nombre de los procesos:
1.
Seleccionar nombres que indiquen la accin que se lleva a cabo. Lo mas apropiado es escoger un
verbo y un objeto que reciba la accin del verbo.
2.
Asegurar que el nombre describa completamente el proceso. (Si un proceso edita y valida los datos de
una factura, no se puede dar el nombre de Edicin de facturas).
3.
Seleccionar nombres para los procesos que expliquen el enlace entre los flujos de entrada y salida.
4.
Evitar nombres vagos como proceso, revisin, reunir u organizar.
5.
Utilizar los nombres de los procesos de bajo nivel ya que estos son ms especficos y descriptivos que
los asociados con los procesos de alto nivel.
6.
Asignar nombres a los procesos que sean nicos para la actividad que ellos describen.
Tambin hemos hablado de numerar los procesos con los nmeros 1, 2, 3, 4 y 5. Los procesos generados con la
expansin de cada uno de ellos sen los niveles inferiores se les asigna un decimal para indicar que son descripciones
detalladas de un proceso de nivel superior.
5.3.8.9. Evaluacin y verificacin del diagrama de flujo de datos

Es fundamental verificar con cuidado todos los diagramas de flujo para determinar si son correctos. La
presencia de lo que parece ser un error seale una deficiencia en el sistema. Debemos hacernos una serie de preguntas,
que nos sirvan de ayuda para evaluar los diagramas de flujo de datos:
1.
Existen en el diagrama de flujo de datos componentes que no tienen nombre (flujo de datos, procesos,
almacenamientos, entradas o salidas)?
2.
Existen almacenes de datos que son entradas y a los que nunca se hace referencia?
3.
Existen procesos que no reciben entradas?
4.
Existen procesos que no generan salida?
5.
Existen procesos que tienen varias finalidades?
6.
Existen almacenes de datos a los que no se referencien?

94
5.4.
7.
Existen demasiados atributos en el almacn de datos (ms que los detalles necesarios)?
8.
El flujo de datos que llega a un proceso es demasiado extenso para la salida
Dfds para sistemas en Tiempo Real.
Los flujos vistos hasta ahora, son simplemente los conductos a lo largo de los cuales viajan los paquetes de
datos entre procesos y almacenes. Podemos considerar las burbujas de los DFD como procesadores de datos. Hay una
clase de sistemas, los de tiempo real, en los que necesitamos modelar flujos de control (es decir seales o
interrupciones). Y se requiere una manera de mostrar procesos de control (esto es, burbujas cuya nica labor es
coordinar y sincronizar las actividades de otras burbujas del DFD). Un flujo de control puede imaginarse como un
conducto que porta una seal binaria (esto es, est encendido o est apagado). A diferencia de otros flujos que se
discuten en este captulo, el flujo de control no porta datos con valores. El flujo de control se manda de un proceso a otro
(o de algn terminador externo a un proceso) como una forma de decir que se inicie el proceso. Un proceso de control
puede considerarse como una burbuja ejecutiva, cuya funcin es coordinar las actividades de otras burbujas en el
diagrama; sus entradas y salidas consisten slo en flujos de control. Los flujos de control salientes del proceso de control
se utilizan para despertar a otras burbujas; los flujos de control entrantes generalmente indican que una de las burbujas
ha terminado su labor o que se ha presentado alguna situacin extraordinaria, de la cual necesita informarse a la burbuja
de control. Por lo comn slo hay un proceso de control de estos en un DFD dado.
95
5.5.
Diccionario de Datos
El diccionario de datos es una lista organizada de todos los datos pertenecientes al sistema, con una serie de
definiciones precisas y rigurosas para que tanto el analista como el usuario comprendan entradas, salidas, elementos de
los almacenamientos y clculos intermedios.
En el diccionario de datos incluimos almacenes de datos, flujos de datos, estructuras de datos, elementos de
datos y en algunos casos el modelo E-R.
El diccionario de datos (DD) define los datos en cuanto que:
1.
Describe el significado de los flujos de datos y los almacenes que muestran los DFDs.
2.
Describe la composicin de la estructura de datos que se mueven a los largo de los flujos.
3.
Describe la composicin de la estructura de datos en los almacenes.
4.
Describe los detalles de las relaciones entre almacenes que aparecen en un diagrama entidad-relacin.
Los analistas utilizan los diccionarios de datos por cuatro razones:
5.5.1.
1.
Para manejar los detalles en sistemas grandes ya que es imposible de recordar todo lo referente a un
sistema.
1.
Para comunicar un significado comn para todos los elementos del sistema. Esto es muy importante
cuando trabajan varios analistas y no pueden reunirse todos los das para comunicarse.
2.
Para documentar las caractersticas del sistema.
3.
Localizar errores en el sistema.
Contenido de un Diccionario de Datos

El DD contiene los siguientes elementos:
1.
5.5.2.
Definiciones lgicas de datos:
Elemento de Dato (Atributos de la Entidad).
Estructura de Dato.
Flujos de Datos.
Almacenes de datos.
2.
Definiciones lgicas de procesos.
3.
Definiciones lgicas de entidades externas.
Sintaxis del Diccionario de Datos
Se debe establecer una sintaxis estandarizada que nos permitir expresar dichos significados, para el caso de los
diccionarios, se utiliza:
96
5.5.3.
Est compuesto por
()
Opcional, puede o no puede estar presente
[]
Seleccin entre varias alternativas
{}
Iteracin, repetir lo mismo varias veces
**
Comentario
Clave principal de un almacenamiento
Separador de alternativas en seleccin Ejemplo:
Notacin del Diccionario de datos
1.
Descripcin de los flujos de datos: Representamos los flujos de datos siempre y cuando el flujo no sea un
nico atributo (dato elemental). Est formado por una o mas estructuras previamente definidas. Del flujo
nos interesa: Nombre, Alias, Contenido, Fuente, Destino y Definicin
2.
Descripcin de Datos elementales: Datos elementales, son datos, que dentro del contexto del usuario, no
tiene sentido descomponerlo. Es importante especificar: Valores permitidos, y unidad de medida. Cada uno
est identificado con: Nombre, Alias, Tipo, Largo, Valor por defecto y Validacin
3.
Descripcin de los almacenamientos de datos: Representamos los almacenamientos de datos. De ellos se

documenta: Nombre, Clave Primaria, Contenido, Procesos que lo ocupan, y Definicin
4.
Descripcin de los procesos: Representamos los procesos del sistema. Se documenta: Nombre,
Descripcin, Flujos de Entrada, Flujos de Salida, Almacenes y Descripcin (narrativa o seudo-cdigo)
5.
Descripcin de las entidades externas: Representamos las entidades externas del sistema. Se documenta:
Nombre, Definicin, A quien representa y Flujos de datos relacionados (E/S).
97
5.6.
Diagrama Entidad-Relacin
El modelo E-R (entidad-relacin) fue propuesto por Edward Chen en 1976 para la definicin del esquema
conceptual de una BD. Posteriormente se ha ido enriqueciendo con nuevos mecanismos de abstraccin y representacin
de la realidad. Es el ms ampliamente utilizado de los llamados semnticos.
Se basa en la utilizacin de conceptos tales como entidad (objeto), atributo y relacin entre objetos. Se dispone
de un formalismo grfico para realizar estas representaciones, pero no de un lenguaje de manipulacin de datos.
La principal ventaja, que seguramente ha forzado su difusin, es que es traducible casi automticamente a un
esquema de BD bajo Modelo Relacional, con cierta prdida de expresividad en el proceso, pero garantizando que las
tablas que resultan estn directamente en Tercera Forma Normal (3FN).
Pasaremos ahora a describir cual es el lenguaje de representacin de entidades, atributos, y relaciones entre
entidades. Hacer notar, sin embargo, que se muestra una mnima parte de este lenguaje, la necesaria para comprender el
significado de los diagramas E-R ms simples.
El Diagrama de entidad-relacin (DER), es una tcnica de modelado que nos muestra los datos relevantes del
sistema, as como las relaciones entre estos datos a un alto nivel de abstraccin.
5.6.1.
Para qu definir un modelo orientado a datos?

Es necesario definir un modelo orientado a datos por:
5.6.2.
El sistema puede ser tan complicado que sea conveniente estudiar sus estructuras de datos
independientemente del proceso que se llevar a cabo. .
El modelo de datos es esencial para comunicarse con el administrador de datos, que es el responsable
de gestionar, controlar los datos esenciales para administrar el negocio, asegurar el correcto y eficiente
funcionamiento de las Bases de Datos del sistema.
El modelo de datos define las relaciones entre los almacenamientos de los DFDs.
Componentes
Los tres componentes principales de un DER son:
entidades
atributos
relaciones entre entidades
5.6.2.1. Representacin de Entidades.

Una entidad se representar mediante un rectngulo nominado. Representa un conjunto de objetos (materiales o
inmateriales) del mundo real: empleados, artculos, clientes, planificaciones, estndares cumpliendo las siguientes
caractersticas:
Cada uno de sus miembros individuales (instancias), pueden ser identificados unvocamente. Existe
alguna manera de diferenciar dos instancias individuales de la entidad.
98
Cada entidad juega una funcin dentro del sistema. El sistema no funciona sin acceder a sus miembros
instancias.
Cada entidad puede ser descrito por uno o ms datos elementales (atributos). Los atributos se aplican a
cada instancia de la entidad.
Para poner nombre a la entidad, normalmente se utiliza la forma singular. Hay que tener en cuenta la relacin
entre los almacenes del DFD y las entidades del DER. Si existe una entidad artculo en un DER, debe haber un almacn
de datos artculos en el DFD asociado.
5.6.2.2. Representacin de Atributos.

Un atributo se ver en un E-R como una elipse unida a una entidad mediante un arco.
En funcin de los distintos tipos de atributos que nos podemos encontrar, variar el tipo de representacin:
atributo identificador: son aquellos que identifican las ocurrencias de la entidad. Se representan
mediante el subrayado del nombre del atributo.
atributo descriptor: atributo no identificador. Si atendemos a su posible estructura:
atributo simple o escalar.
atributo compuesto o estructurado: el nombre del atributo compuesto es la etiqueta de un arco que se
subdividir en tantos atributos simples como forme la estructura.
atributo multivaluado: se indica mediante la etiqueta n sobre el arco.
5.6.2.3. Representacin de Relaciones.

Las relaciones entre entidades se representan mediante un polgono de tantos lados como entidades se asocian,
salvo en el caso de las binarias (relaciones que asocian dos entidades o una consigo misma) que utilizan un rombo, unido
a las entidades mediante arcos. Este polgono ir etiquetado con el nombre de la relacin. Asimismo, se pueden etiquetar
los arcos para realzar el papel que juega dicho objeto dentro de la relacin.
Las entidades estn ligadas unas a otras por relaciones. Cada instancia de la relacin representa una asociacin
entre 0 ms ocurrencias de una entidad y 0 ms ocurrencias de otra entidad
Las relaciones que pueden ser calculadas o derivadas a partir de otros datos, no se representan.
Nos podemos encontrar mltiples relaciones entres dos o ms entidades, y debemos interpretarlo como una
unidad. La relacin se debe estudiar desde la perspectiva de cada uno de las entidades participantes. Es el conjunto de
todas aquellas perspectivas que describen completamente la relacin.
99
5.6.3.
Reglas para la construccin de DERS
1.
Construccin del modelo inicial.

El DER inicial se construye basndose en el propio conocimiento del sistema, y con las entrevistas
iniciales con el usuario.
No se debe esperar que este modelo inicial sea el definitivo.
2.
Refinamiento del modelo inicial.

El primer refinamiento que se debe hacer es definir los datos elementales ligados a cada entidad.
Si se ha hecho el DFD, seguramente estar definido, en el DD, el almacn de datos asociado. Al hacer
este refinamiento nos podemos encontrar ante la necesidad de aadir nuevas entidades o eliminarlos.
3.
Aadir entidades al modelo inicial
Datos elementales que no pueden aplicarse a todas las instancias de un entidad:

Ejemplo: Entidad Empleado. Atributos: nombre, edad, nmero de embarazos
Solucin: Crear un conjunto de entidades-subtipo, Empleado-Masculino, EmpleadoFemenino.
Datos elementales aplicables a todas las instancias de dos entidades diferentes:

Ejemplo: Entidad Cliente-Caja, Cliente-Crdito. Atributos comunes: nombre, direccin.
Solucin: Crear una entidad-supertipo Cliente.
Datos elementales que describen relaciones entre entidades-tipo.

Ejemplo: Relacin Compra y los datos fecha de compra, y descuento.
Solucin: Crear un entidad asociativo Compra.
Eliminar grupos de datos repetitivos dentro de una entidad.

Ejemplo: Entidad Empleado, y cada uno puede tener hijos.
Solucin: Crear un entidad hijo y la relacin es Padre de.
Eliminar entidad del modelo inicial.
Entidades de las cuales solo hay una instancia, y solo tienen identificador.
Ejemplo: Entidad Cnyuge, del cual solo nos interesa el nombre.
Solucin: Eliminar la entidad Cnyuge y la relacin Esta Casado con y guardamos el nombre
cnyuge con el atributo de empleado.
100
Relaciones calculadas o derivadas.

Ejemplo: Relacin Renueva, que se puede calcular a partir de diversos datos de Conductor
(fecha nacimiento, apellidos....).
Solucin: Eliminar la relacin RENUEVA.
5.6.4.
Preguntas a resolver
Una vez vistas las herramientas y tcnicas nos planteamos Que se construye primero, el DFD o el DER?
Normalmente, se desarrollan los dos a la vez.
Es necesario construir los modelos, DFD y DER? Depende del sistema.
La mayora de sistemas de gestin actuales son lo suficientemente complejos en cuanto a funciones y datos que
hacen aconsejable, la realizacin de los dos modelos.
101
5.7.
Miniespecificaciones o Especificacin de Procesos.
Hemos visto que para describir la lgica de un proceso, se pueden utilizar varias alternativas como son:
narrativa, rboles de decisin, tablas de decisin y espaol estructurado (o seudo-cdigo).
Cuando utilizamos narrativa podemos encontrarnos con
frases oscuras (no solo, pero no obstante, sin embargo....)
rangos con huecos indefinidos (hasta 20 unidades sin descuento, mas de 20 u. al 50 %)
Frases con y/o (los clientes que nos compran mas de 1milln al ao y tienen una buena historia de
pagos o que han tenido tratos con nosotros por mas de 20 aos debern recibir trato preferencial).
Adjetivos indefinidos (buena historia de pagos, trato preferencial). Estas razones obligan a pensar
en otras alternativas:
Los rboles de decisin, pueden resultar una tcnica no vlida en situaciones complejas con gran nmero de
condiciones e implicaciones ya que no asegura que se hayan considerado todas.
Se debe utilizar cuando el nmero de acciones sea pequeo y no sean posibles todas las combinaciones.
Las Tablas de decisin, son mas precisas dado que permiten reflejar todas las combinaciones posibles. Pero son
ms difciles de entender para el usuario. Deben simplificarse una vez construidas, y se convertirn en rboles de decisin.
Se debe utilizar, siempre que se dude que el rbol muestre toda la lgica.
Por lo Tanto se opta, en esta fase, por la utilizacin del espaol estructurado, el cual provee una similitud tal
con el lenguaje de programacin, que la conversin es mucho ms rpida. Adems, la lectura por parte del usuario, se
hace ms fcil y, por ende, ms entendible.
102
6.
Diseo.
El diseo podra definirse como "el proceso de aplicar distintas tcnicas y principios con el propsito de definir
un dispositivo, un proceso o un sistema con suficiente detalle como para permitir su realizacin fsica".
El objetivo del diseo es producir un modelo o representacin que se va a construir posteriormente. El proceso
de diseo combina la institucin y los criterios basados en la experiencia en la construccin de las entidades similares;
un conjunto de principios y/o heursticas que guan la evolucin del modelo, un conjunto de criterios que permiten
juzgar la calidad y un proceso de iteracin (repeticin) que lleva como fin ultimo a una representacin definitiva del
diseo.
Diseo de un sistema computacional es una actividad de la transformacin de la declaracin de lo que se
necesita a un plan de implementacin de ese requerimiento en un dispositivo electrnico. (Random House College
Dictionary)
6.1.
Diseo e Ingeniera de software
Diseo de software.
Cambia continuamente medida que evolucionan nuevos mtodos, mejores anlisis esta en una fase
relativamente temprana en el desarrollo carece de profundidad, flexibilidad y naturaleza cuantitativa de otras disciplinas
de la ingeniera, sin embargo existen mtodos, criterios y notacin para hacer un diseo exitoso
Ingeniera de Software
El trmino Ingeniera de Software surge a final de los aos 60 dentro de una conferencia dedicada a la crisis
del software. El objetivo de la Ingeniera de Software es producir productos de software. Productos software: sistemas
software junto la documentacin que describe como instalar y usar el sistema.
Los productos software caen en dos categoras:
Productos genricos: Desarrollados por una organizacin para un mercado abierto.
Productos a medida: Encargados por un cliente.
Ingeniera del Software: Conjunto de mtodos, herramientas y procedimientos para producir software de gran
calidad [R. Pressman]
Los mtodos describen cmo construir tcnicamente el software. Las herramientas dan soporte automtico o
semiautomtico a los mtodos. Los procedimientos relacionan formalmente los mtodos y las herramientas. La calidad
del software es una nocin que puede ser descrita mediante una serie de factores. Los factores pueden ser:
Externos.
Observables por los usuarios del producto.
Correctitud: Capacidad de los productos software de ejecutar exactamente sus tareas tal cmo estn
definidas en su especificacin de requerimientos.
Robustez: Capacidad de un sistema software para funcionar en situaciones anormales.
103
Modificabilidad: Facilidad de un producto para adaptarse al cambio de especificaciones.
Reusabilidad: Facilidad para ser reutilizado en todo o en parte para nuevas aplicaciones.
Compatibilidad: Facilidad de los productos software para combinarse unos con otros.
Eficiencia: Buen uso de los recursos Software y Hardware disponibles.
Portabilidad: Facilidad para adaptarse a otros entornos software o hardware.
Verificabilidad: Facilidad para preparar procedimientos de aceptacin, en particular datos de prueba,

para detectar fallos durante las fases de validacin y operacin.
Integridad: Capacidad de un sistema para proteger sus documentos (programas, datos) contra accesos
y modificaciones no autorizados.
Facilidad de uso: Capacidad de aprender a manejar un sistema software, operar con el, preparar datos
de entrada, interpretar resultados, etc.
Internos.
Observables por profesionales de la computacin.
6.2.
Modularidad: Independencia funcional de los componentes del programa.
Legibilidad: Facilidad de lectura e interpretacin del cdigo del programa
Diseo
Es el ncleo tcnico del proceso de ingeniera de software y se aplica independientemente del paradigma del
desarrollo usado.
Fig. 6.1.: Relacin entre el modelo de anlisis y el modelo de diseo.
104
1.
Diseo de datos.
Transforma el modelo de dominio de la informacin creado durante el anlisis en las estructuras de

datos necesarias para implementar el software.
2.
Diseo de la Interfaz.
Describe como se comunica el software consigo mismo, con los sistemas que operan con l y con los
operadores que los emplean.
3.
Diseo Procedimental.
Transforma elementos estructurales de la arquitectura del programa en una descripcin procedimental

de los componentes del software.
4.
Diseo Arquitectnico.
Define la relacin entre los principales elementos estructurales del programa.
La importancia del diseo del software reside en la calidad. El diseo es la nica manera de traducir los
requisitos del cliente un sistema o producto de software.
6.2.1.
Proceso del diseo
Diseo es un proceso iterativo que, parte desde las especificaciones bsicas y son refinadas hasta que estos
describan el sistema completo con todo detalle.
Caractersticas:
El diseo debe implementar todos los requisitos contenidos en el modelo de anlisis y debe acomodar
todos los requerimientos implcitos que desea el cliente
El diseo debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban
y mantienen el software.
El diseo debera proporcionar una completa idea de lo que es el software, enfocando los dominios de
datos, funcional y de comportamiento desde la perspectiva de la implementacin.
El diseo debera:
Ser una organizacin jerrquica que, haga un uso inteligente del control entre los componentes del
software
Ser modular, es decir, se debera hacer una particin lgica del software en elementos que realicen
funciones y subfunciones especficas.
Contener abstracciones de datos y procedimientos
Producir mdulos (subrutinas y procedimientos, por ej.) que presenten caractersticas funcionales
independientes
Conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el entorno
exterior
Ser producido usando un mtodo que pudiera repetirse segn la informacin obtenida durante el
105
anlisis de los requerimientos de software.

Los mtodos de diseo comparten los siguientes elementos:
Un mecanismo para la transformacin de un modelo de anlisis en una representacin del diseo
Una notacin para representar los componentes funcionales y sus interfaces
Heursticas para el refinamiento y la particin
Consejos para valorar la calidad
Principios del diseo
Diseo de software es un proceso y un modelo a la vez. El proceso de diseo es un conjunto de pasos

que permiten al diseador describir todos los aspectos del software a construir.
Principios para el diseo del "buen" software:
El proceso de diseo no debera ponerse "orejeras"
El diseo no debe inventar nada que ya est inventado
El diseo debera minimizar la distancia intelectual entre el sw y el problema tal y como existe en el
mundo real
El diseo debera estructurarse para admitir cambios
El diseo debera estructurarse para degradarse poco a poco, incluso cuando se enfrenta a datos,
sucesos o condiciones operativos aberrantes
El diseo no es escribir cdigo y escribir cdigo no es disear
Se debera valorar la calidad del diseo mientras se crea, no despus de terminarlo
Se debera revisar el diseo para minimizar los errores conceptuales (semnticos)
Cuando se aplican apropiadamente los principios sealados, el ingeniero de software crea un diseo que
muestre factores de calidad externos e internos. Los factores de calidad externos son aquellos que puede observar el
usuario (por ej. velocidad, fiabilidad, correctitud y utilidad), y los factores internos son aspectos tcnicos importantes
para el desarrollo.
Conceptos de diseo
Todos los conceptos de diseo ayudan al ingeniero a responder a las siguientes preguntas:
Qu criterios pueden emplearse para la particin del software en componentes individuales?
Cmo se extraen la funcin o la estructura de datos de una representacin conceptual del software?
Hay criterios uniformes que definen la calidad tcnica de un diseo de software?
El principio de la sabidura de un ingeniero de software es reconocer la diferencia entre conseguir que

funciona el programa, y hacerlo bien.
106
6.2.2.
Principios utilizados por el Diseo
6.2.2.1. Abstraccin
Cuando consideramos una solucin modular para cualquier problema, se pueden plantear muchos niveles de
abstraccin. Al nivel superior de abstraccin se establece una solucin en trminos amplios usando un lenguaje del
entorno del problema. A niveles ms bajos, se toma una orientacin ms procedimental. Se conjuga la terminologa
orientada al problema con la terminologa orientada a la implementacin en un esfuerzo para plantear la solucin.
Finalmente, en el nivel ms bajo de la abstraccin, la solucin se establece de la manera que pueda implementarse
directamente.
Cada fase de desarrollo de software es un refinamiento en el nivel de abstraccin de la solucin computacional.
A medida que nos movemos a travs de diferentes niveles de abstraccin, trabajamos para crear abstracciones
procedimentales, de los datos y de control. Una abstraccin procedimental es una secuencia dada de instrucciones que
tiene una funcin especfica y limitada. Una abstraccin de datos es una coleccin determinada de datos que describen
un objeto de datos. Una abstraccin de control implica un mecanismo de control del programa sin especificar detalles
internos.
6.2.2.2. Refinamiento
El refinamiento paso a paso es una estrategia de diseo descendente. La arquitectura de un programa se
desarrolla refinando sucesivamente niveles de detalle procedimental. Se desarrolla una jerarqua descomponiendo un
enunciado macroscpico de funcin (una abstraccin procedimental) al estilo paso a paso hasta que llegue a los
enunciados del lenguaje de programacin.
En cada paso del refinamiento, se descomponen una o varias instrucciones del programa en cuestin de
instrucciones ms detalladas. Esta descomposicin sucesiva o refinamiento de especificaciones termina cuando todas las
instrucciones se expresan en trminos de cualquier lenguaje de programacin... A medida que se refinan las tareas,
tambin hay que refinar los datos, descomponerlos, estructurarlos, y es natural refinar las especificaciones de los datos
junto con las especificaciones del programa.
La abstraccin y el refinamiento son conceptos complementarios. La abstraccin permite a un diseador
especificar procedimientos, datos, y aun as, suprimir detalles de bajo nivel a medida que progresa el diseo.
Qu es un mdulo?
Un mdulo se define como un conjunto de sentencias de programa con cuatro atributos bsicos:
1.
Entradas/Salidas: Datos que recibe cuando lo invocan y datos que devuelve al mdulo que lo llamo.
2.
Funcin: Qu hace con las entradas para producir las salidas.
3.
Mecnica: La lgica mediante la cual lleva a cabo su funcin.
4.
Datos internos: Zona de datos a los que nicamente puede referirse l.
Adems posee otros atributos adicionales cmo:

1.
Un nombre, por el cual puede ser referenciado como un todo.
2.
Puede invocar o ser invocado por otros mdulos.
La definicin de mdulo anterior es independiente del lenguaje en el cual se vaya a realizar posteriormente la
codificacin.
107
6.2.2.3. Modularidad
La arquitectura de software conlleva modularidad, es decir, el software se divide en componentes identificables
y tratables por separado, denominados mdulos, que estn integrados para satisfacer los requisitos del programa.
Modularidad es el atributo de software que permite que un programa ser manejable intelectualmente. Un
software monoltico (por ej. Un programa grande compuesto por un solo modulo) no puede ser entendido fcilmente por
un lector. El nmero de caminos de control, mbito de referencia, nmero de variables y la complejidad global hacen su
comprensin casi imposible.
Esto lleva a la conclusin: divide y vencers. Es ms fcil resolver un problema, cuando se rompe en piezas
manejables. Por otro lado, es posible concluir que si subdividimos el software indefinidamente, el esfuerzo sera
mnimo! Desgraciadamente, intervienen otras fuerzas, que hace esta conclusin falsa. A medida que crece el nmero de
mdulos, el esfuerzo asociado con la integracin de estos tambin crece.
Finalmente, es importante resaltar, que un sistema puede disearse modularmente, aunque su implementacin
deba ser monoltica. Hay situaciones en las cuales es inaceptable la introduccin de una relativamente pequea
sobrecarga de velocidad y memoria (carga de subrutinas y procedimientos). Aunque el programa fuente no parezca
modular, se mantiene su filosofa y el programa proporcionar beneficios de un sistema modular.
6.2.2.4. Ocultamiento de la informacin

Este principio sugiere que los mdulos se caractericen por decisiones del diseo que cada uno se oculte de los
dems. Se deberan especificar y disear los mdulos para que la informacin (procedimiento y los datos) contenida
dentro de un mdulo sea inaccesible a otros mdulos que no necesiten esta informacin.
La ocultacin implica que se puede conseguir una modularidad eficaz definiendo un conjunto de mdulos
independientes que se comunican entre s slo la informacin necesaria para conseguir la funcin de software. La
abstraccin ayuda a los a definir las entidades procedimentales (o de informacin) que componen el software. La
ocultacin refuerza las restricciones de acceso tanto al detalle procedimental dentro del mdulo como a cualquier
estructura local de datos empleada por el mdulo.
108
6.3.
Diseo de Datos (Diseo de la Base de Datos).
El propsito de esta actividad es conformar el diseo fsico de la base de datos documentado en un formato
apropiado a la naturaleza de este tipo de diseo. Para lograrlo se precisa tanto de la informacin lgica que proporciona
el diccionario de datos y el diagrama de entidad relacin, ambos componentes de la especificacin de requerimientos
como de la informacin que entrega el documento de restricciones fsicas que emana del personal de operaciones
normalmente responsable, en las unidades de informtica, del centro de procesamiento, de las redes, de la seguridad del
hardware y de los datos del computador, as como de la ejecucin de los programas, el manejo de los discos y otros
asuntos que bien pueden tener radical importancia para la tarea de disear la base de datos.
El diseo de Bases de Datos es el proceso por el que se determina la organizacin de una Base de Datos. El
diseo de una Base de Datos se realiza generalmente en tres fases:
La primera fase es el diseo conceptual.
La segunda fase se refiere al diseo lgico.
Y la ltima fase es la que estudiaremos en particular, es el Diseo Fsico.
6.3.1.
Diseo Fsico de la Base de Datos
El punto de partida del Diseo Fsico de la Base de Datos es el modelo de datos de lgica global y la
documentacin que describe el modelo de la metodologa del diseo de la Base de Datos lgica.
Los modelos lgicos y las relaciones derivadas fueros validadas usando la tcnica de normalizacin, y contra
las transacciones que ellos deben soportar para los usuarios. La fase del diseo de la Base de Datos lgica fue concluida
por la fusin de los modelos de datos locales (que representa el criterio de cada usuario de la empresa) junto a la
creacin de un modelo de datos global (que representa todos los criterios del usuario de la empresa).
En la tercera y final fase de la metodologa del diseo de la Base de Datos, el diseador debe decidir como
trasladar el diseo de la Base de Datos lgica (que es, las entidades, atributos, relaciones y fuerzas) a un diseo de la
Base de Datos fsica que puede ser implementada usando la tarjeta DBMS. Como muchas partes de Diseo Fsico de la
Base de Datos son altamente dependientes de la tarjeta DBMS, debe haber ms de una forma de implementar alguna
parte dada de la Base de Datos. Consecuentemente, el diseador debe ser completamente consciente de la funcionalidad
de la tarjeta DBMS, y debe comprender las ventajas y desventajas de cada alternativa para una implementacin
particular.
El diseador tambin debe ser capaz de seleccionar una estrategia conveniente de almacenamiento que tenga en
cuenta el uso.
En este tema demostramos como convertir las relaciones derivadas del modelo de datos lgico global en una
implementacin de la Base de Datos especfica. Proporcionamos los principios para cambiar estructuras de
almacenamiento por relaciones de base, decidiendo cuando crear ndices, y cuando desnormalizar el modelo de datos
lgico e introducir desempleo.
Ms adelante, mostramos los detalles de implementacin fsica para aclarar la discusin. Antes presentamos la
metodologa para diseos de la Base de Datos fsica, brevemente repasamos los procesos del diseo.
6.3.2.
Comparacin del Diseo Fsico de la Base de Datos y el Diseo Lgico.
En la presentacin de la metodologa del diseo de la Base de Datos, dividimos el proceso del diseo en tres
fases principales:
109
1) Diseo de la Base de Datos Conceptual.

2) Diseo de la Base de Datos Lgica.
3) Diseo de la Base de Datos Fsica.
La fase anterior al Diseo Fsico, fue el diseo de la Base de Datos Lgica, es en gran parte independiente de
los detalles de implementacin, tal como el funcionamiento especfico de la tarjeta DBMS, y la aplicacin de los
programas, pero es dependiente en el modelo de datos de la tarjeta. El rendimiento de este proceso es un modelo y
documentacin de datos lgico y global que describe este modelo, as como el diccionario de datos y el esquema
relacional. A la vez, estos representan las fuentes de informacin para el proceso del Diseo Fsico, y proporcionan al
diseador la Base de Datos fsica, con un vehculo para hacer los empleos desconectados que son tan importantes para
un diseo de la Base de Datos eficiente.
Mientras el diseo de Base de Datos lgico se interesa del qu, el diseo de la Base de Datos Fsica se
interesa por el cmo. Esto requiere diferentes destrezas que son a menudo fundadas en personas diferentes. En
particular, el diseo de la Base de Datos fsica debe conocer como funciona el sistema husped del ordenador del
DBMS, y debe darse completa cuenta del funcionamiento de la tarjeta DBMS. Mientras el funcionamiento
proporcionado por sistemas corrientes muy variados, el Diseo Fsico debe estar hecho a medida a un sistema especfico
DBMS.
Sin embargo, el Diseo Fsico de la Base de Datos no es una actividad aislada, hay a menudo Feed-Back entre
el Diseo Fsico, lgico y de aplicacin. Por ejemplo, las decisiones tomadas durante el Diseo Fsico para mejorar el
funcionamiento, podra afectar a la estructura del esquema lgico.
Diseo Fsico de la Base de Datos.

Es el proceso de produccin de una descripcin, de una implementacin, de un almacenamiento secundario de
la Base de Datos, describe el almacenamiento de estructuras y mtodos de acceso usados para conseguir el acceso
eficiente a los datos. El Diseo Fsico de la Base de Datos es la ltima etapa del proceso de diseo, en el cual, teniendo
presentes los requisitos de los procesos, caractersticas del SGBD o DBMS, del SO y el hardware, se pretenden los
siguientes objetivos:
Disminuir los tiempos de respuesta.
Minimizar espacio de almacenamiento.
Evitar las reorganizaciones.
Proporcionar la mxima seguridad.
Optimizar el consumo de recursos.
En definitiva lo que se pretende alcanzar es el cumplimiento de los objetivos de sistema y conseguir optimizar
el ratio coste/beneficio.
La poca flexibilidad de los sistemas comerciales obliga a llevar a cabo la reestructuracin de las relaciones para
conseguir tiempos de respuesta aceptables. Por tanto, se deber proceder de forma iterativa desde el diseo lgico al
Diseo Fsico, y viceversa para poder conseguir el ratio anteriormente citado.
As mismo, no existe un modelo formal para el Diseo Fsico (como por ejemplo, el modelo relacional para el
diseo lgico), el Diseo Fsico resulta muy dependiente del producto comercial concreto hasta el momento.
110
El Diseo Fsico consta de entradas y salidas. En las entradas se podra destacar adems de los objetivos del
Diseo Fsico; los recursos mquina (soporte fsico), recursos lgicos (sistemas operativos), esquema lgico y la
informacin sobre las aplicaciones (tiempos de respuesta y seguridad).
A partir de las entradas, en la salida obtendremos; normas de seguridad, estructura interna, y especificaciones
para el ajuste.
El problema del Diseo Fsico para el administrador de la Base de Datos consiste en proveer un conjunto
eficiente de estructuras de acceso de modo que el optimizador pueda tomar las mejores decisiones. Entre los
instrumentos ms importantes del Diseo Fsico se encuentra la seleccin de los ndices secundarios, que es uno de los
problemas en la instrumentacin fsica de una Base de Datos.
Una vez diseadas las aplicaciones se conocer cuales son las consultas ms frecuentes y prioritarias a la Base
de Datos, por lo que ser conveniente crear un ndice secundario que ayude a localizar las filas seleccionadas en dichas
consultas y reducir los accesos a disco.
Existen otros elementos importantes en el Diseo Fsico, aunque no todos los sistemas comerciales disponen de
ellos, y si existen el diseador tiene la posibilidad de actuar sobre ellos ajustndolos a cada caso concreto, algunos de
ellos se muestran a continuacin, aunque ms adelante los podremos ver con ms detalle:
Registros fsicos.
Punteros.
Direccionamiento calculado (Hashing)
Agrupamientos (cluster)
Bloqueo y comprensin de datos.
Asignacin de espacios de almacenamientos como memorias intermedias (buffers).
Asignacin de conjuntos de datos a particiones y a dispositivos fsicos.
En general los fabricantes muestran tres estrategias de Diseo Fsico:

1) El SGBD impone una estructura interna, dejndole al diseador muy poca flexibilidad, lo que suele
aumentar la independencia fsica/lgica, pero disminuye la eficacia.
2) El administrador disea la estructura interna, esto supone una importante carga para el administrador y
puede influir de forma negativa en la independencia, aunque puede mejorar la eficacia.
3) El SGBD proporciona una estructura interna opcional que el diseador puede cambiar a fin de
optimizar el rendimiento de la Base de Datos. Esta estrategia tiene unas ventajas:
La Base de Datos puede comenzar a funcionar de inmediato.
La eficacia va aumentando al irse efectuando los ajustes sucesivos.
La independencia se mantiene.
El Diseo Fsico de la Base de Datos implica el diseo de las relaciones de la Base y se integra fuertemente
usando el funcionamiento disponible de la tarjeta DBMS.
111
Traduccin del modelo de datos lgico global para tarjetas DBMS; implica seleccionar las estructuras de
almacenamiento y los mtodos de acceso para las relaciones base.
Tpicamente, el DBMS, implica un nmero de alternativas para construir un almacn de datos, con la excepcin
del PC DBMS, el cual tiende a ajustar el almacenamiento construido. Desde el punto de vista de los usuarios, la
representacin del almacenamiento interno para las relaciones debera ser transparente el usuario debera poder
acceder a las relaciones y tuplas sin tener que especificar donde o como las tablas estn almacenadas.
Esto requiere que el DBMS proporcione datos fsicos independientes para que los usuarios no se vean afectados
por cambios de la estructura fsica de la Base de Datos, como se discuti anteriormente.
El trazado entre el modelo de datos lgico y el modelo de datos fsico est definido en el esquema interno. El
diseador debe proporcionar los detalles del Diseo Fsico para ambos, el DBMS y el sistema operativo. Para el DBMS,
el diseador debe especificar las estructuras de fichero que son usados para representar cada relacin; Para el sistema
operativo, el diseador debe especificar los detalles tales como la localizacin y proteccin de cada fichero. El paso 2
tambin considera enervante (es decir, debilitar las fuerzas fsicas) la fuerza de normalizacin impuesta sobre el modelo
lgico de datos para proporcionar todo el funcionamiento del sistema.
Este es un paso que solo se acometer si fuera necesario, porque los problemas inherentes implican la
introduccin del desempleo, mientras mantengan su consistencia.
El diseo de las Bases Relacionales para la tarjeta DBMS; implica el diseo de medidas de seguridad para
proteger los datos desde un acceso inautorizado. Esto implica decidir como cada modelo lgico global de datos debera
estar implementado, y los controles de acceso que son requeridos en las relaciones de base.
La fuerza de la empresa para disear la tarjeta DBMS; es un proceso continuo de monitorizacin del sistema
operacional para identificar y resolver cualquier problema del funcionamiento resultante del diseo, e implementacin
de nuevos o cambiantes requerimientos.
6.3.3.
La Metodologa del Diseo Fsico de la Base de Datos para la Base de Datos Relacional.
Esta seccin nos proporciona una gua paso a paso para introducir el Diseo Fsico de la Base de Datos para la
Base de Datos relacional. Por tanto, en esta metodologa, demostramos la asociacin cerrada entre el Diseo Fsico de la
Base de Datos y la implementacin para describir como los diseos alternativos pueden implementarse usando varias
tarjetas DBMS.
La primera actividad del Diseo Fsico de la Base de Datos implica la traduccin de las relaciones derivadas del
modelo de datos lgico global dentro de una forma que puede implementarse en la tarjeta relacionada DBMS.
La primera parte de este proceso supone cotejar (es decir, confrontar una cosa con otra), la informacin
recogida durante el modelado y documentacin de los datos lgicos en el diccionario de datos.
La segunda parte de este proceso usa esta informacin para producir el diseo de la base relacional. Este
proceso requiere un conocimiento profundo de las funciones ofrecidas por la tarjeta DBMS. Por ejemplo, el diseador
necesitar conocer:
Si el sistema soporta la definicin de clave primaria, clave secundaria y clave externa.
Si el sistema soporta la definicin de datos requeridos (que es, si el sistema permite atributos definidos
como NO NULOS).
Si el sistema soporta la definicin de dominios.
Si el sistema soporta la definicin de la fuerza de la empresa.
Como crear una base relacional.
112
6.3.4.
Diseo de las Bases Relacionales para la Tarjeta DBMS.
Para comenzar el proceso del Diseo Fsico, primero necesitamos cotejar y asimilar la informacin sobre
relaciones producidas durante el modelado de datos lgicos. La informacin puede ser obtenida desde el diccionario de
datos y la definicin de las relaciones definidas usando el DataBase Design Language (DBDL). Por cada relacin
identificada en el modelo de datos lgico global, nosotros vamos a definir los siguientes pasos:
El nombre de la relacin.
Una lista de los atributos simples que soporta.
La clave primaria y, cuando sea apropiado, las claves alternativas (AK), y las claves externas (FK).
Integrar la fuerza de alguna clave externa identificada.
Desde el diccionario de datos, tambin tenemos para cada atributo:
Los dominios, la consistencia de un tipo de dato, longitud, y alguna fuerza en el dominio.
Una opcin para dejar de evaluar los atributos.
Si el atributo puede tener nulidad.
Si el atributo es derivado y, como sera computado.
113
6.4.
Diseo de Interfaz.
6.4.1.
Diseo Efectivo de Salidas. Objetivos en el diseo de salidas
La salida es la informacin que reciben los usuarios del sistema de informacin. Las salidas pueden tomar
distintas formas: los reportes impresos tradicionales y salidas en formatos, tales como pantallas en monitor, microfichas
y salidas de audio. Los usuarios confan en las salidas para la realizacin de sus tareas; y con frecuencia, juzgan el
mrito del sistema exclusivamente por sus salidas. Con el fin de crear una salida de utilidad, el analista de sistemas
trabaja estrechamente con el usuario, mediante un proceso interactivo, hasta que el resultado llega a ser satisfactorio. Los
objetivos que persigue el analista de sistemas al disear una salida son seis:
1.
Disear una salida para satisfacer el objetivo planteado
Toda salida debe contar con un propsito explcito. No es suficiente que se presente a los usuarios un reporte o
una pantalla, solo porque tecnolgicamente es posible hacerlo. Durante la fase del anlisis de determinacin de los
requerimientos de informacin, el analista de sistemas identifica los propsitos a satisfacer; y con base en tales
propsitos se disea la salida.
2.
Disear una salida que se adapte al usuario
Es difcil personalizar la salida con un gran sistema de informacin que atiende a numerosos usuarios con
diferentes propsitos. Con base en entrevistas, observaciones, consideraciones de costo y, tal vez, prototipos, ser
posible disear salidas que se ajusten a la mayora, si no a todas las necesidades de los usuarios y sus preferencias.
3.
Proveer la cantidad adecuada de informacin
Parte de la tarea del diseo de la salida es decidir que cantidad de informacin es correcta para los usuarios,
pronto se dar cuenta que es una tarea muy difcil, ya que los requerimientos de informacin cambian de manera
continua. Por ejemplo ms que acomodar en una sola pantalla las ventas de todo el ao, se podra proporcionar en doce
pantallas, la venta de cada uno de los meses, y de manera suplementaria, un resumen en una pantalla separada.
4.
Asegurar que la salida est disponible donde se necesita
Quin debe recibir la salida? El incremento de las salidas en lnea (on-line), desplegadas en pantalla y que son
accesibles de manera individual, han resuelto parte del problema de la distribucin, pero una distribucin apropiada
todava es un importante objetivo para el analista de sistemas. Para ser til y aprovechada, la salida debe presentarse al
usuario adecuado. No importa qu tan bien se diseen los reportes, si stos no los ven los tomadores de decisiones
pertinentes; carecern de valor.
5.
Proporcionar oportunamente la salida
En qu momento debe generarse la salida? Una queja comn de los usuarios es que no reciben de manera
oportuna la informacin para la toma de decisiones, uno de los objetivos que debe perseguir el analista es la puntualidad
en la distribucin de la salida. Muchos informes se requieren por da, por mes, por ao y habr otros por excepcin. Una
presentacin a tiempo puede llegar a ser decisiva para la operacin de la empresa.
6.
Elegir el mtodo correcto de salida
La salida puede tomar diferentes formas, incluyendo los reportes impresos en papel, la informacin presente en
pantalla, sonidos de audio y digitalizados que simulan la voz humana y las microfichas. La eleccin del mtodo correcto
para cada tipo de usuario es otro de los objetivos en el diseo de la salida. El analista debe evaluar las ventajas
involucradas al elegir un mtodo de salida. Los costos difieren, as como la flexibilidad, vida media, distribucin,
almacenamiento y posibilidades de acceso y transporte, y, finalmente, el impacto global hacia el usuario. La eleccin del
mtodo de salida no es trivial, ni es una conclusin predeterminada.
114
6.4.1.1. Relacin del contenido de la salida con el mtodo de salida

Es posible concebir la salida como cualquier cosa que sale de la organizacin, a la cual se le llamara salida
externa o que permanece dentro de la organizacin, la cual sera una salida interna.
La salida externa nos es familiar por su uso para los recibos de servicios, publicidad, cheques, informes anuales
y miles de otras comunicaciones que las organizaciones tienen con sus clientes, vendedores, proveedores, industria y
competidores. Algunas de estas salidas, tales como los recibos de servicios, se disean por el analista de sistemas para
cumplir con dos funciones, como lo hara un documento que requiere ir a varias partes y regresar. En otras palabras, la
salida de una de las etapas de un proceso se vuelve la entrada de otro, cuando el cliente regresa aquella parte del
documento.
Las salidas externas difieren de las salidas internas no slo por l mecanismo de distribucin, sino adems, por
su diseo y apariencia. Muchos documentos externos, si se desea que se utilicen correctamente, deben incluir
instrucciones para el receptor. Adems, muchas salidas externas se imprimen en formas que contienen el emblema de la
compaa y los colores corporativos.
Dentro de las salidas internas tenemos varios informes para la toma de decisiones. Estos se distribuyen a todo
lo largo de la organizacin, desde un breve resumen, hasta un informe altamente detallado. Un ejemplo de un resumen es
el reporte que consolida las ventas totales del mes. Un reporte detallado pudiera ser el de las ventas semanales por
vendedor.
Otros tipos de informes internos incluyen los informes histricos que se manejan como reportes por excepcin
y que se emiten slo en el momento de la excepcin (una desviacin de lo esperado). Por ejemplo una lista de todos los
empleados sin faltas en el ao.
6.4.1.2. La eleccin de la tecnologa de salida

Para producir diferentes tipos de salidas, se requiere el uso de diferentes tecnologas. Para salidas impresas de
computador, las opciones con que contamos son las impresoras de impacto y no impacto. Para las salidas por pantalla,
tenemos como opciones monitores independientes o integrados o pantallas de cristal lquido. Las salidas de audio
pueden amplificarse a travs de parlantes o escucharse a travs de una pequea bocina del microcomputador. Las
microfichas son salidas creadas por equipos de cmaras especiales y filmadas en microfichas y microfilms.
En cierta manera, la salida de audio podra considerarse como exactamente lo opuesto a la salida impresa; esta
es temporal, mientras que la palabra es permanente. En general es para beneficio de un solo usuario, mientras que la
salida impresa comnmente cuenta con una amplia distribucin. La salida de audio por ejemplo sirve para atender
pedidos de nmeros de catlogo con llamadas libres de cobro, (0800), las 24 horas del da. Al utilizar un telfono digital,
los clientes marcan el nmero y en respuesta a las instrucciones que reciben por el audio, los clientes seleccionan el
artculo numerado, la cantidad, el precio y refieren el nmero de su tarjeta de crdito. Esto implica para los almacenes la
captura de ventas que de otra forma se perderan, ya sea porque la contratacin de empleados pudiera ser muy cara para
justificar una atencin por 24 horas.
6.4.1.3. Consideraciones al elegir la tecnologa de salida

Existen varios elementos a considerar en su eleccin. Aunque la tecnologa cambia con rapidez, hay principios
tiles que permanecen prcticamente constantes en relacin a los avances tecnolgicos. Estos elementos son:
1.
Quin usar la salida?
Por ejemplo cuando los gerentes de distrito se encuentran alejados de sus oficinas por grandes perodos,
necesitan de salidas impresas que puedan llevar consigo, conforme visiten a los gerentes de su regin. De manera
alternativa, las salidas por pantallas son excelentes para funciones tales como el despacho de transporte, donde el
despachador se encuentra cerca de su escritorio la mayor parte del tiempo.
115
Tambin, aplican diferentes estndares, dependiendo si el receptor de la salida es interno o externo a la

organizacin. Los receptores de salidas externas (clientes, proveedores) requerirn de salidas diferentes que los usuarios
internos de la empresa.
Con frecuencia, los clientes carecen de acceso a las salidas electrnicas, ya que simplemente no cuentan con el
equipo requerido. En este caso, usted debe proporcionar una salida impresa. El conocer quin ser el usuario de la salida,
nos permite determinar el requisito de calidad de la salida. Podemos considerar adecuado para usuarios internos
numerosos, los impresos estndares en papel de computador, una salida en letra de calidad se requerir para una
correspondencia comercial, con un pblico externo.
2.
Cuntas personas necesitan la salida?
La eleccin de la tecnologa de salida tambin queda influenciada por el nmero de usuarios que la usarn. Si
numerosas personas requieren de la salida, probablemente se justificaran las copias impresas. Si slo un usuario
requiere de la salida, una salida por pantalla, en microfichas, o an, una salida de audio puede ser lo ms apropiado.
Si numerosos usuarios de la empresa necesitan salidas diferentes a tiempos diferentes, por perodos cortos y la
requieren con rapidez, entonces una alternativa ser el uso de terminales conectadas en lnea y con acceso directo a la
base de datos.
3.
En dnde se necesita la salida?
Otro factor que influye en la eleccin de la tecnologa de salida es el destino fsico de ella. Aquella informacin
que permanecer cercana a su punto de origen, que ser utilizada por muy pocos usuarios dentro de la empresa y que
pudiera almacenarse y consultarse con frecuencia, con seguridad puede ser impresa. Una abundante informacin que
deba transmitirse a los usuarios a grandes distancias en operaciones satlites, puede mejor distribuirse de manera
electrnica y el receptor decidir si lo imprime, lo presenta en pantalla o lo almacena.
4.
Cul es el propsito de la salida?
Otro factor a considerar para elegir la tecnologa es la funcin de la salida. Si la salida tiene el propsito de
atraer accionistas a la organizacin, y que stos tengan a su disposicin las finanzas corporativas, entonces, lo ms
adecuado sera presentar un reporte anual con excelente diseo. Si el propsito de la salida es actualizar cada 15 minutos
los coeficientes del mercado de valores y el material se encuentra altamente codificado y es variable, entonces, lo mas
adecuado sera hacer uso de las pantallas de vdeo o aun del audio.
5.
Con qu frecuencia se requiere la salida?
Entre ms frecuente se accesa una salida, ms importante ser el disponer con terminales conectadas en lnea al
sistema. En las salidas de acceso poco frecuente, que requieran unos cuantos usuarios, las microfichas son apropiadas,
como microfichas o microfilm.
Aquellas salidas que se consultan con frecuencia son candidatas adecuadas para incorporarse a sistemas en
lnea, con presentaciones en pantallas. La adopcin de este tipo de tecnologa permite que el usuario tenga un fcil
acceso y disminuye a la vez el riesgo del desgaste fsico que deteriora la frecuente manipulacin de las salidas impresas.
6.
Bajo qu regulaciones particulares se produce la salida?
Ciertas salidas estn sujetas a la regulacin del gobierno que impone el uso de determinadas tecnologas. Por
ejemplo las declaraciones juradas del SII o las boletas y facturas electrnicas.
7.
Cules son los costos iniciales y posteriores del mantenimiento y los suministros?
Los costos iniciales de adquirir o arrendar un equipo deben considerarse como otro elemento que entra en la
eleccin de la tecnologa de salida. La mayora de los vendedores le ayudarn a estimar los costos iniciales de compra o
alquiler de un computador, incluyendo el costo de impresoras y terminales de vdeo. Sin embargo, muchos vendedores
no proporcionarn informacin acerca del costo para mantener operando una impresora (papel, cintas, reparaciones y
116
mantenimiento). De tal forma que es responsabilidad del analista, investigar el costo de operacin de las diferentes
tecnologas de salida.
8.
Cules son los requisitos ambientales para las tecnologas de salida?
Como se habr observado anteriormente, las impresoras requieren de un ambiente seco y fresco para operar
adecuadamente. Los monitores requieren de espacio y cableado para conectarse a la base de datos que se accesa. La
salida de audio requiere de un sitio relativamente silencioso, que permita que el usuario comprenda los sonidos
digitalizados. Adems el volumen de la salida de audio debe ser lo suficientemente alto como para escucharse, no
debera ser audible para los otros empleados (o clientes) que no lo utilizan.
En el otro extremo ciertas tecnologas son apreciadas por su discrecin. Las bibliotecas que enfatizan el silencio
en el rea de trabajo, hacen extensivo el uso de monitores de vdeo. Estos son mucho ms silenciosos que la operacin
de impresoras y, ms an que el uso de cardex consultados fsicamente por el usuario.
6.4.1.4. Reconocer la manera en que el sesgo de la salida afecta al usuario

De tres maneras se puede crear un error no intencionado en la presentacin de las salidas:
La manera de ordenar la informacin
Se introduce sesgo en la salida cuando el analista elige la manera de ordenar la informacin de un reporte.
Formas comunes de ordenamiento incluyen el cronolgico, el alfabtico y el de costos.
La manera de establecer los lmites de aceptacin
Una segunda fuente importante de error en la salida es la definicin preliminar de lmites para valores
particulares que sern reportados. El analista de sistemas podra sin intencin, establecer un lmite demasiado bajo o
demasiado alto, rangos estrechos de las salidas por excepcin o rangos amplios para estas salidas.
La eleccin de grficas
El tamao de la grfica debe ser proporcional, de tal forma que el usuario no confunda la importancia de las
variables presentadas. La eleccin del color de la grfica es de suma importancia, de tal forma que no se distorsionen sus
conclusiones. El tipo elegido de grfica para la salida tambin es una fuente de sesgo potencial. Una grfica de torta es
inadecuada si los porcentajes del conjunto no es lo ms relevante. Las grficas de barras y de columnas pueden exagerar
las diferencias entre las variables.
Los analistas de sistemas cuentan con ciertas estrategias especficas para evitar el sesgo en la salida que
diseen:
1- Reconocer la fuente del sesgo
2- Diseo interactivo de la salida que considere a los usuarios
3- Trabajar con los usuarios, de tal forma que conozcan del sesgo de la salida
4- Creacin de una salida flexible que permita al usuario modificar los lmites, los rangos y el ordenamiento.
5- Proponer a los usuarios diferentes salidas para conducir pruebas realistas sobre la salida del sistema.
Prototipos.
En sntesis el analista de sistemas debe solicitar la retroalimentacin activa del usuario, respecto a la salida. El
proceso de diseo requerir de varias interacciones, antes de que el usuario sienta que es de utilidad la salida. Otro
117
aspecto importante es disear una salida en la que los usuarios sean capaces de modificar los lmites y los rangos
establecidos para el usuario.
6.4.1.5. Diseo de la salida impresa
Al hacer uso de la informacin obtenida durante la fase de determinacin de los requisitos de informacin y una
vez decidido, el uso de la salida impresa, el analista de sistemas se encuentra en condiciones de iniciar el diseo fsico de
la salida. La fuente de informacin bsica es el diccionario de datos.
Convenciones en el diseo de reportes
Informacin constante:
Es la informacin que permanece sin cambios cada vez que se imprime el reporte. Para indicar la informacin
constante, el analista la anota en la forma con un carcter por espacio. El ttulo del reporte y los encabezados de todas las
columnas se consideran como informacin constante.
Informacin variable:
Es la informacin que vara cada vez que el reporte se imprime.
Para determinar el ancho del reporte, determine para cada uno de los campos el mximo de:
1) los requerimientos de longitud del campo de los datos elementales, conforme stos aparezcan en el
diccionario de datos, y
2) el rengln ms largo que propone como encabezado de columna. Luego,
3) agregue los espacios que pretendan dar una separacin en ambos lados. Finalmente, sume estos estimados
del campo para obtener el ancho estimado.
Calidad del papel, tipo y tamao
La salida puede imprimirse en innumerables tipos de papel, la restriccin preponderante por lo general es el
costo. El tipo de papel que tiene un tratamiento especial, ya sea preimpreso, entintado a color, con varias copias o con
formas que no requieren papel carbn, ser ms costoso que el simple papel de computador.
La calidad del papel tambin difiere por el contenido de algodn. Mientras ms algodn contenga, tendr una
mejor calidad, durabilidad y mayor precio. Pero un negocio quizs querr que su correspondencia particular se imprima
en papel bond que contenga algodn, mediante el uso de una impresora de calidad, todo ello con el fin de dar una
imagen de mayor distincin.
Salidas en formas especiales
Las formas preimpresas tienen numerosos propsitos; entre ellos tenemos el envo a los clientes de documentos
de ida y vuelta. A travs de uso de colores y de diseos corporativos las formas preimpresas pueden llevar el logotipo de
la corporacin. El uso de formas innovadoras, colores y distribuciones motivan de manera dramtica la atencin del
usuario hacia el reporte particular.
Consideraciones de diseo
Atributos funcionales:
Los atributos funcionales de un reporte impreso incluyen el encabezado o ttulo del reporte, el nmero de la
pgina, la fecha de preparacin, los rtulos de las columnas, el agrupamiento de los datos relacionados y el uso de
elementos de pausa. Cada uno de ellos cumple con un propsito especfico para el usuario.
118
El encabezado o ttulo del reporte dirige al usuario de manera inmediata al tema de su lectura. El ttulo debe ser
descriptivo y conciso. Es redundante incluir la palabra reporte en el ttulo.
Cada pgina debe numerarse de tal forma que el usuario cuente fcilmente con un punto de referencia cuando
discuta la salida con otros o vuelva a localizar datos importantes. Tambin si las pginas de las salidas se encuentran
separadas, su paginacin es invaluable para reconstruir el documento.
En cada impresin incluya la fecha de la preparacin del reporte.
Los encabezados de las columnas sirven para orientar al usuario sobre el contenido del reporte. Cada elemento
debe contar con un encabezado. Los encabezados deben ser breves y descriptivos.
Utilice cortes de control (los cuales son separaciones entre los datos cuando aparece un total) para auxiliar la
lectura. Separe con lneas adicionales el resto de los datos. Por ejemplo, si 200 tiendas de venta de indumentaria
deportiva se agruparan por zona geogrfica, el reporte puede contar con cortes al final de cada una de las zonas.
Atributos estilsticos/estticos
Los reportes impresos estn organizados de tal forma como los apreciaran nuestros ojos. Dentro de este
contexto, esto significa que el reporte debe leerse de arriba hacia abajo y de izquierda a derecha. Los datos relacionados
deben agruparse, como se mencion con anterioridad.
El uso de cortes de control tambin cubre una funcin importante; pero su ubicacin en la pgina tambin le
confiere una caracterstica esttica. D atencin a los cortes de control, a las totales y a otra informacin relevante,
encerrndolos en cuadros mediante el uso de caracteres especiales, tales como asteriscos o espacios adicionales.
Esto permite agilizar la bsqueda de informacin decisiva y evita la larga impresin de columnas continuas de
informacin.
Las salidas de reportes impresos requieren de amplios mrgenes a la derecha y a la izquierda, as como, en los
bordes superior e inferior. Esto permite atraer la atencin del usuario al material que se centra en la pgina facilitando la
lectura. No debe subestimarse la relevancia de la distribucin, la legibilidad y la facilidad de uso, ya que la salida se crea
para ser utilizada.
Pasos para la preparacin de la hoja de distribucin de la salida
A continuacin se presenta una gua, paso a paso, para la preparacin de la hoja de distribucin de la salida:
4) Determine las necesidades del reporte.
5) Identifique a los usuarios.
6) Determine la informacin que se va a incluir.
7) Cuente el nmero de espacios necesarios y decida la dimensin global del reporte.
8) Titule el reporte
9) Numere las pginas del reporte
10) Incluya la fecha de preparacin del reporte
11) Rotule cada columna de datos de manera adecuada
12) Defina la lnea de detalles para los datos variables, indicando si cada espacio se utilizar para un
carcter alfabtico, especial o numrico.
13) Indique la posicin de las totales (cortes de control).
119
14) Revise el boceto (o prototipo) de los reportes con los usuarios y programadores para evaluar su
factibilidad, utilidad, legibilidad, compresin y apariencia esttica.
Estructura jerrquica de una salida impresa
La estructura jerrquica de una salida, nos permite analizar la composicin de la misma y las ocurrencias de los
datos dentro de la salida.
Tiene como objetivo indicar el nmero de veces que aparece un subconjunto de datos en el conjunto al que
pertenece. Es posible colocar los signos de exclusin, inclusin o exclusin exclusiva, cuando los subconjuntos
pertenecientes al mismo nivel aparezcan 0 o 1 vez en el conjunto al que pertenecen.
6.4.2.
Diseo de Pantalla.
Observe que las salidas por pantalla, difieren de diversas maneras de las salidas impresas. Estas son efmeras,
es decir, una imagen en monitor no es permanente, de la misma manera como lo sera una impresin; pueden estar
dirigidas en forma ms especfica hacia el usuario: tienen un formato con mayor flexibilidad, no son portables; y en
ocasiones, las salidas por pantalla permiten modificaciones mediante una interaccin directa.
Adems, los usuarios deben saber qu teclas presionar si desean consultar pantallas adicionales, cmo concluir
la presentacin y si es posible, cmo interactuar con lo desplegado en la pantalla. El acceso a las presentaciones por
pantalla puede controlarse a travs del uso de un cdigo confidencial (password), mientras que la distribucin de las
salidas impresas se controla de manera distinta.
6.4.2.1. Lineamientos para el diseo de pantallas

Existen cuatro lineamientos que facilitan el diseo de las pantallas. Para resumir, estos son:
1) Mantenga una pantalla sencilla.
2) Mantenga una presentacin consistente en la pantalla.
3) Facilite el movimiento del usuario entre pantallas.
4) Cree una pantalla atractiva.
Las dimensiones tpicas de una pantalla son de 80 columnas por 24 renglones. Las diferencias en el diseo de
pantallas radican en la necesidad de indicar los cambios de la pantalla, los movimientos entre pantallas y la conclusin
de la presentacin de la salida.
Cuando la pantalla se encuentra en la fase de diseo preliminar, antes de que hayan sido asignados los espacios
en la forma, es muy conveniente mostrar a los usuarios un boceto de la pantalla y recibir su retroalimentacin acerca de
las modificaciones o mejoras que desearan. Este es un proceso interactivo que contina hasta que el usuario se
encuentra satisfecho por lo que le proporciona la salida y la claridad del formato. As como en la salida impresa, las
pantallas de calidad no pueden crearse de manera aislada. Los analistas de sistemas necesitan retroalimentacin de los
usuarios para disear pantallas de gran vala. Una vez aprobada por los usuarios, el diseo de la pantalla puede
plasmarse en la hoja de diseo de pantallas.
La presentacin orienta al usuario a travs del encabezado. En la parte inferior de la pantalla se tienen
instrucciones. El usuario cuenta con varias alternativas, que incluyen: continuar con la pantalla actual, concluir la
presentacin, obtener ayuda o contar con ms detalle.
Las pantallas de salida dentro de una aplicacin deben presentar de manera consistente la informacin de
pantalla a pantalla.
120
6.4.2.2. Objetivos del diseo de entradas

Un buen diseo de los formatos y las pantallas de entrada debe satisfacer los objetivos de eficacia, precisin,
facilidad de uso, consistencia, sencillez y atraccin.
La eficacia significa que las formas y las pantallas de entrada satisfagan propsitos especficos del sistema de
informacin de la administracin, mientras que la precisin se refiere a un diseo tal que asegure una realizacin
satisfactoria. La facilidad de uso implica que tanto las formas como las pantallas sern explcitas y no requerirn de
tiempo adicional para descifrarse. La consistencia, en este caso, significa que las formas y las pantallas ordenen los datos
de manera similar de una aplicacin a otra, mientras que la sencillez se refiere a mantener en un mnimo los elementos
indispensables que centren la atencin del usuario. La atraccin implica que el usuario disfrutar del uso o trnsito a
travs de las formas y las pantallas cuyos diseos les sean ms atractivos.
6.4.2.3. Buen diseo de los formularios de entrada de datos

Los formularios de entrada de datos son instrumentos importantes para el desempeo adecuado del trabajo. Por
definicin, son documentos duplicados o preimpresos que requieren ser llenados por las personas, en respuesta a un
procedimiento estandarizado. Los mismos hacen surgir y capturan la informacin que los miembros de la organizacin
requieren y con frecuencia se alimentan al computador.
Existen cuatro lineamientos importantes para el diseo de los formularios de entrada:
1.
Disee formas fciles de llenar
Para reducir el error, agilizar su llenado y facilitar la captura de datos, es esencial que las formas sean
fciles de llenar. El costo de las formas es mnimo si se compara con el costo del tiempo que ocupa el empleado
en el llenado y en la alimentacin de los datos en el computador.
Es importante tener en cuenta el Flujo de la forma: El diseo de una forma con un flujo adecuado
minimiza el tiempo invertido y el esfuerzo realizado por los empleados en el llenado. Las formas deben seguir
un flujo de izquierda a derecha y de arriba hacia abajo.
Es importante tambin respetar las siete secciones de una forma: Una segunda tcnica que facilita el
llenado correcto de las formas consiste en la agrupacin lgica de la informacin. Las siete secciones
principales que le confieren solidez a una forma son:
a)
b)
c)
d)
e)
f)
g)
Encabezado
Identificacin y acceso
Instrucciones
Cuerpo del formulario
Firma y verificacin
Totales
Comentarios
De manera ideal, estas secciones deberan aparecer en una sola pgina ordenada. Obsrvese que las
siete secciones cubren la informacin bsica requerida en la mayora de los formularios. La parte superior del
formulario recibe tres secciones: el encabezado, las secciones de identificacin y acceso y la seccin de
instrucciones.
La seccin del encabezado por lo general incluye el nombre y la direccin de la empresa que origina la
forma. La seccin de identificacin y de acceso contiene claves que sirven para archivar el informe y obtener,
en un momento dado, acceso a l. Esto es importante cuando una organizacin requiere conservar un
documento por un determinado nmero de aos. La seccin de instrucciones nos dice cmo debera llenarse la
forma y a donde dirigirla cuando se complete.
La parte central de la forma es su cuerpo, el cual utiliza aproximadamente la mitad de la forma. Esta
parte requiere del mayor detalle y desarrollo de la persona que la llena.
121
La parte inferior de la forma se integra con tres secciones: firmas y verificacin, total y comentarios.
Otro aspecto a tener en cuenta es el rotulado: Los rtulos le indican a las personas qu anotar en un
espacio en blanco, en un rengln o en un recuadro. Se dispone de varias alternativas para rotular. Los rtulos de
lnea pueden encontrarse a la izquierda de reas en blanco y en el mismo rengln, o bien pueden imprimirse
debajo de la lnea donde se registrar el dato. La ventaja de ubicar rtulos debajo de las lneas es que se dispone
de ms espacio en tal lnea para el dato. Otra forma de rotular es proporcionar un recuadro para los datos, en
lugar de la lnea.
Los rtulos pueden ubicarse dentro, fuera o debajo del recuadro. Los recuadros auxilian a la gente a
introducir los datos en el sitio correcto y tambin facilitan la lectura del receptor de la forma. Cualquiera que
sea el estilo que elija para rotular, es importante emplearlo de manera consistente. Por ejemplo, llenar una
forma que contiene rtulos tanto encima como debajo de las lneas se presta a confusin.
Los cuadros de seleccin son ms convenientes cuando el nmero de alternativas de respuesta se
encuentra necesariamente restringido.
Las tablas son muy convenientes dentro del cuerpo de un formulario cuando se requiere detalles.
Cuando un empleado se apega al formato de una forma que cuenta con un arreglo tabular, crea una tabla que
ser de fcil compresin para la siguiente persona que reciba la forma y a la vez permite mantener una
organizacin coherente de los datos.
Puede utilizarse una combinacin de rtulos y cuadros. Es posible que pudiera necesitarse de
diferentes estilos de rotulado.
2.
Asegrese que las formas cumplan con el propsito para el cual fueron diseadas.
3.
Disee formas que aseguren un llenado preciso.
4.
Mantenga las formas atractivas.
Las formas estticas motivan a la gente y hacen que se les d importancia. Esto significar que cuando
la gente llene las formas, se sentir ms satisfecha y adems llenar la forma en toda su extensin. Las formas
no deben parecer amontonadas, sino ms bien, deben dar una apariencia de organizacin y lgica, an despus
de llenarse. Se logra lo anterior, al proporcionar suficiente espacio para alojar respuestas mecanogrficas o
manuscritas. El uso de diferentes tipos de letra dentro de la misma forma puede mejorar su imagen. Puede
motivarse el inters en la forma al separar categoras y subcategoras con lneas de diferente grosor. Los tipos
de letra y las lneas de diferentes grosores son elementos tiles de diseo para atraer la atencin y hacer que la
gente se sienta segura de que llena una forma correctamente.
6.4.2.4. El buen diseo de pantallas

Mucho de lo que ya hemos dicho acerca del buen diseo de formularios de entrada puede transferirse al diseo
de pantallas.
Sin embargo, entre ambos casos existen diferencias, una de ellas y muy importante es la presencia constante de
un cursor (un bloque iluminado u otro sealador) en la pantalla, que orienta al usuario sobre la posicin actual de acceso.
Conforme se introducen los datos en la pantalla, el cursor se ir desplazando un carcter hacia delante de la direccin de
la captura.
Existen cuatro lineamientos para el diseo de pantallas. Ellos son:
1.
Mantenga la pantalla sencilla

La pantalla debe mostrar solo lo que es necesario para la accin particular que se lleva a cabo.
122
a)
Las tres secciones de la pantalla.
La parte superior de la pantalla contiene la seccin del encabezado, parte de la cual se

encuentra programada para indicar al usuario en donde se encuentra dentro de la aplicacin o paquete.
El resto del encabezado puede incluir otros elementos, tales como el nombre del archivo que el usuario
ha creado.
Tambin debe proporcionarse al usuario la definicin de los campos indicando la dimensin
previsible del dato para cada campo de la pantalla.
La tercera seccin de la pantalla se denomina seccin de Comentarios e Instrucciones. Esta
seccin puede contener un men conciso de rdenes que recuerde al usuario las funciones bsicas del
sistema, tales como el cambio de pantalla, o funciones tales como la grabacin de archivos o la
conclusin de la sesin de captura. La inclusin de tales funciones bsicas permite que los usuarios sin
experiencia se sientan ms seguros de su habilidad para operar el computador sin llegar a ocasionar
errores fatales.
b)
Uso de ventanas.
Otra manera de mantener la sencillez de la pantalla es emplear unas cuantas instrucciones

bsicas que al ser llamadas sobrepongan ventanas, que cubran parcial o totalmente la pantalla activa
con nueva informacin.
De esta manera, el usuario comienza la interaccin con el sistema, con una pantalla sencilla y
de buen diseo, y controlando la complejidad del sistema a travs del uso de ventanas mltiples.
Al contar con tal ventana se facilita el acceso rpido y correcto, ya que el usuario no necesita
recordar aquellos cdigos de poco uso o dejar la pantalla para consultar una lista impresa, antes de
completar la entrada de los datos. Adems, el sistema desarrollado puede programarse para aceptar
solo a los cdigos de clasificacin listados en la pantalla y de manera automtica, presentar la ventana
si el cdigo tecleado es incorrecto. Esto evita los errores que pudieran ocurrir si cualquier cdigo de
clasificacin fuera aceptado por el sistema.
Al usar otra orden o al presionar otra tecla ya antes definida, el operador limpia las ventanas
informativas y regresa a la pantalla original.
2.
Conservar consistencia en la pantalla.
El segundo lineamiento para un buen diseo de pantalla es el mantenimiento de una imagen

consistente. Si el trabajo de los usuarios se basa en formas en papel, las pantallas deben apegarse a lo que se
muestra en el papel. La consistencia de la pantalla tambin se mantiene, si la informacin se localiza en la
misma rea cada vez que se accesa una nueva pantalla.
3.
Facilidad de movimiento.
El tercer lineamiento para un buen diseo de pantalla es la facilidad de desplazarse con sencillez entre
una pantalla y otra.
a)
Desplazamiento
Bsicamente consiste en tener el control de las teclas de desplazamiento que provee el teclado
y hacer que se comporten de forma natural, flecha a izquierda desplaza el cursor hacia la izquierda y
as sucesivamente.
b)
Solicitud de mayor detalle
Otra de las tcnicas bsicas de movimiento entre pantallas, permite que los usuarios se
desplacen con rapidez a otras pantallas, mediante la colocacin del cursor junto a un comando
123
especfico. Por ejemplo, colocar el cursor sobre el nombre del empleado que haya elegido y presionar
la tecla correspondiente a un comando preestablecido. Este comando lo llevar a una nueva pantalla, la
cual corresponde al registro detallado del empleado elegido.
c)
Dilogo en pantalla
El uso de dilogos entre el usuario y el computador facilita cierta clase de movimientos entre
las pantallas.
4.
Diseo de una pantalla atractiva
Las pantallas deben atraer al usuario y mantener su atencin. Esto se logra con el uso de espacios
abiertos que rodeen los campos de captura de datos, de tal forma que la pantalla no se vea sobrecargada. Nunca
se debe saturar una forma, as como nunca se debe saturar una pantalla. Siempre ser mejor utilizar pantallas
mltiples, que amontonar todo en una sola. Existen mltiples recursos para lograr esto, algunos de ellos son:
a)
El vdeo inverso y los cursores que destellan
b)
El uso de diferentes tipos de letras
c)
El uso de imgenes en el diseo de pantallas
Utilice imgenes tpicas que los usuarios puedan interpretar fcilmente. Las imgenes para
una aplicacin particular deben limitarse a no ms de veinte formas reconocibles, de esta forma el
vocabulario de imgenes no se saturar y puede desarrollarse un buen esquema de codificacin. Utilice
de manera consistente las imgenes que a todo lo largo de la aplicacin deban aparecer juntas. Esto
asegura continuidad y comprensin. En general las imgenes son tiles si conllevan un significado.
d)
El uso de color en el diseo de la pantalla: Las mejores combinaciones son:

negro sobre amarillo
verde sobre blanco
azul sobre blanco
blanco sobre azul
amarillo sobre negro
El color debe considerarse como una manera importante de contrastar; resaltar datos y
campos de importancia; apuntar errores y permitir codificaciones especiales para las entradas.
124
6.5.
Diseo Procedimental
El diseo procedimental transforma los elementos estructurales en una descripcin procedimental del software.
El diseo procedimental se realiza despus de que se ha establecido la estructura del programa y de los datos. Define los
algoritmos de procesamiento necesarios.
Permite definir un mdulo sin entrar en excesivos detalles. La interfaz del mdulo contiene los parmetros de
entrada y de salida, mientras la funcin del mdulo describe las tareas que este lleva a cabo. Se permite el uso de tablas,
frmulas, lenguaje natural, etc. Permite variar el grado de formalismo en la definicin del mdulo, generalmente, dando
bastante libertad a los programadores. Su inclusin como comentario en el cdigo final facilita el mantenimiento.
Esta documentacin permite a los usuarios, analistas, diseadores y programadores ver el sistema, su software y
los procedimientos, sin necesidad de una interaccin directa. Cierta documentacin proporciona un panorama del
sistema, otra contiene los procedimientos que detalla lo que debe realizarse para operar el software y una distinta detalla
el cdigo de programa utilizado.
No existe una sola tcnica sencilla y estandarizada para la documentacin.
Dentro del anlisis de sistemas se usan tcnicas de documentacin para la especificacin de procesos, pero los
requerimientos que estas especificaciones deben satisfacer son diferentes a las del diseo.
Una buena tcnica de especificacin de proceso debe:
expresarse de una manera que pueda verificar tanto el analista como el usuario
poder ser comunicada efectivamente al amplio publico que este involucrado (usuarios, auditores,
personal de control de calidad, entre otros)
no imponer decisiones de diseo e implantacin
Debido a estos factores, las tcnicas ms utilizadas en esta fase son: lenguaje estructurado o seudocdigo,
rboles de decisin y tablas de decisin.
Pero adems de utilizar una forma procedural, se debe adicionar una forma grfica que permita delimitar los
distintos objetos de programa que participan en la funcin del mdulo, propiamente tal. Esta forma se denomina
Diagrama de Bloques, la cual permite a travs de dibujos simples los elementos participantes en un proceso
determinado. Los elementos grficos son:
Proceso o Mdulo
nombre
Dispositivo de Entrada
Pantalla
Archivo de Datos
Base de Datos
nombre
nombre
nombre
nombre
nombre
125
Informe o Listado (Impresin)
nombre
Dispositivo de Respaldo
nombre
Direccin de la Informacin
Documentos de Entrada
Otra manera de especificar un mdulo es a travs de un lenguaje de manipulacin de datos, el cual es ofrecido
por la gran mayora de los administradores de bases de datos (DBMS), denominado SQL (Secuential Query Language).
6.6.
Diseo Arquitectnico.
El Diseo Arquitectnico o estructural define las relaciones entre los principales elementos estructurales del
programa. El objetivo principal del diseo estructural es desarrollar una estructura de programa modular y representar
las relaciones de control entre los mdulos.
Concluido el diseo se genera el cdigo fuente y para integrar y validar el software, se llevan a cabo pruebas
del software.
126
7.
Programacin
Cuando termina la etapa de diseo, normalmente comienza la etapa de programacin y prueba. La fase de
programacin o implantacin de un proyecto involucra la escritura de instrucciones en un lenguaje de programacin para
implantar lo que el analista ha especificado y el diseador ha organizado en mdulos.
Durante esta fase el analista tiene un papel importante. En el caso extremo, una vez terminada su labor de
especificacin del sistema pasa algn tiempo con el equipo de diseo durante las primeras etapas del diseo, pero luego
deber comenzar con otro proyecto. Sin embargo, existen razones por las cuales el analista debe permanecer involucrado
en el proyecto al comenzar la actividad de programacin:
Por ser lder del proyecto debe estar involucrado en el mismo hasta la prueba final, la aceptacin y entrega
al usuario final. Adems debe verificar que el cdigo es de alta calidad y que las pruebas a los programas
se efectuaron de manera adecuada.
El analista forma parte del grupo que escribe casos de prueba que se usaran para probar los programas. Es
probable que se adhieran en esta actividad uno o ms usuarios por ser los ms aptos para pensar en casos
excepcionales y pocos usuales de prueba. El desarrollo de pruebas puede empezar tan pronto como se
termina la especificacin.
Dado a que por lo pronto solo conoce el contenido lgico de las entradas y salidas, debe esperar a que el
modelo de implantacin del usuario quede terminado para conocer el formato fsico de los mismos y poder
conocer las restricciones operacionales (tiempo de respuesta, volmenes, etc.) que se necesitan probar.
El analista, por estar involucrado desde el principio en el proyecto, es el candidato ideal para estar
involucrado en el desarrollo de manuales para el usuario, preparacin de los usuarios o en la planeacin de
la instalacin del nuevo sistema y conversin de datos desde el otro sistema. En la mayor parte de los
casos, esto puede llevarse a cabo de manera paralela con la programacin y prueba del nuevo sistema.
En el caso de que la especificacin no se comprenda, pueda estar incompleta, ser inconsistente o

contradictoria es necesario que el programador consulte peridicamente para revisar y aclarar las
especificaciones. Otra variante puede ser la solicitud de cambio de especificacin por ser demasiado difcil
de implantar.
Puede que los usuarios cambien los requerimientos, incluso cuando los programadores estn implantando
lo que decan querer.
As como el anlisis estructurado involucra una progresin continua de modelado de alto nivel (el diagrama de
flujo de datos de nivel superior) a aspectos de modelado de bajo nivel (especificaciones de procesos y diccionario de
datos) y el proceso de diseo involucra modelos de diseo que van desde diagramas de estructura de alto nivel hasta
formas de bajo nivel como el pseudocdigo y diagrama de flujo, la programacin debe seguir este mismo patrn. Se
escriben mdulos ejecutivos de alto nivel. Luego se desarrollaran los mdulos de bajo nivel que llevan a cabo clculos
detallados, validan datos de entrada, etc.
Las cuestiones que se deben tomar en cuenta en programacin, independientemente del lenguaje utilizado son:
- Productividad: consiste en escribir mas software, mas rpidamente. Por lo tanto, a la hora de elegir un
lenguaje, se debe adoptar uno que promueva la productividad.
Exceptuando algunos casos raros, la productividad se considera actualmente ms importante que la eficiencia.
127
7.1.
Elementos de Aseguramiento de la Calidad
Eficiencia: este aspecto sigue siendo muy importante en sistemas de tiempo real y aquellos que procesan
grandes volmenes de informacin. Para aplicaciones de estos tipos resulta importante minimizar la cantidad de tiempo
de CPU requerido por el programa. Tambin puede ser importante minimizar la utilizacin de memoria, al igual que la
de otros recursos como el disco. Esta meta usualmente entra en conflicto con otras. Una mayor eficiencia en un
programa puede hacer que sea menos mantenible y menos portable, que tenga mayor nmero de errores y reduzca la
productividad de la persona que escribe el programa.
Correccin: es importante que el lenguaje revise cuidadosamente todo el cdigo y detecte inconsistencias,
referencias ilegales, exija la declaracin de variables, entre otros controles. Esto es indispensable principalmente en
aplicaciones donde un error puede ser critico.
Portabilidad: aspecto importante que permite correr la aplicacin en distintos tipos de computadoras. Sin
embargo no existe un lenguaje universalmente porttil; siempre hay forma de que el programador aproveche las
caractersticas especiales de una computadora o un sistema operativo especficos. Por ello, si la portabilidad es un factor
importante, adems de tener en cuenta el lenguaje se debe analizar el tipo de programacin.
Mantenibilidad: por durar mucho tiempo los sistemas, el software debe mantenerse.
7.2.
Niveles de la organizacin que construye el sistema
La construccin de sistema mediante una organizacin constituida por niveles es una forma de aprovechar ms
eficientemente los recursos humanos aprovechando sus experiencias y permitiendo una actualizacin constante en las
nuevas tecnologas.
Consiste en dejar que la gente con mayor experiencia (analistas/diseadores) realice las tareas de mayor nivel y
dejar la de menor nivel a los ms novatos (programadores). Esto permite que la programacin no se vuelva en una tarea
mecnica consistiendo es la simple traduccin de las especificaciones. De esta manera la gente mayor experimentada
har no solo las tareas de anlisis de alto nivel sino tambin las de diseo de alto nivel e incluso escribir cdigo de alto
nivel. Por otro lado, los novatos estaran involucrados en el proyecto desde el principio (tan pronto como se terminen las
tareas de anlisis de alto nivel) y participaran en el trabajo de escribir especificaciones de procesos y mdulos, en
desarrollar entradas para el diccionario de datos y escribir cdigo para los mdulos de nivel inferior.
Esto permite que los novatos hagan tareas creativas y codifiquen sus propias especificaciones e involucrndolos
en el proceso de anlisis desde las etapas tempranas de su carrera. Simultneamente obligara a los ms maduros estar en
contacto con la tecnologa al hacer tareas de diseo y programacin.
128
8.
Prueba.
La prueba, como su nombre lo indica, involucra ejercitar el sistema para asegurar que produzca las salidas
apropiadas y exhiba el comportamiento adecuado para una gama amplia de entradas.
Pruebas son un factor crtico para determinar la calidad del software, entonces el objetivo de una prueba es
descubrir algn error. Un caso de prueba es bueno cuando su ejecucin conlleva una probabilidad elevada de encontrar
un error. El xito de la prueba se mide en funcin de la capacidad de detectar un error que estaba oculto.
El diseo de casos de prueba para la verificacin del software puede significar un esfuerzo considerable (cerca del
40% del tiempo total de desarrollo).
Existen fundamentalmente dos enfoques:
Prueba de la caja blanca
Prueba de la caja negra
Combinar ambos enfoques permite lograr mayor fiabilidad.
8.1.
Pruebas de caja blanca
La prueba de la caja blanca usa la estructura de control del diseo procedural para derivar los casos de prueba.
La idea es confeccionar casos de prueba que garanticen que se verifican todos los caminos llamados independientes.
Verificaciones para cada camino independiente:
Probar sus dos facetas desde el punto de vista lgico, es decir, verdadera y falsa.
Ejecutar todos los bucles en sus lmites operacionales
Ejercitar las estructuras internas de datos.
Consideraciones:
Los errores lgicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de
que se ejecute un camino del programa.
A menudo creemos que un camino lgico tiene pocas posibilidades de ejecutarse cuando, de hecho, se
puede ejecutar de forma regular.
8.1.1.
Los errores tipogrficos son aleatorios.
Tal como apunt Beizer, los errores se esconden en los rincones y se aglomeran en los lmites.
Prueba del camino bsico

La prueba del camino bsico es una tcnica de prueba de la caja blanca propuesta por Tom McCabe.
La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes por los cuales puede
circular el flujo de control. Camino independiente es aquel que introduce por lo menos una sentencia de procesamiento
(o condicin) que no estaba considerada en el conjunto de caminos independientes calculados hasta ese momento. Para
129
obtener el conjunto un conjunto de caminos independientes se construir el Grafo de Flujo asociado y se calcular su
Complejidad Ciclomtica.
Cada nodo del grafo corresponde a una o ms sentencias de cdigo fuente. Cada nodo que contiene una
condicin se denomina nodo predicado. Cualquier representacin del diseo procedural se puede traducir a un grafo de
flujo.
Si se disean casos de prueba que cubran los caminos bsicos, se garantiza la ejecucin de cada sentencia al
menos una vez y la prueba de cada condicin sus dos posibilidades (verdadera y falsa).
8.1.2.
Pruebas de estructura de control
La tcnica de prueba del camino bsico del punto anterior es una de las muchas existentes para las pruebas de la
estructura de control. Aunque sea alta la efectividad de la prueba del camino bsico, no nos asegura completamente la
correccin del software.
Veremos a continuacin otras variantes de la prueba de la estructura de control. Estas variantes amplan el abanico
de pruebas mejorando la fiabilidad de las pruebas de caja blanca.
8.1.3.
Prueba de Condiciones
La prueba de condiciones es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas
contenidas en el mdulo de un programa. Los tipos de errores que pueden aparecer en una condicin son los siguientes:
8.1.4.
Existe un error en un operador lgico (que sobra, falta o no es el que corresponde).
Existe un error en un parntesis lgico (cambiando el significado de los operadores involucrados).
Existe un error en un operador relacional (operadores de comparacin de igualdad, menor o igual,

etc.).
Existe un error en una expresin aritmtica.
Prueba de Bucles
Pruebas para Bucles simples. (N es el nmero mximo de iteraciones permitidos por el bucle)
Pasar por alto totalmente el bucle
Pasar una sola vez por el bucle
Pasar dos veces por el bucle
Hacer m pasos por el bucle con m < n
Hacer n-1, n y n + 1 pasos por el bucle
Pruebas para Bucles anidados
Comenzar en el bucle ms interior estableciendo los dems bucles en sus valores mnimos.
130
Realizar las pruebas de bucle simple para el ms interior manteniendo los dems en sus valores
mnimos.
Avanzar hacia fuera confeccionando pruebas para el siguiente bucle manteniendo todos los externos
en los valores mnimos y los dems bucles anidados en sus valores tpicos.
Continuar el proceso hasta haber comprobado todos los bucles.
Pruebas para Bucles concatenados

Siempre que los bucles concatenados sean independientes se puede aplicar lo relativo a bucles
simples/anidados. En caso de ser dependientes se evaluarn como bucles anidados.
Pruebas para Bucles no estructurados
Siempre que se usen los mecanismos que aporta la programacin estructurada, este tipo de bucles no
estarn presentes.
8.2.
Pruebas de caja negra
Los mtodos de la caja negra se enfocan los requisitos funcionales del software. La prueba de la caja negra
intenta encontrar errores de los siguientes tipos:
8.2.1.
Funciones incorrectas o inexistentes.
Errores relativos a las interfaces.
Errores en estructuras de datos o en accesos a bases de datos externas.
Errores debido al rendimiento.
Errores de inicializacin o terminacin.
Particin Equivalente
La particin equivalente es un mtodo que divide el campo de entrada de un programa en clases de datos a
partir de los cuales se pueden derivar casos de prueba. La particin equivalente se enfoca pues a definir casos de prueba
para descubrir clases de errores. Se define una condicin de entrada (valor numrico especfico, rango de valores,
conjunto de valores relacionados o condicin lgica).
Las clases de equivalencia se pueden definir de acuerdo a las siguientes directrices:
Si una condicin de entrada especifica un rango, se define una clase de equivalencia vlida y dos no
vlidas.
Si la condicin de entrada es un valor especfico, se define una clase de equivalencia vlida y dos no
vlidas.
Si la condicin de entrada especifica un miembro de un conjunto, se define una clase de equivalencia

vlida y otra no vlida.
Si la condicin de entrada es lgica, se define una clase vlida y otra no vlida.
131
8.2.2.
Anlisis de Valores Lmite
La tcnica de Anlisis de Valores Lmites selecciona casos de prueba que ejerciten los valores lmite dada la
tendencia de la aglomeracin de errores en los extremos. Complementa la de la particin equivalente. En lugar de
realizar la prueba con cualquier elemento de la particin equivalente, se escogen los valores en los bordes de la clase. Se
derivan tanto casos de prueba a partir de las condiciones de entrada como con las de salida.
Directrices:
Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben disear
casos de prueba para los valores a y b y para los valores justo por debajo y justo por encima de ambos.
Si la condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que
ejerciten los valores mximo y mnimo adems de los valores justo encima y debajo de aqullos.
Aplicar las directrices anteriores a las condiciones de salida. Componer casos de prueba que produzcan
salidas en sus valores mximo y mnimo.
Si las estructuras de datos definidas internamente tienen lmites prefijados (por ej., un array de 10
entradas), se debe asegurar disear un caso de prueba que ejercite la estructura de datos en sus lmites.
8.2.3.
Conclusiones
La aplicacin de casos de pruebas apropiados es esencial para la validacin y verificacin del sistema
construido.
Las pruebas normalmente deberan ocupar cerca del 40% del tiempo total de desarrollo de una
aplicacin. An as, no puede asegurarse un 100% de fiabilidad para el sistema.
En sistemas donde la fiabilidad y correccin del software es un aspecto crtico las pruebas deben ser
ms exhaustivas. En estos casos pueden aplicarse tambin pruebas de comparacin.
Las herramientas que reducen los tiempos de prueba son muy valiosas. Se pueden distinguir varias
categoras de herramientas de prueba: analizadores estticos, auditores de cdigo, generadores de archivos de
prueba, generadores de datos de prueba y controladores de prueba.
8.3.
Proceso de Prueba
La evaluacin debe ser de todos los elementos del sistema; ya sean programas de aplicacin recin escritos o
sus modificaciones, as como los nuevos manuales de procedimientos, el nuevo hardware o interfaces del sistema. No es
suficiente una prueba aleatoria de prueba y error.
La evaluacin se debe llevar a cabo a lo largo del desarrollo del sistema para identificar aquellos problemas
desconocidos, no para demostrar la perfeccin de los programas, de los manuales o del equipo.
Es probable que el proceso de prueba del sistema tome tanto como la mitad del tiempo programado para su
desarrollo, dependiendo de que tan cuidadosamente se hayan hecho las actividades iniciales de anlisis, diseo y
programacin. En el caso de un buen trabajo en dichas etapas, la prueba ser para verificar que no haya errores. Si, por
otro lado, se hizo un trabajo imperfecto entonces la prueba se vuelve iterativa: la primera tanda de pruebas muestra la
presencia de errores, y las posteriores verifican si los programas corregidos funcionan correctamente.
132
En muchos casos, el analista forma parte del grupo que escribe casos de prueba que se usaran para probar los
programas. Es probable que trabaje de manera cercana a los usuarios para desarrollar un conjunto eficaz y de gran
alcance de casos de prueba. El desarrollo de pruebas puede llevarse en paralelo con las actividades de implantacin del
diseo y la programacin, para que, cuando los programadores terminen de escribir sus programas y de realizar sus
propias pruebas locales, el equipo del analista/usuario este listo con sus propias casos de prueba.
La evaluacin se realiza a diferentes niveles y a varios intervalos, aun antes de que el sistema entre en
operacin, de todos los programas en cuanto a su diseo con datos de prueba y verificar si los mdulos se enlazan entre
s tal como fue planeado.
Tambin debe probarse el sistema como una unidad, evaluando las interfaces entre los subsistemas, la
operacin adecuada de la salida, la utilidad y comprensin de la documentacin del sistema y de la salida. Los
programadores, analistas, operadores y usuarios juegan diferentes papeles en los diferentes aspectos de la evaluacin del
software.
La evaluacin del hardware comnmente se proporciona como servicio de los vendedores de equipo, quienes
harn sus propias pruebas, cuando se instale el equipo.
8.3.1.
Estrategias de prueba
Las dos estrategias de prueba ms comunes se conocen como prueba ascendente y descendente. El enfoque
ascendente empieza por probar los mdulos individuales pequeos separadamente; esto se conoce como prueba de
unidades, de mdulos o de programas. Luego los mdulos se combinan para formar unidades cada vez ms grandes que
se probaran en masa; esto se conoce como prueba de subsistema. Finalmente, todos los componentes del sistema se
combinan para probarse; esto se conoce como prueba de sistema y suele estar seguido de las pruebas de aceptacin
donde se permite al usuario usar sus propios casos de prueba para verificar que el sistema este trabajando de manera
correcta.
El enfoque de prueba descendente empieza con el esqueleto del sistema; es decir que se supone que se han
desarrollado los mdulos ejecutivos de alto nivel del sistema, pero que los de bajo nivel existen solo como mdulos
vacos. Dado a que muchas de las funciones detalladas no se han implementado, las pruebas iniciales son muy limitadas;
el propsito es solamente comenzar a ejercitar las interfaces entre los subsistemas principales. Las pruebas siguientes
abarcan y tratan aspectos cada vez mas detallados del sistema. Enfoque que en la actualidad es preferible.
Tanto en el enfoque ascendente como descendente deben llevarse a cabo las siguientes pruebas, considerando
que en el descendente el detalle se ira incrementando a medida que el desarrollo avance:
8.3.1.1. Prueba del programa con datos de prueba.

Una buena parte de la responsabilidad de evaluacin recae en el autor original de cada programa. El analista
slo sirve como orientador o coordinador para asegurar que se implanten las tcnicas de evaluacin adecuadas y ser
poco probable que de manera personal participe en este nivel de evaluacin.
En esta etapa, el programador debe realizar una prueba de escritorio, siguiendo en el papel paso a paso el
programa para verificar si las rutinas trabajan como se plane.
Luego desarrolla datos de prueba vlidos como no vlidos para ver si las rutinas bsicas funcionan y tambin
generar errores. Si la salida de la rutina principal es satisfactoria, pueden agregarse datos de prueba para probar otras
rutinas. Los datos de prueba deben examinar los valores mnimos y mximos posibles, as como todas las variaciones en
formato y en los cdigos. La salida debe verificarse cuidadosamente y no suponer que sea correcta.
A todo lo largo del proceso, el analista debe verificar la salida, posibles errores orientando al programador para
que realice cualquier modificacin.
133
8.3.1.2. Prueba del enlace con datos de prueba.

Las evaluaciones de enlace verifican que los programas sean interdependientes y funcionen integralmente tal
como fue planeado.
Para la prueba de enlace se utiliza una pequea cantidad de datos de prueba, generalmente desarrollados por el
analista de sistemas para examinar las especificaciones del sistema, as como del programa. El examen de todas las
combinaciones puede implicar varios pasos a travs del sistema. Puede ser muy difcil darle un seguimiento a un
problema, si se intenta evaluar todo de un solo paso.
El analista crea datos de prueba para cubrir todo un espectro de situaciones de proceso durante esta prueba.
Primero prueba los datos tpicos para ver si el sistema puede manejar transacciones normales; aquellas que cubran el
mayor volumen de trabajo si el sistema trabajara con transacciones normales. Luego agrega variaciones, incluyendo
datos invlidos para asegurar que el sistema detecta los errores de manera adecuada.
Prueba del sistema completo con datos de prueba: en esta etapa se encuentran activamente involucrados los
operadores y usuarios finales. Se utiliza un paquete de datos de prueba credo por el analista con el propsito de evaluar
los objetivos del sistema.
Factores a considerar:
Verificar que los operadores cuentan con una documentacin adecuada en los manuales de
procedimientos para asegurar una operacin correcta y eficiente
Verificar si los manuales de procedimientos son suficientemente claros como para comunicar la
manera de preparar los datos de entrada
asegurarse de que el sistema soportar el flujo de carga o debe modificarse
determinar si la salida es correcta; esto es, que todos los usuarios comprendan en forma general como
llegar a ser la salida
Se debe programar un tiempo adecuado para la evaluacin del sistema. Comnmente se suele obviar cuando la
instalacin del sistema se encuentra fuera de programa, contra una fecha lmite.
La evaluacin del sistema incluye la confirmacin de todos los estndares de calidad para el desempeo del
sistema, tal y como fueron establecidos cuando se definieron las especificaciones iniciales del sistema. Cada uno de los
involucrados deber una vez ms, estar de acuerdo con la forma de determinar si el sistema realiza los que
supuestamente debera de hacer. Esto incluye la magnitud del error, los tiempos de proceso, la facilidad de uso, el
ordenamiento adecuado de las transacciones, tiempos de paro aceptables, la comprensin de los manuales de
procedimientos, etc.
8.3.1.3. Prueba del sistema completo con datos reales.

Es de gran utilidad que el sistema interacte con datos reales, los cuales han sido procesados con xito por el
sistema existente. Esto permite una comparacin precisa con lo que es una salida procesada correctamente, y una buena
idea de cmo deben manejarse los datos reales. Como ocurre con los datos de prueba, slo deben utilizarse una pequea
cantidad de datos reales en este tipo de evaluaciones del sistema.
No es suficiente entrevistar al usuario acerca de cmo interaccionarn con el sistema; este es un importante
periodo para evaluar la manera en que los usuarios finales y operadores interactan con el sistema.
Elementos a observar: facilidad de aprendizaje del sistema, ajuste de factores ergonmicos; las reacciones del
usuario a la realimentacin, incluyendo lo que ocurra cuando se presenta en pantalla un mensaje de error y lo que
ocurrir cuando el usuario se entera de que el sistema est ejecutando sus comandos. Tambin se debe tener en cuenta la
manera en que el usuario reacciona al tiempo de respuesta del sistema, as como el lenguaje de las respuestas.
134
Los manuales de procedimientos deben ser evaluados durante las consultas con datos reales. Estos manuales
deben ser tiles y comprensibles, organizados de diferentes maneras para los usuarios que con distintos enfoques
interaccionan con el sistema.
Dentro de estas cuatro fases se realizan los siguientes tipos de prueba:
1.
Prueba de funcionalidad.
Asegura que el sistema realiza las funciones normales de manera correcta. As los casos de prueba se
desarrollan y alimentan el sistema; las salidas se examinan para ver si son correctas.
2.
Prueba de recuperacin.
Asegura que el sistema puede recuperarse adecuadamente de diversos tipos de fallas. Son de vital
importancia en los sistemas reales de gran procesamiento de informacin. Este tipo de prueba puede
requerir que el equipo que realiza el proyecto simule o provoque fallas de hardware, de corriente, fallas en
el sistema operativo, etc.
3.
Prueba de desempeo.
Asegura que el sistema puede manejar el volumen de datos y transacciones de entrada especificados en
el modelo de implantacin del usuario, adems de asegurar que tenga el tiempo de respuesta requerido.
Esto puede requerir que el equipo que realiza el proyecto simule una gran red de terminales en lnea, de
manera que se pueda simular la operacin del sistema con una gran carga.
4.
Prueba no exhaustiva.
Lo ideal es generar casos de prueba para cubrir cada entrada posible y cada combinacin posible de
situaciones que el sistema pudiera enfrentar alguna vez. Luego se probara de manera exhaustiva para
asegurar que su comportamiento sea perfecto. Sin embargo esto es imposible, en especial en sistemas
grandes. Lo que se debe crear en un conjunto de pruebas que cubran un gran porcentaje de los diferentes
caminos de decisin que pueda tomar, o lo que es lo mismo, los casos deben seleccionarse cuidadosamente
para pasar por tantos caminos lgicos como sea posible. Esto hace que el modelo de requerimientos del
usuario y los diversos modelos de implantacin sean tan correctos como se pueda.
Para lograr realizar las pruebas de manera efectiva debe, el equipo de desarrollo de sistema necesita tres cosas:
un plan de prueba, descripciones de prueba y procedimientos de prueba.
Un plan de prueba es un documente organizado que describe las actividades de prueba, conteniendo:
Propsito: cual es el objetivo de la prueba y que parte del sistema se esta probando.
Localizacin y horario de la prueba
Descripciones: de las entradas al sistema y las salidas.
Procedimientos: como deben prepararse y presentar los datos de prueba al sistema.
Como capturar los resultados de salida, como analizar los resultados.
Otros conceptos usados para aumentar el proceso estndar de prueba:
Recorridos y revisiones: es una forma de supervisin hecha por un grupo revisor de productos tcnicos
(diagramas de flujo, diagramas de estructura, programas) para descubrir errores
Inspecciones: son similares a los recorridos pero tienen un plan ms formal de puntos a examinar en el
programa, la especificacin o el diseo antes de que se pueda aprobar.
135
Pruebas de correccin: este tipo de prueba es altamente costoso porque consiste en desarrollar pruebas
rigurosas de la correccin de un programa. Solo se justifica realizar en sistemas de alto riesgo o
mxima seguridad.
136
9.
Implantacin
9.1.
Conversin
La conversin es la tarea de traducir los archivos, formatos y bases de datos actuales del usuario al formato que
el nuevo sistema requiere. Dependiendo de la cantidad de datos ser el grado de dificultad de esta tarea. Al existir datos
que requieren conversin, se necesita un plan de conversin que debe desarrollarse al terminarse el modelo de
implantacin, el cual debe cubrir los siguientes puntos:
9.2.
Si el usuario ya tiene datos existentes asociados con un sistema existente, probablemente querr usarlos
hasta el ltimo momento posible antes de pasarse al nuevo sistema. Por ello es difcil considerar los datos
existentes como estticos.
Pudiera haber un volumen tan grande de datos existentes que sea imprctico considerar convertirlo todo a
la vez. Los archivos y registros podran tener que convertirse en forma incremental. Esto requiere de una
planeacin y coordinacin cuidadosa.
La conversin debe llevarse a cabo de una manera automatizada; esto slo se puede hacer si los archivos y
datos actuales existen en algn formato automatizado. De ser as, debiera ser fcil escribir un programa
para traducir los archivos actuales al formato requerido por el sistema nuevo. Sin embargo, es difcil esta
forma de conversin, sobre todo si los archivos existentes se encuentran en distintas computadoras, en
distintos formatos, etc.
Los datos existentes pueden contener errores. Por ello, parte del proceso de conversin es la deteccin y
correccin de errores, que puede volver el proceso an ms difcil y retardar el proceso.
Adems de convertir archivos existentes, puede ser necesario convertir programas y procedimientos
existentes.
Capacitacin
La capacitacin es la tarea final del equipo de desarrollo del sistema. Consiste en la preparacin de los usuarios,
del personal de operaciones, los programadores de mantenimiento y varios niveles de administracin. Se debe realizar
un plan de capacitacin es cual debe estar lista al mismo tiempo (si es que no antes) de que el sistema empiece a operar.
Este plan debe contemplar los siguientes aspectos:
Sera conveniente que a los manuales del usuario y guas de referencia se sumen clases y seminarios en
vivo, adems de charlas de orientacin para administradores y personas que necesiten estar al tanto del
sistema aunque no interacten con l a diario. Para lo cual se cuenta con una serie de medios didcticos
modernos: VHS o DVD, enseanza por computadora, e incluso versiones de simulacro del sistema real
para que el usuario pueda ingresar transacciones e interactuar con l. La capacitacin podra consistir en
opciones de ayuda altamente elaboradas integradas al sistema mismo.
Lo recomendable es que personal integrante del equipo de desarrollo del sistema participe en el proceso por
ser los mejores expertos sobre todo como funciona el sistema, aunque no siempre son los mejores
maestros.
La capacitacin debe hacerse en un tiempo relativamente corto, y, prxima al uso del nuevo sistema. Se
deber negociar con ellos un programa de actividades de capacitacin.
137
9.3.
Instalacin
La instalacin es la actualizacin fsica del sistema de informacin existente en uno nuevo modificado. Se
requiere hacer lo siguiente:
Preparar la sede de la computadora. Esto requiere construir o rentar un local de cmputo con la corriente,
espacio, iluminacin y control ambiental adecuados.
Preparacin de la sede del usuario, sobre todo cuando el sistema es en lnea y se requiere terminales e
impresoras en el rea de trabajo del usuario.
La instalacin del hardware, cuando el sistema requiere su propia computadora, usualmente la efecta el
proveedor cuando esta tarea es compleja.
La instalacin de software en las computadoras adecuadas y prepararlas para su operacin.
En el caso de sistemas grandes y distribuidos, pudiera haber una sede de computadoras central y docenas e
incluso cientos de sedes de usuarios. En tal caso puede ser necesario instalar el sistema por etapas, con la visita de
equipos de instalacin especialmente capacitados a cada sede de usuarios de acuerdo a un programa preestablecido. La
instalacin no ser inmediata, se har gradualmente durante un perodo de tiempo.
Existen cinco enfoques de conversin de sistemas:
1.
Conversin Total.
Significa que para una fecha especfica el sistema anterior se retira y el nuevo se pone en uso. Este tipo
funciona mejor cuando pueden tolerarse ciertos retrasos en los procesos. La ventaja es que no hay
posibilidad de que los usuarios sigan utilizando el viejo sistema. Sin embargo es un enfoque riesgoso
porque si se producen errores los retrasos sern significativos por no haber una forma alternativa de
procesamiento; el impacto en los usuarios ser alto por ser el cambio brusco; no hay forma de realizar
comparaciones de los nuevos resultados con los anteriores.
2.
Conversin Paralela.
Este se refiere al uso del sistema anterior y del nuevo al mismo tiempo. Slo es ptimo cuando se
reemplaza un sistema manual. Durante un periodo se observan los resultados y una vez se son iguales se
pone en uso el nuevo y se descarta el sistema viejo. El costo de operar dos sistemas simultneamente es
alto y puede resultar agotador para los usuarios. La comparacin puede ser difcil, a menos que el sistema
viejo sea manual. Los usuarios continuarn interesados en le sistema anterior por estar mas familiarizados
con mismo.
3.
Conversin Gradual.
Intenta combinar las ventajas de los dos mtodos anteriores. El nmero de transacciones se incrementa
en forma gradual conforme el sistema se va implantado. Permite que los usuarios se familiaricen en forma
gradual con el nuevo sistema y la posibilidad de recuperarse de los errores, sin grandes tiempos muertos.
Este enfoque puede requerir demasiado tiempo para la implantacin del nuevo sistema.
4.
Conversin por Prototipos Modulares.
Considera la construccin de un prototipo modular operativo para el cambio gradual. Conforme se

modifica cada mdulo y se acepta, se pone en operacin. Este permite una prueba completa antes de
utilizarse.
Los usuarios se familiarizan con los mdulos conforme stos se vuelven operativos.
138
5.
Conversin Distribuida.
Este contempla muchas instalaciones del mismo sistema. La conversin se realiza en un solo sitio. Una
vez concluida con xito, se realiza otra conversin en los otros sitios. Permite detectar problemas y
evitarlos en otros sitios.
Sin embargo, cada sitio tendr sus propias peculiaridades.
139
10.
Mantencin
Una analista al crear un sistema debe tener la visin de realizar un diseo comprensible y duradero que sirva
para las necesidades actuales y las proyectadas durante varios aos. Parte de su experiencia debe encaminarse a
pronosticar cules necesidades llegarn a aparecer e incorporar cierta flexibilidad y adaptabilidad en el sistema. Cunto
mejor sea el diseo del sistema, ms fcil ser darle mantenimiento y se requerir menos dinero de la empresa para su
mantenimiento.
La reduccin de los costos de mantenimiento es una preocupacin importante de las empresas, ya que el
mantenimiento del software, por s slo, puede devorar hasta el 50 % del presupuesto total de procesamiento de datos.
En el mantenimiento se reflejarn costos excesivos de manera directa sobre el diseador del sistema. Aproximadamente
el 70% de los errores de software se han atribuido a un diseo inadecuado. Desde una perspectiva de sistemas, tiene
sentido detectar y corregir los errores de diseo en el software, en su fase inicial, cuando an es menos costoso dejar que
los errores permanezcan sin identificarse hasta realizar el mantenimiento.
El mantenimiento se realiza para mejorar un software existente, ms que para responder a una crisis o falla de
sistema. Conforme cambian los requerimientos de los usuarios, el software y la documentacin tambin deberan
cambiar, como parte del trabajo de mantenimiento. Adems los programas podran volverse a codificar para mejorar su
eficiencia sobre el programa original. Ms de la mitad del mantenimiento se orienta a tales tareas de perfeccionamiento.
El mantenimiento tambin se realiza para actualizar el software en respuesta a los cambios de la organizacin.
El mantenimiento de emergencia y adaptativo cubre menos de la mitad del mantenimiento total del sistema.
Parte de las tareas del analista es asegurar que existan canales y procedimientos adecuados para permitir una
retroalimentacin acerca de las necesidades de mantenimiento.
Los usuarios y operadores deben ser capaces de comunicar de manera sencilla los problemas y sugerencias a
quienes les dan mantenimiento al sistema. Ser de utilidad que el analista establezca un esquema de clasificacin para
jerarquizar la importancia del mantenimiento requerido. Las peticiones clasificadas permitirn a los programadores del
mantenimiento comprender cmo los usuarios por s mismos, consideran la importancia de sus peticiones. Estas
peticiones pueden tomarse en cuenta junto con otros factores a la hora de programar el mantenimiento.
Una vez instalado el sistema y puesto en operacin, los analistas dejan el proyecto. Algunos programadores se
quedan para el mantenimiento. Pero la mayora de los analistas, diseadores y programadores se transfieren a otros
nuevos proyectos.
Pero el trabajo realizado debe mantenerse durante loa 5, 10 o 20 aos de vida operacional del sistema, tanto los
programas como las especificaciones.
A la hora de realizar modificaciones, a menudo resulta ms fcil una correccin, mejora o cambio rpido y
sucio al sistema existente, que empezar a cambiar el documento de los requerimientos y luego propagar dicho cambio
al documento de diseo y la implantacin del mismo. Esto ocurre sobre todo cuando se necesita el cambio para arreglar
un problema inmediato y urgente. La documentacin es lo ltimo que se quiere hacer, y muchas veces no se hace.
Los sistemas de informacin tienden a ser complejos desde el principio, y se vuelven cada vez ms complejos
al pasar los aos de mantenimiento.
Sin un buen mantenimiento, cualquier sistema puede convertirse en un misterio. La nica solucin es mantener
documentacin precisa y actualizada por la duracin del sistema mismo.
10.1.
Auditoria
La auditoria es otra forma de asegurar la calidad de la informacin que contiene el sistema. Con una definicin
amplia, la auditoria involucra a un experto que no se encuentra involucrado en la puesta en operacin y el uso del
sistema, para examinar la informacin, con el fin de examinar su relevancia. Si se encontrara o no informacin relevante,
140
tal hallazgo deber comunicarse a otros con el propsito de mejorar la relevancia de la informacin que les proporciona
el sistema.
Para los sistemas de informacin existen dos tipos: la interna y externa. La necesidad de ambas para el sistema
que se disea depender del tipo de sistema.
Para las auditorias internas operan personal de la misma organizacin propietaria del sistema, mientras que para
las externas se contrata personal externo.
Los auditores internos estudian los controles utilizados por el sistema para asegurar que ste realiza lo que
supuestamente debe de hacer, as como la operacin de los controles de seguridad. Los informes no reportan a los
responsables del sistema que auditan.
Los externos se contratan cuando los sistemas influyen en los estados financieros del negocio y se debe
asegurar la confiabilidad de estos informes. Tambin intervienen cuando algo fuera de lo ordinario ocurre involucrando
a los empleados de la compaa.
141

Analisis y Diseno de Sistemas

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Analisis y Diseno de Sistemas

Cargado por

Copyright:

Formatos disponibles

Anlisis y Diseo de Sistemas

Texto Preparado por Oscar A. Nez Madrid

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas

Generalidades del Anlisis de Sistemas de Informacin.

La posibilidad de que factores desconocidos influyan en las observaciones es mucho mayor.

Como consecuencia, los modelos cuantitativos son muy vulnerables.

Anlisis y Diseo de Sistemas

Un concepto previo al de comunicacin es el de informacin. Los trabajos en este campo de Wiener y

Investigar el isomorfismo de conceptos, leyes y modelos en varios campos, y promover transferencias

Favorecer el desarrollo de modelos tericos adecuados en aquellos campos donde faltaran.

Reducir en lo posible la duplicacin de esfuerzo terico en campos distintos.

Promover la unidad de la ciencia, mejorando la comunicacin entre los especialistas.

Anlisis y Diseo de Sistemas

La existencia de elementos diversos e interconectados.

El carcter de unidad global del conjunto.

La existencia de objetivos asociados al mismo.

La integracin del conjunto en un entorno.

Las Ciencias de la Complejidad

Hacen hincapi en el estudio de la estructura (interconexin entre componentes) y su importancia en el

Destacan el carcter de totalidad o unidad global de los sistemas objeto de estudio.

El ordenador es la herramienta fundamental de las ciencias de la complejidad debido a su capacidad

Anlisis y Diseo de Sistemas

2.1.2.1. Ingeniera de Sistemas

La dimensin del conocimiento: se refiere al conocimiento especializado de las diversas profesiones y

Para Wymore, el objeto de la Ingeniera de Sistemas es el "anlisis y diseo de sistemas hombre-mquina,

Anlisis y Diseo de Sistemas

2.1.2.2. Anlisis de Sistemas

Anlisis de un sistema ya existente para comprender, mejorar, ajustar yo predecir su comportamiento.

Anlisis como paso previo al diseo de un nuevo sistema-producto.

Anlisis de condiciones (o constricciones): Debe reflejar todas aquellas limitaciones impuestas al

Operativas, como son las restricciones fsicas, ambientales, de mantenimiento, de personal, de

De calidad, como fiabilidad, mantenibilidad, seguridad, confidencialidad, generalidad, etc.

Econmicos, reflejados en un presupuesto.

Temporales, que suponen unos plazos a cumplir.

Metodolgicos, que conllevan la utilizacin de tcnicas determinadas.

Materiales, como espacio, herramientas disponibles, etc.

Construccin de modelos: Una de las formas ms habituales y convenientes de analizar un sistema

El anlisis debe ser consistente y completo.

Anlisis y Diseo de Sistemas

2.1.2.3. Diseo de Sistemas

Diseo e implementacin de cada uno de los subsistemas:

Especificacin consistente y completa del subsistema de acuerdo con los objetivos

Desarrollo segn la especificacin.

Integracin de todos los subsistemas.

Validacin del diseo.

2.1.2.4. Gestin de Sistemas

Controlar la validez de los criterios de diseo.

Anlisis y Diseo de Sistemas

Planificar y desarrollar las necesidades de mantenimiento.

Planificar la supervisin del funcionamiento del sistema.

Concepto de sistema, caractersticas que lo definen y su enfoque.

Anlisis y Diseo de Sistemas

Caractersticas que lo definen.

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas

Cuntos elementos distinguibles tiene este aparente problema?

Qu relaciones de causa y efecto hay entre esos elementos?

Qu funciones hay que ejecutar en cada caso?

Qu intercambios pueden requerirse entre los recursos despus de que se definan?

Anlisis y Diseo de Sistemas

1. Optimizar la zona de cocimiento y el proceso.